Re: LogAbandoned Stack Trace?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jerry, On 1/6/17 5:44 PM, Jerry Malcolm wrote: > On 1/6/2017 4:30 PM, Christopher Schultz wrote: >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 >> >> Jerry, >> >> On 1/6/17 10:35 AM, Jerry Malcolm wrote: >>> I'm getting "too many connections" errors. >> Where? >> >> Can you provide an exact error message and, better yet, a stack >> trace? >> >>> I'm pretty sure I am configured with enough connections that I >>> shouldn't run out. So I'm assuming I'm leaving some >>> connections open. >> That's a good assumption. >> >>> I have LogAbandoned="true" in my jdbc resource statements. >>> The doc says TC will log a stack trace of abandoned >>> connections. But I don't see any stack traces. Would they be >>> in stderr, stdout, catalina log? Or is it that I'm actually not >>> getting any abandoned? >> Which db connection pool are you using? Standard (DBCP-based) or >> tomcat-pool? A full (sanitized) configuration would >> help. >> >> - -chris >> > Chris, Stack trace follows. It looks like it may be mySQL that's > rejecting the connection. But even if that's the case, it's > probably because I'm not closing some connections, which should > still generate a logAbandoned stack trace, correct? I believe I'm > using dbcp. Not doing anything fancy... Just defining data source > resources in the context file: > > name="jdbc/cis" auth="Container" type="javax.sql.DataSource" > maxTotal="100" maxIdle="30" maxWaitMillis="1" > removeAbandoned="true" removeAbandonedTimeout="60" > logAbandoned="true" username="" password="xxx" > driverClassName="com.mysql.jdbc.Driver" > url="jdbc:mysql://localhost:3306/xx" /> Can you reproduce this in a testing environment? If not, I'd recommend the following: 1. Use maxActive="1" in dev/testing 2. removeAbandoned="false" in dev/testing These two settings will grind your application to a halt in dev/testing when you drop a connection because there's only one to go around. It will also help you find deadlock timebombs you may have when a thread tries to check-out two connections when only one is appropriate. You also might want to use a static-analysis tool like FindBugs to scan your code: it might find a bunch of places where you can immediately see missing Connection.close() calls. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJYcCLYAAoJEBzwKT+lPKRYOP8QAIssYUCTjyV/ukTVtYFJHVyv upyqmFkoydAlHJzBluJw0U8NpT12+/mKN6JJJIJPtZZfvNc0kGq0Vd7Vl7mTOQx1 UZqH9ENrpzy+bPGjs2+21b1pstBas4TSyq3zM2nlx1QRgMwit31ywwJyYk3veYDf On20vAWGh3eT1xgnr+IXBCkn0KX6R4JgbRkX2Rh0Dpuah/7QmsNJI/tgBDyqDoOF UW2tN8oW6YfG0CLyodZWwg9jdM9cmLQgNmAc1TNqwoT+BqVDvHEVenLBTRL0OxWs XYSSmoFiivHdT1X6Wy7wR0Ido1/GrKxDD6WvdbRi8ZKqWOYUrjRehKuNE6NzeXH9 OVQBi6bmtTN853HEO6YBh54GQg3JblpyRxJ64fsmdnm/TvvylEUdfPVKnIjxlv5o AYpcfLsg0332xI/MmX+kRbfbQEpBv5fMR0M59p/FT0HYFMc6XtU+6AU6MNmYLwIP zFFPTWKYfswrfXG/PzM6ZU6DBX50UnR9pUmLUoC5n+h31AZMJ7cGxZSVOZ8pLlAt 9KL7h79uNLFUhgBvnHQwLswSm9lgAl6IJzPGOXRssmmWbNiB9+vSzkLjVOZg8Zze Rvj5LhsN4DylhBMXY9b+7tMqBHih9xZV/9ReDIpQ569bJX0t/mpXQemO01qVM9n7 vpqgCeLCy6QAjxNZsFgU =DIwn -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.5 - APR 1.2.10 SSL CPU issue ?
Yep that would, Originally I had just turned the return 0 to throw an IOException - which as it would fall through to the else would be the same effect. I'll see if a java client would do the same, I'm using a golang client/console app for testing. I just tried with wget and see the WSAECONNABORTED status within APR. It also seems a bit time dependent, might be a case of whether APR is getting to the socket read before or after the FIN packet coming though ?? On Fri, Jan 6, 2017 at 5:11 PM, Mark Thomas wrote: > On 06/01/2017 21:50, David Oswell wrote: > > I've somehow gotten the build for tcnative working here (more shocked I > > finally got openssl to build!) > > > > There seems to be a slight difference in how the shutdown occurs. When > the > > APR_EGENERAL is returned its due to falling through the SSL_ERROR_SYSCALL > > block in sslnetwork.c:ssl_socket_recv, > > This seems to be due to a difference in the value returned by; > > sslnetwork.c:324 :rv = > > apr_get_netos_error(); > > > > on the bad case (quick socket close), rv is (730053) which > > is WSAECONNABORTED - APR_STATUS_IS_ECONNABORTED > > on a good disconnect case (slower socket close) rv is (730054) > > = WSAECONNRESET - APR_STATUS_IS_ECONNRESET > > > > I suspect a check with APR_STATUS_IS_ECONNABORTED(rv) might be needed to > > capture this scenario (WSAECONNABORTED), however I'm not sure how else > this > > status might occur, and if any of those cases should not flag it as > closed > > - although reading on WSAECONNABORTED it sounds like this is a close > case. > > Not sure if it's an exception case or just normal EOF though. > > Thanks. That is really useful information. > > I've been trying to re-create the original issue that led to this odd > 'treat an error as eagain' code but without success. I have found a > couple of other bugs (now fixed) so it wasn't a complete waste of time. > > When I added this hack I was fairly sure I was missing something and it > is looking increasingly like this code was fixing a symptom rather than > the root cause. Given that I can't re-create the original problem, I'm > leaning towards removing the special handling for EGENERAL and letting > it trigger a close. > > If you remove the > else if (-result == Status.APR_EGENERAL && isSecure()) { > ... > } > > block, does that fix the problem you are seeing? > > Mark > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: LogAbandoned Stack Trace?
On 1/6/2017 4:30 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jerry, On 1/6/17 10:35 AM, Jerry Malcolm wrote: I'm getting "too many connections" errors. Where? Can you provide an exact error message and, better yet, a stack trace? I'm pretty sure I am configured with enough connections that I shouldn't run out. So I'm assuming I'm leaving some connections open. That's a good assumption. I have LogAbandoned="true" in my jdbc resource statements. The doc says TC will log a stack trace of abandoned connections. But I don't see any stack traces. Would they be in stderr, stdout, catalina log? Or is it that I'm actually not getting any abandoned? Which db connection pool are you using? Standard (DBCP-based) or tomcat-pool? A full (sanitized) configuration would help. - -chris Chris, Stack trace follows. It looks like it may be mySQL that's rejecting the connection. But even if that's the case, it's probably because I'm not closing some connections, which should still generate a logAbandoned stack trace, correct? I believe I'm using dbcp. Not doing anything fancy... Just defining data source resources in the context file: name="jdbc/cis" auth="Container" type="javax.sql.DataSource" maxTotal="100" maxIdle="30" maxWaitMillis="1" removeAbandoned="true" removeAbandonedTimeout="60" logAbandoned="true" username="" password="xxx" driverClassName="com.mysql.jdbc.Driver" url="jdbc:mysql://localhost:3306/xx" /> java.sql.SQLException: Cannot create PoolableConnectionFactory (Data source rejected establishment of connection, message from server: "Too many connections") at org.apache.tomcat.dbcp.dbcp2.BasicDataSource.createPoolableConnectionFactory(BasicDataSource.java:2195) at org.apache.tomcat.dbcp.dbcp2.BasicDataSource.createDataSource(BasicDataSource.java:1945) at org.apache.tomcat.dbcp.dbcp2.BasicDataSource.getConnection(BasicDataSource.java:1412) at jwm.servletdb.ServletDBData.getInstance(ServletDBData.java:139) at jwm.servletdb.ServletDBData.getInstance(ServletDBData.java:93) at jwm.servletdb.ServletDBData.getInstance(ServletDBData.java:62) at org.apache.jsp.jsp.login.login_005fv2_jsp._jspService(login_005fv2_jsp.java:450) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:725) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:432) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:396) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:340) at javax.servlet.http.HttpServlet.service(HttpServlet.java:725) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:291) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:721) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:466) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:391) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:318) at org.apache.catalina.authenticator.FormAuthenticator.forwardToLoginPage(FormAuthenticator.java:411) at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:256) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:470) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79) at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:610) at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:291) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:537) at org.apache.coyote.ajp.AbstractAjpProcessor.process(AbstractAjpProcessor.java:831) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:658) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1556) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1513) at java.util.concurrent.ThreadP
Re: help resolving memory leak error message
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 To whom it may concern, On 1/6/17 5:21 PM, modjkl...@comcast.net wrote: > I'm porting a Apache Flex (with Apache BlazeDS) web app from > glassfish to tomcat 8.5.9, and observing the following severe > error. > > 06-Jan-2017 13:49:07.644 SEVERE > [ContainerBackgroundProcessor[StandardEngine[Catalina]]] > org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapFo rLeaks > > The web application [myApp] created a ThreadLocal with key of type > [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@4d6e6d7b]) > and a value of type [flex.messaging.io.SerializationContext] > (value [flex.messaging.io.SerializationContext@66135428]) but > failed to remove it when the web application was stopped. Threads > are going to be renewed over time to try and avoid a probable > memory leak. > > Is this a warning or an actual error that is causing a memory > leak? This is probably a problem with the application that Glassfish never detected, but has always been there. This is a warning about a leak, but Tomcat will cycle-through the request-processing threads, retiring them at intervals, in order to mitigate the leak. You're welcome ;) If all goes well, this leak will be handled by Tomcat and your service won't suffer for it. That said, you should fix the problem because cleaning-up messes is wasteful if the mess wasn't necessary in the first place. > Can anyone point me in the right direction to resolve this? The leak itself is coming from your application or one of the libraries it's using. The solution will be to find a fix that leak. I would start by asking the Apache Flex people what the SerializationContext is for, and how to remove ThreadLocal values from shared threads (such as those in a servlet environment). It's possible you are using the Flex framework in a way that is not conducive to a servlet environment, but that a few changes could make it safer to use. > I'm a new Tomcat user (please try to be explicit). Welcome to the community. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJYcBxSAAoJEBzwKT+lPKRYmNsP/3w4GmqYvLoCS40bUEqmC0gp placYbZkbloyRLxRRjgbod8qZcj5HPQqJzGfzV9vS4Wu5PdWg5rxbavv/aOOR/3X X5hRtzRiw5TBDDUdxjp2MtxoANWRQ+XXITMFTy8dGqoq3LeAmJSsLpFri7T6GwNx SO2ZeuwYPYX+r462tOlFqboS1FvZTcGp/lU1FCoyIAuPs2qwVsHLKEMpnQ4scEpr MB6wf8vx50+dK27MAW/Oa3MaNOfS85FuJsqJ+rqqfUHNI95A6MVGW0ocQ8EeHpna tGY6QC+xfaiLHfd2u7PR+kFUhMC7G94C37rJtF3vqh+x7gUhsEgtzMRpF6tB5FpV ge5zWY9TIWQ7KejLv0VwIdv4cdR4TcMpjG7Kw2wdExEytoINX0L+ATL7Sg3WN1Cv viAct9D4LyHa/Sov1hudC6VXvLBvvzmHTSThVKgW5thNrut279DMXaHCasPLXSIa WK8+MP77LKh9MjsSP1R61GQgZh6y4/hn/E7g/RB3e17oTUzUqc1UsOQa/2nJlyF0 imHpnC2KPiZMb9FMcrwtRG2K7fOSwOVIctVHnIykM27oZA8usjNmdBdmOGzcJR5F wcnkgIOTOsUKaymYNOAeBYH3FmkG/RAjfavsvXACMyDpiaeucHaR6oNtK47MJHCu qnr4kNE/TtpH9Wbx0GoV =vJk+ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: LogAbandoned Stack Trace?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jerry, On 1/6/17 10:35 AM, Jerry Malcolm wrote: > I'm getting "too many connections" errors. Where? Can you provide an exact error message and, better yet, a stack trace? > I'm pretty sure I am configured with enough connections that I > shouldn't run out. So I'm assuming I'm leaving some connections > open. That's a good assumption. > I have LogAbandoned="true" in my jdbc resource statements. The > doc says TC will log a stack trace of abandoned connections. But I > don't see any stack traces. Would they be in stderr, stdout, > catalina log? Or is it that I'm actually not getting any > abandoned? Which db connection pool are you using? Standard (DBCP-based) or tomcat-pool? A full (sanitized) configuration would help. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJYcBp5AAoJEBzwKT+lPKRYXuMP/0lKpStpX0OdG3HjNRR3iuLF QBN5tl7v/+kAdlBzDRsGo5TosX5jOdyjrn3kSdLA1EuDE/5AkrHmgBxeo/nriUwM QOPudlC40IA2x8+OvkNgHM5ELqohW0keNe44bGTrrvqyw7So16huGmYQnJI0ZKSe PvfWxFtTRF3/maB0OtIy+xk+jxqG7bxx8YghlO2Of1MNvoYRZyjZ/4kdEh4h76VQ 2okjznZaNH9ZN6VJNbCzNlK4mpBbf0wz4FPV7qiIXobz0AkL8KHaHy4Z4QS8sAYF rp9Z8V/oCMqbg2ULnDK03xcuYdFW9/DfYcMhojv/Dw+5fQOqhlZPm/LrgL47g5Mq yW1ohryIV63GRO4VpTy51mgu1gyTAjQc971xJgg+fHQjkbqTMrqmxnQRRplvZhBg 57bmBlC2QQGh2Kp0VuMS/HDyTPGJ4gpQcUPB2LUl0y2mdPezxfE9oNhs8Rx0N7iE 41q6nwe85Qw63CIb+7FI9fRXnNYks98WuU488Aj5J919vnin3FhrQ09UPoJqXuTm u6XJoOo5xt5pu0Er8ydUZumcES7yercGvTLdqrspjlQhprItWOT55aTftN3/GyVd AKf3Bw/E5EQgvDs+X5novo7DnhJv1xxHgQviRdzPhAHwyBhM6POF4MS7ZawSERq/ QiZGvqYhicHGLTMjLq4s =jMzt -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
help resolving memory leak error message
I'm porting a Apache Flex (with Apache BlazeDS) web app from glassfish to tomcat 8.5.9, and observing the following severe error. 06-Jan-2017 13:49:07.644 SEVERE [ContainerBackgroundProcessor[StandardEngine[Catalina]]] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [myApp] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@4d6e6d7b]) and a value of type [flex.messaging.io.SerializationContext] (value [flex.messaging.io.SerializationContext@66135428]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak. Is this a warning or an actual error that is causing a memory leak? Can anyone point me in the right direction to resolve this? I'm a new Tomcat user (please try to be explicit). Thanks for any advice/comments. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.5 - APR 1.2.10 SSL CPU issue ?
On 06/01/2017 21:50, David Oswell wrote: > I've somehow gotten the build for tcnative working here (more shocked I > finally got openssl to build!) > > There seems to be a slight difference in how the shutdown occurs. When the > APR_EGENERAL is returned its due to falling through the SSL_ERROR_SYSCALL > block in sslnetwork.c:ssl_socket_recv, > This seems to be due to a difference in the value returned by; > sslnetwork.c:324 :rv = > apr_get_netos_error(); > > on the bad case (quick socket close), rv is (730053) which > is WSAECONNABORTED - APR_STATUS_IS_ECONNABORTED > on a good disconnect case (slower socket close) rv is (730054) > = WSAECONNRESET - APR_STATUS_IS_ECONNRESET > > I suspect a check with APR_STATUS_IS_ECONNABORTED(rv) might be needed to > capture this scenario (WSAECONNABORTED), however I'm not sure how else this > status might occur, and if any of those cases should not flag it as closed > - although reading on WSAECONNABORTED it sounds like this is a close case. > Not sure if it's an exception case or just normal EOF though. Thanks. That is really useful information. I've been trying to re-create the original issue that led to this odd 'treat an error as eagain' code but without success. I have found a couple of other bugs (now fixed) so it wasn't a complete waste of time. When I added this hack I was fairly sure I was missing something and it is looking increasingly like this code was fixing a symptom rather than the root cause. Given that I can't re-create the original problem, I'm leaning towards removing the special handling for EGENERAL and letting it trigger a close. If you remove the else if (-result == Status.APR_EGENERAL && isSecure()) { ... } block, does that fix the problem you are seeing? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.5 - APR 1.2.10 SSL CPU issue ?
I've somehow gotten the build for tcnative working here (more shocked I finally got openssl to build!) There seems to be a slight difference in how the shutdown occurs. When the APR_EGENERAL is returned its due to falling through the SSL_ERROR_SYSCALL block in sslnetwork.c:ssl_socket_recv, This seems to be due to a difference in the value returned by; sslnetwork.c:324 :rv = apr_get_netos_error(); on the bad case (quick socket close), rv is (730053) which is WSAECONNABORTED - APR_STATUS_IS_ECONNABORTED on a good disconnect case (slower socket close) rv is (730054) = WSAECONNRESET - APR_STATUS_IS_ECONNRESET I suspect a check with APR_STATUS_IS_ECONNABORTED(rv) might be needed to capture this scenario (WSAECONNABORTED), however I'm not sure how else this status might occur, and if any of those cases should not flag it as closed - although reading on WSAECONNABORTED it sounds like this is a close case. Not sure if it's an exception case or just normal EOF though. On Fri, Jan 6, 2017 at 10:00 AM, Mark Thomas wrote: > On 06/01/2017 10:52, Mark Thomas wrote: > > > I can reproduce the (new?) loop error with the following: > > - clean trunk (9.0.x) build > > - enable debug logging for AprEndpoint > > - APR/native 1.2.10 > > - WebSocket drawboard example > > - hold down F5 > > > > I see some error messages as per the original problem but fairly quickly > > Tomcat enters the infinite loop. > > > > Next steps are digging into the APR/native code. > > It was a different loop related specifically to WebSocket that is now > fixed. > > I'm still looking into this. I'm am currently leaning towards removing > the suspect APR_EGENERAL handling from Tomcat but I want to see if I can > re-create the problem that caused it to be added in the first place. I > haven't had any success so far which leads me to suspect that the root > cause may have been a Tomcat bug that was fixed in the 8.5.x/trunk > refactoring. Proving that is going to be tricky. > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Tomcat7 under Debian dont use outgoing proxy
Tried to Unsubscribe. Did not work. Can you ask Web Master to Unsubscribe me. Thanks, /Ed -Original Message- >From: André Warnier (tomcat) >Sent: Jan 6, 2017 7:13 AM >To: users@tomcat.apache.org >Subject: Re: Tomcat7 under Debian dont use outgoing proxy > >Hi. See below. > >On 06.01.2017 13:01, Schöke, Karsten wrote: >> Hello, >> >> I updated tomcat under debian wheezy from tomcat6 to tomcat7. >> We use access to external http/https webservices via proxy option JAVA_OPTS >> in in /etc/default/tomcat6|7 >> >> -Dhttp.proxyHost=x.x.x.x -Dhttp.proxyPort=3128 -Dhttps.proxyHost=x.x.x.x >> -Dhttps.proxyPort=3128 -Dhttp.nonProxyHosts=*.domain.local >> >> This is functional under tomcat6 but not under tomcat7 >> The java Version is not change. >> >> Java: >> [12:51:32] schoekek@92:~> sudo ls -lah /usr/lib/jvm >> lrwxrwxrwx 1 root root 24 Jun 26 2016 default-java -> >> java-1.7.0-openjdk-amd64 >> >> [12:50:05] schoekek@f92:~> dpkg -l|grep jre >> ii default-jre-headless 1:1.7-47+deb7u2 >> amd64Standard Java or Java compatible Runtime (headless) >> ii openjdk-7-jre-headless:amd64 7u111-2.6.7-2~deb7u1 >> amd64OpenJDK Java runtime, using Hotspot JIT (headless) >> >> Tomcat: >> Ii tomcat77.0.28-4+deb7u8 >> >> Is the configuration option or location in tomcat7 change? >> >> thx Karsten >> >> PS: Debian Bugreport: >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848059 >> > >1) The tomcat that you are using is a Debian packaged version. The code is the >same as >what is distributed on the official Tomat website, but the Debian packagers >re-organise a >lot of things in different directories, links, permissions etc. >So it's not that we do not want to help, but for this kind of issue it is >difficult, >because we do not know exactly what the Debian package does. > >In that sense, your bug report to Debian was the right thing to do. > >2) The code of Tomcat itself does not make outgoing TCP connections. >So any use of the proxies that you define here, must be done by a Tomcat >application, >which we do not know. >Another resource to help you, should be the supplier of that application. >Not much we can do on this end. > > > > > >- >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
LogAbandoned Stack Trace?
I'm getting "too many connections" errors. I'm pretty sure I am configured with enough connections that I shouldn't run out. So I'm assuming I'm leaving some connections open. I have LogAbandoned="true" in my jdbc resource statements. The doc says TC will log a stack trace of abandoned connections. But I don't see any stack traces. Would they be in stderr, stdout, catalina log? Or is it that I'm actually not getting any abandoned? Thx. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.5 - APR 1.2.10 SSL CPU issue ?
On 06/01/2017 10:52, Mark Thomas wrote: > I can reproduce the (new?) loop error with the following: > - clean trunk (9.0.x) build > - enable debug logging for AprEndpoint > - APR/native 1.2.10 > - WebSocket drawboard example > - hold down F5 > > I see some error messages as per the original problem but fairly quickly > Tomcat enters the infinite loop. > > Next steps are digging into the APR/native code. It was a different loop related specifically to WebSocket that is now fixed. I'm still looking into this. I'm am currently leaning towards removing the suspect APR_EGENERAL handling from Tomcat but I want to see if I can re-create the problem that caused it to be added in the first place. I haven't had any success so far which leads me to suspect that the root cause may have been a Tomcat bug that was fixed in the 8.5.x/trunk refactoring. Proving that is going to be tricky. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat7 under Debian dont use outgoing proxy
Hi. See below. On 06.01.2017 13:01, Schöke, Karsten wrote: Hello, I updated tomcat under debian wheezy from tomcat6 to tomcat7. We use access to external http/https webservices via proxy option JAVA_OPTS in in /etc/default/tomcat6|7 -Dhttp.proxyHost=x.x.x.x -Dhttp.proxyPort=3128 -Dhttps.proxyHost=x.x.x.x -Dhttps.proxyPort=3128 -Dhttp.nonProxyHosts=*.domain.local This is functional under tomcat6 but not under tomcat7 The java Version is not change. Java: [12:51:32] schoekek@92:~> sudo ls -lah /usr/lib/jvm lrwxrwxrwx 1 root root 24 Jun 26 2016 default-java -> java-1.7.0-openjdk-amd64 [12:50:05] schoekek@f92:~> dpkg -l|grep jre ii default-jre-headless 1:1.7-47+deb7u2 amd64Standard Java or Java compatible Runtime (headless) ii openjdk-7-jre-headless:amd64 7u111-2.6.7-2~deb7u1 amd64OpenJDK Java runtime, using Hotspot JIT (headless) Tomcat: Ii tomcat77.0.28-4+deb7u8 Is the configuration option or location in tomcat7 change? thx Karsten PS: Debian Bugreport: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848059 1) The tomcat that you are using is a Debian packaged version. The code is the same as what is distributed on the official Tomat website, but the Debian packagers re-organise a lot of things in different directories, links, permissions etc. So it's not that we do not want to help, but for this kind of issue it is difficult, because we do not know exactly what the Debian package does. In that sense, your bug report to Debian was the right thing to do. 2) The code of Tomcat itself does not make outgoing TCP connections. So any use of the proxies that you define here, must be done by a Tomcat application, which we do not know. Another resource to help you, should be the supplier of that application. Not much we can do on this end. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat7 under Debian dont use outgoing proxy
Hello, I updated tomcat under debian wheezy from tomcat6 to tomcat7. We use access to external http/https webservices via proxy option JAVA_OPTS in in /etc/default/tomcat6|7 -Dhttp.proxyHost=x.x.x.x -Dhttp.proxyPort=3128 -Dhttps.proxyHost=x.x.x.x -Dhttps.proxyPort=3128 -Dhttp.nonProxyHosts=*.domain.local This is functional under tomcat6 but not under tomcat7 The java Version is not change. Java: [12:51:32] schoekek@92:~> sudo ls -lah /usr/lib/jvm lrwxrwxrwx 1 root root 24 Jun 26 2016 default-java -> java-1.7.0-openjdk-amd64 [12:50:05] schoekek@f92:~> dpkg -l|grep jre ii default-jre-headless 1:1.7-47+deb7u2 amd64Standard Java or Java compatible Runtime (headless) ii openjdk-7-jre-headless:amd64 7u111-2.6.7-2~deb7u1 amd64OpenJDK Java runtime, using Hotspot JIT (headless) Tomcat: Ii tomcat77.0.28-4+deb7u8 Is the configuration option or location in tomcat7 change? thx Karsten PS: Debian Bugreport: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848059
Re: Tomcat 8.5 - APR 1.2.10 SSL CPU issue ?
On 05/01/2017 22:30, Mark Thomas wrote: > On 05/01/2017 22:01, David Oswell wrote: >> After some more digging I've been able to further narrow down the problem >> somewhat, but still not able to pin point the exact cause; >> The issue is not load related, but rather seems to be related to the timing >> of the TCP connection being closed. >> Depending on the timing the poller and exec appear to get into a loop - >> drilled thsi down to an error status returned in AprEndpoint - which might >> need to be thrown as an exception rather than return 0 from >> the fillReadBuffer in AprEndpoint. >> >> Poller thread - AprEndpoint:1573 - Poller(ID 55) wakes ups >> Poller thread - AprEndpoint:1652 - Poller adds socket to timeout >> Poller thread - AprEndpoint:1675 - Poller gets rv = 1 >> Poller thread - AprEndpoint:1694 - Poller gets connection (socket >> Id 565911936 ) >> Poller thread - AprEndpoint:1731 - Poller processesSocket as socket event >> OPEN_READ >> Poller thread - AbstractEndpoint:903 - executor executes >> AprEndpoint$SocketProcessor (id 63) -> No exception thrown. >> >> Exec thread - AprEndpoint:2403 - Socket.recvb result = -20014 >> Interesting comment ? at AprEndpoint:2445 : >> } else if (-result == Status.APR_EGENERAL && isSecure()) { >> //Status.APR_EGENERAL=20014 >> // Not entirely sure why this is necessary. Testing to date >> has not >> // identified any issues with this but log it so it can be >> tracked >> // if it is suspected of causing issues in the future. >> if (log.isDebugEnabled()) { >> >> log.debug(sm.getString("socket.apr.read.sslGeneralError", getSocket(), >> this)); >> } >> return 0; >> Does this need to throw an exception to get caught higher up as an error? > > Oh great. That code. > > It originates here: > http://svn.apache.org/viewvc?view=revision&revision=1534619 > > For the background see this thread: > http://tomcat.markmail.org/thread/4vspjutd4kzqkc5q > > As far as I could tell, something was happening in the TLS layer that > APR/native was reporting as an error that wasn't really an error. > Therefore, I changed Tomcat to ignore the report of an error and carried on. > > What I suspect is happening is that you are seeing a real error that > Tomcat now isn't treating as an error. > > I do have a working build environment for tc-native on Windows now so > this is probably worth a re-visit. > > I'll put this at the top of my TODO list for after the 9.0.x and 8.5.x > releases I've been meaning to start for the last couple of days. > > Given how far you've got with this in a short time, if you wanted to > continue digging that would be great. My suggestion for a way forward > would be: > - enable debug logging for AprEndpoint > - try and recreate the 20014 error with the WebSocket drawing board > example (as described in the links above) > - trace back into APR/native to figure out a) what is generating that > 20014 error code and b) what it should really be generating. > > If you need to build APR/native, the instructions are here: > https://cwiki.apache.org/confluence/display/TOMCAT/Building+the+Tomcat+Native+Connector+binaries+for+Windows I can reproduce the (new?) loop error with the following: - clean trunk (9.0.x) build - enable debug logging for AprEndpoint - APR/native 1.2.10 - WebSocket drawboard example - hold down F5 I see some error messages as per the original problem but fairly quickly Tomcat enters the infinite loop. Next steps are digging into the APR/native code. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: basic logging info
On 06/01/2017 01:22, modjkl...@comcast.net wrote: > Newbie Tomcat user here. I installed Tomcat 8.5.9 on CentOS 7 a few > days ago and noticed the default log files for catalina, > host-manager, localhost, and manager are created fresh each day with > a date in their filename. > > Doesn't this fill up the directory over time? Yes. > Wouldn't it be better > to have the logs accumulate in one file for some time? Then you'd just have one file getting bigger over time. > Can someone set my expectations what the default logging behavior is, One file per day. > then recommend a general approach to configuring something more > manageable (from a sheer number-of-files standpoint)? Cron job to delete anything more than X days old. Longer term, the FileHandler could be enhanced to add an option to delete files more than X days old. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org