-
Bug
-
Resolution: Not an Issue
-
P3
-
None
-
7u17
-
x86
-
linux_redhat_6.0
FULL PRODUCT VERSION :
java version "1.7.0_17"
Java(TM) SE Runtime Environment (build 1.7.0_17-b02)
Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Linux 2.6.32-220.el6.x86_64 #1 SMP x86_64 x86_64 x86_64 GNU/Linux
A DESCRIPTION OF THE PROBLEM :
Application which I am using is processing a lot of xml messages in individual tasks.
For that an Executor is created like below:
executor= Executors.newSingleThreadExecutor
and task added with execute.
executor.execute(task);
Application was working like this for some time.
We just discovered that under heavy load ,the order in which the threads were added in the executor is not anymore respected.
The latest one are jumping in front of the queue from time to time.
The documentation is saying clearly that sequential order is respected , and the LinkedBlockingQueue which is used has the FIFO principle.
The code is just simple, the tasks are just added in the executor, is not anymore where I can check.
Tasks are added from the same thread.
I verified that this is the problem, as the logs are reporting the newer threads are staring earlier.
This is an example logging when happening.
1:00:01.100 DEB new thread[id:500]
1:02:01.160 DEB new thread[id:900]
1:03:01.200 WAR Started thread [thID:900]
1:04:02.200 WAR Started thread [thID:500]
Also is not due to some logging delay, especially as is one task at the moment , so that is not the case.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
I didn't manage to reproduce in normal loading conditions, it happens only under heavy load.
REPRODUCIBILITY :
This bug can be reproduced often.
java version "1.7.0_17"
Java(TM) SE Runtime Environment (build 1.7.0_17-b02)
Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Linux 2.6.32-220.el6.x86_64 #1 SMP x86_64 x86_64 x86_64 GNU/Linux
A DESCRIPTION OF THE PROBLEM :
Application which I am using is processing a lot of xml messages in individual tasks.
For that an Executor is created like below:
executor= Executors.newSingleThreadExecutor
and task added with execute.
executor.execute(task);
Application was working like this for some time.
We just discovered that under heavy load ,the order in which the threads were added in the executor is not anymore respected.
The latest one are jumping in front of the queue from time to time.
The documentation is saying clearly that sequential order is respected , and the LinkedBlockingQueue which is used has the FIFO principle.
The code is just simple, the tasks are just added in the executor, is not anymore where I can check.
Tasks are added from the same thread.
I verified that this is the problem, as the logs are reporting the newer threads are staring earlier.
This is an example logging when happening.
1:00:01.100 DEB new thread[id:500]
1:02:01.160 DEB new thread[id:900]
1:03:01.200 WAR Started thread [thID:900]
1:04:02.200 WAR Started thread [thID:500]
Also is not due to some logging delay, especially as is one task at the moment , so that is not the case.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
I didn't manage to reproduce in normal loading conditions, it happens only under heavy load.
REPRODUCIBILITY :
This bug can be reproduced often.