INT-2839 Fix TCP Caching Connections with Gateways #686

Merged
merged 1 commit into from Nov 30, 2012

2 participants

@garyrussell
Spring member

Using the CachingClientConnectionFactory with a gateway
doesn't work. The Listener (gateway) was not being set up
properly by the wrapper. Instead, the actualListener in the
wrapped connection was set to null. This caused the connection
to "close" itself (return to the pool) immediately after the send.

In addition, even with the actualListener set up to properly
reference the gateway, it still wouldn't work because the
gateway can't correlate the reply (the cached connectionId is
prefixed with "cached:" so the gateway can't find the reply.

Further, when onMessage() returned, it caused the reader loop
to end.

Fixes:

  1. Properly set up the cached connection with the real listener so that ultimately the underlying connection sees there is an actualListener and so doesn't close itself after the send.
  2. Override getListener() on the cached connection to return the real listener.
  3. Override onMessage() in order to fix up the connection id in the message, and return true (intercepted) so the connection doesn't close itself (terminate the reader thread).
  4. close() (return to the pool) after invoking the gateway's onMessage().
  5. Add test cases to verify proper operation including an assertion that the pooled connection is reused.

This is made a little more complex by the tangle between
connections and connection interceptors; mainly because single-use
connections close themselves after use. This will be addressed in
3.0 (INT-2829) making connection interceptors simpler.

@garyrussell garyrussell INT-2839 Fix TCP Caching Connections with Gateways
Using the CachingClientConnectionFactory with a gateway
doesn't work. The Listener (gateway) was not being set up
properly by the wrapper. Instead, the actualListener in the
wrapped connection was set to null. This caused the connection
to "close" itself (return to the pool) immediately after the send.

In addition, even with the actualListener set up to properly
reference the gateway, it still wouldn't work because the
gateway can't correlate the reply (the cached connectionId is
prefixed with "cached:" so the gateway can't find the reply.

Further, when onMessage() returned, it caused the reader loop
to end.

Fixes:

1. Properly set up the cached connection with the real listener
so that ultimately the underlying connection sees there is an
actualListener and so doesn't close itself after the send.
2. Override getListener() on the cached connection to return the
real listener.
3. Override onMessage() in order to fix up the connection id in
the message, and return true (intercepted) so the connection doesn't
close itself (terminate the reader thread).
4. close() (return to the pool) after invoking the gateway's
onMessage().
5. Add test cases to verify proper operation including an assertion
that the pooled connection is reused.

This is made a little more complex by the tangle between
connections and connection interceptors; mainly because single-use
connections close themselves after use. This will be addressed in
3.0 (INT-2829) making connection interceptors simpler.
32251bf
@markfisher markfisher merged commit 32251bf into spring-projects:master Nov 30, 2012
@markfisher
Spring member

LGTM; merged

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment