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

Justin Bertram edited comment on ARTEMIS-4399 at 8/23/23 6:17 PM:
------------------------------------------------------------------

At the moment work is underway on ARTEMIS-4349 to move from Guava to Caffeine. 
During testing of Caffeine we ran into this same kind of problem and we're 
addressing it [there|https://github.com/apache/activemq-artemis/pull/4584]. 
I've never actually seen this kind of behavior with Guava, but with Caffeine it 
jumped right out.


was (Author: jbertram):
At the moment work is underway on ARTEMIS-4349 to move from Guava to Caffeine. 
During testing of Caffeine we ran into this same kind of problem and we're 
addressing it there. I've never actually seen this kind of behavior with Guava, 
but with Caffeine it jumped right out.

> Authentication cache set to size 0 (i.e. disabled) is not threadsafe 
> ---------------------------------------------------------------------
>
>                 Key: ARTEMIS-4399
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-4399
>             Project: ActiveMQ Artemis
>          Issue Type: Bug
>    Affects Versions: 2.29.0
>            Reporter: Rich T
>            Priority: Major
>
> To disable authentication cache you have to set the following config option:
> {code:java}
> setAuthenticationCacheSize(0){code}
> SecurityStoreImpl then creates the following guava cache with maximumSize set 
> to 0:
> {code:java}
> authenticationCache = CacheBuilder.newBuilder()
> .maximumSize(authenticationCacheSize)
> .expireAfterWrite(invalidationInterval, TimeUnit.MILLISECONDS)
> .build();{code}
> The way the guava LocalCache implementation works with maximumSize is that 
> even with size 0 an entry is added but then is removed; this means that 
> another thread can end up pulling an entry out of the cache before it is 
> evicted; even though maximumSize is set to 0.
> It has taken me some effort to track down this timing issue but the behaviour 
> is also explained in the guava docs:
> {code:java}
> When size is zero, elements will be evicted immediately after being loaded 
> into the cache. This can be useful in testing, or to disable caching 
> temporarily without a code change.This feature cannot be used in conjunction 
> with maximumWeight
> {code}
> Based on these findings no auth cache should be created at all when size 0 is 
> requested.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to