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
