We are currently experiencing this problem on our confluence 5.6.6 installation. We've had this for quite some while. The problem seemed to have disappeared completely a while ago, just after an upgrade to 5.6.1. But it slowly creeped back in, and our recent upgrade (because of the security issue) to 5.6.6 did not change this at all. The problem is still getting worse. Nowadays pages containing this macro always give this error, and it often takes multiple reloads to get them to work. We use this macro quite intensively, so we'd really like a quick solution to this problem.

A customer of ours ran into this the other day. They were using version 2.4.3.

I've fixed it and created a pull request: https://bitbucket.org/atlassian/confluence-advanced-macros-plugin/pull-request/32/fixes-the-concurrency-bug-by-removing/diff

The fix is against version 2.4.3 so it currently conflicts on master.

If you would like to build a fixed version of the plugin, you can build this branch: https://bitbucket.org/Adaptavist/confluence-advanced-macros-plugin/branch/CONF-15313-content-by-label-concurrent-modification-exception

still have that issue under some load.

Thanks for your confirmation Jonas.

Hi Roy,

actually this error won't actually take Confluence down, but the macro call fails and renders the error statement instead of the expected result.

Since contentbylabel is one of the key macros to take advantage of labels, it should be as stable as possible.

Jonas

Hi Jonas,

I was looking at a similar case but was not sure if the ConcurrentModificationException error can kill Confluence. If it does, please let me know and I'm happy to create a support ticket for you to troubleshoot this further.

Cheers,

Roy Hartono
Atlassian Support
Sydney

Free code hosting... forever. http://www.atlassian.com/hosted/bitbucket/

Hi, just updating, this is still occuring more than a hundred times a day with a typical load of around 30000 pageviews per day. We are now running version 3.0.2 on Tomcat 6 and JDK 1.6 on a new dedicated application server and a separate database backend running PostgreSQL.

Hi Jonathan,

I don't believe it is related to garbage collection.

The problem is that some of the state used to render macros in stored in a singleton, so multiple renderings of the same macro at the same time can lead to this problem.

Unfortunately the fix is quite difficult and we have not yet been able to schedule it yet.
It is a high priority bug however.

Regards,
Andrew Lynch

We've gotten suspicious that this error occurs during garbage collection. Andrew, you said you identified the problem, but had to pull the fix. Can you say what the actual problem is?