From: fhanik
+ The previous section touched a little bit on the comet connection lifecycle.
+ It is important to remember that comet events are based around IO on an actual socket.
+ To clarify the Comet API, it has been created to resemble the java.nio channel/selector APIs.
+ In the case of Comet, Tomcat is the selector and using the CometEvent object, you can
+ register and unregister your Comet event for different event type notifications.
+ We call the parameter to the CometEvent.register/unregister method a comet operation.
+ This is similar to the interestOps method of a SelectionKey in the java.nio implementation.
+
The Comet implementation of register and unregister has been greatly simplified to not force the
+ comet developer to implement complex synchronizations around the register and unregister code.
+
+ It is important to realize, just like the java.nio API, that once an operation has been registered, it will
+ remain registered until it is unregistered. If you have registered OP_READ, then the comet connection will
+ fire READ events, every time data arrives until your unregister the OP_READ operation.
+ OP_CALLBACK/OP_WRITE work in the same way, essentially, register(OP_CALLBACK|OP_WRITE) will keep spawning
+ CALLBACK/WRITE events until you unregister the operation(s).
+
+ Imagine you are writing a servlet that is updating a set of
+ stock tickers. You have a back ground thread that is receiving
+ updates for tickers as they happen, and you wish to push out these
+ to all the tickers that have the stocks in their list.
+ In the following example, you can accomplish maximum through put by
+ taking advantage of Tomcat's non blocking Comet features.
+ When the StockUpdater thread is running, it receives a set of stock updates.
+ It gets all the clients that are registered for the stocks that have changed.
+ For each client, there is an associated CometEvent object, the StockUpdater
+ checks if it can write without blocking, if so it writes directly, otherwise
+ it registers the client for a WRITE event, that will tell the
+ system that we can write the data now.
+ This is a perfect example of how we can take advantage of the combination of the write event
+ and the isWriteable method to determine, when we can write the data.
+ As with any kind of non blocking IO, you will need to synchronize your code,
+ this has not been done in the example below since the focus is on the
+ data delivery, not synchronization.
+
+ The above stock ticker example is extremely powerful,
+ but also creates a great deal of complexity trying to
+ synchronize between the registration of interested events
+ between the threads.
+ Another option is to simplify this by using blocking IO.
+ That implementation would look like this.
+ Notice that writing data to the client is only done
+ upon an event and never asynchronously. Assuming that the data written is smaller
+ than the socket network buffer, this write is almost always guaranteed
+ to be written without a delay. Should the write be blocked,
+ the system is still concurrent, as the writing happens on a thread
+ from Tomcat's thread pool.
+ In this case, the only synchronization that needs to be done is in between
+ client.getNextUpdates() and client.setAndMergeNextUpdates(clientList).
+
+ Imagine that you wish to write a pseudo transactional system,
+ (please take the word transaction with a grain of salt),
+ and be able to do your own write scheduling.
+ In the next example we are going to demonstrate the ability to
+ use the isReadable() and isWriteable() methods in a poller sense,
+ and do all writes and reads asynchronously on a single thread.
+ Our goal here is to implement a comet servlet that reads a client request,
+ then writes a chunk of data when the request has been received.
+ The servlet will not write the next chunk until the first request has been read
+ and first chunk has been written to all clients.
+ The code below is far from optimal, but it demonstrates the ability
+ to not rely on any IO events, and schedule yourself when you wish to read
+ or write data. All operations are non blocking, so the AllWriterThread
+ will never block on any operation.
In the example below,
+ we just do a busy spin cycle.
+ other
+
+ Ok, so the previous example was kind of silly, but we demonstrated that + you are able to read/write on a single thread, in a non blocking fashion. + Now we are going to achieve the exact same functionality, but not using + any asynchronous data, instead we are going to use + blocking IO and tomcat's worker threads +
+The following pseudo code servlet implments asynchronous chat functionality using the API described above: