Skip to content

Enhance the TcpOutboundGateway to send late replies and other unsolicited messages to a message channel #3326

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.

Sign up for GitHub

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

Jump to bottom
Closed
bakihyt opened this issue Jul 4, 2020 · 1 comment · Fixed by #3327
Closed

Enhance the TcpOutboundGateway to send late replies and other unsolicited messages to a message channel #3326

bakihyt opened this issue Jul 4, 2020 · 1 comment · Fixed by #3327
Assignees
@garyrussell
Labels
type: enhancement
Milestone
5.4 M2

Comments

@bakihyt
Copy link

bakihyt commented Jul 4, 2020 •
edited
Loading

Expected Behavior

I need capability for TcpOutboundGateway to support also single way communication that comes from tcp server without any request from client.

Current Behavior

If i am correct according to my experience on TcpOutboundGateway, it is working two direction that is request/response but also in some use cases server should send to client periodical arbitrary data but without any request if server sends data to client, client generates error like "ERROR 54816 --- [pool-2-thread-1] o.s.i.ip.tcp.TcpOutboundGateway : Cannot correlate response - no pending reply for ::58628:62fd67b6-af2d-42f1-9c4d-d232fbe9c8ca".

If this capability is supported by TcpOutboundGateway than it will not generate any Error then server can send data to connected client so both "request/response" type of communication and "only push message" from server type of communication can be supported.

Context

How has this issue affected you?

I could not receive push (arbitrary) messages from server with using TcpOutboundGateway and this issue forced me to use adapters but message correlation in adapters is complicated if tcp server is not allowed to support such an extension. In my case tcp server was already written and is a a black box product. When i try adapters, I lost req/resp capability because as i understand adapters working asynchronous.

What are you trying to accomplish?

I tried to accomplished that both i have to use req/resp type of communication between client and server but also incase of any push message comes from server, that client should receive it.

What other alternatives have you considered?

To be honest, i did not have other alternative but i am totally open to hear other alternatives.

Are you aware of any workarounds?

@garyrussell supported me to extend TcpOutboundGateway to inject message channel for receive push messages from server and also he supported me to use adapters but also he mentioned that message correlation is complicated if tcp server is intelligent.

Here some links about this topic

https://stackoverflow.com/questions/62702192/spring-integration-gateway-vs-adapters
https://stackoverflow.com/questions/46021319/how-to-extend-tcp-outbound-gateway-to-just-receive-messages-in-spring-integratio?rq=1
https://stackoverflow.com/questions/33902543/spring-integration-tcp-server-push-to-client
@bakihyt bakihyt added status: waiting-for-triage The issue need to be evaluated and its future decided type: enhancement labels Jul 4, 2020
@garyrussell garyrussell changed the title TcpOutboundGateway should support one way messages (from Server to Client with out any request from Client) Enhance the TcpOutboundGateway to send late replies and other unsolicited messages to a message channel Jul 5, 2020
@garyrussell garyrussell self-assigned this Jul 5, 2020
@garyrussell garyrussell removed the status: waiting-for-triage The issue need to be evaluated and its future decided label Jul 5, 2020
@garyrussell garyrussell added this to the 5.4 M2 milestone Jul 5, 2020
garyrussell added a commit to garyrussell/spring-integration that referenced this issue Jul 6, 2020
@garyrussell
spring-projectsGH-3326: TCP: Support Unsolicited Server Messages
4581724 
Resolves spring-projects#3326

- OB Gateway - send unsolicited messages and late replies to a channel
- Support multiple `TcpSender`s
garyrussell added a commit to garyrussell/spring-integration that referenced this issue Jul 6, 2020
@garyrussell
spring-projectsGH-3326: TCP: Support Unsolicited Server Messages
6ee4e03 
Resolves spring-projects#3326

- OB Gateway - send unsolicited messages and late replies to a channel
- Support multiple `TcpSender`s
garyrussell added a commit to garyrussell/spring-integration that referenced this issue Jul 6, 2020
@garyrussell
spring-projectsGH-3326: TCP: Support Unsolicited Server Messages
8050658 
Resolves spring-projects#3326

- OB Gateway - send unsolicited messages and late replies to a channel
- Support multiple `TcpSender`s
@garyrussell garyrussell mentioned this issue Jul 6, 2020
Merged
artembilan pushed a commit that referenced this issue Jul 6, 2020
@garyrussell
GH-3326: TCP: Support Unsolicited Server Messages
e919428 
Resolves #3326

- OB Gateway - send unsolicited messages and late replies to a channel
- Support multiple `TcpSender` s

* Add channel variant to spec; code polishing
@bakihyt
Copy link
Author

bakihyt commented Jul 7, 2020

i removed on of the old question link from feature request body.

garyrussell added a commit to garyrussell/spring-integration that referenced this issue Feb 1, 2022
@garyrussell
spring-projectsGH-3713: TCP: Fix Intercepted Sender List
abda16b 
Resolves spring-projects#3713

spring-projects#3326 added support
for multiple `TcpSenders`. However, when connections are intercepted, the sender
list was not properly chained through the interceptors.

- override `registerSenders` and properly capture the real senders in the last
  interceptor and intermediate interceptors
- this ensures that `addNewConnection` is called on each interceptor
- when removing dead connections, use the (possibly intercepted) connection sender
  list insted of the factory's raw sender list.

**cherry-pick to 5.5.x**
@garyrussell garyrussell mentioned this issue Feb 1, 2022
Merged
garyrussell added a commit to garyrussell/spring-integration that referenced this issue Feb 2, 2022
@garyrussell
spring-projectsGH-3713: TCP: Fix Intercepted Sender List
50153f8 
Resolves spring-projects#3713

spring-projects#3326 added support
for multiple `TcpSenders`. However, when connections are intercepted, the sender
list was not properly chained through the interceptors.

- override `registerSenders` and properly capture the real senders in the last
  interceptor and intermediate interceptors
- this ensures that `addNewConnection` is called on each interceptor
- when removing dead connections, use the connection sender list insted of the
  factory's raw sender list; detect if the connection is an interceptor and
  call its remove method instead.

**cherry-pick to 5.5.x**
artembilan pushed a commit that referenced this issue Feb 2, 2022
@garyrussell @artembilan
GH-3713: TCP: Fix Intercepted Sender List
a493c9c 
Resolves #3713

#3326 added support
for multiple `TcpSenders`. However, when connections are intercepted, the sender
list was not properly chained through the interceptors.

- override `registerSenders` and properly capture the real senders in the last
  interceptor and intermediate interceptors
- this ensures that `addNewConnection` is called on each interceptor
- when removing dead connections, use the connection sender list insted of the
  factory's raw sender list; detect if the connection is an interceptor and
  call its remove method instead.

**cherry-pick to 5.5.x**
artembilan pushed a commit that referenced this issue Feb 2, 2022
@garyrussell @artembilan
GH-3713: TCP: Fix Intercepted Sender List
c1aa9b7 
Resolves #3713

#3326 added support
for multiple `TcpSenders`. However, when connections are intercepted, the sender
list was not properly chained through the interceptors.

- override `registerSenders` and properly capture the real senders in the last
  interceptor and intermediate interceptors
- this ensures that `addNewConnection` is called on each interceptor
- when removing dead connections, use the connection sender list insted of the
  factory's raw sender list; detect if the connection is an interceptor and
  call its remove method instead.

**cherry-pick to 5.5.x**
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@garyrussell garyrussell

Labels
type: enhancement
Projects
None yet
Milestone
5.4 M2
Development

Successfully merging a pull request may close this issue.

GH-3326: TCP: Support Unsolicited Server Messages garyrussell/spring-integration
2 participants
@garyrussell @bakihyt