Hi Simon,
Simon Trudeau wrote:
> Here’s the context to my question:
>
>
>
> I have a client communicating with hundreds of third party server
> concurrently. I want to write to the servers and process each responses
> received.
>
>
>
> Upon receiving the bytes from the server,
>
>
>
> - I need to parse the bytes into messages (protocol parsing)
>
> - Process the parsed message according to the state into which my
> protocol is in. (stateful processing)
>
> - Reply to the server’s request (negotiation of credentials) or
>
> - Send a request of my own to the server.
>
>
>
> Were I to write a server side application, I would write a filter chain
> (readFilter, myProtocolParser, myBusinessLogicActions) for the
> selectorHandler and I would be done! On the other hand, on the client
> side, looks to me like I’m stuck with the CallbackHandler to handle all
> of this! Doesn’t it break the separation of concern principle by having
> a CallbackHandler do too many things?
You can always call the ProtocolChain from the CallbackHandler (this is
what I did for the SIP protocol implementation). What you do is:
ctx.getProtocolChain().execute(ctx);
As an example, for SIP, we do:
> public void onRead(IOEvent<Context> ioEvent) {
> try {
> Context ctx = ioEvent.attachment();
> ctx.setAttribute(IS_CLIENT_EXECUTION, true);
> SelectionKey key = ctx.getSelectionKey();
> if (!key.isValid()) {
> connectionManager.streams.remove(targetTuple);
> return;
> }
>
> ctx.setAttribute("tt", targetTuple);
>
> // disable OP_READ on key before doing anything else
> key.interestOps(key.interestOps() & (~SelectionKey.OP_READ));
> ctx.getProtocolChain().execute(ioEvent.attachment());
> } catch (Throwable e) {
> if (logger.logSevere()) {
> logger.severe(e, "sip.stack.network.connection_read_failed", "tcp");
> }
> }
> }
>
>
>
> How about a FilterChain on the client side for each connection
> established? This way I could make use (reuse) of interfaces such as
> ProtocolParser.
Yup this is what you should do :-)
>
>
>
> I thought of applying a filter chain to a selectorHandler on the client
> side, but, correct me if I’m wrong, I guess this chain would apply to
> all my concurrent client connections instead of being one filterChain
> per connection.
You can have one FilterChain per connection if you use a statefull
ProtocolChainInstanceHandler (see my previous emails).
>
>
>
>
>
> Any thoughts or suggestion so I can come up with nice clients
> implemented according to what you had in mind for client side grizzly
> applications?
So far, your design looks good. But keep the questions coming, as they
will help me writing my next blog :-)
Thanks!!!!
-- Jeanfrancois
>
>
>
>
>
> Thanks,
>
>
>
>
>
> Simon
>
>
>