Provide support for a NULL_CHANNEL header or null-handler on endpoints [INT-1180]

[spring-operator]

Mark Fisher opened INT-1180 and commented

When using a Gateway, any downstream endpoint might simply end the flow without any reply Message. For example a POJO-invoking Service Activator might call a method whose return value is NULL. Normally that would cause a gateway to hang until it times out. Perhaps we can provide something like 'null-handler' on endpoints where a null return value is foreseeable. Or perhaps, we should add a NULL_CHANNEL header in addition to REPLY_CHANNEL and ERROR_CHANNEL. Considering we define a default "nullChannel" that acts like /dev/null, that seems like a fairly consistent solution with our approach to "errorChannel".

---

Affects: 2.0 M4

Issue Links:

• Allow Gateway to return information about the message status [INT-943] #4959 Allow Gateway to return information about the message status

• Consider refactoring reply producers to use a global, reply-forwarding "proxy" channel [INT-918] #4925 Consider refactoring reply producers to use a global, reply-forwarding "proxy" channel

• Transformers should require a reply by default [INT-1385] #5382 Transformers should require a reply by default

• expose the "requires-reply" attribute for service-activator elements [INT-1384] #5381 expose the "requires-reply" attribute for service-activator elements
  ("is superseded by")

• Transformers should require a reply by default [INT-1385] #5382 Transformers should require a reply by default
  ("is superseded by")

[spring-operator]

Mark Fisher commented

might be worth considering this global channel (#4925) for handling replies, errors, and nulls

[spring-operator]

Mark Fisher commented

My current thinking on this issue is that we do not need to add support for a "nullChannel" message header. Instead, we can do three things:

1. add namespace support for the 'requires-reply' property on endpoints that may return NULL values (e.g. service-activator)
2. consider it an error (or at least have requiresReply=TRUE by default) for Transformers to return NULL (contract being that a Transformer must transform a source Message into a target Message)
3. add support for a MessageHeader "requiresReply" that can always be set to TRUE in the Gateway before it sends a request

Option #3 in particular would ensure that either a reply is returned or an Exception is thrown from the Gateway. The 'exceptionMapper' strategy on a Gateway enables translation of those Exceptions into a Message if that is the preferred approach.

NOTE: Filter elements already support the 'throw-exception-on-rejection' attribute, and Router elements support the 'resolution-required' attribute, so with the additions above it should be possible to create downstream flows for a Gateway that will always respond either with a reply Message or an Exception.

[spring-operator]

Mark Fisher commented

#5381 handles #1 above (adding "requires-reply" to <service-activator>).

The header value (#3 above) seems to cause more trouble than it's worth.

[spring-operator]

Mark Fisher commented

Instead of adding a null channel header, this issue has been addressed by alternative means. Most importantly, #5381 enables a <service-activator> to have a "requires-reply" value of TRUE (even though the default is still FALSE... allowing NULL returns). Also, Transformers now require a reply by default (see #5382), since the primary purpose there is to transform Message X into Message Y.

[spring-operator]

Mark Fisher commented

Changing from "invalid" to "won't fix". This issue has been addressed by other superseding issues as described in the previous comment.