Github user michaelandrepearce commented on a diff in the pull request:

    https://github.com/apache/activemq-artemis/pull/1820#discussion_r164268415
  
    --- Diff: 
artemis-jms-client/src/main/java/org/apache/activemq/artemis/jms/client/ActiveMQSession.java
 ---
    @@ -698,8 +699,17 @@ private ActiveMQMessageConsumer createConsumer(final 
ActiveMQDestination dest,
                  */
                 if (!response.isExists() || 
!response.getQueueNames().contains(dest.getSimpleAddress())) {
                    if (response.isAutoCreateQueues()) {
    +                  SimpleString queueNameToUse = dest.getSimpleAddress();
    +                  SimpleString addressToUse = queueNameToUse;
    +                  RoutingType routingTypeToUse = RoutingType.ANYCAST;
    +                  if 
(CompositeAddress.isFullyQualified(queueNameToUse.toString())) {
    +                     CompositeAddress compositeAddress = 
CompositeAddress.getQueueName(queueNameToUse.toString());
    +                     addressToUse = new 
SimpleString(compositeAddress.getAddress());
    +                     queueNameToUse = new 
SimpleString(compositeAddress.getQueueName());
    +                     routingTypeToUse = RoutingType.MULTICAST;
    --- End diff --
    
    I don’t see how that’s breaking, it’s been clear virtual topics as it 
is in activemq5 isn’t going to be ported as is, as use cases will be covered 
either with JMS 2.0 spec or FQQN (note FQQN != virtual topic). 
    
    As noted here your use case is covered by jms shared subscriptions.
    
    This PR atm breaks the documented address model to JMS mapping’s that 
exists. That a JMS queue maps onto Anycast Address and a JMS topic maps onto an 
Multicast Address.
    



---

Reply via email to