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