Hi,
>
> As a further question - how (if at all) is the read ordered with
> respect to
> writes - Do I have to serialise the two operations for the calling
> code to
> ensure I get the correct response? - or is there some other mechanism
> (identifiers etc) I can use?
Actually, if you'll register for async. read from within async write's
CompletionHandler - you'll place it correctly.
But as I told with Async read queue, there is no mechanism how we can
process chunked data :(
So I'll suggest you to use FilterChains for this.
Thanks.
WBR,
Alexey.
>
>
> steve
>
>
> steview wrote:
>>
>> Hi,
>> I am further along and the sending side makes sense. However, the
>> read
>> part of the docs are a bit unclear.
>>
>> Say I have code that looks a bit like this - I want to write a
>> buffer and
>> return the response back to the client (sort of half-synch/half/async
>> pattern) - so the client sees a synchronous interface and and I use
>> the
>> async mechanism underneath.
>> I was thinking something along the lines of:
>>
>> public Future<ReadResult<Buffer, SocketAddress>> send(Connection
>> connection, Buffer buffer){
>> Future<WriteResult<Buffer, SocketAddress>> writeFuture =
>> asyncQueueWriter.write(connection, buffer,
>> new CompletionHandlerAdapter<WriteResult<Buffer,SocketAddress>>(){
>> @Override
>> public void failed(Connection connection, Throwable throwable) {
>> try {
>> setupConnection(address);
>> } catch (Throwable t){
>> logger.warn("connection write failed - attempting
>> reconnection", t);
>> }
>> }
>> });
>> writeFuture.get() // do I need this here?
>> return asyncQueueReader.read(connection);
>> }
>>
>> However, I have a few further questions.
>> 1) I am unsure as to whether I have to wait for the future returned
>> from
>> the write method to complete before calling the read method.
>> 2) If I supply no buffer to the read method does Grizzly manage
>> this for
>> me. (I seem to get nullpointer in current 2.0 code doing this)
>> 3) what role does the callbackhandler play in relation to the future
>> returned from read- if I register for the handler does the complete
>> callback happen before the future return - and can I read the
>> response
>> from there.
>> 4) is the use of the future and the callbackhandler mutually
>> exclusive or
>> cooperative.
>>
>>
>>
>> Oleksiy Stashok wrote:
>>>
>>>> Ok - that makes more sense. So I assume that the transport can
>>>> support many
>>>> connections to different endpoints and I can use the async writer
>>>> to
>>>> dispatch to all these connections?
>>> Absolutely.
>>> Transport describes the nature of networking layer (like TCP, UDP),
>>> and Connection is a represents unit (like socket).
>>>
>>> WBR,
>>> Alexey.
>>>>
>>>>
>>>> steve
>>>>
>>>>
>>>>
>>>>
>>>> Oleksiy Stashok wrote:
>>>>>
>>>>> Hi Steve,
>>>>>
>>>>>> I am pretty new to Grizzly and I am exploring the use of 2.0 as a
>>>>>> client
>>>>>> side library.
>>>>>>
>>>>>> However, I am slightly confused as to how the 2.0 API functions.
>>>>>>
>>>>>> Is the connection supposed to be for use by a single thread
>>>>>> only? -
>>>>>> The
>>>>>> reason I ask this is the streamwriter that is used to send data
>>>>>> has
>>>>>> write(Buffer) - which seems ok - but the
>>>>>> flush(CompletionHandler) is
>>>>>> not
>>>>>> part of this call - so if I have multiple threads using the same
>>>>>> connection
>>>>>> how do I ensure that the order of write/flush is not interleaved
>>>>>> unless I am
>>>>>> synchronizing these calls myself.
>>>>> Actually StreamReader and StreamWriter are not thread safe, so I
>>>>> would
>>>>> not suggest to use the simult. from several threads.
>>>>> Instead of that I'd recommend you to use lower level
>>>>> AsyncWriteQueue
>>>>> API, which is thread-safe.
>>>>>
>>>>> Here is example:
>>>>> TCPNIOTransport transport = .....;
>>>>> Connection connection = .....;
>>>>> final MemoryManager mm = transport.getMemoryManager();
>>>>> final Writer asyncQueueWriter =
>>>>> transport.getAsyncQueueIO().getWriter();
>>>>>
>>>>> Buffer buffer = MemoryUtils.wrap(mm, "Hello World");
>>>>> try {
>>>>> asyncQueueWriter.write(connection, buffer);
>>>>> } catch (IOException e) {}
>>>>>
>>>>>
>>>>> asyncQueueWriter in this example is thread safe, and you can use
>>>>> it
>>>>> simult. from different threads.
>>>>>
>>>>>> Also, what would be the best approach to use as a reconnection
>>>>>> strategy (the
>>>>>> transport has an exception handler - but the connection does
>>>>>> not) -
>>>>>> especially around ability not to lose queued data on a connection
>>>>>> that may
>>>>>> no longer be active - e.g would I have to drain the queue and
>>>>>> reconnect and
>>>>>> resubmit manually.
>>>>> If you use AsyncWriteQueue - it is possible to set
>>>>> CompletionHandler
>>>>> there for each Buffer that you send. If error happens - framework
>>>>> will
>>>>> call CompletionHandler.failed(...) for each Buffer, so you'll be
>>>>> able
>>>>> to resend those data again.
>>>>>
>>>>> asyncQueueWriter.write(connection, buffer, new
>>>>> CompletionHandlerAdapter() {
>>>>> @Override
>>>>> public void failed(Connection connection, Throwable
>>>>> throwable) {
>>>>> resendFailedBuffer(connection, buffer);
>>>>> }
>>>>> });
>>>>>
>>>>> If you have any question - please let me know.
>>>>>
>>>>> WBR,
>>>>> Alexey.
>>>>>
>>>>>>
>>>>>>
>>>>>> Regards
>>>>>> Steve
>>>>>>
>>>>>>
>>>>>> --
>>>>>> View this message in context:
>>>>>> http://www.nabble.com/Grizzly-2.0-as-a-client-connection-provider-tp22680820p22680820.html
>>>>>> Sent from the Grizzly - Users mailing list archive at Nabble.com.
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>>>>> For additional commands, e-mail: 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
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/Grizzly-2.0-as-a-client-connection-provider-tp22680820p22689886.html
>>>> Sent from the Grizzly - Users mailing list archive at Nabble.com.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>>> For additional commands, e-mail: 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
>>>
>>>
>>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Grizzly-2.0-as-a-client-connection-provider-tp22680820p22756035.html
> Sent from the Grizzly - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>