High CPU usage when using BlockingWaitStrategy and dependent event handlers

[Mendel Monteiro-Beckerman]

Hello,

I have noticed CPU spikes when I have dependent event handlers in a Disruptor that use the BlockingWaitStrategy and the first event handler is blocked.  Whilst the first event handler is blocked all subsequent handlers will busy spin.

Is this behaviour known and/or desired?

In our code we have modified the BlockingWaitStrategy so that it doesn't busy spin when waiting for dependent sequences.  We use a phased spin/yield/sleep approach.  Would this approach be appropriate in the Disruptor's BlockingWaitStrategy implementation?

Code to reproduce the behaviour:

@Test
public void should_spin() throws Exception
{
 Disruptor<String> disruptor = new Disruptor<String>(new EventFactory<String>() {
     @Override
     public String newInstance() {
     return "Whatever";
     }
 }, 1024, DaemonThreadFactory.INSTANCE, ProducerType.MULTI, new BlockingWaitStrategy());

 disruptor.handleEventsWith(new BlockingHandler())
          .then(new NoOpHandler());

 disruptor.start();

 for (int i = 0; i < 20; i++)
 {
     if (i == 9) // Force a batch
         Thread.sleep(10);

     publish(disruptor);
 }

 //Debug.WriteLine("Sleeping main thread");
 Thread.sleep(Long.MAX_VALUE);

 disruptor.shutdown();
}

private static void publish(Disruptor<String> disruptor)
{
 long next = disruptor.getRingBuffer().next();
 disruptor.getRingBuffer().publish(next);
}

public class NoOpHandler implements EventHandler<String>
{
 @Override
 public void onEvent(String event, long sequence, boolean endOfBatch) throws Exception {
 System.out.println("Got sequence " + sequence);
 }
}

public class BlockingHandler implements EventHandler<String>
{
 @Override
 public void onEvent(String event, long sequence, boolean endOfBatch) throws Exception {
     if (sequence >= 10)
         Thread.sleep(Long.MAX_VALUE);
 }
}

----------------------------------------------------------------------------------------------------

ABC arbitrage, partenaire officiel du skipper Jean-Pierre Dick // ABC arbitrage, official partner of skipper Jean-Pierre Dick // www.jpdick.com

Please consider your environmental responsibility before printing this email

*********************************************************************************

Ce message peut contenir des informations confidentielles. Les idées et opinions presentées dans ce message sont celles de son auteur, et ne représentent pas nécessairement celles du groupe ABC arbitrage.

Au cas où il ne vous serait pas destiné,merci d'en aviser l'expéditeur immédiatement et de le supprimer.

This message may contain confidential information. Any views or opinions presented are solely those of its author and do not necessarily represent those of ABC arbitrage. 

If you are not the intended recipient, please notify the sender immediately and delete it.

*********************************************************************************

[Michael Barker]

This behaviour is known.  I think for simplicity sake I'll leave the existing as is.  Not sure if you are aware, but rather than modifying the BlockingWaitStrategy, copying and creating your own strategy based on it is probably the best approach.  Building your own wait strategy tailored to your use case/desired load profile is perfectly legitimate use.

Mike.

--
You received this message because you are subscribed to the Google Groups "Disruptor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lmax-disruptor+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mendel Monteiro-Beckerman]

Ok, as long as the trade off is explicit.

I wasn't very clear but I had done exactly what you suggest, created another wait strategy which was a modified BlockingWaitStrategy.

To unsubscribe from this group and stop receiving emails from it, send an email to lmax-disrupto...@googlegroups.com.