Hi Alexey,
Your information is helpful for me. I see..
Thanks a lot.
Regards,
Bongjae Chang
From: Oleksiy Stashok <oleksiy.stashok_at_oracle.com>
Reply-To: <dev_at_grizzly.java.net>
Date: Wed, 16 Feb 2011 11:00:56 +0100
To: <dev_at_grizzly.java.net>
Subject: Re: Documentation efforts for Grizzly 2.0
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:
>> * 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.
>
>
>
>
>