Isn't there any workaround to this situation? In my application, a database update operation depends on whether the message was delivered to the client or not, so in that scenario, I would never know if the message was delivered. And even if onError() is called later, I can never know which message caused IOException.
On Thu, May 12, 2016 at 1:09 PM, Mark Thomas <ma...@apache.org> wrote: > On 12/05/2016 08:24, Tejas Nandanikar wrote: >> Thank you for your quick reply. >> So consider a case where client abruptly loses internet connection. >> In that scenario, the sendText() would return normally as the server >> hasn't received 'close' packet from the client, did I get it right? > > Assuming that the message was small enough to fit completely into the > network buffers, yes. > > Mark > >> >> On Thu, May 12, 2016 at 12:43 PM, Mark Thomas <ma...@apache.org> wrote: >>> On 12/05/2016 06:16, Tejas Nandanikar wrote: >>>> I am using Apache Tomcat 8.0.33. >>>> I was going through Java documentation about RemoteEndpoint.Basic >>>> which says that sendText(String text) blocks until all of the message >>>> has been transmitted. >>>> But I noticed that when the client loses internet connection and >>>> sendText() method is called on the server side, it doesn't thrown an >>>> IOException immediately and the method returns normally. >>>> IOException is thrown later and the onError() method is called. Is >>>> this a normal behaviour? >>> >>> Yes. >>> >>>> Shouldn't the sendText() method block until >>>> all the message has been transmitted successfully or throw an >>>> IOException immediately if there's any problem? >>> >>> Only if the server knows there is a problem at that point. Depending on >>> how the client disconnects, there server might not know and the message >>> will sit in the network buffer until the network stack figures out that >>> the client has gone away. >>> >>> Mark >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: users-h...@tomcat.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
