I'm looking for a way to start/stop/resume a process instance in flowable. In the docs I haven't find anything. All I've found are the operations for start/suspend a deployment process.
Runtimeservice does not have start/suspendProcessByInstanceXXX, at least for what I've found. Are there ways to achieve this?
I don't want to delete running process and then restart, I want to suspend it.
You can achieve this by calling suspendProcessInstanceById() method in RuntimeService which Suspends the process instance with the given process instance id. read more...
Related
I have a requirement where I need to make sure only one message is being processed at a time by a mule flow.Flow is triggered by a quartz scheduler which reads one file from FTP server every time
My proposed solution is to keep a global variable "FLOW_STATUS" which will be set to "RUNNING" when a message is received and would be reset to "STOPPED" once the processing of message is done.
Any messages fed to the flow will check for this variable and abort if "FLOW_STATUS" is "RUNNING".
This setup seems to be working , but I was wondering if there is a better way to do it.
Is there any best practices around this or any inbuilt mule helper functions to achieve the same instead of relying on global variables
It seems like a more simple solution would be to set the maxActiveThreads for the flow to 1. In Mule, each message processed gets it's own thread. So setting the maxActiveThreads to 1 would effectively make your flow singled threaded. Other pending requests will wait in the receiver threads. You will need to make sure your receiver thread pool is large enough to accommodate all of the potential waiting threads. That may mean throttling back your quartz scheduler to allow time process the files so the receiver thread pool doesn't fill up. For more information on the thread pools and how to tune performance, here is a good link: http://www.mulesoft.org/documentation/display/current/Tuning+Performance
i have deployed ODE as a web service and my client app is communicating through the ode events. currently to get the instance id, we are capturing the instance create event and querying all the instances to match the correlation. this is not very efficient and as the number of instances increases, this will be a performance hit. what is the best way to get the instance id as soon as the process instance is created by ODE.
second issue with the above approach is that if the next task in the process is also started and the corresponding event is fired by ODE, we do not have a way to associate this task with the process id until we figure out the process id with the first event which may be delayed due to its asynchronous nature?
thanks,
The current process instance is stored in an extension variable called $ode:pid. You can assign this value to a response variable (e.g. to the instantiating request) and use it to initialize a correlation set.
<assign>
<copy>
<from>$ode:pid</from>
<to>$response.part</to>
</copy>
</assign>
should actually do the job.
I am using Spring JMS with ActiveMQ as the broker and running the application on Tomcat. I have seen many examples of receiving messages synchronously with a specified message selector using receiveSelected(..). But I cannot find any way to dynamically specify the message selector on a jms:listener-container to receive a message asynchronously. The selector will be known only at runtime.
The only way I can think of doing it is to use DefaultMessageListenerContainer instead and create a new instance every time I need a new selector. But I'm unsure if this is the right approach and the best practices in doing so. For example, should the listenerContainer associated with a selector be cached? When should it be shutdown etc.?
I would really appreciate it if someone could point me to an example or outline a strategy to handle this situation.
Thanks in advance!
You can't change the selector while the container is running (you can, but only new listener threads will use it). You can stop the container, modify the selector to include the new conditions, and start the container again.
I want to use NSWorkspace to check if application is launched or closed.
But the process is Launch Daemon and Apple documentation says its not thread safe.
However, the part of code that makes use of Workspace will not be executed at start up or login time. It will be executed after some commands received from other application via BSD communication and process is background process without UI?
Is it safe to use Appkit framework in this situation? Only NSWorkspace API and no other? Alternate solution is Polling? What is your suggestion?
Generally you can use any code that isn't thread safe, as long as you are only doing one operation of whatever the unthreadafe operation is at any given time. I would go ahead and try it, and just be aware that whatever you are doing you can't do concurrently, if you absolutely need to do something concurrently you can try throwing a couple of #synchronized blocks around the code, either in callbacks of a long running background process, or delegate calls.
I want to write a program that can not close it
In other words, they can not kill process .
The solution of the process of closure for less than the other way is to do a good job
I have another solution?
Assuming Linux, this is not quite possible from userspace because there are signals like
SIGKILL that cannot be ignored or handled.
If you have access to kernel, than you could write a kernel moudule which puts the current process in state TASK_UNINTERRUPTIBLE and thus no one could kill it.
please specify your question in detail.
i think you have facing error on previous activity is onResume();
you have to on resume method for removing this error.
in onResume() method you can call finish(); method for stop activity.