Add support for specifying custom header for 'sequenceNumber' in Resequencer [INT-2159]

[spring-operator]

Oleg Zhurakousky opened INT-2159 and commented

---

This issue is a sub-task of #6135

[spring-operator]

Oleg Zhurakousky commented

Based on discussion with Gary there is a valid use case with NIO where re-sequencing must be done by evaluating custom header in place of the sequenceNumber header.

[spring-operator]

Mark Fisher commented

Such a requirement could always be handled by a very simple header-enricher though, correct? Example:

<header-enricher name="sequenceNumber" expression="headers.whatever"/>

[spring-operator]

Gary Russell commented

Yes, of course.

When using NIO, tcp messages can be dispatched in a different sequence to that in which they arrived on the socket. I therefore added a sequence number header (ip_connection_seq) [I now realize it should have been 'ip_connectionSequenceNumber' or similar].

I did this because I didn't want sequenceNumber stomped on by a downstream splitter/aggregator (this was before we pushed/popped sequence details). I figured they may want to resequence some time after a splitter/aggregator pair. I also didn't realize that the standard resequencer was no use anyway because it

a. is group-based, and
b. relies on sequenceNumber/sequenceSize headers.

Now that we push/pop sequence details, an alternative to supporting a parameterized sequence number header would be to have the tcp adapter set the sequenceNumber header (as well as the existing header for backwards compatibility).

[spring-operator]

Oleg Zhurakousky commented

So i think this issue can be resolved as 'Won't Fix', since Resequencer no longer requires 'sequenceSize' to be present. In other words if 'sequenceSize' is not present it is automatically an unbounded Resequencer, so based on your explanation either adding HeaderEnricher or another attribute to TCP endpoints to add 'sequenceNumber' header would do the trick.

[spring-operator]

Gary Russell commented

Agreed, but I think we should not require everyone to add header enrichers; see #6148

[spring-operator]

Oleg Zhurakousky commented

Resolving it as 'Won't fix'. The current solution is as simple as add header-enricher. There is also a more configurable solution under way for TCP see #6148