I added a program to a Mule project in order to avoid duplication of code. They are both REST, access the same webservice and return json. The first service's threading profile looked like this:
<configuration doc:name="Configuration">
<default-receiver-threading-profile maxThreadsActive="10" poolExhaustedAction="WAIT" threadWaitTimeout="10000" maxBufferSize="100" maxThreadsIdle="2" >
</configuration>
When I added my second service, the same threading profile caused the program to hang endlessly. No log entries, no nothing. Raising max active threads to 1000, or even deleting the WAIT option doesn't do anything. It's only when I change "maxThreadsIdle" to 3 or higher, or delete maxBufferSize or delete the entire thing that both can work in the same project. One other thing...when I edit the mule flow and save, the program automatically launches again. Oddly enough, the results end up appearing in any browser I left hanging from trying to submit.
What I want to know is why the min threads needs to be set to 3 or higher...I mean what the heck is actually going on here? Ideally, I would like to keep the threading configuration set to what I have here.
Related
For some client side procedures, I implement remote logging to log the calling of the procedure. The log is printed several times with different thread id, even though the procedure is only called once. Some rpc requests are sent to the sever a few times which causes some database session problem. Is it normal? Is there anyway to avoid it?
Thanks
This is not normal, and suggests there is a bug on your client causing it to send the same call more than once. Try adding logging on the client where you invoke the RPC call, and possibly add breakpoints to confirm why it is being called twice.
My best guess with no other information would be that you have more than one event handler wired up to the same button, or something like that.
--
More specifically, your servlet container starts multiple threads to handle incoming requests - if two requests come in close succession, they might be handled by different threads.
As you noted, this can cause problems with a database, where two simultaneous calls could be made to change the same data, especially if you have some checks to ensure that a servlet call cannot accidentally overwrite some newer data. This is almost certainly a bug in your client code, and debugging it should start there.
I have built and started an OPC UA embedded Openmodelica server with the BouncingBall model like so:
$ omc +s path/to/model
$ ./BouncingBall -embeddedServer=opc-ua -rt=1
Now I'm trying to interact with it using an OPCUA client. However, I don't understand how I'm supposed to interact with the server properly. As far as I know this is undocumented.
The most promising approach seems to be to set enableStopTime to false and run to true. Then the simulation seems to run indefinitely and the values seem to make sense. It seems I'm only able to extract the values in real time however. While running, when I set run to false it seems that the server enters an erroneous state and it refuses to give any values back.
If I restart the executable and instead set step to true nothing seems to change and after trying to set step to true a second time the server becomes unresponsive. The -rt=1 option doesn't seem to matter. Seems like it enters the same state as above (1).
(After restart) If I leave enableStopTime to be true and set run to true the simulation runs to stop and then the server quits with message The simulation finished successfully. Maybe this is intended. Kind of seems odd. Would make sense to be able to restart the simulation or trigger it with new options.
What I would hope to be able to do: Start and stop simulation as well as rewind to a certain point to check the value at that point. It seems to me that the API "affords" this functionality and it could probably be provided by hackingly wrapping the executable and API. Are the above bugs or intended? What is the intended way to interact with an OPC UA server in these cases?
The OpenModelica compiler version is 1.16.0~1-g84b4a71
Please try the latest nightly build
It includes the following commit.
That might solve it. I believe things worked without subscriptions before, since I could never reproduce this without them.
(By the way, do people go on our git commit feed and try to reproduce bugs fixed in the last 24 hours; we quite often get questions that were just recently fixed)
So I wrote an ItemReader. When this app is run from the command line again I want to continue reading from where I left off. How do I do that?
I've added spring-task. It seems to track certain things. Does it help with this?
Everything I have read online seems to be talking about restarting the job after a failure. I don't think I have any use for that. I've added all of my stuff into the ExecutionContext. Should I use the JobRepository and start looking around for the last successful execution?
I made an app that I'm deploying as EAR on WAS 8.5. This app works as an app that constantly checks on a DataQueue and transfer whatever message it finds to an MQ. Since I've been testing it, I realized that if I start it, it remains starting the application indefinitely (since it's an endless loop that checks on the queue). Even without the loop, the read() function of the dataqueue reads indefinitely until it finds a message, what also makes the starting of the app to don't end.
Reflecting on it, I realize that an EAR (with WARs, JARs, etc) it's an app that expects a request (if not all, most of the time). So if it's an endless loop, it won't end the starting of the EAR.
Maybe there's another way to deploy this application on WAS. Is there a way to deploy the app so it will be like a background process that does everything I previously mentioned?
There are 2 solutions to this:
Use MDBs and ensure that you receive the message is a message listener thread. This will ensure that threading is completely taken care by WAS.
Here is an article about using threads in WAS: http://wpcertification.blogspot.in/2010/09/developing-multi-threaded-application.html .
We have a main ruleflow which calls 8 more rule flows (Rule1.rf to Rule8.rf) through an AND splitter. One of the rule flows - say Rules4.rf - is fired sometimes and not fired sometimes.
This is for an online application and we use jBoss. When the server is started, everything works fine. After many hours, for some requests, Rules4.rf is not fired at all and for others, its fired properly.
We even posted the same request again and again and the issue happens some times only. There is no difference in the logs between the success & failure requests, except for the logs from the Rules4.rf which missing in failued requests.
We are using drools 5.1 and java 6.
Please help me. This is creating a very big issue.
It is very difficult to figure out what might be going on without being able to look at the actual code and log. Could you by any chance create a JIRA and attach the process and if possible (a part of) an audit log that shows the issue?
Kris