[#MULE-3648] Nested router should check for null response (caused when async back channel times out) and throw an exception rather than return null

Mule

Nested router should check for null response (caused when async back channel times out) and throw an exception rather than return null

Created: 01/Sep/08 01:16 AM Updated: 19/Nov/08 06:00 AM

Component/s:

Core: Routing / Filters, Transport: JMS

Affects Version/s:

2.0.2

Fix Version/s:

2.1.x Backlog

Time Tracking:

Not Specified

Environment:

Linux (Ubuntu 8.04), Sun Java 1.6, ActiveMQ 4.1

Labels:
User impact:	Medium

Description

« Hide

I've configured a nested router to communicate via JMS. In case a timeout occurs, the JMS transport returns a null value as a reply (the message itself is null, not the payload). This is given back by the NestedInvocationHandler to the caller. I would expect that NIH instead would throw a runtime exception, instead of forcing my application code to check for null pointers and throwing the exception myself.

All

Comments

Work Log

Change History

Transitions

FishEye

Sort Order:

[ Permlink | « Hide ]

Andrew Perepelytsya added a comment - 04/Sep/08 05:43 PM

Please provide a config to better understand if it's an issue

[ Permlink | « Hide ]

Jeroen Benckhuijsen added a comment - 05/Sep/08 03:44 AM

Situation: I'm using a nested router to communicate between services. Suppose one of these services can return null (arguably a bad design). From the perspective of the caller, there is no way to discern between the service actually returning null and not being able to communicate with the service. Returning null may be a valid use case scenario where lack of communication should result in a technical exception which should be handled by e.g. maintenance personnel.

Anyway, the current situation places the responsibility to check whether services are off-line or not inside business code, whereas it should be transparent to the code whether the service is remote or not.