[ARTEMIS-1241] check for FQQN and autocreate queue using the configur…#1759
[ARTEMIS-1241] check for FQQN and autocreate queue using the configur…#1759gtully wants to merge 1 commit into
Conversation
|
I added to some existing auto create address logic in the code path which suffices for my test case. It does appear a little hacky to have three xxToUse local variables and the toString messing on simpleString does not look right. |
|
This looks OK to me. @mtaylor, will you review this since you opened the JIRA? |
| addressToUse = new SimpleString(compositeAddress.getAddress()); | ||
| queueNameToUse = new SimpleString(compositeAddress.getQueueName()); | ||
| AddressSettings as = getAddressSettingsRepository().getMatch(addressToUse.toString()); | ||
| routingTypeToUse = as.getDefaultAddressRoutingType(); |
There was a problem hiding this comment.
The routing type needs to come from the address. If the address doesn't exist, then it should be auto-created before the queue is created.
| } | ||
|
|
||
| final QueueConfig queueConfig = queueConfigBuilder.filter(filter).pagingManager(pagingManager).user(user).durable(durable).temporary(temporary).autoCreated(autoCreated).routingType(routingType).maxConsumers(maxConsumers).purgeOnNoConsumers(purgeOnNoConsumers).build(); | ||
| final QueueConfig queueConfig = queueConfigBuilder.filter(filter).pagingManager(pagingManager).user(user).durable(durable).temporary(temporary).autoCreated(autoCreated).routingType(routingTypeToUse).maxConsumers(maxConsumers).purgeOnNoConsumers(purgeOnNoConsumers).build(); |
There was a problem hiding this comment.
The routing type should be decided by the protocol handler and passed in.
| final QueueConfig.Builder queueConfigBuilder; | ||
|
|
||
| final SimpleString addressToUse = address == null ? queueName : address; | ||
| RoutingType routingTypeToUse = (routingType == null ? ActiveMQDefaultConfiguration.getDefaultRoutingType() : routingType); |
There was a problem hiding this comment.
This logic should live in the OpenWire protocol manager.
| SimpleString topic = new SimpleString("VirtualTopic.Orders"); | ||
| SimpleString subscriptionQ = new SimpleString("Consumer.A"); | ||
|
|
||
| // defaults are false via test setUp |
There was a problem hiding this comment.
We should test the case where an address already exists and the default type is ANYCAST.
There was a problem hiding this comment.
thanks @mtaylor - I see, that getDefaultAddressRoutingType should only be used by auto address creation. The queue routing type needs to be figured out from the address.
|
@mtaylor Pushed an update, with the check in the openwire session the change set is smaller and the new tests with an existing address work as expected. |
| CompositeAddress compositeAddress = CompositeAddress.getQueueName(queueName.toString()); | ||
| addressToUse = new SimpleString(compositeAddress.getAddress()); | ||
| queueNameToUse = new SimpleString(compositeAddress.getQueueName()); | ||
| } |
There was a problem hiding this comment.
@gtully This looks good, except you also need to check that the address exists and if auto-create addresses is switched on. You can get this information from the bindings query.
There was a problem hiding this comment.
server.createQueue() will create the address if it doesn't already exist.
There was a problem hiding this comment.
hmm, all the tests had a createProducer earlier that auto created the address.
With a createConsumer first I see the problem, the bindingQuery AddressInfo is null.
Passing a null routing type in that case and some tidy up in auto address creation in serverimpl works but the routingType comes from defaultConfiguration rather than the address settings in that case.
Question - should the caller figure the routingType from the addressSettings and if so should the logic for null routingType in createQueue get whacked?
There was a problem hiding this comment.
adding the logic to figure the routingType as the path of least resistance and the most explicit. The null routing type autocreateaddress case does not work in createQueue - maybe that is an indication that the relevant code can be removed.
…ed default routing type