Re: RemoteEndpoint.Async sendText blocking
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 6/29/17 5:22 PM, Caldarale, Charles R wrote: >> From: Christopher Schultz [mailto:ch...@christopherschultz.net] >> Subject: Re: RemoteEndpoint.Async sendText blocking > >> When the BIO connector is in use, you end up with weird things >> like this. I would switch to BIO if you want to use async. > > Might want to rephrase that... Presumably Chris meant "switch to > NIO". In fact, I did intend to say NIO. :) > Note that the BIO connector is removed (yay!) in Tomcat 8.5 and > above. Yes, and I think most of the bugs have also finally been worked out. (*ducks*) - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJZVkPUAAoJEBzwKT+lPKRYlR4QAIV46xvoOPW9WgjaZxM95upC Kx6gRwUz9Bmc+8R4yhrMbpX2G48s2TjjYnJSX3IDfao6AjWQNMFIexwydh3L3hka 2iO+DX7TP8J02rZbytrqJ+upGtS+6NEvsBQeAMCLOC5HsKXLVJxOWKQJiTQO7Qg4 YKxI+GpINsVsUM4Ei9HGlQiTSDEN320Sr6RnEoDQstZvZHGH+FxOasJnm748epdI jNBFpCrtdw0cksTdkt7oyDHySMoD4NIGbbEaHm0My3eHVLGTtHmGHFYVP9lvlaWG u73dYqXyqYaqCExvUFuW3m7TsTaKGGul2U8cqMSiBSewTbJ67G3OVMNgJrRq04Hc RImCHEjuEdXP63H4xHeowv8AoAxn+LW2HXmJHl4wlXpYmn2zvtoLr6Sh8upMXSUt o6EIGp5uI3/PKyzj3b4T668zDOA5846ArzNt5mycfaGZFuPs6lERGpmjw3JjYof8 /l0CWasK30wk/uxA4vNYI3LtmNEYbq40wnLJQxEVvCCTyqEstVhK4ZxK7lLb5Pc3 0+i7r4dQ8NZq568xgUohOJQ/TRH999jr2GRob+QWKetMd4qfdRdsdRkabkgykg84 0lnXvpPCxHmJXpN1B/ziD/vU+0/gNG1yYe6DFVoGmWw80SdI5uN7Omk4K7sGTwFi z7sLYGOyxb2yqgitB7T7 =IgtG -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: RemoteEndpoint.Async sendText blocking
> From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Subject: Re: RemoteEndpoint.Async sendText blocking > When the BIO connector is in use, you end up with weird things like > this. I would switch to BIO if you want to use async. Might want to rephrase that... Presumably Chris meant "switch to NIO". Note that the BIO connector is removed (yay!) in Tomcat 8.5 and above. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: RemoteEndpoint.Async sendText blocking
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 To whom it may concern, On 6/29/17 1:49 PM, V User wrote: > Yes, although I admit I'm just learning about all the implications > of that. It seemed to me that even if the actual transmission/write > blocks indefinitely, that should be happening "asynchronously" in > another thread or something and shouldn't stop the Async version of > sendText from returning since it's supposed to return "before the > message is transmitted". It looks like I was wrong there though, so > I'll have to look in to change the connector type. When the BIO connector is in use, you end up with weird things like this. I would switch to BIO if you want to use async. Any reason not to upgrade to Tomcat 8.0/8.5? Many improvements... - -chris > On Thu, Jun 29, 2017 at 1:39 PM, Christopher Schultz < > ch...@christopherschultz.net> wrote: > > Z, V, etc., > > On 6/29/17 1:16 PM, V User wrote: Hello! I have a question about the RemoteEndpoint.Async sendText method. The spec states: "Initiates the asynchronous transmission of a text message. This method returns before the message is transmitted." To me, this implies that the method should return immediately regardless of network status (i.e. it should still return immediately even if the socket connection has died without closing), but I've observed it blocking on writes to a broken connection. I'm also dealing with a known issue with timeouts on Tomcat 7 with a BIO connector (https://bz.apache.org/bugzilla/show_bug.cgi?id=56304). Looking at the source, the Basic/blocking sendText method calls sendPartialString, which uses a Future in the same way that the Async sendText method does, and then calls get on that Future with the configured timeout, so I'd imagine that if the Basic/blocking method has broken timeouts then the Async timeouts will be broken as well. Am I mis-interpreting the spec by expecting Async sendText to return immediately if the socket connection is broken? Is this just an extension of the issue with BIO connectors? My version information is: Server version: Apache Tomcat/7.0.64 Server built: Aug 19 2015 17:18:06 UTC Server number: 7.0.64.0 OS Name:Linux OS Version: 3.13.0-57-generic Architecture: amd64 JVM Version: 1.8.0_131-b11 JVM Vendor: Oracle Corporation Thanks, Z > > Are you in fact using a BIO connector? Because you can't really > expect non-blocking semantics with an underlying pro-blocking > connector. > > -chris >> >> - >> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> > -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJZVWoNAAoJEBzwKT+lPKRYQrEP/0pmfxg7sjspLNnbvDxTc3Hj oCmMjiUyUfyWbQfsh1kHh85CJYoZMgsrTl14jOzmwJFDg3wM1vTJHK99W5F6i9qY 3iRfZPAlRTiR19MqkJv5LL2y/QDg2ccIraJgOiXQ+fIKWQUx23cbEzCdbISwFL/p Gjz5GHc3cpyIHSit9/Hxx8eLUND7P0T57zKpYwyRUVMs6eC0Y67L35tr0DNTUBTv nHrkZ+mBaiTv7kdeDisc7gQjXganP/WuTkjVWP3XTR1JHEDHRiqRykq5pj/K+Nc8 oyK4LBIcmaN/paHKe9o8zlG+iu2koul9fDX5DxuUJSlnxfg0pOaLxDeC/YzFQrWM WPVivhtVhB/fVgoT3IFj4jDoYOHMNepBSEek3ACxi92W+b3bM34YRWo5lKunZqo4 xlCeVaOpXYYfZUQPs7Hxv6p7HPTp+uIAXoVcFX8zCyW30v/bjRJU92RIjcsnDOZE f6Y/RUMB5xejz6A4pwueuLFlSM1Op6FtkyB8HgeS+xNE8xEiVY4RpOfZTbckJ6UL QGsDn1w8hZDqBtHWqpLtYujltP1mZn3FtM1DpUxFZuOu74WJs3pmL14AmbvEtyEm ASoWyQ73l8fmzPwZc9suHY8PRqVZ0/q1QzGX9DFC/im8/5mpDfQC5rZbmLp50ic7 hKP7sfB5KRGvaHmpLjcn =8q1M -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: RemoteEndpoint.Async sendText blocking
Yes, although I admit I'm just learning about all the implications of that. It seemed to me that even if the actual transmission/write blocks indefinitely, that should be happening "asynchronously" in another thread or something and shouldn't stop the Async version of sendText from returning since it's supposed to return "before the message is transmitted". It looks like I was wrong there though, so I'll have to look in to change the connector type. Thanks! On Thu, Jun 29, 2017 at 1:39 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Z, V, etc., > > On 6/29/17 1:16 PM, V User wrote: > > Hello! I have a question about the RemoteEndpoint.Async sendText > > method. The spec states: "Initiates the asynchronous transmission > > of a text message. This method returns before the message is > > transmitted." To me, this implies that the method should return > > immediately regardless of network status (i.e. it should still > > return immediately even if the socket connection has died without > > closing), but I've observed it blocking on writes to a broken > > connection. > > > > I'm also dealing with a known issue with timeouts on Tomcat 7 with > > a BIO connector > > (https://bz.apache.org/bugzilla/show_bug.cgi?id=56304). Looking at > > the source, the Basic/blocking sendText method calls > > sendPartialString, which uses a Future in the same way that the > > Async sendText method does, and then calls get on that Future with > > the configured timeout, so I'd imagine that if the Basic/blocking > > method has broken timeouts then the Async timeouts will be broken > > as well. > > > > Am I mis-interpreting the spec by expecting Async sendText to > > return immediately if the socket connection is broken? Is this just > > an extension of the issue with BIO connectors? > > > > My version information is: Server version: Apache Tomcat/7.0.64 > > Server built: Aug 19 2015 17:18:06 UTC Server number: 7.0.64.0 > > OS Name:Linux OS Version: 3.13.0-57-generic > > Architecture: amd64 JVM Version:1.8.0_131-b11 JVM Vendor: > > Oracle Corporation > > > > Thanks, Z > > Are you in fact using a BIO connector? Because you can't really expect > non-blocking semantics with an underlying pro-blocking connector. > > - -chris > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAllVO1AACgkQHPApP6U8 > pFiZshAApYCGkyjEoMBgCcn9p8UI9HU9Psk62dK8AW40COsc+EeRG7ZdJMB0a1Qs > ajVcN/hwoPzq5Ml1MbWZOoY0qyRPyb0of9e2ZXKi3xX5PpIAe/CJDrnrU9eyzZ9z > VTNlkTfD7lcAjfgmlNM23daiAbLs1e5teO4fjGrgARWeElK0wJfbeYZvFIQmUY+N > sYrsegoy5qYoQ9A5pi9x4ZnrJNsokTZ0FJm/HKpZ9lLzvoCOVkqONNZtd/ak+TO4 > 12AQzU2hRzyRmcSwRRJtbMQ6BzoOiTmKcIodlnwDtWkw1DNg6VVOWMTvF7gpXedq > fDDRxU5p3ME9kyYgUHwh8DaFOmyOBeP0egmiQlYvDJQnK3JfEeukJrW1NP8BvpCM > TOQVnEjz3JHrBuozXqjrW2kGODJTM/h+eubYgHHOc1zCuxkgKBJfwvdsV4WsszNB > BryveNLku1/Zy2fwaEtXUhYS0BP3izswb0RzBClCLoIc1CLnz4ULQ96wGACkzeKj > mWG/4+/LxF+ek/mYAj0jFEFTZUaPI33zkzlHqhd/TxnEf3cszWOZQY3cL5kV0Zmn > lx8BM3KxTW/qSCadWLcv9glSsiO5qWExsX0aBgqHFGDv1lZSg+FVhAc1tIG6ewc0 > G3KLIZJNHNhwBpNxlt+dNSk3Ri/v7aRYnU+oZCut2jcq/Ztiu64= > =EYgI > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: RemoteEndpoint.Async sendText blocking
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Z, V, etc., On 6/29/17 1:16 PM, V User wrote: > Hello! I have a question about the RemoteEndpoint.Async sendText > method. The spec states: "Initiates the asynchronous transmission > of a text message. This method returns before the message is > transmitted." To me, this implies that the method should return > immediately regardless of network status (i.e. it should still > return immediately even if the socket connection has died without > closing), but I've observed it blocking on writes to a broken > connection. > > I'm also dealing with a known issue with timeouts on Tomcat 7 with > a BIO connector > (https://bz.apache.org/bugzilla/show_bug.cgi?id=56304). Looking at > the source, the Basic/blocking sendText method calls > sendPartialString, which uses a Future in the same way that the > Async sendText method does, and then calls get on that Future with > the configured timeout, so I'd imagine that if the Basic/blocking > method has broken timeouts then the Async timeouts will be broken > as well. > > Am I mis-interpreting the spec by expecting Async sendText to > return immediately if the socket connection is broken? Is this just > an extension of the issue with BIO connectors? > > My version information is: Server version: Apache Tomcat/7.0.64 > Server built: Aug 19 2015 17:18:06 UTC Server number: 7.0.64.0 > OS Name:Linux OS Version: 3.13.0-57-generic > Architecture: amd64 JVM Version:1.8.0_131-b11 JVM Vendor: > Oracle Corporation > > Thanks, Z Are you in fact using a BIO connector? Because you can't really expect non-blocking semantics with an underlying pro-blocking connector. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAllVO1AACgkQHPApP6U8 pFiZshAApYCGkyjEoMBgCcn9p8UI9HU9Psk62dK8AW40COsc+EeRG7ZdJMB0a1Qs ajVcN/hwoPzq5Ml1MbWZOoY0qyRPyb0of9e2ZXKi3xX5PpIAe/CJDrnrU9eyzZ9z VTNlkTfD7lcAjfgmlNM23daiAbLs1e5teO4fjGrgARWeElK0wJfbeYZvFIQmUY+N sYrsegoy5qYoQ9A5pi9x4ZnrJNsokTZ0FJm/HKpZ9lLzvoCOVkqONNZtd/ak+TO4 12AQzU2hRzyRmcSwRRJtbMQ6BzoOiTmKcIodlnwDtWkw1DNg6VVOWMTvF7gpXedq fDDRxU5p3ME9kyYgUHwh8DaFOmyOBeP0egmiQlYvDJQnK3JfEeukJrW1NP8BvpCM TOQVnEjz3JHrBuozXqjrW2kGODJTM/h+eubYgHHOc1zCuxkgKBJfwvdsV4WsszNB BryveNLku1/Zy2fwaEtXUhYS0BP3izswb0RzBClCLoIc1CLnz4ULQ96wGACkzeKj mWG/4+/LxF+ek/mYAj0jFEFTZUaPI33zkzlHqhd/TxnEf3cszWOZQY3cL5kV0Zmn lx8BM3KxTW/qSCadWLcv9glSsiO5qWExsX0aBgqHFGDv1lZSg+FVhAc1tIG6ewc0 G3KLIZJNHNhwBpNxlt+dNSk3Ri/v7aRYnU+oZCut2jcq/Ztiu64= =EYgI -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org