Announcement Announcement Module
Collapse
No announcement yet.
AMQP Gateway without temporary queue Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • AMQP Gateway without temporary queue

    Is it possible to have an AMQP gateway without a temporary queue?

    I do have my own response queue, and I don't want to use temporary queues that might disappear after a restart of the requestor.

  • #2
    Do you mean temporary channel?
    Amqp gateway always works with the queue name you have specified.

    Comment


    • #3
      Yes, that's for the request, but it will generate a "distinct anonymous, exclusive, auto delete queue" for the response and pass it as amqp_replyTo.

      Comment


      • #4
        if you are talking about the reply queue. you can set the replyTo property in the message header using an header enricher. This way all reply messages will be sent back to the queue you have specified.
        example
        Code:
        <int:header-enricher  >
                    <int:header  name="amqp_replyTo" value="yourReplyQName"/>
         
        </int:header-enricher>

        Comment


        • #5
          That's not currently supported...

          Code:
          Assert.isNull(message.getMessageProperties().getReplyTo(),
          		"Send-and-receive methods can only be used if the Message does not already have a replyTo property.");

          Comment


          • #6
            Actually I tried that already, the Outbound Gateway will throw an Exception because message can't contain a replyTo.

            Comment


            • #7
              Gary Is there any kind of workaround?

              If I loose msg persistence (i.e. if a service get's restarted) everything will get a bit unsafe.

              Or perhaps if there is any kind of potential future implementation in the backlog I can just use it as it is, and eventually change it.

              Comment


              • #8
                Maybe you just want to use a pair of AMQP outbound/inbound Channel Adapters instead?

                The reason the outbound-gateway doesn't allow an existing replyTo header is that IT needs to be the one waiting for the reply.

                Does that make sense?
                -Mark
                Last edited by Mark Fisher; Jan 17th, 2012, 01:07 PM.

                Comment


                • #9
                  A pair of AMQP outbound/inbound gateways? Do you mean channel adaptor?

                  If I want a composed message processor orchestrating my flow I need a method to

                  Having INFOA, INFOB in a message

                  1 receive INFOA and INFOB in a message
                  2 send to service a INFOA then wait for response
                  3 send to service b INFOB
                  4 compose a response and send it back

                  If I use channel adaptors I'm forced to send INFOA and INFOB to servicea (probably INFOB as a header) that that service might not be written by me, and might not return the received headers.

                  I understand this is a complex matter. One possible solution is to have something similar to a common message store, and whenever a message arrives to a gateway, it can know if that gateway or any other waits for it, similar to what a message agregator does. But that's obviously complex and not a matter of a few hours.

                  Other solution is to let the user to send the replyTo ( I actually don't see why I not permited to pass it, except because it can puzzle users if they reuse a message received by another gateway that already have replyTo) and let upon him to handle the problem using unique identifiers for instances and jms/amqp selective filters.

                  Comment


                  • #10
                    Yes, I meant Channel Adapters, sorry; I just edited the above post to correct that.

                    So... what you're describing is similar to what we do for the JMS outbound-gateway where you *can* provide a reference to any replyTo Destination (or rely on a TemporaryQueue being generated by default). The thing is... in the JMS case, we are able to use a MessageSelector based on the CorrelationID. We would need a similar mechanism - otherwise the gateway cannot correlate a reply it receives from the same Queue to the proper blocking request.

                    Comment

                    Working...
                    X