This is the missing piece in the end-to-end view of the Disruptor. Brace yourselves, it's quite long. But I decided to keep it in a single blog so you could have the context in one place. The important areas are: not wrapping the ring; informing the consumers; batching for producers; and how multiple producers work. ProducerBarriers The Disruptor code has interfaces and helper classes for the Consumer s, but there's no interface for your producer, the thing that writes to the ring buffer. That's because nothing else needs to access your producer, only you need to know about it. However, like the consuming side, a ProducerBarrier is created by the ring buffer and your producer will use this to write to it. Writing to the ring buffer involves a two-phase commit. First, your producer has to claim the next slot on the buffer. Then, when the producer has finished writing to the slot, it will call commit on the ProducerBarrier . So let's look at the first bi
I chose JMock on the back of the QCon conference because there was a session on version 2. I thought I'd take a look at it and see what it does.
ReplyDeleteFor all my test-driven rhetoric I've actually never used any mock framework before so I thought it was about time I took a look into at least one, to see how much easier it might make life.
Mind you recently I've been focussed on functional tests (although in JUnit) because in my particular case it's the data from the DB that is the source of most of our issues so that's where I've concentrated on to start our testing framework.