Salut,
> >> 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
That's great! Thank you for your implementation. I'll test my
program on 1.9.16.
Minoru
> 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
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net