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

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

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

    https://github.com/apache/activemq-artemis/pull/2228#discussion_r208667762
  
    --- Diff: 
artemis-selector/src/main/java/org/apache/activemq/artemis/selector/impl/SelectorParser.java
 ---
    @@ -80,11 +78,15 @@ public static BooleanExpression parse(String sql) 
throws FilterException {
                    StrictParser parser = new StrictParser(new 
StringReader(actual));
                    e = parser.JmsSelector();
                 }
    -            cache.put(sql, e);
    +            synchronized (cache) {
    --- End diff --
    
    I imagine there might be a "better" option here in terms of performance 
than using `synchronized`, but then again this isn't exactly on the hot path.  
This code is only executed when a selector/filter is first created (e.g. for a 
JMS consumer, for a bridge, etc.), and it is only executed once (i.e. execution 
isn't looped).  Most situations where cache growth is problematic (e.g. lots of 
consumers with lots of different selectors connecting and disconnecting often) 
are generally considered messaging anti-patterns anyway.  For such pathological 
cases using `synchronized` is potentially quite a bit faster than a complete 
lack of thread safety because it prevents unfettered cache growth.  In my 
opinion @franz1981's time is better spent elsewhere as this smacks of premature 
optimization.


> SelectorParser cache not thread-safe
> ------------------------------------
>
>                 Key: ARTEMIS-2017
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-2017
>             Project: ActiveMQ Artemis
>          Issue Type: Bug
>    Affects Versions: 2.6.2
>            Reporter: Justin Bertram
>            Assignee: Justin Bertram
>            Priority: Major
>             Fix For: 2.7.0, 2.6.3
>
>
> Concurrent usage of {{SelectorParser.parse()}} can cause the {{cache}} to 
> grow past its hard-coded size of 100.  Synchronizing {{put}} operations 
> eliminates this problem.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to