My intention is to have a ParentWorkflow launch an independent ChildWorkflow and then NOT wait for the child to finish. When I launch the ChildWorkflow directly from the ParentWorkflow, however, I find that I cannot get this behavior -- the parent always waits for the child. You can set what happens to the child if the parent terminates (cancel, abandon, terminate) but you can't "disconnect" the child from the parent.
I figured a good way to be able to do this is to start an activity LaunchChildWorkflowActivity that will then spawn the child workflow. However, a test run has caused this error to appear:
No context found. It means that the method is called outside of the workflow definition code.
The stack trace indicates that in the LaunchChildWorkflowActivity, calling ChildWorkflowClientFactory.getClient() eventually leads to a getDecisionContext() call which is not allowed in an Activity. So now I'm not sure how to proceed.
One idea is to get the ChildWorkflowClient in the ParentWorkflow, and pass it into LaunchChildWorkflowActivity.launchChild, but I'm not sure that's the best idea since SWF has limitations on the size of objects that can be passed from context to context like this.
(The reason I'm trying to make this work is that I want the logic in the ChildWorkflow be its own indepentent lightweight unit that can be retried alone without having to invoke the ParentWorkflow, which contains rather expensive operations.)
ChildWorkflowClientFactory can be used only from a workflow code. As you are starting workflow from an activity it should use normal client that is used from any external code.
Related
I am building an app which list a set of files. When the user performs an action to one of the files, the action is process intensive (performs multiple ajax requests, updates an offline sqlite database, performs various checks on the file, etc). The user can trigger the said action on multiple files at a time.
The problem is that when the action is performed on more than one file, it blocks the UI. Digging down into the issue, removing certain part of the action (i.e. if I remove the section that performs a verification of the file size, type, and calculate the meta when missing, etc), it wears down the effect of UI lock, though it is still there.
From what I read so far, it is suggested to extract such logic out of the main process i.e. to have a separate process to handle those. The proposed solutions I've read are
use worker thread
create a child process
create a server
I've been struggling to understand and come up with a working example for each. I came across this module named piscina which says to generate workers (my understanding it is a wrapper to create worker thread?).
On the repo here I've setup an example which simulates the issue I have. So if I trigger multiple instances of the action by pressing the "Test" button at the bottom. And then try to increment the count at the top, I can experience the UI lock/lags. It takes approximately 10-15 clicks on the "Test" button to replicate. I can also hear the CPU fan increasing when performing this.
Are there any projects/examples around which gives a simplified implementation on how to mitigate or work around this problem?
EDIT
After #tromgy suggestions I've performed the following updates/test:
Adjusting the await run to a regular promise did seem to solve the issue.
But triggering multiple instances simultaneously, for example, 20, still causes UI lock. Attempting the same on my actual project causes memory heap errors.
I tried moving the Piscina instance outside, rather than creating a new instance on each event, it solves the memory leap, but not the UI lock/lag/freeze issue.
I've tried converting invoke to an actual event, the UI issue still persist.
I am using Vaadin 7.7.10 and I see many UIDetachedExceptions in the logs while using background Threads and the #Push annotation.
Please suggest how to release the resources properly in order to clean my logs.
If you do something in UI.access(..) to the UI that has been already detached, you will trigger an UIDetachedException. This is natural, if for example user has closed the browser, or there has been something in the network that has closed the connection, and thus the UI has been detached. If in your case the UIDetachedException is happening due these reasons, it is harmless. In that case, you can avoid littering your log by checking UI.isAttached() which returns false if the UI has been detached, and UI.isClosing() if the UI has already been put into the clean-up queue.
This happens because the user has closed their browser window or tab which means that the particular UI instance is no longer in use.
The best approach is usually to override the detach method in your application's UI subclass and do the cleanup there. Just remember to also call super.detach().
Another alternative is to catch the UIDetachedException that may be thrown by UI.access and do the cleanup at that point. The drawback of this approach is that you don't get the notification immediately when the UI is detached, but only when trying to do something with it.
my currently running application (A1) needs to be terminated but as well as run some other application (A2). But I need to run application A2 after fully terminated of A1. Now I have something like this:
begin
Application.Terminate;
wait(2000); <<<<<<<
ShellExecute(A2)...
end;
To be more exact - I need to call installation (A2) and want to be sure A1 is not running, because A2 is installation of A1. Please imagine that termination could last more time or it shows some modal dialog...
Is there any easy way how to do it (wait for it)? Of course without communication with or changing of A2! A2 could be anything else in the future.
Vladimír
I need to call installation (A2) and want to be sure A1 is not running.
This is impossible. You cannot execute code in a process that has terminated. Once the process has terminated there is nothing that can execute code.
You'll need a new process. Start the new process with the sole task of waiting on its parent to terminate, and then do whatever is needed once the parent has terminated.
If want to make a proper installer/updater program don't worry about when and how do you execute it but instead how it will detect if your application is running or not.
Now if your main application already has a mechanizm to prevent starting of multiple instances of your application you already have half the work done. How?
Such mechanizms publish the information about an instance of your application already running to be available by other programs.
Most common appraoch to do so is by registering a named Mutex. So when second instance of your application starts it finds out that it can't create a new Mutex with the same name becouse one already exists. So now in most cases second instance of your application sends a custom message to the first instance to bring that instance to the front (restore application) and then closes itself.
If you want to read more about different mechanizms to controling how many instances of your application can be running at the same time I suggest you check the next article:
http://delphi.about.com/od/windowsshellapi/l/aa100703a.htm
So how do you use such mechanizm for your installer/updater?
Just as you would check in second instance of your application to see if another instance is already running you check this in your installer/updater instead. You don't even need to do this schecking at the start of installer/updater. You can do it even later (downloading the update files first).
If there is an instance of your application running you broadcast a custom message. But this message is different from the one that one instance would send to another.
This will now tell your application that it is about to be updated so it should begin the closing procedure.
If you form this custom message in such a way that it also contains information about your installer/updater application.handle you give yourself the ability for your main application to send a return response in which it notifies the installer/updater in which state it is. For instnace:
asClosing (main application is just about to close)
asWaitinUserInput (main application is waiting for user to confirm save for instance)
asProcessing (main application is doing some lengthy processing so it can't shut down at this time)
And if there is no response in certain amount of time your installer could asume that your main application might be hung so it notifies the user that automatic closure of main application has failed and so that the user should close it manually and then retry the updating process.
Using such approach would allow you to start your installer/updater at any time during execution of your main application.
And not only that. You can start your installer/updater by double clicking its executable, by a shourtcut, by some other application or even by a windows task system.
I have an application which needs to run several other applications in chain. I am running them via ShellExecuteEx. The order of running each of the apps is very important cause they are dependant on each other. For example:
Start(App1);
If App1.IsRunning then
Start(App2);
If App2.IsRunning then
Start(App3);
.........................
If App(N-1).IsRunning then
Start(App(N));
Everything works fine but there is a one possible problem:
ShellExecuteEx starts the application, and return almost immediately. The problem might arise when for example App1 has started properly but has not finished some internal tasks, it is not yet ready to use. But ShellExecuteEx is already starting App2 which depends on the App1, and App2 won't start properly because it needs fully initialized App1.
Please note, that I don't want to wait for App(N-1) to finish and then start AppN.
I don't know if this is possible to solve with ShellExecuteEx, I've tried to use
SEInfo.fMask := SEE_MASK_NOCLOSEPROCESS or SEE_MASK_NOASYNC;
but without any effect.
After starting the AppN application I have a handle to the process. If I assume that the application is initialized after its main window is created (all of Apps have a window), can I somehow put a hook on its message queue and wait until WM_CREATE appears or maybe WM_ACTIVATE? In pressence of such message my Application would know that it can move on.
It's just an idea. However, I don't know how to put such hook. So if you could help me in this or you have a better idea that would be great:)
Also, the solution must work on Windows XP and above.
Thanks for your time.
Edited
#Cosmic Prund: I don't understand why did you delete your answer? I might try your idea...
You can probably achieve what you need by calling WaitForInputIdle() on each process handle returned by ShellExecute().
Waits until the specified process has finished processing its initial input and is waiting for user input with no input pending, or until the time-out interval has elapsed.
If your application has some custom initialization logic that doesn't run in UI thread then WaitForInputIdle might not help. In that case you need a mechanism to signal the previous app that you're done initializing.
For signaling you can use named pipes, sockets, some RPC mechanism or a simple file based lock.
You can always use IPC and Interpocess Synchronization to make your application communicate with (and wait for, if needed) each other, as long as you code both applications.
I have a DirectShow filter created with Delphi Pro 6 and the DSPACK direct show library. I'm running under windows XP. I've tried creating the form dynamically when the container class for the DirectFilter has its constructor called, passing NIL into the constructor as the AOwner parameter (TMyForm.Create(nil) and then calling the Form's Show() method. The form does show but then appears to stop receiving windows messages because it never repaints and does not respond to input. As a test I then tried creating my own WndProc() and overriding the Form's WndProc(). My WndProc() did get called once but never again.
I'm guessing it's because I'm a DLL and the context that I am running in is not "friendly" to the window message handler for the form; perhaps something to do with the thread that calls it or whatever. If someone could give me a tip on how to solve this or what the proper way to create a persistent window is from the context of a DirectShow filter I'd appreciate it. Note, as I said the window needs to be persistent so I can't create it as a Filter property page.
Thanks,
Robert
I can't help you with the DirectShow filter specifics, but I feel that some general information about windows and message handling might help.
Windows have thread affinity, which means that all messages for a window will be handled in the context of the thread that created it. That means that this thread needs to have the standard message processing loop, the low level equivalent of Application.ProcessMessages(). Both messages from the same and from other threads will be queued in the message queue of the creating thread, and the message loop will get them, (optionally) translate them, and dispatch them to the window handler of the target window.
What you are describing could be caused by either
not having a message processing queue in the thread that creates the window, or
creating the window in the wrong thread
(Note that these are essentially the same, but stated like this it becomes apparent that there may be different problems that cause this, which need to be fixed in different ways - either the window needs to be created in a different thread, or a processing loop needs to be created in the thread.)
You need to find out which of the two causes your window not to process messages. You don't necessarily need to override WndProc(), message handling methods for distinct messages will work (or not work) the same. That your WndProc() was called once doesn't really tell you much, because under some circumstances messages sent from the same thread will be handled without the message loop, by calling the window proc directly.
Since your filter resides in a DLL I don't think that creating your own message loop would be the right thing. This works for a modal dialog, which will be created, the message loop will run until the dialog is closed, and then the message loop will terminate and the DLL function will return. It will not work for a DLL exported function that will be called and needs to return all while the message loop is still running. I assume the framework that creates and calls those filters will handle the message loop as well. However, that is a gut feeling, not knowing about DirectShow filters this may well be wrong.
What might help you to debug this is a tool like Spy++ from Visual Studio, with which you can show information about windows, log messages sent to them or to all windows in the same process or thread, show window hierarchies and do a lot of other interesting things. If you don't have that, there are a lot of clones (some freeware) on the net, which Google should turn up. Trying to show the messages sent to all windows of the same thread or process should tell you whether a message loop is running. You should also be able to get more information by running SysInternals Process Explorer or similar tools.