Hi Jean-Francois,
I was not yet a member of this mailing list when this conversation
took place, so I've had to do some copying & pasting from the java.net
site. Hopefully this message will be categorized into the correct
message thread.
I am exploring the implementation of a framework on top of Grizzly
that will send messages asynchronously to Flash applications. Since
over 95% of browsers on the web today have Flash installed, this is
similar to Comet but more straightforward on both the server and
client side, and hopefully more performant because of the lack of http
overhead, etc. My dream is to downgrade connections to Comet whenever
Flash is not installed or when a direct non-http socket connection is
blocked by a firewall. I am imagining that I can ultimately scale this
by connecting the server processes to an application server using JMS.
As Luiz mentioned, in
https://grizzly.dev.java.net/servlets/ReadMsg?list=users&msgNo=117 you
wrote:
> The current Comet implementation currently support async read/write via
> a second Selector. I suspect I can generalize the implementation so it
> can be used outside of Comet.
I believe this is correct; the implementation can be generalized. I
really hate the idea of duplicating some of your code and effort in an
attempt to build my framework.
That being said, I am reading through the Comet implementation right
now. Though I'm unfamiliar with Netbeans (grumble grumble), it seems
that the only place in com.sun.grizzly.comet where a Selector is
created is in the CometSelector thread, created and started exactly
once in CometSelector#start. It also seems that CometSelector#start
can only be called once per application, since it seems to only be
called in the CometEngine singleton constructor. I therefore fail to
see the second selector to which you were referring. Or perhaps this
one Selector *is* the second Selector? Maybe the first one was the one
in com.sun.grizzly.http or whatever that handles synchronous http
requests.
Furthermore, there is something about com.sun.grizzly.comet that
surprises me: it seems that the only class in com.sun.grizzly that it
depends on is Pipeline. If you were to generalize the implementation,
how do you imagine pulling the current functionality in CometSelector
into com.sun.grizzly.comet? Suppose I were to go crazy and try to do
this on my own. Are there tests I can run against Grizzly Comet to let
me know if I've inadvertently broken something?
Thank you,
Adam
--
aduston_at_uchicago.edu
312-375-9879