users@grizzly.java.net

Re: Grizzly TCP Server: how to async call inside a filter

From: Raffaele Marcello <marcelloraffaele_at_gmail.com>
Date: Wed, 23 Oct 2013 13:13:40 +0200

Thank you, i appreciate a lot your help!
Unfortunately i cannot share my code but i can show you an example (you can
see attached files). In reality i was inspired by BIOPFilter from official
examples.

In my protocol can happen that some ritrasmitted messages arrive while the
server is waiting for a response.
I would like to listen arriving messages (read) even if i'm waiting for
responses. As you can see, i used two filter, when MyCallerFilter is
executing the request to remote services, MyProtocolFilter is unable to
read from input stream.
Maybe i can do it using async call on service (maybe using a thread) or
using async call from MyProtocolFilter to MyCallerFilter.
Unfortunately i didn't understand how to use "*asyncMessageProcessor*",
which class it is? Are there some examples that show how to use it?
Is there the chance to create a task and ask Grizzly exec it async?
Any other suggestion?

Thanks
R




2013/10/22 Oleksiy Stashok <oleksiy.stashok_at_oracle.com>

> Hi,
>
>
>
> On 22.10.13 07:10, Raffaele Marcello wrote:
>
>> Hi,
>> i developed a TCP Server using Grizzly using two Filters:
>> - MyProtocolFilter to manage the protocol( messages recognition )
>> - MyCallerFilter to invoke a remote server (using RMI) and manage the
>> answer.
>>
>> Unfortunately now it works using only one thread per connection. I'm
>> having problems because sometimes some message can arrive while i'm waiting
>> for the remote method invocation. In that case the new message is queued in
>> input buffer and it can cause retransmissions.
>> I want to ask if is possible to asynchronous invoke remote methods
>> managing the results(Maybe using another thread). In this way i could
>> manage new arriving messages while i'm waiting responses.
>>
> Sure, it's possible. As I understand your protocol doesn't require
> responses to come in the same order as requests?
> The easiest thing you can do in MyCallerFilter is:
>
> public NextAction handleRead(FilterChainContext ctx) throws Exception {
> asyncMessageProcessor.doAsync(**ctx.getMessage(),
> ctx.getConnection()); // pass the message and the connection, so async
> processor knows to whom it has to send the response
> return ctx.getStopAction();
> }
>
> If you can share your code - I'll be able to provide more details.
>
>
> Does anyone have a solution in order to maintain good performance? Can i
>> use some Grizzly configuration or specific class?
>>
> Sure, you can tune I/O strategies, buffer sizes, etc, but first it will be
> good to have something working :)))
>
> Thanks.
>
> WBR,
> Alexey.
>
>
>>
>> Thanks
>> R
>>
>
>


-- 
RM