[rabbitmq-discuss] RabbitMQ RoadMap

[Abhishek Kona]

On 02/03/11 8:36 PM, Matthew Sackman wrote:
> On Wed, Mar 02, 2011 at 08:30:50PM +0530, Abhishek Kona wrote:
>>     * Easier way to do Queue Replication (with messages). DRBD and
>>       heartbeat is not the solution I watn to use. It would be better to
>>       have an application level replication (similar to RabbitMQ
>>       clustering).
> Yup. We are working on this. Initially it will depend on clustering too,
> so it might not work well over WANs or in scenarios where network
> partitions are common, but this wrinkle can be addressed later on.
>
Thanks and great to know.
>>     * Messages reappearing in queue after No-ACKs in a set time out.
>>       (client should not be made to hold a connection (and channel) to
>>       do the same).
> Ok, this is a new one. The problem you're trying to solve here is to
> detect slow-consumers and to have messages sent to such consumers
> rerouted if the consumer doesn't process the msg fast enough?
>
Yes. Some times tasks based on items in queue may take lot of time 
(300s), it does not make sense for the consumer to hold the connection 
for so long (also there can be connection termination, in the mean while).
>>     * A better push model to push messages to clients (looking at Java).
>>       The current Consumer model I feel needs to improve for handling
>>       connection terminations.
> Interesting. Can you elaborate on how you feel it needs improving? My
> understanding is that it's pretty robust atm, but then again, I don't
> often use the client libraries.
I need some time to put my thoughts together in this matter. But my 
concerns were earlier voiced at http://goo.gl/QnAcH . I am still looking 
at handling reconnection.
My basic issues are the clients have to keep a connection open (or keep 
polling).  There can to be a other solution (end point registrations at 
server ,  exploring solutions like - 0MQ, rest, pubsubhubbub etc for 
doing that).
>> PS: I do not care about the AMQP protocol much and want a message
>> queue engine more suited to my use case.  So this might be the cause
>> of any of my feature requests not in line with the specification(my
>> ignorance, please forgive).
> We have no problems with extending the protocol to address missing
> functionality from AMQP, as evidenced by our extensions page:
>
> http://www.rabbitmq.com/extensions.htm
> Matthew
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss