[
https://issues.apache.org/jira/browse/QPID-8554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17403434#comment-17403434
]
Alex Rudyy edited comment on QPID-8554 at 8/23/21, 11:48 PM:
-------------------------------------------------------------
Hi [~lacam],
I am still struggling to understand an impact of the reported issue.
The {{CachingSecurityToken}} is used mainly to cache authorization results for
publishing operations. The token are session based. Thus, as far as I
understand the tokens are only used in IO threads. I do not see how the same
token can be invoked from multiple IO threads. Could you please provide the
stack traces for the issue?
was (Author: alex.rufous):
Hi [~lacam],
I am still struggling to understand an impact of the reported issue.
The {CachingSecurityToken} is used mainly to cache authorization results for
publishing operations. The token are session based. Thus, as far as I
understand the tokens are only used in IO threads. I do not see how the same
token can be invoked from multiple IO threads. Could you please provide the
stack traces for the issue?
> [Broker-J] Infinite loop in CachingSecurityToken class
> ------------------------------------------------------
>
> Key: QPID-8554
> URL: https://issues.apache.org/jira/browse/QPID-8554
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
> Reporter: Marek Laca
> Priority: Minor
> Labels: Broker, Java, thread-safe
>
> The CachingSecurityToken class is caching the authorization results. It can
> be utilized by multiple threads at the same time. Hence, it has to be
> multi-thread safe. The CachingSecurityToken::authorise could get stuck in an
> infinite loop when multiple threads try to update the local cache
> simultaneously.
> Two threads can be in permanent conflict when each thread is trying to
> override changes of another thread.
> {code:java}
> AccessControlCache cache;
> while((cache = CACHE_UPDATE.get(this)).getAccessControl() !=
> ruleBasedAccessControl)
> {
> CACHE_UPDATE.compareAndSet(this, cache, new
> AccessControlCache(ruleBasedAccessControl));
> }
> {code}
> Suppose two threads, the thread A and B in following scenario with steps:
> The thread A run into the loop:
> 1. Thread A checks the condition and the 'accessControl' in the cache differs
> from its local value 'ruleBasedAccessControl', let label it as accessControlA.
> 2. Thread A updates the cache with local value accessControlA.
> The thread B run into the loop:
> 3. Thread B checks the condition and the 'accessControl' in the cache differs
> from its local value 'ruleBasedAccessControl', let label it as accessControlB.
> 4. Thread B updates the cache with local value accessControlB.
> The thread A starts the next iteration of the loop:
> 5. Thread A checks the condition and the 'accessControl' in the cache is
> accessControlB, it differs from its local value accessControlA.
> 6. Thread A updates the cache with local value accessControlA.
> The thread B starts the next iteration of the loop:
> 7. Thread B checks the condition and the 'accessControl' in the cache is
> accessControlA, it differs from its local value accessControlB.
> 8. Thread B updates the cache with local value accessControlB.
> The steps 5-8 can repeat forever. Each thread finds in the cache the value
> from another thread and update cache with its own.
> The code does not have any guarantee after how many iterations the loop ends.
> The probability of the endless competition increases with number of threads.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
