>> 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?
GC could be issue, I agree, but IMHO currently it is optimized good,
and in many cases perform better, than thread-safe collections.
> 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.
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
>