Results 1 to 10 of 10

Thread: AMQP Gateway without temporary queue

  1. #1

    Question 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. #2

    Default

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

  3. #3

    Default

    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.

  4. #4

    Default

    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>

  5. #5
    Join Date
    Mar 2010
    Location
    Gtr Philadelphia, PA
    Posts
    2,036

    Default

    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.");
    Gary P. Russell
    Spring Integration Team
    SpringSource, a division of VMware

  6. #6

    Default

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

  7. #7

    Default

    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.

  8. #8
    Join Date
    Oct 2005
    Location
    Boston, MA
    Posts
    2,840

    Default

    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 at 01:07 PM.

  9. #9

    Default

    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.

  10. #10
    Join Date
    Oct 2005
    Location
    Boston, MA
    Posts
    2,840

    Default

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •