Hi Yi,
>
>>
>> So once ConnectorHandler is connected - you can start to use async.
>> read/write queues, don't wait for CallbackHandler.onRead/Write
>> notification calls. But for sure it's possible to combine that as you
>> do.
>> -------------------------------------------
>> It's the truth.
>> After I revise the size of the readBuffer from 10240 to 1024, the
>> async. read/write operations work as expected. So, what the general
>> async. buffer rules? I think I could investigate AsyncReadCondition.
>> Any suggestion?
>
> One note with AsyncQueueReader: when data comes to the client
> channel, framework checks if there is ByteBuffer in AsyncReaderQueue
> waiting for incoming data, if not - CallbackHandler.onRead() will be
> called. So, if you want to use just AsyncReaderQueue - you have to
> be always sure, that there is ByteBuffer in queue waiting for
> incoming data :)
> I experienced blocking when using
> AsyncQueueReader.readFromAsyncQueue(). If we don't know exact size
> of the data to read, is there a way to know how much data is
> available? so that a suitable ByteBuffer could be allocated.
AFAIK not :(
As I told before Async read queue could be useful just for specific
scenarious, probably in your case it makes sense to not use it.
Thanks.
WBR,
Alexey.
>
> Thanks!
>
>
> IMHO, for your scenario it makes sense to use combined method:
> CallbackHandler to process client incoming data (implement
> CallbackHandler.onRead()), and use AsyncWriteQueue to send data to
> the server (don't put any logic to the CallbackHandler.onWrite()).
>
> If you will have any question on that - just let me know :)
>
>>
>> Another, it seems TcpSelectorHandler(true) is the same as
>> TcpSelectorHandler() in this client example.
> Not sure it's the same. Depending on that TCPSelectorHandler will
> pass different initialization steps.
>
> Thanks.
>
> WBR,
> Alexey.
>