I have a process that splits into many different branches. The business requirement is that at any step, the process has to sent back to the process originator for correction and re-approval.
I know it would be possible to to use gateway logic at the end of each step and have the process return to the beginning that way; however, this would add many lines and branches to the process so that it would be incredibly difficult to read. I was thinking that an alternate way to accomplish this would be to simply abort the process and restart based on the information in the existing process - this seems more maintainable.
Both of these would not be too hard to implement, but I am wondering if there is an easier way to achieve this goal. I have not worked with signals much, but is there a way to leverage that to return to a previous step in the process?
Start of Editted Solution
Based on #Kris Verlaenen suggestion, it created the example process below.
I started by putting all of the steps that can be might be skipped into an Embedded SubProcess. The Return, Rejection, and Cancel signals were added from the Boundary Events tab of the palette. While the process waits for the Supervisor or Manager approval to complete, you can send a either of the signals to either go back to the first step or jump to the end of the process.
Using a event sub-process could allow you to trigger some part of your process every time the event occurs (could be signal, error, etc.)
Using an embedded sub-process with boundary event might help, as that way you would only have to link back grom that boundary event to the start, and whenever a signal / error occurs inside the sub-process, the boundary event could catch this. You could even make it interrupting, meaning it would cancel anything inside the sub-process as well, basically resetting what you were doing.
Related
is there a way that that a component in the spring integration graph will start processing a message (end of day) first when all other messages (other type) finished processing? in this question we have to consider that spring integrations can start multiple threads. An other restriction is that this component will be used in graphs where i have no control. so i can not tell:
how long "other type" message processing takes
if some messages run in error
are just drop by some filter
multiplied with a publish-subscribe channel
if there are some TaskExecutor used (introduces new thread and transaction boundary)
there is no end artifact which i could check if it is there or not
when "end of day" arrives to my component it is possible that "other type" messages are still in processing. even if my component is at the end of the graph it is possible that messages run it error not arrive there. other posibility that a message is mutiplied and i do not know how many times. because of this i do not know how long i should wait with the "end o day" processing.
it is also possible that an other tool/framework would make this problem easier or eliminate it completely.
was tinking about checking the task executor if all threads are free, but there might be several task executors some of which not involved.
This sounds like not related to what you say in the question, when you claim that process you use is a black box.
If you really can have access somehow to the process, e.g. via ChannelInterceptor: https://docs.spring.io/spring-integration/docs/current/reference/html/core.html#channel-interceptors, so you can have some global bean like AtomicBoolean active to set in the beginning of the flow and reset in the end. So, your "in the end of day" message would poll this flag periodically to be sure when to send it. You just simply can use a #InboundChannelAdapter to produce your message or null when flag is false.
I want my servlet to wait for the result of a database update before moving to the next line.
I have the following code snippet:
//wait for this to finish and get the status
status=profiledao.updateProfile(profile);
//then execute this statement
httpresponse.getWriter().print(fileName);
What is the best way to do this?
Thanks.
Unless you are running this line asynchronously with additional unshown code, the code you have posted will do exactly what you are intending to do in a normal Java environment.
If you are running this asynchronously and want to continue doing so while still accomplishing the task you are talking about, you want what is called a Promise
CompletableFuture.supplyAsync(this::sendMsg)
.thenAccept(this::notify);
This code is a very very simple way of doing this in an asynchronous setting, however, if the code you have shown is Synchronous then this is not needed.
I have many threads performing different operations on object and when nearly 50% of the task finished then I want to serialize everything(might be I want to shut down my machine ).
When I come back then I want to start from the point where I had left.
How can we achieve?
This is like saving state of objects of any game while playing.
Normally we save the state of the object and retrieve back. But here we are storing its process's count/state.
For example:
I am having a thread which is creating salary excel sheet for 50 thousand employee.
Other thread is creating appraisal letters for same 50 thousand employee.
Another thread is writing "Happy New Year" e-mail to 50 thousand employee.
so imagine multiple operations.
Now I want to shut down in between 50% of task finishes. say 25-30 thousand employee salary excel-sheet have been written and appraisal letters done for 25-30 thousand and so on.
When I will come back next day then I want to start the process from where I had left.
This is like resume.
I'm not sure if this might help, but you can achieve this if the threads communicate via in-memory queues.
To serialize the whole application, what you need to do is to disable the consumption of the queues, and when all the threads are idle you'll reach a "safe-point" where you can serialize the whole state. You'll need to keep track of all the threads you spawn, to know if they are in are idle.
You might be able to do this with another technology (maybe a java agent?) that freezes the JVM and allows you to dump the whole state, but I don't know if this exists.
well its not much different than saving state of object.
just maintain separate queues for different kind of inputs. and on every launch (1st launch or relaunch) check those queues, if not empty resume your 'stopped process' by starting new process but with remaining data.
say for ex. an app is sending messages, and u quit the app with 10 msg remaining. Have a global queue, which the app's senderMethod will check on every launch. so in this case it will have 10msg in pending queue, so it will continue sending remaining msgs.
Edit:
basically, for all resumable process' say pr1, pr2....prN, maintain queue of inputs, say q1, q2..... qN. queue should remove processed elements, to contain only pending inputs. as soon as u suspend system. store these queues, and on relaunching restore them. have a common routine say resumeOperation, which will call all resumable process (pr1, pr2....prN). So it will trigger the execution of methods with non-0 queues. which in tern replicate resuming behavior.
Java provides the java.io.Serializable interface to indicate serialization support in classes.
You don't provide much information about the task, so it's difficult to give an answer.
One way to think about a task is in terms of a general algorithm which can split in several steps. Each of these steps in turn are tasks themselves, so you should see a pattern here.
By cutting down each algorithms in small pieces until you cannot divide further you get a pretty good idea of where your task can be interrupted and recovered later.
The result of a task can be:
a success: the task returns a value of the expected type
a failure: somehow, something didn't turn right while doing computation
an interrupted computation: the work wasn't finished, but it may be resumed later, and the return value is the state of the task
(Note that the later case could be considered a subcase of a failure, it's up to you to organize your protocol as you see fit).
Depending on how you generate the interruption event (will it be a message passed from the main thread to the worker threads? Will it be an exception?), that event will have to bubble within the task tree, and trigger each task to evaluate if its work can be resumed or not, and then provide a serialized version of itself to the larger task containing it.
I don't think serialization is the correct approach to this problem. What you want is persistent queues, which you remove an item from when you've processed it. Every time you start the program you just start processing the queue from the beginning. There are numerous ways of implementing a persistent queue, but a database comes to mind given the scale of your operations.
I am currently working on a project in JAVA where I have to make an agent to interact with a server.
Each 50ms, the server will receive the last thing I outputted to System.out and send me a new set of lines as a 'state' through the System.in printstream to analyze and send my next message to System.out.
Also, if the server receives multiple outputs from me, it only regards the most recent one.
..
As for my question:
My program originally constructed a tree and then analyzed each leaf node to see which would be optimal, and then waited around for the next input, but I can recursively do a deeper tree search that would make my output 'better' (and again and again to keep returning a better result).
Using this and the fact that if the server receives multiple outputs, it only takes the most recent one, I could do each level, print my result and start the next level. But here comes my problem...
I can't be stuck in some complex algorithm while I am supposed to receiving the next input as I will then miss it. So I was wondering if there is a way to cancel anything else I am doing when I receive something via System.in and then go back to the beginning of the function and start the search again with the new set of input (and rinse and repeat..)
I hope this all makes sense,
Thank ye all
You absolutely require either multiple threads (or multiple processes) here.
I assume that you've solved the problem of receiving input into System.in, as well as the problem of your algorithm. The next step is to package each in a Runnable interface, and hand each a reference to a queuing object. This will scaffold a Producer-Consumer relationship.
Whenever your listening Runnable (the Producer) gets a message, it needs to put it on your queue. After every unit of work, your algorithm (the Consumer) should look into the queue for items that are there. If it finds something, it should integrate it as normal. If not, it continues on with it's work.
Both the Producer and the Consumer need to be started in their own threads and allowed to run concurrently.
I've been playing with Java Servlets and Ajax a bit, and I've got
a situation on which I would really appreciate advice.
Let's say I have HTML page with a start and stop buttons, and as a result of clicking start button,
overridden doGet (or doPost) method on a servlet is invoked which computes something that takes a long time to complete.
(e.g. a giant loop, or even Infinite loop, doesn't matter, I'm interested in concepts here).
So, I'm asking you:
1.What would be my options to kill / shut down / halt / exit
doGet method whan I hit stop button on a web page?
Do I use threading here, or there is simpler way?
I take it that using System exit is not a very good idea, right? ;)
2.So, let's say I implement code for stopping doGet method.
What would happen If I hit start on one browser(e.g.IE), and while this long
computation takes place open new tab or other browser(e.g.Firefox) and open same url
and hit stop? Would that stop my original computation? Is there any easy way to avoid this?
I know that questions are a bit off, as I'm just starting with server-side of things. :)
Any suggestions would be greatly appreciated!
your stop handler can set a flag in the session context, which the long-running thread will occasionally check and exit if necessary.
you can avoid the multiple browser issue, by generating a unique task id each time the page is loaded. then you can only start or stop a specific task. this id can be a key in the session.
I think you need some kind of new process started after you submit request and this process should answer responses during runtime (showing progress for example via AJAX). Also it should check if there is new request with stop command. Page should be AJAX one with progress/result/stop button.