users@grizzly.java.net

Re: Grizzly 2.0 as a client connection provider

From: steview <steve-nabble_at_jofti.com>
Date: Tue, 24 Mar 2009 14:13:37 -0700 (PDT)

Hi Alexey,

Thanks for the reply.
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?

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.