Salut,
Minoru Nitta wrote:
> Salut Jeanfrancois, Alexey,
>
>
>
> Sorry for late reply. I udnerstand your idea and it will be useful.
> I am also interested in Jeanfrancois's idea (one Context per Thread),
> because garbage collection is one of the main factors that affect
> total performance. Do you have any plan to implement that?
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.
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
>