I have a Mule app that takes in HTTP requests (http inbount endpoint.) When I'm starting my server, I need to make sure the Mule app is ready to take in requests before I start another program, let's call it program B, which is the client sending the requests to the Mule app.
While Mule starts at about the same time as Program B in Ubuntu, program B is much faster to be up and kicking than the Mule app is. Program B only gets "Connection Refused" Errno111 until the Mule app is ready, which, while not being a critical issue (thanks to retries), is annoying to see happening at every startup. Therefore, I need to let Program B idle for a given amount of time until the app is ready to take in requests.
So far I can think of two ways to do this. The first is to use a hard-coded integer in my shell script (Program B), for instance:
sleep 180
with the hope it is long enough for the Mule app to be ready. It does work quite reliably because Mule and the app are identical every time the server is started, and so they tend to take the same amount of time given the same hardware/OS.
The second solution I'm thinking of is to check the output of Mule or the new lines appended to its log file and trigger the program when the Mule app is ready to start. When the app is ready, you usually have a line like this in the main mule.log as well as in the stdout:
+ Started app 'myapp' +
I could then sleep for a few seconds to be sure and then start to make requests.
However, I'm wondering if there is not a more refined way to do this. For instance, Program B could be the one expecting to be notified by Mule when it is ready. Or there may be a way to query Mule in a cleaner fashion to tell whether an app is ready or not.
Thanks for your suggestions!
As a solution, I am sending a test request (a simple GET as opposed to a POST) to Mule every 10 seconds, if I get a connection refused error, then the loop continues. When the request goes through, then program B can start safely. In the main flow, I'm using a choice and separate GET requests from POST requests, so the POST requests do what they have always done, while the GET request is only used to check whether the app is up or not. There may be a simpler way to get information from Mule than this, but this seems to be far better than waiting a number of seconds or grepping the log.