Set correlationId and sequenceNumber Headers in Messages Originated by Tcp Endpoints [INT-2162]

[spring-operator]

Gary Russell opened INT-2162 and commented

Unbounded message groups will be supported by #6135, using standard headers. Tcp messages currently contain correlation and sequence data in separate headers, requiring header-enrichers upstream of the resequencer. Adding the standard headers (as well as the custom headers) will allow the resequencer to be used out of the box.

---

Affects: 2.1 M1

This issue is a sub-task of #6135

[spring-operator]

Mark Fisher commented

On routers and publish-subscribe-channels we have the "apply-sequence" boolean flag. I wonder if we could do the same for TCP endpoints. The behavior could be such that values go to "sequenceSize" and "sequenceNumber" instead of the current headers. Since this would be a new flag, it wouldn't break backwards compatibility that way (as long as it's false by default).

[spring-operator]

Oleg Zhurakousky commented

I like it +1

[spring-operator]

Gary Russell commented

I have no issue with that, and I like the way it allows us to deprecate the old headers, maybe removing them in 2.2.

However, I have another problem. I was going to use the connection id as the correlation id. Currently, this is NOT a UUID and I am concerned about re-use after JVM restart, because the sequenceNumber will start at 1 again. So, I want to set the correlation id (for all messages emanating from a socket) to a UUID corresponding to that socket. My problem is you have taken great pains to NOT expose the custom Id generator (if any) on MessageHeaders.

One kludge would be to create a dummy message on connection instantiation and use its ID.

An alternative would be to change the connection id from

this.connectionId = this.hostName + ":" + this.port + ":" + connectionNumber.incrementAndGet();

to

this.connectionId = this.hostName + ":" + this.port + ":" + (System.currentTimeMillis() + connectionNumber.incrementAndGet());

Thoughts?

[spring-operator]

Oleg Zhurakousky commented

Well custom UUID generation is exposed. Its an undocumented feature that we probably have to document at some point.
Check this out: https://jira.springsource.org/browse/INT-1903

[spring-operator]

Gary Russell commented

Yes, I know the capability is there, but it is baked into MessageHeaders and not available externally to other classes.

OTOH, since TCP socket creation is much less frequent than message creation, maybe using UUID.randomUUID() is ok. But, if someone has configured a custom generator, they might expect it to be used everywhere.

[spring-operator]

Gary Russell commented

Mark,

After some offline discussion with Oleg, I think I am down to these choices; none are ideal...

1. Put a static getter on MessageHeaders to see if a custom generator is configured - don't like that because it makes MessageHeaders a factory for the uuid generator.
2. Use reflection to get the generator, if any - not keen on this one at all.
3. Make IdGenerator a first class citizen (instead of being inside MH) - a lot of work.
4. Use UUID.randomUUID() - TCP sockets are created much less frequently than messages, but someone may (perhaps rightly) expect their custom generator to be always used.
5. Create and discard a dummy message and use its UUID - I need to take a shower for even thinking of this one.

I don't think my earlier idea of using the system time is viable because apps might use a message store that's shared across instances (or even apps); it has to be a UUID.

#3 is probably the right solution but it's an extraordinary amount of work for something so simple.

Maybe #2, #4, or #5 for now, with a goal of moving to #3?

[spring-operator]

Oleg Zhurakousky commented

Just to add to what Gary and I have been discussing I am also (at least in interim) favoring #2. We do have some exceptional cases where the use of Reflection is the right approach especially if it is an internal detail.

[spring-operator]

Mark Fisher commented

I think the ways we've used reflection are very different though. Using reflection to replace a static assignment (if I understand correctly) is pretty crazy if you ask me :)

[spring-operator]

Mark Fisher commented

I want to give it some thought, but I am at least beginning to question the severity with which we restrict providing your own ID when creating a Message. It's good that we enforce uniqueness, but if it's clearly documented, then taking that responsibility into your own hands means you are assuming the risk. Maybe it's worth considering.

[spring-operator]

Oleg Zhurakousky commented

We are not replacing anything. Just getting it. Look at #1. Since we should not have a static getter I am saying we can use #2 and get the value of Id Generator

[spring-operator]

Oleg Zhurakousky commented

I agree with exposing it publicly if documented. So #3 is definitely the right option. Is it the right option for M2 given the time? That is why I prefer #2 now and since #3 will be addressed at some point it wil be a single line code change in Gary's code.
The bottom line is that now and then the user will always rely on the UUID generation strategy used by the framework.

[spring-operator]

Gary Russell commented

Just to clarify - I need to uniquely identify a connection, to use as a correlation id for messages generated from that connection, for possible downstream resequencing. The ID needs to be unique and so an UUID fits the bill. However, I would prefer the generation of the UUID to use a technique consistent with that used to generate a message id.

[spring-operator]

Mark Fisher commented

Sorry. It's clear now. I should have read more carefully before weighing in ;)

I would lean to #4 - at least as a first solution. I don't yet see why it's terribly important that the same strategy be used as for Messages. The main reason that has been exposed is for high-performance requirements where the randomUUID() overhead is unacceptable. Will that performance issue also apply for TCP Connections?... probably not in the most common cases (considering the reason for using CorrelationIDs based on that is only going to apply when Connections are being reused).

[spring-operator]

Gary Russell commented

I'll go with #4 then. I realize the driver for a custom generator was performance, and totally agree that that is not an issue here.

What I was (and to some extent still am) concerned about is, if someone provides their own generator, we'd end up getting a JIRA saying "why aren't you using my custom generator for all UUIDs?"

Maybe we just defer #3 until that happens :-)