Spring Integration
  1. Spring Integration
  2. INT-2822

Add 'requires-reply' attribute to gateways XSDs, e.g. <jdbc:outbound-gateway>

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Complete
    • Affects Version/s: 2.2 RC2
    • Fix Version/s: 3.0 M3
    • Component/s: None
    • Labels:

      Description

      I have some config:

      <channel id="inputChannel">
        <dispatcher load-balancer="none"/>
      </channel>
      
      <jdbc:outbound-gateway request-channel="inputChannel" data-source="dataSource" order="1">
            <jdbc:query>
      	SELECT *
      	FROM SOMETABLE
      	WHERE id = :payload
      	and arcDate >= trunc(:headers[REQUEST_DATE], 'MM')
            </jdbc:query>
      </jdbc:outbound-gateway>
      
      <jdbc:outbound-gateway request-channel="inputChannel" data-source="dataSource" order="2">
      	<jdbc:query>
      	   SELECT *
      	   FROM SOMETABLE
      	   WHERE id = :payload
      	   and arcDate >= add_months(trunc(:headers[REQUEST_DATE], 'MM'), -1)
      	   and arcDate &lt; trunc(:headers[REQUEST_DATE], 'MM')
      	</jdbc:query>
      </jdbc:outbound-gateway>
      

      So, I want to invoke second query if first one doesn't return anything.
      It is return null; from JdbcOutboundGateway. Further ARPMH doesn't do anything because his property is requiresReply = false;.
      But I was surprised that I can't reconfigure it via xml-attribute: it is absent.
      Was it done intentionally?
      There are a lot gateways who might not produce reply, but it may be interest to do some recovery.
      Right now only several components have 'requires-reply' attribute:
      <service-activator>, <enricher> & <splitter>.
      WDYT?

        Activity

        Hide
        Gary Russell added a comment -

        Yes, I think this is a valid request - so the gateway can throw an exception instead of just "eating" the null.

        I made a similar comment in post #4 here http://forum.springsource.org/showthread.php?131298-Durable-RPC-with-Spring-Integration-and-RabbitMQ

        Show
        Gary Russell added a comment - Yes, I think this is a valid request - so the gateway can throw an exception instead of just "eating" the null. I made a similar comment in post #4 here http://forum.springsource.org/showthread.php?131298-Durable-RPC-with-Spring-Integration-and-RabbitMQ
        Hide
        Artem Bilan added a comment -

        There is an workaround:

        <int:chain input-channel="request" output-channel="reply">
        	<bean class="org.springframework.integration.jdbc.JdbcOutboundGateway">
        	      <constructor-arg ref="dataSource"/>
                      <constructor-arg>
                  	<null/>
                      </constructor-arg>
                      <constructor-arg value="select * from bazz where id=:payload"/>
                      <property name="requiresReply" value="true"/>
        	</bean>
        </int:chain>
        

        It becomes not so critical. However it should be done in the nearest future.

        Show
        Artem Bilan added a comment - There is an workaround: <int:chain input-channel= "request" output-channel= "reply" > <bean class= "org.springframework.integration.jdbc.JdbcOutboundGateway" > <constructor-arg ref= "dataSource" /> <constructor-arg> <null/> </constructor-arg> <constructor-arg value= "select * from bazz where id=:payload" /> <property name= "requiresReply" value= "true" /> </bean> </int:chain> It becomes not so critical. However it should be done in the nearest future.
        Hide
        Gary Russell added a comment -

        This just came up in a question in the (internal) PSO chat - so elevating to M2.

        Show
        Gary Russell added a comment - This just came up in a question in the (internal) PSO chat - so elevating to M2.
        Hide
        Artem Bilan added a comment -

        Ok, will be done over weekends

        Show
        Artem Bilan added a comment - Ok, will be done over weekends
        Hide
        Gary Russell added a comment -

        Cool - FYI, the question was specifically the JMS ob gateway where there is a timeout and the gateway silently exits.

        I am thinking we should, perhaps, make this true by default, at least for the JMS and AMQP gateways? Maybe it's ok to do that in a major release?

        Show
        Gary Russell added a comment - Cool - FYI, the question was specifically the JMS ob gateway where there is a timeout and the gateway silently exits. I am thinking we should, perhaps, make this true by default, at least for the JMS and AMQP gateways? Maybe it's ok to do that in a major release?
        Hide
        Artem Bilan added a comment -

        IMO AbstractReplyProducingMessageHandler#requiresReply should be true by default: it comes from the name of the component.
        And that's why I said once, that one-way handlers e.g. <file:outbound-channel-adapter> should not implement AbstractReplyProducingMessageHandler by their nature.
        But it isn't a question to this issue...

        And, of course, if we name components as 'gateway' we assume, that there should be a reply.
        So, I see what I can do and you'll make comments on the PR.

        Show
        Artem Bilan added a comment - IMO AbstractReplyProducingMessageHandler#requiresReply should be true by default: it comes from the name of the component. And that's why I said once, that one-way handlers e.g. < file:outbound-channel-adapter > should not implement AbstractReplyProducingMessageHandler by their nature. But it isn't a question to this issue... And, of course, if we name components as 'gateway' we assume, that there should be a reply. So, I see what I can do and you'll make comments on the PR.
        Show
        Artem Bilan added a comment - PR: https://github.com/SpringSource/spring-integration/pull/768
        Hide
        Gary Russell added a comment -

        Merged

        Show
        Gary Russell added a comment - Merged

          People

          • Assignee:
            Artem Bilan
            Reporter:
            Artem Bilan
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: