dev@grizzly.java.net

Re: Issue No. 534

From: Oleksiy Stashok <Oleksiy.Stashok_at_Sun.COM>
Date: Wed, 06 May 2009 16:59:09 +0200

>> Yesterday I added a configuration API to avoid caching Context. I
>> did some benchmark and didn't see any regressions but a very tiny
>> improvement...but I need to do more testing as I suspect it will
>> impact garbage collection a lot. So I will implement the Context-
>> per-thread tomorrow and do more testing.
> Not sure this will be easy. As we create Context and *then* pass it
> to thread pool, which in its turn picks up a thread and runs task.
> So, to be able to use Context-per-Thread we need to be able to pick
> up a thread from thread pool, get associated Context and then run
> the task directly on thread, bypassing thread pool.
I will correct myself.
For Leader/Follower strategy, which we recently implemented, we can
use Context-per-Thread. I've implemented that for 1.9.16

WBR,
Alexey.

>
>
> WBR,
> Alexey.
>
>>
>>
>> A+
>>
>> -- Jeanfrancois
>>
>>> Minoru
>>>> Salut,
>>>>
>>>> Jeanfrancois Arcand wrote:
>>>>> Salut,
>>>>>
>>>>> Oleksiy Stashok wrote:
>>>>>> Hi Minoru,
>>>>>>
>>>>>>> Thank you for your information. I built grizzly-framework jar
>>>>>>> with
>>>>>>> revision 3055, but the problem was not solved. I'll try to fix
>>>>>>> the problem
>>>>>>> without using synchronized blcok.
>>>>>> Oh, sorry.
>>>>>> I really doubt it's not possible to solve this completely
>>>>>> without synchronization.
>>>>>>
>>>>>> And I'm starting to think about removing Context cacheing at
>>>>>> all. So for each I/O event we will create new Context. Cause I
>>>>>> expect caching (synchronization + Context reseting) is probably
>>>>>> more expensive, than creation of new Context object.
>>>>> I'm not sure...we need to do some benchmark to see if that will
>>>>> really make a difference. An alternative can also be to have one
>>>>> Context per Thread like ByteBuffer.
>>>> OK discussing with Alexey we decided to go ahead and stop caching
>>>> Context object. This is configurable
>>>> (Controller.setAllowContextCaching(..)). Default is false.
>>>>
>>>> Thanks!
>>>>
>>>> -- Jeanfrancois
>>>>
>>>>
>>>>
>>>>> A+
>>>>>
>>>>> --Jeanfrancois
>>>>>
>>>>>
>>>>>
>>>>>> What do you think?
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> WBR,
>>>>>> Alexey.
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Minoru
>>>>>>>
>>>>>>>
>>>>>>>> Hi Minoru,
>>>>>>>>
>>>>>>>>> I tested my program with grizzly-
>>>>>>>>> framework-1.9.15-20090423.170629-3.jar
>>>>>>>>> and grizzly-utils-1.9.15-20090423.170629-3.jar.
>>>>>>>>> Unfortunately the result
>>>>>>>>> was as same as before. I investigated the problem a little,
>>>>>>>>> and I found
>>>>>>>>> out that instance of SelectionKeyContextTask was actually a
>>>>>>>>> CallbackHandlerContextTask.
>>>>>>>> May be fix is not there. I made change on 24.04.2009
>>>>>>>> "
>>>>>>>> Author: oleksiys
>>>>>>>> Date: 2009-04-24 15:18:20+0000
>>>>>>>> New Revision: 3055
>>>>>>>>
>>>>>>>> Modified:
>>>>>>>> trunk/code/modules/grizzly/src/main/java/com/sun/grizzly/
>>>>>>>> ContextTask.java
>>>>>>>>
>>>>>>>> Log:
>>>>>>>> fix NPE
>>>>>>>>
>>>>>>>> https://grizzly.dev.java.net/source/browse/grizzly/trunk/code/modules/grizzly/src/main/java/com/sun/grizzly/ContextTask.java?view=diff&rev=3055&p1=trunk/code/modules/grizzly/src/main/java/com/sun/grizzly/ContextTask.java&p2=trunk/code/modules/grizzly/src/main/java/com/sun/grizzly/ContextTask.java&r1=3054&r2=3055
>>>>>>>> <https://grizzly.dev.java.net/source/browse/grizzly/trunk/code/modules/grizzly/src/main/java/com/sun/grizzly/ContextTask.java?view=diff&rev=3055&p1=trunk/code/modules/grizzly/src/main/java/com/sun/grizzly/ContextTask.java&p2=trunk/code/modules/grizzly/src/main/java/com/sun/grizzly/ContextTask.java&r1=3054&r2=3055
>>>>>>>> >
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> CallbacHandlerContextTask is executed in a separate thread
>>>>>>>>> in principle.
>>>>>>>>> So I think SelectionKeyContextTask.call method must be
>>>>>>>>> thread safe
>>>>>>>>> (synchronized method). I modified the source code of Grizzly
>>>>>>>>> and tested it,
>>>>>>>>> then, NullPointerException did not occur.
>>>>>>>>>
>>>>>>>>> Does this make sense?
>>>>>>>> Yes, though we need to avoid synchronized, where it's
>>>>>>>> possible. The problem I've fixed is that we returned Context
>>>>>>>> to pool and only then recycled it. That's why, I expect, NPE
>>>>>>>> was thrown.
>>>>>>>>
>>>>>>>> Thank you.
>>>>>>>>
>>>>>>>> WBR,
>>>>>>>> Alexey.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Minoru
>>>>>>>>>
>>>>>>>>>> Hi Minoru,
>>>>>>>>>>
>>>>>>>>>> can you pls. try the latest 1.9.15 built from sources
>>>>>>>>>> (cause I'm not
>>>>>>>>>> sure when snapshot will become available on maven)
>>>>>>>>>>
>>>>>>>>>> WBR,
>>>>>>>>>> Alexey.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>>>>>>>> <mailto:dev-unsubscribe_at_grizzly.dev.java.net>
>>>>>>>>> For additional commands, e-mail: dev-
>>>>>>>>> help_at_grizzly.dev.java.net <mailto:dev-help_at_grizzly.dev.java.net
>>>>>>>>> >
>>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net <mailto:dev-unsubscribe_at_grizzly.dev.java.net
>>>>>>> >
>>>>>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>>>>>> <mailto:dev-help_at_grizzly.dev.java.net>
>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>