Re: Apache Tomcat 9.0.0-M4 and http/2 on Mac OS X 10.11.4
Hi, short update: I got HTTP/2 with Apache Wicket running on Jetty, now. Sadly I couldn't solve the issues with Tomcat. :-( kind regards Tobias > Am 05.04.2016 um 05:00 schrieb Christopher Schultz > : > > Tobias, > >> On 4/4/16 4:49 AM, Tobias Soloschenko wrote: >> I just figured out that this issue might depend on the file names of APR >> 1.5.2 - if I create links in the lib folder that reflects the names of >> 1.4.8 - tomcat throws an exception that the version of APR can not be >> resolved: >> >> ln -s libapr-1.0.dylib libtcnative-1.0.dylib >> >> ln -s libapr-1.a libtcnative-1.a >> >> ln -s libapr-1.dylib libtcnative-1.dylib >> >> ln -s libapr-1.la libtcnative-1.la >> >> >> Exception: >> >> 04-Apr-2016 10:42:39.579 WARNING [main] >> org.apache.catalina.core.AprLifecycleListener.init The APR based Apache >> Tomcat Native library failed to load. The error reported was >> [org.apache.tomcat.jni.Library.version(I)I] > > That wasn't going to work. > > APR and tcnative are different libraries. Copying one to the other is > about as useful as trying to load your /etc/passwd file as a shared library. > > When you set JAVA_OPTS: > >> "export >> JAVA_OPTS=-Djava.library.path=/usr/local/Cellar/apr/1.5.2/libexec/lib" >> >> but Tomcat can not find it at this location. > > How did you start Tomcat after that? What files are in > .../1.5.2/libexec/lib? What is in your "TCNATIVE_PRIV_INCLUDES" > directory? Where do you configure that for loading into Tomcat? > > -chris > > - > 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
Re: Question regarding parseRequestLine
On 10/05/2016 22:00, Thomas Meyer wrote: > Hi, > > I noticed that I can block tomcat 8 by opening 200 connection to the > http 1.1 connector and send 512 bytes of zero in each connection. > > Tomcat 8 seems to block in parseRequestLine() method for 20 seconds > (connectionTimeout) and times out after that. > > The blocking seems to happen while waiting for the http method name. Which connector are you using? > I looked up RFC 2616 and byte zero is as far as I understand not a > legal character for the http method name which are GET, PUT and so on > and extension token which is defined as token which is defined as all > characters excluding 0-31 and 127. > So why doesn't tomcat trash the connection when it detects an invalid > http method name? > > Is this behaviour just a super tolerant implementation? It looks like a very tolerant implementation. > > Bug or feature? I'm curious to know the background of this > behaviour/implementation! The background is it goes all the way back to 4.1.x. It may go back further but there was a big refactoring between 4.0.x and 4.1.x that was before my time so I never figured out my way around the 4.0.x code. Given that clients should not be sending non-token method values and such a value is probably indicative of an issue, detecting this and responding with a 400 is probably better than being tolerant. I'll take a look at a patch. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: A question regarding websocket implementation of Apache Tomcat 8.0.33
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 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 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
Re: A question regarding websocket implementation of Apache Tomcat 8.0.33
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 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
Re: A question regarding websocket implementation of Apache Tomcat 8.0.33
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? On Thu, May 12, 2016 at 12:43 PM, Mark Thomas 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
Re: A question regarding websocket implementation of Apache Tomcat 8.0.33
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
