[ 
https://issues.apache.org/jira/browse/ARTEMIS-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16023714#comment-16023714
 ] 

ASF GitHub Bot commented on ARTEMIS-1179:
-----------------------------------------

Github user clebertsuconic commented on the issue:

    https://github.com/apache/activemq-artemis/pull/1288
  
    @michaelandrepearce about seventu:
    
    A few years ago I wrote this:
    
    https://github.com/hornetq/hornetq-checkstyle-checks
    
    later one I tried submitting this to maven checkstyle, but then I was told 
that sevntu was the labs to go... so I tried submitting it there. it was so 
much of work to do that I gave up but someone there took on my idea and 
developed the same thing there....
    
    
    That's basically to enforce name on parameters, otherwise jenkins will show 
all the tests without any context:
    
    ```java
       @Parameterized.Parameters(name = "group={0}, command={1}, 
need-instance={2}")
       public static Collection getParameters() {
    ```
    
    
    
    Now if the repo keeps going out.. perhaps we should ditch it... best would 
be to ask them to have it on maven repo.


> Add Optional Client JMS Destination Cache
> -----------------------------------------
>
>                 Key: ARTEMIS-1179
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-1179
>             Project: ActiveMQ Artemis
>          Issue Type: Improvement
>            Reporter: Michael Andre Pearce
>
> Some frameworks, constantly resolve the destination by name on every send, 
> rather than caching this.
> Spring is one such very popular framework, but we have seen this 
> unfortunately else where (no doubt replicating springs logic at some point of 
> history)
> This causes a performance issue, and obviously extra calls to the broker as 
> currently the artemis jms client calls the broker to check the address.
> In some enterprise/platform setups where destinations excluding temporary 
> destinations, destinations/address's are created permanently broker side, as 
> such the destination once resolved on the client can be permanently cached 
> thus avoiding the above mentioned performance and extra calls to the broker.
> The default should keep the existing behaviour, but users should be able to 
> opt in to this benefit.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to