הילה 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
fine.
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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
