Re: Using Barrier with high load and got the error "Can't add waiter, no barriers" returned

In fact, for the real one, I intend to inject the concurrent request of the stock instruments containing in below format

IBM: IBM.N,IBM.L,IBM.nK
FB: FB.O,FB.mK
...
...

My script will randomly select each line and split it into dictionary data type. For example, IBM, there will be 3 instruments to be requested, I would like to create a unique barrier for each chain and if the same chain is called again, the barrier should have different name but since there are many agents/worker processes running at the same time the barrier name can then be repeatedly used and that made script stopped working sometimes. I'm guessing the barrier is called and killed by other worker process.. 

Is there any way to generate a unique barrier name for each run (chain) across worker processes/servers?

Thanks much Phil

Thiraphat

On Dec 28, 2013, at 5:31 PM, Philip Aston <[email protected]> wrote:


Assuming you want all the threads across all the processes to be
synchronised, just use some constant for the barrier name, e.g.

   barrrierName="phase1"

- Phil



> On 28/12/13 07:48, Thiraphat Srisati wrote:
> Thanks much Phil for your help. I will try to configure the timeout to something else and re-compile the code. Regarding the unique id, how should I revise the code to avoid duplication?
> 
> Please help
> 
> Thiraphat
> 
> On Dec 27, 2013, at 10:15 PM, Philip Aston <[email protected]> wrote:
> 
> My guess is that the console process is incorrectly determining that the
> worker process is dead and cancelling its barriers. The console relies
> on regular "heartbeat" messages from each worker process. It is possible
> that a lengthy GC or busy network might have delayed this. The console
> will consider any worker that has failed to report for 2 seconds to be
> dead. Unfortunately, this isn't configurable, so you'll have to
> recompile the code to change it. Look at
> net.grinder.console.communication.ProcessStatusImplementation.FLUSH_PERIOD.
> I've opened bug #244 to improve this in the future.
> 
> Also, I see that your unique ID generator isn't working. In your log
> output, I see the same ID being repeatedly used. I'm guessing that the
> whole reason you want to use a barrier is for cross-process
> synchronisation. This implies that you want to use a well known name,
> not a generated one.
> 
> - Phil
> 
>> On 17/12/13 12:39, Thiraphat wrote:
>> The full error returned from a console.
>> 
>> -----
>> 
>> 
>> D:\Distribution\AC>PATH=C:\Program Files\Java\jre6\bin;C:\Program
>> Files\OpenSSH\
>> bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program
>> Files\IBM
>> \Director\bin;C:\Program Files\Common
>> Files\IBM\ICC\cimom\bin;C:\WINDOWS\system3
>> 2\WindowsPowerShell\v1.0;D:\QueryTesting\TclClient
>> 
>> D:\Distribution\AC>java -cp D:\Grinder\grinder-3.6\lib\grinder.jar;
>> net.grinder.
>> Console
>> Exception in thread "main" java.lang.IllegalStateException: Can't add
>> waiter, no
>> barriers
>>       at
>> net.grinder.synchronisation.AbstractBarrierGroups$BarrierGroupImpleme
>> ntation.addWaiter(AbstractBarrierGroups.java:217)
>>       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(MessageDispatchS
>> ender.java:116)
>>       at
>> net.grinder.console.communication.ConsoleCommunicationImplementation.
>> processOneMessage(ConsoleCommunicationImplementation.java:267)
>>       at
>> net.grinder.console.ConsoleFoundation.run(ConsoleFoundation.java:197)
>> 
>>       at net.grinder.Console.run(Console.java:73)
>>       at net.grinder.Console.main(Console.java:92)


------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
grinder-use mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/grinder-use

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk