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
Related
Environment
JDK 1.8
Tomcat 7.0.55
A spring web app
Chef scripts for deploying
What's the issue
The application is deployed via chef and most of the times everything is fine. Except for 1 in 10 times or so the web.xml (under appbase webapps/myapp/WEB-INF/web.xml) goes missing during redeployment which causes the application not to start up.
This symptom disappears in eventual chef-runs adding to the peculiarity of the issue.
My investigation till now
Ruled out any chef aspects from the problem . Was able to confirm that the scripts are doing what they are suppose to do - delete old war DIR -> unzip new war DIR in place(we use exploded war's) there by causing un-deploy of old and deployment of new.
Next point of investigation was to see if the tomcat is deploying the new web app even before its completely unzipped or extracted - this was not the case as confirmed by time lines on the logs.
We do not have jar's getting locked - so ruled out any issues caused by such scenarios.
All of the symptoms I see now points towards tomcats auto deployment policies - but was not able to see anything here which would cause such kind of inconsistency - Have gone through tomcat bug list sniffing for any compatibility issues but was not able to find any.
Am putting it out there to see if any one else is facing similar issues - any thoughts are welcome. Let me know if you need any more information
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.
My setup is as following:
Production web server with Glassfish 3.1.1 wrapped into a windows service.
Developing environment with Netbeans 7.1 with the included Glassfish server.
I thought a valid way to deploy updates to production server was to copy the content of the Netbeans /build directory and it worked well many times.
Unfortunately I experienced a major problem, described in the link below, where new roles were not recognized because glassfish had cached data somewhere else.
Glassfish: how to investigate roles/groups problems
I checked the Glassfish configuration a lot but couldn't find any parameters like 'rebuild cached data at the server start'. So my question is how can I deploy updates in my production server being sure that my changes will not be invalidated by pre-compiled cached data ?
Thanks
Filippo
When I add a new server (glassfish) or another, it works just fine. I can startup the server and deploy apps on it.
But, every time I restart netbeans the added servers are not there. It means I must add servers every time I open netbeans.
I'm using netbeans7.
Thanks.
Well, it is not happening any more on netbeans 7.2. If it was a bug, it has been fixed.
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.