Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: domain of kumarkmmca@gmail.com designates
 209.85.216.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <8175F68C-E9CC-4CC3-9F61-9C18B6D8B21C@gopivotal.com>
References: 
 <CAAU8gB4zR43qTx+h+hE3_pgQsh0a0BY6iENntzT6F0qDTmiKKw@mail.gmail.com>
	<52F8FE1D.50008@christopherschultz.net>
	<CAAU8gB4XKZvjW1Jcyj1qF0qKu4m7TWhoGyBK=AZcShPAtJ5Nsw@mail.gmail.com>
	<13C3CD27-78E8-4B8A-B249-63477CCCF577@gopivotal.com>
	<CAAU8gB6r4P2R9hTz7C6pMJb6jYbKE9a_s9kvcWTvoxvNvm9eFg@mail.gmail.com>
	<09DE390D-0EF9-495B-B2DA-C14B89C6D778@gopivotal.com>
	<CAAU8gB5hu2fmbi2P2JWRyydTBjMQ57-43EGw16iWuKVG1ooXFg@mail.gmail.com>
	<8175F68C-E9CC-4CC3-9F61-9C18B6D8B21C@gopivotal.com>
Date: Mon, 10 Feb 2014 19:22:36 -0500
Message-ID: 
 <CAAU8gB5-SO-h9GjM4_NnLKY8cSXmejTH0C-G5qMNfdU7CsqjHA@mail.gmail.com>
Subject: Re: sudden increase in tomcat sessions..?
From: Kumar Muthuramalingam <kumarkmmca@gmail.com>
To: Tomcat Users List <users@tomcat.apache.org>
Content-Type: multipart/alternative; boundary=001a11c16f5efe252504f216733b

--001a11c16f5efe252504f216733b
Content-Type: text/plain; charset=ISO-8859-1

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 ?

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:
> >>>>>
> >>>>>> -----BEGIN PGP SIGNED MESSAGE-----
> >>>>>> 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 - http://gpgtools.org
> >>>>>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> >>>>>>
> >>>>>> iQIcBAEBCAAGBQJS+P4dAAoJEBzwKT+lPKRYmHUP/1JzT1aYbqq3CWq8bzJsEKtX
> >>>>>> LTiNknxXUBmhQE1WZ5J+4f2Pq/7spUD0rOGtkvYyuGw37+ruL0AGJSiEzQ2uA6mD
> >>>>>> rtylt5IzGO4jjW2Yqr4LlDKmXhBr0IDj4+Xz1KT4W7R7XDY6gNIfN1d8CuAAAP0F
> >>>>>> BKSLj3crNEmDur+hd0SH3m+oNKYpgy/xVfvWN2MohBY4rIAPpGvmS9IJDeKaWyHY
> >>>>>> +SZYsyN6bKExWCqaQbObL7ZjHwLhC+hLECEDHFNiZje5dCyKMaALVJYNkaB/jzWw
> >>>>>> ZLv3FNyTpG35hhBM1j760C+37ZkRt34+rER7ZBBEODfgoxQSGb59Fe9uCtX8aVa4
> >>>>>> 9ATxQ8RAqJcMaCgJ6ADTiJhf91MGbPtWJ5ABwqzg8iP650gUcF6RiRWPFdpq1k33
> >>>>>> 6SCGeEwHoIMuzCvnp1EiaxXaDFQ1NUYhCz5fEkAeYmZlgl/SlTHrvhe5lTyMQ179
> >>>>>> CeccAWjrO1UhyJz5bS9pt8l5xzsVAFxlVCk67rLwffAhWxZb6EmrsclTlBaxDyFL
> >>>>>> jx6+UH7SADWi0xaGk3LdBdCWHaJRT5F9StPsAReUP/mPpJVVWR6u9x/V1i4HrZX6
> >>>>>> /06jj3RCUBxGPKMk6OlidZDQj9XcKMR1CuDeq+ItfzXKg8rgj3C5FaZXUsNYCNTV
> >>>>>> LgJmIZUtom+YKPoikzQB
> >>>>>> =2HLh
> >>>>>> -----END PGP SIGNATURE-----
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> 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
>
>

--001a11c16f5efe252504f216733b--