Hi,
>
> This is with reference to the blog entry http://weblogs.java.net/blog/jfarcand/archive/2006/07/tricks_and_tips_4.html
> which elaborates a design of reading for bytes of a logical request
> packet in the context of a read thread pool with a temporary
> selector drawn from a pool of ready to use Selectors.
IMHO read with temporary selector is really good "trick and tip", but
not general solution for framework. It really improves performance in
case, when we sure new data will come very fast and we can avoid
expensive thread context switches.
> I have just downloaded and gone through the latest code release
> 1.9.14. For the server side, I find that reading is being done in
> the context of a thread pool but if I am not wrong, there is no
> longer any select(readTimeout) for this read.
Right. In ReadFilter we do just regular non-blocking read, because by
time ReadFilter is called we're sure the channel has some data ready,
so there is no need in temporary selector read.
> Rather, I think that if the bytes for one logical request has not
> been accumulated, the readPostProcessor accumulates the incomplete
> portion in memory and returns immediately unlike the design
> elaborated above.
Yes. As general solution this is more reliable. Cause temporary
selector read, potentially, can block the thread for some time, which
could be dangerous. Temporary selector reads, IMHO, should be used
just for cases, where you're sure it will not bring unexpected problems.
> I see that the above design is being used in the client side
> TCPConnectorHandler only, using InputReader, but not in the server
> side.
Correct, when you work with ConnectorHandler in blocking mode, you do
all I/O operations (read/write/close) in single thread, so we can
safely use temporary selector reads. So instead of:
Future f = connectorHandler.read(buffer, NON_BLOCKING); ///
<------- read asynchronously
f.get(...); /// Wait for result
we use just:
connectorHandler.read(buffer, BLOCKING); // <------ read in the
same thread
> Please correct me if I am wrong and point me to the right code.
> However, if my analysis is correct, I would be interested in knowing
> whether there has been any design change and the motivation behind it.
We still widely use temporary selector reads in http module for
reading and parsing http protocol, but as I told temporary selector
reads should be used carefully to avoid unexpected thread blocking.
Thank you.
WBR,
Alexey.
>
> Thanks and Regards,
> Archanaa Panda
>
> Important notice: This e-mail and any attachment there to contains
> corporate proprietary information. If you have received it by
> mistake, please notify us immediately by reply e-mail and delete
> this e-mail and its attachments from your system.
> Thank You.