You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Felix Meschberger (JIRA)" <ji...@apache.org> on 2004/11/18 15:57:29 UTC
[jira] Created: (JCR-20) Logging into a repository with a big version history takes a long time
Logging into a repository with a big version history takes a long time
----------------------------------------------------------------------
Key: JCR-20
URL: http://nagoya.apache.org/jira/browse/JCR-20
Project: Jackrabbit
Type: Bug
Environment: Jackrabbit SVN 76106
Reporter: Felix Meschberger
Priority: Critical
Wenn a SessionImpl instance is created, the VersionManager.getVirtualItemStateProvider method is called. This method - amongst other things - loads the complete (!) version history into memory and walks through it to do some mapping.
Besides taking a long time (near 1 minute just to get the version history through PersistentVersionManager.getVersionHistories()) mapping the version histories ultimately results in an "OutOfMemoryError".
Currently there are 768 version histories and this is only a very small fraction of the expected final number of version histories in my application
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Resolved: (JCR-20) Logging into a repository with a big version history takes a long time
Posted by "Tobias Strasser (JIRA)" <ji...@apache.org>.
[ http://nagoya.apache.org/jira/browse/JCR-20?page=history ]
Tobias Strasser resolved JCR-20:
--------------------------------
Resolution: Fixed
fixed by revision 11518
fixed issues 22 and 23. login should be faster now.
> Logging into a repository with a big version history takes a long time
> ----------------------------------------------------------------------
>
> Key: JCR-20
> URL: http://nagoya.apache.org/jira/browse/JCR-20
> Project: Jackrabbit
> Type: Bug
> Environment: Jackrabbit SVN 76106
> Reporter: Felix Meschberger
> Assignee: Tobias Strasser
> Priority: Critical
>
> Wenn a SessionImpl instance is created, the VersionManager.getVirtualItemStateProvider method is called. This method - amongst other things - loads the complete (!) version history into memory and walks through it to do some mapping.
> Besides taking a long time (near 1 minute just to get the version history through PersistentVersionManager.getVersionHistories()) mapping the version histories ultimately results in an "OutOfMemoryError".
> Currently there are 768 version histories and this is only a very small fraction of the expected final number of version histories in my application
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (JCR-20) Logging into a repository with a big version history takes a long time
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ http://nagoya.apache.org/jira/browse/JCR-20?page=comments#action_55618 ]
Felix Meschberger commented on JCR-20:
--------------------------------------
Raising the Java VM max heap helps in this case. But given that jackrabbit uses around 60MB (or more) when logging in, this kind of worries me...
> Logging into a repository with a big version history takes a long time
> ----------------------------------------------------------------------
>
> Key: JCR-20
> URL: http://nagoya.apache.org/jira/browse/JCR-20
> Project: Jackrabbit
> Type: Bug
> Environment: Jackrabbit SVN 76106
> Reporter: Felix Meschberger
> Priority: Critical
>
> Wenn a SessionImpl instance is created, the VersionManager.getVirtualItemStateProvider method is called. This method - amongst other things - loads the complete (!) version history into memory and walks through it to do some mapping.
> Besides taking a long time (near 1 minute just to get the version history through PersistentVersionManager.getVersionHistories()) mapping the version histories ultimately results in an "OutOfMemoryError".
> Currently there are 768 version histories and this is only a very small fraction of the expected final number of version histories in my application
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Assigned: (JCR-20) Logging into a repository with a big version history takes a long time
Posted by "Tobias Strasser (JIRA)" <ji...@apache.org>.
[ http://nagoya.apache.org/jira/browse/JCR-20?page=history ]
Tobias Strasser reassigned JCR-20:
----------------------------------
Assign To: Tobias Strasser
> Logging into a repository with a big version history takes a long time
> ----------------------------------------------------------------------
>
> Key: JCR-20
> URL: http://nagoya.apache.org/jira/browse/JCR-20
> Project: Jackrabbit
> Type: Bug
> Environment: Jackrabbit SVN 76106
> Reporter: Felix Meschberger
> Assignee: Tobias Strasser
> Priority: Critical
>
> Wenn a SessionImpl instance is created, the VersionManager.getVirtualItemStateProvider method is called. This method - amongst other things - loads the complete (!) version history into memory and walks through it to do some mapping.
> Besides taking a long time (near 1 minute just to get the version history through PersistentVersionManager.getVersionHistories()) mapping the version histories ultimately results in an "OutOfMemoryError".
> Currently there are 768 version histories and this is only a very small fraction of the expected final number of version histories in my application
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Closed: (JCR-20) Logging into a repository with a big version history takes a long time
Posted by "Stefan Guggisberg (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-20?page=all ]
Stefan Guggisberg closed JCR-20:
--------------------------------
closing resolved issue
> Logging into a repository with a big version history takes a long time
> ----------------------------------------------------------------------
>
> Key: JCR-20
> URL: http://issues.apache.org/jira/browse/JCR-20
> Project: Jackrabbit
> Type: Bug
> Environment: Jackrabbit SVN 76106
> Reporter: Felix Meschberger
> Assignee: Tobias Strasser
> Priority: Critical
>
> Wenn a SessionImpl instance is created, the VersionManager.getVirtualItemStateProvider method is called. This method - amongst other things - loads the complete (!) version history into memory and walks through it to do some mapping.
> Besides taking a long time (near 1 minute just to get the version history through PersistentVersionManager.getVersionHistories()) mapping the version histories ultimately results in an "OutOfMemoryError".
> Currently there are 768 version histories and this is only a very small fraction of the expected final number of version histories in my application
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (JCR-20) Logging into a repository with a big version history takes a long time
Posted by "Tobias Strasser (JIRA)" <ji...@apache.org>.
[ http://nagoya.apache.org/jira/browse/JCR-20?page=comments#action_55637 ]
Tobias Strasser commented on JCR-20:
------------------------------------
this is in fact not a desirable behaviour. will rearrange caching.
> Logging into a repository with a big version history takes a long time
> ----------------------------------------------------------------------
>
> Key: JCR-20
> URL: http://nagoya.apache.org/jira/browse/JCR-20
> Project: Jackrabbit
> Type: Bug
> Environment: Jackrabbit SVN 76106
> Reporter: Felix Meschberger
> Assignee: Tobias Strasser
> Priority: Critical
>
> Wenn a SessionImpl instance is created, the VersionManager.getVirtualItemStateProvider method is called. This method - amongst other things - loads the complete (!) version history into memory and walks through it to do some mapping.
> Besides taking a long time (near 1 minute just to get the version history through PersistentVersionManager.getVersionHistories()) mapping the version histories ultimately results in an "OutOfMemoryError".
> Currently there are 768 version histories and this is only a very small fraction of the expected final number of version histories in my application
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (JCR-20) Logging into a repository with a big version history takes a long time
Posted by "Tobias Strasser (JIRA)" <ji...@apache.org>.
[ http://nagoya.apache.org/jira/browse/JCR-20?page=comments#action_55664 ]
Tobias Strasser commented on JCR-20:
------------------------------------
currently, the virtual item state provider of the version store acts like a persistent state provider and does not create items for every session.
it is true, that all versions are loaded (twice) in memory. once in the internal representation, and once in the virtual state. both can be done more dynamically.
> Logging into a repository with a big version history takes a long time
> ----------------------------------------------------------------------
>
> Key: JCR-20
> URL: http://nagoya.apache.org/jira/browse/JCR-20
> Project: Jackrabbit
> Type: Bug
> Environment: Jackrabbit SVN 76106
> Reporter: Felix Meschberger
> Assignee: Tobias Strasser
> Priority: Critical
>
> Wenn a SessionImpl instance is created, the VersionManager.getVirtualItemStateProvider method is called. This method - amongst other things - loads the complete (!) version history into memory and walks through it to do some mapping.
> Besides taking a long time (near 1 minute just to get the version history through PersistentVersionManager.getVersionHistories()) mapping the version histories ultimately results in an "OutOfMemoryError".
> Currently there are 768 version histories and this is only a very small fraction of the expected final number of version histories in my application
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira