tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: sudden increase in tomcat sessions..?
Date Tue, 11 Feb 2014 18:31:11 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Kumar,

On 2/11/14, 11:56 AM, Kumar Muthuramalingam wrote:
> what I mean is if I am supposed to get a response for that
> Update.jsp file and I didn't get it for a while. Will the load
> balancer will check for it connectivity? Is there any timeout set
> for load balancer to get response.

Load balancers typically continuously check for connectivity. It might
use a particularly long request to trigger a re-check, but only you
can answer that: we don't know what lb you have, what the
configuration is, etc.

- -chris

> On Tue, Feb 11, 2014 at 8:13 AM, Daniel Mikusa
> <dmikusa@gopivotal.com>wrote:
> 
>> On Feb 10, 2014, at 7:22 PM, Kumar Muthuramalingam
>> <kumarkmmca@gmail.com> wrote:
>> 
>>> Before that can you tell me one thing please. Suppose if a page
>>> request (eg. /UpdateQuery.JSP) is coming from a load balancer
>>> to tomcat and the UpdateQuery.JSP is connected to some third
>>> party server. Assume if the tomcat is not getting any reply
>>> from the Query server for some seconds. Will the load balancer
>>> will send ping requests to tomcat to verify the connection of
>>> the application ?
>> 
>> I've never seen a load balancer that works like that.  Usually
>> they just request a singe resource on a repeating cycle, like
>> every second or two.  I guess it really depends on your load
>> balancer though.
>> 
>> Dan
>> 
>>> 
>>> Thanks Kumar.
>>> 
>>> 
>>> On Mon, Feb 10, 2014 at 4:21 PM, Daniel Mikusa
>>> <dmikusa@gopivotal.com wrote:
>>> 
>>>> On Feb 10, 2014, at 4:07 PM, Kumar Muthuramalingam <
>> kumarkmmca@gmail.com>
>>>> wrote:
>>>> 
>>>>> Yes its the load balancer. and recently I found in the log
>>>>> that there
>>>> was a
>>>>> memory leak exception while the tomcat server was
>>>>> restarted.The session increase problem started from this
>>>>> particular date . Could this be a
>>>> cause
>>>>> for the tomcat to hang up and DOS occurred?
>>>> 
>>>> Can you include the message you saw?  Otherwise it's tough to
>>>> say.
>>>> 
>>>>> One more question. I see this memory leak exception in only
>>>>> one tomcat catalina log file. I didn't see this in other
>>>>> servers log file. One
>>>> tomcat
>>>>> can handle 200 sessions. So once if it reaches the limit
>>>>> will the
>>>> requests
>>>>> will get diverted to other available servers so that the
>>>>> server
>> sessions
>>>>> also will increase? If so how to find that redirection in
>>>>> log file.
>>>> 
>>>> You'd want to look at how your load balancer is setup.
>>>> Tomcat just handles the requests that you send to it.  If you
>>>> want to control how requests are delivered to multiple Tomcat
>>>> servers then you need to do
>> that
>>>> before the requests hit your Tomcat servers, like with your
>>>> load
>> balancer.
>>>> 
>>>> Dan
>>>> 
>>>>> 
>>>>> Sorry if I 'm crazy.
>>>>> 
>>>>> Thanks, Kumar
>>>>> 
>>>>> 
>>>>> On Mon, Feb 10, 2014 at 2:19 PM, Daniel Mikusa
>>>>> <dmikusa@gopivotal.com wrote:
>>>>> 
>>>>>> On Feb 10, 2014, at 1:59 PM, Kumar Muthuramalingam <
>>>> kumarkmmca@gmail.com>
>>>>>> 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.
>>>>>> 
>>>>>> Dan
>>>>>> 
>>>>>>> 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 <
>> dmikusa@gopivotal.com
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> On Feb 10, 2014, at 11:56 AM, Kumar Muthuramalingam
>>>>>>>> <
>>>>>> kumarkmmca@gmail.com>
>>>>>>>> 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 < chris@christopherschultz.net> wrote:
>>>>>>>>> 
> 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
>>>>>>>>>> 
>>>>>>>>>> 
>>>> ---------------------------------------------------------------------
>>>>>>>>>>
>>>> 
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>> users-help@tomcat.apache.org
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>> ---------------------------------------------------------------------
>>>>>>>>
>> 
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>> For additional commands, e-mail:
>>>>>>>> users-help@tomcat.apache.org
>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> 
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail:
>>>>>> users-help@tomcat.apache.org
>>>>>> 
>>>>>> 
>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>>
>>>> 
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail:
>>>> users-help@tomcat.apache.org
>>>> 
>>>> 
>> 
>> 
>> ---------------------------------------------------------------------
>>
>> 
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>> 
>> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJS+mxsAAoJEBzwKT+lPKRY+pcP/R7CUOIr3BgpI3iOodKP1Rze
nAf/+sSyULzgfv0VBh+RQwcM3iq+2/rgGdv1Hl8Is2A3v9gA4RBWhqU0dq5AZdBM
zDAWQoDfj/MOIHPvqsuAH7DdzyvH5frcpgCAGhQk5RThKSlQNJgzsOTOsdWRUx1Y
RHccZ2ZfqKVhzDxeSuG/YYZ9P70U3QrpuqchV7YyI3l+eFdrr+VdjW3wfc4To3hy
LqNn7Hy5ztafxcfo/PlDYt7X/uVOT/3oAhfdyvb9Qaj0LX2MjPJSbXlSn0sYBDwx
gKGaWUotC375oV67/4XMdb0VBf1pIjB1V8AmnzSkrtbf+L8HaMABxprjJCK8ul8o
VjmHiRUzrndEbSHy15JivLx2CRqJCYmAK9ZLIcdC1H7imHLnYdyPimqj2KBOVIDq
IVPeplyFbYraS3VH1tfZJ4o6eykTY5GupBrZMEK4MJ+hPDBmSsY78g9jSIQA7dU4
8wHlvsTWwFzJrY/cIi1y0pU/MxFwo6N/6TZVEBOmVsbDBhp1nX6YlkORbKtnc4c9
xljlI8NR5+ss/btYmTkchP6TzUlzx6uVnAZ2VEinpo1vvuScjrj1EWPmXKA1xl0i
DWdFC3LHWrOyrZZJ5bpncVtGkhM7in1ML25aFn8JSY+cKTS1AfaUbk+GJXg0Tb2m
XKMTYcnAzexoqiZaMpTH
=JpTC
-----END PGP SIGNATURE-----

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


Mime
View raw message