Announcement Announcement Module
Collapse
No announcement yet.
JMS Inbound Gateway (RC1) -- bug or config problem? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • JMS Inbound Gateway (RC1) -- bug or config problem?

    In RC1, I'm using the JMS inbound gateway to get messages from a JMS queue and place them onto a channel:

    <jms:inbound-gateway request-channel="eebChannel" connection-factory="connectionFactory" destination="p1"/>

    However, after receiving a message it blocks waiting for a reply, even though I don't have a reply-channel set. The desired behavior would be for it to receive the message from the JMS queue (p1) and place it onto the eebChannel and not wait for a reply.

    Is this a configuration problem on my part or a bug?

    I noticed in the JmsInboundGateway code, it does the following inside the message listener onMessage() method:

    Message<?> replyMessage = JmsInboundGateway.this.sendAndReceiveMessage(objec t);

    Shouldn't it do:

    JmsInboundGateway.this.send(object);

    if there is no reply-channel specified?

    In the M6 release, the JmsGateway apparently did either a 'send' or a 'sendAndReceive' depending on whether a reply was expected:

    listener.setDefaultListenerMethod(this.expectReply ? "sendAndReceive" : "send");

    But obviously I don't know the code well enough to say for sure...

  • #2
    Additional info.

    I should add that I'm attempting to use the jms:inbound-gateway since I want a message-driven listener, not a polling listener, on the inbound JMS queue.

    Is this appropriate? Is there a better way to do this without using the jms:inbound-gateway or the jms:inbound-channel-adapter since it polls?

    Comment


    • #3
      This is the main question for sure. We need to provide one or the other - a "one-way" option for inbound gateway or an "event-driven" option for inbound-channel-adapter".

      I am leaning toward an event-driven inbound-channel-adapter, b/c the distinction we are trying to make between "channel-adapter" and "gateway" is that the former is one-way and the latter is for request/reply.

      This would also be consistent with the inbound Mail support where we have a polling "inbound-channel-adapter" but also an "imap-idle-channel-adapter" that is event-driven.

      What do you think?

      Comment


      • #4
        Options

        I agree with you. An event-driven jms:inbound-channel-adapter seems like the right thing to do, and it would preserve the semantic difference you want to maintain between the channel-adapter and gateway.

        Do you think this is something that can be provided in the 1.0 release?

        Comment


        • #5
          Yes, I think we should include this in 1.0 if at all possible. Would you mind opening an issue in JIRA?

          Comment


          • #6
            Sure, I'll do that shortly.

            Comment


            • #7
              I've added this to JIRA: INT-477

              (URL not included since I'm a newbie ).

              Comment


              • #8
                Thank you.

                For others who are interested in watching this issue, here is the link:
                http://jira.springframework.org/browse/INT-477

                Comment


                • #9
                  Added a vote in Jira, i have the exact same use-case.

                  Comment


                  • #10
                    Similar use case

                    I have a similar use case, but jms:inbound-gateway is unsuitable for even more reasons:

                    * I am connecting to a pubsub instead of a queue, I don't see a way to configure the inbound gateway using the xml tag for connecting to pubsubs.

                    * I have some advanced options that I need to specify in DefaultMessageListenerContainer, specifically, I need to specify cacheLevel, exceptionListener, recoveryInterval, subscriptionDurable, pubSubDomain

                    * I have my own class derived from DefaultMessageListenerContainer that I use to override some behavior.

                    I think a simple solution would be to allow me to specify the MessageListenerContainer that I want to use.

                    So my request is, if you are going to add the capability to jms:inbound-channel-adapter to do event-driven messaging, go all the way and allow me to specify the MessageListenerContainer, for both jms:inbound-channel-adapter and jms:inbound-gateway

                    I opened INT-482 for this (can not post url ).

                    Comment


                    • #11
                      The URL is: http://jira.springframework.org/browse/INT-482

                      As far as the pubsub configuration, the 'request-destination' can be any JMS Destination reference (Queue or Topic). Have you tried setting that for a Topic?

                      Comment


                      • #12
                        To the best of my knowledge, and by looking at the code, it will only try to resolve Topics if isPubSubDomain is set.

                        so I am not sure what to put in request-destination to make it look for a topic without specifying isPubSubDomain.

                        But even if I do, I still need to make it a durable subscription and use some of the other advanced parameters in DefaultMessageListenerContainer.

                        Comment


                        • #13
                          If you are providing a Destination reference, it does not need the 'pubSubDomain' value. That is only necessary when it is resolving a destination-name.

                          However, it is true that we need to enable setting that boolean value alongside destination-name to ensure that Topics can be used when resolving by name.

                          Comment


                          • #14
                            My destinations are by name, I do not have Destination objects set up in JNDI, so I am relying on DynamicDestinationResolver.

                            Comment


                            • #15
                              OK. I will be sure to include the addition of 'pub-sub-channel' when tackling the issue. Out of curiosity, what JMS provider are you using?

                              Comment

                              Working...
                              X