tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kumar Muthuramalingam <kumarkm...@gmail.com>
Subject Re: sudden increase in tomcat sessions..?
Date Tue, 11 Feb 2014 16:56:05 GMT
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.

Thanks,
Kumar.


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:
> >>>>>>>
> >>>>>>>> -----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
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message