According to Erlang memsup documentation:
system_memory_high_watermark = float()
The threshold, as percentage of system memory, for how much system memory can be allocated before the corresponding alarm is set. Te default is 0.80 (80%)
What is the default behaviour when this alarm is set, in case the corresponding alarm_handler is not present.
Quoting from the alarm_handler documentation:
The alarm handler process is a gen_event event manager process which receives alarms in the system. This process is not intended to be a complete alarm handler. It defines a place to which alarms can be sent. One simple event handler is installed in the alarm handler at start-up, but users are encouraged to write and install their own handlers.
So a default alarm handler is installed, which I think simply does nothing at all. You can write your own and attach it to the alarm handler to react to the alarms sent.
If your question is instead what happens if SASL is not started when you start os_mon, it's not possible: see here
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.
I am designing a basket abandoning system for an Ecommerce company. The system will send a message to a user based on the below rules:
There is no interaction by the user on the site for 30 minutes.
Has added more than $50 worth of products to the basket.
Has not yet completed a transaction.
I use Google Cloud Dataflow to process the data and decide if a message should be sent. I have couple of options in below:
Use a Sliding window with a duration of 30 minutes.
A global window with a time based trigger with a delay of 30 minutes.
I think Sliding Window might work here. But my question is, can there be a solution based on using a global window with a processing time based trigger and a delay for this usecase?
As far as i understand the triggers based on Apache Beam documentation =>
Triggers allow Beam to emit early results, before a given window is closed. For example, emitting after a certain amount of time elapses, or after a certain number of elements arrives.
Triggers allow processing late data by triggering after the event time watermark passes the end of the window.
So, for my use case and as per the above trigger concepts, i don't think the trigger can be triggered after a set delay for each and every user (It is mentioned in above - can emit only after a certain number of elements it is mentioned above, but not sure if that could be 1). Can you confirm?
Both answers 1 - Sliding Windows and 2 - Global Window are incorrect
Sliding windows is not correct because - assuming there is one key per user, a message will be sent 30 minutes after they first started browsing even if they are still browsing
Global Windows is not correct because - it will cause messages to be sent out every 30 minutes to all users regardless of where they are in their current session
Even Fixed Windows would be incorrect in this case, because assuming there is one key per user, a message will be sent every 30 minutes
Correct answer would be - Use a session window with a gap duration of 30 minutes
This is correct because it will send a message per user after that user is inactive for 30 minutes
I think that sliding window is the correct approach from what you described, and I don't think you can solve this with trigger+delay. If event time sliding windowing makes sense from your business logic perspective, try to use it first, that's what it's for.
My understanding is that while you can use a trigger to produce early results, it is not guaranteed to fire at specific (server/processing) time or with exact number of elements (received so far for the window). The trigger condition enables/unblocks the runner to emit the window contents but it doesn't force it to do so.
In case of event time this makes sense, as it doesn't matter when the event arrives or when the trigger fires, because if the element has a timestamp within a window, then it will be assigned to the correct window no matter when it arrives. And when the trigger will fire for the window, the element will be guaranteed to be in that window if it has arrived.
With processing time you can't do this. If event arrives late, it will be accounted for at that time, and will be emitted next time the trigger fires, basically. And because the trigger doesn't guarantee the exact moment it fires you can potentially end up with unexpected data belonging to unexpected emitted panes. It is useful to get the early results in general but I am not sure if you can reason about windowing based on that.
Also, trigger delay only adds a fire delay (e.g. if it was supposed to fire at 12pm, not it will fire at 12.05pm) but it doesn't allow you to reliably stagger multiple trigger firings so that it goes off at specific intervals.
You can look at the design doc for triggers here: https://s.apache.org/beam-triggers , and possibly lateness doc may be relevant as well: https://s.apache.org/beam-lateness
Other docs can be found here, if you are interested: https://beam.apache.org/contribute/design-documents/ .
Update:
Rui pointed that this use case can be more complicated and probably not easily solvable by sliding windows. Maybe it's worth looking into session windows or manual logic on top of keys+state+timers
I find state[1] and timer[2] doc of Apache Beam, which should be able to handle this specific use case without using processing time trigger in global window.
Assuming the incoming data are events of users' actions, and each event(action) can be keyed by user_id.
The nice property that state and timer have is on per key and window basis. So you can accumulate state for each user_id and the state is amount of money in cart in this case. Timer can be set at the first time when amount in cart exceeds $50, and timer can be reset when user still have shopping actions within 30 mins in processing time.
Assume transaction completion is also a user_id keyed event. When an transaction completion event is seen, timer can be deleted[3].
update:
This idea is completely on processing time domain so it will have false alarm messages depending on lateness problem in system. So the question is how to improve this idea to event time domain so we have less false alarm. One possibility is event time based timer[4]. I am not clear what does event time based timer mean at this moment.
[1] https://beam.apache.org/blog/2017/02/13/stateful-processing.html
[2] https://docs.google.com/document/d/1zf9TxIOsZf_fz86TGaiAQqdNI5OO7Sc6qFsxZlBAMiA/edit#
[3] https://github.com/apache/beam/blob/master/sdks/java/core/src/main/java/org/apache/beam/sdk/state/Timers.java#L45
[4] https://github.com/apache/beam/blob/master/sdks/java/core/src/main/java/org/apache/beam/sdk/state/TimeDomain.java#L33
In my application I use a winevent hook to get focus changes system-wide. Because there are no timing problems, I use an out-of-context hook, even if I know that it is slow. If there are multiple events fired quickly on after another, the system queues them and gives them to the hook callback function in the right order.
Now I would like to process only the newest focus change. So if there are already other messages in the queue, I want the callback function to stop and restart with the parameters of the newest message. Is there a way to do that?
When you receive a focus change, create an asynchronous notification to yourself, and cancel any previous notification(s) that may still be pending.
You can use PostMessage() and PeekMessage(PM_REMOVE) for that. Post a custom message to yourself, removing any previous custom message(s) that are still in the queue.
Or, you can use TTimer/SetTimer() to (re)start a timer on each focus change, and then process the last change when the timer elapses.
Either way, only the last notification will be processed once the messages slow down.
I want my FSM to terminate any time event doesn't come after specified amout of time in every state.
I can achieve such a scenario only in case there is no event after FSM creation by specifing timeout value in init callback, but I would like to have this functionality working for all of the states as well.
Any easy & quick solution?
Best Regards
Matt
You can set timeout in return tuple in each state {next_state, NextStateName, NewStateData, Timeout}. See gen_fsm documentation for more details. But it works only for case there is not any incoming messages in gen_fsm so it is suitable only if for example you would like terminate process when probably nobody is communicating with it. If you would like hard limits (for protocols for example) you should use erlang:send_after/3 or erlang:start_timer/3 and handle also timer termination and so.
I have a program that occasionally needs to scan some directories recursively (an improvement for this part of the program is in the pipeline, but won't be ready for a while). To avoid the user having to wait for this scanning, I would like to do the scanning while the user isn't using my program when possible.
I intend to implement it by running a timer that checks for idle time. I've found the following for checking system idle time:
http://www.delphitips.net/2007/11/11/how-to-detect-system-idle-time/
This would be functional, but I would prefer to activate the function even when the user is working with other programs on the same computer. This way, if he switches to another program, I could catch up on the scanning I need to do.
I realize that I could do the scanning in a background thread, and either that or some sort of windows hooks will be implemented at some point, but not just yet.
EDIT:
The goal here is a relatively easy change to the program to do any scanning that might be queued while the user isn't actively using MY application. The scanning isn't especially intensive, but it isn't done in a thread, and therefore freezes my app while in progress. Basically, I'm looking for a quick win while I'm working on a more long term solution.
Use the Application.OnIdle event. That event is triggered when your program has no more window messages to handle. The keyboard and mouse both generate messages, so if there are no more messages, then the user is not using your program, even if it has the focus.
procedure TJasonForm.ApplicationEventsIdle(Sender: TObject; var Done: Boolean);
var
NoMoreFiles: Boolean;
begin
// TODO: Scan for the next file
Done := NoMoreFiles;
end;
As long as Done is False and there are no messages in the queue, your program will continue to call that event handler, allowing you to find more files. When the user generates some input, your program will handle the messages before calling OnIdle again.
When you've finished scanning the file system, set Done to True so that the program stops re-calling the OnIdle handler. If you neglect to do that, then your program will use all available CPU time repeatedly calling an event handler that does nothing.
For this to work, you'll need to use a non-recursive search routine. A recursive search will search the whole file system before returning, but if you do that, then the OnIdle handler will hang your program, which is the oposite of what you want. You can use a queue of directory names, and each time the event is fires, pop one item off the queue, search it, and add its contents to the end of the queue.
...but I would prefer to activate the
function even when the user is working
with other programs on the same
computer. This way, if he switches to
another program, I could catch up on
the scanning I need to do.
Stop the scanning in Application.OnActivate and resume in Application.OnDeactivate.
What you need is a separate thread that will be resumed when the system is idle or paused when there is activity. A simple way to do this is to place a Timer Component and check if the system is idle and thread is suspended or not use ResumeThread ,SuspendThread
Look here
http://pastebin.com/8X9Sg42H i crafted something for your situation enjoy