Return-Path: X-Original-To: apmail-tomcat-users-archive@www.apache.org Delivered-To: apmail-tomcat-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 0174E4010 for ; Tue, 17 May 2011 14:09:36 +0000 (UTC) Received: (qmail 29278 invoked by uid 500); 17 May 2011 14:09:31 -0000 Delivered-To: apmail-tomcat-users-archive@tomcat.apache.org Received: (qmail 29205 invoked by uid 500); 17 May 2011 14:09:31 -0000 Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Tomcat Users List" Delivered-To: mailing list users@tomcat.apache.org Received: (qmail 29161 invoked by uid 99); 17 May 2011 14:09:31 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 17 May 2011 14:09:31 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of aw@ice-sa.com designates 212.85.38.228 as permitted sender) Received: from [212.85.38.228] (HELO tor.combios.es) (212.85.38.228) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 17 May 2011 14:09:24 +0000 Received: from [192.168.245.129] (p549E8DEA.dip0.t-ipconnect.de [84.158.141.234]) by tor.combios.es (Postfix) with ESMTPA id 80AD72260D5 for ; Tue, 17 May 2011 16:08:59 +0200 (CEST) Message-ID: <4DD28179.8030203@ice-sa.com> Date: Tue, 17 May 2011 16:08:57 +0200 From: =?UTF-8?B?QW5kcsOpIFdhcm5pZXI=?= Reply-To: Tomcat Users List User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Tomcat Users List Subject: Re: Application crash after Migrate to different ESX References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit הילה wrote: > Hey Guys, > > My application runs on tomcat 6.0.29, win 2008 R2, which is a VM machine. > i use the JDBC application pool., with java 1.6.24 64bit. OK. > > I have a problem, in which after migrate of the VM machine to another ESX, > the application crashes, and doesn't recover by itself. Well, Vmware is good at that kind of thing, but it cannot do miracles, so one would kind of expect such behaviour. (I mean if an application dies, Vmware cannot resurrect it). > I know that after migrate, a disconnection is expected, but in my case - it > crashes completely, or alternately until it works (but don't know if it's > stable now). Now that is a rather obscure way of explaining the issue. We might need Konstantin again here. > when it's not working, i see via netstat a time_wait of the connection to > the DB. That is a normal TCP state. See e.g. : http://www.ssfnet.org/Exchange/tcp/tcpTutorialNotes.html (TCP STATE TRANSITION DIAGRAM). It happens for a short while just before a socket is closed. It is not the /reason/ for the error below. So ok, you move a VM somewhere else, while an application is running. For some reason, this causes a TCP connection to close, and as a result your application is getting the exception below. So what is the problem ? Can your application not catch this, and retry ? > > this is what displayed in the log- > > 2011-05-17 11:57:49,959 ERROR [Request-Processor3] > org.hibernate.transaction.JDBCTransaction - *JDBC begin failed* > * * > > *java.sql.SQLException: Invalid state, the Connection object is closed.* > > at > net.sourceforge.jtds.jdbc.ConnectionJDBC2.checkOpen(ConnectionJDBC2.java:1699) > > at > net.sourceforge.jtds.jdbc.ConnectionJDBC2.getAutoCommit(ConnectionJDBC2.java:2123) > > at sun.reflect.GeneratedMethodAccessor93.invoke(Unknown > Source) > > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > > at java.lang.reflect.Method.invoke(Method.java:597) > > at > org.apache.tomcat.jdbc.pool.ProxyConnection.invoke(ProxyConnection.java:125) > > at $Proxy0.getAutoCommit(Unknown Source) > > at > org.hibernate.transaction.JDBCTransaction.begin(JDBCTransaction.java:49) > > at > org.hibernate.transaction.JDBCTransactionFactory.beginTransaction(JDBCTransactionFactory.java:24) > > at > org.hibernate.jdbc.JDBCContext.beginTransaction(JDBCContext.java:271) > > at > org.hibernate.impl.SessionImpl.beginTransaction(SessionImpl.java:1079) > > at > com.vsgaming.app.appContext.getDatabaseConnection(appContext.java:296) > > at > com.vsgaming.system.SystemMethods.health(SystemMethods.java:383) > > at > com.vsgaming.system.SystemMethods.processRequest(SystemMethods.java:146) > > at > com.vsgaming.app.appServlet$RequestProcessor.processStandardCompositeRequest(appServlet.java:1547) > > at > com.vsgaming.app.appServlet$RequestProcessor.processLoadBalancedCompositeRequest(appServlet.java:1727) > > at > com.vsgaming.edge.appServlet$RequestProcessor.processCompositeRequest(appServlet.java:1449) > > at > com.vsgaming.app.appServlet$RequestProcessor.processRequestThread(appServlet.java:1372) > > at > com.vsgaming.app.appServlet$RequestProcessor.run(appServlet.java:1338) > > at java.lang.Thread.run(Thread.java:662) > > > I also noticed that servers that were migrated that has the APR native dll > installed, reacted better than the one without the APR native dll (I don't > know if it's related, but this is the only difference between the servers > that I could think of). > > > > has someone experienced this issue? > > how can I solve it? > > > Thanks > > Hila > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org For additional commands, e-mail: users-help@tomcat.apache.org