At a high level, what does JBoss 5's shutdown do? What might go wrong if I just kill the java process instead of gracefully shutting down JBoss?
A graceful JBoss 5 shutdown takes about 6 minutes for my application, which is pretty big and has 305 EJBs. JBoss seems to pause for a long time just before unbinding the EJB LocalHomes from jndi.
Given that, I am considering simply killing the java process. I am wondering about what might go wrong if I do that.
I run JBoss in mostly in *nix, sometimes in Windows.
Killing the process will leave the JBoss files in a potentially inconsistent state, and will certainly leave them in a messy state. When it restarts, it will probably clean up after itself OK, but then again it may not.
On Windows (you didn't say which platform you use), I've seen a killed JBoss process not release locked files properly, and the server won't restart at all. It's pretty rare, though.
In the end, if it works for you, the I wouldn't worry too much about it.
It releases all you connections such as jndi, jdbc, jms.. It also waits for your classes to finish up what it is doing. It also stops other services such as jms and web console
Related
We have an issue with undeploying an enterprise archive from Wildfly in a controlled matter. So the issue is that we automatically undeploy and deploy a new enterprise archive to Wildfly (Wildfly is also restarted). However, the issue is that we need to make sure that system goes down in a controlled matter so that state is not lost of corrupted.
This is normally done with a shutdown-hook, but that does not work well with Wildfly. When undeploy executes the shutdown-hook is executed, but Wildfly will not respect it. It will not give enough time to system to do clean up and threads to terminate.
So is there anyway to pause the undeploy or force Wildfly wait longer for the system to terminate before killing it?
We have an application on JBoss 7.1.0 istance, usually running ok but sometime the performance degrading, in this case a restart of JBoss is useful.
I have configured an access.log to record the timing of the pages and when the performance are degrading, we have an increase in recorded time on it for some pages.
How can I better identify and troubleshoot the problem? I think can be a problem related to objects in memory of JBoss server.
I exclude can be a memory issue on client because the access.log record the slow time, is it right or can I be misinterpreting the access.log and the problem can be also on client?
The ram / cpu on server are not under load when there are slowness and the xmx is oversized.
The JBoss is on Windows with JDK 1.7.0_80.
Thanks
UPDATE: Our degrading performance problem was related to an APM configured to record too much data and solved by removing it (are needed to be better configured).
I don't think JBOSS server has a problem. By reading your statement, I think the your code is leaking connections. Login into JBOSS Console and see the stats of your connection pools (you need to enable stats if not enabled already). If the connection count grows linearly and never comes down then you need to fix the leakage at code level. You can also use JConsole to monitor JVM memory and detect problems.
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?
We are upgrading JBOSS from (4.0.2) to latest Jboss (Wildfly 9.0.1) for our J2EE webApp. After upgrading we found that EJB calls are stop responding after 1 hour of load test.
Please note that the other areas of application is working fine where EJB is not used. The problem is only with remote EJB calls.
We have to restart Jboss to fix the issue.
Do we need to any configuration (threads/EJB pool) in Jboss (Wildfly 9.0.1)?
I'd just like to drop in and say that we're experiencing the same thing. What I recall reading is that this happens when the Wildfly has to wait to long to return an answer and suddenly the whole service becomes unresponsive.
We were running 8.2.0 Final and the only suggestion I could find was to upgrade. After performing an upgrade to 9.0.1 Final we're still seeing this. There was seemingly more people experiencing this but I have not been able to find any solution yet. The issues I found on the JBoss issue tracker on this have all been rejected and they're implying that it's more open for community discussion.
I have this lingering notion that toying around with timeouts might help though I haven't had time to try this yet.
P.S. I'm not privileged enough to simply comment which I would preferred.
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.