BIND 10 #1145: MessagePack as a possible replacement of MSGQ?

BIND 10 Development do-not-reply at isc.org
Fri Jul 15 11:54:30 UTC 2011


#1145: MessagePack as a possible replacement of MSGQ?
-------------------------------------+-------------------------------------
                   Reporter:  jreed  |                 Owner:  UnAssigned
                       Type:  task   |                Status:  reviewing
                   Priority:         |             Milestone:
  critical                           |  Sprint-20110802
                  Component:         |            Resolution:
  Unclassified                       |             Sensitive:  0
                   Keywords:         |           Sub-Project:  Core
            Defect Severity:  N/A    |  Estimated Difficulty:  0.0
Feature Depending on Ticket:         |           Total Hours:  0
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => UnAssigned
 * status:  accepted => reviewing


Comment:

 Hello

 Short: I recommend not using this.

 The msgpack itself looks like really cool thing. But it is
 serialization/deserialization ‒ in short, we could replace JSON with it,
 but we have trouble with transporting it, not encoding the data. So while
 this might provide some more performance (for the cost of changing a lot
 of things and having to translate configuration and so on), it is not the
 solution we need here.

 It has a msgpack-rpc, which is closer to what we need, but:
  * The documentation only talks about calling remote functions, not about
 any kind of notifications or broadcasts. We would still need to implement
 the message hub for it.
  * The RPC part of C++ is testing stage, python is alpha.
  * There are not many developers (there are few, but each of them seems to
 be focusing on one language binding, the core, C++ and python seems to be
 developed by two people only).
  * It doesn't say what platforms it runs on. It notes that it needs new
 kernel and it does _not_ run on RHEL5/CentOS5 ‒ I don't think they tested
 it on any kind of BSD or Solaris.
  * It depends on some mpio library, which isn't in gentoo repositories
 (which is quite an indicator of „nearly nobody uses it“). The last release
 of this one is from 2004, which indicates it might be dead. I didn't
 manage to compile it, it needs libusb (don't ask me why) and it isn't
 satisfied with libusb-0.1.12 nor libusb-copat-0.1.3.
  * No documentation for the RPC part. The serialization part is
 documented, but there's not much to document anyway.

 So, in short, this might be a good tool for developing website with
 frontend and backend, which will run on a server farm, but not
 distributed, but I think it would cause more trouble for us than solve.

-- 
Ticket URL: <http://bind10.isc.org/ticket/1145#comment:5>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development


More information about the bind10-tickets mailing list