RE: Slow HTTP Rquest via Tomcat

[Thone Soungpanya]

Hello All,

Thank you all for responding to my issue. I will see if we can turn off 
autodeploy and see if this helps. Will let you know.

Yes, that seems confusing if it is just stating "DEBUG Checking 
context[/ps_9.0_8.53.02_1] redeploy resource 
/usr/local/tomcat-instance5/webapps/ps_9.0_8.53.02_1.war". That statement seems 
as if it checked context, founded that something changed so it redeployed. But 
sounds like it did not per Mark's comment.

Also, I checked the folders for conf files, etc. and no file timestamps have 
changed. It always had the same timestamp as the day we deployed the folder 
unless we directly changed the file data for some reason. 

Thanks,

Thone

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Wednesday, January 14, 2015 12:52 PM
To: Tomcat Users List
Subject: Re: Slow HTTP Rquest via Tomcat

On 14/01/2015 20:46, André Warnier wrote:
> Mark Thomas wrote:
>> On 14/01/2015 18:56, Christopher Schultz wrote:
>>
>>> Possibly.
>>>
>>> I re-read the log file, and there are no logs that actually say that 
>>> the context is reloading. It just says "checking context[/path] 
>>> reload resource" over and over again. I checked, and Tomcat does not 
>>> emit any log messages that look like that... this must come from somewhere 
>>> else.
>>
>> Nope. Look again at the debug logging in
>>
>> org.apache.cataline.startup.HostConfig.checkResources()
>>
>>
>>> so I'm not sure what I'm looking at. What I can tell is that some 
>>> component is furiously checking "reload resources" during the time 
>>> period covered by that log file.
>>
>> Furiously? Look at the timestamps. This is taking milliseconds at most.
>> This is normal behaviour.
>>
>>> I would check the /Tomcat/ log during the same period to see if 
>>> anything is happening, there.
>>
>> GC logging should rule that out as a factor.
>>
> 
> So a log message like :
> 
> 2015-01-12 16:11:07,390 DEBUG Checking context[/ps_9.0_8.53.02_1] 
> redeploy resource 
> /usr/local/tomcat-instance5/webapps/ps_9.0_8.53.02_1.war
> 
> only means that Tomcat is checking /if/ that resource has been 
> changed, not that it is actually redeploying it ?

Correct. There are both redeploy resources and reload resources. Most web 
applications have several of both. If autoDeploy is enabled they are checked 
every ~15s by default.

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Web filter to forward some requests to another remote webserver

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jose,

On 1/14/15 3:54 PM, Jose María Zaragoza wrote:
> 2015-01-14 20:05 GMT+01:00 Christopher Schultz
> : Jose,
> 
> On 1/14/15 8:27 AM, Jose María Zaragoza wrote:
 2015-01-14 12:46 GMT+01:00 André Warnier :
> Jose María Zaragoza wrote:
>> 
>> Hello:
>> 
>> I would like to create a web filter to forward some
>> requests to another webserver,
>> 
>> The filter receives an
>> "application/x-www-form-urlencoded" request , inspects
>> the value of a parameter and chooses to forward to
>> another remote webserver ( as a proxy )
 
 
 Thanks
 
 I agree with you . I'll try to use an Apache httpd front-end
 
 Anyway, I've seen that if I execute
 
 Map parameter = ((HttpServletRequest) 
 request).getParameterMap();
 
 , then request.getInputStream is empty
 
 
 But if I execute
 
 Map parameter = ((HttpServletRequest) 
 request).getParameterMap(); chain.doFilter(request,
 response);
 
 , the next filter in the chain receives the body ( as I
 expect it )
 
 I don't understand this behaviour
> 
> I think that might be a bug... calling 
> HttpServletRequest.getParameter* should cause the request entity to
> be parsed, as long as the content type is 
> application/x-www-form-urlencoded. I think getParameterMap counts,
> but I'd have to review the spec & javadoc (where some fun spec 
> requirements are hidden!).
> 
> Anyhow, when you call HttpServletRequest.getParameter*, the
> container *must* consume the request, according to the spec.
> 
> 
>> Thanks.
> 
>> In my case, all requests to be forwarded are POST requests  (
>> and content type is application/x-www-form-urlencoded ) According
>> to your reply, if I've got a chain of filters and the first one
>> calls getParameterMap , do the next filters lose the content of 
>> the payload ?

Correct. Once the request entity has been read (which happens when you
call request.getParameter*), it's no longer available to the application.

>> I tested to call several times to getParameterMap method on the
>> same webfilter and it always returned the right values. Looks
>> like getParameterMap doesn't consume() payload, but ... if I call
>> getInputStream() after getParameterMap() , the stream is empty
> 
>> I'm using Tomcat 7.0.50 and I cannot understand the logic of
>> this

Interesting. I find that surprising... I'll look into that.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJUttm6AAoJEBzwKT+lPKRYcSAP/jxIW6s7nsU+aI/XLVW02bxp
Nqb6qkZAVuyvpLRxi6UXDIINR00jb06+ijaz21fLn0F3G0KNQXDPmKi+jcC6zX1P
rB6pJsbfJQYGfkZ0pdF12q+WzFwq1CQbJ4fFlK6WDtKxzoo4XKjlFHwByEPU4yKU
GgyEGX+OD0hIh6nzPyC5pR1iXBLC25f9rsqrlOL+S4sN2MXYLZlHUuBgqN0dOoqH
MN4r5WaaDBQVhadMmi8PScZm3iFMwdjFro7ry4FOuqB5uH6cV6oLIpfzP6F9cTQ2
AUKiL1z6m5VdzsTbtJN0LwqvbILECClcrXJK1OCDL/Uzj04uqCL/+r88mVdjswAJ
lacktHZzF+oPoY2oDDgMAPZTuPlr6nM2D4LETVYpSpUZIGWlJsDmNF/Fe7MAcAo6
ZoC16FSYDTDpEIwXmNzEgWRMn0400DLmdLaS+zO5Sr2h3EI793qVok8Q44yE2Tg8
Um7AdcpBhPzinbXK/OZMoj0YwcBmQDwo4Srdz1hxABc2VG+siCUu1NbwDa3qU+Tx
8Spi1d3Wpnbv2Vuw+1oNnD79EsH1Q3ookRoQTn9B3GDsr7FWs+WZAlSDQERRe+nR
84qswLpAWIC63Geqr3pH4Trsxaa+ge4RX66J8u6vIGYGaxsKJWblqsj02o19Y+O0
hu9eG7FK+q7/+7NR7cj5
=mRkw
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Slow HTTP Rquest via Tomcat

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 1/14/15 3:27 PM, Mark Thomas wrote:
> On 14/01/2015 18:56, Christopher Schultz wrote:
> 
>> Possibly.
>> 
>> I re-read the log file, and there are no logs that actually say
>> that the context is reloading. It just says "checking
>> context[/path] reload resource" over and over again. I checked,
>> and Tomcat does not emit any log messages that look like that...
>> this must come from somewhere else.
> 
> Nope. Look again at the debug logging in
> 
> org.apache.cataline.startup.HostConfig.checkResources()

Ah. Not all on one line. Stupid mistake while grepping. I even checked
both .java and .properties files.

>> so I'm not sure what I'm looking at. What I can tell is that
>> some component is furiously checking "reload resources" during
>> the time period covered by that log file.
> 
> Furiously? Look at the timestamps. This is taking milliseconds at
> most. This is normal behaviour.

I saw the "Checking context" message many times for the
"ps_9.0_8.53.11" context and thought it was happening over and over
again. It seems there are many version of the "ps" webapp deployed
simultaneously and I was assuming they were the same. Thus, furiously.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJUtth3AAoJEBzwKT+lPKRYafgP/2PX5GtW9hXnOjY4h4w5gVxu
lk98RkyLLtX5nEeogeLjtDru3hRc2JsSX4v1ThMBPgk8g9qVxdf6yI6Tq6R1qiSN
eiBcy21WYTRQtPbg3NxakmK8jEqx15X0hOZtI7zTTIW4ITwa13MpBd+WrFFEIvwy
YkmPGRu3jI6s2HEwPjufLnpMAM8q6uF7QU41H9veD0VecDMKGrIMJDtLfc7jm+Op
eh95GMpHxZSogLCBrtt5P2YmFwctq5cjE4FyFpMnRES7Klc2zUPLxhZNBGCwLZxN
JueadGu1v4LQ5EZQ3NlY/YmA1lRFAfjKqvHE215vTY2nIeRhkr0gu3J/SH/tP9Xy
0dKz4Hb6cKbxmdjeJSsGOOu+PDiHpx6KQ4B2wWxhD2ATTxj4EYY3Cg3cRVcK1yng
OLuz2C1xMfbqNVFFQgHPg92tJedMDLnd5MyaLWg1gyp532naw5fTEJa30udrdL4H
gPvSiksLgNfCSTCWw743PajtMdcsmfs45eNtruelmLYD0yNjbXEKclzeSSHqW+xY
gZ7rCMUWOlXKvi5+Gs8ScIre6wac692Dl7VXOVGKT/jNQBW/orgWsXTov8GOag+l
GvzQX1CbkLuyxpiAL2c2ReoypaBdrc5+5v0ycWPUzQLE7Da4TII5sTdT/y85lOH1
AikKHDEgI70fUUQYky7f
=/Sky
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Web filter to forward some requests to another remote webserver

[Jose María Zaragoza]

2015-01-14 20:05 GMT+01:00 Christopher Schultz :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Jose,
>
> On 1/14/15 8:27 AM, Jose María Zaragoza wrote:
>> 2015-01-14 12:46 GMT+01:00 André Warnier :
>>> Jose María Zaragoza wrote:

 Hello:

 I would like to create a web filter to forward some requests
 to another webserver,

 The filter receives an "application/x-www-form-urlencoded"
 request , inspects the value of a parameter and chooses to
 forward to another remote webserver ( as a proxy )
>>
>>
>> Thanks
>>
>> I agree with you . I'll try to use an Apache httpd front-end
>>
>> Anyway, I've seen that if I execute
>>
>> Map parameter = ((HttpServletRequest)
>> request).getParameterMap();
>>
>> , then request.getInputStream is empty
>>
>>
>> But if I execute
>>
>> Map parameter = ((HttpServletRequest)
>> request).getParameterMap(); chain.doFilter(request, response);
>>
>> , the next filter in the chain receives the body ( as I expect it
>> )
>>
>> I don't understand this behaviour
>
> I think that might be a bug... calling
> HttpServletRequest.getParameter* should cause the request entity to be
> parsed, as long as the content type is
> application/x-www-form-urlencoded. I think getParameterMap counts, but
> I'd have to review the spec & javadoc (where some fun spec
> requirements are hidden!).
>
> Anyhow, when you call HttpServletRequest.getParameter*, the container
> *must* consume the request, according to the spec.


Thanks.

In my case, all requests to be forwarded are POST requests  ( and
content type is application/x-www-form-urlencoded )
According to your reply, if I've got a chain of filters and the first
one calls getParameterMap , do the next filters lose the content of
the payload ?

I tested to call several times to getParameterMap method on the same
webfilter and it always returned the right values.
Looks like getParameterMap doesn't consume() payload, but ... if I
call getInputStream() after getParameterMap() , the stream is empty

I'm using Tomcat 7.0.50 and I cannot understand the logic of this


Regards


 If you want to
> pull-in the request entity, you'll have to read it yourself using
> HttpServletRequest.getInputStream / HttpServletRequest.getReader. That
> means parsing it yourself, buffering it yourself, etc. You also get to
> wrap the request and re-supply the buffered request to the local web
> application should you choose to process it locally instead of proxy
> it remotely.
>
> Also note that Tomcat supplies some response headers itself that
> cannot be overridden, so you can't be a completely-transparent reverse
> proxy. Keep that in mind if you decide to go down this road...
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJUtr3zAAoJEBzwKT+lPKRYDzkP/1XM5y72x41YBG56xgcvzsV6
> wQ1S5TLuEvzPGPBAR7sFWv+qCeZecIJ9WvkBTgaKiPm4Dn8rxLCvf34yaNTsHg7P
> D0POXQrON36lZmUfg9utIySv4L0Y88MCFpdEkJr38ENTOK7bhAGsNK6kITeR2rXJ
> z8XOOmMVgMYSGKqbUK3gbBKpifdr0fuSobcDPnJkOv751e63/jMzf0IBI2z3tQhe
> xsXEd3JaCjguzOIXBCgbXaZUxEk3EgBjHm3xlHX1GEYSIwr/PHqyTtK4a82r25Ny
> dhWbMsQc8hV018helpTVPj9ae0IUQXaDTsP+aXgXOwrzKXu1pLpMGeXjery54uwY
> gJG32tMfNKLVikiq5xIKBHObzplei/jHjDn66w9Z0W3SZiGhtg9xDynpgqFPxKHY
> iv/m5bwO0jPEUU7Yq99uu+jMwfJJDIWtWSKKrQ3IzmxJ6uNsiPhKX2jfTUn3wJ19
> 9q9ur/fER9nB9q4GAjUUVVe07Z4NH9ofPvXTKJExklpH64nCx99zmBYqXcLdsaxb
> 2uGJcl6bu7sKWm0GzL7+kSnvFhOfkfM9mDoVgNbxKyJEHRcurA91PL2DguEOuUtV
> g9pXrY+Sfd2siq2K1O1TX7wPOebNc/HFIWPux6rtGXB8/pc3XPhaM2UwlxpHfLzp
> YyN10GOrc+HacHHbtwHs
> =vczy
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Slow HTTP Rquest via Tomcat

[Mark Thomas]

On 14/01/2015 20:46, André Warnier wrote:
> Mark Thomas wrote:
>> On 14/01/2015 18:56, Christopher Schultz wrote:
>>
>>> Possibly.
>>>
>>> I re-read the log file, and there are no logs that actually say that
>>> the context is reloading. It just says "checking context[/path] reload
>>> resource" over and over again. I checked, and Tomcat does not emit any
>>> log messages that look like that... this must come from somewhere else.
>>
>> Nope. Look again at the debug logging in
>>
>> org.apache.cataline.startup.HostConfig.checkResources()
>>
>>
>>> so I'm not sure what I'm looking at. What I can tell is that some
>>> component is furiously checking "reload resources" during the time
>>> period covered by that log file.
>>
>> Furiously? Look at the timestamps. This is taking milliseconds at most.
>> This is normal behaviour.
>>
>>> I would check the /Tomcat/ log during the same period to see if
>>> anything is happening, there.
>>
>> GC logging should rule that out as a factor.
>>
> 
> So a log message like :
> 
> 2015-01-12 16:11:07,390 DEBUG Checking context[/ps_9.0_8.53.02_1]
> redeploy resource /usr/local/tomcat-instance5/webapps/ps_9.0_8.53.02_1.war
> 
> only means that Tomcat is checking /if/ that resource has been changed,
> not that it is actually redeploying it ?

Correct. There are both redeploy resources and reload resources. Most
web applications have several of both. If autoDeploy is enabled they are
checked every ~15s by default.

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Catalina INFO: Encountered a non-recycled request and recycled it forcedly

[Sean Dawson]

I am - could try to simplify up a testcase and see if it always happens.

Thanks.


On Wed, Jan 14, 2015 at 3:40 PM, Mark Thomas  wrote:

> On 14/01/2015 20:06, Sean Dawson wrote:
> > I'm seeing this...
> >
> > Jan 14, 2015 2:56:32 PM org.apache.catalina.connector.CoyoteAdapter
> > checkRecycled
> > INFO: Encountered a non-recycled request and recycled it forcedly.
> > org.apache.catalina.connector.CoyoteAdapter$RecycleRequiredException
> >  at
> >
> org.apache.catalina.connector.CoyoteAdapter.checkRecycled(CoyoteAdapter.java:590)
> >  at
> >
> org.apache.coyote.http11.AbstractHttp11Processor.recycle(AbstractHttp11Processor.java:1792)
> >  at
> >
> org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.release(Http11AprProtocol.java:245)
> >  at
> >
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:694)
> >  at
> >
> org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.doRun(AprEndpoint.java:2466)
> >  at
> >
> org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:2455)
> >  at
> >
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> >  at
> >
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> >  at
> >
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> >  at java.lang.Thread.run(Thread.java:745)
> >
> > which looks similar to...
> >
> > https://issues.apache.org/bugzilla/show_bug.cgi?id=57011
> >
> > The thing is, I'm using 7.0.57 (on Windows64).
>
> There are lots of edge cases in the connector code, particularly around
> async so I'm not entirely surprised you have found one that isn't
> handled correctly.
>
> Are you able to reproduce this reliably? If yes, it should be a
> relatively easy fix.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Slow HTTP Rquest via Tomcat

[André Warnier]

Mark Thomas wrote:

On 14/01/2015 18:56, Christopher Schultz wrote:


Possibly.

I re-read the log file, and there are no logs that actually say that
the context is reloading. It just says "checking context[/path] reload
resource" over and over again. I checked, and Tomcat does not emit any
log messages that look like that... this must come from somewhere else.


Nope. Look again at the debug logging in

org.apache.cataline.startup.HostConfig.checkResources()



so I'm not sure what I'm looking at. What I can tell is that some
component is furiously checking "reload resources" during the time
period covered by that log file.


Furiously? Look at the timestamps. This is taking milliseconds at most.
This is normal behaviour.


I would check the /Tomcat/ log during the same period to see if
anything is happening, there.


GC logging should rule that out as a factor.



So a log message like :

2015-01-12 16:11:07,390 DEBUG Checking context[/ps_9.0_8.53.02_1] redeploy resource 
/usr/local/tomcat-instance5/webapps/ps_9.0_8.53.02_1.war


only means that Tomcat is checking /if/ that resource has been changed, not that it is 
actually redeploying it ?




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Catalina INFO: Encountered a non-recycled request and recycled it forcedly

[Mark Thomas]

On 14/01/2015 20:06, Sean Dawson wrote:
> I'm seeing this...
> 
> Jan 14, 2015 2:56:32 PM org.apache.catalina.connector.CoyoteAdapter
> checkRecycled
> INFO: Encountered a non-recycled request and recycled it forcedly.
> org.apache.catalina.connector.CoyoteAdapter$RecycleRequiredException
>  at
> org.apache.catalina.connector.CoyoteAdapter.checkRecycled(CoyoteAdapter.java:590)
>  at
> org.apache.coyote.http11.AbstractHttp11Processor.recycle(AbstractHttp11Processor.java:1792)
>  at
> org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.release(Http11AprProtocol.java:245)
>  at
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:694)
>  at
> org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.doRun(AprEndpoint.java:2466)
>  at
> org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:2455)
>  at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>  at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>  at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
>  at java.lang.Thread.run(Thread.java:745)
> 
> which looks similar to...
> 
> https://issues.apache.org/bugzilla/show_bug.cgi?id=57011
> 
> The thing is, I'm using 7.0.57 (on Windows64).

There are lots of edge cases in the connector code, particularly around
async so I'm not entirely surprised you have found one that isn't
handled correctly.

Are you able to reproduce this reliably? If yes, it should be a
relatively easy fix.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Undeploy Error

[Mark Thomas]

On 14/01/2015 19:55, Mike Seda wrote:
> 
> On 01/04/2015 11:13 AM, Mark Thomas wrote:
>> On 03/01/2015 02:25, Mike Seda wrote:
>>> On 01/01/2015 09:35 AM, Mark Thomas wrote:
 On 31/12/2014 22:38, Mike Seda wrote:

> Please let us know what you think.
 The information you provided doesn't add up.

 CATALINA_BASE:   /usr/local/tomcat
 
 -Dwebapp.path=/srv/tomcat/webapps/$1/
>>> /usr/local/tomcat/webapps is a symlink to /srv/tomcat/webapps.
>> OK. Assuming those are both local file systems then that should work.
>> That it works most of the time suggests that the symlink isn't the issue
>> (although a non-local file system might be).
> 
> Both file-systems are local.

OK. I think we can rule that out for now then.

>> When undeployment fails, is the application still usable by clients?
> 
> No.

I'm assuming that the app works up to the point where you try to
undeploy it, then it stops working (as if it was undeployed) but you get
the error that the undeploy failed.

Is this correct?

Is it possible that the undeploy might be being triggered twice? It
would be worth checking the access logs for requests to the Manager app.

>> The deployer uses JMX. The next step would be to connect a JMX client
>> and see if the deployed applications listed match what you expect when
>> you see one of these intermittent issues.
> 
> The intermittent issue has not re-occurred yet.

OK. The access logs (if you have them) are likely to be the best avenue
of investigation until then,

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Slow HTTP Rquest via Tomcat

[Mark Thomas]

On 14/01/2015 18:56, Christopher Schultz wrote:

> Possibly.
> 
> I re-read the log file, and there are no logs that actually say that
> the context is reloading. It just says "checking context[/path] reload
> resource" over and over again. I checked, and Tomcat does not emit any
> log messages that look like that... this must come from somewhere else.

Nope. Look again at the debug logging in

org.apache.cataline.startup.HostConfig.checkResources()


> so I'm not sure what I'm looking at. What I can tell is that some
> component is furiously checking "reload resources" during the time
> period covered by that log file.

Furiously? Look at the timestamps. This is taking milliseconds at most.
This is normal behaviour.

> I would check the /Tomcat/ log during the same period to see if
> anything is happening, there.

GC logging should rule that out as a factor.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Catalina INFO: Encountered a non-recycled request and recycled it forcedly

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Sean,

On 1/14/15 3:06 PM, Sean Dawson wrote:
> I'm seeing this...
> 
> Jan 14, 2015 2:56:32 PM
> org.apache.catalina.connector.CoyoteAdapter checkRecycled INFO:
> Encountered a non-recycled request and recycled it forcedly. 
> org.apache.catalina.connector.CoyoteAdapter$RecycleRequiredException
>
> 
at
> org.apache.catalina.connector.CoyoteAdapter.checkRecycled(CoyoteAdapter.java:590)
>
> 
at
> org.apache.coyote.http11.AbstractHttp11Processor.recycle(AbstractHttp11Processor.java:1792)
>
> 
at
> org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.release(Http11AprProtocol.java:245)
>
> 
at
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:694)
>
> 
at
> org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.doRun(AprEndpoint.java:2466)
>
> 
at
> org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:2455)
>
> 
at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>
> 
at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>
> 
at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
>
> 
at java.lang.Thread.run(Thread.java:745)
> 
> which looks similar to...
> 
> https://issues.apache.org/bugzilla/show_bug.cgi?id=57011
> 
> The thing is, I'm using 7.0.57 (on Windows64).

Interesting. Are you using servlet async?

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJUts7OAAoJEBzwKT+lPKRYANMP/31Sg7xmrg0t3UPeTQ2FCd80
XEjgaZNWSPZujLpLLoi9t3VRZIhAsccZCU58wzu46pyCNhA39+ypaJ/TX+ib+xxv
ihs9MY9S7k8KzZgQLWeLtdwr/ZYap4hxx9khJWFgOW/OaxEHkz6XoWfEDcWzG7zr
Ws2bwcNOxGyo/iJHIHOdD6+64mzR4gK2u+kXwZG9Am1X4hj+yj5QmhSlCqDOgAkm
RcW/3ejEwxruBQsx3IiEXqUTxJZu+9MaRnnXGd3rDlXiVeL30lckXEbvduP2lkDq
u2OOMrYCNBjTSAX4/RCz+hBGCsGUC+jstV1rBrWFaCD9pDkeeYUfic2S7SNRITqZ
JtsZYNxPOc/WBJk8CQ74Vryris1/yeBIik2kFF6FSWP6lfk12/OoPlt3RH/4ljwJ
Ad4P5mDK1hqW36kToMBdefIkZlLJ3+xC7hdo0cyImLh1BarHuNKMdU2UQm7/FkOf
FwT0Ij7nsoV9NkaLoioAN9kgmFe58vb84/NRU3/FZlVcIIAK+OMe2NWrj/dwgym+
lgjzCYdOLeFVAIA7pYiUdbN5/WGP2N5iQlUPSBTZ179YE8d2Ve2/MiobbhGFYYDU
8XrQB89VbnEHS+9n4pVMlyXs+uWNlYDDjhy+W4GNSK8mpWaSG+wOK6dNe02l4Qyj
GcUlneyHpdwzRqVV7hgs
=sLQt
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Is there a way to abruptly force a connection closed without returning anything?

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

André,

On 1/14/15 3:05 PM, André Warnier wrote:
> Christopher Schultz wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>> 
>> André,
>> 
>> On 1/14/15 5:56 AM, André Warnier wrote:
>>> Christopher Schultz wrote:
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
 
 Jesse,
 
 On 1/13/15 6:29 PM, Jesse Barnum wrote:
> I need the ability to examine the POST data from a request,
> examine it, and either respond to it or close the
> connection without returning any result, not even a 200 OK
> status.
> 
> The reason for this is because I’m getting overwhelmed
> with thousands of invalid requests per second, which are
> racking up bandwidth fees. The requests can’t be traced to
> an IP address, so I can’t just block them in a firewall or
> Apache - I need to actually use logic in my Tomcat app to
> figure out which requests to respond to.
> 
> Is there a way to force Tomcat to just drop the connection
> and close the socket without sending a response?
 You can't close the stream form your code, Tomcat will ignore
 it, so a response flush, and return a 200 response anyway.
 
 I'm curious, what's wrong with an empty 200 response? It's
 only a couple of bytes, but I suppose if you are getting
 millions per hous, you could still incur bandwidth costs...
 
 You might be able to do this with a Valve, but then you
 might have problems with your web application needing to
 provide the logic to determine whether or not to accept the
 request.
 
 When you say "can't be traced to an IP address" do you mean
 that you are seeing invalid requests coming from all over the
 place, or that the requests don't include a source IP address
 (which seems fishy)?
 
 A few options that might achieve your goal without using the 
 technique you describe:
 
 1. Use client authentication; unauthorized clients can't
 even handshake Downsides: SSL overhead
 
 2. Use a VPN (which essentially uses client authentication) 
 Downsides: VPNs really, really suck
 
 3. (As Mark E suggests) Use mod_security with httpd I know
 this will seriously separate your business logic form your
 web application, but perhaps there is a simple set of
 criteria that might eliminate a significant portion of the
 requests, thus solving the problem "well enough"
 
>>> I have an additional suggestion, harking back to a time when I
>>> was trying to convince the Apache httpd devs to implement
>>> something like this in .. Apache httpd. By experience with
>>> trying to convince people, I know that this is controversial,
>>> so hold on tightly and follow the gist.  You can always decide
>>> by yourself if this is appropriate for your case.
>>> 
>>> The idea is this : when you get such a request, and you decide
>>> that it is invalid, return a 404 "not found", but delay it by
>>> some random number of seconds. (do a random sleep in your
>>> webapp, or in a filter after the webapp).
>> 
>> This is essentially a reverse slowloris attack against the
>> client. The major problem is that it ties up resources on the
>> server, which is the whole problem you are trying to solve in the
>> first place. In theory, it's a good idea, but in practice, you
>> are using system resources to .. avoid using system resources.
>> I'm not sure if the curve is linear (your suggestion may be
>> "cheaper" than simply doing nothing), but it's certainly not a
>> free lunch.
>> 
>>> The short-term hope is that if attackers notic that your
>>> website is such a "sink", they may just take it out of their
>>> list of targets, so as not to slow down their whole nefarious
>>> scheme.
>> 
>> This is the club[0] effect: your server is marginally more of a
>> pain in the neck than someone else's, so they ignore you and
>> attack others.
>> 
> 
> Yes, exactly. And think about it : if this was a default (but
> optional) feature of Tomcat in general, then after a sufficient
> while (e.g. the time for a significant portion of Tomcat sites to
> upgrade to the newest release), the miscreants may notice that most
> Tomcat servers are such pains in the a.., and start avoiding them
> altogether. Seen from a Tomcat point of view, wouldn't that be nice
> ?
> 
> And (one can dream) imagine that most mainstream webservers were
> to adopt a similar scheme over time, then the general method of
> blindly scanning a lot of IPs for weak webservers would cease to be
> practical, and would be abandoned, to the general benefit of all
> the Internet.
> 
> The default (but optional) feature in question would be : any 404
> (not found) or 401 (forbidden) response is delayed by a random
> number of seconds (say between 1 and 100). Enough to bother the
> miscreants and make their scanning uneconomical, but low enough so
> that it is impossible for said miscreants to know whet

Re: Can't make SSL work on Tomcat7 on Ubuntu Server 14.04

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Alexandre,

On 1/14/15 2:15 PM, Alexandre Lima wrote:
> On 14 January 2015 at 15:59, Christopher Schultz < 
> ch...@christopherschultz.net> wrote:
> 
> Alexandre,
> 
> On 1/14/15 1:18 PM, Alexandre Lima wrote:
 On 13 January 2015 at 18:20, Christopher Schultz < 
 ch...@christopherschultz.net> wrote:
 
 Alexandre,
 
 On 1/13/15 2:41 PM, Alexandre Lima wrote:
>>> On 13 January 2015 at 16:11, Christopher Schultz < 
>>> ch...@christopherschultz.net> wrote:
>>> 
>>> Alexandre,
>>> 
>>> On 1/13/15 1:37 PM, Alexandre Lima wrote:
>> Hello! This is the first time I'm using tomcat,
>> so I'm a little bit lost...
>>> 
>>> Welcome! Configuring SSL always turns out to be a pain
>>> in the neck.
>>> 
>> Using the tutorials, I could make the server and
>> the application I want to run with it work. The
>> only modification I did until now was changing
>> the http port from 8080 to 80, I did that
>> changing the http conector on servers.xml,
>> enabling authbind and executing the folowing
>> commands:
>> 
>> sudo touch /etc/authbind/byport/80 sudo chmod
>> 500 /etc/authbind/byport/80 sudo chown tomcat7 
>> /etc/authbind/byport/80
>> 
>> So, the server and the application I want to use
>> with it are actually working on port 80
>>> 
>>> You've confirmed this? I've never used authbind before,
>>> so I just wanted to make sure that you have Tomcat
>>> working properly with non-SSL before you try to add
>>> SSL.
>>> 
>> , but the next and last step, which is enabling
>> an SSL connection, isn't working.
>> 
>> What I did following the site's tutorial was:
>> created my self signed certificate with keytools
>> and put it on /home/myuser/key.keystore
>>> 
>>> Can you outline the steps you took? Where is your
>>> keystore?
>>> 
>> Additionally, I've created the folowing
>> conector:
>> 
>> > protocol="org.apache.coyote.http11.Http11Protocol"
>>
>> 
SSLEnabled="true" maxThreads="200" scheme="https"
>> secure="true"
>> keystoreFile="/home/myuser/key.keystore" 
>> keystorePass="mypass" clientAuth="false" 
>> sslProtocol="TLS" />
>>> 
>>> That looks good so far.
>>> 
>> Saved it, restarted server and accessed 
>> https://myip:8443, but it isn't working. Chrome
>> says "No data recieved" and "Unable to load the
>> webpage because the server sent no data and
>> "Error code: ERR_EMPTY_RESPONSE".
>> 
>> Firefox says that the connection was reset while
>> the page was being loaded.
>> 
>> That's where I am now. I don't know what to try 
>> anymore.
>>> 
>>> Try:
>>> 
>>> $ telnet localhost 8443
>>> 
>>> (on the server with Tomcat running)
>>> 
>>> That will tell you if the port is open (it should be, 
>>> otherwise you'd be getting different errors from Chrome
>>> and ff) and what, if anything, gets dumped to it when
>>> you connect.
>>> 
>>> If you get a connection and nothing happens, try
>>> submitting a request like this:
>>> 
>>> $ telnet localhost 8443 GET /
>>> 
>>> [output goes here]
>>> 
>>> Post the results of the above if you get anything.
>>> 
>>> Dumb question: you restarted Tomcat after updating 
>>> server.xml, right?
>>> 
>>> -chris
 
 -




>
 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: 
 users-h...@tomcat.apache.org
 
 
>>> Thank you for the reply Christopher! I've used the
>>> command: keytool -genkey -alias tomcat -keyalg RSA
>>> -keystore /home/myuser/key.keystore to generate the
>>> keystore. I should put the keystore in some special
>>> directory or this one is fine? So, after, requesting:
>>> telnet localhost 8443
>>> 
>>> I got some strange stuff:
>>> 
>>> ~$ telnet localhost 8443 Trying ::1... Connected to 
>>> localhost. Escape character is '^]'. GET /
>>> ^U^C^A^@^B^B
>>> 
>>> 
>>> 
>>> And yes, I've restarted it :)
 
 Good. Now, try this:
 
 $ openssl s_client -debug -connect localhost:8443
 
 Assuming that the server is running and listening for SSL 
 connections, s_client should be able to connect, and it
 should give you tons of good information about what's
 happening, there.
 
 -chris
> 
> -
>
>
>
> 
To unsu

Re: Is there a way to abruptly force a connection closed without returning anything?

[André Warnier]

Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

André,

On 1/14/15 5:56 AM, André Warnier wrote:

Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256

Jesse,

On 1/13/15 6:29 PM, Jesse Barnum wrote:
I need the ability to examine the POST data from a request, 
examine it, and either respond to it or close the connection 
without returning any result, not even a 200 OK status.


The reason for this is because I’m getting overwhelmed with 
thousands of invalid requests per second, which are racking up 
bandwidth fees. The requests can’t be traced to an IP address,

so I can’t just block them in a firewall or Apache - I need to
actually use logic in my Tomcat app to figure out which
requests to respond to.

Is there a way to force Tomcat to just drop the connection and 
close the socket without sending a response?

You can't close the stream form your code, Tomcat will ignore it,
so a response flush, and return a 200 response anyway.

I'm curious, what's wrong with an empty 200 response? It's only
a couple of bytes, but I suppose if you are getting millions per
hous, you could still incur bandwidth costs...

You might be able to do this with a Valve, but then you might
have problems with your web application needing to provide the
logic to determine whether or not to accept the request.

When you say "can't be traced to an IP address" do you mean that
you are seeing invalid requests coming from all over the place,
or that the requests don't include a source IP address (which
seems fishy)?

A few options that might achieve your goal without using the
technique you describe:

1. Use client authentication; unauthorized clients can't even
handshake Downsides: SSL overhead

2. Use a VPN (which essentially uses client authentication) 
Downsides: VPNs really, really suck


3. (As Mark E suggests) Use mod_security with httpd I know this
will seriously separate your business logic form your web
application, but perhaps there is a simple set of criteria that 
might eliminate a significant portion of the requests, thus

solving the problem "well enough"

I have an additional suggestion, harking back to a time when I was 
trying to convince the Apache httpd devs to implement something

like this in .. Apache httpd. By experience with trying to convince
people, I know that this is controversial, so hold on tightly and
follow the gist.  You can always decide by yourself if this is
appropriate for your case.

The idea is this : when you get such a request, and you decide that
it is invalid, return a 404 "not found", but delay it by some
random number of seconds. (do a random sleep in your webapp, or in
a filter after the webapp).


This is essentially a reverse slowloris attack against the client. The
major problem is that it ties up resources on the server, which is the
whole problem you are trying to solve in the first place. In theory,
it's a good idea, but in practice, you are using system resources to
.. avoid using system resources. I'm not sure if the curve is linear
(your suggestion may be "cheaper" than simply doing nothing), but it's
certainly not a free lunch.


The short-term hope is that if attackers notic that your website is
such a "sink", they may just take it out of their list of targets,
so as not to slow down their whole nefarious scheme.


This is the club[0] effect: your server is marginally more of a pain
in the neck than someone else's, so they ignore you and attack others.



Yes, exactly.
And think about it : if this was a default (but optional) feature of Tomcat in general, 
then after a sufficient while (e.g. the time for a significant portion of Tomcat sites to 
upgrade to the newest release), the miscreants may notice that most Tomcat servers are 
such pains in the a.., and start avoiding them altogether.

Seen from a Tomcat point of view, wouldn't that be nice ?

And (one can dream) imagine that most mainstream webservers were to adopt a similar scheme 
over time, then the general method of blindly scanning a lot of IPs for weak webservers 
would cease to be practical, and would be abandoned, to the general benefit of all the 
Internet.


The default (but optional) feature in question would be : any 404 (not found) or 401 
(forbidden) response is delayed by a random number of seconds (say between 1 and 100).
Enough to bother the miscreants and make their scanning uneconomical, but low enough so 
that it is impossible for said miscreants to know whether this is intentional, or just a 
slow server.


Although I am incapable of designing this myself, I believe that there must exist a way to 
create a mechanism in Tomcat to apply this scheme at low resource cost to the server.
For example : as soon as it is known that the response to a request is 401 or 404, 
actually sending out that response after the random delay could be forked out to some 
separate pool of lightweight specialised threads, and the heavy thread handling the webapp 
could be re

Catalina INFO: Encountered a non-recycled request and recycled it forcedly

[Sean Dawson]

I'm seeing this...

Jan 14, 2015 2:56:32 PM org.apache.catalina.connector.CoyoteAdapter
checkRecycled
INFO: Encountered a non-recycled request and recycled it forcedly.
org.apache.catalina.connector.CoyoteAdapter$RecycleRequiredException
 at
org.apache.catalina.connector.CoyoteAdapter.checkRecycled(CoyoteAdapter.java:590)
 at
org.apache.coyote.http11.AbstractHttp11Processor.recycle(AbstractHttp11Processor.java:1792)
 at
org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.release(Http11AprProtocol.java:245)
 at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:694)
 at
org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.doRun(AprEndpoint.java:2466)
 at
org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:2455)
 at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
 at java.lang.Thread.run(Thread.java:745)

which looks similar to...

https://issues.apache.org/bugzilla/show_bug.cgi?id=57011

The thing is, I'm using 7.0.57 (on Windows64).

Re: Undeploy Error

[Mike Seda]

On 01/04/2015 11:13 AM, Mark Thomas wrote:
> On 03/01/2015 02:25, Mike Seda wrote:
>> On 01/01/2015 09:35 AM, Mark Thomas wrote:
>>> On 31/12/2014 22:38, Mike Seda wrote:
>>>
 Please let us know what you think.
>>> The information you provided doesn't add up.
>>>
>>> CATALINA_BASE:   /usr/local/tomcat
>>> 
>>> -Dwebapp.path=/srv/tomcat/webapps/$1/
>> /usr/local/tomcat/webapps is a symlink to /srv/tomcat/webapps.
> OK. Assuming those are both local file systems then that should work.
> That it works most of the time suggests that the symlink isn't the issue
> (although a non-local file system might be).

Both file-systems are local.

>
> When undeployment fails, is the application still usable by clients?

No.

>
>>> The web application path you are providing to your build.xml (which we
>>> have no way of knowing what it does)
>> /usr/local/tomcat-deployer/build.xml is the standard build.xml provided
>> in the apache-tomcat-7.0.52-deployer tarball - obtained via the
>> following link:
>> http://tomcat.apache.org/download-70.cgi
> OK.
>
> The deployer uses JMX. The next step would be to connect a JMX client
> and see if the deployed applications listed match what you expect when
> you see one of these intermittent issues.

The intermittent issue has not re-occurred yet.

>
> Is there any pattern to the names of the applications where you see this
> issue?

No.

> I'm just wondering if the path <-> JMX name translation is a
> factor in this.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Occasional long wait for a JDBC connection

[Filip Hanik]

The timeout happens in your SocketRead, this is configurable (default is
forever)
http://dev.mysql.com/doc/connector-j/en/connector-j-reference-configuration-properties.html

what appears to be happening is that somewhere there isn't a reset packet
sent from the server to the JDBC driver. Setting a timeout may alleviate
this. This property is not the same as query timeout, this is simply a
timeout in between packets. but if you have long running queries, this may
affect it.

*socketTimeout*



On Wed, Jan 14, 2015 at 11:44 AM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Darren,
>
> On 1/13/15 11:32 PM, Darren Davis wrote:
> > On Tue, Jan 13, 2015 at 8:39 PM, Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> > Darren,
> >
> > (Sorry... just had to remove that monstrous stack trace...)
> >
> > On 1/13/15 5:04 PM, Darren Davis wrote:
>  Hi Christopher.  Yes, we've tried a show process list and can
>  find no evidence of the validation query running on mysql.
> >
> > Strange. Maybe you are waiting for the db server's buffer to flush
> > or something like that.
> >
> >
> >> I think this is because the client thinks it still has an open
> >> connection, the client net stat command shows an open connection
> >> over port 3306, at least for a few minutes after it's killed by
> >> the load balancer.  The Server loses its connection in netstat
> >> immediately.
> >
> >
>  We also just tried an experiment outside of Tomcat
>  completely, but connecting to a downed web server host and
>  manually opening up a mysql client connection to the data
>  server and executing a single command.
> 
>  We left that client window idle for an hour and 5 minutes,
>  and attempted to execute a simple select count(*) command
>  against a tiny table.  The client attempted to execute the
>  query, and a NetStat on that box showed an open connection
>  between the two servers using port 3306.  We also checked the
>  process list during this time and could not find any queries
>  at all from the sever in question.
> 
>  At about the 15 minute wait mark, the client finally came
>  back with this message: "ERROR 2013 (HY000): Lost connection
>  to MySQL server during query.
> >
> > Was this with the MySQL command-line client? What query did you
> > issue ("SELECT 1")?
> >
> >
> >> Yes, it was just the command line client, and we issued a select
> >> count(*) from a table with a couple rows in it.
> >
> >
>  Attempting the execute the command a 2nd time (using the up
>  arrow), re-established the connection and it ran perfectly in
>  a few milliseconds.
> >
> > That's interesting. I've never experienced anything like that with
> > MySQL, but we use a VLAN between our application and database
> > servers with no hardware firewall, so we don't have any connection
> > timeout problems. Also, when connections are dropped due to
> > inactivity, they re-connect without any problems.
> >
>  I checked the mysql configuration and it is set to the
>  default values for keeping connections/interactive
>  connections open (for 8 hours), so it seems that maybe the
>  Cisco firewall between the two servers is terminating
>  connections out from under us, but in a way what the O/S
>  cannot detect it.
> >
> > What if you set that idle connection timeout to something like 5
> > minutes? Can you reproduce this issue more quickly? Can you look
> > at the fw configuration to see if you can change the idle timeout
> > /down/ to something more testable?
> >
> > As part of our move to the new versions of Tomcat/Java, we are in a
> > new
> >> cloud environment which features a different type of firewall.
> >> The provider confirmed to us late today, that it is configured to
> >> kill "idle" TCP connections after an hour, which is something our
> >> old firewall didn't do.
> >
> >> Because we sometimes have low traffic during this time of the
> >> year, especially on the weekends, what we think is happening is
> >> that one or more of the minimum 10 connections is going unused
> >> for more than an hour, and since we didn't have any connection
> >> testing while idle turned on, they were being killed by the
> >> firewall out from under the pool, and depending on how soon they
> >> were used after that, we would run into the 15 minute delay
> >> before they were deemed lost, and replaced with a new
> >> connection.
>
> This should be entirely possible. That's the point of the
> connection-validation operation (whether done by an actual query or
> not). The question is why the connection is being dropped in a way
> that is thwarting the connection-validation at all. It may come down
> to some kind of OS-level setting, or a slightly different
> configuration on the firewall.
>
> It seems that removing the firewall's idle-connection policy would be
> an easy way to try to 

Re: Can't make SSL work on Tomcat7 on Ubuntu Server 14.04

[Alexandre Lima]

On 14 January 2015 at 15:56, Sanaullah  wrote:

> >   >  protocol="org.apache.coyote.
> http11.Http11Protocol"
> >  SSLEnabled="true" maxThreads="200" scheme="https"
> >  secure="true" keystoreFile="/home/myuser/key.keystore"
> >  keystorePass="mypass" clientAuth="false" sslProtocol="TLS"
> >  />
>
>
> May be its due to the truststore file ? I haven't seen any truststore file
> in your connector configuration
>
>
> On Wed, Jan 14, 2015 at 11:18 PM, Alexandre Lima 
> wrote:
>
> > On 13 January 2015 at 18:20, Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA256
> > >
> > > Alexandre,
> > >
> > > On 1/13/15 2:41 PM, Alexandre Lima wrote:
> > > > On 13 January 2015 at 16:11, Christopher Schultz <
> > > > ch...@christopherschultz.net> wrote:
> > > >
> > > > Alexandre,
> > > >
> > > > On 1/13/15 1:37 PM, Alexandre Lima wrote:
> > >  Hello! This is the first time I'm using tomcat, so I'm a
> > >  little bit lost...
> > > >
> > > > Welcome! Configuring SSL always turns out to be a pain in the
> > > > neck.
> > > >
> > >  Using the tutorials, I could make the server and the
> > >  application I want to run with it work. The only modification
> > >  I did until now was changing the http port from 8080 to 80, I
> > >  did that changing the http conector on servers.xml, enabling
> > >  authbind and executing the folowing commands:
> > > 
> > >  sudo touch /etc/authbind/byport/80 sudo chmod 500
> > >  /etc/authbind/byport/80 sudo chown tomcat7
> > >  /etc/authbind/byport/80
> > > 
> > >  So, the server and the application I want to use with it are
> > >  actually working on port 80
> > > >
> > > > You've confirmed this? I've never used authbind before, so I just
> > > > wanted to make sure that you have Tomcat working properly with
> > > > non-SSL before you try to add SSL.
> > > >
> > >  , but the next and last step, which is enabling an SSL
> > >  connection, isn't working.
> > > 
> > >  What I did following the site's tutorial was: created my
> > >  self signed certificate with keytools and put it on
> > >  /home/myuser/key.keystore
> > > >
> > > > Can you outline the steps you took? Where is your keystore?
> > > >
> > >  Additionally, I've created the folowing conector:
> > > 
> > >   > >  protocol="org.apache.coyote.http11.Http11Protocol"
> > >  SSLEnabled="true" maxThreads="200" scheme="https"
> > >  secure="true" keystoreFile="/home/myuser/key.keystore"
> > >  keystorePass="mypass" clientAuth="false" sslProtocol="TLS"
> > >  />
> > > >
> > > > That looks good so far.
> > > >
> > >  Saved it, restarted server and accessed https://myip:8443,
> > >  but it isn't working. Chrome says "No data recieved" and
> > >  "Unable to load the webpage because the server sent no data
> > >  and "Error code: ERR_EMPTY_RESPONSE".
> > > 
> > >  Firefox says that the connection was reset while the page was
> > >  being loaded.
> > > 
> > >  That's where I am now. I don't know what to try anymore.
> > > >
> > > > Try:
> > > >
> > > > $ telnet localhost 8443
> > > >
> > > > (on the server with Tomcat running)
> > > >
> > > > That will tell you if the port is open (it should be, otherwise
> > > > you'd be getting different errors from Chrome and ff) and what, if
> > > > anything, gets dumped to it when you connect.
> > > >
> > > > If you get a connection and nothing happens, try submitting a
> > > > request like this:
> > > >
> > > > $ telnet localhost 8443 GET /
> > > >
> > > > [output goes here]
> > > >
> > > > Post the results of the above if you get anything.
> > > >
> > > > Dumb question: you restarted Tomcat after updating server.xml,
> > > > right?
> > > >
> > > > -chris
> > > >>
> > > >>
> -
> > > >>
> > > >>
> > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > > >> For additional commands, e-mail: users-h...@tomcat.apache.org
> > > >>
> > > >>
> > > > Thank you for the reply Christopher! I've used the command: keytool
> > > > -genkey -alias tomcat -keyalg RSA -keystore
> > > > /home/myuser/key.keystore to generate the keystore. I should put
> > > > the keystore in some special directory or this one is fine? So,
> > > > after, requesting:   telnet localhost 8443
> > > >
> > > > I got some strange stuff:
> > > >
> > > > ~$ telnet localhost 8443 Trying ::1... Connected to localhost.
> > > > Escape character is '^]'. GET / ^U^C^A^@^B^B
> > > >
> > > >
> > > >
> > > > And yes, I've restarted it :)
> > >
> > > Good. Now, try this:
> > >
> > > $ openssl s_client -debug -connect localhost:8443
> > >
> > > Assuming that the server is running and listening for SSL connections,
> > > s_client should be able to connect, and it should give you tons of
> > > good information about what's happening, there.
> > >
> >

Re: Can't make SSL work on Tomcat7 on Ubuntu Server 14.04

[Alexandre Lima]

On 14 January 2015 at 15:59, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Alexandre,
>
> On 1/14/15 1:18 PM, Alexandre Lima wrote:
> > On 13 January 2015 at 18:20, Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> > Alexandre,
> >
> > On 1/13/15 2:41 PM, Alexandre Lima wrote:
>  On 13 January 2015 at 16:11, Christopher Schultz <
>  ch...@christopherschultz.net> wrote:
> 
>  Alexandre,
> 
>  On 1/13/15 1:37 PM, Alexandre Lima wrote:
> >>> Hello! This is the first time I'm using tomcat, so I'm
> >>> a little bit lost...
> 
>  Welcome! Configuring SSL always turns out to be a pain in
>  the neck.
> 
> >>> Using the tutorials, I could make the server and the
> >>> application I want to run with it work. The only
> >>> modification I did until now was changing the http port
> >>> from 8080 to 80, I did that changing the http conector
> >>> on servers.xml, enabling authbind and executing the
> >>> folowing commands:
> >>>
> >>> sudo touch /etc/authbind/byport/80 sudo chmod 500
> >>> /etc/authbind/byport/80 sudo chown tomcat7
> >>> /etc/authbind/byport/80
> >>>
> >>> So, the server and the application I want to use with
> >>> it are actually working on port 80
> 
>  You've confirmed this? I've never used authbind before, so I
>  just wanted to make sure that you have Tomcat working
>  properly with non-SSL before you try to add SSL.
> 
> >>> , but the next and last step, which is enabling an SSL
> >>> connection, isn't working.
> >>>
> >>> What I did following the site's tutorial was: created
> >>> my self signed certificate with keytools and put it on
> >>> /home/myuser/key.keystore
> 
>  Can you outline the steps you took? Where is your keystore?
> 
> >>> Additionally, I've created the folowing conector:
> >>>
> >>>  >>> protocol="org.apache.coyote.http11.Http11Protocol"
> >>> SSLEnabled="true" maxThreads="200" scheme="https"
> >>> secure="true" keystoreFile="/home/myuser/key.keystore"
> >>> keystorePass="mypass" clientAuth="false"
> >>> sslProtocol="TLS" />
> 
>  That looks good so far.
> 
> >>> Saved it, restarted server and accessed
> >>> https://myip:8443, but it isn't working. Chrome says
> >>> "No data recieved" and "Unable to load the webpage
> >>> because the server sent no data and "Error code:
> >>> ERR_EMPTY_RESPONSE".
> >>>
> >>> Firefox says that the connection was reset while the
> >>> page was being loaded.
> >>>
> >>> That's where I am now. I don't know what to try
> >>> anymore.
> 
>  Try:
> 
>  $ telnet localhost 8443
> 
>  (on the server with Tomcat running)
> 
>  That will tell you if the port is open (it should be,
>  otherwise you'd be getting different errors from Chrome and
>  ff) and what, if anything, gets dumped to it when you
>  connect.
> 
>  If you get a connection and nothing happens, try submitting
>  a request like this:
> 
>  $ telnet localhost 8443 GET /
> 
>  [output goes here]
> 
>  Post the results of the above if you get anything.
> 
>  Dumb question: you restarted Tomcat after updating
>  server.xml, right?
> 
>  -chris
> >
> > -
> >
> >
> >
> >
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail:
> > users-h...@tomcat.apache.org
> >
> >
>  Thank you for the reply Christopher! I've used the command:
>  keytool -genkey -alias tomcat -keyalg RSA -keystore
>  /home/myuser/key.keystore to generate the keystore. I should
>  put the keystore in some special directory or this one is
>  fine? So, after, requesting:   telnet localhost 8443
> 
>  I got some strange stuff:
> 
>  ~$ telnet localhost 8443 Trying ::1... Connected to
>  localhost. Escape character is '^]'. GET / ^U^C^A^@^B^B
> 
> 
> 
>  And yes, I've restarted it :)
> >
> > Good. Now, try this:
> >
> > $ openssl s_client -debug -connect localhost:8443
> >
> > Assuming that the server is running and listening for SSL
> > connections, s_client should be able to connect, and it should give
> > you tons of good information about what's happening, there.
> >
> > -chris
> >>
> >> -
> >>
> >>
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>
> >>
> > Hello Chris! I've tried the command you suggested and the most
> > important thing I found was this:
> >
> > subject=/C=Unknown/ST=Unknown/L=Unknown/O=SysAid/OU=Unknown/CN=Unknown
> >
> >
> issuer=/C=Unk

Re: Web filter to forward some requests to another remote webserver

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jose,

On 1/14/15 8:27 AM, Jose María Zaragoza wrote:
> 2015-01-14 12:46 GMT+01:00 André Warnier :
>> Jose María Zaragoza wrote:
>>> 
>>> Hello:
>>> 
>>> I would like to create a web filter to forward some requests
>>> to another webserver,
>>> 
>>> The filter receives an "application/x-www-form-urlencoded"
>>> request , inspects the value of a parameter and chooses to
>>> forward to another remote webserver ( as a proxy )
> 
> 
> Thanks
> 
> I agree with you . I'll try to use an Apache httpd front-end
> 
> Anyway, I've seen that if I execute
> 
> Map parameter = ((HttpServletRequest) 
> request).getParameterMap();
> 
> , then request.getInputStream is empty
> 
> 
> But if I execute
> 
> Map parameter = ((HttpServletRequest) 
> request).getParameterMap(); chain.doFilter(request, response);
> 
> , the next filter in the chain receives the body ( as I expect it
> )
> 
> I don't understand this behaviour

I think that might be a bug... calling
HttpServletRequest.getParameter* should cause the request entity to be
parsed, as long as the content type is
application/x-www-form-urlencoded. I think getParameterMap counts, but
I'd have to review the spec & javadoc (where some fun spec
requirements are hidden!).

Anyhow, when you call HttpServletRequest.getParameter*, the container
*must* consume the request, according to the spec. If you want to
pull-in the request entity, you'll have to read it yourself using
HttpServletRequest.getInputStream / HttpServletRequest.getReader. That
means parsing it yourself, buffering it yourself, etc. You also get to
wrap the request and re-supply the buffered request to the local web
application should you choose to process it locally instead of proxy
it remotely.

Also note that Tomcat supplies some response headers itself that
cannot be overridden, so you can't be a completely-transparent reverse
proxy. Keep that in mind if you decide to go down this road...

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJUtr3zAAoJEBzwKT+lPKRYDzkP/1XM5y72x41YBG56xgcvzsV6
wQ1S5TLuEvzPGPBAR7sFWv+qCeZecIJ9WvkBTgaKiPm4Dn8rxLCvf34yaNTsHg7P
D0POXQrON36lZmUfg9utIySv4L0Y88MCFpdEkJr38ENTOK7bhAGsNK6kITeR2rXJ
z8XOOmMVgMYSGKqbUK3gbBKpifdr0fuSobcDPnJkOv751e63/jMzf0IBI2z3tQhe
xsXEd3JaCjguzOIXBCgbXaZUxEk3EgBjHm3xlHX1GEYSIwr/PHqyTtK4a82r25Ny
dhWbMsQc8hV018helpTVPj9ae0IUQXaDTsP+aXgXOwrzKXu1pLpMGeXjery54uwY
gJG32tMfNKLVikiq5xIKBHObzplei/jHjDn66w9Z0W3SZiGhtg9xDynpgqFPxKHY
iv/m5bwO0jPEUU7Yq99uu+jMwfJJDIWtWSKKrQ3IzmxJ6uNsiPhKX2jfTUn3wJ19
9q9ur/fER9nB9q4GAjUUVVe07Z4NH9ofPvXTKJExklpH64nCx99zmBYqXcLdsaxb
2uGJcl6bu7sKWm0GzL7+kSnvFhOfkfM9mDoVgNbxKyJEHRcurA91PL2DguEOuUtV
g9pXrY+Sfd2siq2K1O1TX7wPOebNc/HFIWPux6rtGXB8/pc3XPhaM2UwlxpHfLzp
YyN10GOrc+HacHHbtwHs
=vczy
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Web filter to forward some requests to another remote webserver

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

André,

On 1/14/15 6:46 AM, André Warnier wrote:
> Jose María Zaragoza wrote:
>> Hello:
>> 
>> I would like to create a web filter to forward some requests to 
>> another webserver,
>> 
>> The filter receives an "application/x-www-form-urlencoded"
>> request , inspects the value of a parameter and chooses to
>> forward to another remote webserver ( as a proxy )
>> 
>> I've seen some posts where they open a HttpURLConnection to
>> remote server and send the request. This is right for me, but I'd
>> would like if there is another way ( easier ) to implement it.
>> 
> 
> Hi.
> 
> The only easier way is to do your proxying before the request even
> gets to Tomcat (e.g. via an Apache httpd front-end, which
> conditionally proxies to Tomcat or to the other webserver).  That
> is easier, because Apache httpd already has well-tested and
> widely-used proxy modules built-in.  But of course it depends on
> whether the Apache front-end would be able to test the "parameter"
> you are referring to. (It can do that kind of thing via Apache
> directives such as "SetEnvIf", and via mod_rewrite).

+1000

> For Tomcat, there is no such ready-made Proxy webapp available, so
> you have to do it yourself. That can be relatively simple or quite
> complicated, depending on what the requests are and what the
> proxied-to application is like. There was a thread on this list a
> couple of days ago which was related to a similar case.

This is not a good use of anyone's time, unless they want to start a
new medium-scale project to create a Java webapp-based reverse proxy :)

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJUtrz/AAoJEBzwKT+lPKRYHSwP/2KYaadoHmHVvz9pOD5BU6ms
hIxEIXboe7PHbonnX0fKSAZbwbw5HlT4+FlTprk2Pxs3ITnwskR10+IOwSFZUoeC
A36YaJGcj2k//qdrSdnTpaD5qtqrOb1TOb/jqtKalHDcggnSua5578cITJ5RoS/F
VbIGcowlqKQizI4tdKWDrSN6L6A221ufzgFCBay4bqUy/uxZid8TCm/axJEamB6j
sW+USeoyVWd5Z0jDUN9stJHu3DlBnGpgNClywGsGVsV0YGP9Sn/88I99d7Ovf2d8
I2K4A8RPbXViTLoZuIAO++Ve5KVpMesZKvJyakWBzH/qY1VRIKKDSG5kdzg0ixkG
5/nE1Zxso8qgGc1jCJKIg6tceJmEYWMK6+5R/iSBmRY45ATvepRkrzWmiVcyyln4
E5sg/G7GLZEIFiVGIUjwlcRIJQWEfx7huTmZgxzmzq5PZGi2kXTGy5qjAUOa3Cen
H3IharFiNO0E8LclhWccjZ3NFWs9dhuxGPukCeVjE9hrD61okXbD4fLxElmnsZUU
MFGtR2sia3uqV4XpobpWyc724lFhleufMOmfBR6+cNd3n63PE+EwuM1UdUrtbRGn
yCOJ9xbIGc+z97GKwcxF+Rd7nkNJLlIU6NbDAbZB0O2Dk+Q5ztLLHag9qOgV374i
AzQr9JxR85rris5ytnCy
=KZAI
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Can't make SSL work on Tomcat7 on Ubuntu Server 14.04

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Alexandre,

On 1/14/15 1:18 PM, Alexandre Lima wrote:
> On 13 January 2015 at 18:20, Christopher Schultz < 
> ch...@christopherschultz.net> wrote:
> 
> Alexandre,
> 
> On 1/13/15 2:41 PM, Alexandre Lima wrote:
 On 13 January 2015 at 16:11, Christopher Schultz < 
 ch...@christopherschultz.net> wrote:
 
 Alexandre,
 
 On 1/13/15 1:37 PM, Alexandre Lima wrote:
>>> Hello! This is the first time I'm using tomcat, so I'm
>>> a little bit lost...
 
 Welcome! Configuring SSL always turns out to be a pain in
 the neck.
 
>>> Using the tutorials, I could make the server and the 
>>> application I want to run with it work. The only
>>> modification I did until now was changing the http port
>>> from 8080 to 80, I did that changing the http conector
>>> on servers.xml, enabling authbind and executing the
>>> folowing commands:
>>> 
>>> sudo touch /etc/authbind/byport/80 sudo chmod 500 
>>> /etc/authbind/byport/80 sudo chown tomcat7 
>>> /etc/authbind/byport/80
>>> 
>>> So, the server and the application I want to use with
>>> it are actually working on port 80
 
 You've confirmed this? I've never used authbind before, so I
 just wanted to make sure that you have Tomcat working
 properly with non-SSL before you try to add SSL.
 
>>> , but the next and last step, which is enabling an SSL 
>>> connection, isn't working.
>>> 
>>> What I did following the site's tutorial was: created
>>> my self signed certificate with keytools and put it on 
>>> /home/myuser/key.keystore
 
 Can you outline the steps you took? Where is your keystore?
 
>>> Additionally, I've created the folowing conector:
>>> 
>>> >> protocol="org.apache.coyote.http11.Http11Protocol" 
>>> SSLEnabled="true" maxThreads="200" scheme="https" 
>>> secure="true" keystoreFile="/home/myuser/key.keystore" 
>>> keystorePass="mypass" clientAuth="false"
>>> sslProtocol="TLS" />
 
 That looks good so far.
 
>>> Saved it, restarted server and accessed
>>> https://myip:8443, but it isn't working. Chrome says
>>> "No data recieved" and "Unable to load the webpage
>>> because the server sent no data and "Error code:
>>> ERR_EMPTY_RESPONSE".
>>> 
>>> Firefox says that the connection was reset while the
>>> page was being loaded.
>>> 
>>> That's where I am now. I don't know what to try
>>> anymore.
 
 Try:
 
 $ telnet localhost 8443
 
 (on the server with Tomcat running)
 
 That will tell you if the port is open (it should be,
 otherwise you'd be getting different errors from Chrome and
 ff) and what, if anything, gets dumped to it when you
 connect.
 
 If you get a connection and nothing happens, try submitting
 a request like this:
 
 $ telnet localhost 8443 GET /
 
 [output goes here]
 
 Post the results of the above if you get anything.
 
 Dumb question: you restarted Tomcat after updating
 server.xml, right?
 
 -chris
> 
> -
>
>
>
> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail:
> users-h...@tomcat.apache.org
> 
> 
 Thank you for the reply Christopher! I've used the command:
 keytool -genkey -alias tomcat -keyalg RSA -keystore 
 /home/myuser/key.keystore to generate the keystore. I should
 put the keystore in some special directory or this one is
 fine? So, after, requesting:   telnet localhost 8443
 
 I got some strange stuff:
 
 ~$ telnet localhost 8443 Trying ::1... Connected to
 localhost. Escape character is '^]'. GET / ^U^C^A^@^B^B
 
 
 
 And yes, I've restarted it :)
> 
> Good. Now, try this:
> 
> $ openssl s_client -debug -connect localhost:8443
> 
> Assuming that the server is running and listening for SSL
> connections, s_client should be able to connect, and it should give
> you tons of good information about what's happening, there.
> 
> -chris
>> 
>> -
>>
>> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>> 
>> 
> Hello Chris! I've tried the command you suggested and the most
> important thing I found was this:
> 
> subject=/C=Unknown/ST=Unknown/L=Unknown/O=SysAid/OU=Unknown/CN=Unknown
>
> 
issuer=/C=Unknown/ST=Unknown/L=Unknown/O=SysAid/OU=Unknown/CN=Unknown
> --- No client certificate CA names sent --- SSL handshake has read
> 1073 bytes and written 555 bytes --- New, TLSv1/SSLv3, Cipher is
> ECDHE-RSA-AES256-SHA384 Server public key is 1024 bit Secure
> Renegotiation IS supported Compression: NONE Expansion: NONE 
> SSL

Re: Slow HTTP Rquest via Tomcat

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

David,

On 1/14/15 1:15 PM, David kerber wrote:
> On 1/14/2015 1:02 PM, Christopher Schultz wrote: Thone,
> 
>> ...
> 
> 
 Also, yes, autodeploy is equal to "True". I will check with
 my colleague to see if we can test with false because this
 will impact all web folders. Do you see any impact if this
 was "false"? Why is it defaulted to "true"?
> 
> See http://tomcat.apache.org/tomcat-7.0-doc/config/host.html and 
> http://tomcat.apache.org/tomcat-7.0-doc/config/host.html#Automatic_Application_Deployment
>
> 
> 
> It defaults to true because it's not much overhead and most people 
> want to allow automatic re-deployment of web applications. It's
> easily disabled.
> 
> The real question is "why is Tomcat deciding to reload"?
> 
> The only time Tomcat reloads for us (we run with autoDeploy set to 
> default in production) is when we "touch" the META-INF/context.xml
> file.
> 
> You should check the timestamps on your context.xml files (or 
> appname.xml files, if you are placing those into 
> CATALINA_BASE/conf/[engine]/[host]/[appname].xml) and/or your WAR 
> files (or exploded WAR directories) in your appbase (defaults to 
> CATALINA_BASE/webapps) to see if those timestamps are changing for 
> some reason.
> 
> Timestamps should be retained in ms since the epoch, so DST
> changes shouldn't have any effect (e.g. in March, your webapps
> won't automatically reload just because of clock adjustments). But,
> if the system time changes radically for some reason, it may
> trigger a reload or if the file dates change for some reason (I
> dunno... some weird NFS thing?) then you may also get a reload.
> 
> I wonder if these occasional slow-downs are an artifact of
> reloading the web application in the middle of a request.
> 
>> I take it TC is running as a service (or whatever it's called on
>> Linux)? And if so, will it auto restart if TC crashes?  I know
>> it's quite a stretch, but if something was messed up badly
>> enough, could it crash the service during the request, causing it
>> to auto restart and reload?

Possibly.

I re-read the log file, and there are no logs that actually say that
the context is reloading. It just says "checking context[/path] reload
resource" over and over again. I checked, and Tomcat does not emit any
log messages that look like that... this must come from somewhere else.

so I'm not sure what I'm looking at. What I can tell is that some
component is furiously checking "reload resources" during the time
period covered by that log file.

I would check the /Tomcat/ log during the same period to see if
anything is happening, there.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJUtrv5AAoJEBzwKT+lPKRYAIcQAKxw0yIy9G0jsdEnpN2XK1Fi
Sk7YSUtjJhzC4eQR/ndeROeuECPqrYDcIal9c351rN+Uwt73RHvei9rmTe5bQ6Ek
8SE0K09yq0nfEBKGaWUJiPGBMWpAuWw2/c4vzTwkgG7/QKVx4Pfu2IE64+/5WaRE
SDPDmvVjxwTY031TmPfJ7/Jtp4rw6yxAVd/r1VqM3+CIPakqozYP6V94ZTHUcE9F
NwIHdc62zXxTk55Qq5+96vyIYTrV3uAoRA9q8cKkbAAXFOoCa0XRtgfi6qgik3iu
iGOhbxpiUxOj3pEO/gRhJEZGEq7MikpoNDqM2ELhpXVlogwuvpoHLaDkd4e23bir
MOXU2KO38QrQuCUb+Foee9EhjbNwPLuOtqOhTQU239eYws5Y+ay8EEfhWLgvvz5z
8T7AEbkrqUulJ4txhKktBIKVikyk/TDfwfFdNyttQNXjpp0NHbbX5BvCTCxA+FBt
dTAGnUUG6I7ZJ4VfyQpwu8QdG2gSugttk08Ju7lNFeDLoVSHZnc1NB3GbndFizDK
SYZumI9shX7uuh+y991UWl5mzYbq841NAEgV7KF1w4M3K/uPXiYfFEqMlhQlSlVx
hqkZHU9qoIch7FoBUXikL9oPKLqUWG16AubjbUeLom5g2LUPFOXlj2V219o0Zl6M
qRZGo2KZoC3hVAIFkEIQ
=f/u5
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Can't make SSL work on Tomcat7 on Ubuntu Server 14.04

[Sanaullah]

>    protocol="org.apache.coyote.
http11.Http11Protocol"
>  SSLEnabled="true" maxThreads="200" scheme="https"
>  secure="true" keystoreFile="/home/myuser/key.keystore"
>  keystorePass="mypass" clientAuth="false" sslProtocol="TLS"
>  />


May be its due to the truststore file ? I haven't seen any truststore file
in your connector configuration


On Wed, Jan 14, 2015 at 11:18 PM, Alexandre Lima 
wrote:

> On 13 January 2015 at 18:20, Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > Alexandre,
> >
> > On 1/13/15 2:41 PM, Alexandre Lima wrote:
> > > On 13 January 2015 at 16:11, Christopher Schultz <
> > > ch...@christopherschultz.net> wrote:
> > >
> > > Alexandre,
> > >
> > > On 1/13/15 1:37 PM, Alexandre Lima wrote:
> >  Hello! This is the first time I'm using tomcat, so I'm a
> >  little bit lost...
> > >
> > > Welcome! Configuring SSL always turns out to be a pain in the
> > > neck.
> > >
> >  Using the tutorials, I could make the server and the
> >  application I want to run with it work. The only modification
> >  I did until now was changing the http port from 8080 to 80, I
> >  did that changing the http conector on servers.xml, enabling
> >  authbind and executing the folowing commands:
> > 
> >  sudo touch /etc/authbind/byport/80 sudo chmod 500
> >  /etc/authbind/byport/80 sudo chown tomcat7
> >  /etc/authbind/byport/80
> > 
> >  So, the server and the application I want to use with it are
> >  actually working on port 80
> > >
> > > You've confirmed this? I've never used authbind before, so I just
> > > wanted to make sure that you have Tomcat working properly with
> > > non-SSL before you try to add SSL.
> > >
> >  , but the next and last step, which is enabling an SSL
> >  connection, isn't working.
> > 
> >  What I did following the site's tutorial was: created my
> >  self signed certificate with keytools and put it on
> >  /home/myuser/key.keystore
> > >
> > > Can you outline the steps you took? Where is your keystore?
> > >
> >  Additionally, I've created the folowing conector:
> > 
> >   >  protocol="org.apache.coyote.http11.Http11Protocol"
> >  SSLEnabled="true" maxThreads="200" scheme="https"
> >  secure="true" keystoreFile="/home/myuser/key.keystore"
> >  keystorePass="mypass" clientAuth="false" sslProtocol="TLS"
> >  />
> > >
> > > That looks good so far.
> > >
> >  Saved it, restarted server and accessed https://myip:8443,
> >  but it isn't working. Chrome says "No data recieved" and
> >  "Unable to load the webpage because the server sent no data
> >  and "Error code: ERR_EMPTY_RESPONSE".
> > 
> >  Firefox says that the connection was reset while the page was
> >  being loaded.
> > 
> >  That's where I am now. I don't know what to try anymore.
> > >
> > > Try:
> > >
> > > $ telnet localhost 8443
> > >
> > > (on the server with Tomcat running)
> > >
> > > That will tell you if the port is open (it should be, otherwise
> > > you'd be getting different errors from Chrome and ff) and what, if
> > > anything, gets dumped to it when you connect.
> > >
> > > If you get a connection and nothing happens, try submitting a
> > > request like this:
> > >
> > > $ telnet localhost 8443 GET /
> > >
> > > [output goes here]
> > >
> > > Post the results of the above if you get anything.
> > >
> > > Dumb question: you restarted Tomcat after updating server.xml,
> > > right?
> > >
> > > -chris
> > >>
> > >> -
> > >>
> > >>
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > >> For additional commands, e-mail: users-h...@tomcat.apache.org
> > >>
> > >>
> > > Thank you for the reply Christopher! I've used the command: keytool
> > > -genkey -alias tomcat -keyalg RSA -keystore
> > > /home/myuser/key.keystore to generate the keystore. I should put
> > > the keystore in some special directory or this one is fine? So,
> > > after, requesting:   telnet localhost 8443
> > >
> > > I got some strange stuff:
> > >
> > > ~$ telnet localhost 8443 Trying ::1... Connected to localhost.
> > > Escape character is '^]'. GET / ^U^C^A^@^B^B
> > >
> > >
> > >
> > > And yes, I've restarted it :)
> >
> > Good. Now, try this:
> >
> > $ openssl s_client -debug -connect localhost:8443
> >
> > Assuming that the server is running and listening for SSL connections,
> > s_client should be able to connect, and it should give you tons of
> > good information about what's happening, there.
> >
> > - -chris
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v1
> > Comment: GPGTools - http://gpgtools.org
> >
> > iQIcBAEBCAAGBQJUtYwOAAoJEBzwKT+lPKRYkRIQAKFA3/GpDdzT5ZVWZ8+VXjQr
> > AYgy42TqufEs8RicHNjB0Ey92azX4zNMau4yBxQ3dqv660vOqW3PW1XSVC8yF+ke
> > +QBwivtJCglep+7nsPTTL4nSM4yAOCGMzYKGXidNdczvqcnoM2XA8jg0JiM68gBx

Re: Is there a way to abruptly force a connection closed without returning anything?

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

André,

On 1/14/15 5:56 AM, André Warnier wrote:
> Christopher Schultz wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>> 
>> Jesse,
>> 
>> On 1/13/15 6:29 PM, Jesse Barnum wrote:
>>> I need the ability to examine the POST data from a request, 
>>> examine it, and either respond to it or close the connection 
>>> without returning any result, not even a 200 OK status.
>>> 
>>> The reason for this is because I’m getting overwhelmed with 
>>> thousands of invalid requests per second, which are racking up 
>>> bandwidth fees. The requests can’t be traced to an IP address,
>>> so I can’t just block them in a firewall or Apache - I need to
>>> actually use logic in my Tomcat app to figure out which
>>> requests to respond to.
>>> 
>>> Is there a way to force Tomcat to just drop the connection and 
>>> close the socket without sending a response?
>> 
>> You can't close the stream form your code, Tomcat will ignore it,
>> so a response flush, and return a 200 response anyway.
>> 
>> I'm curious, what's wrong with an empty 200 response? It's only
>> a couple of bytes, but I suppose if you are getting millions per
>> hous, you could still incur bandwidth costs...
>> 
>> You might be able to do this with a Valve, but then you might
>> have problems with your web application needing to provide the
>> logic to determine whether or not to accept the request.
>> 
>> When you say "can't be traced to an IP address" do you mean that
>> you are seeing invalid requests coming from all over the place,
>> or that the requests don't include a source IP address (which
>> seems fishy)?
>> 
>> A few options that might achieve your goal without using the
>> technique you describe:
>> 
>> 1. Use client authentication; unauthorized clients can't even
>> handshake Downsides: SSL overhead
>> 
>> 2. Use a VPN (which essentially uses client authentication) 
>> Downsides: VPNs really, really suck
>> 
>> 3. (As Mark E suggests) Use mod_security with httpd I know this
>> will seriously separate your business logic form your web
>> application, but perhaps there is a simple set of criteria that 
>> might eliminate a significant portion of the requests, thus
>> solving the problem "well enough"
>> 
> 
> I have an additional suggestion, harking back to a time when I was 
> trying to convince the Apache httpd devs to implement something
> like this in .. Apache httpd. By experience with trying to convince
> people, I know that this is controversial, so hold on tightly and
> follow the gist.  You can always decide by yourself if this is
> appropriate for your case.
> 
> The idea is this : when you get such a request, and you decide that
> it is invalid, return a 404 "not found", but delay it by some
> random number of seconds. (do a random sleep in your webapp, or in
> a filter after the webapp).

This is essentially a reverse slowloris attack against the client. The
major problem is that it ties up resources on the server, which is the
whole problem you are trying to solve in the first place. In theory,
it's a good idea, but in practice, you are using system resources to
.. avoid using system resources. I'm not sure if the curve is linear
(your suggestion may be "cheaper" than simply doing nothing), but it's
certainly not a free lunch.

> The short-term hope is that if attackers notic that your website is
> such a "sink", they may just take it out of their list of targets,
> so as not to slow down their whole nefarious scheme.

This is the club[0] effect: your server is marginally more of a pain
in the neck than someone else's, so they ignore you and attack others.

- -chris

[0] http://en.wikipedia.org/wiki/The_Club_%28automotive%29
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJUtrpnAAoJEBzwKT+lPKRYqW0P/0cSN1nyLwzVJZ2yBGoVmH3H
MPsDjxnB/WFIvLtuDq2jGzerpzC4d//6kCxY6D2IxyPTXVLYABsvVA4A1WU4fnIB
5RJPFSf3U5MytpUbeXUGKv2J7nOF5kIGPIydpz7XTex+t+y8RGyPrfl6s2wLadIV
LtPCI1Wje8By2UcIlLu4JMQXE6jLiXirW5/UgvwOiNq/92QCUSBilmn591yjjYtL
WCLSOCcVsRtHnckjrLSXPLXEMAT2qVMFwdYgwT0AgyuuzRCZ6HAcuPzou6BXmJXx
Uqhc34NzVYZ2lHSCLx8ZvYrJLlRPSAl0XQ70wwnX1DpmJfXOwdSqCXJTXv2/lpT7
CGPyN+n7EYIivP2zV04Iksp5vLu/8xTqzgkew5QOgCbviKZs9krDm+HbbCKA/dHp
su9Bo/2Bo1OFgNEzyBsSWTuiKTAHt2yIunQw61YdWa5RpkMtXZ3kzrni9zaeNnas
dxrxtlbCk44i5i09v6F/+lvgTRfu5zbp3qBtvlTirkWQhBhjiD5+XUMFPC6695Ih
QMba6yc4JlKRy3JYpulNr8eXFPb8hT9FxNxf/367++FQso12VM5uPBOcizt9vToJ
b6v+GEFAIhM3g8vsVfxSZxhMAslkBP0d8mKpMtnNSsaL2lkxWDLp9jDB6ZhoejMm
VgYrKKu+mbvyN0VOkypt
=s7hV
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Occasional long wait for a JDBC connection

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Darren,

On 1/13/15 11:32 PM, Darren Davis wrote:
> On Tue, Jan 13, 2015 at 8:39 PM, Christopher Schultz < 
> ch...@christopherschultz.net> wrote:
> 
> Darren,
> 
> (Sorry... just had to remove that monstrous stack trace...)
> 
> On 1/13/15 5:04 PM, Darren Davis wrote:
 Hi Christopher.  Yes, we've tried a show process list and can
 find no evidence of the validation query running on mysql.
> 
> Strange. Maybe you are waiting for the db server's buffer to flush
> or something like that.
> 
> 
>> I think this is because the client thinks it still has an open
>> connection, the client net stat command shows an open connection
>> over port 3306, at least for a few minutes after it's killed by
>> the load balancer.  The Server loses its connection in netstat
>> immediately.
> 
> 
 We also just tried an experiment outside of Tomcat
 completely, but connecting to a downed web server host and
 manually opening up a mysql client connection to the data
 server and executing a single command.
 
 We left that client window idle for an hour and 5 minutes,
 and attempted to execute a simple select count(*) command
 against a tiny table.  The client attempted to execute the
 query, and a NetStat on that box showed an open connection
 between the two servers using port 3306.  We also checked the
 process list during this time and could not find any queries
 at all from the sever in question.
 
 At about the 15 minute wait mark, the client finally came
 back with this message: "ERROR 2013 (HY000): Lost connection
 to MySQL server during query.
> 
> Was this with the MySQL command-line client? What query did you
> issue ("SELECT 1")?
> 
> 
>> Yes, it was just the command line client, and we issued a select
>> count(*) from a table with a couple rows in it.
> 
> 
 Attempting the execute the command a 2nd time (using the up 
 arrow), re-established the connection and it ran perfectly in
 a few milliseconds.
> 
> That's interesting. I've never experienced anything like that with 
> MySQL, but we use a VLAN between our application and database
> servers with no hardware firewall, so we don't have any connection
> timeout problems. Also, when connections are dropped due to
> inactivity, they re-connect without any problems.
> 
 I checked the mysql configuration and it is set to the
 default values for keeping connections/interactive
 connections open (for 8 hours), so it seems that maybe the
 Cisco firewall between the two servers is terminating
 connections out from under us, but in a way what the O/S
 cannot detect it.
> 
> What if you set that idle connection timeout to something like 5 
> minutes? Can you reproduce this issue more quickly? Can you look
> at the fw configuration to see if you can change the idle timeout
> /down/ to something more testable?
> 
> As part of our move to the new versions of Tomcat/Java, we are in a
> new
>> cloud environment which features a different type of firewall.
>> The provider confirmed to us late today, that it is configured to
>> kill "idle" TCP connections after an hour, which is something our
>> old firewall didn't do.
> 
>> Because we sometimes have low traffic during this time of the
>> year, especially on the weekends, what we think is happening is
>> that one or more of the minimum 10 connections is going unused
>> for more than an hour, and since we didn't have any connection
>> testing while idle turned on, they were being killed by the
>> firewall out from under the pool, and depending on how soon they
>> were used after that, we would run into the 15 minute delay 
>> before they were deemed lost, and replaced with a new
>> connection.

This should be entirely possible. That's the point of the
connection-validation operation (whether done by an actual query or
not). The question is why the connection is being dropped in a way
that is thwarting the connection-validation at all. It may come down
to some kind of OS-level setting, or a slightly different
configuration on the firewall.

It seems that removing the firewall's idle-connection policy would be
an easy way to try to get around this issue at least temporarily.

 I've also fired up the yourKit profiler on this box and am
 seeing other threads which have had to wait in the same 
 SocketInputStream.read code, all three started a few seconds
 apart, it just wasn't detected as a deadlock, because it took
 place outside of any synchronized methods.
> 
> What makes you think it's deadlock? Deadlock is a very specific
> thing. Just because many threads are waiting in
> SocketInputStream.read doesn't mean there are any threading issues
> at all. I suspect that each SocketInputStream is distinct and only
> in use by a single thread. The threads are blocked on I/O, right?
> So they aren't waiting on a monitor. The best you could do would be
> to find the nativ

Re: Can't make SSL work on Tomcat7 on Ubuntu Server 14.04

[Alexandre Lima]

On 13 January 2015 at 18:20, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Alexandre,
>
> On 1/13/15 2:41 PM, Alexandre Lima wrote:
> > On 13 January 2015 at 16:11, Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> > Alexandre,
> >
> > On 1/13/15 1:37 PM, Alexandre Lima wrote:
>  Hello! This is the first time I'm using tomcat, so I'm a
>  little bit lost...
> >
> > Welcome! Configuring SSL always turns out to be a pain in the
> > neck.
> >
>  Using the tutorials, I could make the server and the
>  application I want to run with it work. The only modification
>  I did until now was changing the http port from 8080 to 80, I
>  did that changing the http conector on servers.xml, enabling
>  authbind and executing the folowing commands:
> 
>  sudo touch /etc/authbind/byport/80 sudo chmod 500
>  /etc/authbind/byport/80 sudo chown tomcat7
>  /etc/authbind/byport/80
> 
>  So, the server and the application I want to use with it are
>  actually working on port 80
> >
> > You've confirmed this? I've never used authbind before, so I just
> > wanted to make sure that you have Tomcat working properly with
> > non-SSL before you try to add SSL.
> >
>  , but the next and last step, which is enabling an SSL
>  connection, isn't working.
> 
>  What I did following the site's tutorial was: created my
>  self signed certificate with keytools and put it on
>  /home/myuser/key.keystore
> >
> > Can you outline the steps you took? Where is your keystore?
> >
>  Additionally, I've created the folowing conector:
> 
>    protocol="org.apache.coyote.http11.Http11Protocol"
>  SSLEnabled="true" maxThreads="200" scheme="https"
>  secure="true" keystoreFile="/home/myuser/key.keystore"
>  keystorePass="mypass" clientAuth="false" sslProtocol="TLS"
>  />
> >
> > That looks good so far.
> >
>  Saved it, restarted server and accessed https://myip:8443,
>  but it isn't working. Chrome says "No data recieved" and
>  "Unable to load the webpage because the server sent no data
>  and "Error code: ERR_EMPTY_RESPONSE".
> 
>  Firefox says that the connection was reset while the page was
>  being loaded.
> 
>  That's where I am now. I don't know what to try anymore.
> >
> > Try:
> >
> > $ telnet localhost 8443
> >
> > (on the server with Tomcat running)
> >
> > That will tell you if the port is open (it should be, otherwise
> > you'd be getting different errors from Chrome and ff) and what, if
> > anything, gets dumped to it when you connect.
> >
> > If you get a connection and nothing happens, try submitting a
> > request like this:
> >
> > $ telnet localhost 8443 GET /
> >
> > [output goes here]
> >
> > Post the results of the above if you get anything.
> >
> > Dumb question: you restarted Tomcat after updating server.xml,
> > right?
> >
> > -chris
> >>
> >> -
> >>
> >>
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>
> >>
> > Thank you for the reply Christopher! I've used the command: keytool
> > -genkey -alias tomcat -keyalg RSA -keystore
> > /home/myuser/key.keystore to generate the keystore. I should put
> > the keystore in some special directory or this one is fine? So,
> > after, requesting:   telnet localhost 8443
> >
> > I got some strange stuff:
> >
> > ~$ telnet localhost 8443 Trying ::1... Connected to localhost.
> > Escape character is '^]'. GET / ^U^C^A^@^B^B
> >
> >
> >
> > And yes, I've restarted it :)
>
> Good. Now, try this:
>
> $ openssl s_client -debug -connect localhost:8443
>
> Assuming that the server is running and listening for SSL connections,
> s_client should be able to connect, and it should give you tons of
> good information about what's happening, there.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJUtYwOAAoJEBzwKT+lPKRYkRIQAKFA3/GpDdzT5ZVWZ8+VXjQr
> AYgy42TqufEs8RicHNjB0Ey92azX4zNMau4yBxQ3dqv660vOqW3PW1XSVC8yF+ke
> +QBwivtJCglep+7nsPTTL4nSM4yAOCGMzYKGXidNdczvqcnoM2XA8jg0JiM68gBx
> Jxl7MdM/S2ktngs8tuG6SSaiY5eyPB1ySUwXOD3zfrVLJK7Ex4y2USt9IKAEYhBl
> A3kxWHIjlV+1m+ZAf6WmwWMmsBWxtVVx6iDAiR/ZIzvY/VMpqtSZ0rSGeM7OnfhV
> ER2NN+4z+2kqskj5WJ6ZX2Q6i7CbdPfrCq6RstPOLaWNZICIoqVlR43I21+BOc5o
> ugORSS97XBuQy5fXfBbgOJoN0wupttBNB44We9ZmHexuInVl3uxbyDra8yRkVT8M
> qT7jcDW8lMFmCxmbilelsDRpnYj55j5OA+453nI0vQap/ojZBTb/fgRsl6PnPTRG
> omd+jC1wMFIfycu+2ahJB1YHNTGTfD3MWP/Wey/82u3X9QJD35TTcNt+gyVrCLtw
> eLoUUqkaCSZNuudWBpm61/2gp//c9adWRZTozd9/c4Yasp8f2ruLDK3+6rA7ohM5
> OZ7Mh5wEal8zNnBC7sQeuoekkiQKDRQlQdATSAthlszFMByn+k5A5IJNWUB1asUp
> VPf4zB2XaBIxgnKm3qPV
> =Bl3E
> -END PGP SIGNATURE-
>
> -
> To unsubscribe,

Re: Slow HTTP Rquest via Tomcat

[David kerber]

On 1/14/2015 1:02 PM, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Thone,


...



Also, yes, autodeploy is equal to "True". I will check with my
colleague to see if we can test with false because this will impact
all web folders. Do you see any impact if this was "false"? Why is
it defaulted to "true"?


See http://tomcat.apache.org/tomcat-7.0-doc/config/host.html
and
http://tomcat.apache.org/tomcat-7.0-doc/config/host.html#Automatic_Application_Deployment

It defaults to true because it's not much overhead and most people
want to allow automatic re-deployment of web applications. It's easily
disabled.

The real question is "why is Tomcat deciding to reload"?

The only time Tomcat reloads for us (we run with autoDeploy set to
default in production) is when we "touch" the META-INF/context.xml file.

You should check the timestamps on your context.xml files (or
appname.xml files, if you are placing those into
CATALINA_BASE/conf/[engine]/[host]/[appname].xml) and/or your WAR
files (or exploded WAR directories) in your appbase (defaults to
CATALINA_BASE/webapps) to see if those timestamps are changing for
some reason.

Timestamps should be retained in ms since the epoch, so DST changes
shouldn't have any effect (e.g. in March, your webapps won't
automatically reload just because of clock adjustments). But, if the
system time changes radically for some reason, it may trigger a reload
or if the file dates change for some reason (I dunno... some weird NFS
thing?) then you may also get a reload.

I wonder if these occasional slow-downs are an artifact of reloading
the web application in the middle of a request.


I take it TC is running as a service (or whatever it's called on Linux)? 
 And if so, will it auto restart if TC crashes?  I know it's quite a 
stretch, but if something was messed up badly enough, could it crash the 
service during the request, causing it to auto restart and reload?






- -chris


-Original Message- From: André Warnier
[mailto:a...@ice-sa.com] Sent: Tuesday, January 13, 2015 2:04 PM To:
Tomcat Users List Subject: Re: Slow HTTP Rquest via Tomcat

Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256

Thone,

On 1/13/15 1:05 PM, Thone Soungpanya wrote:

Hello Andre,

I do not think it is an DNS lookup issue but I'll check on it.

Yes we actually have logs but it does not tell us much. We
added additional logging in our servlet code to tell us when
and what the code is doing. I have attached a log for 1
connection which took about 1 minute and 23 seconds to
complete. I have eliminated all sensitive information with
"XX". During this time, there would be
other connections too simultaneously.

Some information on the request: 1) HTTP request initiated at
16:11:06 to Tomcat.


This is a very confusing log file... from latest-to-oldest.


+10



Before #2 happens, Tomcat reloads. Many (all?) web applications
were re-loaded. Was that expected?


2) Connection to Third Party System happened at 16:12:22. You
can see it on line 38 with following text "2015-01-12
16:12:22,426 INFO 06E4074221FF93C2827079EBC2102847; begin
request"


Okay.


3) Response back to Tomcat from Third Party System at 16:12:29


This does not appear in the log.


So it seems that between point#1 and point #2, there was about
a 1 minute and 16 seconds delay before connection to the third
party. Point #2 to Point #3 only took 7 seconds.

Can you or anyone see what may be the issue from the logs?




Maybe if you provide clearer logs, having some real information
allowing to distinguish one request processing sequence from
another.


Tomcat is reloading in the middle of the request?


Right, that's what it looks like. And not only this one time. From
the (very difficult) look of it, it seems that this system is
spending its time reloading its applications almost continuously.
Using some nifty features of Notepad++, I have extracted and
re-ordered what I believe are log lines relating to one webapp (and
I don't really know for sure if this is one request, or several).
See attached if it makes it, it's probably clearer.  Otherwise, I
have also pasted these log lines below.

I have selected lines related to a webapp named "ps_1.5_8.53.10",
and re-ordered them in a logical older-to-younger top-down
sequence.

Examining thse lines, we see : - at 2015-01-12 16:11:07,396 : what
appears to be the beginning of a redeployment of that webapp - at
2015-01-12 16:11:08,108 (one second later) : what appears to be the
beginning of a request to that webapp - at 2015-01-12 16:11:15,918
(7 seconds later), what seems to be the beginning of yet another
redeployment of that webapp - at 2015-01-12 16:11:21,037, another
request starting

In-between, there are a lot of other lines apparently showing
similar (other) webapps redeployments, and maybe other lines
related to that same webapp, but all quite difficult to identify
because there is no common marker.

That logfi

Re: Slow HTTP Rquest via Tomcat

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Thone,

On 1/13/15 7:59 PM, Thone Soungpanya wrote:
> Hello Andre,
> 
> Yes sorry the logs files are not clear. We have so much traffic
> going through the Tomcat and many clients connecting which it seems
> to be logging for different sessions at different time. We really
> have no control to sort this out as the connections are
> simultaneous.
> 
> Our reordering of the logs and the entries listed may be correct. I
> cannot tell myself if it is linked to the same session. We tried to
> use Session IDs to add against the entries we make for servlet code
> but that somehow does not follow in order.
> 
> As for your comment on web.xml and retriggering the redeployment of
> the web app folders, yes, I am wondering why this is happening if
> that is the case. There is a web.xml in each WEB-INF folder however
> nothing never change. Also, this is all it has in it below where it
> is just the servlet name and mapping. Can this really retrigger it
> if it never changes?
> 
> http://java.sun.com/xml/ns/j2ee
> http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"; version="2.4"> 
> Peoplesoft Connector 
> PeopleSoft Connector Applications. 
>  PSConnectorServlet 
> PSConnectorServlet  
>  PSConnectorServlet 
> /servlet/PSConnectorServlet 
>  
> 
> Also, yes, autodeploy is equal to "True". I will check with my 
> colleague to see if we can test with false because this will impact
> all web folders. Do you see any impact if this was "false"? Why is
> it defaulted to "true"?

See http://tomcat.apache.org/tomcat-7.0-doc/config/host.html
and
http://tomcat.apache.org/tomcat-7.0-doc/config/host.html#Automatic_Application_Deployment

It defaults to true because it's not much overhead and most people
want to allow automatic re-deployment of web applications. It's easily
disabled.

The real question is "why is Tomcat deciding to reload"?

The only time Tomcat reloads for us (we run with autoDeploy set to
default in production) is when we "touch" the META-INF/context.xml file.

You should check the timestamps on your context.xml files (or
appname.xml files, if you are placing those into
CATALINA_BASE/conf/[engine]/[host]/[appname].xml) and/or your WAR
files (or exploded WAR directories) in your appbase (defaults to
CATALINA_BASE/webapps) to see if those timestamps are changing for
some reason.

Timestamps should be retained in ms since the epoch, so DST changes
shouldn't have any effect (e.g. in March, your webapps won't
automatically reload just because of clock adjustments). But, if the
system time changes radically for some reason, it may trigger a reload
or if the file dates change for some reason (I dunno... some weird NFS
thing?) then you may also get a reload.

I wonder if these occasional slow-downs are an artifact of reloading
the web application in the middle of a request.

- -chris

> -Original Message- From: André Warnier
> [mailto:a...@ice-sa.com] Sent: Tuesday, January 13, 2015 2:04 PM To:
> Tomcat Users List Subject: Re: Slow HTTP Rquest via Tomcat
> 
> Christopher Schultz wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>> 
>> Thone,
>> 
>> On 1/13/15 1:05 PM, Thone Soungpanya wrote:
>>> Hello Andre,
>>> 
>>> I do not think it is an DNS lookup issue but I'll check on it.
>>> 
>>> Yes we actually have logs but it does not tell us much. We
>>> added additional logging in our servlet code to tell us when
>>> and what the code is doing. I have attached a log for 1
>>> connection which took about 1 minute and 23 seconds to
>>> complete. I have eliminated all sensitive information with
>>> "XX". During this time, there would be
>>> other connections too simultaneously.
>>> 
>>> Some information on the request: 1) HTTP request initiated at 
>>> 16:11:06 to Tomcat.
>> 
>> This is a very confusing log file... from latest-to-oldest.
> 
> +10
> 
>> 
>> Before #2 happens, Tomcat reloads. Many (all?) web applications
>> were re-loaded. Was that expected?
>> 
>>> 2) Connection to Third Party System happened at 16:12:22. You
>>> can see it on line 38 with following text "2015-01-12
>>> 16:12:22,426 INFO 06E4074221FF93C2827079EBC2102847; begin
>>> request"
>> 
>> Okay.
>> 
>>> 3) Response back to Tomcat from Third Party System at 16:12:29
>> 
>> This does not appear in the log.
>> 
>>> So it seems that between point#1 and point #2, there was about
>>> a 1 minute and 16 seconds delay before connection to the third
>>> party. Point #2 to Point #3 only took 7 seconds.
>>> 
>>> Can you or anyone see what may be the issue from the logs?
>> 
> 
> Maybe if you provide clearer logs, having some real information
> allowing to distinguish one request processing sequence from
> another.
> 
>> Tomcat is reloading in the middle of the request?
> 
> Right, that's what it looks like. And not only this one time. From
> the (very difficult) look of it, it seems that this system is
> spending its time reloading its applications almost continuously. 
> Using some 

Re: Session Clustering Monitoring

[Peter Rifel]

Chris,

On 1/13/15, 11:06 AM, "Christopher Schultz" 
wrote:

>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA256
>
>Peter,
>
>On 1/13/15 1:10 PM, Peter Rifel wrote:
>> On 1/13/15, 6:32 AM, "Christopher Schultz"
>>  wrote:
>> 
>> I was wondering, because there is an unfortunately situation with
>> session stickiness and long-lived clients where fail-over can cause
>> a large number of clients to switch to a particular server and
>> /stay there/ even if they have to re-login (when you'd likely
>> prefer that they get re-balanced to another node if they have to
>> re-login).
>> 
>> If you had a temporary failure of one node, perhaps the clients
>> were re-assigned to another node and they "stayed there" when the
>> failing node became available again. Those clients would stay there
>> until either their newly-assigned node failed, or they closed their
>> browser (assuming they are using cookies that live for the life of
>> the client, like JSESSIONIDs typically do).
>> 
>> After the weekend in your scenario, perhaps all your users
>> restarted their browsers (or computers) and thus were re-balanced.
>> 
>>> But shouldn't all sessions be replicated regardless of how
>>> stickiness is (or isn't) setup?
>
>Yes, they should. I was just considering a possible failure scenario.
>With completely distributable sessions and the DeltaManager, the whole
>cluster should stay in sync.
>
>>> I assume that the DeltaManager only replicates changes to the
>>> state of all sessions since its last replication.  Maybe if there
>>> was a hiccup in replication by one tomcat instance, the sessions
>>> that it created or extended would not have gotten replicated and
>>> then never made their way to the other instances until they
>>> expire on their own.
>
>If this happened, you should be able to see some indication in the log
>files.
>
>>> If this is the case, I may try and come up with a better method
>>> for monitoring the clustering state, unless anyone has any
>>> suggestions on how to fix this supposed hiccup.
>
>It seems reasonable to expect that the session count would be
>consistent across the cluster, at least over time (obviously, it could
>take a few seconds for the cluster to become consistent if you are
>watching very carefully).
>
>The logs contain no clues?

Both log4j and CATALINA_OUT on every instance make no reference to any
session related issues at the time that this started.

>
>How many nodes are in the cluster? 5? I know that DeltaManager's
>performance degrades as the number of nodes increases, but I think
>it's a linear performance drop, as opposed to anything polynomial. I'm
>not sure if 5 nodes ends up being the breaking point, especially given
>your load profile (which you didn't specify).

Yes, we have 5 nodes.  I may consider a different Manager if this becomes
more of an issue.

>
>When you get nodes out of sync, can you probe them to find out if
>those "extra" sessions might be expired, but not yet cleaned-up?

Yes I will try and dump the session id list the next time this happens and
do some debugging.  Hopefully its not during a weekend...

Thanks again for your help! I'll be back here again if I have any new info.

Peter

>
>- -chris
>-BEGIN PGP SIGNATURE-
>Version: GnuPG v1
>Comment: GPGTools - http://gpgtools.org
>
>iQIcBAEBCAAGBQJUtWy+AAoJEBzwKT+lPKRYg9kQAL04b/noYkqhhGJ+dznl5njP
>nXX0VSCoCEF0+tEIGMvwS2k3MWJdxIlqPvpLnj2efompRmICB7cvVAjYF99xX6g9
>7SqV3TQ9eSNC3FzTPZomUolbSph7XS1eus3BEauRJ90H2ZaokeczSPDRPK/Gzsoq
>5+A9B22AcAspQOckZ+FaG5Qw/nwNeH+woksnPP2gCsgD85Rgs2PSlxJ+C8bF2VZ7
>PbXnDCBTh2dSPnFWb/E3tHVMb9lICz6/T/oVswnGJNuxwHfoceuWxnzlDisTU4jj
>LCNqg65gCOcscqLooS/L2t4znWlsnKAVsCmxOLYutOlZgLtnMhVXPqi7u1sRbZV6
>SL+3HSOoT6hpI2/w80RVxdPtVosLx0NpYPEq0Kp/Bv/4iXdwGyxtqJ6biTppyCe6
>US6Se7QyOt4lZOG0Bgp6nwx657sgAZUTBqN2JNFmVizx89Lh2A7r6fN6FoPnMxWH
>6ab4qTjPGi8C0TsndY4ei7IDyEF14/JhNgJcpstt37KTJkhuECHZng0vaP7mt0rG
>f27w2fR2UQtRMkAE3ydKgGUSrOTybai6Y6Z4R4pOoKQl3lilwAMX/PjPODAWkc6T
>RC9upIneDXdWB2eZzSfIr9v06JV/GT5fHjIn0eV1CtFs+95zYg4Jtn9+obTte08y
>WnYTGW5w9PC69+csaVcz
>=pPm4
>-END PGP SIGNATURE-
>
>-
>To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>For additional commands, e-mail: users-h...@tomcat.apache.org
>


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Delay when: Deploying web application

[Mike Smotritsky]

Konstantin, thank you very much!
Exactly what I needed!

Thanks and Regards,

Mike


On 1/14/2015 2:05 PM, Konstantin Kolinko wrote:

2015-01-14 14:15 GMT+03:00 Mike Smotritsky :

Hi guys, please help me solve this riddle:

Startup times for my app are hugely growing with advancement of Tomcat
technology!:

7.0.23 - 23 sec
7.0.40 - 32 sec
7.0.47 - 75 sec
7.0.57 - 88 sec

The delay is when the application is deploying to DIR from WAR.
Running on VM/newest RedHat, patches are up to date


https://wiki.apache.org/tomcat/HowTo/FasterStartUp

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org





-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Web filter to forward some requests to another remote webserver

[Jose María Zaragoza]

2015-01-14 12:46 GMT+01:00 André Warnier :
> Jose María Zaragoza wrote:
>>
>> Hello:
>>
>> I would like to create a web filter to forward some requests to
>> another webserver,
>>
>> The filter receives an "application/x-www-form-urlencoded" request ,
>> inspects the value of a parameter and chooses to forward to another
>> remote webserver ( as a proxy )


Thanks

I agree with you . I'll try to use an Apache httpd front-end

Anyway, I've seen that if I execute

Map parameter = ((HttpServletRequest)
request).getParameterMap();

, then request.getInputStream is empty


But if I execute

Map parameter = ((HttpServletRequest)
request).getParameterMap();
chain.doFilter(request, response);

, the next filter in the chain receives the body ( as I expect it )

I don't understand this behaviour


Regards



>>
>> I've seen some posts where they open a HttpURLConnection to remote
>> server and send the request. This is right for me, but I'd would like
>> if there is another way ( easier ) to implement it.
>>
>
> Hi.
>
> The only easier way is to do your proxying before the request even gets to
> Tomcat (e.g. via an Apache httpd front-end, which conditionally proxies to
> Tomcat or to the other webserver).  That is easier, because Apache httpd
> already has well-tested and widely-used proxy modules built-in.  But of
> course it depends on whether the Apache front-end would be able to test the
> "parameter" you are referring to.
> (It can do that kind of thing via Apache directives such as "SetEnvIf", and
> via mod_rewrite).
>
> For Tomcat, there is no such ready-made Proxy webapp available, so you have
> to do it yourself.
> That can be relatively simple or quite complicated, depending on what the
> requests are and what the proxied-to application is like.
> There was a thread on this list a couple of days ago which was related to a
> similar case.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Delay when: Deploying web application

[Konstantin Kolinko]

2015-01-14 14:15 GMT+03:00 Mike Smotritsky :
> Hi guys, please help me solve this riddle:
>
> Startup times for my app are hugely growing with advancement of Tomcat
> technology!:
>
> 7.0.23 - 23 sec
> 7.0.40 - 32 sec
> 7.0.47 - 75 sec
> 7.0.57 - 88 sec
>
> The delay is when the application is deploying to DIR from WAR.
> Running on VM/newest RedHat, patches are up to date


https://wiki.apache.org/tomcat/HowTo/FasterStartUp

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Web filter to forward some requests to another remote webserver

[André Warnier]

Jose María Zaragoza wrote:

Hello:

I would like to create a web filter to forward some requests to
another webserver,

The filter receives an "application/x-www-form-urlencoded" request ,
inspects the value of a parameter and chooses to forward to another
remote webserver ( as a proxy )

I've seen some posts where they open a HttpURLConnection to remote
server and send the request. This is right for me, but I'd would like
if there is another way ( easier ) to implement it.



Hi.

The only easier way is to do your proxying before the request even gets to Tomcat (e.g. 
via an Apache httpd front-end, which conditionally proxies to Tomcat or to the other 
webserver).  That is easier, because Apache httpd already has well-tested and widely-used 
proxy modules built-in.  But of course it depends on whether the Apache front-end would be 
able to test the "parameter" you are referring to.

(It can do that kind of thing via Apache directives such as "SetEnvIf", and via 
mod_rewrite).

For Tomcat, there is no such ready-made Proxy webapp available, so you have to 
do it yourself.
That can be relatively simple or quite complicated, depending on what the requests are and 
what the proxied-to application is like.

There was a thread on this list a couple of days ago which was related to a 
similar case.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Delay when: Deploying web application

[Mike Smotritsky]

Hi guys, please help me solve this riddle:

Startup times for my app are hugely growing with advancement of Tomcat 
technology!:


7.0.23 - 23 sec
7.0.40 - 32 sec
7.0.47 - 75 sec
7.0.57 - 88 sec

The delay is when the application is deploying to DIR from WAR.
Running on VM/newest RedHat, patches are up to date

Very much appreciate you help!

Thanks and Regards,
Mike

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Memory shortage appears as missing pulse-java.jar file error with Java 7

[Konstantin Kolinko]

2015-01-13 14:18 GMT+03:00 Peter Lavin :
>
> Hi all, I have deployed a simple (Eclipse developed) webservice in a Tomcat7
> container which is running on Debian, details as follows...
>
> The error is as follows... (abridged, but it is complaining about missing a
> file called pulse-java.jar)
>
> INFO: Deploying web application archive
> /var/lib/tomcat7/webapps/SecureServiceExample.war
> Jan 12, 2015 3:03:01 PM org.apache.catalina.startup.TldConfig tldScanJar
> WARNING: Failed to process JAR
> [jar:file:/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/ext/pulse-java.jar!/]
> for TLD files
> java.io.FileNotFoundException:
> /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/ext/pulse-java.jar (No such file
> or directory)
> at java.util.zip.ZipFile.open(Native Method)
> at java.util.zip.ZipFile.(ZipFile.java:215)
> at java.util.zip.ZipFile.(ZipFile.java:145)

1) It is a warning, not an error.

2) If Tomcat attempts to scan the file, it means that the file is
listed by the System classloader (or some other classloader in
classloader hierarchy).

I do not know how system classpath is configured on your system.

It is either auto-detected (and thus the file exists, but maybe it is
not readable), or there is some system configuration file for java
that has a stale value. E.g. if you are launching it from within
Eclipse IDE  it may be listed in your Java Runtime configuration.

Some versions of Java 7 certainly do have pulse-java.jar.  It is in
"ext" directory, so it is not part of the core JRE, but an extension.
Maybe there is a separate package that installs it?

Quick googling finds a mention that it was removed between 7u51 and 7u71.
https://bugs.launchpad.net/ubuntu/+source/openjdk-7/+bug/1389493

3) Consider upgrading your Tomcat version.
https://wiki.apache.org/tomcat/FAQ/Linux_Unix#Q5

Current versions of Tomcat 7 do not scan pulse-java.jar for TLDs.

A) since 7.0.30 (r1377297) pulse-java.jar is explicitly included into
tomcat.util.scan.DefaultJarScanner.jarsToSkip value in
catalina.properties

B) since 7.0.38 (r1448831) Tomcat skips scanning of all JRE JARs as a whole.

4) The warning message and OOM are different errors. They are likely
not related. You have not cited the actual OOM message.

Though unneeded scanning of some large jar files is a waste of time
and may require a lot of memory. You can configure what files are
skipped via above mentioned
"tomcat.util.scan.DefaultJarScanner.jarsToSkip" setting.

>
> I'm using a Debian GNU Linux 7 VM, running version.sh of Tomcat7 yields...
>
> Using CATALINA_BASE:   /usr/share/tomcat7
> Using CATALINA_HOME:   /usr/share/tomcat7
> Using CATALINA_TMPDIR: /usr/share/tomcat7/temp
> Using JRE_HOME:/usr/lib/jvm/java-7-openjdk-amd64
> Using CLASSPATH:
> /usr/share/tomcat7/bin/bootstrap.jar:/usr/share/tomcat7/bin/tomcat-juli.jar
> Server version: Apache Tomcat/7.0.28
> Server built:   Apr 8 2014 08:47:08
> Server number:  7.0.28.0
> OS Name:Linux
> OS Version: 3.2.0-4-amd64
> Architecture:   amd64
> JVM Version:1.7.0_65-b32
> JVM Vendor: Oracle Corporation
>
> Tomcat7 was installed using apt-get. With the default memory settings
> (around line 271 in catalina.sh) as follows...
>
> CATALINA_OPTS="$CATALINA_OPTS $JPDA_OPTS"
>
> The above error occurs.
>
> When I made the following changes... (below) the error goes away
>
> CATALINA_OPTS="-server $CATALINA_OPTS -Xms512m -Xms2048m
> -XX:MaxPermSize=512m -Dcom.sun.management.jmxremote"
>
> My question... pulse-java.jar does not exist in Java 7 although it did in
> Java 6. In Java 7, it is provided by a different file. It appears that the
> shortage of allocated memory manifests itself as a missing file. Has anyone
> else found anything like this or used a different solution to fix it?


Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Is there a way to abruptly force a connection closed without returning anything?

[André Warnier]

Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jesse,

On 1/13/15 6:29 PM, Jesse Barnum wrote:

I need the ability to examine the POST data from a request,
examine it, and either respond to it or close the connection
without returning any result, not even a 200 OK status.

The reason for this is because I’m getting overwhelmed with
thousands of invalid requests per second, which are racking up
bandwidth fees. The requests can’t be traced to an IP address, so I
can’t just block them in a firewall or Apache - I need to actually
use logic in my Tomcat app to figure out which requests to respond
to.

Is there a way to force Tomcat to just drop the connection and
close the socket without sending a response?


You can't close the stream form your code, Tomcat will ignore it, so a
response flush, and return a 200 response anyway.

I'm curious, what's wrong with an empty 200 response? It's only a
couple of bytes, but I suppose if you are getting millions per hous,
you could still incur bandwidth costs...

You might be able to do this with a Valve, but then you might have
problems with your web application needing to provide the logic to
determine whether or not to accept the request.

When you say "can't be traced to an IP address" do you mean that you
are seeing invalid requests coming from all over the place, or that
the requests don't include a source IP address (which seems fishy)?

A few options that might achieve your goal without using the technique
you describe:

1. Use client authentication; unauthorized clients can't even handshake
   Downsides: SSL overhead

2. Use a VPN (which essentially uses client authentication)
   Downsides: VPNs really, really suck

3. (As Mark E suggests) Use mod_security with httpd
   I know this will seriously separate your business logic form your
web application, but perhaps there is a simple set of criteria that
might eliminate a significant portion of the requests, thus solving
the problem "well enough"



I have an additional suggestion, harking back to a time when I was trying to convince the 
Apache httpd devs to implement something like this in .. Apache httpd.
By experience with trying to convince people, I know that this is controversial, so hold 
on tightly and follow the gist.  You can always decide by yourself if this is appropriate 
for your case.


The idea is this : when you get such a request, and you decide that it is invalid, return 
a 404 "not found", but delay it by some random number of seconds.

(do a random sleep in your webapp, or in a filter after the webapp).

The rationale of this is as follows : most such requests - if not all - come from 
automated nefarious agents, which try to break into your server (and others) by finding 
some weakness.
They work on the base of a list of IP's (or hostnames) and use potentially many infected 
hosts to issue such requests.  When one of these agents does find a "hit" (a URL which 
actually looks weak), it phones it back to Mamma, which can then mount a more serious 
attack.  The strategy works, because each missed request (to a well-protected server) 
usually only takes a few milliseconds to send and get a response, so these agents can do 
thousands of them in a reasonable timeframe.


But..
If it was so that each target took a long but unpredictable time to respond (only for 
those bad requests), by a legitimate but slow response, then these agents would have a 
major problem, because given the same attacking resources, they could only achieve a small 
fraction of the probes that they intend to do.
And, this should not bother legitimate accesses by legitimate applications very much, 
because these legitimate applications send overwhelmingly "good" requests (so they get a 
normal answer time).


The only serious drawback (at least in my view), is that you have to provision on your 
server a sufficient amount of response threads, to do this "sleeping" for bad requests, 
while continuing to serve legitimate ones.
But it might be possible to design a clever scheme by which such sleeping webapp instances 
would consume a minimal amount of resources while doing so.
(Mabe such as internally dispatching the bad requests to some special webapp which handles 
this at low cost).


The long-term hope of course would be that if a sufficient number of webservers on the 
Internet came to adopt similar practices, this type of robot scanning may become so 
impractical for their originators, that it would be abandoned.
The short-term hope is that if attackers notic that your website is such a "sink", they 
may just take it out of their list of targets, so as not to slow down their whole 
nefarious scheme.






-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Memory shortage appears as missing pulse-java.jar file error with Java 7

[Peter Lavin]

Hi André, thanks for your reply.

well spotted, I've corrected my Xmx/Xms error and restarted.

On 13-01-2015 14:07, André Warnier wrote:

Peter Lavin wrote:
Tomcat7 was installed using apt-get. With the default memory 
settings (around line 271 in catalina.sh) as follows...

CATALINA_OPTS="$CATALINA_OPTS $JPDA_OPTS"
The above error occurs.
When I made the following changes... (below) the error goes away
CATALINA_OPTS="-server $CATALINA_OPTS -Xms512m -Xms2048m


a typo here ? (2 times -Xms ..)

and, what was in $JPDA_OPTS ?



To your clarification...

JPDA_OPTS is set as follows (i.e. the default, just before line 270, I 
did not change this)...


="-agentlib:jdwp=transport=$JPDA_TRANSPORT,
address=$JPDA_ADDRESS,server=y,suspend=$JPDA_SUSPEND"

regards,
Peter

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Web filter to forward some requests to another remote webserver

[Jose María Zaragoza]

Hello:

I would like to create a web filter to forward some requests to
another webserver,

The filter receives an "application/x-www-form-urlencoded" request ,
inspects the value of a parameter and chooses to forward to another
remote webserver ( as a proxy )

I've seen some posts where they open a HttpURLConnection to remote
server and send the request. This is right for me, but I'd would like
if there is another way ( easier ) to implement it.

Thanks and regards

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org