Dynamic JMS Queue Creation in WildFly

[arunkumaraswamy]

Hello Everyone,

I'm just new to wildfly and require your support in creating the dynamic JMS queues for my application. Kindly guide me and let me know the steps i follow are having issues.

Let me summarize the need which i'm looking and trying out with WildFly 9.0.2 Final.

The application which i'm working now works with Jboss AS 6.1.0, and we are in process of migrating it to wildfly versions. We are in the initial analysis of its feasibility and facing issues with JMS queue creation from the application which we are deploying.

The application presently uses JMX to create a queue. We decided to move to jboss-cli and used the wrapper ( Advanced CLI scripting with Groovy, Rhino, Jython, etc. ) from this link to create a JMS queue (Hornet Queue as of now).

The standalone jboss-cli command while running creates the queue as exepcted (jms-queue add --queue-address=sampleQueue --entries=java:jboss/exported/jms/queue/sampleQueue). With the wrapper code's normal java execution also creates the queue as expected.

CLI cli = CLI.newInstance();

cli.connect();

Result result = null;

String queueId = "sampleQueue";

result = cli.cmd(“jms-queue add --queue-address="+queueId+" --entries=java:jboss/exported/jms/queue/" + queueId)

ModelNode response =  result.getResponse();

System.out.println(response.get("outcome").asString().equals("success"));

cli.disconnect();

When i include the queue creation logic (java code) with my application war, and this logic when gets executed as part of the deployment (due to some configuration triggers) the application deployment hangs and fails subsequently.

// note we have adjusted the "jboss.as.management.blocking.timeout" to 300. and it doesn't helped in the deployment.

The error logged onto the server logs are as below.

2017-05-16 14:22:02,747 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0348: Timeout after [300] seconds waiting for service container stability. Operation will roll back. Step that first updated the service container was 'deploy' at address '[("deployment" => "app.war")]'

2017-05-16 14:22:02,750 ERROR [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0021: Deploy of deployment "app.war" was rolled back with the following failure message: "WFLYCTL0344: Operation timed out awaiting service container stability"

2017-05-16 14:22:07,751 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0190: Step handler org.jboss.as.server.deployment.DeploymentHandlerUtil$1@1a67560 for operation {"operation" => "deploy","address" => {"deployment" => "app.war"},"operation-headers" => {"caller-type" => "user","access-mechanism" => "NATIVE"}} at address [("deployment" => "app.war")] failed handling operation rollback -- java.util.concurrent.TimeoutException: java.util.concurrent.TimeoutException

  at org.jboss.as.controller.OperationContextImpl.waitForRemovals(OperationContextImpl.java:396)

  at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1384)

  at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1332)

  at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1292)

Post this the container gets to instable state and only works post the restart of application server itself.

Any help or reference guides would really help us. Thanks in advance.

./Arun

[jbertram]

This is more about Wildfly than it is about HornetQ so I'm moving it to the Wildfly forum.

[jbertram]

I am certainly no expert on Wildfly deployment semantics, but from what I understand the server start-up process is multi-threaded (so as to be as fast as possible) which means that dependent services are started in order but everything else is just started as quickly as possible with no real deterministic order.  In your case, my guess is that your application is being deployed prior to (or perhaps concurrently with) the messaging subsystem which is causing your management code to fail.

[arunkumaraswamy]

Hi Justin,

Thanks for the reply.

Just to add, The server is started well before the deployment in that case the messaging subsystems should have been properly initialized (pl, correct me if i'm wrong). So during the deployment of the application war it just tries to create a queue in the running application server. Also would like to highlight we are not doing the restart of application server (where there exists a possibility of concurrent deployment while the server is starting up).

Dynamic JMS Queue Creation in WildFly

[jaikiran]

This is actually as per design - deployments are not supposed to invoke management operations _during the deployment_. Doing so can result in dead lock as you are noticing. I'm guessing you are doing it as part of some servlet context initialization or some such construct.

[arunkumaraswamy]

Hi Jai,

Thanks for the reply.

As said we are doing the queue creation during the initialization. Let me check the application how this can be handled. Thanks for clarifying the design aspect behind the deployment.

[mnovak]

I think what you're looking for is "hornetq-jms.xml" file. It's deployment file which you place in your deployment to "META-INF" or "WEB-INF" directory and it will deploy all queues/topics for the deployment. Example of such deployment file is: https://github.com/wildfly/quickstart/blob/9.x/cmt/src/main/webapp/WEB-INF/hornetq-jms.xml

<?xml version="1.0" encoding="UTF-8"?>
<messaging-deployment xmlns="urn:jboss:messaging-deployment:1.0">
  <hornetq-server>
  <jms-destinations>
  <jms-queue name="InvoiceManagerQueue">
  <entry name="/queue/InvoiceManagerQueue"/>
  </jms-queue>
  </jms-destinations>
  </hornetq-server>
</messaging-deployment>

Note that if you undeploy this deployment then all queue/topics will be undeployed as well. But they're not actually physically deleted from WF9 server. If you redeploy the deployment then all messages will be still in those destinations.

Note that it's safer for production to have standalone...xml with your queues/topics already in configuration of WF before you deploy your application. Deploying those destinations with your deployment using hornetq-jms.xml is mostly for improving developer experience than for actual use in production.