Support for null payloads. [INT-997]

[spring-operator]

Oyvind Kvien opened INT-997 and commented

Spring Integration should support null payloads.

A common case is when using legacy services in a service-activator. The service might return null, and I don't want to refactor it as it's been running stable for years. If Spring Integration don't support null payloads I'll be forced the create a wrapper around it to control it's return type, which is poor design.

Another common case is when using an XmlPayloadUnmarshallingTransformer, like this:
<si-xml:unmarshalling-transformer input-channel="freeTextSearchResponseChannel" unmarshaller="freeTextSearchUnmarshaller"/>

It receives XML from channel "freeTextSearchResponseChannel" and unmarshals it. If the XML is invalid the transformer will return null based on which unmarsller you pick. This will cause the message payload to be null.

---

Affects: 1.0.3

Reference URL: http://forum.springsource.org/showthread.php?t=85345

Issue Links:

• Add support for null return values in gateway/service-activator methods [INT-2222] #6203 Add support for null return values in gateway/service-activator methods

8 votes, 7 watchers

[spring-operator]

Mark Fisher commented

This issue is a bit tricky, because in Spring Integration, we are intentionally treating NULL as a "short circuit" within a pipeline. For example, when a Filter does not accept a Message, the adapting handler implementation returns null to signify that the processing should not continue.

I understand your case, and I agree that we need to support this in some way. I would like to know what you would expect to happen when a service does return null. Would you expect it to continue through the pipeline? Or, would you expect it to immediately reply with a null-payload Message to the "replyChannel" as configured on the Message?

Each of the above options presents a challenge. For the first option, one would need to make sure that any service is handling potential null values, whereas now that is avoided at the framework level. For the second option, it might be too early to send a reply in some cases, e.g. a splitter->[service-activators]->aggregator where a null return occurs in one of the intermediate services (should wait until the aggregator replies).

[spring-operator]

Oyvind Kvien commented

I'd expect it to continue through the pipeline. This will give you the opportunity for further processing of the message even though the payload is null.

[spring-operator]

Oleg Zhurakousky commented

I think the 'null' behavior that we currently have in SI should remain untouched for one simple reason; A 'null' in itself is a cause of many issues (e.g., NPE etc...) and relying on it is not reliable ;)
One of the options we might consider is creating a NullPayload object as the way to signal that this message doe not have a payload, but it is also not an accident.

[spring-operator]

Oyvind Kvien commented

Yeah a NullPayload object like in i.e. Mule would be satisfactory.

[spring-operator]

Mark Fisher commented

The main question is how should we expect downstream components to handle this payload? In some cases, you might still want to do something (e.g. reading or writing headers), but it seems like in most cases, the various handlers would not know how to deal with the payload.

Rather than starting from an implementation detail (like handling null as a payload), can we step back and talk about the use-case scenario a bit?

[spring-operator]

Oleg Zhurakousky commented

Mark this came up several times in the forums and few engagements.
For example:

Gateway:

public void initiateEvent(@Header("eventType") String event)

In this case the Message won't have any payload, but it is anything but empty, and has plenty of valuable information.

1. method name available with Message History
2. custom header (eventType)
   etc...

The goal is to use the method invocation as an event and the way to initiate an integration flow.
So in a way it is a perfectly valid message.

[spring-operator]

Mark Fisher commented

I see, but in the "traditional" event model an Event object would contain minimally the "source". Therefore, when translating that model to messaging, I would say that an EventMessage should have a source as its payload.

By that token, if a Service accepts a DocumentMessage but returns null, the response message could be an EventMessage.

Perhaps, I'm just overreacting, but "NullPayload" has always seemed like a hack to me. I think a cleaner solution is possible... just not yet sure what it is ;) So, please continue with the use-case samples.

[spring-operator]

Oyvind Kvien commented

Just a little update about how we decided to solve the null payload issue in my current project.

The initial problem was that the executing thread would hang when a null payload was returned from a <service-activator>. It's a very serious problem that could easily bring down the server.

ServiceActivatingHandler has a requiresReply property that can make the handler throw a MessageHandlingException if the service returns null. The default of this property is false, and it is unfortunately not exposed in the Spring Integration namespace support (<service-activator>). It would be really easy to write an extended namespace (myapp:service-activator) where this property is true by default. If all usages are then switched from <service-activator> to myapp:service-activator we would then ensure that the problem with the hanging threads resulting from a null payload would never occur. It's also very easy to extend the namespace with custom handling. In my project we typically want to throw an EntityNotFoundException.

Another solution we thought about was configuring a channel on a global scope where all messages with a null payload should be sent to. But then again we would need some kind of component to somehow interprit the message for further processing.

Just food for thought.

[spring-operator]

Mark Fisher commented

Good news! We have already added the "requires-reply" attribute to the <service-activator> element in 2.0 (see #5381).

I've also created an issue to address that for 1.0.5: #5388

The behavior is such that requires-reply=TRUE will trigger a MessageHandlingException will be thrown when the underlying service method returns null. The default value is still FALSE.

@Oyvind: In your opinion, does this new configuration option supersede the current JIRA issue? I am inclined to resolve this accordingly.

Thanks for the feedback,
Mark

[spring-operator]

Oyvind Kvien commented

Well, yes the requires-reply attribute does solve the initial problem. But just throwing a MessageHandlingException provides little flexibility to give any kind of meaning to why the payload is null. At least in my project when a <service-activator> returns null I usually want to throw a given exception to be caught at a higher level.

What would be nice is the possibility to also configure a reference to a optional handler that's invoked when payload is null.

I.e: <service-activator null-handler-ref="myNullHandler"/>

It would at least solve my problems pretty nicely.

[spring-operator]

Mark Fisher commented

I have thought about this as well.

The first thing I'd like to ask is why you can't create a simple wrapper object that invokes the real target service and handles Exception-throwing/wrapping or better yet apply an AOP proxy with after/after-throwing advice?

Secondly, what is upstream from the <service-activator>? If you have a <gateway> upstream, we do support an "exception-mapper" now.

[spring-operator]

Oyvind Kvien commented

We did use wrapper objects to begin with, but decided to go for a more generic solution with an extended namespace as mentioned above.

The problem isn't how to get around the null payload issue. I guess the main problem is, as #5381 says, the gateway method will hang until it times out when the ServiceActivator returns a null payload downstream from a gateway. This is very dangerous behaviour and as far as I know not documented. Isn't that a really bug?

I guess what I'm trying to say is that unless this behaviour is changed, the ServiceActivator need to explicitly document or handle this in some good/generic way.

[spring-operator]

Christian Nedregård commented

Hi.

I work with Øyvind.

We are seeing similar behaviour also when using splitter/aggregator on a direct channel. If the original payload is an empty list the current thread will be hanging forever.

This behaviour is unexpected and, as mentioned above, dangerous. It can take down a server in seconds if it receives many requests that generates this type of payload.

It seems unsatisfactory to solve this by adding special configuration to specific endpoints. Its easy to forget and the issue could be re-introduced with new endpoints in the future.

Is there a global way I can configure my channels so that they will never hang on a null payload?

Regards
Christian

[spring-operator]

Mark Fisher commented

Christian, What is the entry point to your message flow?, and are you using 2.0 now? The best way to avoid this through a single configuration is to set the timeout on the entry point.

[spring-operator]

Christian Nedregård commented

Thanks for your quick reply Mark :)

We are upgrading to 2.0 early next year.

All our entry points are through GatewayProxyFactoryBean via a specialized gateway namespace handler.
We'll set a default timeout there then. Thanks for the tip.

This will prevent threads from hanging forever. Some of our channels will require a quite large timeout though (e.g. 200 seconds) so they will still make the whole servert vulnerable for thread starvation.

IMHO the timeout is still just a temporary fix though. Are hanging threads really the expected and acceptable behavior of a channel that receives a null payload from an endpoint? I realize that our usage of SI might be more serial than the regular users, but still.. this does not make sense to me.

Is this issue still under consideration?

Thanks again

Chr