We are marking this issue as fixed for 2.1 as we have incorporated the fix from the customer-provided patch.

As we were not able to reproduce the exact problem locally, if the problem persists in Crowd 2.1, we will re-open this issue for further investigation.

As we have not been able to reproduce this issue locally, we would appreciate feedback on Crowd 2.1.0-beta4 from customers affected by CWD-1996.

Steps to upgrade your test instances:

1. Upgrade your Crowd server to Crowd 2.1.0-beta4
2. Upgrade your Crowd client libraries in Confluence by:
   1. deleting the old crowd-integration-client-*.jar in Confluence's WEB-INF/lib
   2. copying the new crowd-integration-client-2.1.0-beta4.jar into Confluence's WEB-INF/lib
   3. restart Confluence

Let us know if you still experience issues with nested groups in Confluence after upgrading to the beta.

We just released Crowd 2.1 Beta 4 with multiple fixes to nested group caching.

This is beta software so the usual warnings about not running it on productions systems apply.

The patch that I last uploaded to CSP-51344 has been working for us for nearly a month without a single failure

This problem was common on our Confluence 3.0.2 and rampant after upgrading to Confluence 3.3.1. In September we tried a patch that Atlassian provided. It improved the 3.3.1 bug so that the occurrence lowered from several times an hour to a few times a week, to the 3.0.2 level. In the mean time we investigated the source ourselves as we were able to reproduce the problem on a test server.

I believe that yesterday we've finally come up with a version that eliminates nested group failure bug! yay! I've posted the patch to CSP-51344 so that Atlassian engineers can look at it.

There are several problems

1. NestingHelper uses the crowd integration caches as data structures to pass data between its private members. This is error prone as the cache is highly mutable. Instead use method-scoped maps.
2. When one item in a crowd integration cache expires, then because of the inter-relationships of nested groups, all the crowd integration caches need to be cleared and rebuilt and all reads or writes to the cache must be blocked until the rebuild finishes.

Hi Dan,

We're not absolutely certain yet, but it looks like Confluence 3.2. crowd-integration-client-xx.jar has always used ehCache for storing users and groups.

In Confluence 3.2, we moved from using a Tangosol Coherence-based cache to ehCache for general Confluence caching. At the moment, it appears that Confluence and Crowd are conflicting in the way they use ehCache. Diagnosing this is complicated by the fact that we can't reproduce the issue locally.

We are working on it though.

Cheers,
Dave.

Hi,

What's the rationale for explicitly using the singleton cache manager that then gets shared between the Crowd integration client and Confluence?
If this gets executed before the host application (i.e. Confluence) initializes its own caches then the crowd configuration will be used but not the Confluence one.

Could this be changed to:

public CacheImpl(URL configLocation)
    {
        System.out.println("config location: " + configLocation);
        this.ehCacheManager = new net.sf.ehcache.CacheManager(configLocation);

Do you have any insight into when this bug started? We have updated from crowd 2.0.3 to crowd 2.0.7 as well as Confluence 3.1 to 3.3.1 and now see this issue.

Dan

Hi folks,

This integration is being completely rewritten for Crowd 2.1 / Confluence 3.5, which will fix this bug.

Apologies for not being able to fix it sooner; we cannot reproduce the problem here.

Cheers,
Dave.

• Crowd has a single default timeout value: 1 hour for all the caches. But Confluence has different times for different caches: 1 hour, 30 min, 10 min and 5 min (confluence-home-dir/config/ehcache.xml).

• Integrations having the problem are using the crowd-ehcache.xml file provided at <Crowd>/client/config

• The problem happens to Confluence only. We have not received reports for JIRA or other Apps.