Re: Troubleshooting Web Services Calls/Duplicate Headers
Thanks for the quick reply Mark. I expected your answers but wasn't sure if they were capabilities unware to me that could help. Randy On Thu, Apr 26, 2018, 1:18 PM Mark Thomas wrote: > On 26/04/18 18:30, Randy Oun wrote: > > > Questions: > > -Are there any known Tomcat issues that could contribute to this > behavior? > > No. Outgoing HTTP connections are nothing to do with Tomcat. > > > -Are there troubleshooting methods for Tomcat itself that can help debug > > the issue? We've increased logging levels and are not seeing any events > > that are helping us diagnose root cause. > > Again, no. For the above reason. > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Troubleshooting Web Services Calls/Duplicate Headers
On 26/04/18 18:30, Randy Oun wrote: > Questions: > -Are there any known Tomcat issues that could contribute to this behavior? No. Outgoing HTTP connections are nothing to do with Tomcat. > -Are there troubleshooting methods for Tomcat itself that can help debug > the issue? We've increased logging levels and are not seeing any events > that are helping us diagnose root cause. Again, no. For the above reason. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Troubleshooting Web Services Calls/Duplicate Headers
Hello Tomcat Users community, currently I have an application hosted in Tomcat 8.5.23 that is getting connect resets when calling a web service. Network traces show that duplicate headers in the web service request (see below) and probable cause. The application devs are not seeing where their code is causing this behavior. Questions: -Are there any known Tomcat issues that could contribute to this behavior? -Are there troubleshooting methods for Tomcat itself that can help debug the issue? We've increased logging levels and are not seeing any events that are helping us diagnose root cause. Thanks in advance, Randy = Example Request from Network Trace POST /WebServiceEndpoint HTTP/1.1 Content-Type: text/xml;charset=utf-8 SOAPAction: "" Authorization: Basic = HTTP_X_FORWARDED_FOR: 10.200.X.X serverId: server.domain.org SR_API_KEY: XXX POST /WebServiceEndpoing HTTP/1.1 Content-Type: text/xml;charset=utf-8 SOAPAction: "" Authorization: Basic = serverId: server.domain.org SR_API_KEY: XXX SR_CATEGORY Cache-Control: no-cache Pragma: no-cache User-Agent: Java/1.8.0_151 Host: destination.server.domain.org Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2 Connection: keep-alive Content-Length: 613 http://schemas.xmlsoap.org/soap/envelope/";> Soap payload...
Re: tomcat connection pool not closing properly
On Thu, Apr 26, 2018 at 10:23 AM, Chris Cheshire wrote: [snip] I've done some more testing with older and newer versions of tomcat, and also swapping to use commons dbcp. All of them exhibit the same behaviour. So the question becomes is this expected behaviour (previous connection pool instances lingering on webapp reload), or is it mysqld misbehaving? It's not a critical problem as restarting tomcat itself clears all the connections, which isn't an issue on sandboxes and rare on the live site anyway. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Socket accept failed: The specified network name is no longer available.
On 26 April 2018 15:18:59 BST, Igor wrote: >I'm trying to find the reason for this problem- >I've installed Wireshark on the instance and have captured the packets >in >the moments that we see a problem. >Tomcat's error log has millisecond precision (.000), but Wireshark's >log has >microsecond precision (.00). >Tomcat's error log has no additional details, so I can't find a match >between the Wireshark capture result and Tomcat's log. > >I try to find out: >1. how to print out into Tomcat's log ip:port of the socket that wasn't >accepted? That isn't available. Tomcat logs all the information the JVM provides. >2. is the timestamp that Tomcat writes to the log set on the event >occurrence or on writing to the file? Neither. It is the time the log message was created. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 9 ;jsessionid
Chris, >As for your image URLs failing due to those path parameters... why are >they failing? Which component is generating those HTTP 500 responses? I did some more investigation and my app would not display the image with the ; http://www.myapp.co.uk/images/image_32x32.png;jsessionid=52FC7E289A9BDAB18ABBBE7D1C5CC85A 26-Apr-2018 15:16:43.356 SEVERE [ajp-nio-8009-exec-2] org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for servlet [default] in context with path [] threw exception org.springframework.security.web.firewall.RequestRejectedException: The request was rejected because the URL contained a potentially malicious String ";" at org.springframework.security.web.firewall.StrictHttpFirewall.rejectedBlacklistedUrls(StrictHttpFirewall.java:265) at org.springframework.security.web.firewall.StrictHttpFirewall.getFirewalledRequest(StrictHttpFirewall.java:245) Something in spring security blocking the ; in the URL. I will go back to 8.5.x to see if I still get the ;jsession on the URL's, my thinking is probably always did have the jsessionid but they were not blocked by spring security. Cheers Greg On 26 April 2018 at 14:11, Christopher Schultz wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Greg, > > On 4/26/18 4:53 AM, Greg Huber wrote: > > Hello, > > > > One thing I have noticed with Tomcat 9.0.x I get alot > > ;jsessionid=xxx appended to my urls. This did not happen with > > 8.5.x. > > > > /images/image_32x32.png;jsessionid=BF27C604B287CCF6DF3DBDB180C2CBEB > > > > 500 Internal Server Error /images/image_32x32.png;jsessionid= ... > > 23784378307846F: 1 Time(s) /images/image_32x32.png;jsessionid= ... > > 85D9B02C5A030FF: 1 Time(s) > > > > > >> From previous experience this happens when there is no session. > >> I use > > struts and have used encode="false" on the tags to prevent this: > > > > > > > > Also I have used (in the past) <%@ page session="false" %> but > > have commented this out as it causes down stream problems for me. > > > > Would there be a reason why these has now started happening on 9? > > I'm not sure about why Tomcat 9 specifically might be doing this if > Tomcat <9 didn't, but this happens when: > > 1. An unauthenticated user makes a request > 2. There was no session-id in the request > 3. The server decided to create a session > 4. The server can't prove that cookies are supported by the client > > When all those things happen, all URLs (when "encoded") should contain > ";jsessionid=" path parameters because the client might not accept the > Set-Cookie response header. > > You can explicitly disable URL-based session-tracking if you'd like in > WEB-INF/web.xml: > > > COOKIE > > > This will of course require cookies. I'm not sure if that's okay for you > . > > As for your image URLs failing due to those path parameters... why are > they failing? Which component is generating those HTTP 500 responses? > > - -chris > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlrh0AMACgkQHPApP6U8 > pFgxbw//dyJKCTcfaHSIsFWC1VbPbe3glKZhq9iKROiJZohtc4+muXL00uwNA7tv > SyX9B2WcknHInEO1jmN0aXdiTs8mri1iqJsLYyomwCWsyMlD0Ekkwk8C6BHdHVbv > HExzFmQ0sChs6X37SYUpdbW8LMe/9g8aGgY4EbpTT7jzMk6cq+iXqLIpQEpbCFLX > VnBY+8HJtKN7Asernrb44ZVrHhdVAv+jT8CcNMw96K2sMKm1fXYXqI1WD7Gx3sDO > uQyb17mVNepK/6qnaJ6F6a3Rzmwf1+CDzi+LRtpX39/8ebkT1gC+8dpFZ2wrOb7P > n1Gx+fEhoYS6g2F+ytcpJaKVId1s5AEJCWQoF+WkWdc+XN7qR2HBPGuYX0hh7KxQ > 01+LSrN88j5GXvtFnFIzcMCrpUg1q7BVnLVVItusuDSbRJFBTt899ekYH1xfe/Vu > TVuK4K6fSZPGw3vK7JxkYK0I7mjZrNonyqjDvr2mBcwrK2u98EnhuctwLYvF9ilt > DGEb3prZHvr7cjceSJ/MAoff7OU/ZAnuCGYhRxpb1DHsVAaSMyxa3gqOMy025WHh > WviCRORP/sru1YRvd33eS1ZhEtawcTpmP7meyDSTRSBI6tf61Gmw7tIr/vnQL4YJ > Z/IaXFgjQJR57bxjG/G+/4xyDe3VB6W8V73tymC6l6mWYfwtGH4= > =xqYE > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
tomcat connection pool not closing properly
[ tomcat 8.5.30, mysql server 5.7.22, connector/j 5.1.46, centos 6, debian 8. ] I recently upgraded my sandboxes from 8.5.24 to 8.5.28 and now .30 and I have noticed that when a webapp is reloaded via the host manager, the associated connection pool is not getting closed down properly in the database. I am not getting abandoned connection warnings in tomcat, rather mysql eventually complains because its max connections has been exceeded. If I run "show full processlist" in mysql after every reload, there are now an extra 5 open connections for the webapp user. It seems that the connection pools are still active, because the connection time column cycles between 0 and timeBetweenEvictionRunsMillis (in seconds). The connections themselves are not showing anything running on them however. Once I shutdown the tomcat process entirely, everything closes and there are no errors in the tomcat logs about abandoned connections. This wasn't the case sometime around 8.5.24. I'm not sure if this is a problem in mysql or tomcat as I have upgraded mysql, the connector and tomcat. I don't know where to look so I'll start here. I have the following in my context.xml for my webapp's connection pool I start tomcat via a systemd service unit. # /etc/systemd/system/tomcat1.service [Unit] Description=Apache Tomcat Web Application Container (sandbox1) Wants=network.target After=syslog.target network.target [Service] Type=forking EnvironmentFile=-/etc/default/tomcat1 ExecStart=/opt/apache-tomcat-8.5.30/bin/catalina.sh start ExecStop=/opt/apache-tomcat-8.5.30/bin/catalina.sh stop User=sandbox1 Group=sandbox1 UMask=0007 [Install] WantedBy=multi-user.target # /etc/default/tomcat1 JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64 CATALINA_HOME=/opt/apache-tomcat-8.5.30 CATALINA_BASE=/home/sandbox1/tomcat CATALINA_OUT=/home/sandbox1/tomcat/logs/catalina.out CATALINA_PID=/home/sandbox1/tomcat/tomcat.pid - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Socket accept failed: The specified network name is no longer available.
I'm trying to find the reason for this problem- I've installed Wireshark on the instance and have captured the packets in the moments that we see a problem. Tomcat's error log has millisecond precision (.000), but Wireshark's log has microsecond precision (.00). Tomcat's error log has no additional details, so I can't find a match between the Wireshark capture result and Tomcat's log. I try to find out: 1. how to print out into Tomcat's log ip:port of the socket that wasn't accepted? 2. is the timestamp that Tomcat writes to the log set on the event occurrence or on writing to the file? -- Sent from: http://tomcat.10.x6.nabble.com/Tomcat-User-f1968778.html - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: DefaultServlet subclass behavior change TC6 to 8
> If you look at doGet() and follow the code you should be able to figure out what you need to change to get things working in 8.5.x. Thanks Mark, that did the trick, serveResource calls getRelativePath(request, true) now where we were overriding getRelativePath(request) Chris, the Filter idea definitely looks like a better design, I'll keep that in mind if we rework the feature. Thanks. /Daryl
Re: Tomcat 9 ;jsessionid
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Greg, On 4/26/18 4:53 AM, Greg Huber wrote: > Hello, > > One thing I have noticed with Tomcat 9.0.x I get alot > ;jsessionid=xxx appended to my urls. This did not happen with > 8.5.x. > > /images/image_32x32.png;jsessionid=BF27C604B287CCF6DF3DBDB180C2CBEB > > 500 Internal Server Error /images/image_32x32.png;jsessionid= ... > 23784378307846F: 1 Time(s) /images/image_32x32.png;jsessionid= ... > 85D9B02C5A030FF: 1 Time(s) > > >> From previous experience this happens when there is no session. >> I use > struts and have used encode="false" on the tags to prevent this: > > > > Also I have used (in the past) <%@ page session="false" %> but > have commented this out as it causes down stream problems for me. > > Would there be a reason why these has now started happening on 9? I'm not sure about why Tomcat 9 specifically might be doing this if Tomcat <9 didn't, but this happens when: 1. An unauthenticated user makes a request 2. There was no session-id in the request 3. The server decided to create a session 4. The server can't prove that cookies are supported by the client When all those things happen, all URLs (when "encoded") should contain ";jsessionid=" path parameters because the client might not accept the Set-Cookie response header. You can explicitly disable URL-based session-tracking if you'd like in WEB-INF/web.xml: COOKIE This will of course require cookies. I'm not sure if that's okay for you . As for your image URLs failing due to those path parameters... why are they failing? Which component is generating those HTTP 500 responses? - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlrh0AMACgkQHPApP6U8 pFgxbw//dyJKCTcfaHSIsFWC1VbPbe3glKZhq9iKROiJZohtc4+muXL00uwNA7tv SyX9B2WcknHInEO1jmN0aXdiTs8mri1iqJsLYyomwCWsyMlD0Ekkwk8C6BHdHVbv HExzFmQ0sChs6X37SYUpdbW8LMe/9g8aGgY4EbpTT7jzMk6cq+iXqLIpQEpbCFLX VnBY+8HJtKN7Asernrb44ZVrHhdVAv+jT8CcNMw96K2sMKm1fXYXqI1WD7Gx3sDO uQyb17mVNepK/6qnaJ6F6a3Rzmwf1+CDzi+LRtpX39/8ebkT1gC+8dpFZ2wrOb7P n1Gx+fEhoYS6g2F+ytcpJaKVId1s5AEJCWQoF+WkWdc+XN7qR2HBPGuYX0hh7KxQ 01+LSrN88j5GXvtFnFIzcMCrpUg1q7BVnLVVItusuDSbRJFBTt899ekYH1xfe/Vu TVuK4K6fSZPGw3vK7JxkYK0I7mjZrNonyqjDvr2mBcwrK2u98EnhuctwLYvF9ilt DGEb3prZHvr7cjceSJ/MAoff7OU/ZAnuCGYhRxpb1DHsVAaSMyxa3gqOMy025WHh WviCRORP/sru1YRvd33eS1ZhEtawcTpmP7meyDSTRSBI6tf61Gmw7tIr/vnQL4YJ Z/IaXFgjQJR57bxjG/G+/4xyDe3VB6W8V73tymC6l6mWYfwtGH4= =xqYE -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to coustomize error 404 apache tomcat 9.0.6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Alexandre, >>> On Apr 25, 2018, at 7:06 PM, Christopher Schultz >>> wrote: >>> >> Anexandre, >> > On 4/25/18 6:23 PM, Alexandre Adao wrote: What will be the > easiest way to customize page error 404 running Apache > Tomcat 9.0.6? I have tried some links such as > https://serverfault.com/questions/254102/custom-error-pages-on-apa che- >> > > tomcat > > >> and didn't work. > > I am running on Windows Server 2016 at the moment. My > default directory is: C:\Program Files\Apache Software > Foundation\Tomcat 9.0.6. Which web.xml needs to be > changed? ..\conf or ..\weapps ? How can I customize the > error page 404? >> >> Do you want to customize the 404 response page for your web >> application (e.g. /myapp/no-such-resource) or for the whole >> server (e.g. /no-such-context/no-such-resource)? > On 4/25/18 7:49 PM, Alexandre Adao wrote:> For the whole server... The easiest thing for you to do is: C:> CD C:\Program Files\Apache Software Foundation\Tomcat 9.0.6 C:> MKDIR webapps\ROOT C:> CD webapps\ROOT C:> MKDIR WEB-INF C:> COPY CON WEB-INF\web.xml http://java.sun.com/xml/ns/javaee"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"; version="3.0" metadata-complete="true"> Dummy ROOT context to prevent 400 Bad Request responses 404 /404.html ^Z<- That's a CTRL-Z character, to end the here-document Now, put whatever content you want into 404.html and you are done. If you like what you have, make it into a WAR file and you can drop it onto all your running servers. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlrhzvIACgkQHPApP6U8 pFj9LA/+OhtekamX2nv4IfD+K8iYqqrLqpreL/sGumaQ8I+18+R5RUMXN13v0Nfs A3DZK8ASK9dThZtXg1HnHuFP+F3tFgk50Wt8NIg3CqbS+CI6ozljXjuogXI1vUlB 1ZdRdvAyB79F4k3h9CGPmh10BAuTohR4O1K8//NtW1Ca0JpOIS1ZDYTuj//XQA6N 4be37HOTGCh5+szp8E+wpM4DncHjlOB2AbtCTeNeTmb4KzoJuIYSlJxwWxXV58fc dRCi0di/uy2DnwS/3KNQp4dyk2qnnr9iwHcfopr+Vb24hvrH+7sLTSaydxZkfoxh lPY9KfD6asPjfrCZWeT9/scN+iQ4ELnpdB+e/FuQ9BNZQ/fIfSFBFnkpEeMw7qmF j2A76gViJO+RNhGmDF5kOjOlR9Wy2oYI7/7mnfiqS30SK56so5wZY0eEoF+0W3IE 1GvatccA2l2dJwQzAcEOcUzdrUPRNCK9omfvW0Qil8Rl0l7/h/v+jW72MdN+kZBY eEatVGdkrYw/qXG/QGc4lbpoe5/6HIzGZ7SmZH8ymoQR/+LyMwOFn5MrRn+dZTpV QGWddokaz0er3WU7pRRuhWRlHp1GPsYh5X7y2WnJ++R33G0ctksm6q1iCOx4utnr +yOVqQDhUjphEThWpQwostlj07ejY6wjS5+WjitDkAbB+sjCIxI= =ytZS -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: x-forwarded-X stuff and websockets
> > > > Are you sure the L7 load balancer can handle HTTP upgrade? Looking at > the Amazon docs you want an "Application load balancer" rather than a > "Classic load balancer" > > My guess is that the load balancer is removing one or more of the > headers Tomcat depends on to identify the request as a WebSocket > request. Can you use tcpdump to capture a request that returns a 404? > Looking at that trace should point us in the right direction. > > Mark > thx mark thats very likely it. https://aws.amazon.com/elasticloadbalancing/details/#compare weird thing is websockets are working with classic tcp/layer 4 ... I guess that is kind of logical because everything is just send as is... and the the http/https layer 7 one of classes really doesn't support it correctly And ALB doesnt support smtp and other ports that we need (At least that is what is told to me) And in the end we also need sticky session support and so (what only an http or application load balancer supports) so we have here an very annoying problem that any solution we pick will not support all features that we need... -- Johan Compagner Servoy
Re: Tomcat 9 ;jsessionid
On 26/04/18 09:53, Greg Huber wrote: > Hello, > > One thing I have noticed with Tomcat 9.0.x I get alot ;jsessionid=xxx > appended to my urls. This did not happen with 8.5.x. > > /images/image_32x32.png;jsessionid=BF27C604B287CCF6DF3DBDB180C2CBEB > > 500 Internal Server Error >/images/image_32x32.png;jsessionid= ... 23784378307846F: 1 Time(s) >/images/image_32x32.png;jsessionid= ... 85D9B02C5A030FF: 1 Time(s) > > > From previous experience this happens when there is no session. I use > struts and have used encode="false" on the tags to prevent this: > > > > Also I have used (in the past) <%@ page session="false" %> but have > commented this out as it causes down stream problems for me. > > Would there be a reason why these has now started happening on 9? You'll need to explain the exact steps to reproduce this on a clean Tomcat install. The smaller the test case, the better. With that, we should be able to say why a session is being created and the ID encoded in the URL. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: x-forwarded-X stuff and websockets
On 26/04/18 08:54, Johan Compagner wrote: > Hi, > > We have a tomcat on an amazon service with for now a ELB L4 (tcp > loadbalancer, with ssl offloading) before it > > That works for the most part just fine, except we don't know that we are in > ssl mode or not > Our application have support for that to look at the x-forwarded-proto > header (and some other fallbacks) to see what is really the scheme the end > users uses > > So we switch to a ELB L7 load balancer which is the http load balancer that > will add those x-forwarded-proto for us. And yes i checked they are on all > the reques tthen. > > This seems to work for all kind of connections to servlets/files/filters > and so on except websockets > Suddenly if we switch that on then all the websocket connections are > returning 404 (i see that in the browser and in the tomcat access log) > Can't find any other thing in the log files that would give me a clue what > is happening > > Does anybody has an idea why suddenly the http upgrade stuff to websockets > (wss protocol) are suddenly seen as 404/NOT_FOUND ? Are you sure the L7 load balancer can handle HTTP upgrade? Looking at the Amazon docs you want an "Application load balancer" rather than a "Classic load balancer" My guess is that the load balancer is removing one or more of the headers Tomcat depends on to identify the request as a WebSocket request. Can you use tcpdump to capture a request that returns a 404? Looking at that trace should point us in the right direction. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: converting 8.0.x ssl Connector to 8.5.x sslHostConfig
On 26/04/18 02:37, Baron Fujimoto wrote: > We're working on upgrading from 8.0.x to 8.5.x in preparation for 8.0's > impending EOL. > Our initial 8.5 deployment which essentially uses our legacy server.xml SSL > connectors from 8.0 seems to work as expected. The HTTP Connector > documentation suggests that the SSL configuration should now be handled by > the nested SSLHostConfig and Certificate elements; is this the case? I've > been running into snags trying to convert our lagacy config. Is there a > migration guide I may have missed? What snags? What is the original 8.0.x configuration? What is the new 8.5.x configuration? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: APR/native error on tomcat 8.5.16
On 25/04/18 13:34, M. Manna wrote: > I needed to mask out certain information before I could send you the full > stack trace. Here is the full version: OK. That looks like a normal ClientAbortException. This doesn't look like Tomcat's logging. It looks like application logging. I think you need to look at the application's exception handling. Mark > > INFO | jvm 1| 2018/04/25 05:37:38 | > org.apache.catalina.connector.ClientAbortException: java.io.IOException: > Unexpected error [730,054] writing data to the APR/native socket > [953,181,632] with wrapper > [org.apache.tomcat.util.net.AprEndpoint$AprSocketWrapper@3685e06d > :953181632]. > INFO | jvm 1| 2018/04/25 05:37:38 | at > org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:356) > INFO | jvm 1| 2018/04/25 05:37:38 | at > org.apache.catalina.connector.OutputBuffer.flushByteBuffer(OutputBuffer.java:815) > INFO | jvm 1| 2018/04/25 05:37:38 | at > org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:310) > INFO | jvm 1| 2018/04/25 05:37:38 | at > org.apache.catalina.connector.OutputBuffer.flush(OutputBuffer.java:284) > INFO | jvm 1| 2018/04/25 05:37:38 | at > org.apache.catalina.connector.CoyoteOutputStream.flush(CoyoteOutputStream.java:118) > INFO | jvm 1| 2018/04/25 05:37:38 | at > lsajdflslsjdfServlet.doPost(lsajdflslsjdfServlet.java:161) > INFO | jvm 1| 2018/04/25 05:37:38 | at > lsajdflslsjdfServlet.doGet(lsajdflslsjdfServlet.java:36) > INFO | jvm 1| 2018/04/25 05:37:38 | at > javax.servlet.http.HttpServlet.service(HttpServlet.java:635) > INFO | jvm 1| 2018/04/25 05:37:38 | at > javax.servlet.http.HttpServlet.service(HttpServlet.java:742) > INFO | jvm 1| 2018/04/25 05:37:38 | at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231) > INFO | jvm 1| 2018/04/25 05:37:38 | at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) > INFO | jvm 1| 2018/04/25 05:37:38 | at > org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) > INFO | jvm 1| 2018/04/25 05:37:38 | at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) > INFO | jvm 1| 2018/04/25 05:37:38 | at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) > INFO | jvm 1| 2018/04/25 05:37:38 | at > lsajdflslsjdfFilter.doFilter(lsajdflslsjdfFilter.java:26) > INFO | jvm 1| 2018/04/25 05:37:38 | at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) > INFO | jvm 1| 2018/04/25 05:37:38 | at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) > INFO | jvm 1| 2018/04/25 05:37:38 | at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:198) > INFO | jvm 1| 2018/04/25 05:37:38 | at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96) > INFO | jvm 1| 2018/04/25 05:37:38 | at > org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:478) > INFO | jvm 1| 2018/04/25 05:37:38 | at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140) > INFO | jvm 1| 2018/04/25 05:37:38 | at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:80) > INFO | jvm 1| 2018/04/25 05:37:38 | at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87) > INFO | jvm 1| 2018/04/25 05:37:38 | at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:342) > INFO | jvm 1| 2018/04/25 05:37:38 | at > org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:799) > INFO | jvm 1| 2018/04/25 05:37:38 | at > org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66) > INFO | jvm 1| 2018/04/25 05:37:38 | at > org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868) > INFO | jvm 1| 2018/04/25 05:37:38 | at > org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.doRun(AprEndpoint.java:2298) > INFO | jvm 1| 2018/04/25 05:37:38 | at > org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) > INFO | jvm 1| 2018/04/25 05:37:38 | at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > INFO | jvm 1| 2018/04/25 05:37:38 | at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > INFO | jvm 1| 2018/04/25 05:37:38 | at > org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) > INFO | jvm 1| 2018/04/25 05:37:38 | at > java.lang.Thread.run(Thread.java:745) > INFO | jvm
Tomcat 9 ;jsessionid
Hello, One thing I have noticed with Tomcat 9.0.x I get alot ;jsessionid=xxx appended to my urls. This did not happen with 8.5.x. /images/image_32x32.png;jsessionid=BF27C604B287CCF6DF3DBDB180C2CBEB 500 Internal Server Error /images/image_32x32.png;jsessionid= ... 23784378307846F: 1 Time(s) /images/image_32x32.png;jsessionid= ... 85D9B02C5A030FF: 1 Time(s) >From previous experience this happens when there is no session. I use struts and have used encode="false" on the tags to prevent this: Also I have used (in the past) <%@ page session="false" %> but have commented this out as it causes down stream problems for me. Would there be a reason why these has now started happening on 9? Cheers Greg
x-forwarded-X stuff and websockets
Hi, We have a tomcat on an amazon service with for now a ELB L4 (tcp loadbalancer, with ssl offloading) before it That works for the most part just fine, except we don't know that we are in ssl mode or not Our application have support for that to look at the x-forwarded-proto header (and some other fallbacks) to see what is really the scheme the end users uses So we switch to a ELB L7 load balancer which is the http load balancer that will add those x-forwarded-proto for us. And yes i checked they are on all the reques tthen. This seems to work for all kind of connections to servlets/files/filters and so on except websockets Suddenly if we switch that on then all the websocket connections are returning 404 (i see that in the browser and in the tomcat access log) Can't find any other thing in the log files that would give me a clue what is happening Does anybody has an idea why suddenly the http upgrade stuff to websockets (wss protocol) are suddenly seen as 404/NOT_FOUND ? -- Johan Compagner Servoy
Re: tomcat 7 and 8 version memory setting
Ramesh, On Thu, Apr 26, 2018 at 11:45 AM, Naga Ramesh wrote: > Team, > > > > I have configured the tomcat7 & 8 versions on our AWS environment, but how > much memory need to give min and max for each tomcat. ( max to max how much > need to give the max vlaue) > > > > Server: AWS linux > > RAM: 128GB > > > > I have given min:4096M and max:32768M > IMO, without analyzing the application's heap usage pattern, it's very hard to speculate what should be the ideal heap size for any application. If you set too low values, you might ended up seeing frequent GCs and in worst case - OutOfMemory. If you go for a very high value, and your application's requirement is much lesser than that, then you have lots of unused memory(which you can use in different purpose). As you have already setup a min/max value, I will strongly suggest you to look closely at the heap usage for at least one week. You can get that information in GC log(hopefully you are logging it). After that you can set min/max heap size to a value which is 20-30% more than your max heap usage. That will give your app some head room so that in emergency situation(like very large request processing or sudden spike in user traffic) your app behaves normally. Thanks! Suvendu - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
