Is there any solution to solve the pagination in the repostitory
Our application need do pagination for the content in the repository ,such as the "top" keyword in database.I don't know the jackrabbit supply such mechanism.Now we solve this problem by querying repostioty according to every request,But this is very inefficient . Thank you for your help.
Re: Contents of jcr-server ?
hi cédric About the 'jcr-remoting-over-webdav' part, I understant that the JCRWebdavServer stands as the server side, but do you know if someone ever worked on the JCR client part, to build the whole chain : JCR API -> WebDav request -> network -> JCRWebdavServer -> JCR Repository yes -> take a look at the spi-contrib... we ended up defining a separate layer (SPI). you may find further info as well as a summary of open issues within /contrib/spi/ and last but not least david recently startet a thread regarding the spi in general: http://thread.gmane.org/gmane.comp.apache.jackrabbit.devel/8674/focus=8728 regards angela
Re: [jira] Commented: (JCR-623) Clustering
Do you have any detail in configuration about clustering?such as the repository model. 2006/11/7, Dominique Pfister (JIRA) <[EMAIL PROTECTED]>: [ http://issues.apache.org/jira/browse/JCR-623?page=comments#action_12447461] Dominique Pfister commented on JCR-623: --- Initial commit: 471766 Features still missing: - Automatic archival of journal log entries to save space - Using a database as backend for the journal > Clustering > -- > > Key: JCR-623 > URL: http://issues.apache.org/jira/browse/JCR-623 > Project: Jackrabbit > Issue Type: New Feature > Components: core >Reporter: Dominique Pfister > Assigned To: Dominique Pfister > > Implement basic clustering, i.e. make two or more repositories available at the same time, allowing them to stay in sync with changes applied to only one of them. -- 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] Updated: (JCR-624) OutOfMemoryError When repeat login and the logout many times
[ http://issues.apache.org/jira/browse/JCR-624?page=all ] Yusuke Fujisawa updated JCR-624: Attachment: Test.java > OutOfMemoryError When repeat login and the logout many times > > > Key: JCR-624 > URL: http://issues.apache.org/jira/browse/JCR-624 > Project: Jackrabbit > Issue Type: Bug >Affects Versions: 1.1 > Environment: Windows, JDK1.5.0_09, -Xmx512m >Reporter: Yusuke Fujisawa > Attachments: Test.java > > > When repeat login and the logout many times, I encountered?OutOfMemoryError. > javax.jcr.RepositoryException: Cannot instantiate persistence manager > org.apache.jackrabbit.core.state.db.DerbyPersistenceManager: Java exception: > 'Java heap space: java.lang.OutOfMemoryError'.: Java exception: 'Java heap > space: java.lang.OutOfMemoryError'. > at > org.apache.jackrabbit.core.RepositoryImpl.createPersistenceManager(RepositoryImpl.java:1095) > at > org.apache.jackrabbit.core.RepositoryImpl.createVersionManager(RepositoryImpl.java:300) > at > org.apache.jackrabbit.core.RepositoryImpl.(RepositoryImpl.java:245) > at > org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:498) > at > org.apache.jackrabbit.core.TransientRepository$2.getRepository(TransientRepository.java:245) > at > org.apache.jackrabbit.core.TransientRepository.startRepository(TransientRepository.java:265) > at > org.apache.jackrabbit.core.TransientRepository.login(TransientRepository.java:333) > at > org.apache.jackrabbit.core.TransientRepository.login(TransientRepository.java:388) > at Test.tryLoginAndLogout(Test.java:19) > at Test.test1(Test.java:13) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at junit.framework.TestCase.runTest(TestCase.java:164) > at junit.framework.TestCase.runBare(TestCase.java:130) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:120) > at junit.framework.TestSuite.runTest(TestSuite.java:230) > at junit.framework.TestSuite.run(TestSuite.java:225) > at > org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128) > at > org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) > Caused by: SQL Exception: Java exception: 'Java heap space: > java.lang.OutOfMemoryError'. > at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source) > at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source) > at org.apache.derby.impl.jdbc.Util.javaException(Unknown Source) > at > org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown > Source) > at > org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown > Source) > at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown > Source) > at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown > Source) > at org.apache.derby.impl.jdbc.EmbedPreparedStatement.(Unknown > Source) > at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.(Unknown > Source) > at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.(Unknown > Source) > at org.apache.derby.jdbc.Driver30.newEmbedPreparedStatement(Unknown > Source) > at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown > Source) > at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown > Source) > at > org.apache.jackrabbit.core.state.db.DatabasePersistenceManager.init(DatabasePersistenceManager.java:224) > at > org.apache.jackrabbit.core.RepositoryImpl.createPersistenceManager(RepositoryImpl.java:1091) > ... 27 more > java.lang.OutOfMemoryError: Java heap space -- 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
[jira] Created: (JCR-624) OutOfMemoryError When repeat login and the logout many times
OutOfMemoryError When repeat login and the logout many times Key: JCR-624 URL: http://issues.apache.org/jira/browse/JCR-624 Project: Jackrabbit Issue Type: Bug Affects Versions: 1.1 Environment: Windows, JDK1.5.0_09, -Xmx512m Reporter: Yusuke Fujisawa When repeat login and the logout many times, I encountered OutOfMemoryError. javax.jcr.RepositoryException: Cannot instantiate persistence manager org.apache.jackrabbit.core.state.db.DerbyPersistenceManager: Java exception: 'Java heap space: java.lang.OutOfMemoryError'.: Java exception: 'Java heap space: java.lang.OutOfMemoryError'. at org.apache.jackrabbit.core.RepositoryImpl.createPersistenceManager(RepositoryImpl.java:1095) at org.apache.jackrabbit.core.RepositoryImpl.createVersionManager(RepositoryImpl.java:300) at org.apache.jackrabbit.core.RepositoryImpl.(RepositoryImpl.java:245) at org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:498) at org.apache.jackrabbit.core.TransientRepository$2.getRepository(TransientRepository.java:245) at org.apache.jackrabbit.core.TransientRepository.startRepository(TransientRepository.java:265) at org.apache.jackrabbit.core.TransientRepository.login(TransientRepository.java:333) at org.apache.jackrabbit.core.TransientRepository.login(TransientRepository.java:388) at Test.tryLoginAndLogout(Test.java:19) at Test.test1(Test.java:13) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:164) at junit.framework.TestCase.runBare(TestCase.java:130) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:120) at junit.framework.TestSuite.runTest(TestSuite.java:230) at junit.framework.TestSuite.run(TestSuite.java:225) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) Caused by: SQL Exception: Java exception: 'Java heap space: java.lang.OutOfMemoryError'. at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.javaException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.(Unknown Source) at org.apache.derby.jdbc.Driver30.newEmbedPreparedStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source) at org.apache.jackrabbit.core.state.db.DatabasePersistenceManager.init(DatabasePersistenceManager.java:224) at org.apache.jackrabbit.core.RepositoryImpl.createPersistenceManager(RepositoryImpl.java:1091) ... 27 more java.lang.OutOfMemoryError: Java heap space -- 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
Re: Contents of jcr-server ?
Hi angela, Many thanks for all these pointers. About the 'jcr-remoting-over-webdav' part, I understant that the JCRWebdavServer stands as the server side, but do you know if someone ever worked on the JCR client part, to build the whole chain : JCR API -> WebDav request -> network -> JCRWebdavServer -> JCR Repository AFAIU, the above chain miss only the first part, ie a JCR implementation based on Webdav requests. Or am I wrong ? I'm actually want to set up all possible 'jcr-remoting-over-whatever' stuff, so that I am able to perform benchmarks, compare functionalities and so on, ... Of course if I ever manage to get some figures, I'll post them here. Regards, Cédric Angela Schreiber a écrit : hi cedric there used to be a index.jsp, that roughly summarizes the contents of the jcr-server. http://svn.apache.org/repos/asf/jackrabbit/trunk/jcr-server/webapp/src/webapp/index.jsp and there were various threads regarding the aim and the status of the jcr-server in the dev list. e.g. http://thread.gmane.org/gmane.comp.apache.jackrabbit.devel/6516/focus=6528 peter darton once wrote a HOWTO. apparently it never made it into the docu: http://www.mail-archive.com/jackrabbit-dev@incubator.apache.org/msg03759.html and corrigenda: http://www.mail-archive.com/jackrabbit-dev@incubator.apache.org/msg03762.html >> I'm wondering whether this WebDAV stuff is provided to access a JCR >> Repository through a WebDAV layer (the client is a WebDAV one), or to >> implement the model 3 deployment over WebDAV (the client is a JCR >> one), or to have a full Java WebDAV server (a Slide successor). its a chimaera http://issues.apache.org/jira/browse/JCR-417 points to the issue, that should improve this situation. particularly separating the webdav-only part from the 'jcr-remoting-over-webdav'. that fact, that the jcr-server contains 2 implementations with completely different aims, apparently causes quite some confusion. regarding 'full webdav server': - we made some efforts to make the 'simple' server compliant to RFC2518. i don't know, if its a 'full' webdav server, since at Day we used to built thin webdav-views on top of our repository and not focusing too much on the Webdav itself ;) - maybe the following post may give you some hints about the basics, that lead to the webdav-library present in jackrabbit (and your question regarding 'slide'): http://thread.gmane.org/gmane.comp.apache.jackrabbit.devel/6516/focus=6528 regards angela -- Cédric Damioli Directeur de projets Solutions CMS ANYWARE TECHNOLOGIES Tel : +33 (0)5 61 00 52 90 Fax : +33 (0)5 61 00 51 46 http://www.anyware-tech.com
[jira] Closed: (JCR-619) CacheManager (Memory Management in Jackrabbit)
[ http://issues.apache.org/jira/browse/JCR-619?page=all ] Tobias Bocanegra closed JCR-619. Fix Version/s: 1.2 Resolution: Fixed Committed revision 471800. > CacheManager (Memory Management in Jackrabbit) > -- > > Key: JCR-619 > URL: http://issues.apache.org/jira/browse/JCR-619 > Project: Jackrabbit > Issue Type: New Feature > Components: core >Affects Versions: 1.1 >Reporter: Thomas Mueller > Assigned To: Tobias Bocanegra > Fix For: 1.2 > > Attachments: cacheManager.txt, cacheManager2.txt > > > Jackrabbit can run out of memory because the the combined size of the various > caches is not managed. The biggest problem (for me) is the combined size of > the o.a.j.core.state.MLRUItemStateCache caches. Each session seems to create > a few (?) of those caches, and each one is limited to 4 MB by default. > I have implemented a dynamic (cache-) memory management service that > distributes a fixed amount of memory dynamically to all those caches. > Here is the patch -- 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] Assigned: (JCR-619) CacheManager (Memory Management in Jackrabbit)
[ http://issues.apache.org/jira/browse/JCR-619?page=all ] Tobias Bocanegra reassigned JCR-619: Assignee: Tobias Bocanegra > CacheManager (Memory Management in Jackrabbit) > -- > > Key: JCR-619 > URL: http://issues.apache.org/jira/browse/JCR-619 > Project: Jackrabbit > Issue Type: New Feature > Components: core >Affects Versions: 1.1 >Reporter: Thomas Mueller > Assigned To: Tobias Bocanegra > Attachments: cacheManager.txt, cacheManager2.txt > > > Jackrabbit can run out of memory because the the combined size of the various > caches is not managed. The biggest problem (for me) is the combined size of > the o.a.j.core.state.MLRUItemStateCache caches. Each session seems to create > a few (?) of those caches, and each one is limited to 4 MB by default. > I have implemented a dynamic (cache-) memory management service that > distributes a fixed amount of memory dynamically to all those caches. > Here is the patch -- 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
Re: Contents of jcr-server ?
hi cedric there used to be a index.jsp, that roughly summarizes the contents of the jcr-server. http://svn.apache.org/repos/asf/jackrabbit/trunk/jcr-server/webapp/src/webapp/index.jsp and there were various threads regarding the aim and the status of the jcr-server in the dev list. e.g. http://thread.gmane.org/gmane.comp.apache.jackrabbit.devel/6516/focus=6528 peter darton once wrote a HOWTO. apparently it never made it into the docu: http://www.mail-archive.com/jackrabbit-dev@incubator.apache.org/msg03759.html and corrigenda: http://www.mail-archive.com/jackrabbit-dev@incubator.apache.org/msg03762.html >> I'm wondering whether this WebDAV stuff is provided to access a JCR >> Repository through a WebDAV layer (the client is a WebDAV one), or to >> implement the model 3 deployment over WebDAV (the client is a JCR >> one), or to have a full Java WebDAV server (a Slide successor). its a chimaera http://issues.apache.org/jira/browse/JCR-417 points to the issue, that should improve this situation. particularly separating the webdav-only part from the 'jcr-remoting-over-webdav'. that fact, that the jcr-server contains 2 implementations with completely different aims, apparently causes quite some confusion. regarding 'full webdav server': - we made some efforts to make the 'simple' server compliant to RFC2518. i don't know, if its a 'full' webdav server, since at Day we used to built thin webdav-views on top of our repository and not focusing too much on the Webdav itself ;) - maybe the following post may give you some hints about the basics, that lead to the webdav-library present in jackrabbit (and your question regarding 'slide'): http://thread.gmane.org/gmane.comp.apache.jackrabbit.devel/6516/focus=6528 regards angela Cédric Damioli a écrit : Hi all, Can someone tell me what are the purposes of the different parts of jcr-server ? I searched ML and wiki, but didn't found anything... see above. the index.jsp and the mentioned HOWTO should provide answers for this. There are 4 folders : - client, which I suppose to be a generic Java WebDAV client - webdav, which I suppose to be the generic parts of a Java WebDAV server, but not a server itself - server, which seems to actually contains the WebDAV server, but it also seems there are two different implementations. Is it true ? And why ? - webapp, which is the servlet part of the above server see above I also may be totally wrong about this. If someone has pointers on relevant docs, wiki, ..., I would appreciate. Of course, I would be happy to contribute back all the answers to a wiki or something like that, to make the stuff more clear to other users ? Regards,
[jira] Assigned: (JCR-620) Document View Import tests fail for EMF/XMI serialization
[ http://issues.apache.org/jira/browse/JCR-620?page=all ] Stefan Guggisberg reassigned JCR-620: - Assignee: Stefan Guggisberg > Document View Import tests fail for EMF/XMI serialization > - > > Key: JCR-620 > URL: http://issues.apache.org/jira/browse/JCR-620 > Project: Jackrabbit > Issue Type: Test > Components: JCR API >Affects Versions: 1.1 > Environment: New JUnit for org.apache.jackrabbit.test.api >Reporter: Dan Connelly > Assigned To: Stefan Guggisberg > Attachments: DocumentViewDOMSourceImportTest.java, > XMIDocumentViewImportTest.java, XMIDocumentViewImportTest.java, > XMIDocumentViewImportTest.java > > > XMIDocumentViewImportTest is copy of DocumentViewImportTest EXCEPT that > createSimpleDocument is overridden. > New simple document is typical of XMI serializations from Eclipse Modeling > Framework (EMF). > Four out of eight tests fail due to bad uriTrace below: > javax.jcr.NamespaceException: > www.apache.org/jackrabbit/test/namespaceImportTest7: is not a registered > namespace uri. > at > org.apache.jackrabbit.core.NamespaceRegistryImpl.getPrefix(NamespaceRegistryImpl.java:378) > at > org.apache.jackrabbit.core.LocalNamespaceMappings.getPrefix(LocalNamespaceMappings.java:193) > at > org.apache.jackrabbit.core.SessionImpl.getNamespacePrefix(SessionImpl.java:1307) > at > org.apache.jackrabbit.test.api.XMIDocumentViewImportTest.checkImportSimpleXMLTree(XMIDocumentViewImportTest.java:176) > at > org.apache.jackrabbit.test.api.XMIDocumentViewImportTest.performTests(XMIDocumentViewImportTest.java:154) > at > org.apache.jackrabbit.test.api.XMIDocumentViewImportTest.doTestImportXML(XMIDocumentViewImportTest.java:119) > at > org.apache.jackrabbit.test.api.XMIDocumentViewImportTest.testWorkspaceImportXml(XMIDocumentViewImportTest.java:70) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at junit.framework.TestCase.runTest(TestCase.java:154) > at junit.framework.TestCase.runBare(TestCase.java:127) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:118) > at > org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:393) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at > org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128) > at > org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) -- 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
Re: Contents of jcr-server ?
Sorry for cross-posting, but I realized that I may have more answers here than on the users ML. Regards, Cédric Cédric Damioli a écrit : Hi all, Can someone tell me what are the purposes of the different parts of jcr-server ? I searched ML and wiki, but didn't found anything... There are 4 folders : - client, which I suppose to be a generic Java WebDAV client - webdav, which I suppose to be the generic parts of a Java WebDAV server, but not a server itself - server, which seems to actually contains the WebDAV server, but it also seems there are two different implementations. Is it true ? And why ? - webapp, which is the servlet part of the above server I'm wondering whether this WebDAV stuff is provided to access a JCR Repository through a WebDAV layer (the client is a WebDAV one), or to implement the model 3 deployment over WebDAV (the client is a JCR one), or to have a full Java WebDAV server (a Slide successor). I also may be totally wrong about this. If someone has pointers on relevant docs, wiki, ..., I would appreciate. Of course, I would be happy to contribute back all the answers to a wiki or something like that, to make the stuff more clear to other users ? Regards, -- Cédric Damioli Directeur de projets Solutions CMS ANYWARE TECHNOLOGIES Tel : +33 (0)5 61 00 52 90 Fax : +33 (0)5 61 00 51 46 http://www.anyware-tech.com
Re: New feature: Clustering
Dominique Pfister a écrit : Hi, I just committed some files to implement a first approach to clustering in jackrabbit. Inside this approach, all repositories in the cluster share the persistence layer (e.g. a derby database started standalone). When a repository commits some changes, it will write a log record to a shared "journal" directory. Another repository watching that directory will eventually read this record, invalidate its internal caches and fire corresponding events. More than clustering, does this approach also enable a new PM-based implementation of the Model 3 deployment, ie a remote, shareable PM, accessible from various Jackrabbit instances ? I know this is not the purpose of a PM, but with this proposed architecture, results are functionnally the same, aren't they ? I also guess that this approach will be way faster than the RMI one, even if it's not its primary goal. Regards, -- Cédric Damioli Directeur de projets Solutions CMS ANYWARE TECHNOLOGIES Tel : +33 (0)5 61 00 52 90 Fax : +33 (0)5 61 00 51 46 http://www.anyware-tech.com
[jira] Commented: (JCR-622) Auto Reconnect for RepositoryAccessServlet
[ http://issues.apache.org/jira/browse/JCR-622?page=comments#action_12447465 ] Jukka Zitting commented on JCR-622: --- The best option would probably be to wrap the RMI repository client in a TransientRepository instance, potentially with an extra feature that invalidates an acquired repository client when a login fails with a remote exception. > Auto Reconnect for RepositoryAccessServlet > -- > > Key: JCR-622 > URL: http://issues.apache.org/jira/browse/JCR-622 > Project: Jackrabbit > Issue Type: Bug > Components: webdav >Affects Versions: 1.1 >Reporter: Claus Köll > > If i bind the RepositoryAccessServlet to a RMI Repository and then reboot the > Repository i get a > NullpointerException. > Stack : > java.lang.NullPointerException > at > org.apache.jackrabbit.webdav.jcr.JcrDavException.(JcrDavException.java:111) > at > org.apache.jackrabbit.webdav.simple.DavSessionProviderImpl.attachSession(DavSessionProviderImpl.java:99) > at > org.apache.jackrabbit.server.AbstractWebdavServlet.service(AbstractWebdavServlet.java:181) > If i deploy jackrabbit in a Model 3 Environment this Situation can happen > very often. > thanks > claus -- 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-623) Clustering
[ http://issues.apache.org/jira/browse/JCR-623?page=comments#action_12447461 ] Dominique Pfister commented on JCR-623: --- Initial commit: 471766 Features still missing: - Automatic archival of journal log entries to save space - Using a database as backend for the journal > Clustering > -- > > Key: JCR-623 > URL: http://issues.apache.org/jira/browse/JCR-623 > Project: Jackrabbit > Issue Type: New Feature > Components: core >Reporter: Dominique Pfister > Assigned To: Dominique Pfister > > Implement basic clustering, i.e. make two or more repositories available at > the same time, allowing them to stay in sync with changes applied to only > one of them. -- 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
New feature: Clustering
Hi, I just committed some files to implement a first approach to clustering in jackrabbit. Inside this approach, all repositories in the cluster share the persistence layer (e.g. a derby database started standalone). When a repository commits some changes, it will write a log record to a shared "journal" directory. Another repository watching that directory will eventually read this record, invalidate its internal caches and fire corresponding events. In order to enable clustering on some repositories, do the following for each repository: (1) Configure persistence managers with sharable data sources, e.g. standalone databases instead of embedded ones (2) Add a configuration entry to the end of your repository's repository.xml: This will make the repository write changes to the directory "/mnt/journal" and read changes made by others in the cluster. Make sure that every repository will get a different value for the "id" attribute. Alternatively, you may set the system property named "org.apache.jackrabbit.core.cluster.node_id" to your preferred value. Features still missing in the current implementation are: - Automatic archival of journal log entries to save space - Using a database as backend for the journal - And probably a lot more... The status of those features can be tracked here: https://issues.apache.org/jira/browse/JCR-623 Kind regards Dominique Pfister
[jira] Created: (JCR-623) Clustering
Clustering -- Key: JCR-623 URL: http://issues.apache.org/jira/browse/JCR-623 Project: Jackrabbit Issue Type: New Feature Components: core Reporter: Dominique Pfister Assigned To: Dominique Pfister Implement basic clustering, i.e. make two or more repositories available at the same time, allowing them to stay in sync with changes applied to only one of them. -- 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] Created: (JCR-622) Auto Reconnect for RepositoryAccessServlet
Auto Reconnect for RepositoryAccessServlet -- Key: JCR-622 URL: http://issues.apache.org/jira/browse/JCR-622 Project: Jackrabbit Issue Type: Bug Components: webdav Affects Versions: 1.1 Reporter: Claus Köll If i bind the RepositoryAccessServlet to a RMI Repository and then reboot the Repository i get a NullpointerException. Stack : java.lang.NullPointerException at org.apache.jackrabbit.webdav.jcr.JcrDavException.(JcrDavException.java:111) at org.apache.jackrabbit.webdav.simple.DavSessionProviderImpl.attachSession(DavSessionProviderImpl.java:99) at org.apache.jackrabbit.server.AbstractWebdavServlet.service(AbstractWebdavServlet.java:181) If i deploy jackrabbit in a Model 3 Environment this Situation can happen very often. thanks claus -- 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
Re: SPI: ItemInfo.getParentId()
Julian Reschke wrote: Julian Reschke schrieb: ... Looking at JCR2SPIs NodeImpl and HierarchyManagerImpl it seems that the only way to access a Node by absolute path is to recursively access all parent nodes, visiting their children. This seems to be not only inefficient, but may also cause a problem when the given user doesn't have read access to all parent nodes... the current design of the spi demands that the client on top of the spi resolves paths to ids and vice versa. this design was actually just borrowed from the jackrabbit implementation, where the lower layers don't know about paths but the items just have forward and backward references (parent uuid, child node entries and property names). I'm not so sure if we should move this task to the server. I think in most cases a workspace is accessed in a traversal way. At least that's what most methods in the JCR are about. To get a node or a property you usually start from a node you accessed before. But you are right that this design will cause problems when there are ancestor nodes that cannot be accessed. in the meantime I realized that the IdFactory can do that for me, assuming it allows .createNodeId((NodeId)null, path); ...where path would be absolute -- which the one in spi2dav doesn't (why?). (As a matter of fact a createNodeId(Path) signature would be useful). the method createNodeId(NodeId, Path) is meant for ids that are relative to an existing id. createNodeId(String, Path) is what you are looking for. here, the String uuid parameter is optional. So given the fact that the SPI API at least in theory has the capability to do the lookup without having to access the parent collections, shouldn't JCR2SPI use that when circumstances require that? major parts of the jcr2spi currently rely on hierarchical caching structure of nodes and properties. which means if an item is in the cache it's ancestors are cached as well. this simplified the handling of spi ids a lot because in some cases they can be very volatile. think of same name siblings and parent nodes that become referenceable. regards marcel
The problem about jackrabbit in Jboss
Are there anyone try to config Jboss and deploy jackrabbit in it for clustering? I need some help about this.Thank you.
