[
https://issues.apache.org/jira/browse/JCR-3027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chad davis updated JCR-3027:
----------------------------
Description:
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.
was: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.
> 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
> 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
