Java Disruptor pattern and low latency

Question

Q1) Does anyone familiar with the Java Disruptor pattern know the size of messages they benchmarked their results against? I am writing a similar system (out of pure interest) and when I read the description of their testing there is no mention of the message size sent?

http://code.google.com/p/disruptor/wiki/PerformanceResults

Q2) Is the disruptor for computer to computer communications, or inter-process? I originally had the impression it was for computer to computer but their work is labelled "inter thread" messaging library?

Answer 1

Disruptor is not just within the same machine, it is withing a single process. When they say "inter-thread", they mean that it is for sending messages between threads of one process.

The message size is actually almost irrelevant because the messages don't get copied. The messages are all fixed at the beginning and reused, so it doesn't really matter how big they are.

Answer 2

Although Im not entirely familiar, just exploring it...

1) It looks like from the perf test folder in the src that they are using the ValueEvent class, which just holds a long, there is also some other xxxEvent classes that are used in other perf tests that are slightly bigger but from what i can gather so far, only a long is used within the ring buffer.

2) I would assume it is for completely same machine inter thread comms. the latency & uncertainty of comms across machines would make it extremely slow. (relatively) and then the project would also need to deal with socket comms, which I haven't seen in this lib.

Answer 3

1,Disruptor not care the size of message. but result should be linearly down by size of message(workload increased, the speed decreased)

In deed it's not care the message.

The KEY of the library is the ID of buffer. pointer, position, cursor, indicator, all both mean the same. Disruptor self call it as "sequence"

Once the ID got, the whole world only owned by you!:) so ONLY one writer. the real key point.:)

2,not C2C, nor P2P:). just T2T. the T is thread. peter-lawrey have a great library Java-Chronicle, can be used in P2P case. a new article on java dzone: http://java.dzone.com/articles/ultra-fast-reliable-messaging

3, the core pattern should be capable to clone to cross boundary use cases. every thing is ID. As to the message, customerized.

4, another important point, is the cache of volatile. a great example on github

5, JDK8 intro a new annotation @Contended, seems sexy. details about contended