[jira] Commented: (JCR-1064) Optimize queries that check for the existence of a property
[ https://issues.apache.org/jira/browse/JCR-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528684 ] Ard Schrijvers commented on JCR-1064: - Have been thinking this issue over, since I think it is quite important performance improvement to get it right. I want to remove the part from the MultiIndex constructor below resetVolatileIndex(); (thus the Recovery.run(this, redoLog); and the rest) and move this in a seperate method, which I call from the SearchIndex after the MultiIndex constructor and the test for the index format. WDOT? Optimize queries that check for the existence of a property --- Key: JCR-1064 URL: https://issues.apache.org/jira/browse/JCR-1064 Project: Jackrabbit Issue Type: Improvement Components: indexing Affects Versions: 1.3.1 Reporter: Ard Schrijvers Priority: Minor Fix For: 1.4 Attachments: JCR-1064-2.patch, JCR-1064-2.patch, JCR-1064-2.patch, JCR-1064-2.patch, JCR-1064-DEPR.patch //[EMAIL PROTECTED] is transformed into the org.apache.jackrabbit.core.query.lucene.MatchAllQuery, that through the MatchAllWeight uses the MatchAllScorer. The calculateDocFilter() in MatchAllScorer does not scale and becomes slow for growing number of nodes. Solution: lucene documents will get a new Field: public static final String PROPERTIES_SET = _:PROPERTIES_SET.intern(); that holds the available properties of this document. NOTE: Lucene indices build without this performance improvement should still work and fall back to the original implementation -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1112) CacheManager interval between recalculation of cache sizes should be configurable
[ https://issues.apache.org/jira/browse/JCR-1112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528718 ] Martijn Hendriks commented on JCR-1112: --- Hi, I think that there are some issues with the current CacheManager that could be improved: - The MLRUItemStateCache.touch method triggers the CacheManager.cacheAccessed method, which may call resizeAll. When the system is heavily loaded, many threads may unnecessarily be blocked by the synchronized block in CacheManager.cacheAccessed. The chances for this increase as SLEEP decreases and the time needed for resizeAll increases. This could easily be improved . - The resizeAll method is expensive (for MLRUItemStateCaches, which are used everywhere) because it calls MLRUItemStateCache.getMemoryUsed, which recalculates the size of each entry in the cache (linear complexity in the size of the cache...). Since the NodeState/PropertyState.calculateMemoryFootprint seem to give approximate values anyway, wouldn't it be an idea to keep track of the approximate cache size in the MLRUItemStateCache itself? Furthermore, getMemoryUsed even blocks read-access to the cache. A large shared cache such as the one of the SharedItemStateManager suffers significantly from this, I think. The minimum time between rebalancing seems small but, as Thomas noted, there are certain use-cases where this is needed. Isn't there a way to detect such extreme cache blowups in another way? When, for instance, a MLRUItemStateCache keeps track of its own approximate size, the time derivative of this size could be used to prevent blowups. Best wishes, Martijn CacheManager interval between recalculation of cache sizes should be configurable - Key: JCR-1112 URL: https://issues.apache.org/jira/browse/JCR-1112 Project: Jackrabbit Issue Type: New Feature Components: core Reporter: Przemo Pakulski Assignee: Thomas Mueller Priority: Minor Attachments: JCR-1112.txt Currently interval between recaluclation of cahce size is hard coded to 1000 ms. Resizing/recalculation of cache size is quite expensive method (especially getMemoryUsed on MLRUItemStateCache is time consuming) Depending on the configuration, we realized that under some load up to 10-15% percent of CPU time (profiler metrics) could be spend doing such recalculations. It does not seem to be needed to resize cache every second. Best this interval should be configurable in external config. file with other cache settings (like memory sizes). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Jackrabbit 1.3.2 and 1.4 release planning
Hi, I'm about to start working on the release plans for both Jackrabbit 1.3.2 and 1.4. I'll start by identifying issues in Jira to target releases, and will follow up with more detailed release plans for both releases later this week. The 1.3.2 release will be a patch release from the 1.3 branch, and will contain a set of new bug fixes from trunk. I expect to only include fixes that have already been implemented and tested, but please let me know if there's some high priority bug that's still pending and you'd like to see it released soon. I'd like to push to have the 1.3.2 release out already in early October. The 1.4 release will be the next feature from Jackrabbit trunk. It will contain all the recent work on jackrabbit-core as well as both the OCM and SPI layers as new release components. There are still a number of issues open and I think I still need to open a few new issues targeted for the release, so it might well be a few more months before the release is ready. In any case I'd very much like to push the release out during Q4 this year. PS. We probably need to soon start making more comprehensive plans also for the 2.0 release. At least we should come up with a plan on what to do with Jackrabbit trunk after the 1.4 release. I'll follow up on that once the 1.3.2 and 1.4 plans are more concrete. BR, Jukka Zitting
[jira] Commented: (JCR-1138) Data store garbage collection
[ https://issues.apache.org/jira/browse/JCR-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528753 ] Thomas Mueller commented on JCR-1138: - Revision 577297: Add AbstractBundlePersistenceManager.getAllNodeIds Data store garbage collection - Key: JCR-1138 URL: https://issues.apache.org/jira/browse/JCR-1138 Project: Jackrabbit Issue Type: Improvement Components: core Reporter: Thomas Mueller Assignee: Thomas Mueller Currently the data store garbage collection needs to be run manually. It should be simpler to use (maybe tool based), or automatic. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-935) ConcurrentModificationException during logout (cont'd)
[ https://issues.apache.org/jira/browse/JCR-935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528769 ] Stefan Guggisberg commented on JCR-935: --- hi esteban, thanks for sharing your results. as mentioned earlier, FineGrainedISMLocking represents experimental code. it's work in progress and hasn't (yet?) been 'officially' endorsed. therefore i don't consider this issue a jackrabbit bug. if we agree to follow the approach of FineGrainedISMLocking we'll need to carefully investigate the new concurrency issues (such as the NPE mentioned earlier). the current 'synchronized' statements have been very carefully placed and are the result of exhaustive debugging sessions hunting down concurrency issues with DefaultISMLocking. synchronizing on the various ItemState methods as suggested bears IMO a high risk of causing dead locks. cheers stefan ConcurrentModificationException during logout (cont'd) -- Key: JCR-935 URL: https://issues.apache.org/jira/browse/JCR-935 Project: Jackrabbit Issue Type: Bug Components: core Affects Versions: 1.3 Reporter: Pablo Rios I seldom get a CME running ConcurrentReadWriteTest.testReadWrite test. Following are different stack traces of two runs: Exception in thread Thread-9 java.util.ConcurrentModificationException at org.apache.commons.collections.map.AbstractReferenceMap$ReferenceEntrySetIterator.checkMod(AbstractReferenceMap.java:761) at org.apache.commons.collections.map.AbstractReferenceMap$ReferenceEntrySetIterator.hasNext(AbstractReferenceMap.java:735) at org.apache.commons.collections.map.AbstractReferenceMap$ReferenceValues.toArray(AbstractReferenceMap.java:543) at java.util.Collections$UnmodifiableCollection.toArray(Unknown Source) at java.util.Collections$UnmodifiableCollection.toArray(Unknown Source) at org.apache.jackrabbit.core.state.LocalItemStateManager.dispose(LocalItemStateManager.java:341) at org.apache.jackrabbit.core.state.SessionItemStateManager.dispose(SessionItemStateManager.java:316) at org.apache.jackrabbit.core.SessionImpl.logout(SessionImpl.java:1269) at org.apache.jackrabbit.core.XASessionImpl.logout(XASessionImpl.java:379) at org.apache.jackrabbit.core.AbstractConcurrencyTest$Executor.run(AbstractConcurrencyTest.java:114) at java.lang.Thread.run(Unknown Source) Exception in thread Thread-9 java.util.ConcurrentModificationException at org.apache.commons.collections.map.AbstractReferenceMap$ReferenceEntrySetIterator.checkMod(AbstractReferenceMap.java:761) at org.apache.commons.collections.map.AbstractReferenceMap$ReferenceEntrySetIterator.nextEntry(AbstractReferenceMap.java:770) at org.apache.commons.collections.map.AbstractReferenceMap$ReferenceValuesIterator.next(AbstractReferenceMap.java:829) at org.apache.commons.collections.map.AbstractReferenceMap$ReferenceValues.toArray(AbstractReferenceMap.java:544) at java.util.Collections$UnmodifiableCollection.toArray(Unknown Source) at java.util.Collections$UnmodifiableCollection.toArray(Unknown Source) at org.apache.jackrabbit.core.state.LocalItemStateManager.dispose(LocalItemStateManager.java:341) at org.apache.jackrabbit.core.state.SessionItemStateManager.dispose(SessionItemStateManager.java:316) at org.apache.jackrabbit.core.SessionImpl.logout(SessionImpl.java:1269) at org.apache.jackrabbit.core.XASessionImpl.logout(XASessionImpl.java:379) at org.apache.jackrabbit.core.AbstractConcurrencyTest$Executor.run(AbstractConcurrencyTest.java:114) at java.lang.Thread.run(Unknown Source) My working copy is revision 538918 with both JCR-314 patches applied, using FineGrainedISMLocking strategy. I run this test manually from within Eclipse 3.2.1 / JRE 1.5.0_10-b03. The workstation were I run this test has an Intel Dual-Core Xeon 5130 2 GHz. To able to compare this CPU with another, with the default params of this test (NUM_NODES = 5, NUM_THREADS = 5, RUN_NUM_SECONDS = 20), the number of operations are ~ #writes performed: 300-400, #reads performed: 470 - 490. Regards, Pablo -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (JCR-1126) Content created by one TOMCAT not visible for another TOMCAT
[
https://issues.apache.org/jira/browse/JCR-1126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rama Krishna reopened JCR-1126:
---
We are implementing the tomcat load balancing for my application.
So, we need to share the same repository for all tomcats.
1) We have shared the repository folder for all tomcats (NSF mount)
2) added the cluster node in repository.xml
Cluster id=node1
Journal class=org.apache.jackrabbit.core.journal.FileJournal
param name=revision value=${rep.home}/revision.log /
param name=directory value=${rep.home}/../shared /
/Journal
/Cluster
3) added same repository.xml in all tomcats
4) First tomcat is started successfully
5) While starting the second tomcat, its throwing error.
Please advise.
Here is the error details:
19.09.2007 12:34:08 *INFO * [main] Init: [None] OCS RepositoryServlet
initializing.. (OcsLogger.java, line 80)
19.09.2007 12:34:08 *INFO * [main] Init: [None] repository-home =
/opt/webhost/ocs/shared/tomcat/mounted_data/jcr (OcsLogger.java, line 80)
19.09.2007 12:34:08 *INFO * [main] Init: [None] repository-config =
/opt/webhost/ocs/tomcat5.5.9/webapps/ocs/WEB-INF/content-repository/repository.xml
(OcsLogger.java, line 80)
19.09.2007 12:34:08 *INFO * [main] Init: [None] repository-name =
ocs.repository (OcsLogger.java, line 80)
19.09.2007 12:34:08 *INFO * [main] Init: [None] jaas config =
/opt/webhost/ocs/tomcat5.5.9/webapps/ocs/WEB-INF/content-repository/jaas.config
(OcsLogger.java, line 80)
Sep 19, 2007 12:34:08 PM org.apache.jackrabbit.core.RepositoryImpl init
INFO: Starting repository...
Sep 19, 2007 12:34:08 PM org.apache.jackrabbit.core.util.RepositoryLock acquire
WARNING: Existing lock file
/opt/webhost/ocs/shared/tomcat/mounted_data/jcr/.lock detected. Repository was
not shut down properly.
19.09.2007 12:34:08 *ERROR* [main] Init: [None] Unable to initialize
repository: javax.jcr.RepositoryException: The repository home
/opt/webhost/ocs/shared/tomcat/mounted_data/jcr appears to be in use since the
file named .lock is locked by another process.javax.jcr.RepositoryException:
The repository home /opt/webhost/ocs/shared/tomcat/mounted_data/jcr appears to
be in use since the file named .lock is locked by another process.
at
org.apache.jackrabbit.core.util.RepositoryLock.acquire(RepositoryLock.java:129)
at org.apache.jackrabbit.core.RepositoryImpl.init(RepositoryImpl.java:229)
at org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:521)
at
com.hp.ocs.j2ee.RepositoryServlet.startRepository(RepositoryServlet.java:337)
at com.hp.ocs.j2ee.RepositoryServlet.init(RepositoryServlet.java:191)
at javax.servlet.GenericServlet.init(GenericServlet.java:211)
at org.apache.catalina.core.StandardWrapper.loadServlet(Unknown Source)
at org.apache.catalina.core.StandardWrapper.load(Unknown Source)
at org.apache.catalina.core.StandardContext.loadOnStartup(Unknown Source)
at org.apache.catalina.core.StandardContext.start(Unknown Source)
at org.apache.catalina.core.ContainerBase.addChildInternal(Unknown Source)
at org.apache.catalina.core.ContainerBase.addChild(Unknown Source)
at org.apache.catalina.core.StandardHost.addChild(Unknown Source)
at org.apache.catalina.startup.HostConfig.deployDescriptor(Unknown Source)
at org.apache.catalina.startup.HostConfig.deployDescriptors(Unknown Source)
at org.apache.catalina.startup.HostConfig.deployApps(Unknown Source)
at org.apache.catalina.startup.HostConfig.start(Unknown Source)
at org.apache.catalina.startup.HostConfig.lifecycleEvent(Unknown Source)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(Unknown Source)
at org.apache.catalina.core.ContainerBase.start(Unknown Source)
at org.apache.catalina.core.StandardHost.start(Unknown Source)
at org.apache.catalina.core.ContainerBase.start(Unknown Source)
at org.apache.catalina.core.StandardEngine.start(Unknown Source)
at org.apache.catalina.core.StandardService.start(Unknown Source)
at org.apache.catalina.core.StandardServer.start(Unknown Source)
at org.apache.catalina.startup.Catalina.start(Unknown Source)
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 org.apache.catalina.startup.Bootstrap.start(Unknown Source)
at org.apache.catalina.startup.Bootstrap.main(Unknown Source)
(OcsLogger.java, line 124)
Content created by one TOMCAT not visible for another TOMCAT
Key: JCR-1126
URL: https://issues.apache.org/jira/browse/JCR-1126
Project: Jackrabbit
Issue Type: Bug
Components: webapp
Environment: Application running on loadbalanced 3 tomcats in unix
Re: Jackrabbit 1.3.2 and 1.4 release planning
Jukka Zitting wrote: ... The 1.4 release will be the next feature from Jackrabbit trunk. It will contain all the recent work on jackrabbit-core as well as both the OCM and SPI layers as new release components. There are still a number of issues open and I think I still need to open a few new issues targeted for the release, so it might well be a few more months before the release is ready. In any case I'd very much like to push the release out during Q4 this year. ... Sounds good to me. In particular, I think that once JCR2SPI has been integrated as a top-level project, we should try to work on reducing code duplication between it and the monolithic Jackrabbit. BR, Julian
[jira] Resolved: (JCR-1126) Content created by one TOMCAT not visible for another TOMCAT
[ https://issues.apache.org/jira/browse/JCR-1126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting resolved JCR-1126. Resolution: Invalid Assignee: Jukka Zitting Again resolving this as Invalid. Please do not use the issue tracker for support questions. The clustering feature request each cluster node to have their separate repository home directory and configuration files - only the persisted content is shared between the cluster nodes. See http://wiki.apache.org/jackrabbit/Clustering and the Jackrabbit mailing list archives for more details. Also, feel free to ask questions on the Jackrabbit mailing list, but please only file bug reports when you are reasonably sure that the problem is caused by Jackrabbit itself and not a misconfiguration. Content created by one TOMCAT not visible for another TOMCAT Key: JCR-1126 URL: https://issues.apache.org/jira/browse/JCR-1126 Project: Jackrabbit Issue Type: Bug Components: webapp Environment: Application running on loadbalanced 3 tomcats in unix Reporter: Rama Krishna Assignee: Jukka Zitting Attachments: jaas.config, repository.xml, screenshot-1.jpg, workspace-v1.2.xml Hello friends, I am working in a Content Management Project. We have implemented load balancing in TOMCAT (say A, B and C). But now the content created by TOMCAT-A is not visible for TOMCAT-B and TOMCAT-C even though content folder is shared between the TOMCATS. Thanks Regards, RK -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: release for Jackrabbit 1.4
Jukka Zitting wrote: Hi, On 9/11/07, ruchi goel [EMAIL PROTECTED] wrote: What is the expected time frame for release of Jackrabbit 1.4 ? I don't yet have any exact dates, but I'd expect at least a month or two before the release is ready. At least we still need to finalize the data store implementation and handle the upgrades of the OCM and SPI components. I'll come up with a more detailed release plan with relevant Jira references in near future. Is there interest in getting some essential bug fixes out already before the 1.4 release? I could easily imagine doing a 1.3.2 patch release if there's interest. BR, Jukka Zitting Yes, we are deeply interested in an interim release since we were dependent on Graffito's OCM layer earlier. Now since it is part of Jackrabbit , we will be depending on a Jackrabbit release to be bundled in our product. Is 1.4 release on hold because of the bugs mentioned in the mail chain ( with the same subject). Thanks, Ruchi
