Split DefaultExceptionHandler into strict and forgiving versions #74
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Currently DefaultExceptionHandler will close the channel when an unhandled consumer or listener exception occurs. Not everybody agrees this is a great idea. This commit introduces a forgiving version and keeps DefaultExceptionHandler strict. For 3.6.0 we will make DefaultExceptionHandler forgiving.
michaelklishin
added a commit
that referenced
this pull request
Jul 3, 2015
Split DefaultExceptionHandler into strict and forgiving versions
JavierCane
added a commit
to CodelyTV/scala-ddd-example
that referenced
this pull request
Jan 10, 2018
* Purge the queue before performing the test in order to avoid consuming previously published events such as the ones coming from the acceptance tests. * Since the `MessagePublisher` publishes out the messages asynchronously, we were validating that the queue was empty even before publishing the message, so we were not really waiting for the message to be consumed before asserting that the consumed message was the expected one. Now we wait until the queue has messages before starting to consume. * The previous assertion was running in another thread and, since the default exception handler used by the RabbitMQ library is an implementation which catches the exceptions and traduce them into a log error (rabbitmq/rabbitmq-java-client#74), the test was never failing (only logging errors). Now we inject from the test to the messages consumer a handler which extracts the event into a synchronized `mutable.Buffer` in order to perform the assertions proving that the consumed messages are the ones we're really expecting. Since that assertion is performed outside the consumer, the test will fail in case the expected messages doesn't match the consumed ones.
JavierCane
added a commit
to CodelyTV/scala-ddd-example
that referenced
this pull request
Jan 10, 2018
* Purge the queue before performing the test in order to avoid consuming previously published events such as the ones coming from the acceptance tests. * Since the `MessagePublisher` publishes out the messages asynchronously, we were validating that the queue was empty even before publishing the message, so we were not really waiting for the message to be consumed before asserting that the consumed message was the expected one. Now we wait until the queue has messages before starting to consume. * The previous assertion was running in another thread and, since the default exception handler used by the RabbitMQ library is an implementation which catches the exceptions and traduce them into a log error (rabbitmq/rabbitmq-java-client#74), the test was never failing (only logging errors). Now we inject from the test to the messages consumer a handler which extracts the event into a synchronized `mutable.Buffer` in order to perform the assertions proving that the consumed messages are the ones we're really expecting. Since that assertion is performed outside the consumer, the test will fail in case the expected messages doesn't match the consumed ones.
JavierCane
added a commit
to CodelyTV/scala-ddd-example
that referenced
this pull request
Jan 11, 2018
* Purge the queue before performing the test in order to avoid consuming previously published events such as the ones coming from the acceptance tests. * Since the `MessagePublisher` publishes out the messages asynchronously, we were validating that the queue was empty even before publishing the message, so we were not really waiting for the message to be consumed before asserting that the consumed message was the expected one. Now we wait until the queue has messages before starting to consume. * The previous assertion was running in another thread and, since the default exception handler used by the RabbitMQ library is an implementation which catches the exceptions and traduce them into a log error (rabbitmq/rabbitmq-java-client#74), the test was never failing (only logging errors). Now we inject from the test to the messages consumer a handler which extracts the event into a synchronized `mutable.Buffer` in order to perform the assertions proving that the consumed messages are the ones we're really expecting. Since that assertion is performed outside the consumer, the test will fail in case the expected messages doesn't match the consumed ones.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #68.