Hello !
I would like to create a child process which could run after the end of the main process in java (I did a simple schema of the execution I'd like : result wanted. Is that possible ?
You can't start a child process from a process that is no longer running, so the child will have to be started beforehand. And in that case, how will the child know the parent has terminated?
Your design is upside down. The "main work" should be done in a child, and the parent should sit there waiting for the child to terminate before it does whatever it needs to do. That's an easy implementation and is a common design pattern. It is, for example, what any Unix shell does to run an external program.
(I assume that when you say "process" that is what you mean - i.e., something in an entirely separate address space)
Finally I've found a simple response. I don't know why I was hesitating so much.
I'd just start a thread from my main fonction and according to my log, the thread continued after the principal treatment.
I'm guessing I have a daemon thread because the child is not killed.
Related
I'm trying to design a process which will spawn multiple sub process(instances) and finally the outcome of the sub-processes will decide the main process flow.
As I agree there can by multiple ways to design the same, but wanted to to check from all experts in this forum.
My query is what is the followed model in this case.
Do we create two individual processes -
1. to spawn the process and then wrap it up.
2. To keep track the sub processes and inform the main process(1).
Please help me with your suggestions.
Thanks & regards,
BPMN developer.
For this use case, BPMN has multi-instanc Activities - see the BPMN Specification, page 432 (page 462 in PDF).
You can create a sub process of the type multi-instance Activity and define - via the isSequential attribute - whether the sub processes should be spawned sequentially or in parallel.
Via the completionCondition Expression, you can define a check that is executed every time an instance completes and that cancels all other instances if it returns true.
My project is not using Akka as of now, it runs as a single process and does too many things.
As a first inital step, we are trying to put a scaffolding in place so that we get Fault Tolerance. For example,
ProjectSupervisor
|
ExistingProcessActor
Where ExistingProcessActor would run as a forever long running job anf if it gets killed because of some Exception, ProjectSupervisor will restart it
I wasn't too sure about this, so I asked on user-group, and received an interesting advice as
[Me] def run: Unit = LogReaderDisruptor.main(Array())
is a method that is supposed to run forever, plus it required some setup (that is available on client's machine or test environment)
[Advice here] By that do you
mean that the main() is never returning? If so, then you're blocking
the Actor and wasting an entire thread. Spawn this off on a dedicated
dispatcher instead (see dispatchers and futures docs).
I went through the documentation but did not understood what I need to do.
Does that mean following?
ExistingProcessActor will start a new future by giving a custom dispatcher of type PinnedDispatcher?
If so, then in case of any failure how would ProjectSupervisor be notified? He is monitoring ExistingProcessActor and not future (future is not Actor)
I am confused, kindly guide me
You don't need to use a Future in order to have the work done in a dedicated dispatcher. This can be done by spawning an actor and assigning that actor to the dedicated dispatcher. A simple example from the akka docs:
val myActor =
context.actorOf(Props[MyActor].withDispatcher("my-dispatcher"), "myactor1")
http://doc.akka.io/docs/akka/snapshot/scala/dispatchers.html
You could do this within your project supervisor when creating the ExistingProcessActor, putting that actor on a pinned dispatcher, and then your supervision strategy will continue to work as you want.
I need to create a multithreaded Java application for recursive directory search wherein I need to search for all files/folders based on the search-string.
Example : :
Search-string - 'hello'
Search-directory : 'C:\'
Expectation here is that I need to recursively search all files & folders in C:\ having
name as hello
My idea is to spawn a thread per directory to have a better performance.
Challenge is that we have a timeout factor wherein all the matching files/folders are to be shown within the timeout interval - if timeout happens before complete search is done, we need to show whatever results are available. I am pretty confused on how to handle this timeout - can you please help?
Cheers,
Jay
Think you can spawn a child thread for search - say 'ThreadA' from main thread. Have a waited-join for Main Thread and ThreadA. Let this child thread 'ThreadA' spawn other threads and have a join for the same. Let all the child threads use ConcurrentLinkedQueue to capture the results - so, after the Main Thread returns after the join timeout, it can print the values in the Queue
I am creating a process P1 by using Process P1= Runtime.exec(...). My process P1 is creating another process say P2, P3....
Then I want to kill process P1 and all the processes created by P1 i.e. P2, P3...
P1.destroy() is killing P1 only, not its sub processes.
I also Googled it and found it's a Java bug:
http://bugs.sun.com/view_bug.do?bug_id=4770092
Does anyone have any ideas on how to do it?
Yes, it is a Bug, but if you read the evaluation the underlying problem is that it is next to impossible to implement "kill all the little children" on Windows.
The answer is that P1 needs to be responsible for doing its own tidy-up.
I had a similar issue where I started a PowerShell Process which started a Ping Process, and when I stopped my Java Application the PowerShell Process would die (I would use Process.destroy() to kill it) but the Ping Process it created wouldn't.
After messing around with it this method was able to do the trick:
private void stopProcess(Process process) {
process.descendants().forEach(new Consumer<ProcessHandle>() {
#Override
public void accept(ProcessHandle t) {
t.destroy();
}
});
process.destroy();
}
It kills the given Process and all of its sub-processes.
PS: You need Java 9 to use the Process.descendants() method.
Java does not expose any information on process grandchildren with good reason. If your child process starts another process then it is up to the child process to manage them.
I would suggest either
Refactoring your design so that your parent creates/controls all child processes, or
Using operating system commands to destroy processes, or
Using another mechanism of control like some form of Inter-Process Communication (there are plenty of Java libraries out there designed for this).
Props to #Giacomo for suggesting the IPC before me.
Is you writing other processes' code or they are something you cannot change?
If you can, I would consider modifying them so that they accept some kind of messages (even through standard streams) so they nicely terminate upon request, terminating children if they have, on their own.
I don't find that "destroying process" something clean.
if it is bug, as you say then you must keep track pf process tree of child process and kill all child process from tree when you want to kill parent process
you need to use data structure tree for that, if you have only couple of process than use list
Because the Runtime.exec() return a instance of Process, you can use some array to store their reference and kill them later by Process.destroy().
I am calling a .exe file from my java code using :
Runtime r=Runtime.getRuntime();
Process p=null;
p=r.exec("ABCD.exe");
I want the program to wait till the exe completes its job .(This is actually server side code...control passes to Client side after this).The problem now is that UI on client side is populated before the .exe on server side can form the required components.Hence UI formed does not have the correct files.
I have tried the normal p.waitfor() thing but it doesn't seem to work.
Any suggestions?
The short answer is that you want to call Process.waitFor() in your main thread, as you allude to.
However, dealing with Processes is not exactly fire-and-forget, because, as referenced by the class javadocs, you likely need to be reading the process' output. If you don't do this (which in this case will require a separate thread) then in many instances you'll have an effective deadlock - your Java app is waiting for the process to finish, but the process is trying to write output to a full buffer and thus waiting for the Java app to read its output.
If you gave more information about how "it didn't work", that would help with the diagnosis too.
Edit: on a completely separate point, there's no purpose in initialising p to null and then immediately reassigning it. Your second line would be clearer and less confusing as Process p = r.exec("ABCD.exe");.