Use the same context to guarantee message delivery order #52
Conversation
|
@vietj, can you review the changes? |
|
we need to come up with a test for this |
|
any test for this ? |
|
@vietj, sure, I will work on it |
…e_order # Conflicts: # src/test/java/io/vertx/rabbitmq/RabbitMQServiceTest.java
|
@vietj , just done |
|
what is the actual thread if we remove run on context ? |
|
the solution appears faulty to me because we should be on the vertx thread and the correct solution would rather be to capture somewhere the context and use context#runOnContext rather than vertx.runOnContext |
|
So |
|
@vietj, can we catch a context in the ConsumerHandler constructor by calling vertx#getOrCreateContext and then use context#runOnContext for handling? |
| })); | ||
|
|
||
| awaitLatch(latch); | ||
| testComplete(); |
There was a problem hiding this comment.
testComplete should not be called here, it is only necessary when called asynchronously and if you call await() in the junit thread
| assertNotNull(json); | ||
| String body = json.getString("body"); | ||
| assertNotNull(body); | ||
| log.info("received: " + body + " expected: " + expectedMessage); |
| channel.basicPublish("", queueName, properties, msg.getBytes("UTF-8")); | ||
|
|
||
| vertx.eventBus().consumer(address, msg -> { | ||
| String expectedMessage = receiveOrderQueue.poll(); |
There was a problem hiding this comment.
rather collect all messages in a synchronized list, remove the latch and use assertWaitUntil(() -> list.size() == 1000) in the main thread, it will be more clear and easier to read
There was a problem hiding this comment.
and check the message order in the junit thread after assertWaitUntil
| AMQP.BasicProperties properties = new AMQP.BasicProperties.Builder().contentType("text/plain").contentEncoding("UTF-8").build(); | ||
|
|
||
| // send messages | ||
| for (String msg : sendingOrder) |
There was a problem hiding this comment.
you should likely publish messages after having etup the event bus consumer
There was a problem hiding this comment.
It is very important to have unconsumed messages in rabbitmq before running a consumer, that is how the problem were discovered. The order might looks like fine when publishing and instantly receiving because of delay between arrived messages.
That is what @tibor-kocsis saying about issue reproducing:
If you run the Sender, then a few minutes later the Receiver, the output will be the following
There was a problem hiding this comment.
ah ok, are we sure then this is enough ?
There was a problem hiding this comment.
I think it is enough
|
looks ok now |
A solution for #51.