[rabbitmq-discuss] .NET API - Using PublishConfirms to get Reliability

[Matthias Radestock]

On 26/02/14 02:03, Marty Wasznicky wrote:
> My first finding was that performance was very slow.  with 250 byte
> messages, I'm getting about 500 to 600 msg/sec delivered.

I encourage you to experiment with PerfTest - 
http://www.rabbitmq.com/java-tools.html#perftest and compare results.

> I then resubmit all the messages in my internal queue on the
> publisher side.  The result is always the same.  I'm always 3 or 4
> messages short!

What do you mean? Are you saying that the publisher got an ack for these 
messages but the consumer never sees them?

> I then retested without a cluster and without shutting down.  After
> my test run..and after the consumer successfully gets all the
> messages I always find the same thing. sometimes I have thousands of
> unacknowledged messages left in my publisher queue.  I'd come back 5
> minutes later....still there.

What do you mean by "the publisher queue"? Are you referring to a queue 
in the publisher or a rabbitmq queue?

> Rabbit MQ is losing a few messages if both servers in the cluster are
> shut down.

I can assure you it is not.

> Second one, Acks/Nacks seem to just get lost by Rabbit MQ.

I can assure you that does not happen.

> Third one...only happens now again...The producer actually receives
> Acks for delivery tags/messages that don't exist in the its internal
> queue.

I can assure you that does not happen.

Please capture a protocol trace for the publisher. 
https://www.rabbitmq.com/java-tools.html#tracer. If there is a problem 
then that will show up there.

> Fourth one....when both servers go down, sometimes, but not always,
> the consumer will not throw an exception when it tries to read the
> message in the while loop

That's normal TCP/IP behaviour. It takes time for disconnects to be 
detected. You can reduce the time by reducing the heartbeat interval 
configured in the client or server.

> if I use the TxCommit and TxRollback....I don't have any issues on
> resending by resending everything in the producer's internal queue.
> Message loss only seems to happen with PublishConfirms

Transactions are actually just a thin wrapper around Confirms. This is 
further evidence that the problems you are seeing are likely due to bugs 
in your application code.


Regards,

Matthias.