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

Reply via email to