Announcement Announcement Module
No announcement yet.
AbstractGateway receive and send receive timeout misconception Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • AbstractGateway receive and send receive timeout misconception

    If gateway receive or sendAndReceive method aborts cause of receive timeout then we have null as result. I quess we have ambiguity in such case. Method returns null value as payload or null because timeout expired. Maybe exception is more natural way in the case of timeout? For example:

    public abstract class AbstractMessagingGateway extends AbstractEndpoint implements MessagingGateway {
    ... ... ...
        public Object sendAndReceive(Object object) {
            return this.sendAndReceive(object, true);
        private Object sendAndReceive(Object object, boolean shouldMapMessage) {
            Message<?> request = this.toMessage(object);
            Message<?> reply = this.sendAndReceiveMessage(request);        
            if (!shouldMapMessage) {
                return reply;
            if (reply == null){
               throw new MessagingException("Reply timeout expired");   
            return this.fromMessage(reply);
    ... ... ...
    Last edited by ajones; Jun 19th, 2009, 01:13 PM.

  • #2
    We don't support null as a payload. On one hand it seems wasteful to send a message with a null in it, on the other hand this complicates things a bit when mapping request-reply to a method invocation.

    In this case however, it means that the ambiguity you speak of doesn't exist. Or did I miss something?


    • #3
      I guess what is happening is the method that ultimately handles the Message may return an Object in some cases and null in others?

      In the cases where that method returns null, from the Spring Integration perspective, the message flow would end. Therefore, no message is sent to the consuming endpoint's output channel, and the receive call on that channel will eventually timeout.

      Does that describe your situation?


      • #4
        I was making resource adapter for our middleware application that conforms to JCA 1.0. I have decided to create an convenient messaging abstraction layer before implement adapter.

        public inteface ConnectionFactory {
          Connection createConnection() throws IntegrationException;
        //Simplified connection to messaging system that have own reply channel
        // and default outbound channel.
        public interface Connection {
           //Can be used for sending an event object in publish/subcribe channel or queue
           void send(Object obj) throws MessageException;
           Object sendAndReceive(Object obj) throws Exception;
        Thereby, I have messaging semantics but don`t have explicit messages. Also I have abstraction from concrete messaging system. From this point of view returning null from sendAndReceive is simply null, not more. And exception is exception including timeout and other not good things.

        I agree with Iwein that using null object as payload not good idea but this can happen in other concrete messaging system not Spring Integration. If we take a look at the MessagingGateway interface it has mixed semantics:
        public interface MessagingGateway {
        	void send(Object object);
        	Object receive();
        	Object sendAndReceive(Object object);
        	Message<?> sendAndReceiveMessage(Object object);
        It is common practice not using a null object for a message. So returning null from sendAndReceiveMessage is common in the case of timeout for example. But returning a null from sendAndReceive seems a bit strange if we don`t know such architectural constraint as not using a null payload object of course. This was the reason of my ambiguity thoughts
        Last edited by ajones; Jun 22nd, 2009, 06:36 AM.