Re: LogAbandoned Stack Trace?

[Christopher Schultz]

-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 ?

[David Oswell]

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?

[Jerry Malcolm]

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 

Re: help resolving memory leak error message

[Christopher Schultz]

-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?

[Christopher Schultz]

-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

[modjklist]

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 ?

[Mark Thomas]

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 ?

[David Oswell]

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

[Edward Bicker]

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?

[Jerry Malcolm]

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 ?

[Mark Thomas]

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

[tomcat]

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

[Schöke , Karsten]

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 ?

[Mark Thomas]

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=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

[Mark Thomas]

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