[zeromq-dev] More asynchronous broker
Kenneth Adam Miller
kennethadammiller at gmail.com
Thu Dec 4 22:51:32 CET 2014
I'm wanting to open source my broker implementation. What potential
modularity, increased quality, design trait could a broker possess that
would make it more attractive than the bare bones example given on the
guide?
On Thu, Dec 4, 2014 at 4:50 PM, Kenneth Adam Miller <
kennethadammiller at gmail.com> wrote:
> Oh whoops, I went back and re-read the guide, and it seems that perhaps my
> understanding was load balancing broker was using a couple of REP sockets
> on each end... possibly my implementation differs from what was described
> because they use routers, and the routers emit id's that are ferried to and
> from the other side in order that they reach their origin properly.
> Everything is already as asynchronous as I had wanted it already. I updated
> by stackoverflow, but not here, sorry.
>
> Thank you so so much for the reply though.
>
> On Thu, Dec 4, 2014 at 6:59 AM, Pieter Hintjens <ph at imatix.com> wrote:
>
>> We're working on a broker, Malamute,
>> https://github.com/Malamute/malamute-core, which may give you some
>> design ideas. It's not doing the kind of async service request/reply
>> you describe yet, but will.
>>
>> Another option is the zeromq/Majordomo broker, which does already
>> provide async request/reply.
>>
>> On Thu, Dec 4, 2014 at 11:17 AM, Kenneth Adam Miller
>> <kennethadammiller at gmail.com> wrote:
>> > Hello? Can anybody help on this? Is there an alternative design that
>> would
>> > provide the same end somehow?
>> >
>> > On Mon, Nov 24, 2014 at 6:04 PM, Kenneth Adam Miller
>> > <kennethadammiller at gmail.com> wrote:
>> >>
>> >> After reading through the manual about the load balancing broker, I
>> >> thought that it would be great to implement in my own code. So I did,
>> adding
>> >> some additional touches to make it more responsive. One performance
>> >> enhancement I was looking to add was the ability to dispatch to
>> multiple
>> >> long-running work jobs concurrently. I think I'm right about this, I
>> could
>> >> be wrong though, so consider the following with respect to just the
>> lbbroker
>> >> code that's in the manual:
>> >>
>> >> Two workers (clients) simultaneously request work, each with long
>> running
>> >> jobs given to them (by a manager, or manager). In the current code,
>> It's
>> >> good because it's not round-robin-ing the work to different
>> recipients, it's
>> >> selecting FCFS. But there's also a problem in that a reply is first
>> needed
>> >> from the first worker who gets through before work can be dispensed to
>> the
>> >> second worker.
>> >>
>> >> Basically, I want to dole worker out as fast as there are workers
>> ready to
>> >> receive it, FCFS style and concurrently as well.
>> >>
>> >> How can I most easily go about achieving this? Preferably by modifying
>> my
>> >> current lbbroker implementation, which isn't too different from
>> lbbroker in
>> >> the manual. If you could, please suggest changes to lbbroker
>> >>
>> >> Thanks in advance.
>> >
>> >
>> >
>> > _______________________________________________
>> > zeromq-dev mailing list
>> > zeromq-dev at lists.zeromq.org
>> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> >
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20141204/fcbfc7c2/attachment.htm>
More information about the zeromq-dev
mailing list