tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Mikusa <>
Subject Re: sudden increase in tomcat sessions..?
Date Mon, 10 Feb 2014 19:19:53 GMT
On Feb 10, 2014, at 1:59 PM, Kumar Muthuramalingam <> wrote:

> Thanks for the reply. I accept this remedy will clear the issue. But my
> question is how to verify the root cause of this DOS attack that occurred
> earlier?

As previously directed, look at your access logs.  That should show you who is requesting
this JSP file.

If it’s your load balancer (or some other trusted IP), then problem solved.  Just correct
the JSP.

If it’s a third party then in additional to fixing the JSP, you’ll probably want to investigate
why they’re calling that JSP so much.  I suppose you could even go so far as to blocking
them with your firewall or a filter, but that’s up to you.


> What ever steps suggested above is to take a precaution or solve
> the issue. please help me.
> Thanks,
> Kumar.
> On Mon, Feb 10, 2014 at 12:06 PM, Daniel Mikusa <>wrote:
>> On Feb 10, 2014, at 11:56 AM, Kumar Muthuramalingam <>
>> wrote:
>>> Thanks for your reply. I have 3 applications running under the tomcat and
>>> only one application got a ping.jsp file others don't. And also I could
>> see
>>> from the access logs that only the application that has got ping.jsp file
>>> was pinged others were not. And the sessions are high only for this
>>> particular application. Now I got something else in my mind. Is ping.jsp
>> is
>>> a mandatory file for tomcat. We got nothing in that ping.jsp. It 's an
>>> empty file with <%="OK"%>.
>> Seems like this could be the problem.  This JSP file is going to create a
>> session every time you "ping" it, since JSP files will create a session by
>> default.  If you're client, whatever is requesting this JSP, doesn't
>> maintain the session then it'll end up creating a new session every time it
>> requests the JSP page.
>> Add this and the JSP won't create a session.
>> <%@ page session="false" %>
>>> I agree this could be due to DOS attack.
>> If so, it would seem to be self inflicted.  Fix your JSP file and I bet
>> this problem will go away.
>> Dan
>>> Can we ask our network pupil to
>>> find if there was a network failure or delay happened. Can we find that
>> is
>>> my another question?
>>> Please help me.
>>> Thanks,
>>> Kumar.
>>> On Mon, Feb 10, 2014 at 11:28 AM, Christopher Schultz <
>>>> wrote:
>>>> Hash: SHA256
>>>> Kumar,
>>>> On 2/8/14, 7:08 PM, Kumar Muthuramalingam wrote:
>>>>> I 'm using tomcat version 6 and 7. One day there was a sudden
>>>>> increase in number of sessions in both tomcats. And all the
>>>>> sessions had no username, same lastaccessed time, same created time
>>>>> and the inactive time was 00:00:00. It is not happening always but
>>>>> it happens some times on some day. Can't predict. And We have set
>>>>> the idle timeout as -1 because we have to.
>>>> I have a suggestion for this: don't set the session timeout to -1
>>>> until the user has successfully authenticated.
>>>> Sessions can be created at any time, including before authentication.
>>>> You could add a Filter that detects sessions that are authenticated
>>>> without the -1 timeout and sets them to that value.
>>>> This would allow login-less sessions to expire naturally while
>>>> authenticated users would enjoy sessions that never expire.
>>>> (Honestly, sessions that never expire is probably a bad idea...
>>>> clients are disappear at any time and never come back. At least set
>>>> the session timeout to something hugely long like 5 days or something)
>>>>> When I try to dig the log. It showed that the load balancer IP was
>>>>> sending many ping requests to our application. Can anybody tell why
>>>>> this is happening and how can I find the cause?
>>>> The lb needs to ping your webapp all the time to see if it's up.
>>>> Perhaps it's using a resource that (stupidly) always creates a session
>>>> if one does not exist?
>>>> - -chris
>>>> -----BEGIN PGP SIGNATURE-----
>>>> Version: GnuPG v1
>>>> Comment: GPGTools -
>>>> Comment: Using GnuPG with Thunderbird -
>>>> LTiNknxXUBmhQE1WZ5J+4f2Pq/7spUD0rOGtkvYyuGw37+ruL0AGJSiEzQ2uA6mD
>>>> rtylt5IzGO4jjW2Yqr4LlDKmXhBr0IDj4+Xz1KT4W7R7XDY6gNIfN1d8CuAAAP0F
>>>> BKSLj3crNEmDur+hd0SH3m+oNKYpgy/xVfvWN2MohBY4rIAPpGvmS9IJDeKaWyHY
>>>> ZLv3FNyTpG35hhBM1j760C+37ZkRt34+rER7ZBBEODfgoxQSGb59Fe9uCtX8aVa4
>>>> 9ATxQ8RAqJcMaCgJ6ADTiJhf91MGbPtWJ5ABwqzg8iP650gUcF6RiRWPFdpq1k33
>>>> 6SCGeEwHoIMuzCvnp1EiaxXaDFQ1NUYhCz5fEkAeYmZlgl/SlTHrvhe5lTyMQ179
>>>> CeccAWjrO1UhyJz5bS9pt8l5xzsVAFxlVCk67rLwffAhWxZb6EmrsclTlBaxDyFL
>>>> jx6+UH7SADWi0xaGk3LdBdCWHaJRT5F9StPsAReUP/mPpJVVWR6u9x/V1i4HrZX6
>>>> /06jj3RCUBxGPKMk6OlidZDQj9XcKMR1CuDeq+ItfzXKg8rgj3C5FaZXUsNYCNTV
>>>> LgJmIZUtom+YKPoikzQB
>>>> =2HLh
>>>> -----END PGP SIGNATURE-----
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:
>>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message