Hi guys,
if I understand correctly Ken allocates temporary selector to mimic
blocking I/O on top of non-blocking channel, it's what Grizzly 1.x is
usually doing and 2.0 Connections, when used in blocking mode. Temporary
selectors might be useful if you want to have InputStream, which is
blocking, built on top of NIO Channel and work with the channel like it
was blocking. This is something we'd like to avoid in 2.0, especially
when using same thread strategy.
Agree with Ken, it could be interesting topic to discuss during the
today's meeting.
Thanks.
WBR,
Alexey.
On 02/16/2011 09:49 AM, Bongjae Chang wrote:
> 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:
> o We start with one selector.
> o 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.
> o 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.
> o There must always be a dedicated main selector, which can
> never block for a significant time.
> o 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 <mailto:kencavanaugh_at_mac.com>>
> Reply-To: <dev_at_grizzly.java.net <mailto:dev_at_grizzly.java.net>>
> Date: Mon, 14 Feb 2011 23:38:41 -0800
> To: <dev_at_grizzly.java.net <mailto:dev_at_grizzly.java.net>>, Ryan Lubke
> <ryan.lubke_at_oracle.com <mailto:ryan.lubke_at_oracle.com>>
> Cc: Ken Cavanaugh <kencavanaugh_at_mac.com <mailto: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:
> o We start with one selector.
> o 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.
> o 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.
> o There must always be a dedicated main selector, which can
> never block for a significant time.
> o 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.
> o I can certainly use the version I have in the ORB, which
> has seen more refinement in any case.
> o I'm not sure how exactly I can integrate this into Grizzly
> 2.0.
> o 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.
>