I'm running on Win 7 using Eclipse 4.2 starting a web app on a Tomcat 7 server and using Derby database. I have tried many approaches but run consistently into a common problem:
Everything works just fine the first time I start up and run.
When I redeploy my application after a change, all database connections hang (any kind of restart).
If I stop Eclipse and restart Eclipse, that clears up the problem and the next run works fine again.
Having done some investigation, it appears that the problem is that the Derby port (1527) is not released from one execution of the server to the next. That seems very strange to me since Derby is started by the Tomcat instance which is a separate javaw process.
I've tried:
Configuring the Derby connection as a Tomcat resource
Establishing the connection within my code (rather than via Tomcat resource)
Both the embedded and the network driver
Starting / stopping the network driver from a servlet on startup and shutdown of the Tomcat server
Shutting down the embedded driver via servlet on shutdown of Tomcat
Again, every approach works fine to connect the first time.
One other symptom that doesn't appear to be related (except for as a possible indicator of whether or not shutdown completes correctly) is that the db.lck file for my database never gets deleted. However, whether or not it exists has no bearing on whether or not I can reconnect (only stopping/starting eclipse has an impact).
Any insight would be appreciated.
Thanks!
After some further investigation I'm going to call this a duplicate of: Cannot create JDBC driver of class ' ' for connect URL 'null' : I do not understand this exception. It's not quite the same thing, but that solution (creating META-INF/context.xml) allows it to proceed to failing calls rather than hangs, which is a significant improvement and suggests it's largely related.
I did finally figure this out. It turns out I had the derby jars in the Tomcat lib folder (for Tomcat) and in the deployment assembly for my application in Eclipse (rather than just in the build path). So Tomcat was using the built-in libs, while my app was using the embedded libs, and this resulted in conflicts. Leaving the libs as part of Tomcat and removing them from my war file solved the problem completely.
Related
I'm running Tomcat 8.5 in Eclipse 2019.3:
Every time I restart a Tomcat instance by clicking the green circle/triangle button, I end up with duplicate instances running:
How can I stop this from happening?
Here's some things I've already tried:
I tried upgrading to tomcat 9.0, it didn't help. This is the reason you see a couple of 9.0 configurations in a Stopped state.
I tried splitting up my application into two smaller apps, it didn't help. This is the reason you see two different Tomcat configurations of each version.
This turned out to be a coding issue! Once a Servlet Filter responsible for logging was removed, the problem went away. I presume that the Servlet Filter created a non-daemon thread that prevented termination of Tomcat, but I didn't dig deeper to confirm.
I am currently working on a web based application using Glassfish. Therefore I have to implement functionality, compile/package it (using maven), deploy the .war file on a glassfish server, test it and undeploy it again to start a new cycle.
My problem is, that Glassfish won't undeploy my .war file under Windows 7. Undeployment takes about 3 minutes and does not remove all deployed files in /glassfish/domains/myDomain/applications. It generates a .glassfishStaleFiles.
To deploy again, I first have to delete the content of /glassfish/domains/myDomain/applications entirely.
Obviously this takes too long and I need to do this many times a day while implementing.
BUT: It all works fine when using Ubuntu. Clean and fast undeployment and deployment.
Thanks in advance
This is a known issue with GlassFish, due to the way file handles are dealt with in Windows compared to Linux. If some process has a file open in Windows, then that will prevent deployment. There are lots of these edge cases in GlassFish many of which (perhaps all) have been fixed in Payara Server, which is derived from GlassFish. Payara Server is free, so I would recommend trying the latest version 4.1.2.174 to see if the issue is resolved there.
Here is an example of some of the fixes for these kinds of issues in Payara Server:
https://github.com/payara/Payara/pull/467
I'm starting to move from visualvm to java mission control. I use wildfly 8.2, which doesn't work with JMC out of the box, but have modified the JMC ini to include the required class path as per my answer in the jboss community https://developer.jboss.org/message/955742#955742
I've been able to connect successfully, however the time it takes to connect is ridiculous. Often waiting 1-10 minutes (during which time jmc often becomes unresponsive) when connecting to a local wildfly instance, it's almost instant, the delay happens only when connecting to a remote instance.
Does anyone know what would cause this to be so slow, and if anything can be done to sort it?
I'm having the following problem with Eclipse 3.7 and Tomcat 7.0.8: I've added my Tomcat with a deployment descriptor in my Eclipse. I've enabled "Use Tomcat installation" in the server settings and tried to start it. The Console in Eclipse says "Server started up in 70s", I can access my application, but the servers state remains "Starting/Synchronized". As a result sooner or later the configured timeout is triggered and I'm getting an error.
Why is Eclipse not recognizing that the server was started successfully?
I've also tried to reinstall Eclipse and Tomcat - no positive changes.
Also adding a clean, fresh downloaded Tomcat results in the same "error".
Any suggestions?
Richard
Try changing the HTTP port from the server configuration screen. For example if you previously had 8080, try changing it to 8090. This should automatically update the new port number to server.xml.
I started running into the same problem after I had been modifying the server port directly in server.xml. Changing the ports back to what they had been did not seem to solve the problem. It looked like the server pluging and actual configuration got somehow out of sync.
A strange problem occurred yesterday on a production system which has been running fine for weeks on a JBoss 4.2.3 application server: the JAR file containing the web application was no longer in the deployment folder (so the clients could no longer access the application). The server is running on a Windows box.
There was no indication of undeployment in the server logs. Normally JBoss detects if somebody deletes (or moves) a deployed web application file and executes the standard undeployment procedure, so there would be a log entry in this case.
Other web applications on the same system continued to run fine, so it was only this JAR file which simply disappeared.
Has somebody seen a similar problem with web applications on JBoss?
I'd bet my shoes that's not possible to happen spontaneously.
Check your security settings - didn't you leave JMX console accessible? Etc.