RabbitMQ transactions issues on server restarts
stm...@gmail.com
Luke Bakken
Michael Klishin
--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-user...@googlegroups.com.
To post to this group, send email to rabbitm...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
stm...@gmail.com
tool it is also lost to the real application and then it is lost.
All sent messages are stamped with unique ids. The log analyzer verifies that all sent messages are received. That is better than using counters. One
duplicate and one lost message will even out with a counter, but will be detected with unique ids.
The tool does handle disconnects and reconnects in the same way as a real application and the errors are logged. There are some places where they are
race conditions that are not detected by the log analyzer. One would need to read the tool's detailed logs and investigate, possibly also in the broker
logs. However, with very few exceptions it is just as stable (or more) as a real JMS application would be. If it detects an issue a real application
would also have an issue.
Produced with roll-back - the total number of produced messages, including ones which were produced and then rolled-back by the producer.
Consumed with roll-back - the total number of consumed messages, including ones which were consumed and then rolled-back by the consumer.
A lost message is, well, gone. Sent but not received. It may be truly lost, it may have been moved to a dead letter queue or the id property may have been lost. Without the id property the message becomes an alien.
A duplicate message has been delivered and (more importantly) committed by the consumer at least twice.
In doubt messages are messages that may have been committed or rolled back or that may be stuck in prepared state. With normal transactions this state is used when the tool has tried to commit but failed. If the failure is due to a broker crash or network failure it is not clear if the problem happened before or after the message was committed on the server. For two phase transactions there are a wide range of errors that leave messages in doubt. In all cases in doubt transactions require more analysis.
A ghost message has been sent, rolled back, but was delivered anyway. For explicit rollbacks (using the rollback option) that is very serious as it means that transactions are broken. There may be rollbacks caused by lost connections or other technical issues where a message has been committed but where the tool assumed it had been rolled back. Normally those messages should be listed as in doubt, but they may end up here.
An alien message is a message without the properties set by the producer. In a correctness test where the consumer is used with the producer and with the id property set, there should be none. For a performance test where messages are generated without the id property they are normal.
An undead message has never been sent, but yet it is not alien. Most likely a log file from another test has been imported, but it is also possible that a message got through without being logged when a producer was killed. That may be correct, or it may be problematic. If there are unexplained undead messages present, keep testing and find out why.