I need to implement the following functionality:
I have something like a messenger. So, user sends messages, and system should wait 3 sec after last message. So, for example user sends 'Hello!',and system should start countdown, and if 2 seconds passed and user sends 'hey!', it should start counting down again. If 3 secs has passed, special action should fire. Are there any special classes and technologies for this in java and java frameworks?
UPDATE:
Basically I need something ready to implement a time barrier with ability to change waiting time. So, I need to wait 3 secs after LAST message came. So, when API gets message 'Hello', it should start waiting for 3 secs before perform some action. If 2 secs passed and API gets next message 'Hey', it should init it's time counter and start counting down seconds again. So, totally 5 secs are passed. And If there's no message to API for 3 secs after last message, action should run.
If I do Thread.sleep or future.get I specify fixed number of secs to delay, but I want to have ability to change this number online and system should take it. For example:
int counter=5;//any shared seconds quantity holder
while(true){
counter--;
Thread.sleep(1000);
}
....
setCounter(5);//I call somewhere, and loop will be looping again.
But I am looking for something stable and tested, not to invent a bicycle.
Related
Hope you are all Safe
Suppose I have the following process: 2 different sources, queue, delay, and sink.
I have an agent called "patients".
My Goal: to have different service rates (delay time) for patients who are coming from the first source (using percentages). in other words, I want to have for example; 10% of patients (who are coming from source 1) have delay time equal to 5 min and 90% have delay time equal to 10 min.
What I did: is that I assigned a parameter called "percentage" for the agent (patients). and using "On exit" of the first source I typed
agent.percentage = 1;
and then on the delay time I wrote:
agent.percentage = 1 ? uniform(0.1);
But it didn`t work, how can I do that?
You need to both
store the source the agent came from;
randomly determine which delay time you need if they came from a particular source.
So your agent parameter should be called sourceNumber or similar (not percentage), which you set accordingly when you create it (as you did).
Then your delay time is something like the below (assuming the 90%/10% split is only for agents from source 1, and other sources have delay time 50 for illustration):
agent.sourceNumber == 1 ? (randomTrue(0.1) ? 5 : 10) : 50
If you need it more complicated (e.g., more than two source alternatives), or want it to be more 'legible' with Java if statements and similar, you would write a function called, say, getDelayTime which returns a double and include a call to that function in the delay time expression.
NB: If you need individual source 1 agents to always have delay time 5 or 10 (if they go through that delay multiple times) then you need to do the sampling when you create them (and store the delay time they will get in, or an indicator of which delay time they will get, in the agent).
I am testing a certain "functionality" that happens after log in.
The test case is 500 users exercising that functionality within 5 minutes.
I can add a synchronising timer after the log in, to ensure all 500 threads have logged in but then it will do all 500 "functionality" tasks at once, rather than 5 minutes, which will crash the app (it thinks there's a DDoS attack and shuts down).
Right now, I am handling this by giving some think time after login, to slow down login to a stable figure that I can predict and then start "functionality" at each thread's turn, as scheduled by: the main scheduler + the the log in response time + the think time...
But that's a bit fuzzy.
Is there a way to "ramp up" tasks once already running?
I can think in two options.
The first one is two use random times. You would use the range from 0 seconds to 300 - 1 that is [0-300) or using millis [0-300000). Then sleep the thread basesd on this ramdon time.
This approach can be a little more realist, because for instance, in a specific second of the given interval you don't have any threads starting and in other particular second you have 2-3. This still should be well balanced in general, since you won't make all petitions at start.
The second one is to start the threads uniformly. During your configuration time (login and before firing the threads) you can use something like an AtomicInteger, initializing it with new AtomicInteger(0) and calling getAndIncrement() to assign the possition of the thread, in the range [0-500) and then when you fire the threads sleep 300.0 * id / 500.0 milliseconds to execute the task/petition.
By default JMeter executes requests as fast as it can, you can "throttle" the execution to desired throughput (request per minute) rate using Constant Throughput Timer.
Example Test Plan would look like:
Thread Group
Login
Synchronizing Timer
Functionality
Constant Throughput Timer
Constant Throughput Timer follows JMeter Scoping Rules so you can apply it either to single sampler or to a group of samplers.
I am writing a reminder app for Android that repeatedly sends the user a notification with increasing intervals in between. Namely after 30s, 2m, 10m, ..., 25 days, 4 months, 2 years.
I originally intended to do this by registering a JobService that would run every 30s to check whether it was time to send a notification. However, as this post warns (and as I found out):
Which means that my job runs at most once every 15 minutes, and prevents me from sending my 30s, 2m and 10m reminders.
What would be the correct/most efficient way of implementing such functionality?
(Also, running a job every 30s to check for the 2y notification is quite inefficient)
Don't make it a periodic job. Make each next schedule a one-time event. Each time the job is triggered schedule a new item.
I have created two Handlers, which each have Runnable Tasks which run in a loop through:
// do it again 1 hundeth of a sec later
QuestionHandler.postDelayed(QuestionHandlerTask, 10);
And through:
// and do it again 1 sec later
GameHandler.postDelayed(GameHandlerTask, 1000);
Both the tasks start at 10 and count downwards and their results are displayed in labels. The reason i have used 2 handler's is because i want 1 timer to count down by milleseconds and 1 to count down by seconds.
However, the GameHandlerTask that runs once per second runs significantly faster than the other. By the time it reaches 1 the QuestionHandlerTask is still at 4 seconds:
Is this a commonly known problem or have i done something seriously wrong? Is there some way i can make it so my timers run at the same speed? Is there other methods that i can use that would be better in this circumstance (where i want precise timing)?
This is because the screen cannot refresh 100 times per second, which is what is happening with the 10 millisecond timer. So the screen tries to show every single value that you told it to show, but can only do so at its maximum refresh rate.
It is not the timer that is slow, it is the screen that can't keep up with the timer.
To solve this, try to calculate how much does the number need to go down by in 40 milliseconds, and you start a timer of 40ms. This will update the screen 25 times a second, which the screen should be able to handle.
Been experimenting with Jmeter, and I'd like to know the best way to accomplish:
20 users logging onto an application, over 20 minutes, and performing some actions for another 20 minutes, before logging off over a period of 20 minutes. I.e. have 200 users logging on, and then once ALL of them are logged on, begin 20 minute timer. Once 20 minutes are up, start to log the ones who logged on earliest off.
I realise this MAY or MAY NOT BE a realistic testing scenario, but i'd like to see if it's possible.
At the moment I have a test plan whereby a user logs on, performs some actions, and then logs off. I can't see how I can ramp up and ramp down.
There's an option in Test Plan "Run thread groups consecutively". Set it to checked.
Then add 3 thread groups to your test plan. I'd suggest using Thread Group for first (20 threads, loop count 1, ramp up time 1), Ultimate Thread Group (20 threads starting immediately and holding load for 20min) for second and Thread Group again for third (20 threads, loop count 1, ramp up time 1).
Place appropriate samplers inside each TG - first just logs in, second does actions, third logs off.
That's it. If you have any troubles - let me know.
You'll need several thread groups in JMeter starting off and running at different intervals, in that way you could ensure that the users who start first will end first.
Also see a related question on this.
You can have no of users=20, ramp up time=1200 sec (1 per min), difference of time between test start and test end time=20 min to achieve that.
I think I had a similar problem in the past
Here Want I've did:
First set your thread group to have 20 thread with a rampup period of 60 seconds
After the login put a "test action" (in the sampler menu)
target = current thread, with the action pause and 20 minutes (1 200 000 ms) or more if you want to be safe.
After this test action, put all your navigating request.
Once your navigation is done, put another "test action" with the same setting has the previous one
(target = current thread, with the action pause and 20 minutes (1 200 000 ms))
put the logouf request after the sampler.
This should cover you case.
Take note that the sampler just pause your thread so the first thread that start should be the first thread that end.
If you want to scale it to 200 you just need to change your thread group rampup period to 6 or 5 seconds.
hope it's help.