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 <dmik...@gopivotal.com>wrote: > On Feb 10, 2014, at 7:22 PM, Kumar Muthuramalingam <kumarkm...@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 <dmik...@gopivotal.com > >wrote: > > > >> On Feb 10, 2014, at 4:07 PM, Kumar Muthuramalingam < > kumarkm...@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 <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 > >>>> > >>>> > >> > >> > >> --------------------------------------------------------------------- > >> 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 > >
