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?
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. Sorry if I 'm crazy. Thanks, Kumar On Mon, Feb 10, 2014 at 2:19 PM, Daniel Mikusa <dmik...@gopivotal.com>wrote: > On Feb 10, 2014, at 1:59 PM, Kumar Muthuramalingam <kumarkm...@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 <dmik...@gopivotal.com > >wrote: > > > >> On Feb 10, 2014, at 11:56 AM, Kumar Muthuramalingam < > kumarkm...@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 < > >>> ch...@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-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 > >> > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
