Hi Mark,
> Thanks Alexey, that makes sense now, for some reason I forgot about
> the synchronizing.
oh, it happens with everyone :)
> I suppose then it is safe to say that all that assigning a new
> instance of the Adapter to each processor thread will just increase
> the memory footprint?
In Grizzly Adapter case (as they are stateless by default) - yes.
Thanks.
WBR,
Alexey.
>
>
> Mark
>
> On Fri, Jul 18, 2008 at 9:52 PM, Oleksiy Stashok <Oleksiy.Stashok_at_sun.com
> > wrote:
>>
> 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
>>>
>>>
>>
>>
>
>