Access to the ContainerHost link creation

Aug 4, 2015 at 5:14 PM
Is there a way to tie into the link creation of the Amqp.Listener.ContainerHost type? Here is my use case. This application will be acting as an AMQP server. There will be many client connections. Each client will get its own partition of a particular resource on the server. Since the AMQP 1.0 specification states that a link ID must be unique (section 2.6.1) I was thinking of using the link creation event to automatically partition the client resources with its link ID. If I cannot get access to the link creation event here are the two alternatives I see.
  1. Have the client send a registration message after its link creation. This will register the client and create a partition. However this is a bit redundant since the link creation event essentially has all of the same information.
  2. Check the link ID for each message and check if a partition is created each time. If no partition is present, create it. The downside to this one is that there is overhead checking if a partition is created for every single message.
I'm also open to alternatives that I didn't think of if this doesn't seem like the best idea. Thanks for the help.
Aug 5, 2015 at 5:57 PM
One temporary solution is to implement IContainer (basically duplicating the code of ContainerHost that you need). You should have full access to link creation and closure. Meanwhile let me see how I can expose these events to the user.

Aug 6, 2015 at 5:24 PM
Thanks for the suggestion, Xin. I've just found a bug in the Apache Qpid library that affects my idea for creating resource partitions based on the link name.

They do not uniquely set the link name. I still think it would be really nice to have access to the link creation event, but for now I am going to go with option 1 that I mentioned in my first post so that I can play nicely with Qpid.
Aug 7, 2015 at 5:45 PM
I can think of scenarios where the application cannot pre-register all known addresses and needs to be involved in link creation. I plan to make this accessible as follows:
  1. user can register an AttachProcessor on the ContainerHost.
  2. when an attach frame is received, the processor will be invoked with an AttachContext that contains necessary information for the application to use.
  3. when the application finishes processing, it calls AttachContext.Complete to fully attach the link endpoint (or fail it).
It is similar to the current message processor registration pattern, but with this one can only register either an attach handler or a message handler, not both.

Aug 15, 2015 at 7:58 AM
I have updated the code on GitHub with the above support. The new example Listener.ContainerHost shows how to use a link processor to have full control of the link creation.
Aug 15, 2015 at 6:53 PM
Thanks, Xin. The example looks great. Glad to see you are using GitHub!