Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#1145 closed task (complete)

MessagePack as a possible replacement of MSGQ?

Reported by: jreed Owned by: UnAssigned
Priority: high Milestone: Sprint-20110802
Component: Unclassified Version:
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: Core Feature Depending on Ticket:
Estimated Difficulty: 5 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description (last modified by shane)

This is subtask of #765, investigating if MessagePack could be used as a replacement for our MSGQ.

See Aharen's email at
https://lists.isc.org/mailman/htdig/bind10-dev/2011-June/002340.html
http://msgpack.org/

Subtickets

Change History (7)

comment:1 Changed 8 years ago by shane

  • Description modified (diff)

comment:2 Changed 8 years ago by stephen

  • Milestone changed from New Tasks to Sprint-20110802

comment:3 Changed 8 years ago by shane

  • Priority changed from major to critical

comment:4 Changed 8 years ago by vorner

  • Owner set to vorner
  • Status changed from new to accepted

comment:5 Changed 8 years ago by vorner

  • Owner changed from vorner to UnAssigned
  • Status changed from accepted to reviewing

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.

comment:6 Changed 8 years ago by shane

  • Resolution set to complete
  • Status changed from reviewing to closed

Okay, makes sense. An interesting technology, but not a perfect fit.

comment:7 Changed 8 years ago by stephen

  • Estimated Difficulty changed from 0.0 to 5
Note: See TracTickets for help on using tickets.