Hi Jeanfrancois,
Great! This is really helpful!
There are 3 different conversations that could happen between the client
and server. The connection is always open
There could be many of those 3 combinations during the life time of the
connection:
1. client ------> request -----> server (there's no response back from
server)
2. client ------> request -----> server
response <--------|
3. server ------> response -------> client (server just sends a message
to the client)
It is not a one to one relationship between request and response. They
are more like events (client events and server events).
Thanks,
Fay Zheng
-----Original Message-----
From: Jeanfrancois.Arcand_at_Sun.COM [mailto:Jeanfrancois.Arcand_at_Sun.COM]
Sent: Thursday, April 12, 2007 9:23 AM
To: Zheng, Fay
Subject: Re: How to handle events initiated from server in Grizzly?
Hi,
Zheng, Fay wrote:
> I am looking at Grizzly 1.5.
> Yes. Our server has its own protocols. So we will need our own
> implementation of StreamAlgorithm and WriteProtocolFilter.
If you are looking at 1.5 and you don't need http support, then all you
need is to look under grizzly/trunk/modules/grizzly. In that module,
StreamAlgorithm and all the concept defined in Grizzly 1.0 aren't there
(with the exception of the Pipeline concept). StreamAlgorithm, Task(s)
etc. only apply if you are building your server on top of
grizzly/trunck/modules/http.
>
> The client will keep the TCP connection open as long as it is running.
> Periodically the client may send one or more requests to the server
then
> it can be handled using the following flow:
>
> ReadTask --> ProcessTask --> process --> continue if there's any
> response
> -->WriterProtoclFilter --> write response
OK this looks very similar to what Comet processing is doing (with
HTTP).
>
> Currently our server uses a thread pool to broadcast some message
> periodically through the existing client connection to all the
clients.
> How can I fit those writeTasks in the Grizzly framework?
In order to do that with 1.5, you will need to write three
ProtocolFilter:
+ AsyncReadFilter (which extend com.sun.grizzly.filter.ReadFilter and
override the postExecute method and only return true (as you don't want
to neither cancel the SelectionKey nor register it back to Selector (if
I understand correctly).
+ ProcessorFilter (look if response are available) If yes, then invoke
the WriteFilter. If no, the either send an empty response or invoke the
next Filter which is ParkFilter (see below).
What you want to be able to do is:
client ------> request -----> server
response <--------| // If response are available
response <--------|
If no response, do you want to park the request or just send an empty
response? Say differently, do you want the client to always wait for a
response or can a client receive no response and send a request latter
on?
Do you mind if we continue the discussion on users_at_grizzly.dev.java.net
or you need to keep the dicussion private (I've no problem keeping it
private).
Thanks!
-- Jeanfrancois
>
> Thanks,
>
> Fay Zheng
> fzheng_at_ea.com
> 650.628.2738
>
> -----Original Message-----
> From: Jeanfrancois.Arcand_at_Sun.COM [mailto:Jeanfrancois.Arcand_at_Sun.COM]
> Sent: Wednesday, April 11, 2007 3:07 PM
> To: Zheng, Fay
> Subject: Re: How to handle events initiated from server in Grizzly?
>
> Hi Fay Zheng,
>
> Zheng, Fay wrote:
>> Hi Jean,
>
> In Quebec, we don't have middle name, which means my name is
> Jeanfrancois :-) :-)
>
>>
>>
>> We have an existing server application using blocking I/O and
>> thread-per-connection implementation. We want to add NIO layer (build
> on
>> top of Grizzly) to this app to improve capacity. Our existing app not
>> only handle requests from client connection (request-process-response
>> model), but we also have varies events sent to the client that are
>> initiated by the server. How should we handle those kinds of events
in
>
>> grizzly? Is there a way to plug-in a writerTask pipeline?
>
> If I understand correctly, your server is pushing data back to the
> client using its own protocol, right?
>
> Are you looking at Grizzly 1.0 or 1.5? For 1.5, you will need to add a
> WriterProtocolFilter. For 1.0, you are right a WriterTask will do the
> job. But can you elaborate (if that's not private) on what your are
> doing exactly? More information will help me understanding your
> implementation :-)
>
> BTW I'm in Brazil this week, giving talks on Grizzly :-) I may reply
> slowly...hopefully not!
>
> Thanks!
>
> -- Jeanfrancois
>
>
>
>>
>>
>> Thanks,
>>
>>
>>
>> Fay Zheng
>>
>> fzheng_at_ea.com <mailto:fzheng_at_ea.com>
>>
>> 650.628.2738
>>
>>
>>