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>:
> 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>:
>> 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>:
>>> 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
>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>
>>>
>>
>>
>
>