This repository was archived by the owner on Sep 16, 2021. It is now read-only.
AsyncMessageProcessorRoute#21
Merged
Merged
Conversation
They are just "Messages" and messages can be "processed." It follows that it is an appropriate abstraction for messages which, in processing, do not need to know about any other message, and do not produce a result other an indication of "success" or "failure" where failure is indicated by an Exception, and success is indicated by the absence of an Exception.
This gives more diagnostic information, and allows us to include the subset of failures which happen before we have a parsed message.
| private final MessageFactory messageFactory; | ||
|
|
||
| private final int idCount = idCounter.getAndIncrement(); | ||
| private final String routeId = "async-message-repository-" + idCount; |
Member
There was a problem hiding this comment.
What meaning does this have? I'd rather see the routeId be something meaningful... like maybe just 'async-message-repository' or somehow encoding the fromUri...
Contributor
Author
There was a problem hiding this comment.
Numeric portion is just so multiple can be instantiated in the same camel context, which is mildly useful if only for testing purposes. fromUri is typically broadcast in many camel log messages so I think it may be redundant to include in routeId / maybe somewhat atypical from what I've seen.
Member
|
Looks good overall. I had a couple minor comments, but nothing big. Merge when ready. |
Contributor
Author
|
Thanks! |
alechenninger
added a commit
that referenced
this pull request
Feb 16, 2016
AsyncMessageProcessorRoute
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
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
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.
This can be used to asynchronously process messages which have business logic completely independent of each other.
For example, incoming document messages can be parsed and as part of processing, update (or insert) entities in a data store (such as lightblue). The handling of any incoming document doesn't need to know about any other. Perhaps you could argue that it could benefit from this, such as if two documents referred to the same entity, then they could coordinate and do one update instead of two, but this is something we should talk about later.
It could also be used to handle incoming messages were are more like "requests" or "command messages" which as a result of processing do something else.
It's generic enough that I think eventually maybe our other types of events could be brought together under this kind of model but, for now those differ in that, in least for document events, processing involves coordinating many document events together and optimizing them, so it is not natural to implement with this additional abstraction just yet.
On the other hand, Notifications as currently implemented could be handled in this model actually. But this is for another conversation, and another PR :).