voyent
AHS vs Tomcat 6 NIO  XML
Forum Index -> Async HTTP Server
Author Message
Marioko

Joined: 14/Nov/2006 00:00:00
Messages: 125
Offline


Hi, in icefaces developer guide said that we can use AHS or Tomcat 6 for scaling application using NIO..

what is the advantages and disvantages between AHS and Tomcat 6 NIO connector???

thanks
pred


Joined: 09/Jul/2007 00:00:00
Messages: 87
Offline


Yes some information will be great =)

- Stephane Maldini
jack.van.ooststroom


Joined: 26/Oct/2004 00:00:00
Messages: 223
Offline


Explanation of the Differences Between AHS and Tomcat 6 NIO

I'll explain the differences between AHS and Tomcat 6 NIO or any other supported ARP (Asynchronous Request Processing) solutions like GlassFish' Comet support (GlassFish ARP) and Jetty's Continuations (Jetty ARP). Two things should be basically taken into account: ARP and Single Point of Entry.

1. ARP

When it comes to ARP, we recommend using the application server's ARP capabilities if available, thus GlassFish ARP, Jetty ARP, or Tomcat 6 NIO. Please note that when AHS is running in servlet-mode it can utilize GlassFish ARP or Jetty ARP as well. (AHS in servlet-mode currently cannot utilize Tomcat 6 NIO.)

However, when the used application server does not have ARP capabilities that are supported by ICEfaces, the AHS can be used in server-mode to utilize its own ARP capabilities. AHS running in server-mode requires more configuration though as it listens to its own port for incoming connections, thus not using the application server's traditional port. This configuration will require a web server front-end as explained in the ICEfaces Developer's Guide.

2. Single Point of Entry

When multiple asynchronous ICEfaces applications are deployed in separate .war-files to the same application server, problems could arise as each ICEfaces application will have its own instance of the BlockingServlet.

Each asynchronous ICEfaces application requires at least two connections from the browser to the server: one for the UI requests and one for the blocking requests. Certain browsers will only allow up to two simultaneous connection to the same host:port combination. Thus accessing two asynchronous ICEfaces applications from a single browser instance will require probably 3 simultaneous connections (2 connections for the blocking requests and one connection for the UI requests).

AHS can help out in situations like these to function as a Single Point of Entry. In this case, AHS would handle the blocking requests for all asynchronous ICEfaces applications running in the back-end. The applications will feed their updates to AHS using JMS communication.

I hope this clarifies the differences.

Regards,

Jack van Ooststroom
Senior Developer
ICEsoft Technologies, Inc.
[Email]
pred


Joined: 09/Jul/2007 00:00:00
Messages: 87
Offline


Thanks for your answer =)

If I have well understood :
Nothing < Tomcat 6 NIO or other ARP system < AHS

- Stephane Maldini
qpid

Joined: 09/Nov/2007 00:00:00
Messages: 21
Offline


These are very important information, wondering why they aren't in the developers guide on page 54 near to:
Another potential advantage of ICEfaces AHS is that it can function
as a single-point-of-entry for all blocking connections to avoid the various connection limits to the same
host enforced by the browsers. Multiple asynchronous ICEfaces applications can be configured to use
the same ICEfaces AHS instance, further improving configuration flexiblity and scalability. 


While the first reading i didn't notice this information. Whereas I only understand this behaviour of some browser/platforms after your comment.

Thank you!

regards qpid


 
Forum Index -> Async HTTP Server
Go to:   
Powered by JForum 2.1.7ice © JForum Team