Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: domain of aw@ice-sa.com designates
 212.85.38.228 as permitted sender)
Message-ID: <4DD3A111.9090003@ice-sa.com>
Date: Wed, 18 May 2011 12:36:01 +0200
From: =?UTF-8?B?QW5kcsOpIFdhcm5pZXI=?= <aw@ice-sa.com>
Reply-To: Tomcat Users List <users@tomcat.apache.org>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Application crash after Migrate to different ESX
References: <BANLkTik60s_nP_C4JFbk60TRG-XJsGrQww@mail.gmail.com>
 <4DD28179.8030203@ice-sa.com>
 <BANLkTimmh9kLEpKXzPQGeEJM7pp9ap2d-w@mail.gmail.com>
 <4DD2E14C.7080005@ice-sa.com>
 <BANLkTik0Cc6LwqnbAtH8ZmR+RZAm2EgjtA@mail.gmail.com>
 <BANLkTimdJazuvD4Fh5NL2Vacsrk4sodpUQ@mail.gmail.com>
In-Reply-To: <BANLkTimdJazuvD4Fh5NL2Vacsrk4sodpUQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

הילה wrote:
> UPDATE-
> 
> this behavior occur even when I'm disconnecting the Network card from the VM
> settings and connecting it again.
> afterwards, the keep alive is alternately unavailable. looks like it's not
> always trying to approach the DB opened wireshark and saw that ip.addr==DB
> IP ADDRESS is not always showing results when the keep alive is unavailble =
> he's not trying to get to the DB at all, I think.
> 
> it all sorts out after I restart the tomcat service. this is why I think it
> does related to tomcat.
> 
Hi again.

First, nobody denies that you are seeing a problem, at some level.
But just as your expertise is probably at the application level, and the expertise of your 
in-house DBA team is at the database administration level, well the expertise of the 
people on this list is mostly at the Tomcat and java level, and that is the level at which 
this list may be able to help you resolve the problem, if the problem is at the Tomcat level.

In that sense, the fact that when you restart Tomcat (or rather, the JVM which runs 
Tomcat) the problem goes away, does not mean that it is "Tomcat's fault".  It just means 
that when you restart Tomcat, everything starting with your application and all the way 
down to the database network connections get reset and restarted from scratch.  No wonder 
everything works fine then of course.

Similarly, when you unplug and replug the network cable, everyone here would expect that 
some network connections may be lost in the event, and that this may cause problems to 
your application.

The issue here consists of determining what part, in the stack of pieces of code which are 
involved, should detect this loss of connection, and try to recover from it.
And if it is really a part of Tomcat which should do that, and it does not, then people 
here may be able to help, to the best of their abilities and (donated) free time.
And if it is not a part of Tomcat which should do that, but another piece of code, then 
the people here can only tell you to go to the mailing list of that other piece of code 
for help.

I am not a big Tomcat or java expert, so I am trying to look at this issue "top-down", in 
a generic way, in the hope of helping to narrow down the issue and maybe save some time 
for the real Tomcat/java experts here.
In your original stack trace, the only point where I see a Tomcat class involved is this one :
                 at
org.apache.tomcat.jdbc.pool.ProxyConnection.invoke(ProxyConnection.java:125)

Above that (in the stack), and apart from your own application, there are only Hibernate 
methods (a separate Apache project, as far as I know not part of Tomcat); and below that 
(in the stack), there are mostly jtds classes (a separate, non-Apache project).

So, from a naive point of view, what makes you think that when for some reason (good or 
bad) a network connection to the underlying database system gets lost or becomes unstable, 
it is the job of that single lone Tomcat class to solve the problem ?
I am not saying that it is not maybe a problem of that one Tomcat class; but what I am 
asking is what makes you so sure that it is ?

On a separate level, you have still not really explained what your "smart keep alive" is, 
or at what level it happens, or where that code comes from.
Except for this, which does not say much in terms of usable information :

"smart keep alive is a keep alive in its ordinary meaning. it called smart
cause it's not checking only the port and its availability, but also a
connection to the DB and functionality via DB query of some sort."

So at what level is that code running, and where does it come from ?
And can it be, in the logic of your hardware/software infrastructure, that it is that 
piece of code which should handle a temporary DB connection loss, and recover from it ?
Or should it be the jtds driver code ?
Or should it really be that org.apache.tomcat.jdbc.pool.ProxyConnection Tomcat class ?
What do you think ?
(I personally don't know.  I am just trying to help you narrowing dowen the problem, and 
maybe explaining to the Tomcat experts here why you think that they could be helpful).


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org