That looks like it would work. Let me try it out and I'll let you know.
Thanks!
Bo
On 08/25/2010 07:27 AM, Oleksiy Stashok wrote:
> Hi Bo,
>
> sorry for the delay.
> Please take a look at the sample [1].
> Hope it's what you're looking for.
>
> Thanks.
>
> WBR,
> Alexey.
>
> [1]
> https://grizzly.dev.java.net/source/browse/grizzly/branches/2dot0/code/samples/framework-samples/src/main/java/com/sun/grizzly/samples/reverse/ReverseEchoFilter.java?view=markup
>
>
> On Aug 23, 2010, at 23:44 , Bo Li wrote:
>
>> Hi Alexey
>>
>> Is there a supported way to implement something like the
>> leader-follower threading strategy but with decoding messages on the
>> same connection? What I mean is we would like to decode only one PDU
>> of the protocol with the Grizzly worker thread and continue
>> processing of the decoded PDU on the same thread while letting
>> another Grizzly worker thread decode additional PDUs (if any) in the
>> read buffer or process additional read events on the connection.
>>
>> We are interested in this because we want to separate PDU decoding
>> and processing without having to hand over the processing task to
>> another thread. It seems like the overhead of additional queuing and
>> invoking of the task in another thread pool causes a 13% degradation
>> in throughput.
>>
>> Thanks
>> Bo
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>