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