Hi Ken,
For a while, I tried to think your question about IOStrategy.
* 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.
If I remember correctly, I think that your features can be similar to multi
selector function relating to cpu num in Grizzly than dynamic pattern.
And I am curious about the benefit of your temporary selector(compared to
multi read selector function). I am unsure I am understanding your words
correctly.
I couldn't find the DynamicIOStrategy implementation in trunk's Grizzly 2.0
source. If I am understanding the doc correctly, I think Dynamic IOStrategy
means that users' implementation or Grizzly's implementation (which will be
provided?) just chooses either Worker-thread IOStrategy or Same-thread
IOStrategy according to system's load, statistics and etc.
As your sample, if you can know the message size("hot" event) in advance and
you choose either same main thread or worker thread("hot"), I think it look
like the dynamic pattern of Grizzly.
If I am misunderstanding, please feel free to advice me.
Thanks.
Regards,
Bongjae Chang
From: Ken Cavanaugh <kencavanaugh_at_mac.com>
Reply-To: <dev_at_grizzly.java.net>
Date: Mon, 14 Feb 2011 23:38:41 -0800
To: <dev_at_grizzly.java.net>, Ryan Lubke <ryan.lubke_at_oracle.com>
Cc: Ken Cavanaugh <kencavanaugh_at_mac.com>
Subject: Re: Documentation efforts for Grizzly 2.0
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.