I create a NamedWindow at time 'T', it fires every 5 minutes, assume Subscriber will cost 30 seconds to output all results, for example, T+5min, fire start, T + 5 min + 30 second fire finish. Here is the problem: when I destroy the statements at T + 5 min + 10 seconds, will the subscriber just output 10 seconds and the rest results of 20 seconds be destroyed? subscriber will be interrupted immediately at T + 5 min + 10 seconds?
Esper never uses Thread.interrupt on a subscriber or listener.
Related
For example, I'd like it to trigger at 6:30, 6:40, 6:50, 7:00, 7:10, 7:20..etc
Is it possible to schedule a cron job that starts at 6:30 every day and runs every 10 minutes until 10:00?
I've tried (30/10 6-10 ? * * * *), but that triggers 6:30, 6:40, 6:50, 7:30, 7:40 and misses the triggers between 7 and 7:30
This is on AWS EventBridge's scheduler.
With 30/10 it will start after 30 mins for every 10 mins. Due to this for every hour it will miss the 0-30 mins window
Why not try 0/10 6-10 ? * * *
Starting 3 - 6.00 6.10 & 6.20 will be extra but it works for other times
I am just looking for confirmation that I understand the lambda settings correctly.
The minimum concurrency setting is 10, My lambda function takes 3000 ms.
So does that mean the maximum number of times my function can be called a minute is...
60 seconds / 3 seconds = 20 calls
20 x 10 concurrent = 200 function calls per minute.
thanks
I have a Lambda function that has 3 event triggers here are the Cron job for each:
Cron 1: cron(50/1 22 * * ? *)
Cron 2: cron(50/1 12 * * ? *)
Cron 3: cron(*/15 * * * ? *)
Now Cron 2 Timestamp logs reads as follows, which is ok. Notice that it starts 2-3 seconds into the intended trigger:
10
2021-07-10T05:59:03.867-07:00
11
2021-07-10T05:59:03.867-07:00
12
2021-07-10T05:59:02.314-07:00
START
13
2021-07-10T05:58:02.988-07:00
END
14
2021-07-10T05:58:02.988-07:00
15
2021-07-10T05:58:02.547-07:00
START
BUT Cron 1 & 3 starts over 30+ seconds into the intended trigger. I compared everything possible and there are no settings that are different (to my knowledge). Any idea why 2 of the 3 events have a delay but one doesn't? I understand a small 1-5 second delay by reading here https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/ScheduledEvents.html but somethings seems to be off.
2021-07-10T06:30:37.253-07:00
2
2021-07-10T06:30:37.253-07:00
3
2021-07-10T06:30:33.929-07:00
4
2021-07-10T06:15:36.931-07:00
5
2021-07-10T06:15:36.931-07:00
6
2021-07-10T06:15:33.881-07:00
7
2021-07-10T06:00:34.037-07:00
8
2021-07-10T06:00:34.037-07:00
9
2021-07-10T06:00:33.596-07:00
The precision of Event Bridge is one minute:
All scheduled events use UTC+0 time zone, and the minimum precision for a schedule is one minute. Your scheduled rule runs within that minute, but not on the precise 0th second.
So your delays are perfectly fine and within the 1 minute interval.
I have following test plan to test concurrent user load test of a website -
Configuration set as -
Target Concurrency = 10
Ramp up Time = 1
Ramp up step count = 1
Hold Target rate time = 6
So it's creating confusion, what I am expecting that it will send only 10 requests at a time in 1 second but the result is it sends first 10 request at a time in 1 second and continue sending requests till 60 seconds.
Why it is so?
Keep Hold Target Rate Time to 1 sec to match your expectations.
The graph should reflect the settings you made.
Note: In the graph you shared, it is clearly visible that you kept Hold Target Rate Time to 60 sec (reflected in the graph also) which resulted in 60 seconds execution after ramp-up time.
Reference:
Refer Concurrency ThreadGroup section in the link
as per requirements for simulating 10 requests at a time in 1 second
Target Concurrency = 10
Ramp up Time = 1
Ramp up step count = 1
Hold Target rate time = 1
Keep Hold Target rate time till you want to run to test.
e.g 1 sec for running test plan for 1 sec, 1 min to run test plan for 1 min.
I want to wait 1.5 seconds in a boost thread. Using boost::xtime I can wait an integer number of seconds:
// Block on the queue / wait for data for up two seconds.
boost::xtime_get(&xt, boost::TIME_UTC);
xt.sec++;
xt.sec++;
....
_condition.timed_wait(_mutex, xt)
How can I wait 1.5 seconds instead?
Would the following not work using the nanoseconds and seconds portion and increasing by 0.5 billion nanoseconds and adding a second which is 1.5 seconds
xt.sec++;
xt.nsec += 500000000;
_condition.timed_wait(_mutex, xt);