> > All, > > 16 emails into this chain - might be worth a summary > > 1) You have tomcat 6.0.29 running on virtual machines running on win 2008 > 2) You have a load balancer which calls a home made xslt transform, that > queries the database. If this fails 3 times in a row, the load balancer > treats the machine as dead > 3) When you move one virtual machine to another machine, the custom code > stops working, hence the load balancer assumes that the new virtual machine > is dead, hence the issue > > IMO this covers all the salient facts so far stated. >
Good summary. :] just want to add that sometimes it is dead, the keep alive get page 500 and stays like this (this is the behavior while disconnect and reconnect the network card when the server is out of the LB pool), and sometimes it's page 500, then ok state, then page 500 again, then ok - until I restart the tomcat and then it's settled (this is the behavior while disconnect and reconnect the network card / migrate to another esx , when the server is part of the LB pool). > The problem is clearly that the pool doesn't test the connections when it > lends them. You say that you are unwilling or unable to alter this by > configuring test on borrow and using dbcp. The alternative seems to catch > the exception in your custom code, and get it to re-initialize the database > connection pool. You will effectively just re-implement the connection > pool, > but if you won't use the existing one doesn't seem much else to suggest > > I haven't understood the part in purple. can you explain? and for the sake of trying, I will configure test on borrow and see what happens. > Personally I'd be interested in determining what specifically is wrong with > dbcp for your environment. Works fine for me and many others on this list I > would wager. Assuming that you can recreate the dbcp issue off production, > what symptoms do you get? Could you post the full resource element from the > context.xml section? > we used dbcp connection pool for several years now, but on November we got a requirement to switch the user that runs the tomcat service, from local system to a domain user. when did that, it generated a memory leak (not sure if just because of it, or also because of the ntlmauth.dll use). we searched for a solution to the memory leak for couple of months, until I ran into the JDBC connection pool. I switched to using the JDBC connection pool, with still using domain user to run the tomcat service, and the memory leak disappeared. No problem to do it on production, I can pull out the server from the LB and test it. that's what I did to see if it happens only on migrate to another esx, or even when disconnect and reconnect the network card. even if the server is out of the LB pool, it still can connect to DB and the keep alive can still show OK (or not, if the server/DB is not functioning). the difference is surfing to keepalive.xml when it's in the LB pool, and surfing to _keepalive.xml when it's not in the LB pool. I will post the resource element from the xml file on Sunday (it's weekend here, so we don't work). On Sunday I'll also try adding testonborrow to the resource tag and see if the issue still occurs. if so, I'll proceed to check the DBCP pool with this issue. > > Sure, add some extra variables to the problem. That will make it a lot > > > simpler to find out what happens. > > > > > > no need of sarcasm here. > > > > Most|all the people on this list are doing this for the love of it - as I > understand it nobody is paid to do it. I would heartily encourage all the > humor possible to make this more fun for everyone :-) > Oh well.. :] > > Chris >
