INT-2508

[olegz]

Fixed the concurrency issue with PriorityChannel by
introducing private MessageWrapper as an implementation of Message to maintain the contract with the Comparator.The MessageWrapper will maintain the original Message in tact plus
the copy of MessageHeaders + sequence header which previously was injected in the original Message via DFA. The only downside of this approach is the invocation of
new MessageHeaders which generates the UUID, but its much better than the other approach i tried (Proxy)

[garyrussell]

I think there are a number of things that can be done to improve this...

1. Add a field to indicate whether this PC uses a SequenceFallbackComparator.
2. Only wrap the message if the PC uses a SequenceFallbackComparator.
3. Instead of copying the headers, simply make the wrapper wrap the message and a sequence field.
4. Change the SequenceFallbackComparator to cast and use the field (after the priority header).

This avoids manipulating the headers altogether, and avoids the UUID generation.

[olegz]

1. SequenceFallbackComparator is always used to ensure that two messages with the same comparator field value are still ordered in the order they were sent to a PC, so adding the field would not provide any value.
2. Touched an inappropriate file #1 answers it
3. That is what we do everywhere else (e.g., Mongo, Redis), but Comparator's contract is to compare two Messages and we can't break this since 'comparator' field is exposed to the end user where they can provide their own comparator. That is why we went the DFA route the first time.
4. removed inappropriate.txt #3 answers it as well

This is not a simple use case and without introducing a breaking change i am not sure there are many options. As I said before, I also tried Proxy approach (to wrap Message in Proxy), but that has a significant performance impact 1:3, so that is why UUID seemed like not a a big deal.
Ideally it would be nice to have MessageHeaders as an Interface, than I would be able to wrap it in a much nicer way

[garyrussell]

1, 2. Oops - yes, I see, you always wrap the supplied comparator in a SFC.
3, 4. I must be missing something; what is wrong with this...

garyrussell@1b3f2df

??

The wrapper is still a message; we just don't need a new set of headers.

[olegz]

No, i guess i misunderstood what you were saying before. I thought you were proposing to have MessageWrapper not be a Message which would be a problem.
Anyway, yes that will work so i'll change

[garyrussell]

Needs some more polishing (imports and header is no longer used)