Sorry,
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?
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.