[rabbitmq-discuss] persistence

[Alexis Richardson]

Lars

Sorry - we did not answer this last week.

On Thu, May 22, 2008 at 5:05 PM, Lars Bachmann
<lars.bachmann at s2002.tu-chemnitz.de> wrote:
> Mathias,
>
> thank you for your help and all the information you gave me. Now my
> task is to check some other mq brokers and in the end we ll see which
> system fits our requirements the best. The work with rabbitmq was all
> in all very satisfying except this channel bug. I hope it ll be fixed
> soon, but let's first have a look on the problems of the other brokers
> ;-).

Good luck - please do share your results with the list so that we can
all improve RabbitMQ and understand more use cases and deployment
scenarios.


> One more question. In the roadmap the jms integration is mentioned.
> Will this be also realized in the next release of rabbitmq ?

Currently it is possible to run a subset of JMS against RabbitMQ by
using the Qpid M2.1 client.  This turns out to work quite well, and
gives you things like Spring integration, albeit confined to the
subset of cases.  The cases that are not supported yet are in the
further recesses of the JMS TCK.  The most awkward cases are
DTX and serverside Selectors which are addressed in versions of
the AMQP spec, such as 0-10.  We are just working through some
interop issue with other members of the WG which will reduce the
scope for variance in the cases not covered by Qpid M2.1.

Does that answer your question?

alexis


> Lars
>
>> Lars,
>>
>> Matthias Radestock wrote:
>>> Lars Bachmann wrote:
>>>> In our company we comparing different messaging solutions and
>>>> rabbitmq seemed to be a good one, but the problems with the
>>>> presistent messages are unfortunatelly a big minus.
>>>
>>> The problem actually isn't with persistent messaging, but with
>>> sending lots of messages at a rate greater than the broker can
>>> process, and building up backlogs of 10th of thousands of messages
>>> in doing do. Persistence increases the workload and thus lowers the
>>>  processing rate, which makes the problem more noticeable when
>>> persistence is enabled.
>>>
>>> The bug is not causing any difficulties in practice unless *all* of
>>>  the following are true of your clients:
>>> - they publish messages to the broker at a rate that significantly
>>> exceeds the brokers processing capacity
>>> - they sustain such a rate for a significant period of time (i.e.
>>> not just a few second blip)
>>> - they disconnect shortly after sending all these messages
>>
>> I forgot to mention that this is actually a grey area in the AMQP spec.
>> What RabbitMQ is doing is perfectly compliant. We have initiated a
>> discussion in the the AMQP working group to get the spec clarified.
>> Independently of that, as I mentioned, we will fix the the problem in
>> the next release.
>>
>> I should also point out that AMQP's basic.publish is fundamentally
>> asynchronous and thus limited in the guarantees it provides. You get
>> stronger guarantees when wrapping your publish requests in transactions
>> (see channel.tx{Select,Commit,Rollback}() in the Java API). The server
>> guarantees that persistent messages have been written to disk by the
>> time it returns tx.commit-ok, though obviously this carries a
>> performance penalty.
>>
>>
>> Matthias.
>
>
>
>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>



-- 
Alexis Richardson
+44 20 7617 7339 (UK)
+44 77 9865 2911 (cell)
+1 650 206 2517 (US)