Spring AMQP
  1. Spring AMQP
  2. AMQP-60

Add namespace support for defining Exchanges, Queues and Bindings

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Complete
    • Affects Version/s: None
    • Fix Version/s: 1.0.0.M3
    • Component/s: Core
    • Labels:
      None

      Description

      In the simplest case we could have separate elements all at top-level, including <binding>:

      <direct-exchange name="e" .../>
      
      <queue name="q" .../>
      
      <binding from="e" to="q" with="foo"/>
      

      However, it might be clearer to provide a hierarchical model where bindings are more implicit. One advantage of this approach would be the ability to have different semantics for different top-level exchange types (e.g. no routing-key for FanoutExchanges, key/value matching for HeaderExchanges, etc.)

      <direct-exchange name="e">
          <bindings routing-key="foo">
              <queue name="q"/>
          </bindings>
      </direct-exchange>
      

        Activity

        Hide
        Dave Syer added a comment -

        I like the hierarchical model. Are there any corner cases for normal exchange types? (I can't think of any.)

        Show
        Dave Syer added a comment - I like the hierarchical model. Are there any corner cases for normal exchange types? (I can't think of any.)
        Hide
        Andrey Paramonov added a comment -

        How do you bind a queue to two exchanges in hierarchical model?

        Show
        Andrey Paramonov added a comment - How do you bind a queue to two exchanges in hierarchical model?
        Hide
        Mark Fisher added a comment -

        That's a good question. Since Queue declaration is an idempotent operation, it should be possible to have duplicate Queue element entries. However, it would be nice to avoid duplication as well. I think we would most likely want to provide a "ref" option to avoid that.

        Show
        Mark Fisher added a comment - That's a good question. Since Queue declaration is an idempotent operation, it should be possible to have duplicate Queue element entries. However, it would be nice to avoid duplication as well. I think we would most likely want to provide a "ref" option to avoid that.
        Hide
        Dave Syer added a comment -

        Since a Queue is not associated with an Exchange except by the binding, and you can also bind more than one routing key to a single queue in the same exchange, maybe it is better if <exchange/> contains <binding/> elements, but no <queue/> elements:

        <queue name="q"/>
        <direct-exchange name="e">
            <binding routing-key="foo" queue="q"/>
        </direct-exchange>
        
        Show
        Dave Syer added a comment - Since a Queue is not associated with an Exchange except by the binding, and you can also bind more than one routing key to a single queue in the same exchange, maybe it is better if <exchange/> contains <binding/> elements, but no <queue/> elements: <queue name= "q" /> <direct-exchange name= "e" > <binding routing-key= "foo" queue= "q" /> </direct-exchange>
        Hide
        Mark Fisher added a comment -

        I think the <binding> sub-elements is a good idea. We might need to consider the queue's whose names are auto-generated by the broker. I guess for that case, we might need to make a distinction between a Queue's name and it's bean ID? e.g. <queue id="myAnonymousQueue"/> (has no "name"). A bit weird. Thoughts?

        Show
        Mark Fisher added a comment - I think the <binding> sub-elements is a good idea. We might need to consider the queue's whose names are auto-generated by the broker. I guess for that case, we might need to make a distinction between a Queue's name and it's bean ID? e.g. <queue id="myAnonymousQueue"/> (has no "name"). A bit weird. Thoughts?
        Hide
        Dave Syer added a comment -

        Does it make sense to configure an anonymous queue in Spring? I thought those would be created on the fly for specific needs of clients. I guess maybe it does if the consumers are always alive (otherwise the queue is deleted automatically?).

        Show
        Dave Syer added a comment - Does it make sense to configure an anonymous queue in Spring? I thought those would be created on the fly for specific needs of clients. I guess maybe it does if the consumers are always alive (otherwise the queue is deleted automatically?).
        Hide
        Andrey Paramonov added a comment -

        Having binding inside exchange definition, "independent" from queue, seems counter-intuitive to me. Exchanges are usually long-living objects, as oppose to queues, which are more "volatile". So in my mind binding is much closer to queue than to exchange.

        I agree with Dave about anonymous queues. I wouldn't configure them in app context. And I think people will be confusing bean IDs and names, which one to use when.

        Show
        Andrey Paramonov added a comment - Having binding inside exchange definition, "independent" from queue, seems counter-intuitive to me. Exchanges are usually long-living objects, as oppose to queues, which are more "volatile". So in my mind binding is much closer to queue than to exchange. I agree with Dave about anonymous queues. I wouldn't configure them in app context. And I think people will be confusing bean IDs and names, which one to use when.
        Hide
        Dave Syer added a comment -

        Well, I sort agree. But I went with the bindings as sub-elements of exchanges because actually the parameters of a binding are specific to the exchange type (not the queue), e.g. fanout only needs a queue, topic needs a queue and a pattern, etc. I'll mark this as resolved and maybe open another for a <rabbit-admin/> parser that can register the bindings with the broker (works with a bean definition but it's a bit cryptic).

        Show
        Dave Syer added a comment - Well, I sort agree. But I went with the bindings as sub-elements of exchanges because actually the parameters of a binding are specific to the exchange type (not the queue), e.g. fanout only needs a queue, topic needs a queue and a pattern, etc. I'll mark this as resolved and maybe open another for a <rabbit-admin/> parser that can register the bindings with the broker (works with a bean definition but it's a bit cryptic).

          People

          • Assignee:
            Dave Syer
            Reporter:
            Mark Fisher
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: