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