I've got some issue with executors. Is this the right way to use them?
Everything works fine for couple of hours since program execution, but then I assume threads start to behave a bit strange ...
VPNConnect thread is used to restart the vpn connection at each odd, full hour. The thread checks in the loop what time it is and when the time comes, sets flag 1 in its place on the database.
The other two independent threads do something different in the loops, while checking the flag set by the vpn thread. If the flag has been changed to 1, each thread allows the current loop to end and does not start another one. After finishing the last loop, the Rzeszowiak and NieruchomiamiGdynia thread set their flags to 0.
And now, if both of the above flags are set to 0 and the vpn flag is equal to 1, vpn is disconnected and reconnected, then the vpn thread sets its flag to 0. Threads Rzeszowiak i NieruchomosciGdynia seeing that the thread vpn has the flag 0 arouse work setting its flags on 1.
For the next 2 hours, the Rzeszowiak and NieruchomosciGdynia threads do their job while the vpn thread is set to 0. When the full, odd hour comes, the vpn thread sets its flag to 1 and the game starts again, as I described above.
So what's the problem?
For a short time after starting the program everything works as it should. For example, about 23:00 two threads finish their work, wait for the vpn restart and again arouse to work until 01:00 and then again restart vpn work until 03:00, reboot, etc ... At least it should be theory ...
Practice, however, shows that after a few (sometimes 3, sometimes 4, sometimes 6 - there is no rule) comes to the following situations:
The vpn thread does not disconnect and reconnect, although Rzeszowiak and NieruchomieniaGdynia are waiting for it (0 set on the basis).
The vpn thread disconnects and reconnects, but the Rzeszowiak and NieruchomiamiGdynia threads do not arouse.
I have a strange feeling that after some time these threads are lost somewhere or even disappear. Everything returns to order when I stop the entire program and run it again (without any manual interference in the state of the database). The situation is ok sometimes for 3 hours, sometimes 6 and sometimes even for a day ...
ConfigFile cf = new ConfigFile(args[0], args[1]);
cf.loadFile();
VPNConnect vpnConnectThread = new VPNConnect();
Executors.newSingleThreadScheduledExecutor().scheduleWithFixedDelay(vpnConnectThread,1,60,TimeUnit.SECONDS);
if(cf.getRzeszowiak()!=null && !cf.getRzeszowiak().equals("")) {
RzeszowiakPl rzeszowiakPlThread = new RzeszowiakPl(cf.getRzeszowiak());
Executors.newSingleThreadScheduledExecutor().scheduleWithFixedDelay(rzeszowiakPlThread,1,1,TimeUnit.SECONDS);}
if(cf.getNieruchomsciGdynia()!=null && !cf.getNieruchomsciGdynia().equals("")) {
NieruchomosciGdynia nieruchomosciGdyniaThread = new NieruchomosciGdynia(cf.getNieruchomsciGdynia());
Executors.newSingleThreadScheduledExecutor().scheduleWithFixedDelay(nieruchomosciGdyniaThread,1,1,TimeUnit.SECONDS);}
Related
I added data to Disruptor by calling tryPublishEvent function.
After I wait 40 second and tried to check unprocessedDataCount by following calculation:
long ringBufferUnProcessedCount = disruptor.getBufferSize()
- disruptor.getRingBuffer().remainingCapacity()
Sometimes remainingCapacity value equals to 0, even if before getting ringBufferUnProcessedCount value we wait 40 seconds.
This error happens very rarely.
Do not you know why it might be?
If disruptor.getRingBuffer().remainingCapacity() equals 0 then that means that your disruptor is full and you are experiencing backpressure.
This may be caused by two things, either one of the eventHandlers is blocked for whatever reason and cannot make forward progress or the eventHandlers cannot process events quickly enough to keep up with the rate of production of new events.
I have 1 thread group and I have defined 100 threads and 1 Iteration with a single HttpSampler. Basically I am testing a single GET API.
Now, Jmeter should start 100 threads and then they should fire request to my server which have the API. The server can respond to 100 requests concurrently. So, basically at any point in time I should have 100 concurrency.
But that is not what is happening when I checked through Blazemeter. I get a max users of 37 and total users as 100 which means max concurrency during the test was 37.
This can be possible only if Jmeter did not executed the threads parallel. So where am I wrong ?
I want all threads to execute parallel after they all are created and fire requests at once so that maximum concurrency is 100 for 1 iteration.
If you need more control and accuracy use Ultimate Thread Group JMeter plugin (instead of regular Thread Group)
Set Start Thread Count as 100, with 0 initial delay and 0 Startup Time, with positive Hold time, your thread will hold 100 max users
General example:
If your computer can't handle generating load, you may need distributed testing setup
It is not suggested to use Ramp-Up period as 0.
I think you are making confusion between concurrency (Related to virtual users) and simultaneous (Related to requests or samplers).
To hit requests simultaneously, use the Synchronizing Timer as a child of your requests. It will pause X number of threads and then released at once. And before that, to maintain the concurrency at 100 users, try to use the ramp-up time accordingly (i.e 10 seconds). So it will take 10 seconds for 100 users alive on the server and then hit the requests for 100 users simultaneously.
It doesn't matter which thread group you use but if you maintain the concurrency for more period of time (hold that concurrency), then use Ultimate Thread Group or you can use the loop count accordingly.
If you want to perform spike testing, then the regular Thread group is fine. But you have to remember that, some of your threads might already finish their work and were shut down so you won't see the expected number of the concurrent user.
Here are the example screenshots for 1 minute Test duration (100 users ramp-up time 30 sec + hold load time 20 sec + 10 sec for ramp downtime)
Ultimate Thread Group Config:
Test Results (100 requests at once):
Test Results (100 Concurrent users):
Hope it helps you to understand.
To achieve this, you can use Synchronizing_Timer. Add Synchronization Timer as a child of your GET Request.
The purpose of the SyncTimer is to block threads until X number of
threads have been blocked, and then they are all released at once. A
SyncTimer can thus create large instant loads at various points of the
test plan.
Secondly, to keep a constant load of 100 Request Per Second/Hit Per Second for a time duration, you can use Throughput Shaping Timer. Make sure, you add the Loop Count to Forever and Duration accordingly in Thread Group.
JMeter acts as follows:
The number of threads specified in the Thread Group is being kicked off during the ramp-up period
Each thread starts executing Samplers upside down (or according to the Logic Controllers)
When thread doesn't have any more Samplers to execute or loops to iterate it's being shut down
Assuming all above you may run into the situation when some threads have already finished their work and were shut down and some haven't yet been started. Check out JMeter Test Results: Why the Actual Users Number is Lower than Expected article for more comprehensive explanation if needed
Therefore the solutions are in:
Provide more "iterations" on Thread Group level to let your users loop over, this way you will have 100 concurrent users
If you need to perform some form of Spike Testing and don't want/cannot increase the number of loops just use Synchronizing Timer, this way JMeter will pause the threads until the desired amount is reached and release them at exactly the same moment
Right now I have two threads running in my program. One constantly tries to read input from the user, and the other watches for a timeout. A timeout occurs if the user does not send any input in a given amount of time. The two threads look like this:
User input thread
while(true){
if(in.hasNextLine()){
processLine(in.nextLine());
timeLastRecieved = System.currentTimeMillis();
}
}
Timeout thread
while(true){
//Check for a timout
if(timeLastRecieved+timeoutDuration <= System.currentTimeMillis())
timeUserOut();
else{
//Sleep until it is possible for a timeout to occur
Thread.sleep((timeLastSent+timeoutDuration) - System.currentTimeMillis());
}
}
As of now I have these thread separated, but I could combine them like this...
while(true){
if(in.hasNextLine()){
processLine(in.nextLine());
timeLastRecieved = System.currentTimeMillis();
}
//Check for a timout
if(timeLastRecieved+timeoutDuration <= System.currentTimeMillis())
timeUserOut();
}
But I really don't need to check for a timeout that frequently. So should I combine the threads and check for a timeout too often, or should I have two threads. I am not as worried about performance as I am proper coding etiquette. If it means anything the timeout duration in something like 15 minutes long.
EDIT: Just want to point out that in the version with two thread I am sleeping, but in the combined version I never sleep the thread. This obviously causes the if statement that checks for a timeout to run more then necessary.
To summarize my comments: I don't think a separate thread to check for timeouts is necessary.
Reasons:
You'd need to share information like timeLastRecieved between them, which could be more complex than wanted (e.g. AFAIK in some cases access to long values is not atomic).
From your description it seems that polling for user input and timeout (no input provided in time) are closely related, thus the polling thread could check for the timeout as well. That doesn't mean it has to handle the timeout too, just reporting it somewhere or calling some timeout handler might be better design.
It is easier to read and understand since updating timeLastRecieved and checking for a timeout is handled in the same place.
Since there is no inter-thread communication nor coordination needed (there are no threads that need to communicate) it probably is more robust as well.
A few hints on checking for the timeout:
You should calculate the timeout threshold when you update timeLastReceived and then only check agains the current time instead of calculating it in every iteration.
You might want to calculate the timeout threshold before processing the input in order not to have it depend on the processing time as well.
Finally, there are alternative approaches like using java.util.Timer. Here you could simply schedule a timeout task which is executed when the timeout should occur. That task then would check if the timeout really happened and if not it just returns.
To handle new input before the timeout occured you could use at least two approaches:
Cancel the current timeout task, remove it from the timer and schedule a new one.
If there is already a scheduled timeout task then don't schedule a new one but wait for the current one to run. The current one then checks for the timeout and if none happened it schedules a new task (or itself) for the current anticipated timeout (note that this would require some inter-thread communcation so be careful here).
You need to have two threads - one waiting for data coming in through the InputStream / Reader, and one that's watching the time to see if the time elapsed as taken too long. The only way to do it with 1 thread would be to sleep for a segment of the timeout period and then poll for data periodically. But that's less efficient than having a separate thread dedicated to reading from your InputStream/Reader.
You may want to check out Timeout as a generic option for implementing a timeout
I found a surprising things about Thread.sleep. Thread doesn't wake up in time. Let me explain. I create an activity (no service) and run a thread like the following.
Thread.sleep(50000); // 50 seconds
System.out.println("something");
Then i keep the activity in foreground and off the display (by pressing power button). Also i was logging in a file saved in sdcard. What i found that, After almost 10 min Thread delay 7.35 minutes to print instead of 50 seconds. Is it normal?? Can i trust on Thread.sleep()?
16:47:57 ---- START
--------
-------- (all are in time)
--------
16:57:07 -- (in time)
16:57:57 -- (in time)
17:05:38 --- (late)
Can i trust on Thread.sleep()?
You can trust it to behave as specified1. But the specification says that a sleep will cause the thread to stop for at least that number of milliseconds. Under some circumstances, it could stop for longer. For example, if there is a lot of work for a higher priority thread to do, a lower priority thread may not be woken from the sleep for a long time.
1 - Actually, in theory, it might not behave as specified. But you've tendered no evidence to support that ...
You can try:
LockSupport.parkNanos(nanos)
Or other methods it provides. It's more accurate.
I found out that when you turn off the screen using power button then android go to sleep after sometimes. CPU also go to sleep when screen is off. That's whey Thread.sleep() is giving large delay. In my case my device was in sleep mode for 7.30 minute and when i turn on the screen cpu wake up and start the Thread again. By acquiring the Partial_wake_lock you can hold cpu to go to sleep even when you press the power button(not shutdown).
More details
I encounter a problem with java threads and I am not sure if its related to my approach or if thread pooling is going to resolve what I am trying to achieve.
for (int i = 0; i < 100; i++) {
verifier[i]=new Thread();
verifier[i].start();
}
I initialize 100 threads and start them. In the threads the code that gets executed is just
con = (HttpURLConnection) website.openConnection(url);
// gets only the header
con.setRequestMethod("HEAD");
con.setConnectTimeout(2000); // set timeout to 2 seconds
These threads repeat the process above over a long list of url/data.
The first 50 threads execute almost instantly then they just stop for 60 seconds or so and then there is another spike of execution that 20 of them or so finish at the same time and so on. The same deadlock occurs even if there is 4 of them.
My first guess was a deadlock. I am not sure how to resolve the issue and maintain a constant execution pace, without deadlocks and stops.
I am looking for an explanation of why this occurs and how it can be resolved.
By DeadLock I reefer to the Java Virtual Machine and how it handles thread. Not deadlock caused by my threads.
SCREENSHOT OF THREAD EXECUTION:
It looks like the threads are dying for no reason and I don't know why?!
It could be that the operating system configurable limit of tcp/ip connections gets hit, which causes the JVM to block waiting for a new TCP/IP connection to be created, which will only happen if a connection already used get's closed.
This could help to find what is going on:
profile the run with visualvm which comes with the JVM itself (run it on the command line with jvisualvm). There should be indication of how many threads are created and why are they blocked, deadlocks, etc.
Wait for it to block and take thread dumps of the JVM process to check for deadlocks in the thread stack traces using jstack or visualvm, search for the deadlock keyword.
Check with netstat -nao the state of your TCP connections, to see if the operating system limit is getting hit, if there are many connections in CLOSE_WAIT at the times the blocking occurs
Are you behind a corporate proxy/firewall, you could be hitting some other sort of security limit that prevents you from opening more TCP connections, not necessarily the limit of the operating system
If none of this helps you can always edit the question with further findinds, but based on the description of the code other limits are getting hit that on a first look don't seem related to JVM thread deadlocks, hope this helps.