I wanted to know what is the difference between starting an application and starting a managed server in weblogic server?
I have 5 different applications targeted to one managed server, whenever I make any change to any one application I have to restart the managed server entirely to make the changes to reflect. Why is it not that when I simply start and stop the application alone from Deployments it reflects, why do I need to start the managed server every time?
Restarting the managed server will restart the entire JVM including all installed EAR files. Stopping an application simply puts the application in Admin mode so the application class files are not unloaded.
This following document discusses various methods for redeploying applications in WebLogic based on the scope of the deployment:
https://docs.oracle.com/cd/E24329_01/web.1211/e24443/redeploy.htm#DEPGD258
Related
So we need to provision (add the jms extension/subsystem/configurations to standalone.xml) the JMS subsystem in wildfly when starting the server if it's not already provisioned and that needs to happen automatically. We have an application written in java and we chose to provision the jms subsystem with wildfly's cli java api and that is executed when our application starts deploying. The thing is we need to provision the jms subsystem and use it in the same application.
Problem is, when we add the needed configurations in standalone.xml with wildfly's cli java api, the server requires a reload but we can't reload it because our app is already deploying, it tries to use the defined queues and fails because... Well, the subsystem is not active yet. On next server restart everything is ok but as you can guess in a production environment this is unacceptable. Is there any solution to this? I've tried adding a reload cli command in the end of the batch that creates the jms subsystem and it starts reloading the server but the deployment doesn't stop and exceptions start flying left and right.
Also the whole idea of reloading the server from the app while the app is deploying seems kinda wrong to me.
Thanks in advance.
Solution:
Well the solution in the end was an easy one, we just had to add a reload step in the batch operation that adds the jms subsystem. The problem was that we had a set of async operation that all fired off when the app was deployed so i just had to make sure none of them started until i can check for the messaging subsystem and reload wildfly if necessary. That way I'm not interrupting any async tasks forcefully.
You need to select appropriate profile i.e full or full-ha while starting server only. If you do this there will not be need to add JMS subsystem.
If you want to go with your approach only, add dependency of queue in
application. It will not start deploying until and unless queue is bound to server.
we need to perform reload operation when we add new subsystem, if you dont want to perform reload operation then I will suggest you to start server in 'admin-only' mode. When we start server in 'admin-only' mode then it open only management port(9990/9999). Configure messaging subsystem through CLI command reload server instance. Hope it helps..!!
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.
Our database drivers are usually copied under <jboss.home>\common\lib folder in JBoss 5.1 and this is quite annoying since if you have to upgrade the driver you will have to re-start the JBoss 5.1 server. How does everyone else handle such situations in a production environment?
Upgrading database drivers is not something you want to do on a running server. Your connection pools will all be using the "old" driver - there's no sensible way to make that switch without a restart.
If downtime is important to you, then you should be using more than one server in a cluster, and perform rolling upgrades/restarts on each one.
I'm using jboss 5 on solaris and have a simple question.
If a single server is hosting multiple web applications is it possible to stop/start/restart an individual application without bouncing the entire server from the jmx console/command line.
The setup we have at work is that each application is hosted by a different jboss instance, this was done as no-one knows how to stop/start individual apps without affecting the other. This doesn't make sense to me and creates additional load on the server. I know in glassfish you can do it through the admin console but the jmx console is not so user friendly to make this obvious to me
thanks sapatos
Yes. Go in admin-console at http://localhost:8080/admin-console to the respective web-app and then on the operations tab from where you can invoke start/stop/restart.
You can of course also do it in jmx-console.
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.