I have a falcon project who makes use of a Fysom state Machine. The SM change state based on informations from the outside. The SM is created at the app launch and passed to a view as an argument.
At some point I'm waiting for a user event to go in a certain state, which is sent through the API to trigger a SM event.
Problem I have is that when launched with uwsgi the view is not aware of the current state of the state, it considers it's still in its initial state, so I cannot go to the desired state.
The problem does not happen with wsgiref.simpleserver.
I there a way to make the view aware of the changes on the SM ?
Thanks
The problem seems to be related to this:
The SM is created at the app launch and passed to a view as an argument.
Are you sure you still have a reference to the object, or does uwsgi do a copy of the object in each view ?
You could have a look to:
- uwsgi shared memory
- uwsgi caching
Singleton design pattern, see here:
http://python-3-patterns-idioms-test.readthedocs.io/en/latest/Singleton.html
Related
Tested: In order to avoid repeated execution of some code (like chrome.contextMenus.create repeated execution makes
Unchecked runtime.lastError: Cannot create item with duplicate id
), it needs to be moved into chrome.runtime.onInstalled.addListener.
But some code (like chrome.action.onClicked.addListener) moved into chrome.runtime.onInstalled.addListener won't run on next wakeup.
If chrome.action.onClicked.addListener is placed at the top level of the service worker,
will the Listener be added again every time the service worker wakes up,
Will there be multiple duplicate listeners?
will the functions in the new added Listener and in Listener added previous be executed both?
https://developer.chrome.com/docs/extensions/mv3/service_workers/ saying:
A background service worker is loaded when it is needed, and unloaded when it goes idle. Some examples include:
The extension is first installed or updated to a new version.
The background page was listening for an event, and the event is
dispatched.
A content script or other extension sends a message.
Another view in the extension, such as a popup, calls
runtime.getBackgroundPage.
says 'unloaded when it goes idle', will the Listener added previous be unloaded too? ___if so,how awaking service worker again?
or only unload the functions in Listener added previous, and reserve the Listener empty shell just for awaking service worker ?
Yes, it reruns anew.
No, there'll be no duplicate listeners.
No multiple threads, no sleeping/suspending/resuming.
The confusion is caused by a rather inept description in the old version of the documentation, now it's rewritten. What actually happens is that after a certain timeout the service worker is simply terminated. It doesn't "unload" or "resume". It "terminates completely" and "starts fresh".
When it terminates, the JavaScript environment disappears (JS listeners, variables, everything).
When it's started by the browser in reaction to an event to which you subscribed via addListener in the previous run of the SW, your SW script runs in its entirety. Each addListener for a chrome event registers this listener internally. Then the event that woke the worker will be dispatched to the listeners. This is why it is important to register the listeners synchronously in the first task of the event loop when the script starts (the old documentation used a rather arcane term "top-level" from the makers of V8 and oversimplified it to the need to declare the listeners in the global scope of the script, which is not mandatory because you can certainly do it inside a function call as long as it's synchronous).
The contextMenus API is different: the data is saved inside Chrome's internal preferences so there's no need to recreate it on each run, doing it inside chrome.runtime.onInstalled is sufficient. Firefox doesn't save them yet, but I guess they will do it once they implement MV3.
P.S.
The lifetime duration is 30 seconds after the last incoming external event. Using a runtime port adds another 5 minutes to the timeout. Using native host messaging keeps the service worker alive indefinitely, but it is also possible to emulate a persistent service worker to a degree even without native messaging: more info.
Another view in the extension, such as a popup, calls runtime.getBackgroundPage.
This is not true anymore in MV3.
When having multiple hue pages run tez applications at the same time, it, sometimes, will apply the same session to two different tasks, which will cause of of them receiving KILL signal and the other one complains that current app master is being used and retrying. I looked into the code of HiveServerClient._get_tez_session and I think the problem lies in the way busy_sessions is retrieved, which is not thread-safe. So there's chance that two query will be allocated to the same session when submitted virtually the same time.
I'd like to know is there any way to get current editor id (doc_id) from HiveServerClient._get_tez_session method, so I could do some hacking for a quick solution now. Thanks.
You can solve this by disabling Tez session mode
set tez.am.mode.session=false;
Session mode is more aggressive in reserving execution resources and
is typically used for interactive applications where multiple DAGs are
submitted in quick succession by the same user. For long running
applications, one-off executions, batch jobs etc non-session mode is
recommended. If session mode is enabled then container reuse is
recommended.
Also try to disable container reuse:
set tez.am.container.reuse.enabled=false;
See all Tez configuration settings here.
Also read this thread about Tez session naming.
I did not test it myself, maybe you can use hive.session.id property for getting/setting session id's.
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.