On June 24, 2011 01:43:56 PM Martin Sustrik wrote: > Hi Henry, > > > I have followed the 0MQ mailing list for about a year, experimented with > > 0MQ and contributed to the 0MQ adaptor for plack. I like many of the > > features of 0MQ, including asynchronous I/O, multi-language support, > > fan-out/fan-in connections and end-point connection syntax. But there > > are a number of things that I find frustrating and that hinder my use of > > > 0MQ for more applications, including: > <snip> > > Thanks for your thoughts on the topic! Unfortunately, the topic is so > broad it can't be answered in a single email. However... > > One thing I am not sure about is whether you are solving a real pressing > technical problem.
Yes, I have a couple of workload distibution applications with highly asymmertric workloads (see my message from from 2011-04-04 "Re: LRU broker queue in intuitive way on 3.0"). I can't figure out how to configure 0MQ in such a way that I can add additional workers after the application has started, because all the messages already have been sent (and queued) to other workers. Also, I am trying to deploy Mongrel2, which uses 0MQ, in a couple of environments. There have have been a couple of issues that have arisen where there has been a misunderstanding as to how OMQ works (e.g Change to ZeroMQ 2.1.x Caused Bug In Mongrel2 Handlers) and where there is no clear idea on how to solve these issues. > If so, have you had a look at traditional messaging > systems like RabbitMQ, ActiveMQ etc.? They mostly work along the lines > you've outlined. > I was looking for something more light weight. Plus, Pieter Hintjens did a good job of convincing me of the advantages of 0MQ in his Switch or Broker? presentation/whitepaper:-) > If, on the other hand, what you are interested in is improving 0MQ, I > would suggest starting with some small piece that would allow you to > become familiar with the codebase rather then trying to redesign the > entire system in a single go. An example would be an advanced message > scheduler that would allow to steer large proportion of messages to a > particular peer (see your bullet no.3). > I presume you are refering to the point about how to fairly queue messages to workers regardless of whether the are directly connected to a ventilator or through a streamer. This is not a small piece and does not address my immediate needs. > Thoughts? I still haven't figured out if making the investment in 0MQ is more profitable than investing in another technology (as you mentioned above) or building something custom that meets my immediate needs. Henry > Martin > _______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev -- Henry Baragar Instantiated Software
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
