You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "chad davis (JIRA)" <ji...@apache.org> on 2011/07/20 00:34:57 UTC

[jira] [Created] (JCR-3027) JCR Server has concurrency issues on JcrWebdavServer.SessionCache internal HashMap caches

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
             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.  

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Updated] (JCR-3027) JCR Server has concurrency issues on JcrWebdavServer.SessionCache internal HashMap caches

Posted by "chad davis (JIRA)" <ji...@apache.org>.
     [ 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

        

[jira] [Updated] (JCR-3027) JCR Server has concurrency issues on JcrWebdavServer.SessionCache internal HashMap caches

Posted by "angela (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JCR-3027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

angela updated JCR-3027:
------------------------

    Resolution: Fixed
        Status: Resolved  (was: Patch Available)

applied slightly modified patch.

running the tests i noticed however the following warning:

10:30:57.694 WARN  [14745440@qtp-1360221-0] SessionState.java:236 Attempt to close session-admin-45364 while another thread is concurrently accessing this session. Blocking until the other thread is finished using this session. Please review your code to avoid concurrent use of a session.

i will open a new issue for that.

> 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
>            Assignee: angela
>              Labels: dav, davex, performance, remote
>             Fix For: 2.3.0
>
>         Attachments: JCR-3027_JCRWebdavServer.java.patch, JCR-3027_JCRWebdavServerServlet.java.patch, JCR-3027_web.xml.patch
>
>
> 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

        

[jira] [Assigned] (JCR-3027) JCR Server has concurrency issues on JcrWebdavServer.SessionCache internal HashMap caches

Posted by "angela (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JCR-3027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

angela reassigned JCR-3027:
---------------------------

    Assignee: angela

> 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
>            Assignee: angela
>              Labels: dav, davex, performance, remote
>             Fix For: 2.3.0
>
>         Attachments: JCR-3027_JCRWebdavServer.java.patch, JCR-3027_JCRWebdavServerServlet.java.patch, JCR-3027_web.xml.patch
>
>
> 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

        

[jira] [Commented] (JCR-3027) JCR Server has concurrency issues on JcrWebdavServer.SessionCache internal HashMap caches

Posted by "angela (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/JCR-3027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13069421#comment-13069421 ] 

angela commented on JCR-3027:
-----------------------------

hi chad
thanks a lot for the patches. i will take a look and apply them as soon as possible.

> 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
>            Assignee: angela
>              Labels: dav, davex, performance, remote
>             Fix For: 2.3.0
>
>         Attachments: JCR-3027_JCRWebdavServer.java.patch, JCR-3027_JCRWebdavServerServlet.java.patch, JCR-3027_web.xml.patch
>
>
> 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

        

[jira] [Updated] (JCR-3027) JCR Server has concurrency issues on JcrWebdavServer.SessionCache internal HashMap caches

Posted by "chad davis (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JCR-3027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

chad davis updated JCR-3027:
----------------------------

    Attachment: JCR-3027_web.xml.patch

> 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
>
>         Attachments: JCR-3027_JCRWebdavServer.java.patch, JCR-3027_JCRWebdavServerServlet.java.patch, JCR-3027_web.xml.patch
>
>
> 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

        

[jira] [Updated] (JCR-3027) JCR Server has concurrency issues on JcrWebdavServer.SessionCache internal HashMap caches

Posted by "chad davis (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JCR-3027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

chad davis updated JCR-3027:
----------------------------

    Status: Patch Available  (was: Open)

These patches are against the trunk, but they apply equally well against 2.2.5.  

> 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
>
>         Attachments: JCR-3027_JCRWebdavServer.java.patch, JCR-3027_JCRWebdavServerServlet.java.patch, JCR-3027_web.xml.patch
>
>
> 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

        

[jira] [Updated] (JCR-3027) JCR Server has concurrency issues on JcrWebdavServer.SessionCache internal HashMap caches

Posted by "chad davis (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JCR-3027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

chad davis updated JCR-3027:
----------------------------

    Attachment: JCR-3027_JCRWebdavServer.java.patch

> 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
>
>         Attachments: JCR-3027_JCRWebdavServer.java.patch
>
>
> 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

        

[jira] [Updated] (JCR-3027) JCR Server has concurrency issues on JcrWebdavServer.SessionCache internal HashMap caches

Posted by "chad davis (JIRA)" <ji...@apache.org>.
     [ 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

        

[jira] [Updated] (JCR-3027) JCR Server has concurrency issues on JcrWebdavServer.SessionCache internal HashMap caches

Posted by "chad davis (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JCR-3027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

chad davis updated JCR-3027:
----------------------------

    Attachment: JCR-3027_JCRWebdavServerServlet.java.patch

> 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
>
>         Attachments: JCR-3027_JCRWebdavServer.java.patch, JCR-3027_JCRWebdavServerServlet.java.patch, JCR-3027_web.xml.patch
>
>
> 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

        

[jira] [Updated] (JCR-3027) JCR Server has concurrency issues on JcrWebdavServer.SessionCache internal HashMap caches

Posted by "chad davis (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JCR-3027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

chad davis updated JCR-3027:
----------------------------


My fixes were done on 2.2.5.  In the next couple of days I'll port my work to the trunk and attach the patches to this ticket. 

> 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.  

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira