Barring the timeout problem you are experiencing, it seems that part of the problem is that the step that Stops ActiveMQ is looping to the LISTEN step which bypasses the logic to start up ActiveMQ for subsequent incoming requests. Once this branch happens, the service cannot check the ActiveMQ Status and start ActiveMQ when the next transaction arrives.
In the world of VSMs, the LISTEN steps acts as a polling type step. The LISTEN step waits for something to trigger its execution. In this case, that trigger is an incoming request. Any steps inserted to the left of a LISTEN step fire one time when the service is launched (started, deployed, or redeployed). Steps that are left of the LISTEN step do not act like polling steps. Therefore, once ActiveMQ shuts down at the end of one transaction, ActiveMQ is not restarted until the service is stopped & started or the service is re/deployed to VSE. To fix this issue, you could move your status check and start of ActiveMQ to the right side of the LISTEN step.
I wonder though if it would be easier (or perhaps more controllable, or readable, or a better separation of concerns) to implement your requirement using two services? The main service and a helper service that only starts / stops ActiveMQ on demand. For example:
Service 1 contains your current service. Rather than start/stop Active MQ, this service calls another service that handles ActiveMQ start / stop logic. Basic steps in this service are:
LISTEN -> REST CALL to Start ActMQ -> VSI Image Selection -> Respond -> REST CALL to Stop ActMQ -> Loop to LISTEN Step
Service 1 is only responsible for processing incoming transactions. It invokes another service to start/stop ActiveMQ using REST with a query string such as: http:// Then custom steps that perform logic such as…
- if query string cmdValue equal “start”, Check ActMQ Status, if is already running, Respond with ActMQ started and loop to listen; else Start ActMQ, wait desired amount of time, respond with ActMQ started, Loop to Listen
- if query string cmdValue equal “stop”, if ActMQ already stopped, respond with ActiveMQ stopped and loop to listen; else stop ActMQ, respond with ActMQ stopped, Loop to Listen
In Service 2, the timeout assertions are forced to branch to the LISTEN step. To do this, Right CLICK on the timeout assertion and force branch to the LISTEN step.
To access the query parameter, you can use String cmdValue = lisa_vse_reqeust.getAttributes().get(“cmd”);
Obviously, the descriptions are missing a few steps, and some branching logic, but hopefully you get the idea.
Lastly, I have concerns about the threading model your service seems to be implementing. Are you able to control the speed with which incoming transactions arrive on the LISTEN step?
My fear is that the service(s) might experience issues when incoming requests are flowing in & out faster than ActiveMQ can shut down and start up. For example, if it takes 15 seconds for ActiveMQ to stop and 15 seconds to start (30 wall seconds), the incoming transactions have to be spaced accordingly. Otherwise, one transaction might be trying to start Active MQ while another transaction has fired the Active MQ stop step. I do not believe forcing the concurrency of the Service to a value of “1” is going to help you control this potential issue.