<p>Hi. One way I deal with this is with an AtomicBoolean flag that knows if the task is being processed. If true, then I don't disconnect the channel.</p>
<p><blockquote type="cite">On 20 Aug 2010 19:44, "javadevmtl" <<a href="mailto:java.dev.mtl@gmail.com">java.dev.mtl@gmail.com</a>> wrote:<br><br><br>
I redid my stress test this time I added back the ReadTimeoutHandler but I'm<br>
no longer dynamically removing it from the pipeline like I was doing before.<br>
This time everything worked fine.<br>
<br>
It's just a matter of understanding how it works and how it can be used...<br>
My issue with the timer is the following or at least this is how I think it<br>
works...<br>
<br>
The moment the client connects the timer starts counting until "some"<br>
packets come in. Once a couple of packets come in the timer is reset and<br>
counts again. If I set the read timeout to say 3 seconds that means that<br>
there will be a ReadTimeoutException thrown every 3 seconds. Sometimes my<br>
business logic takes longer then 3 seconds to execute since it connects to<br>
DB and other 3rd parties. So if it takes longer then 3 seconds I don't want<br>
to timeout the client. Currently on ReadTimeOutException I close the socket.<br>
<br>
So I figure what I can do is just set a higher read time out value like say<br>
10 seconds and I'm ok. Like this I can also handle clients that potentially<br>
don't send the "right" protocol/message to the server and I can clean them<br>
up.<br>
<font color="#888888">--<br>
View this message in context: <a href="http://netty-forums-and-mailing-lists.685743.n2.nabble.com/Read-timeout-errors-in-infinite-loop-tp5440336p5444648.html" target="_blank">http://netty-forums-and-mailing-lists.685743.n2.nabble.com/Read-timeout-errors-in-infinite-loop-tp5440336p5444648.html</a><br>
</font><p><font color="#500050">Sent from the Netty User Group mailing list archive at Nabble.com.<br>_________________________________...</font></p></blockquote></p>