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-tp22680820p22755949.html
Sent from the Grizzly - Users mailing list archive at Nabble.com.