zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Віталій Тимчишин <tiv...@gmail.com>
Subject Re: ExecutorService over a zookeeper
Date Mon, 14 Feb 2011 08:48:22 GMT
Sorry for second e-mail, did not answer the whole thing

You should not publish results in ZK but use some other communication
> method.
>
I do. But i need to tell that result are ready and available on this
address.



> ZK is really not meant as a messaging solution.
> Maybe you'd be better served with a standard message queue (e.g. Apache
> activeMQ, rabbitMQ) and use ZK only for coordination? If you have really
> high
> message load, you could have a look at Hedwig (google://zookeeper hedwig).
>
>
After few years working with activeMQ, I hate it. As other projects workers
in our company do. I simply hangs after some time with no apparent reason.
It does not like rollbacks. (Vitalii, please stop or this won't be a
Zookeeper e-mail :) ).
But why Zookeeper is not a messaging? Actually I was suggested Kafka in this
thread, and it looks like messaging solution. The problem is that JMS-like
messaging does not suit me. First of all, it does not alove a message to be
cancelled. Then, it gives no control over message processing (Producer may
want in future to control message requeue on Consumer failure for "bad"
message not to put down all Consumers one by one). Also it requires at least
two queues to handle responses (I've used Queue + Topic for Hazelcast) I
already has support for Hazelcast & Grid-Gain, but there are certain problem
with them. That's why I am trying Zookeeper now.
As for storage for both tasks & responses, we are using NFS now and may move
to HDFS if Zookeeper will be adopted successfully (or, better say, it's
orthogonal to clustering solution selection).

-- 
Best regards,
 Vitalii Tymchyshyn

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message