0

I'm interested in trying to see how I might leverage the Akka/ZeroMQ module in my project.

In that document, 4 so-called "messaging patterns" are identified but only 1 (Pub-Sub) are explained in detail. They are:

  1. Pub-Sub
  2. Router-Dealer
  3. Push-Pull
  4. Rep-Req

To me (a messaging greenhorn), I don't understand how there could be anything more than Pub-Sub: you have a message, you publish it to a broker, and another process (subscriber) consumes it from the broker.

So my specific question is: what are some concrete use cases for each message ZeroMQ pattern, and why would I ever want to utilize each pattern if Akka already has a mechanism for communicating between threads?

I ask this because the documentation linked above simply states "More documentation and examples will follow soon." for all patterns except Pub-Sub.

smeeb
  • 27,777
  • 57
  • 250
  • 447
  • Just to **avoid** a potential mis-understanding, one may read `PUB/SUB` pattern in more contexts, than just the ZeroMQ-implemented one, so a care is to be taken not to generalise beyond the context limits and not to expect the former to have all the smart features of the latter. – user3666197 Sep 09 '14 at 16:01

1 Answers1

1

Before going into more details right for your question, kindly check another Answer almost identical to your one >>> https://stackoverflow.com/a/25742744/3666197

Q: What are some concrete use cases for each message ZeroMQ pattern

A: Best proceed with the book, you will find many indispensable comments and remarks there

Q: .. don't understand how there could be anything more than Pub-Sub

A: Oh yes, there is a complete new Universe behind that. ZeroMQ is broker-less, zero-copy, incredibly fast to touch just a few ( read below )

Q: why would I ever want to utilize each pattern if Akka already has a mechanism for communicating between threads?

A: Well, it depends. If you are happy with message passing performance for just a few localhost threads ( not much above a few tens ), no need to invest your time into ZeroMQ. If going for high perormance, distributed, (almost) linear scaleability and heterogenous portability, well, then there might be the right time to start reading into ZMQ.

Several links to a few must-read-s

worth for shaping one's mind before moving into details from the ZeroMQ evangelists Pieter Hintjens & Martin Sústrik

An initial view on PUB/SUB from http://250bpm.com/blog:39 ( check and do not miss Martin's cool notes on unit-testing & other gems in his collection )

A very indepth must-have & must-read is a book ( available as pdf ) "Code Connected, Volume 1" If going seriously in for messaging, this is a basis to work with.

A collection of good whitepapers is on http://zeromq.org/area:whitepapers

Community
  • 1
  • 1
user3666197
  • 1
  • 6
  • 50
  • 92
  • Thanks @user3666197 - I'll take a look at that link and digest it. However, one important thing not yet addressed is: *why* would one even need to use this Akka/0MQ module if Akka already has its own mechanism in place for thread communication? – smeeb Sep 09 '14 at 16:09
  • Have you checked performance differencies thereof? Zero-copy memory footprint? Zero-blocking thread-to-thread signalling/synchronisation issues? ZeroMQ spans **transparently** over several transport classes { inproc | ipc | tcp | pgm | epgm } so for distributed / multi-host messaging or thread-to-thread localhost messaging, there is no difference ( but the transport "*distance*" & protocol/unprotocol "*latency*" in TimeDOMAIN ) – user3666197 Sep 09 '14 at 16:20
  • 2
    I'd suggest that place to start learning the ZeroMQ patterns is the Guide, which is online at http://zguide.zeromq.org. – Pieter Hintjens Sep 09 '14 at 16:21
  • Thanks again @user366197 - so are you saying that that Akka/0MQ module **speeds up** Akk actor communication by introducing things such as low-memory footprints, non-blocking thread signaling, etc.? In other words, is it fair to say that one would use this for extremely high throughput between communicating Actors? – smeeb Sep 09 '14 at 16:28
  • @smeeb Cannot speak about your case performance figures, however such tests may prove your expectations, not vice versa. Check performance tests to be able to compare "native" vs. ZMQ-based scenarios. ZeroMQ performance self-measurement tools bring you time resolution down to **sub-microsecond** scale via `zmq.Stopwatch()`. Another sign of being smart, end-to-end. – user3666197 Sep 09 '14 at 16:39