I'm looking to restart a PM2 process if no new logs for the last X minutes, but not sure if that's possible
I'm not sure which kinds of logs you are looking for, but I assume you want PM2 to restart the application from the start every so many minutes even if there were no unhandled errors.
If this is the case for your issue, you can create a simple setTimeout that will kill your process X minutes after it was started, which will then cause PM2 to restart it from scratch.
This piece of code should suffice:
setTimeout(() => {
process.exit(0);
}, X * 60000);
Just make sure to replace "X" with the number of minutes you need to wait before restarting the application. The number "60000" is 60 (seconds) * 1000 (milliseconds) since setTimeout expects an integer value in milliseconds.
Related
I would love to be able to wait for a random amount of time (let's say a number between 5-12 seconds, chosen at random each time) before executing my next action in Puppeteer, in order to make the behaviour seem more authentic/real world user-like.
I'm aware of how to do it in plain Javascript (as detailed in the Mozilla docs here), but can't seem to get it working in Puppeteer using the waitFor call (which I assume is what I'm supposed to use?).
Any help would be greatly appreciated! :)
You can use vanila JS to randomly wait between 5-12 seconds between action.
await page.waitFor((Math.floor(Math.random() * 12) + 5) * 1000)
Where:
5 is the start number
12 is the end number
1000 means it's converting seconds to milliseconds
(PS: However, if you question is about waiting 5-12 seconds randomly before every action, then you should have a class with wrapper, which is a different issue until you update your question.)
I am new to AWS IoT. I am using "AWSIotDevice" as super class of my virtual device.
By using below, i am able to update shadow on AWS IoT. But my concern is, it is updating shadow every 3 seconds. I don't require it. Shadow should update only after setting new values in my virtual device. It can be after 10 seconds or 30 seconds. I tried using "setKeepAliveInterval" to 30 seconds, but still it is updating shadow every 3 seconds.
Please suggest how to disable it or increase the interval for longer time say 10 minutes or so?
AWSIotMqttClient awsIotClient = new AWSIotMqttClient(clientEndpoint,
clientId, pair.keyStore, pair.keyPassword);
awsIotClient.setKeepAliveInterval(30000);
AWSIotDevice awsIotDevice = new MyAWSIotDevice(thingName);
awsIotClient.attach(awsIotDevice);
awsIotClient.connect(10000);
Really appreciate your help.
Regards,
Krishan
You haven't explicitly said, but that looks like the Java SDK.
That being the case, you need to change the DEVICE_REPORT_INTERVAL, which, as you've notice, defaults to 3000ms.
To do this on AWSIotDevice you should use setReportInterval.
I need the figure out how to manage my retries in Nservicebus.
If there is any exception in my flow, It should retry 10 times every 10 seconds. But when I search in Nservicebus' website (http://docs.particular.net/nservicebus/errors/automatic-retries), there are 2 different retry mechanisms which are First Level Retry(FLR) and Second Level Retry (SLR).
FLR is for transient errors. When you got exception, It will try instantly according to your MaxRetries parameter. This parameter should be 1 for me.
SLR is for errors that persist after FLR, where a small delay is needed between retries. There is a config parameter called "TimeIncrease" defines a delay time between tries. However, Nservicebus do these retries increasingly delay time. When you set this parameter to 10 second. It will try 10.seconds, 30.seconds, 60.seconds and so on.
What do you suggest to me to provide my first request to try every 10 seconds with or without these mechanisms?
I found my answer;
The reply of Particular Software's community(John Simon), You need to apply a custom retry policy, have a look at http://docs.particular.net/nservicebus/errors/automatic-retries#second-level-retries-custom-retry-policy-simple-policy for an example.
Say you have millions of Android GCM device keys and you want to send them in a management script. This script will take loads of time to finish as it's processing the keys in the DB as a queue.
Question: How do you implement this faster? how do you send these notifications in parallel? how do you get to near-real-time push notifications?
One solution would to to instantiate an X number of celery workers where each worker is responsible for an offset Y at which it starts fetching from MySQL.
Example:
Worker 1: starts at offset 0,
Worker 2: starts at offset 10,000,
Worker 3: starts at offset 20,000,
Worker 4: starts at offset 30,000,
Worker 5: starts at offset 40,000,
Worker 1: Restarts at offset 50,000,
Worker 2: Restarts at offset 60,000,
... etc
Is this a viable solution?
Create list of tasks as a Celery group. Also because you have to retrieve all records from Android model it's good to create separate celery task which will do it in background:
#shared_task
def push_notification(offset, limit):
for android in Android.objects.all()[offset:offset+limit]:
pass
#shared_task
def push_notification_to_all():
count = Android.objects.all().count()
limit = 100
group(push_notification.s(offset, limit) for offset in range(0, count, limit)()
push_notification_to_all.delay()
Also instead of sending
I am working on expect scripting. I want to understand the difference between sleep and after. Any example will help me to understand.
There are three different entities:
The Tclx's sleep
The sleep command from the Tclx package. According to the documentation, it takes a decimal argument, taken to be the number of seconds to sleep. However, the fraction part is truncated. That means sleep 2.5 will sleep for two seconds.
The Expect's sleep
The sleep command from the Expect package. This is similar to its counterpart from the Tclx package. However, sleep 2.5 means sleeping for 2.5 seconds, there is no truncation.
After
Finally, the built-in after, which is a totally different beast. The after command takes its first input as the number of milliseconds to sleep off. This is the "synchronous" mode Jerry refers to. After also takes a second argument. In this case, after returns a token right away. After the specified time, the script will be executed. With the token, you can cancel the script.
I hope this helps.
sleep is similar to after "synchronous" mode, with the difference being that (emphasis mine):
Tcl's built-in after command uses delay units of milliseconds whereas the TclX/Expect command works with seconds (i.e., a factor of 1000 different). Be careful when converting.[1]
My try at a short explanation:
The Tcl sleep will like the TclX sleep just pause the script.
The after command can pause the script, but it is normally used for event based programming. It can execute a script after the elapsed time (if the event loop is running).
More on this see here at beedub.com.