[
https://issues.apache.org/jira/browse/CAMEL-5828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Riccardo Sirchia updated CAMEL-5828:
------------------------------------
Attachment: README.md
Hey Willem,
I attached a README.md to this issue to be used for documentaion.
Regarding the problem with unit tests: I've tried many times but unfortunately
I'm unable to reproduce it... Can you post some stacktrace/additional details
to explain what exactly is going wrong?
To explain why it differs from the implementation of SEDA: the main cause lies
in the fact that the SedaConsumer itself is responsible for distributing the
exchange to multiple consumers where the Disruptor logic takes care of the
multicasting in my component. This implies that the synchronization point
should also lie within the Disruptor logic.
To compare the solutions:
SedaConsumer copies the incoming exchange (including handover synchronisations)
to prepare for distribution to the processors. If the exchange is multicasted,
the handover completion synchronisations are taken out of the copied exchange,
it is distributed to all processors and it triggers the synchronisations after
they have all finished.
The Disruptor stores the published exchange (which was copied earlier by the
DisruptorProducer) in a pre-allocated, mutable ExhangeEvent on the RingBuffer
(managed by the DisrutprReference). The DisruptorReference knows how many
unique DisruptorConsumers are consuming from that Disruptor and passes this
information along to the ExhangeEvent. The ExchangeEvent is then given to all
registered DisruptorConsumers, each executing on their own thread, which copy
the exchange (without the handover synchronisations) and notify the
ExchangeEvent when they are done processing. The ExchangeEvent counts all
finished consumers and upon completion of the last performs the handover
synchronisation.
I have a change pending (will post patch tomorrow) that takes the
handoverCompletions from the published exchange before it is provided to all
consumers (more in line with how SEDA works).
I noticed however that while I was fixing some other threading issues ealier
(coincidentally also regarding handover sync etc), I introduced some severe
performance problems making the disruptor slower than the SEDA component :)
This happened because I tried to improve upon the request-reply behaviour of
SEDA in multicast scenarios (make it more feature rich), however it is not
worth doing so when it will cost the main advantage of the Disruptor.
The pending patch will rollback these changes and as mentioned make the code
more clear on the completion synchronisation.
Riccardo
> Offer LMAX Disruptor pattern as an endpoint in CAMEL
> ----------------------------------------------------
>
> Key: CAMEL-5828
> URL: https://issues.apache.org/jira/browse/CAMEL-5828
> Project: Camel
> Issue Type: New Feature
> Reporter: Eric
> Assignee: Willem Jiang
> Fix For: Future
>
> Attachments: camel-disruptor.patch, README.md
>
>
> My system is an hybrid of CAMEL and LMAX Disruptor, where threads consuming
> from LMAX ringbuffer are feeding a "pool" of SEDA queues in a round-robin
> fashion. This system operates at very high-speed such as consumers from the
> SEDA queues and their producers are constantly blocking on the queues.
> Having a non-blocking, high-performance endpoint like LMAX Disruptor would be
> a great addition to CAMEL.
> LMAX Disruptor website: http://lmax-exchange.github.com/disruptor/
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
