Architecture design question behind Adapters, SelectorThreads and DefaultProcessorTasks

[Kram]

Hey Everyone,

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...

Cheers,
Mark

[Oleksiy Stashok]

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.

> 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?

Thanks.

WBR,
Alexey.

>
>
> Cheers,
> Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jeanfrancois Arcand-2]

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@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Kram]

Hello Everyone,

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?

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@...> 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@...
For additional commands, e-mail: dev-help@...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Oleksiy Stashok]

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@...> 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@...
For additional commands, e-mail: dev-help@...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Kram]

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@...> 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@...> 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@...
For additional commands, e-mail: dev-help@...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Oleksiy Stashok]

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@...> 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@...> 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@...
For additional commands, e-mail: dev-help@...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Kram]

Thanks Alexey, that makes sense now, for some reason I forgot about the synchronizing.

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?

Mark

On Fri, Jul 18, 2008 at 9:52 PM, Oleksiy Stashok <Oleksiy.Stashok@...> 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@...> 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@...> 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@...
For additional commands, e-mail: dev-help@...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Oleksiy Stashok]

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@...> 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@...> 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@...> 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@...
For additional commands, e-mail: dev-help@...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...