# Disruptor 2.0 Released

DevFeed: [Disruptor 2.0 Released](<https://devfeed.tech/articles/disruptor-2-0-released-13612.md>)

Original publisher: [Read original article](<https://mechanical-sympathy.blogspot.com/2011/08/disruptor-20-released.html>)

Author: Martin Thompson (noreply@blogger.com)

Published: 2011-08-27T08:49:00Z

Content type: release

Language: en

Sources: [Mechanical Sympathy](<https://devfeed.tech/sources/mechanical-sympathy.md>)

Topics: [Concurrent Programming](<https://devfeed.tech/topics/concurrent-programming.md>), [Java](<https://devfeed.tech/topics/java.md>), [Programming](<https://devfeed.tech/topics/programming.md>)

Tags: [concurrent](<https://devfeed.tech/tags/concurrent.md>), [concurrent-programming](<https://devfeed.tech/tags/concurrent-programming.md>), [dependency](<https://devfeed.tech/tags/dependency.md>), [disruptor](<https://devfeed.tech/tags/disruptor.md>), [framework](<https://devfeed.tech/tags/framework.md>), [graph](<https://devfeed.tech/tags/graph.md>), [java](<https://devfeed.tech/tags/java.md>), [performance](<https://devfeed.tech/tags/performance.md>), [queue](<https://devfeed.tech/tags/queue.md>), [release](<https://devfeed.tech/tags/release.md>)

## AI overview

This release article announces Disruptor 2.0, highlighting a cleaner API, renamed event-processing concepts, a DSL for assembling EventProcessor dependency graphs, and substantial performance improvements over queue-based approaches.

## Source excerpt

Significantly improved performance and a cleaner API are the key takeaways for the Disruptor 2.0 concurrent programming framework for Java. This release is the result of all the great feedback we have received from the community. Feedback is very welcome and really improves the end product so please keep it coming. You can find the Disruptor project here, plus we have a wiki with links to detailed blogs describing how things work. Naming & API Over the lifetime of the Disruptor naming has been a challenge. The funny thing is that with the 2.0 release we have come almost full circle. Originally we considered the Disruptor as an event processing framework that often got used as a queue replacement. To make it understandable to queue users we adopted the nomenclature of producers and consumers. However the consumers are not true consumers. With this release the consensus is to return to the event processing roots and adopt the following naming changes. Producer -> Publisher Events are claimed in strict sequence and published to the RingBuffer. Entry -> Event Events represent the currency of data exchange through the dependency graph of EventProcessors. Consumer -> EventProcessor Events are processed by EventProcessors. The processing of an event can be read only, but can also involve mutations on which other EventProcessors depend. ConsumerBarrier -> DependencyBarrier Complex graphs of dependent EventProcessors can be constructed for the processing of an Event. The DependencyBarriers are assembled to represent the dependency graph. This topic is the real value of the Disruptor and often misunderstood. A fun example can be seen playing FizzBuzz in our performance tests. The ProducerBarrier was always a one-to-one relationship with the RingBuffer so for ease of use its behaviour has been merged into the RingBuffer. This allows direct publishing into the RingBuffer. DSL Wizard The most complex part of using the Disruptor is the setting up of the dependency graph of EventP