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!
Mule ESB has an JMX interface which provide the endpoint status.
<management:jmx-server>
<management:connector-server url="service:jmx:rmi:///jndi/rmi://localhost:1099/server" rebind="false" />
</management:jmx-server>
JMX MBean
Evaluate the attribute 'Connected=true' by a jmx client before starting the other process.
Mule.$YOUR_SERVICE_NAME > Endpoint > $FLOW_NAME > $CONNECTOR_NAME
+ Attribute: 'Connected' (true/false)
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.
Related
I am experiencing a weird problem in a GWT application. I have multiple RPC calls which work correctly, however if one of them takes longer than 30 seconds on the server side (for example a database or web service call took a long time), the server side code gets repeated (literally; the code get executed again).
I do not experience this in my develompent environment, however when I deploy the application (container is Jetty 6.1.24 on Ubuntu 12.04 LTS) and connect to it from a browser (regardless of the type), the problem starts to exist.
Since I do not think this a designed GWT behaviour (but I might be wrong ofcourse) I am basically looking for ways to debug this and find out the reason for it. Thanks in advance!
Some more information would be great to understand what is going on, but I would start the investigation by first narrowing down whether the erroneous GWT-RPC call is triggered on the client or server.
To see if the extra GWT-RPC request originates from the browser, in Google Chrome, go to View->Developer->Developer Tools.. Click on the Network Tab.
As you reproduce your steps, the Network Tab will show you every request sent to the server.
If you see the erroneous GWT-RPC request logged in this Network Tab View, then the request is fired off from the GWT-compiled Javascript in the application. With SuperDevMode, you can then set debug breakpoints in the browser and see what is triggering the request.
If the erroneous GWT-RPC is not shown in the Network Tab View, then the server-side method is somehow triggered by your server code/configuration. Set some debug breakpoints on your server code, and drill down the call stack to see what is calling the method.
Hope that helps to get started on the investigation.
Maybe I'm overthinking this but I'd like some advice. Customers can place an order inside my GWT application and on a secondary computer I want to monitor those submittals inside th eGWT application and flash an alarm every time an order is submitted, provided the user has OK'd this. I cant figure out the best way to do this. Orders are submitted to a mysql database if that makes any difference. Does anyone have a suggestion on what to do or try?
There are two options: 1) polling or 2) pushing which would allow your server (in the servlet handling the GWT request) to notify you (after the order is successfully placed).
In 1) polling, the client (meaning the browser you are using to monitor the app) will periodically call the server to see if there is data waiting. It may be more resource intensive as many calls are made for infrequent data. It may also be slower due to the delay between calls. If only your monitoring client is calling though it wouldn't be so resource intensive.
In 2) pushing, the client will make a request and the request will be held open until there is data. It is less resource intensive and can be faster. Once data is returned, the client sends another request (this is long polling). Alternatively, streaming is an option where the server doesn't sent a complete request and just keeps sending data. This streaming option requires a specific client-/browser-specific implementation though. If it's just you monitoring though, you should know the client and could set it up specifically for that.
See the demo project in GWT Event Service
Here is the documentation (user manual) for it.
Also see GWT Server Push FAQ
There are other ways of doing it other than GWT Event Service of course. Just google "GWT server push" and you'll find comet, DWR, etc., and if you are using Google's App Engine the Channel API
I'm using a 3rd party web service that's implemented as SOAP web services.
Per their instructions I used eclipse to generate java stub classes from the WSDL.
After experiencing some long-running requests with them I dug into the generated classes, found where an org.apache.axis.client.Call was being created and invoked. I set a configurable timeout on the Call object.
I can test this by setting the timeout to something unrealistic, like 10 milliseconds. When I do this every request times out as expected.
In production, I'm seeing calls to them take longer than the timeout. As in the timeout is 3 seconds but the execution takes over a minute.
Is there something I'm missing? Maybe I need to dust off my TCP/IP Illustrated books and reacquaint myself with the finer points or maybe it's just something under the covers of the axis code.
I would suggest you to find out how long this 3rd party web service is actually taking to respond to the clients rather than digging into your code since the problem might be at the server side.
For this you actually do not need to write a client yourself, but can use a tool like SOAP-IU and try sending a request. SOAP-UI has lots of details in the internet if you need to find out how to send a request. Please refer here to get started.
I have a crawler Java application which is supposed to connect to some HTTP servers, download the HTML content of their pages, then move on to other HTTP servers. For this task, I've used the Apache HTTP library.
At the first few hours of the run, things seem to work rather smoothly (there are some connection-related exceptions thrown around from time to time, but that's to be expected).
Yet after a while, it seems like I keep getting SocketTimeoutException on every request I send out. The exception does not occur on the HttpClient class's "execute" method, but rather when I try to get the content of the Entity (which I retrieve from the HttpResponse object), or when I try to write that content to a file.
Then, if I stop the application, and start it over again, things seem to go back to working fine - even though it picks up from where it stopped at, meaning it's interacting with the same servers which I received the SocketTimeoutException when trying to interact with before.
I tried looking for all kinds of possible clean-ups that I might be missing and might be essential when using this library, but couldn't find anything.
Any help would be greatly appreciated.
Thanks.
This sounds like the kind of thing which could be caused by connection pools where you're not closing things when you're done with them, if the timeout occurs while the client library waits to retrieve a pooled connection. Are you sure you're closing everything properly (in finally statements)?
If you run Wireshark to monitor your traffic, what network traffic occurs while it's "broken"?
Make sure that you're not using a lot of http requests at the same time. For example, send 5 http requests, and wait for first response. Then you can make another request etc. Looks like your http requests opens too much sockets.
We have a string processing service (c++, uses stdin/out for in/output) that has different layouts, each layout runs separately (eventually will run on separate machines), each layout takes time to load, thats why it must keep running after first run.
I must implement a system with client that will ask the master server to connect it to a relevant slave server which actually runs the relevant layout service. The slave server will communicate the data passed from the client to the service, and when finished will become available on the master server for other clients.
The question is what is the best way to go about implementing the servers? Should I keep an open connection between slave/master until the process is complete to notify the master that the connection is over or keep some sort of var in a synchronized function to check that?
Any other important inputs (or other designs) I have overlooked are also very welcomed, Thanx!
Assuming you can't replace the C++ stuff, here is how I would do it off the top of my head.
I would setup one master server. That server would run a process that accepts requests (probably by HTTP, so it'd be a webservice) and I would have it read the request, parse out what it is, and then call the correct slave. Basically it acts as a proxy. Once it receives the response from the slave it forwards it back to the caller. The simplicity here means that if you start getting more of one type of request, you can set up additional servers for that and round-robin requests to them.
The slaves would be webservices that open the C++ program and forward input and retrieve output. That's all it would do.
I wouldn't bother keeping open connections (except between the slave and the C++ program based on your description). Just using a web request for this stuff will keep the connection between the master and the slave open during the process, but it shouldn't be a problem. This way you don't need to worry about this detail.
Now if I were you I would seriously look at reimplementing the C++ code in Java or calling it via JNI or something. If you can avoid it, I think avoiding the Java wrapper around C++ thing would be a good design goal. The Java could do whatever expensive process it is during start up once, and then hold things ready in memory like the C++ code does.
I hope this helps.
Depending on your scalability needs, you may want to take a look at the Java NIO package. This will give you a starting point to build a scalable, non-blocking server implementation.