Farm hot-deploy waits for MDBs to finish?

[seoeng]

I have MDBs which sometimes run lengthy processes. I want to be able to drop a new EAR into the /farm directory, and all of the apps should restart/redeploy. But what is happening is that the apps which are running these long-running MDBs are waiting for the MDBs to finish before restarting/redeploying.

What is the recommended solution? I don't care about the MDBs not finishing -- they will just restart once the app is redeployed, correct? The MDBs are bean-managed.

[seoeng]

Here is a bit more specific request:

How can I hot deploy my cluster nodes so that each cluster will continue to serve its web apps while waiting for the MDBs to finish? I.E. pre-determine the order of undeployment.

Currently my web apps are being undeployed, so I get a blank (white) screen until the MDBs undeploy. If my MDBs are first to undeploy, the transition would be seamless.

[brian.stansberry]

On your first question re: MDBs, you might have better luck on the EJB or JMS forums, as your question is really about the general lifecycle of MDBs; farm service just inherits the basic behavior. There may be a switch or something to get the MDB to abort early (although I doubt it.).

On your second question, I think you're on the right track. If your MDB and the WAR are packaged in an EAR, then I think just declaring the MDB jar after the WAR in application.xml should result in the MDB deploying last / undeploying first.

If the MDB and WAR are packaged separately, you can add a "depends" element to the MDB's jboss.xml telling it to depend on the WAR's mbean. There's also tricks you can do with deployment order by how you name packages. That kind of stuff is covered in the docs.

[seoeng]

Its a no go on the application.xml order. I will have to work on the deployment configuration classes:

http://wiki.jboss.org/wiki/Wiki.jsp?page=ConfiguringTheDeploymentScannerInConfjbossSystem.xml

[brian.stansberry]

What AS release is this?

[seoeng]

Ok, I have been able to get the ordering correct by doing the following:

1. Put the deployment order in application.xml

<?xml version="1.0" encoding="UTF-8"?>
<application id="Application_ID" version="1.4" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/application_1_4.xsd">
 <display-name>ear</display-name>
 <module id="AWebModule_1189479168218">
 <web>
 <web-uri>jsf.war</web-uri>
 <context-root></context-root>
 </web>
 </module>
 <module id="EjbModule_1190938532906">
 <ejb>ejb.jar</ejb>
 </module>
</application>

2. Create jboss-app.xml file and place under /META-INF directory in EAR:

<?xml version="1.0" encoding="UTF-8"?>
<jboss-app>
 <module-order>strict</module-order>
</jboss-app>

Unfortunately, I am running into another issue. When I undeploy the app, the MDBs are now undeploying first (which is good -- my web-app stays up until the MDBs are done undeploying presumably), BUT the MDBs continue to consume the JMS Queues. They won't shut down. I figured that the MDBs (currently running) would undeploy after finishing, but that isn't true.

I understand this is getting off of the Forum Topic, and if you wish to move this Thread please do so. Thanks!

[seoeng]

I stand corrected. It finally DID undeploy the MDBs.

One MDB was running when I undeployed. That MDB continued to run (which is correct) and then when it was finished, it sent 2 messages on the Queue which spawned 2 new MDBs. Once those had finished, it undeployed.

Is there something inside JBoss that causes the JMS Messages sent from inside a MDB to continue running while a JMS Message sent from outside the MDB waits until the MDBs are undeployed/redeployed again?

Very interesting behavior, but I'll take it!

[brian.stansberry]

Glad it worked.

I can only speculate on the MDB undeploy behavior; for a better answer you'd probably need to post on EJB or JMS forums. :)

Pure speculation:

As you undeploy it's in the stop() method for the container. Sees there are active beans so the deployer thread blocks waiting for that to clear. It happens that stop() is coded in such a way that the blocking occurs before the step gets executed that prevents creating new MDB instances to handle the new messages you generate.