On Feb 14, 2011, at 6:43 PM, Ryan Lubke wrote:
> Hey Folks,
>
> We're following up on our original message about the documentation efforts for Grizzly 2.0.
>
> I'm happy to report that we've made decent progress on this effort, however, before Grizzly 2.0
> goes final, it would be great if the community could review the documentation [1] in an effort
> to find errors or offer suggestions on how to improve it.
>
> Please log any bugs/suggestions on JIRA [2] using the documentation component
> and we'll address them as quickly as possible.
>
> [1] http://grizzly.java.net/nonav/docs/docbkx/html/grizzly-docs.html
> [2] http://java.net/jira/browse/GRIZZLY
>
I've read the core docs (I'm not too interested in the HTTP code), and started looking at
the use of Grizzly in CORBA (finally!). I have a few preliminary questions/comments:
The GIOP message parsing example is more or less what I've wanted to be able to write. This seems to do a good job of simplifying the parsing nightmare we had in 1.x.
I'll probably have problems with the TCP selector strategies. The scheme that the ORB uses is a bit complicated:
We start with one selector.
When a message arrives on a connection (doesn't matter whether it's client or server), we treat the connection as being "hot". This means that a new temporary selector is allocated, and effectively that thread is dedicated to handling only one connection.
When the connection is no longer hot (currently I think this happens when the ORB finishes processing the last fragment of a possibly long message), the temporary selector is released, and the SelectionKey (I think) is returned to the main selector.
There must always be a dedicated main selector, which can never block for a significant time.
This looks somewhat like the dynamic pattern, but I'm unsure how to do this in Grizzly.
I also need the connection cache semantics like what I originally created for Alexey for SOAP/TCP, which I think was integrated into Grizzly 1.x.
I can certainly use the version I have in the ORB, which has seen more refinement in any case.
I'm not sure how exactly I can integrate this into Grizzly 2.0.
The key requirement is that the ORB must manage the complete lifecycle of the connection.
In particular, releasing a connection can only happen when we know no outstanding work requires the connection, and the release must be atomic with respect to acquiring or reusing a connection.
These may be interesting topics for the next Grizzly meeting.
The docs look pretty good, aside from Bongjae's comments (the missing diagrams in particular are a serious and
hopefully easy to fix issue).
Thanks,
Ken.