tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Application crash after Migrate to different ESX
Date Fri, 20 May 2011 07:01:12 GMT
הילה wrote:
>> So, if you are using that pool, I basically do not understand why you would
>> need any additional mechanism to overcome the loss of a db connection when
>> your VM is migrated.
>> Particularly that "smart keep alive" you keep talking about, but never
>> telling us where it comes from and where it is inserted in that
>> architecture.
>> I don't understand on what mechanism are you talking about. I don't want to
> add anything (unless it can fix the problem)
> I just stated the problem, and the environment we have (win 2008, tomcat
> 6.0.29, jdbc pool.. These are the dry facts)
> The keep alive is an xslt file which contains actions to perform on the DB
> to check that everything is alive.
> if so, it returns an OK response, which can be viewed in HTML file on IE
> browser.
> The Load balancer samples the keep alive every 10 seconds to check the OK
> state. if it's not OK for 3 times in a row- the LB takes it out from the
> servers' pool and no one else can connect to it.

So now there is also a load balancer ?  I've just gone through all your previous posts, 
and this is the first time it has been mentioned.
And it appears that it is the load balancer which tests de DB server directly (?)
Huh ? I'm like Chris now, just a bit confused again about your setup.

> so yes. we need this keep alive and can't dismiss it, because it's the
> indication that the server is functioning properly. 

Which server ?

and if it's not function
> - The LB can identify it and remove the server from the servers' pool so no
> one will try and approach it.

Again, which server is taken out of the server pool ?  The DB server, or the one running 
Tomcat ?

Do you actually mean that the load balancer on one side, and Tomcat on the other side, are

each accessing the DB server in parallel and by different channels ?

>>> we use the JTDS driver (I tried the Microsoft JDBC, but its performance is
>>> poor compared to the JTDS driver of sourceforge)
>>> Someone in my company suggested that the problem can rely in either of
>>> these
>>> JARs.
>>> so I will check with the tomcat-dbcp.jar as scenario 1, sql-jdbc.jar as
>>> scenario2, and maybe both combined as scenario 3.
>>> scenario 4 will be testing the behavior while validation is configured.
>> 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. these aren't additional variables. we spoke on the
> connection pool, so this is one of the things I can focus on to try and fix
> the problem.
Yes, that was sarcasm. I was just getting a bit frustrated, because I am trying to help, 
but it seems impossible to get logical explanations here even about your exact configuration.

So let me try again, graphically.
As far as I can tell by your posts, your configuration is :

hardware :
- Vmware VM with your application and Tomcat and jdbc pool and jtds drivers
- network
- another machine with the DB

and, somewhere, there is a load-balancer with a "smart keep alive" feature built-in.

logical :

Application <--> Tomcat <--> jdbc pool <--> jtds driver <--> network
<--> database

At the start, the jdbc pool contains for example 10 connections to the database.
At some point, there is a network problem, and as a consequence 5 of these connections are

broken.  But the jdbc pool is not configured to detect this in advance, and as a 
consequence, when the application tries to use a DB connection, it may get one of the 5 
pooled connections which are broken, and it then gets an exception and breaks down.
Or it may get a pooled connection that is not broken, and then everything appears to work


Now can you tell us where in the above schema the "smart keep alive" fits in ?

Or else, correct the above schema to tell us how things really work ?

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message