-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Cannot applied correctly TcpConnectorInterceptor on sending with server connection #8609
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I've added the repro project. |
I'm not sure what does difference your patch do?
Where the mentioned
So, we still deal with those |
Processing flow without patch (Spring Integration default behavior)
Processing flow with applying patch interceptor
|
At lease, I think should be passed a last interceptor instance(in sample: |
Probably patch code of @Override public void addNewConnection(TcpConnection connection) {
super.addNewConnection(connection);
// Call addNewConnection of TcpSender with wrapped connection(interceptor)
Optional.ofNullable(getSender()).ifPresent(x -> x.addNewConnection(getTheConnection()));
} ↓ @Override public void addNewConnection(TcpConnection connection) {
// Call addNewConnection of TcpSender with wrapped connection(interceptor)
getSenders().forEach(x -> x.addNewConnection(getTheConnection()));
} Processing flow with applying new patch interceptor
|
Call the |
Right. I see now. Thanks. @garyrussell , any thoughts? |
Clearly looks like a bug. @kazuki43zoo are you planning to submit a PR? If so, thanks. |
OK. Just debugged
Which points only to one interceptor. With the fix for that
Confirming that connection is wrapped twice. Just because we have With the fix we have a failing other test though:
Perhaps the one just reflecting the current wrong behavior. |
I wonder why |
The result of failing test is this:
Which, I think, indicates that target |
Doesn't look like that |
I see - if the send is not called (because it's skipped), the negotiation error won't happen. |
When I fix it like this:
All good:
|
@artembilan @garyrussell |
…ectorInterceptor Fixes spring-projects#8609 * add getLastWrapper() in TcpConnectionSupport * change to passed the instance that geted via getLastWrapper() instead of self instance to TcpSender#addNewConnection
@artembilan @garyrussell |
…ectorInterceptor Fixes spring-projects#8609 * Changed to passed the self instance to addNewConnection instead of argument's connection
Fixes #8609 * Changed to passed the self instance to `addNewConnection()` instead of argument's connection in a `TcpConnectionInterceptorSupport` to compose a chain of interceptors from top to down. This way the target `Sender` get the last interceptor in a chain as its connection. **Cherry-pick to `6.0.x` & `5.5.x`**
Fixes #8609 * Changed to passed the self instance to `addNewConnection()` instead of argument's connection in a `TcpConnectionInterceptorSupport` to compose a chain of interceptors from top to down. This way the target `Sender` get the last interceptor in a chain as its connection. **Cherry-pick to `6.0.x` & `5.5.x`**
Fixes #8609 * Changed to passed the self instance to `addNewConnection()` instead of argument's connection in a `TcpConnectionInterceptorSupport` to compose a chain of interceptors from top to down. This way the target `Sender` get the last interceptor in a chain as its connection. **Cherry-pick to `6.0.x` & `5.5.x`**
In what version(s) of Spring Integration are you seeing this issue?
5.5.17 (Probably 6.0.x line too)
Describe the bug
If define multiple
TcpConnectionInterceptor
, cannot applied correctlyTcpConnectorInterceptor
on sending a message with server connection. As actual result, it has been applied only the first interceptor(interceptor that wrapped the realTcpConnection
). Probably c1aa9b7 's changed are affect this behavior.To Reproduce
For example, When following beans are defined,
characterAppendingInterceptor1
has been applied butcharacterAppendingInterceptor2
has not been applied on sending a message. As a side note, When receive a message, all interceptors are applied.Expected behavior
We expected all interceptors are applied on sending a message. As workaround, I add the following
TcpConnectorInterceptor
, it work fine as expected behavior.Sample
Just wait a few time!! I will add the repro project in My GitHub repository at after.
How to reproduce:
Please run the
SpiGh8609ApplicationTests#connectAndReceive
.FYI:
SpiGh8609ApplicationWithPatchTests
: Tests for applying workaround patch interceptorSpiGh8609ApplicationWithoutInterceptorTests
: Tests for no interceptorsThe text was updated successfully, but these errors were encountered: