I'm able now to send data back from the client, but I don't know how to keep
the information about the client.
The connection with the client will stay open until the client quit. The
client will be able to send more that one message.
I try to put that code in the protocolFilter to retreive the current client,
but I'm not using the right key into the hasmap, so each time the client
send a new request.. a new ClientConnectionHandler is created.. that's
really bad. So I try to check if there is alreay a ClientConnectionHandler
created for this client.
here the code
ClientConnectionHandler clientConnectionHandler = null;
if(manager.selectionKeyMap.containsKey(context.getSelectionKey())){
clientConnectionHandler =
manager.selectionKeyMap.get(context.getSelectionKey());
} else {
clientConnectionHandler = new ClientConnectionHandler(manager,
context.getSelectionKey(), context.getSelectorHandler());
}
2008/7/11 Jeanfrancois Arcand <Jeanfrancois.Arcand_at_sun.com>:
> Salut,
>
> Survivant 00 wrote:
>
>> if I want to force the client connection to close in my Thread. I should
>> use this
>>
>> selectorHandler.closeChannel(key.channel());
>>
>
> Yes, or selectorHandler.getSelectionKeyHandler().cancel(..);
>
> A+
>
> -- jeanfrancois
>
>
>
>> ?
>>
>>
>>
>>
>> 2008/7/11 Oleksiy Stashok <Oleksiy.Stashok_at_sun.com <mailto:
>> Oleksiy.Stashok_at_sun.com>>:
>>
>> ByteBuffer.allocateDirect(query.length());
>>>
>>> was for debug only... but like you know a better way.. can you
>>> share it please :)
>>>
>> Common idea is to reuse rather than allocate new :)
>> So, if in your case it's possible to associate ByteBuffer with
>> a threadQuote and always reuse it - it could be much better. But
>> sure it depends on usecase.
>>
>> Thanks.
>>
>> WBR,
>> Alexey.
>>
>>
>>>
>>>
>>>
>>>
>>> 2008/7/11 Oleksiy Stashok <Oleksiy.Stashok_at_sun.com
>>> <mailto:Oleksiy.Stashok_at_sun.com>>:
>>>
>>>
>>> Yep, it's exactly what I meant.
>>>
>>> ByteBuffer writeBuffer =
>>>> ByteBuffer.allocateDirect(query.length());
>>>> writeBuffer.put(query.getBytes());
>>>> writeBuffer.flip();
>>>>
>>>
>>> Be careful with ByteBuffer allocation. May be it makes sense
>>> to use some kind of ByteBuffer pool here? But it's on you :)
>>>
>>> Thanks.
>>>
>>> WBR,
>>> Alexey.
>>>
>>> On Jul 11, 2008, at 16:16 , Survivant 00 wrote:
>>>
>>> cool. so just to be sure.. can you validate this part of
>>>> code (it's working, but want to be sure that it will not
>>>> explode later)
>>>>
>>>>
>>>> instead of using the context like :
>>>>
>>>> context.getAsyncQueueWritable().writeToAsyncQueue(writeBuffer,
>>>> null, null, true);
>>>>
>>>>
>>>> I replace that by passing to a Thread the SelectorHandler and
>>>> the SelectionKey.. and when the thread will had finish
>>>> processing the query it will send back the response to the
>>>> client.
>>>>
>>>>
>>>> IN MY ProtocolFilter.
>>>>
>>>> ....
>>>> ByteBuffer writeBuffer =
>>>> ByteBuffer.allocateDirect(query.length());
>>>> writeBuffer.put(query.getBytes());
>>>> writeBuffer.flip();
>>>> SelectionKey key = context.getSelectionKey();
>>>> SelectorHandler selectorHandler = context.getSelectorHandler();
>>>>
>>>>
>>>> threadQuote.process(selectorHandler, key, writeBuffer);
>>>>
>>>>
>>>> in the process(...){
>>>>
>>>> we are waiting for the process to complet... and when it's
>>>> done we do that ;
>>>>
>>>> sendBacktoClient(selectorHandler, key, writeBuffer );
>>>>
>>>> return true;
>>>> }
>>>>
>>>> private void sendBacktoClient(SelectorHandler
>>>> selectorHandler,SelectionKey key, ByteBuffer buffer){
>>>>
>>>> try {
>>>>
>>>> selectorHandler.getAsyncQueueWriter().write(key,writeBuffer);
>>>>
>>>> } catch (IOException ex) {
>>>> throw ex;
>>>> }
>>>>
>>>>
>>>> so like that.. it's completly safe ? and is it a good way ?
>>>>
>>>>
>>>> 2008/7/11 Oleksiy Stashok <Oleksiy.Stashok_at_sun.com
>>>> <mailto:Oleksiy.Stashok_at_sun.com>>:
>>>>
>>>> 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,
>>>> ...);
>>>>
>>>> WBR,
>>>> Alexey.
>>>>
>>>> I need to be able to keep a reference on the client that
>>>>> sended the message that I parse in the previous filter.
>>>>>
>>>>>
>>>>> before I was keeping the SocketChannel.. and when I
>>>>> receive a response, I can send it back to the client
>>>>> using socketChannel.write(...)
>>>>>
>>>>> but now I don't have that.. and if the context is
>>>>> recycle, I need to find a way how to send the info back
>>>>> to the clients.
>>>>>
>>>>>
>>>>> 2008/7/11 Oleksiy Stashok <Oleksiy.Stashok_at_sun.com
>>>>> <mailto:Oleksiy.Stashok_at_sun.com>>:
>>>>>
>>>>> Hi,
>>>>>
>>>>> basically, you're right the new API proposed by John
>>>>> in not available yet.
>>>>> But if you need Context just to get AsyncWriteQueue
>>>>> - you can use following:
>>>>> selectorHandler.getAsyncQueueWriter().write(...)
>>>>> this will be safe.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> WBR,
>>>>> Alexey.
>>>>>
>>>>> On Jul 11, 2008, at 13:57 , Survivant 00 wrote:
>>>>>
>>>>> the thread :Asynchronous Request Processing with
>>>>>> TCPIP look my current problem it's really interessting.
>>>>>>
>>>>>> I look into the Thread you give me, but look like
>>>>>> it's not totally ready right ?
>>>>>>
>>>>>> I have no problem to use the new API, but where to
>>>>>> start from ?
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2008/7/10 Jeanfrancois Arcand
>>>>>> <Jeanfrancois.Arcand_at_sun.com
>>>>>> <mailto:Jeanfrancois.Arcand_at_sun.com>>:
>>>>>>
>>>>>> Salut,
>>>>>>
>>>>>>
>>>>>> Survivant 00 wrote:
>>>>>>
>>>>>>
>>>>>> Suppose that in a ProtocolFilter in the
>>>>>> execute method a create a Thread and pass
>>>>>> the context to that Thread for further
>>>>>> processing.
>>>>>>
>>>>>> the context will still be valid when the
>>>>>> program will exit the execute method ? (or
>>>>>> do I have to wait until the processing is
>>>>>> done ? )
>>>>>>
>>>>>>
>>>>>> No you cannot do that because the Context get
>>>>>> recycled when the ProtocolChain complete its
>>>>>> execution.....unless your use the new API we
>>>>>> added this week, or John's proposal. See:
>>>>>>
>>>>>>
>>>>>> https://grizzly.dev.java.net/issues/show_bug.cgi?id=186
>>>>>>
>>>>>> http://www.nabble.com/Re%3A-Asynchronous-Request-Processing-with-TCPIP-td18391541.html
>>>>>>
>>>>>> http://www.nabble.com/Re%3A-WG%3A--Re%3A-WG%3A--Re%3A-Fwd%3A-WG%3A--Re%3A-WG%3A--Re%3A-WG%3A--Re%3A-WG%3A--Re%3A-Asynchronous-Request-Processing-with-TCPIP-td18360066.html
>>>>>>
>>>>>> A+
>>>>>>
>>>>>> -- jeanfrancois
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail:
>>>>>> users-unsubscribe_at_grizzly.dev.java.net
>>>>>> <mailto:users-unsubscribe_at_grizzly.dev.java.net>
>>>>>> For additional commands, e-mail:
>>>>>> users-help_at_grizzly.dev.java.net
>>>>>> <mailto:users-help_at_grizzly.dev.java.net>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>
>