users@grizzly.java.net

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

From: Survivant 00 <survivant00_at_gmail.com>
Date: Tue, 15 Jul 2008 08:52:12 -0400

euh, sorry it was the only way that I found a sample. That why I asked the
questions.. maybe the problem is there, but like I didn't know other way..



2008/7/15 Oleksiy Stashok <Oleksiy.Stashok_at_sun.com>:

> 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
>>>
>>>
>>
>>
>
>