Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

>We couldn’t seem to find any way to subscribe to events and publish events without a single point of failure.

Really? You think this doesn't exist? In fact, this is nothing but a deployment concern for any mature message broker.

http://www.rabbitmq.com/ha.html

http://activemq.apache.org/masterslave.html

http://hornetq.sourceforge.net/docs/hornetq-2.0.0.GA/user-ma...

There are lots more options than these, and you can also use heartbeat/lvs to take something like redis and make it HA.

I'm glad you had fun inventing your own distributed hash infrastructure, but please do not attempt to convince other people that there are no other options out there for reliable and highly available messaging.



Er. This seems a little overly hostile for something that amounted to "Hey, here's this fun thing I made. Anyone else want to play with it?"

Rather than arguing this point again, I'll just point at the other comment thread that addressed these concerns.

Fun fact: I didn't mention highly available messaging in the post at all. I mentioned single points of failure and bottlenecks. Those aren't quite the same.


A highly available system has no single point of failure.


It can, however, have bottlenecks.

All of your solutions, based on the conversation below, separate the messaging into its own service. Which isn't really how I want to work with my software. I guess the best way I can describe it is as a different aesthetic. There are certainly ways to accomplish the same thing, technologically, but they all feel wrong to me. Introducing a message queue, with a broker, and needing to implement HA on that simply to remove that single point of failure... That feels like a workaround to me. I prefer working with a decentralised pub/sub framework. Personally. Personally, that difference is worth the development time and lack of maturity. To me.

Which is why I slapped an alpha label on the project. Why I made no attempt to convince people they should switch over, or even that my way was objectively better than any other way.

I had an itch. I scratched it. I released the backscratcher I used as open source so other people with the same itch could scratch it. I'm not sure why some people think this is a contemptible act.


Bottlenecks can also be managed with various design and deployment strategies. There has actually been a lot of thought and time put into some of these products and they do have to solve the same problems you are concerned with.

Like I said, I'm glad you had fun with it. But you stated in your article, that there are not existing solutions without a single point of failure, and that simply isn't true. That's the only part I object to.


I think we may have to agree to disagree here. You do not like the way I expressed my dissatisfaction with the previously available solutions, and I do not like they way you expressed dissatisfaction with my attempt to explain my predicament.

I stand by what I wrote, as it is the best way I can explain the, frankly, hard to describe issue I take with separating the messaging component into its own servers. If I had to rewrite it, I don't know how I could explain it any differently and get closer to accurately expressing myself. I'm sincerely sorry if you feel I've misled you or am misleading people; it is not my intention in the slightest. I can't imagine what I could conceivably stand to gain from such a deception.

I would, however, suggest that if people are taking their tech advice from me without doing any research of their own (which is what you seem to be suggesting, as you've commented several times that the information that you believe contradicts me is easily available), perhaps my inability to properly express my reservations with the previously available solutions is not the biggest issue at play here?


>Really? You think this doesn't exist?

That's not what the author said, "we couldn't find" is a personal judgement which leaves things wide open.

>I'm glad you had fun inventing your own distributed hash infrastructure, but please do not attempt to convince other people that there are no other options out there for reliable and highly available messaging.

That didn't happen.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: