>
Hi,
> Thanks for the tip, however, I do not quite understand how that
> would work. If I had 3 worker threads all with references to one
> adapter, and they all, at exactly the same time, want to call one of
> the the adapters methods, I would imagine that the single adapter
> instance would have to process one threads request at a time,
> essentially queuing the threads requests, correct?
Nope :)
It doesn't synchronize the callers. So all the threads can access
Adapter simult.
> However, if each worker thread had a different instance of the
> Adapter class, then even if they want to call methods of their own
> adapter objects, obviously, the adapter would simply only have one
> threads request to deal with...
That's true, but since Adapter doesn't have any internal state - you
don't need to have different Adapter instances... just one is enough.
Just imagine easy case.
public class SimpleAdapter {
public int add(int a, int b) { return a+b;}
}
If we share SimpleAdapter instance among several threads, which call
add(...) method.
Is there any sense to have SimpleAdapter per thread? Why not just use
one instance of SimpleAdapter? :)
Thanks.
WBR,
Alexey.
>
>
> Your thoughts?
>
> Cheers,
> Mark
>
> On Fri, Jul 18, 2008 at 7:03 PM, Oleksiy Stashok <Oleksiy.Stashok_at_sun.com
> > wrote:
> Hi,
>
>>
>> Thanks for the information, i understand that making the class
>> stateless would not generate multi-threading issues, but in my
>> situation, speed is of the essence and I was concerned that by
>> having many procesor threads that use the same Adapter instance
>> would produce a sort of bottleneck as one instance handles all the
>> request processing.
>>
>> Am I correct in saying this?
>
> If Adapter doesn't have any state associated - it's safe to reuse it
> simult. from different threads and there should not be any bottleneck.
> I would even say, that reusing single Adapter instance will perform
> better, than constructing Adapter for each connection.
>
> If you have any questions - please ask :)
>
> Thanks.
>
> WBR,
> Alexey.
>
>>
>>
>> I am pretty new to the whole threading, sockets, NIO, side of
>> things, and want to ensure that I undersand things correctly.
>>
>> I really appreciate the advice
>>
>> Mark
>>
>> On Fri, Jul 18, 2008 at 1:13 AM, Jeanfrancois Arcand <Jeanfrancois.Arcand_at_sun.com
>> > wrote:
>> Salut,
>>
>>
>> Oleksiy Stashok wrote:
>> Hello Mark,
>>
>> I think main decision was to make Adapter stateless, so it will not
>> have any internal state, so there should not be multi-threading
>> issues.
>>
>> Indeed. We already creates DefaultProcessorTask/Request/Response
>> which are statefull, the Adapter doesn't necessary needs to be
>> statefull as well....That makes a big difference under load.
>>
>>
>>
>> I was just wondering if someone could give me some incite behind
>> the decision to, when the selector thread calls
>> configureProcessorTask(DefaultProcessorTask task) it assigns the
>> task.setAdapter(adapter); method?
>>
>> This would mean that each DefaultProcessorTask has the same adapter
>> assigned to process requests... wouldn't this create multi-
>> threading issues when many different DefaultProcessorTask's try to
>> call their adapters service method?
>>
>> I may have the wrong impression here but wouldnt it be better if in
>> the configureProcessorTask method in the SelectorThread class sets
>> a new instance of an adapter onto the DefaultProcessorTask?
>>
>> task.setAdapter( new SampleAdapter() );
>>
>> instead of task.setAdapter(adapter);
>>
>> Ofcourse, if you wanted to copy the object instead of a new
>> instance, then you would need to implement Cloneable on the
>> adapter...
>> IMHO, clones it's always tricky... and place with possible issues.
>> Can you pls. describe your scenario? Why you may need to have
>> stateful Adapter?
>>
>> Right? Or better, if you have time, maybe you can send us a patch
>> that support stateless and statefull Adapter :-) :-) :-)
>>
>> Thanks!
>>
>> -- Jesnfrancois
>>
>>
>>
>>
>>
>> Thanks.
>>
>> WBR,
>> Alexey.
>>
>>
>>
>> Cheers,
>> Mark
>>
>>
>> ---------------------------------------------------------------------
>> 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
>>
>>
>
>