If you don't care about this stuff, but still read the first line, do
our community a favor and get involved :)
The API's are pretty much identical,
Remy:
https://svn.apache.org/viewvc/tomcat/sandbox/comet/java/org/apache/catalina/CometEvent.java?view=markup
Filip:
https://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/CometEvent.java?view=markup
There are a few differences
isReadable()
- Remy - same functionality as ServletInputStream.available()
- Filip - ServletInputStream.available() ||
InternalNioInputBuffer.hasData ||
InternalNioInputBuffer.nonBlockRead().hasData
ie, is readable in my API means that there is some data from the bottom
layer of the API. Doesn't mean that it would actually result in data to
a ServletInputStream.read(), but most cases it would. The benefit of
this method is that it actually does check the socket for data in a non
blocking way if the first two conditions have not been met.
API has been implemented in trunk. so isAvailable() is different, and
both methods can be used for different purposes
isWriteable()
This functions the same way in both APIs. After playing with the API
this function is useless unless you have true non blocking writes.
Why? Well, the function will always return true, unless there is
another thread writing, but write is not thread safe, so another thread
should never attempt to write.
And in a blocking way, isWriteable()->true : write(blocking) :
isWriteable()->true, always.
However, in the blocking API, there is a true way to find out if we can
write or not, and that is by calling CometEvent.register(OP_WRITE), this
will actually check with the poller
to see if the network buffer is ready to receive more data and dispatch
a worker thread.
callback()
- Remy - one time callback from the container on a Tomcat worker thread
- Filip - same functionality implemented, CometEvent.register(OP_CALLBACK)
I definitely like the register/unregister for events more than I like
the one time functionality of callback()/sleep().
OP_CALLBACK currently is implemented and working in trunk.
Why do I like register more? Cause we can add new operations in the
future without changing the API. This leads to more flexibility.
Currently OP_CALLBACK stays registered until it is "unregister"-ed. If
we wanted to achieve callback() functionality, we can add a
OP_CALLBACK_ONCE operation or simply change the behavior of existing
callback, without changing the API.
it is also possible to retrieve the state of a comet connection by
calling getRegisteredOps, something not available in the sandbox API.
sleep()
- Remy - deregister from the READ events
- Filip - same functionality exists,
CometEvent.unregister(OP_READ,OP_WRITE,OP_CALLBACK) or simply
CometEvent.unregister(OP_READ) if nothing else is registered.
Again, I think the trunk API is more flexible, and cleaner. sleep() is
associated with Thread.sleep() in every programmers head. and doesn't
really apply to an event based API.
This is implemented in trunk and working.
Conclusion, both APIs are almost identical. I believe the trunk API is
more flexible and allows for additions of functionality in the future
without changing the API.
Remy's initial -1 to the trunk was based on the implementation, having
to synchronize etc. All that has been simplified and removed.
So therefor, the API's are almost identical, I would vote
sandbox API -> -1 -> API is simple but not extensible, names are not
intuitive as they are not event oriented.
trunk API -> +1 -> API is equally simple, more geared towards event
based API, more flexible, as I am sure new needs will need new
operations and events
The only thing not working in trunk at this moment is non blocking, but
after doing the research, this is a major surgery to try to do within
the existing buffer/filter API
I'd rather delay such an attempt until we can reach consensus on the API
and the "simple stuff".
Looks like we are gonna have to have a pancake flipping contest :)
Filip
Remy Maucherat wrote:
Hi,
I've been working on additions to CometEvent to implement the
additional Comet functionality that was agreed upon before creating
the "trunk" branch. Although not functional at the moment, I consider
it to be developed enough from an algorithmic standpoint to be
proposed and reviewed (it is also important to not continue an API
fork for too long, since otherwise it would be harder to merge, so
some resolution is needed). I went through a few revisions of the API,
as more tweaks appeared possible. The idea was to allow the extra
functionality without adding complexity or incompatible changes, since
this is most likely going to be an interim API.
The repository is at:
https://svn.apache.org/repos/asf/tomcat/sandbox/comet
It has the following changes over the 6.0.x branch:
- additions of four methods in CometEvent (sleep and callback, and the
two flags isRead(Write)able)
- sleep delays request processing until either callback is called, or
a timeout occurs
- callback allows waking up requests which are "asleep" or waiting for
an IO event
- non blocking IO exclusively in Comet mode, since it now seems to me
it is algorithmically equivalent to blocking IO; for read, it has been
demonstrated previously; for write, it seems there should always be
write events after a properly handled congestion (where the servlet
uses isWriteable), since if the servlet does not, it will be best to
simply fail-fast the connection using an IOException (the servlet
would effectively only handle clients which are "fast enough" if using
the Comet API like in Tomcat 6.0, which avoids a lot of issues)
- isRead(Write)able indicate if data may be read or written (since
this is non blocking IO, reading or writing would read or write 0
bytes); if it is false and reading or writing is done, an IO exception
will be thrown
- no additional data structures
- new ActionCode: ACTION_COMET_TIMEOUT (which is cleanup),
ACTION_COMET_CALLBACK (called by the callback() method),
ACTION_COMET_SLEEP (called by the sleep() method), ACTION_COMET_WRITE
(called by the CometEvent.isWriteable method without the need for an
explicit callback from the servlet - isWriteable knows the result of
the last write, and the servlet is supposed to not attempt any further
writing if isWriteable returns false)
- no additional features, like verification of caller threads (which I
consider useless)
I hope I did not forget anything.
Comments ? / Votes ?
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
