users@grizzly.java.net

Re: Should I use Context to store the clients references ?

From: Oleksiy Stashok <Oleksiy.Stashok_at_Sun.COM>
Date: Tue, 15 Jul 2008 14:42:02 +0200

> I'll explain my needs from the start.
>
> it's for a stock quote simulator.
>
> when a client connect to the server, it will send requests.
>
> like that
>
> client 1 -> - want the feed for the symbol | aaa
> - want the feed for the symbol | bbb
>
> client 2 -> - want the feed for the symbol | aaa
>
>
> In the server using grizzly :
>
> I have 2 filters in the chains.
>
> - the first for parsing the messages
> - the second for processing the message
>
> I need to keep a reference for all the clients and know which feed
> they register to.
>
> When I process to message, I'll receive the response from a 3th
> party later, and I 'll receive it on a callback method, and I'll
> send back the response to the client register as soon as the
> response arrive.
>
>
> The main problem that I had was that in the second filter, I need to
> know if the client already ask for a feed and I need to know how to
> send it back to data. That why I wanted to use a
> ClientConnectionHandler ( before using grizzly, I created the
> cleintconnectionhandler just after the socketserver.accept() ) to
> keep the selectionKey and the channel to send the data back.
>
>
> if I loop into your sample.. it will create a pool each time the
> client send a message.
Why? You're using stateful ProtocolChain? In other words you have
protocol chain, associated with each client connection?

WBR,
Alexey.

>
>
>
>
> 2008/7/15 Oleksiy Stashok <Oleksiy.Stashok_at_sun.com>:
> Hi,
>
> your implementation is ok.
> Though if having the map of all client connections is not must -
> then you can create ClientConnectionHandler pool like inline...
>
>> public class QuoteQueryManagerFilter implements ProtocolFilter {
>>
> ConcurrentLinkedQueue<ClientConnectionHandler> pool = new
> ConcurrentLinkedQueue<ClientConnectionHandler>();
>> private QuoteManager manager;
>>
>> public QuoteQueryManagerFilter(QuoteManager manager) {
>> this.manager = manager;
>> }
>>
>> public boolean execute(Context context) throws IOException {
>> String query = (String)
>> context.removeAttribute(ProtocolParser.MESSAGE);
>>
>> if(query==null || query.trim().length()==0){
>> return false;
>> }
>>
>> System.out.println("query = " + query);
>>
>> //here should be the parsed query command string with
>> // which query should be able to create a command
>> // I have no time to rewrite ClientConnectionHandler
>> // Basically you have in context a link to client connection
>> //with that and for example TCPSelectorHandler your
>> commands can
>> //send data to client
>>
>> /*
>> * For now instead of keeping whole Context, you can just
>> keep SelectionKey as reference to the client,
>> * and send response back using:
>> selectorHandler.getAsyncQueueWriter().write(SelectionKey, ...);
>> */
>>
>> // on va chercher le ClientConnectionHandler si il existe
>>
> ClientConnectionHandler clientConnectionHandler =
> pool.poll();
> if (clientConnectionHandler != null) {
> clientConnectionHandler.init(manager,
> context.getSelectionKey(), context.getSelectorHandler());
> } else {
> clientConnectionHandler = new
> ClientConnectionHandler(manager, context.getSelectionKey(),
> context.getSelectorHandler());
> }
>
>> // ClientConnectionHandler clientConnectionHandler = null;
>>
>> //
>> if(manager.selectionKeyMap.containsKey(context.getSelectionKey())){
>> // clientConnectionHandler =
>> manager.selectionKeyMap.get(context.getSelectionKey());
>> // } else {
>> // clientConnectionHandler = new
>> ClientConnectionHandler(manager, context.getSelectionKey(),
>> context.getSelectorHandler());
>> // }
>>
>> manager.processQuery(clientConnectionHandler, query);
>>
>>
>
> and then return ClientConnectionHandler to the pool from processing
> thread.
> In example above single ClientConnectionHandler could be associated
> with different client connections, but not at the same time.
>
> If you need to associate ClientConnectionHandler with just one
> client connection during its life-cycle - may be it makes sense to
> use ThreadAttachment's attributes.
> Let me know if this is required.
>
> Thanks.
>
> WBR,
> Alexey.
>
>
>>
>> 2008/7/15 Oleksiy Stashok <Oleksiy.Stashok_at_sun.com>:
>> Hi,
>>
>>
>> I have a chain of 2 filters.
>>
>> #1 - parsing the request
>> #2 - processing the request
>>
>> and loop until the client quit.
>>
>> I want to kept the info about the connection like :
>> context.getSelectionKey(), context.getSelectorHandler() in a
>> Object like :
>>
>> ClientTracker(SelectionKey key, SelectorHandler selectorHandler)
>>
>> and I'll send data back to the client using the key and the
>> selectorhandler.
>>
>> but I don't know where to create that class (ClientTracker) and
>> where to put it to use it later.
>>
>> if I create the ClientTracker into the 2 filters.. a new reference
>> will be created each time the client send a request.. it's not what
>> I want.
>>
>> I tought of putting the ClientTracker in the context and check if
>> the class exist in the context.. but like the context could be
>> invalidate, I could lose the info..
>>
>> Normally, I would have created the ClientTracker equivalent class,
>> after the socketserver.accept();
>>
>> Do you want to store somewhere complete map of clients
>> (ClientTracker), which are currently connected?
>> Also, can you pls. provide more details how you want to use
>> ClientTracker class? Some code snippets...
>>
>> Thank you.
>>
>> WBR,
>> Alexey.
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>
>>
>
>