Allow to process sender/receiver address in Policy

[wingedfox]

Hi,

I met an issue with ApacheArtemis bundled with Fabric8 - fabric8io/fabric8-ipaas#465
Artemis forces to use jms.queue. prefix and you already have similar issue #48 with ActiveMQ.

For rather small projects this might be not an issue, but for bigger project it is, because it blocks cluster-wide queue/topic naming.

What do you think about applying some policy-based processing to linkPolicy or address in createSender?

[mbroadst]

@wingedfox The solution was actually to move parseAddress to the base Policy itself (see here). You can modify that in your Policy subclass now to handle whatever special cases you run into.

It does appear that maybe you're specifically asking about parsing link addresses in particular, in which case it might be a sane solution to move that to the Policy as well. Would that satisfy your use case here?

[wingedfox]

@mbroadst Solution works with an url, not queue/topic name referred as address in
createSender - https://github.com/noodlefrenzy/node-amqp10/blob/master/lib/amqp_client.js#L186
createReceiver - https://github.com/noodlefrenzy/node-amqp10/blob/master/lib/amqp_client.js#L253

I am looking for a way to process link address in order to have a policy with queue/topic name mangling for different MQ implementations. Today I have to do the same in the business logic.

AMQPClient.createSender(process.env.MQ_Q_PREFIX + 'queue.name');

[mbroadst]

@wingedfox right, and those are using this method. I'm proposing we move that method to Policy (similar to parseAddress), so that users can implement their own logic. Does that sound reasonable?

[wingedfox]

Sure it does.

[mbroadst]

@wingedfox okay I've pushed the fix in d1ae649, perhaps you can give it a try? The idea here would be that you have something like:

let policy = new Policy();
policy.parseLinkAddress = function(address) {
   let result = Policy.prototype.parseLinkAddress(address);
   result.name = 'something-else';
   return result;

   // alternatively you can completely bypass the default implementation of `Policy`
}

let client = new amqp.Client(policy);

[wingedfox]

Thanks, it works pretty well, but is there a good way to find out whether we're creating sender/receiver for queue or topic?

Also, it worth to rewrite Policies using classes and utilize parent methods from extended policies instead of binding to the prototypes. Guess, I'll make a PR with such changes.

[mbroadst]

@wingedfox the same method is called for both sender and receiver, can you explain the use case behind needing to know more context for address parsing?

Also, the policies are using classes (insofar as javascript supports them). The above example, extending parseLinkAddress is how you override methods in "subclasses" in javascript.

[wingedfox]

@mbroadst, the question was about the distinction between queues and topics from within the link parser.

About the classes, it's all about the syntax sugar.

[mbroadst]

@wingedfox I still don't understand the question about queues and topics, could you please elaborate.

I'm also not clear what you're getting at with classes? Do you mean using ES6 classes? There has been discussion of an ES6 port, however we still have a large legacy user base that require support for node 0.10 so the transition has not begun yet.

[wingedfox]

@mbroadst
From my point of view, it is a good idea to have single MQ connection in an application and this leads to a problem: how to find out whether sender (or publisher) is going to be connected to a queue or topic from within a policy.

This question comes from the initial requirement set by Apache Artemis to explicitly use topic and message prefixes during link set up.

There's a simple way: make 2 connections, one for queues and one for topics and assign different policies, e.g. ArtemisQueuePolicy and ArtemisTopicsPolicy and statically append corresponding prefixes, but it is not the 'best practice' at all.

[mbroadst]

@wingedfox I feel like we are caught in an XY problem here. I agree that having a single connection is the ideal path for an application (and this is indeed the intent put forth in the spec, for most cases). What I am still unclear of is what your actual problem is when parsing the link address, can you please provide some code to further explain your use case?

Specifically: why is it important to you from a policy/client perspective to know whether the user is going to be connected to a queue or a topic? Shouldn't this information be known from the user's side? IIRC the ActiveMQ/Artemis connection strings look like topic://some.topic, queue://some.queue, so you would have that information in parseLinkAddress. Furthermore, AMQP 1.0 doesn't care about topic vs queue, they are all just links.