Hi Alexey,
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?
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...
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
>>
>>
>
>