AssertionError on barrier addWaiter
Amaury Denoyelle <[email protected]> Fri, 5 May 2017 09:02:59 +0200
| Newsgroups | gmane.comp.java.grinder.user |
|---|---|
| Message-ID | <20170505070259.k9LVPX68y%[email protected]> |
Hello everyone,
I'm using The Grinder 3.11 for load test. My configuration is :
- The Grinder console on one host
- 2 agents on two separate hosts, each running 10 processes / 500 threads
So, the total of threads running is 10,000. During scenario, each
threads are synchronised over the same barrier (not at the same time,
each thread calls time.sleep(threadNumber) before waiting on the
barrier). But randomly during test execution, a Java exception is thrown
from the console, probably when some threads call barrier.await().
Output of the console (BarrierIdentity is truncated, as it shows 411
strings):
Exception in thread "main" java.lang.AssertionError: (411 [BarrierIdentity[Process 'ibmblade01-4' [ibmblade01-4:411631404|1493911201434|2103114530:5], 1134], BarrierIdentity[Process 'ibmblade01-4' [ibmblade01-4:411631404|1493911201434|2103114530:5], 1375] [...]
at net.grinder.synchronisation.AbstractBarrierGroups$BarrierGroupImplementation.addWaiter(AbstractBarrierGroups.java:221)
at net.grinder.console.synchronisation.ProcessBarrierGroups$1.addWaiter(ProcessBarrierGroups.java:87)
at net.grinder.console.synchronisation.WireDistributedBarriers$3.handle(WireDistributedBarriers.java:100)
at net.grinder.console.synchronisation.WireDistributedBarriers$3.handle(WireDistributedBarriers.java:96)
at net.grinder.communication.MessageDispatchSender.send(MessageDispatchSender.java:116)
at net.grinder.console.communication.ConsoleCommunicationImplementation.processOneMessage(ConsoleCommunicationImplementation.java:287)
at net.grinder.console.ConsoleFoundation.run(ConsoleFoundation.java:226)
at net.grinder.Console.run(Console.java:69)
at net.grinder.Console.main(Console.java:86)
Looking at the code where the exception is thrown, it seems that
m_barriers and m_waiters.size() are equal (411)
(synchronisation/AbstractBarrierGroups.java).
The barrier is used properly as described in documentation. It is
defined in __init__ function and await used in __call__. All threads are
started at the same time, and none are cancelled prematurely.
Do you have any idea of the cause of the problem ? Is 10,000 threads
waiting on one barrier a little bit overkill ?
Thank you for your help,
--
Amaury Denoyelle
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot