5 ms·

I looked at it, I promise I did. Really wanted to avoid writing this if I could. From what I can see in the docs, RabbitMQ is a client/server relationship. Mea

I looked at it, I promise I did. Really wanted to avoid writing this if I could. From what I can see in the docs, RabbitMQ is a client/server relationship. Meaning there is a server. Meaning a single point of failure and a bottleneck. I hate those more than I hate writing new software. Not because I think there is less danger of bugs in this than there is danger that the AMQP server will fall over... it just feels wrong to me. I'm not saying, by any stretch of the imagination, somebody should use this over RabbitMQ. But if a distributed hash table is more suited to their needs, or if, like me, they're allergic to SPoFs and don't mind if the software is a little less mature if it means avoiding them... Well, now they have a package in Go they can use. If they want to.

JulianMorrison 14y ago
0mq doesn't have a client/server relationship. http://www.zeromq.org/ http://www.zeromq.org/
- brian_cloutier 14y ago
  What does it have?
  - JulianMorrison 14y ago
    Peer-to-peer connections analogous to TCP. In the case of pub/sub all subscribers connect to the publisher. http://zguide2.zeromq.org/page:all http://zguide2.zeromq.org/page:all
    - paddyforan 14y ago
      I guess I was wrong about hard-coding the IPs. Maybe? It doesn't have many-to-many baked in, though. That I can see, at least. It looks like I may have been able to make this work, but the setup would be a little complex. ... because a distributed hash table is not complex at all. -_-
      - JulianMorrison 14y ago
        It doesn't have many-to-many but in my experience most things aren't true many-to-many. More like, there are a handful of publishers in the system and each has a handful of subscribers. Suppose your architecture is API -> Web sockets and you want to make it highly scalable, then what I'd do is: 1. Many API -> few relays (use doozerd to keep up to date as to where the relays are and select one randomly, use ZMQ_ROUTER socket type to enqueue API->relay messages). 2. Few Relay -> many web socket (again using doozerd for the web socket nodes to find the relay, and using ZMQ_PUB on the relay and ZMQ_SUB on the web socket nodes).
        paddyforan 14y ago
        Sounds like it would work, and have great availability and scalability. It just, conceptually, doesn't mesh with how I think about the system. An absolutely aesthetic distinction, I know.
- paddyforan 14y ago
  I believe I looked at that as well. It was six months ago, so forgive me if my memory is a bit off. Looking at the intro, it looks like I have to hardcode the IPs and ports of all of the machines I want to publish or subscribe to. Is that correct? If so, that's a little fragile for my tastes. I like "upgrading servers" by standing up new servers, testing they work, and then changing the floating IP associated with the DNS to point to them instead. And I can hear you say "Aha! Floating IP! Just use that!" but for most cloud providers (I believe), that is billed as external bandwidth, which is not free like internal requests are. Finally, if I want to stand up more servers to scale horizontally, I'd still have to modify my code and redeploy it to all my servers. I think. Unless I'm missing something about how 0mq works. Which I totally could be. On the whole, learning what I needed to learn to make Pastry happen made me a better programmer, too. So if for no other reason than that, I'm glad I did it.
  - JulianMorrison 14y ago
    No more so than with TCP sockets you have to "hard code" the IP connected to. 0mq is low level, it's not going to do routing like Pastry, but you can get away with having one fixed location for a "lookup server" that keeps track of everything else's location (something like the Doozer project, also in Go https://github.com/ha/doozerd https://github.com/ha/doozerd ). Also, 0mq only needs to know the IP of the publisher, for pub-sub.
    - paddyforan 14y ago
      Very cool. Where were you six months ago? ;) I was familiar with doozer, but doozer wasn't(/isn't) being actively maintained and it doesn't compile against the latest version of Go, so I'd have to bring it up to speed before I could use it anyways. Not saying it would be harder, but between that and writing the 0mq library (pretty sure one does not exist in Go yet), I'd estimate the work would be more or less equivalent and yield just about the same stability. Seat of the pants guess, but it makes me feel better, at least.
      - JulianMorrison 14y ago
jeremyjh 14y ago
You didn't look very hard. http://www.rabbitmq.com/ha.html http://www.rabbitmq.com/ha.html
- paddyforan 14y ago
  I thought you just missed this. Apparently I was wrong. I think you're missing the point a little.
old_sound 14y ago
You'll have a single point of failure depending on how you orchestrate your architecture, not if you use RabbitMQ, ZeroMQ or whatever. There's no magic in the software world
- paddyforan 14y ago
  And my application will certainly have its single points of failure. But they will be things that I could not architect around with new software.
rabbitmq 14y ago
This does not make any sense. All software runs on machines. Each machine is potentially a 'single point of failure'. This sometimes is a problem, and sometimes is not. Just because software runs on multiple machines it does not mean that there is 'no SPoF', for example in a distributed messaging system you need to replicate state, unless you don't mind losing it when you have a crash. If you don't mind losing state, then it is very easy to run RabbitMQ on more than one server. If you do mind losing state, then RabbitMQ provides several ways to use multiple servers in a decentralised and redundant manner. See eg http://www.rabbitmq.com/distributed.html http://www.rabbitmq.com/distributed.html It is very easy to write a system with multiple components. The difficulty is preserving all the additional capability (eg uptime) while maintaining a coherent system. This role can be played by a "broker" which does NOT imply a single machine or "SPoF" - it can be a distributed service. See eg http://www.rabbitmq.com/blog/2010/09/22/broker-vs-brokerless/ http://www.rabbitmq.com/blog/2010/09/22/broker-vs-brokerless...
- paddyforan 14y ago
  I mean this in the most neutral and unassuming way possible, but... Are you familiar with the basics of a distributed hash table? To say that "each machine is potentially a single point of failure" is... inaccurate. According to the algorithm's authors, you can lose the vast majority of your cluster simultaneously without affecting the stability of the cluster, in certain cases. As a worst-case scenario, you'll need 16 servers to drop offline simultaneously before there's a problem. Am I saying my solution is better than RabbitMQ? No. Am I saying people should use my solution instead of RabbitMQ? No. Am I saying my solution is closer to what I want than RabbitMQ is? Yes. Yes I am.
  - rabbitmq 14y ago
    Paddy, thanks for asking me if I am "familiar with the basics" of a DHT. Just to be clear, I don't think DHTs are the same as messaging systems. But, they touch on a set of related issues. My assertion was that "Just because software runs on multiple machines it does not mean that there is 'no SPoF'". You seem to have read this as saying "in all cases where there are multiple machines, there is always a SPoF". In any case, I was trying to make a more general point, which is that (A) lots of cases which seem to have no SPoF, in fact do have SPoFs, (B) some cases get accused of having a SPoF, but doing so is a mistake, and Rabbit is in this category because you can set up a number of multi-machine scenarios with the required redundancy, and (C) in many cases having a SPoF is not a problem anyway, and may even be a good thing. You said "From what I can see in the docs, RabbitMQ is a client/server relationship. Meaning there is a server. Meaning a single point of failure and a bottleneck. I hate those..". With all due respect this represents a misunderstanding of Rabbit. Moreover you assert that 'there is a server' means that there is a 'single point of failure'. Because the conclusion does not follow from the premise, I assumed you must have meant something else. Perhaps you could explain why you think your system has fewer 'bottlenecks' than RabbitMQ or other messaging systems. I don't think that it does but would love to be enlightened. From your more recent comment, you seem to be saying that using a DHT is a good thing. Yes, I agree, sometimes this is the case. Are you familiar with how RabbitMQ does any of the following: clustering, HA, federation? You say that "Am I saying my solution is closer to what I want than RabbitMQ is? Yes. Yes I am.". I would love to understand this.

JulianMorrison 14y ago

0mq doesn't have a client/server relationship. http://www.zeromq.org/ http://www.zeromq.org/

brian_cloutier 14y ago
What does it have?
- JulianMorrison 14y ago
  Peer-to-peer connections analogous to TCP. In the case of pub/sub all subscribers connect to the publisher. http://zguide2.zeromq.org/page:all http://zguide2.zeromq.org/page:all
  - paddyforan 14y ago
    I guess I was wrong about hard-coding the IPs. Maybe? It doesn't have many-to-many baked in, though. That I can see, at least. It looks like I may have been able to make this work, but the setup would be a little complex. ... because a distributed hash table is not complex at all. -_-
    - JulianMorrison 14y ago
      It doesn't have many-to-many but in my experience most things aren't true many-to-many. More like, there are a handful of publishers in the system and each has a handful of subscribers. Suppose your architecture is API -> Web sockets and you want to make it highly scalable, then what I'd do is: 1. Many API -> few relays (use doozerd to keep up to date as to where the relays are and select one randomly, use ZMQ_ROUTER socket type to enqueue API->relay messages). 2. Few Relay -> many web socket (again using doozerd for the web socket nodes to find the relay, and using ZMQ_PUB on the relay and ZMQ_SUB on the web socket nodes).
      - paddyforan 14y ago
        Sounds like it would work, and have great availability and scalability. It just, conceptually, doesn't mesh with how I think about the system. An absolutely aesthetic distinction, I know.
paddyforan 14y ago
I believe I looked at that as well. It was six months ago, so forgive me if my memory is a bit off. Looking at the intro, it looks like I have to hardcode the IPs and ports of all of the machines I want to publish or subscribe to. Is that correct? If so, that's a little fragile for my tastes. I like "upgrading servers" by standing up new servers, testing they work, and then changing the floating IP associated with the DNS to point to them instead. And I can hear you say "Aha! Floating IP! Just use that!" but for most cloud providers (I believe), that is billed as external bandwidth, which is not free like internal requests are. Finally, if I want to stand up more servers to scale horizontally, I'd still have to modify my code and redeploy it to all my servers. I think. Unless I'm missing something about how 0mq works. Which I totally could be. On the whole, learning what I needed to learn to make Pastry happen made me a better programmer, too. So if for no other reason than that, I'm glad I did it.
- JulianMorrison 14y ago
  No more so than with TCP sockets you have to "hard code" the IP connected to. 0mq is low level, it's not going to do routing like Pastry, but you can get away with having one fixed location for a "lookup server" that keeps track of everything else's location (something like the Doozer project, also in Go https://github.com/ha/doozerd https://github.com/ha/doozerd ). Also, 0mq only needs to know the IP of the publisher, for pub-sub.
  - paddyforan 14y ago
    Very cool. Where were you six months ago? ;) I was familiar with doozer, but doozer wasn't(/isn't) being actively maintained and it doesn't compile against the latest version of Go, so I'd have to bring it up to speed before I could use it anyways. Not saying it would be harder, but between that and writing the 0mq library (pretty sure one does not exist in Go yet), I'd estimate the work would be more or less equivalent and yield just about the same stability. Seat of the pants guess, but it makes me feel better, at least.
    - JulianMorrison 14y ago

jeremyjh 14y ago

You didn't look very hard. http://www.rabbitmq.com/ha.html http://www.rabbitmq.com/ha.html

paddyforan 14y ago
I thought you just missed this. Apparently I was wrong. I think you're missing the point a little.

old_sound 14y ago

You'll have a single point of failure depending on how you orchestrate your architecture, not if you use RabbitMQ, ZeroMQ or whatever. There's no magic in the software world

paddyforan 14y ago
And my application will certainly have its single points of failure. But they will be things that I could not architect around with new software.

rabbitmq 14y ago

This does not make any sense. All software runs on machines. Each machine is potentially a 'single point of failure'. This sometimes is a problem, and sometimes is not. Just because software runs on multiple machines it does not mean that there is 'no SPoF', for example in a distributed messaging system you need to replicate state, unless you don't mind losing it when you have a crash. If you don't mind losing state, then it is very easy to run RabbitMQ on more than one server. If you do mind losing state, then RabbitMQ provides several ways to use multiple servers in a decentralised and redundant manner. See eg http://www.rabbitmq.com/distributed.html http://www.rabbitmq.com/distributed.html It is very easy to write a system with multiple components. The difficulty is preserving all the additional capability (eg uptime) while maintaining a coherent system. This role can be played by a "broker" which does NOT imply a single machine or "SPoF" - it can be a distributed service. See eg http://www.rabbitmq.com/blog/2010/09/22/broker-vs-brokerless/ http://www.rabbitmq.com/blog/2010/09/22/broker-vs-brokerless...

paddyforan 14y ago
I mean this in the most neutral and unassuming way possible, but... Are you familiar with the basics of a distributed hash table? To say that "each machine is potentially a single point of failure" is... inaccurate. According to the algorithm's authors, you can lose the vast majority of your cluster simultaneously without affecting the stability of the cluster, in certain cases. As a worst-case scenario, you'll need 16 servers to drop offline simultaneously before there's a problem. Am I saying my solution is better than RabbitMQ? No. Am I saying people should use my solution instead of RabbitMQ? No. Am I saying my solution is closer to what I want than RabbitMQ is? Yes. Yes I am.
- rabbitmq 14y ago
  Paddy, thanks for asking me if I am "familiar with the basics" of a DHT. Just to be clear, I don't think DHTs are the same as messaging systems. But, they touch on a set of related issues. My assertion was that "Just because software runs on multiple machines it does not mean that there is 'no SPoF'". You seem to have read this as saying "in all cases where there are multiple machines, there is always a SPoF". In any case, I was trying to make a more general point, which is that (A) lots of cases which seem to have no SPoF, in fact do have SPoFs, (B) some cases get accused of having a SPoF, but doing so is a mistake, and Rabbit is in this category because you can set up a number of multi-machine scenarios with the required redundancy, and (C) in many cases having a SPoF is not a problem anyway, and may even be a good thing. You said "From what I can see in the docs, RabbitMQ is a client/server relationship. Meaning there is a server. Meaning a single point of failure and a bottleneck. I hate those..". With all due respect this represents a misunderstanding of Rabbit. Moreover you assert that 'there is a server' means that there is a 'single point of failure'. Because the conclusion does not follow from the premise, I assumed you must have meant something else. Perhaps you could explain why you think your system has fewer 'bottlenecks' than RabbitMQ or other messaging systems. I don't think that it does but would love to be enlightened. From your more recent comment, you seem to be saying that using a DHT is a good thing. Yes, I agree, sometimes this is the case. Are you familiar with how RabbitMQ does any of the following: clustering, HA, federation? You say that "Am I saying my solution is closer to what I want than RabbitMQ is? Yes. Yes I am.". I would love to understand this.