[
https://issues.apache.org/jira/browse/JCR-3027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chad davis updated JCR-3027:
----------------------------
Component/s: jackrabbit-webapp
> JCR Server has concurrency issues on JcrWebdavServer.SessionCache internal
> HashMap caches
> -----------------------------------------------------------------------------------------
>
> Key: JCR-3027
> URL: https://issues.apache.org/jira/browse/JCR-3027
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-jcr-server, jackrabbit-webapp
> Affects Versions: 2.2.5
> Reporter: chad davis
> Labels: dav, davex, performance, remote
> Fix For: 2.3.0
>
>
> After doing the davex remoting performance work outlined in JCR-3026, the
> increased concurrency on my jcr server exposed a lot of errors related to
> getting and putting from the JcrWebdavServer.SessionCache's internal
> HashMap's. This problem with HashMap's is a well known concurrency error and
> was easily fixed by upgrading these maps to ConcurrentHashMaps. Performance
> seems dramatically better.
> The fix includes exposure of a tuning parameter that allows the user to set
> the expected concurrency level. This is the number of concurrent requests
> you expect the server to be handling. In the typical davex remoting
> scenario, this means you should tune this server side value to match the
> total max connections of all clients pointed at the server. See JCR-3026.
> USAGE: Set the 'concurrency-level' init param for the JcrRemotingServlet,
> via the web.xml of the jackabbit-webapp component. Default value is 50. Or
> you can intervene in a lower level api if appropriate.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
