Hi Adam,
sorry for the delay. Today we launched GlassFish v2 and it was kind of
crazy :-)
Adam Duston wrote:
> 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.
Yes I can't wait to see your code :-) :-) BTW, with the current Comet
implementation, you can always write your own NotificationHandler that
hooks into a JMS engine (like IBM is doing with Bayeux in WebSpehere).
>
> 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.
Yes this is something on my plate. Mostly I want to pull out the Comet
design from HTTP and supports it a the TCP level. I can't promise
exactly when I will have it but for sure it is before end of October
(next week I'm stuck at AjaxWorld, demonstrating the Comet monster :-)).
>
> 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.
This is the "main" one where the initial request was accepted. In the
current code, the com.sun.grizzly.http.SelectorThread accept the
requests (under the hood its a TCPSelectorHandler), reads some bytes and
then delegate the bytes request processing to Grizzly Asynchronous
Request Processing (on which Comet is build on top of it, as an
AsyncFilter). Hence the first Selector is the one accepting the connection.
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.
Indeed.
>
> 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.
Right, but the current AsyncProcessorTask are http dependent, and that's
the one that sequentially execute the request (with the help of the
AsyncExecutor|AsyncHandler). We need a similar mechanism for TCP where
we can sequentially execute the following operations:
1. Read bytes
2. Parse bytes (request line most of the time)
3. Execute (for Comet/Http, it means hooking the CometEngine)
4. Write response
5. Park or resume the transaction
If you were to generalize the implementation,
> how do you imagine pulling the current functionality in CometSelector
> into com.sun.grizzly.comet?
I would first implement an async mechanism similar to the
AsyncHandler|Executor. Then build Comet on top of it (we shouldn't not
say Comet as it too tight to http). I suspect a generic ProtocolFilter
(maybe named AsyncProtocolFilter) can be the entry point.
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?
Go crazy anytime :-) Writing Comet unit test is quite complicated and
right now I didn't spend the time on it. But I've several applications
that we can use for testing our implementation. I know this is not the
best way, but that's better than nothing!
Thanks!
-- Jeanfrancois
>
> Thank you,
> Adam
>