[jira] Updated: (JCR-2024) Bundle cache is not cleared when *BundlePersistenceManager is closed
[ https://issues.apache.org/jira/browse/JCR-2024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Przemo Pakulski updated JCR-2024: - Affects Version/s: 1.5.3 Fix Version/s: 1.5.4 Bundle cache is not cleared when *BundlePersistenceManager is closed Key: JCR-2024 URL: https://issues.apache.org/jira/browse/JCR-2024 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-core Affects Versions: 1.5.3 Reporter: Przemo Pakulski Assignee: Przemo Pakulski Priority: Minor Fix For: 1.5.4, 1.6.0 Attachments: JCR-2024.txt Close method of persistence managers is responsible for releasing all acquired resources. In case of BundlePersistenceManager it should also free memory by clearing the bundle cache. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-2023) WorkspaceInfo.dispose() does not deregister SharedItemStateManager from virtual item state providers
[ https://issues.apache.org/jira/browse/JCR-2023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Przemo Pakulski updated JCR-2023: - Affects Version/s: 1.5.3 Fix Version/s: 1.6.0 1.5.4 WorkspaceInfo.dispose() does not deregister SharedItemStateManager from virtual item state providers Key: JCR-2023 URL: https://issues.apache.org/jira/browse/JCR-2023 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Affects Versions: 1.5.3, 1.5.4, 1.6.0 Reporter: Przemo Pakulski Assignee: Przemo Pakulski Fix For: 1.5.4, 1.6.0 Attachments: JCR-2023.txt Automatic disposal of idle workspaces frees unused workspaces but corresponding SharedItemStateManager (and releated PersistenceManager) is still kept in memory referenced by virtual item state providers, this can lead to memory leaks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-2023) WorkspaceInfo.dispose() does not deregister SharedItemStateManager from virtual item state providers
[ https://issues.apache.org/jira/browse/JCR-2023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Przemo Pakulski updated JCR-2023: - Affects Version/s: (was: 1.5.4) (was: 1.6.0) WorkspaceInfo.dispose() does not deregister SharedItemStateManager from virtual item state providers Key: JCR-2023 URL: https://issues.apache.org/jira/browse/JCR-2023 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Affects Versions: 1.5.3 Reporter: Przemo Pakulski Assignee: Przemo Pakulski Fix For: 1.5.4, 1.6.0 Attachments: JCR-2023.txt Automatic disposal of idle workspaces frees unused workspaces but corresponding SharedItemStateManager (and releated PersistenceManager) is still kept in memory referenced by virtual item state providers, this can lead to memory leaks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-2024) Bundle cache is not cleared when *BundlePersistenceManager is closed
[ https://issues.apache.org/jira/browse/JCR-2024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Przemo Pakulski resolved JCR-2024. -- Resolution: Fixed Fix Version/s: (was: 1.5.4) Resolved in revision 755582. Bundle cache is not cleared when *BundlePersistenceManager is closed Key: JCR-2024 URL: https://issues.apache.org/jira/browse/JCR-2024 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-core Reporter: Przemo Pakulski Assignee: Przemo Pakulski Priority: Minor Fix For: 1.6.0 Attachments: JCR-2024.txt Close method of persistence managers is responsible for releasing all acquired resources. In case of BundlePersistenceManager it should also free memory by clearing the bundle cache. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-2023) WorkspaceInfo.dispose() does not deregister SharedItemStateManager from virtual item state providers
[
https://issues.apache.org/jira/browse/JCR-2023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12682266#action_12682266
]
Przemo Pakulski commented on JCR-2023:
--
During initialization of workspace SharedItemStateManager is registeres as
listener fro virtual item state providers, by the following code :
// create item state manager
try {
itemStateMgr = createItemStateManager(persistMgr, rootNodeId,
ntReg, true, cacheFactory, ismLocking);
try {
itemStateMgr.addVirtualItemStateProvider(
vMgr.getVirtualItemStateProvider());
itemStateMgr.addVirtualItemStateProvider(
virtNTMgr.getVirtualItemStateProvider());
} catch (Exception e) {
log.error(Unable to add vmgr: + e.toString(), e);
}
When workspace is disposed SharedItemStateManager should be deregistered from
virtual item state providers to aloow JVM to free memory.
WorkspaceInfo.dispose() does not deregister SharedItemStateManager from
virtual item state providers
Key: JCR-2023
URL: https://issues.apache.org/jira/browse/JCR-2023
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: jackrabbit-core
Affects Versions: 1.5.4, 1.6.0
Reporter: Przemo Pakulski
Assignee: Przemo Pakulski
Automatic disposal of idle workspaces frees unused workspaces but
corresponding SharedItemStateManager (and releated PersistenceManager) is
still kept in memory referenced by virtual item state providers, this can
lead to memory leaks.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-2023) WorkspaceInfo.dispose() does not deregister SharedItemStateManager from virtual item state providers
[ https://issues.apache.org/jira/browse/JCR-2023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Przemo Pakulski updated JCR-2023: - Attachment: JCR-2023.txt Attached patch which updates dispose() method of SharedItemStateManager and deregister it from virtual item state providers. WorkspaceInfo.dispose() does not deregister SharedItemStateManager from virtual item state providers Key: JCR-2023 URL: https://issues.apache.org/jira/browse/JCR-2023 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Affects Versions: 1.5.4, 1.6.0 Reporter: Przemo Pakulski Assignee: Przemo Pakulski Attachments: JCR-2023.txt Automatic disposal of idle workspaces frees unused workspaces but corresponding SharedItemStateManager (and releated PersistenceManager) is still kept in memory referenced by virtual item state providers, this can lead to memory leaks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-2024) Bundle cache is not cleared when *BundlePersistenceManager is closed
Bundle cache is not cleared when *BundlePersistenceManager is closed Key: JCR-2024 URL: https://issues.apache.org/jira/browse/JCR-2024 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-core Reporter: Przemo Pakulski Assignee: Przemo Pakulski Priority: Minor Fix For: 1.5.4, 1.6.0 Close method of persistence managers is responsible for releasing all acquired resources. In case of BundlePersistenceManager it should also free memory by clearing the bundle cache. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-2024) Bundle cache is not cleared when *BundlePersistenceManager is closed
[ https://issues.apache.org/jira/browse/JCR-2024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Przemo Pakulski updated JCR-2024: - Attachment: JCR-2024.txt Patch attached, close() method added to AbstractBundlePersistenceManager which clears the cache. Bundle cache is not cleared when *BundlePersistenceManager is closed Key: JCR-2024 URL: https://issues.apache.org/jira/browse/JCR-2024 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-core Reporter: Przemo Pakulski Assignee: Przemo Pakulski Priority: Minor Fix For: 1.5.4, 1.6.0 Attachments: JCR-2024.txt Close method of persistence managers is responsible for releasing all acquired resources. In case of BundlePersistenceManager it should also free memory by clearing the bundle cache. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1992) XML serialization in JRE 1.6 broken
XML serialization in JRE 1.6 broken --- Key: JCR-1992 URL: https://issues.apache.org/jira/browse/JCR-1992 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-jcr-commons Affects Versions: 1.5.2 Reporter: Przemo Pakulski Fix For: 1.6.0 It looks that after fixing JCR-1767, prefix mappings are added twice when running export using JRE 1.6. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1992) XML serialization in JRE 1.6 broken
[ https://issues.apache.org/jira/browse/JCR-1992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Przemo Pakulski updated JCR-1992: - Affects Version/s: 1.5.2 XML serialization in JRE 1.6 broken --- Key: JCR-1992 URL: https://issues.apache.org/jira/browse/JCR-1992 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-jcr-commons Affects Versions: 1.5.2, 1.6.0 Reporter: Przemo Pakulski Fix For: 1.5.3, 1.6.0 It looks that after fixing JCR-1767, prefix mappings are added twice when running export using JRE 1.6. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1992) XML serialization in JRE 1.6 broken
[ https://issues.apache.org/jira/browse/JCR-1992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Przemo Pakulski updated JCR-1992: - Fix Version/s: 1.5.3 Affects Version/s: (was: 1.5.2) 1.6.0 XML serialization in JRE 1.6 broken --- Key: JCR-1992 URL: https://issues.apache.org/jira/browse/JCR-1992 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-jcr-commons Affects Versions: 1.5.2, 1.6.0 Reporter: Przemo Pakulski Fix For: 1.5.3, 1.6.0 It looks that after fixing JCR-1767, prefix mappings are added twice when running export using JRE 1.6. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (JCR-1992) XML serialization in JRE 1.6 broken
[ https://issues.apache.org/jira/browse/JCR-1992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12675383#action_12675383 ] ppakulski edited comment on JCR-1992 at 2/20/09 7:58 AM: --- Example node exported using 1.4 : sv:node sv:name=DP11 xmlns:mix=http://www.jcp.org/jcr/mix/1.0; xmlns:nt=http://www.jcp.org/jcr/nt/1.0; xmlns:fn_old=http://www.w3.org/2004/10/xpath-functions; xmlns:fn=http://www.w3.org/2005/xpath-functions; xmlns:mtm=com.oyster.mom.contentserver xmlns:xs=http://www.w3.org/2001/XMLSchema; xmlns:sv=http://www.jcp.org/jcr/sv/1.0; xmlns:rep=internal xmlns:jcr=http://www.jcp.org/jcr/1.0; node exported using 1.6 : sv:node xmlns:fn=http://www.w3.org/2005/xpath-functions; xmlns:fn_old=http://www.w3.org/2004/10/xpath-functions; xmlns:mtm=com.oyster.mom.contentserver xmlns:xs=http://www.w3.org/2001/XMLSchema; xmlns:jcr=http://www.jcp.org/jcr/1.0; xmlns:mix=http://www.jcp.org/jcr/mix/1.0; xmlns:sv=http://www.jcp.org/jcr/sv/1.0; xmlns:rep=internal xmlns:nt=http://www.jcp.org/jcr/nt/1.0; sv:name=DP11 xmlns:fn=http://www.w3.org/2005/xpath-functions; xmlns:fn_old=http://www.w3.org/2004/10/xpath-functions; xmlns:mtm=com.oyster.mom.contentserver xmlns:xs=http://www.w3.org/2001/XMLSchema; xmlns:jcr=http://www.jcp.org/jcr/1.0; xmlns:mix=http://www.jcp.org/jcr/mix/1.0; xmlns:sv=http://www.jcp.org/jcr/sv/1.0; xmlns:rep=internal xmlns:nt=http://www.jcp.org/jcr/nt/1.0; It is causing the following exception when trying to import serialized content later : Caused by: javax.jcr.InvalidSerializedDataException: XML parse error: Attribute fn bound to namespace http://www.w3.org/2000/xmlns/; was already specified for element sv:node.: Attribute fn bound to namespace http://www.w3.org/2000/xmlns/; was already specified for element sv:node. at org.apache.jackrabbit.commons.AbstractSession.importXML(AbstractSession.java:356) was (Author: ppakulski): Example : sv:node sv:name=DP11 xmlns:mix=http://www.jcp.org/jcr/mix/1.0; xmlns:nt=http://www.jcp.org/jcr/nt/1.0; xmlns:fn_old=http://www.w3.org/2004/10/xpath-functions; xmlns:fn=http://www.w3.org/2005/xpath-functions; xmlns:mtm=com.oyster.mom.contentserver xmlns:xs=http://www.w3.org/2001/XMLSchema; xmlns:sv=http://www.jcp.org/jcr/sv/1.0; xmlns:rep=internal xmlns:jcr=http://www.jcp.org/jcr/1.0; It is causing the following exception when trying to import serialized content later : Caused by: javax.jcr.InvalidSerializedDataException: XML parse error: Attribute fn bound to namespace http://www.w3.org/2000/xmlns/; was already specified for element sv:node.: Attribute fn bound to namespace http://www.w3.org/2000/xmlns/; was already specified for element sv:node. at org.apache.jackrabbit.commons.AbstractSession.importXML(AbstractSession.java:356) XML serialization in JRE 1.6 broken --- Key: JCR-1992 URL: https://issues.apache.org/jira/browse/JCR-1992 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-jcr-commons Affects Versions: 1.5.2, 1.6.0 Reporter: Przemo Pakulski Fix For: 1.5.3, 1.6.0 It looks that after fixing JCR-1767, prefix mappings are added twice when running export using JRE 1.6. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1979) Deadlock on concurrent read transactioan write operations
Deadlock on concurrent read transactioan write operations Key: JCR-1979 URL: https://issues.apache.org/jira/browse/JCR-1979 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Affects Versions: 1.5.0 Reporter: Przemo Pakulski Isuue has been introduced by resolving JCR-1755 (Transaction-safe versioning). This fixed changed sequence of commits, but at the same time order of acquiring locks has been disturbed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1979) Deadlock on concurrent read transactional write operations
[ https://issues.apache.org/jira/browse/JCR-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Przemo Pakulski updated JCR-1979: - Summary: Deadlock on concurrent read transactional write operations (was: Deadlock on concurrent read transactioan write operations) Deadlock on concurrent read transactional write operations - Key: JCR-1979 URL: https://issues.apache.org/jira/browse/JCR-1979 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Affects Versions: 1.5.0 Reporter: Przemo Pakulski Isuue has been introduced by resolving JCR-1755 (Transaction-safe versioning). This fixed changed sequence of commits, but at the same time order of acquiring locks has been disturbed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1979) Deadlock on concurrent read transactional write operations
[ https://issues.apache.org/jira/browse/JCR-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12673248#action_12673248 ] Przemo Pakulski commented on JCR-1979: -- http-8080-10 daemon prio=10 tid=0x08bb4800 nid=0x54be in Object.wait() [0x43075000..0x430771c0] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on 0x5c2cf4c0 (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock) at java.lang.Object.wait(Object.java:485) at EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock.acquire(Unknown Source) - locked 0x5c2cf4c0 (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock) at org.apache.jackrabbit.core.state.DefaultISMLocking$ReadLockImpl.init(DefaultISMLocking.java:78) at org.apache.jackrabbit.core.state.DefaultISMLocking$ReadLockImpl.init(DefaultISMLocking.java:72) at org.apache.jackrabbit.core.state.DefaultISMLocking.acquireReadLock(DefaultISMLocking.java:40) at org.apache.jackrabbit.core.state.SharedItemStateManager.acquireReadLock(SharedItemStateManager.java:1403) at org.apache.jackrabbit.core.state.SharedItemStateManager.getNodeReferences(SharedItemStateManager.java:317) at org.apache.jackrabbit.core.version.VersionItemStateProvider.getNodeReferences(VersionItemStateProvider.java:135) at org.apache.jackrabbit.core.state.SharedItemStateManager.getNodeReferences(SharedItemStateManager.java:329) at org.apache.jackrabbit.core.state.LocalItemStateManager.getNodeReferences(LocalItemStateManager.java:202) at org.apache.jackrabbit.core.state.XAItemStateManager.getReferences(XAItemStateManager.java:358) at org.apache.jackrabbit.core.state.XAItemStateManager.hasNodeReferences(XAItemStateManager.java:321) at org.apache.jackrabbit.core.state.SessionItemStateManager.hasNodeReferences(SessionItemStateManager.java:222) at org.apache.jackrabbit.core.NodeImpl.getReferences(NodeImpl.java:4639) at org.apache.jackrabbit.core.NodeImpl.getReferences(NodeImpl.java:2890) http-8080-18 daemon prio=10 tid=0x08691c00 nid=0x54d0 in Object.wait() [0x41a6c000..0x41a6dec0] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on 0x5f1e49a0 (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock) at java.lang.Object.wait(Object.java:485) at EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock.acquire(Unknown Source) - locked 0x5f1e49a0 (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock) at org.apache.jackrabbit.core.state.DefaultISMLocking$1.init(DefaultISMLocking.java:51) at org.apache.jackrabbit.core.state.DefaultISMLocking.acquireWriteLock(DefaultISMLocking.java:48) at org.apache.jackrabbit.core.state.SharedItemStateManager.acquireWriteLock(SharedItemStateManager.java:1417) at org.apache.jackrabbit.core.state.SharedItemStateManager.access$200(SharedItemStateManager.java:116) at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:545) at org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:1056) at org.apache.jackrabbit.core.state.XAItemStateManager.prepare(XAItemStateManager.java:149) at org.apache.jackrabbit.core.TransactionContext.prepare(TransactionContext.java:138) - locked 0x72252158 (a org.apache.jackrabbit.core.TransactionContext) at org.apache.jackrabbit.core.XASessionImpl.prepare(XASessionImpl.java:324) Deadlock on concurrent read transactional write operations - Key: JCR-1979 URL: https://issues.apache.org/jira/browse/JCR-1979 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Affects Versions: 1.5.0 Reporter: Przemo Pakulski Isuue has been introduced by resolving JCR-1755 (Transaction-safe versioning). This fixed changed sequence of commits, but at the same time order of acquiring locks has been disturbed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (JCR-1979) Deadlock on concurrent read transactional write operations
[ https://issues.apache.org/jira/browse/JCR-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12673249#action_12673249 ] ppakulski edited comment on JCR-1979 at 2/13/09 5:38 AM: --- Thread http-8080-10 is executing readOnly operation, have acquired ReadLock for workspace and is waiting on ReadLock for version storage. Thread http-8080-18 is commiting transaction, have acquired WriteLock for version storage already and waiting on WriteLock for workspace. was (Author: ppakulski): Thread http-8080-10 is executing readOnly operation, have acquired ReadLock for workspace and is waiting on ReadLock for version storage. Thread http-8080-18 is commiting transaction, have acquired WriteLock for version storage already and waiting on WriteLock for workspace. Deadlock on concurrent read transactional write operations - Key: JCR-1979 URL: https://issues.apache.org/jira/browse/JCR-1979 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Affects Versions: 1.5.0 Reporter: Przemo Pakulski Isuue has been introduced by resolving JCR-1755 (Transaction-safe versioning). This fixed changed sequence of commits, but at the same time order of acquiring locks has been disturbed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1979) Deadlock on concurrent read transactional write operations
[ https://issues.apache.org/jira/browse/JCR-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12673249#action_12673249 ] Przemo Pakulski commented on JCR-1979: -- Thread http-8080-10 is executing readOnly operation, have acquired ReadLock for workspace and is waiting on ReadLock for version storage. Thread http-8080-18 is commiting transaction, have acquired WriteLock for version storage already and waiting on WriteLock for workspace. Deadlock on concurrent read transactional write operations - Key: JCR-1979 URL: https://issues.apache.org/jira/browse/JCR-1979 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Affects Versions: 1.5.0 Reporter: Przemo Pakulski Isuue has been introduced by resolving JCR-1755 (Transaction-safe versioning). This fixed changed sequence of commits, but at the same time order of acquiring locks has been disturbed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1775) Transaction-safe versioning
[
https://issues.apache.org/jira/browse/JCR-1775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12641319#action_12641319
]
Przemo Pakulski commented on JCR-1775:
--
I've created custom PM by simply overriding one method, to be able to track the
sequence of stored changes :
public synchronized void store(ChangeLog changeLog) throws
ItemStateException {
super.store(changeLog);
log.warn(STORE : + getSchemaObjectPrefix() + : + changeLog);
}
Then I run checkout/checkin operation on single node :
1) without transaction
checkout
11:12:17 WARN STORE :D1V1R2_: {#addedStates=0, #modifiedStates=2,
#deletedStates=0, #modifiedRefs=0}
11:12:17 WARN STORE :VERSION_: {#addedStates=0, #modifiedStates=0,
#deletedStates=0, #modifiedRefs=1}
checkin
11:12:17 WARN STORE :VERSION_: {#addedStates=13, #modifiedStates=3,
#deletedStates=0, #modifiedRefs=0}
11:12:17 WARN STORE :D1V1R2_: {#addedStates=0, #modifiedStates=3,
#deletedStates=0, #modifiedRefs=0}
11:12:17 WARN STORE :VERSION_: {#addedStates=0, #modifiedStates=0,
#deletedStates=0, #modifiedRefs=1}
11:12:17 WARN STORE :VERSION_: {#addedStates=0, #modifiedStates=0,
#deletedStates=0, #modifiedRefs=1}
2) checkout/checkin in transaction
11:13:57 WARN STORE :D1V1R2_: {#addedStates=0, #modifiedStates=3,
#deletedStates=0, #modifiedRefs=0}
11:13:57 WARN STORE :VERSION_: {#addedStates=0, #modifiedStates=0,
#deletedStates=0, #modifiedRefs=1}
11:13:57 WARN STORE :VERSION_: {#addedStates=13, #modifiedStates=3,
#deletedStates=0, #modifiedRefs=1}
Checkout/checkin in single JCR transaction still consist of 3 database level
transactions,
Moreover when using transaction changes in version storage are persisted first
before storing changes in the workspace.
This is probably because of order of txResources in XASessionImpl class as
described in JCR-631.
Transaction-safe versioning
---
Key: JCR-1775
URL: https://issues.apache.org/jira/browse/JCR-1775
Project: Jackrabbit
Issue Type: Improvement
Components: jackrabbit-core, transactions, versioning
Reporter: Jukka Zitting
Assignee: Jukka Zitting
Fix For: 1.5.0
I've been working on a partial fix to JCR-630. Instead of implementing fully
transactional versioning (i.e. a checkin will disappear when a transactin is
rolled back), I'm ensuring that all versioning operations within a
transaction will leave the version store in a consistent state even if the
transaction otherwise fails at any point.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1775) Transaction-safe versioning
[ https://issues.apache.org/jira/browse/JCR-1775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12641325#action_12641325 ] Przemo Pakulski commented on JCR-1775: -- D1V1R2 - is name of the workspace, VERSION is schemaObjectPrefix, i'm using MSSqlPersistenceManager Transaction-safe versioning --- Key: JCR-1775 URL: https://issues.apache.org/jira/browse/JCR-1775 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core, transactions, versioning Reporter: Jukka Zitting Assignee: Jukka Zitting Fix For: 1.5.0 I've been working on a partial fix to JCR-630. Instead of implementing fully transactional versioning (i.e. a checkin will disappear when a transactin is rolled back), I'm ensuring that all versioning operations within a transaction will leave the version store in a consistent state even if the transaction otherwise fails at any point. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (JCR-1775) Transaction-safe versioning
[
https://issues.apache.org/jira/browse/JCR-1775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12641319#action_12641319
]
ppakulski edited comment on JCR-1775 at 10/21/08 2:51 AM:
I've created custom PM by simply overriding one method, to be able to track the
sequence of stored changes :
public synchronized void store(ChangeLog changeLog) throws
ItemStateException {
super.store(changeLog);
log.warn(STORE : + getSchemaObjectPrefix() + : + changeLog);
}
Then I run checkout/checkin operation on single node :
1) without transaction
checkout
11:12:17 WARN STORE :D1V1R2_: {#addedStates=0, #modifiedStates=2,
#deletedStates=0, #modifiedRefs=0}
11:12:17 WARN STORE :VERSION_: {#addedStates=0, #modifiedStates=0,
#deletedStates=0, #modifiedRefs=1}
checkin
11:12:17 WARN STORE :VERSION_: {#addedStates=13, #modifiedStates=3,
#deletedStates=0, #modifiedRefs=0}
11:12:17 WARN STORE :D1V1R2_: {#addedStates=0, #modifiedStates=3,
#deletedStates=0, #modifiedRefs=0}
11:12:17 WARN STORE :VERSION_: {#addedStates=0, #modifiedStates=0,
#deletedStates=0, #modifiedRefs=1}
11:12:17 WARN STORE :VERSION_: {#addedStates=0, #modifiedStates=0,
#deletedStates=0, #modifiedRefs=1}
2) checkout/checkin in transaction
11:13:57 WARN STORE :D1V1R2_: {#addedStates=0, #modifiedStates=3,
#deletedStates=0, #modifiedRefs=0}
11:13:57 WARN STORE :VERSION_: {#addedStates=0, #modifiedStates=0,
#deletedStates=0, #modifiedRefs=1}
11:13:57 WARN STORE :VERSION_: {#addedStates=13, #modifiedStates=3,
#deletedStates=0, #modifiedRefs=1}
Checkout/checkin in single JCR transaction still consist of 3 database level
transactions,
Moreover when using transactions, as you can see from the logs changes in
workspace are persisted first before storing changes in the version storage.
This is probably because of order of txResources in XASessionImpl class as
described in JCR-631.
was (Author: ppakulski):
I've created custom PM by simply overriding one method, to be able to track
the sequence of stored changes :
public synchronized void store(ChangeLog changeLog) throws
ItemStateException {
super.store(changeLog);
log.warn(STORE : + getSchemaObjectPrefix() + : + changeLog);
}
Then I run checkout/checkin operation on single node :
1) without transaction
checkout
11:12:17 WARN STORE :D1V1R2_: {#addedStates=0, #modifiedStates=2,
#deletedStates=0, #modifiedRefs=0}
11:12:17 WARN STORE :VERSION_: {#addedStates=0, #modifiedStates=0,
#deletedStates=0, #modifiedRefs=1}
checkin
11:12:17 WARN STORE :VERSION_: {#addedStates=13, #modifiedStates=3,
#deletedStates=0, #modifiedRefs=0}
11:12:17 WARN STORE :D1V1R2_: {#addedStates=0, #modifiedStates=3,
#deletedStates=0, #modifiedRefs=0}
11:12:17 WARN STORE :VERSION_: {#addedStates=0, #modifiedStates=0,
#deletedStates=0, #modifiedRefs=1}
11:12:17 WARN STORE :VERSION_: {#addedStates=0, #modifiedStates=0,
#deletedStates=0, #modifiedRefs=1}
2) checkout/checkin in transaction
11:13:57 WARN STORE :D1V1R2_: {#addedStates=0, #modifiedStates=3,
#deletedStates=0, #modifiedRefs=0}
11:13:57 WARN STORE :VERSION_: {#addedStates=0, #modifiedStates=0,
#deletedStates=0, #modifiedRefs=1}
11:13:57 WARN STORE :VERSION_: {#addedStates=13, #modifiedStates=3,
#deletedStates=0, #modifiedRefs=1}
Checkout/checkin in single JCR transaction still consist of 3 database level
transactions,
Moreover when using transaction changes in version storage are persisted first
before storing changes in the workspace.
This is probably because of order of txResources in XASessionImpl class as
described in JCR-631.
Transaction-safe versioning
---
Key: JCR-1775
URL: https://issues.apache.org/jira/browse/JCR-1775
Project: Jackrabbit
Issue Type: Improvement
Components: jackrabbit-core, transactions, versioning
Reporter: Jukka Zitting
Assignee: Jukka Zitting
Fix For: 1.5.0
I've been working on a partial fix to JCR-630. Instead of implementing fully
transactional versioning (i.e. a checkin will disappear when a transactin is
rolled back), I'm ensuring that all versioning operations within a
transaction will leave the version store in a consistent state even if the
transaction otherwise fails at any point.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1825) DBDataStore doesn't support concurrent reads
[ https://issues.apache.org/jira/browse/JCR-1825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12641336#action_12641336 ] Przemo Pakulski commented on JCR-1825: -- Without setting copyWhenReading to true usage of DBDataStore is dangerous, could be a bottleneck depending how long streams are kept open. If streams are not closed DBDataStore hangs/locks. DBDataStore doesn't support concurrent reads Key: JCR-1825 URL: https://issues.apache.org/jira/browse/JCR-1825 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-core Affects Versions: 1.5.0 Reporter: Przemo Pakulski Fix For: 1.5.0 My understanding is that setting parameter copyWhenReading to true should allow concurrent reads by spooling binary property to temporary file and free database resources (connection) immediately to make it available for other threads. After applying patch for JCR-1388, DBDataStore doesn't support concurrent reads anymore, resultSet is kept open and db connection is blocked until the stream is read and closed. When copyWhenReading is set to true db connection should be released immediately, this is the reason i guess why temporary file is used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1825) DBDataStore doesn't support concurrent reads
[
https://issues.apache.org/jira/browse/JCR-1825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12641343#action_12641343
]
Przemo Pakulski commented on JCR-1825:
--
without doing major changes I suggest to change DBDataStore class as follow :
Index: src/main/java/org/apache/jackrabbit/core/data/db/DbDataStore.java
===
--- src/main/java/org/apache/jackrabbit/core/data/db/DbDataStore.java
(revision 706573)
+++ src/main/java/org/apache/jackrabbit/core/data/db/DbDataStore.java
(working copy)
@@ -519,6 +519,9 @@
if (copyWhenReading) {
File temp = moveToTempFile(result);
result = new TempFileInputStream(temp);
+DatabaseHelper.closeSilently(rs);
+putBack(conn);
+rs = null;
}
}
and DbResources.java close method to do not free db resources twice :
public void close() {
if (!closed) {
closed = true;
if (rs!=null) {
DatabaseHelper.closeSilently(rs);
try {
store.putBack(conn);
} catch (Exception e) {
log.info(Closing DbResources: , e);
}
}
}
}
Is it ok ?
DBDataStore doesn't support concurrent reads
Key: JCR-1825
URL: https://issues.apache.org/jira/browse/JCR-1825
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-core
Affects Versions: 1.5.0
Reporter: Przemo Pakulski
Fix For: 1.5.0
My understanding is that setting parameter copyWhenReading to true should
allow concurrent reads by spooling binary property to temporary file and free
database resources (connection) immediately to make it available for other
threads.
After applying patch for JCR-1388, DBDataStore doesn't support concurrent
reads anymore, resultSet is kept open and db connection is blocked until the
stream is read and closed. When copyWhenReading is set to true db connection
should be released immediately, this is the reason i guess why temporary file
is used.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (JCR-1825) DBDataStore doesn't support concurrent reads
[
https://issues.apache.org/jira/browse/JCR-1825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12641372#action_12641372
]
ppakulski edited comment on JCR-1825 at 10/21/08 6:13 AM:
Cannot see important 2 lines responsible for freeing resources in
'copyWhenReading' block
if (copyWhenReading) {
File temp = moveToTempFile(result);
result = new TempFileInputStream(temp);
+ DatabaseHelper.closeSilently(rs);
+ putBack(conn);
dbResources = new DbResources(result);
}
I do not follow changes in DbInputStream class, but I assume they are not so
important.
was (Author: ppakulski):
Cannot see important 2 lines responsible for freeing resources are missing
in 'copyWhenReading' block
if (copyWhenReading) {
File temp = moveToTempFile(result);
result = new TempFileInputStream(temp);
+ DatabaseHelper.closeSilently(rs);
+ putBack(conn);
dbResources = new DbResources(result);
}
I do not follow changes in DbInputStream class, but I assume they are not so
important.
DBDataStore doesn't support concurrent reads
Key: JCR-1825
URL: https://issues.apache.org/jira/browse/JCR-1825
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-core
Affects Versions: 1.5.0
Reporter: Przemo Pakulski
Fix For: 1.5.0
Attachments: patch.txt
My understanding is that setting parameter copyWhenReading to true should
allow concurrent reads by spooling binary property to temporary file and free
database resources (connection) immediately to make it available for other
threads.
After applying patch for JCR-1388, DBDataStore doesn't support concurrent
reads anymore, resultSet is kept open and db connection is blocked until the
stream is read and closed. When copyWhenReading is set to true db connection
should be released immediately, this is the reason i guess why temporary file
is used.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1825) DBDataStore doesn't support concurrent reads
[
https://issues.apache.org/jira/browse/JCR-1825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12641372#action_12641372
]
Przemo Pakulski commented on JCR-1825:
--
Cannot see important 2 lines responsible for freeing resources are missing in
'copyWhenReading' block
if (copyWhenReading) {
File temp = moveToTempFile(result);
result = new TempFileInputStream(temp);
+ DatabaseHelper.closeSilently(rs);
+ putBack(conn);
dbResources = new DbResources(result);
}
I do not follow changes in DbInputStream class, but I assume they are not so
important.
DBDataStore doesn't support concurrent reads
Key: JCR-1825
URL: https://issues.apache.org/jira/browse/JCR-1825
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-core
Affects Versions: 1.5.0
Reporter: Przemo Pakulski
Fix For: 1.5.0
Attachments: patch.txt
My understanding is that setting parameter copyWhenReading to true should
allow concurrent reads by spooling binary property to temporary file and free
database resources (connection) immediately to make it available for other
threads.
After applying patch for JCR-1388, DBDataStore doesn't support concurrent
reads anymore, resultSet is kept open and db connection is blocked until the
stream is read and closed. When copyWhenReading is set to true db connection
should be released immediately, this is the reason i guess why temporary file
is used.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1803) Node.restore() throws java.lang.ClassCastException
Node.restore() throws java.lang.ClassCastException
--
Key: JCR-1803
URL: https://issues.apache.org/jira/browse/JCR-1803
Project: Jackrabbit
Issue Type: Bug
Components: versioning
Affects Versions: core 1.4.6, 1.5.0
Reporter: Przemo Pakulski
Priority: Blocker
Fix For: 1.5.0
I'm trying to upgrade to 1.5 using existing 1.3.x repository. Restore of
versionable node throws ClassCastException.
Caused by: java.lang.ClassCastException: org.apache.jackrabbit.uuid.UUID
at
org.apache.jackrabbit.core.value.InternalValue.getString(InternalValue.java:436)
at
org.apache.jackrabbit.core.version.InternalFrozenNodeImpl.init(InternalFrozenNodeImpl.java:113)
at
org.apache.jackrabbit.core.version.AbstractVersionManager.createInternalVersionItem(AbstractVersionManager.java:576)
at
org.apache.jackrabbit.core.version.VersionManagerImpl.getItem(VersionManagerImpl.java:258)
at
org.apache.jackrabbit.core.version.InternalVersionImpl.getFrozenNode(InternalVersionImpl.java:111)
at
org.apache.jackrabbit.core.version.VersionImpl.getFrozenNode(VersionImpl.java:120)
at
org.apache.jackrabbit.core.NodeImpl.internalRestore(NodeImpl.java:4180)
at
org.apache.jackrabbit.core.NodeImpl.internalRestore(NodeImpl.java:4141)
at org.apache.jackrabbit.core.NodeImpl.restore(NodeImpl.java:3429)
It seems that bug has been introduced already in 1.4 as part of JCR-926
(InternalValue cleanup).
Index:
C:/data/jackrabbit/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/version/InternalFrozenNodeImpl.java
===
---
C:/data/jackrabbit/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/version/InternalFrozenNodeImpl.java
(revision 549117)
+++
C:/data/jackrabbit/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/version/InternalFrozenNodeImpl.java
(working copy)
@@ -109,10 +109,10 @@
PropertyState prop = props[i];
if (prop.getName().equals(QName.JCR_FROZENUUID)) {
// special property
-frozenUUID =
UUID.fromString(node.getPropertyValue(QName.JCR_FROZENUUID).internalValue().toString());
+frozenUUID =
UUID.fromString(node.getPropertyValue(QName.JCR_FROZENUUID).getString());
Probably one of the assumptions made was wrong :
- The type of QName.JCR_FROZENUUID is STRING (Object.toString() was used
before).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1803) Node.restore() throws java.lang.ClassCastException
[
https://issues.apache.org/jira/browse/JCR-1803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12639070#action_12639070
]
Przemo Pakulski commented on JCR-1803:
--
I've examined that all the libraries are ok.
Problem seems to be related to old issue JCR-487, our version storage still
contains frozen nodes with jcr:frozenUuid field stored as REFERENCE instead of
STRING.
Method internalValue().toString() works in both cases, whilst getString() on
jcr:frozenUUID fails for such nodes :(.
Node.restore() throws java.lang.ClassCastException
--
Key: JCR-1803
URL: https://issues.apache.org/jira/browse/JCR-1803
Project: Jackrabbit
Issue Type: Bug
Components: versioning
Affects Versions: core 1.4.6, 1.5.0
Reporter: Przemo Pakulski
Priority: Blocker
Fix For: 1.5.0
I'm trying to upgrade to 1.5 using existing 1.3.x repository. Restore of
versionable node throws ClassCastException.
Caused by: java.lang.ClassCastException: org.apache.jackrabbit.uuid.UUID
at
org.apache.jackrabbit.core.value.InternalValue.getString(InternalValue.java:436)
at
org.apache.jackrabbit.core.version.InternalFrozenNodeImpl.init(InternalFrozenNodeImpl.java:113)
at
org.apache.jackrabbit.core.version.AbstractVersionManager.createInternalVersionItem(AbstractVersionManager.java:576)
at
org.apache.jackrabbit.core.version.VersionManagerImpl.getItem(VersionManagerImpl.java:258)
at
org.apache.jackrabbit.core.version.InternalVersionImpl.getFrozenNode(InternalVersionImpl.java:111)
at
org.apache.jackrabbit.core.version.VersionImpl.getFrozenNode(VersionImpl.java:120)
at
org.apache.jackrabbit.core.NodeImpl.internalRestore(NodeImpl.java:4180)
at
org.apache.jackrabbit.core.NodeImpl.internalRestore(NodeImpl.java:4141)
at org.apache.jackrabbit.core.NodeImpl.restore(NodeImpl.java:3429)
It seems that bug has been introduced already in 1.4 as part of JCR-926
(InternalValue cleanup).
Index:
C:/data/jackrabbit/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/version/InternalFrozenNodeImpl.java
===
---
C:/data/jackrabbit/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/version/InternalFrozenNodeImpl.java
(revision 549117)
+++
C:/data/jackrabbit/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/version/InternalFrozenNodeImpl.java
(working copy)
@@ -109,10 +109,10 @@
PropertyState prop = props[i];
if (prop.getName().equals(QName.JCR_FROZENUUID)) {
// special property
-frozenUUID =
UUID.fromString(node.getPropertyValue(QName.JCR_FROZENUUID).internalValue().toString());
+frozenUUID =
UUID.fromString(node.getPropertyValue(QName.JCR_FROZENUUID).getString());
Probably one of the assumptions made was wrong :
- The type of QName.JCR_FROZENUUID is STRING (Object.toString() was used
before).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1803) Node.restore() throws java.lang.ClassCastException
[
https://issues.apache.org/jira/browse/JCR-1803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12639075#action_12639075
]
Przemo Pakulski commented on JCR-1803:
--
I fixed it by simply reverting this single line. Doesn't like it but works :).
Alternative solution is to fix the whole existing version storage somehow on
low level (PM?), but it must be done differently depending on used persistence
manager.
Node.restore() throws java.lang.ClassCastException
--
Key: JCR-1803
URL: https://issues.apache.org/jira/browse/JCR-1803
Project: Jackrabbit
Issue Type: Bug
Components: versioning
Affects Versions: core 1.4.6, 1.5.0
Reporter: Przemo Pakulski
Priority: Blocker
Fix For: 1.5.0
I'm trying to upgrade to 1.5 using existing 1.3.x repository. Restore of
versionable node throws ClassCastException.
Caused by: java.lang.ClassCastException: org.apache.jackrabbit.uuid.UUID
at
org.apache.jackrabbit.core.value.InternalValue.getString(InternalValue.java:436)
at
org.apache.jackrabbit.core.version.InternalFrozenNodeImpl.init(InternalFrozenNodeImpl.java:113)
at
org.apache.jackrabbit.core.version.AbstractVersionManager.createInternalVersionItem(AbstractVersionManager.java:576)
at
org.apache.jackrabbit.core.version.VersionManagerImpl.getItem(VersionManagerImpl.java:258)
at
org.apache.jackrabbit.core.version.InternalVersionImpl.getFrozenNode(InternalVersionImpl.java:111)
at
org.apache.jackrabbit.core.version.VersionImpl.getFrozenNode(VersionImpl.java:120)
at
org.apache.jackrabbit.core.NodeImpl.internalRestore(NodeImpl.java:4180)
at
org.apache.jackrabbit.core.NodeImpl.internalRestore(NodeImpl.java:4141)
at org.apache.jackrabbit.core.NodeImpl.restore(NodeImpl.java:3429)
It seems that bug has been introduced already in 1.4 as part of JCR-926
(InternalValue cleanup).
Index:
C:/data/jackrabbit/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/version/InternalFrozenNodeImpl.java
===
---
C:/data/jackrabbit/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/version/InternalFrozenNodeImpl.java
(revision 549117)
+++
C:/data/jackrabbit/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/version/InternalFrozenNodeImpl.java
(working copy)
@@ -109,10 +109,10 @@
PropertyState prop = props[i];
if (prop.getName().equals(QName.JCR_FROZENUUID)) {
// special property
-frozenUUID =
UUID.fromString(node.getPropertyValue(QName.JCR_FROZENUUID).internalValue().toString());
+frozenUUID =
UUID.fromString(node.getPropertyValue(QName.JCR_FROZENUUID).getString());
Probably one of the assumptions made was wrong :
- The type of QName.JCR_FROZENUUID is STRING (Object.toString() was used
before).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1242) Improve serialization of NodeReferences for BundleDB PMs
[ https://issues.apache.org/jira/browse/JCR-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Przemo Pakulski updated JCR-1242: - Attachment: JCR-1242-ISB.patch Attached new ItemStateBinding patch, new methods introduced 'read/writeIndexedPropertyId()' as suggested by Tobias, should be compatible now with third-party PMs. I would like to have it included in 1.5. Improve serialization of NodeReferences for BundleDB PMs Key: JCR-1242 URL: https://issues.apache.org/jira/browse/JCR-1242 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Reporter: Przemo Pakulski Priority: Minor Attachments: JCR-1242-BPM.patch, JCR-1242-ISB.patch, JCR-1242.patch BudleDB PMs use currently Serializer class to serialize, deserialize node references. Those methods are unefficient, it use string representation of UUID, namespaceURI and localName. For UUID rawBytes should be used and for namespaceURI, localName namespaceIndex/nameIndex should be used to improve efficiency of serialization/deserialization. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1766) Bundle binding deserialization problem
Bundle binding deserialization problem -- Key: JCR-1766 URL: https://issues.apache.org/jira/browse/JCR-1766 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-core Affects Versions: core 1.4.6, 1.5 Reporter: Przemo Pakulski Fix For: core 1.4.6, 1.5 I'm trying to upgrade from 1.3.x to jackrabbit 1.4.x (branch) and have problems with existing repostories (probaly the same issue is with 1.5.x) Caused by: org.apache.jackrabbit.core.state.ItemStateException: failed to read bundle: deadbeef-face-babe-cafe-babecafebabe: java.lang.IllegalArgumentException: invalid namespaceURI specified at org.apache.jackrabbit.core.persistence.bundle.BundleDbPersistenceManager.loadBundle(BundleDbPersistenceManager.java:1229) at org.apache.jackrabbit.core.persistence.bundle.BundleDbPersistenceManager.loadBundle(BundleDbPersistenceManager.java:1161) at org.apache.jackrabbit.core.persistence.CSPersistenceManager.loadBundle(CSPersistenceManager.java:201) It looks that issue was introduced by resolving JCR-1632 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (JCR-1766) Bundle binding deserialization problem
[ https://issues.apache.org/jira/browse/JCR-1766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12634431#action_12634431 ] ppakulski edited comment on JCR-1766 at 9/25/08 3:20 AM: --- After reading and ignoring some property names (jcr:mixinTypes, 'jcr:uuid' ,'jcr:primaryType) also folllowing property entries should be read and ignored to do not break deserialization. was (Author: ppakulski): After reading and ignoring some property names (jcr:mixinTypes, 'jcr:uuid' ,'jcr:primaryType) also folllowing property entries should be read and ignored to do not break serialization. Bundle binding deserialization problem -- Key: JCR-1766 URL: https://issues.apache.org/jira/browse/JCR-1766 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-core Affects Versions: core 1.4.6, 1.5 Reporter: Przemo Pakulski Fix For: core 1.4.6, 1.5 I'm trying to upgrade from 1.3.x to jackrabbit 1.4.x (branch) and have problems with existing repostories (probaly the same issue is with 1.5.x) Caused by: org.apache.jackrabbit.core.state.ItemStateException: failed to read bundle: deadbeef-face-babe-cafe-babecafebabe: java.lang.IllegalArgumentException: invalid namespaceURI specified at org.apache.jackrabbit.core.persistence.bundle.BundleDbPersistenceManager.loadBundle(BundleDbPersistenceManager.java:1229) at org.apache.jackrabbit.core.persistence.bundle.BundleDbPersistenceManager.loadBundle(BundleDbPersistenceManager.java:1161) at org.apache.jackrabbit.core.persistence.CSPersistenceManager.loadBundle(CSPersistenceManager.java:201) It looks that issue was introduced by resolving JCR-1632 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1766) Bundle binding deserialization problem
[ https://issues.apache.org/jira/browse/JCR-1766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Przemo Pakulski updated JCR-1766: - Description: I'm trying to upgrade from 1.3.x to jackrabbit 1.4.x (branch) and have problems with existing repostories (probaly the same issue is with 1.5.x) Caused by: org.apache.jackrabbit.core.state.ItemStateException: failed to read bundle: deadbeef-face-babe-cafe-babecafebabe: java.lang.IllegalArgumentException: invalid namespaceURI specified at org.apache.jackrabbit.core.persistence.bundle.BundleDbPersistenceManager.loadBundle(BundleDbPersistenceManager.java:1229) at org.apache.jackrabbit.core.persistence.bundle.BundleDbPersistenceManager.loadBundle(BundleDbPersistenceManager.java:1161) It looks that issue was introduced by resolving JCR-1632 was: I'm trying to upgrade from 1.3.x to jackrabbit 1.4.x (branch) and have problems with existing repostories (probaly the same issue is with 1.5.x) Caused by: org.apache.jackrabbit.core.state.ItemStateException: failed to read bundle: deadbeef-face-babe-cafe-babecafebabe: java.lang.IllegalArgumentException: invalid namespaceURI specified at org.apache.jackrabbit.core.persistence.bundle.BundleDbPersistenceManager.loadBundle(BundleDbPersistenceManager.java:1229) at org.apache.jackrabbit.core.persistence.bundle.BundleDbPersistenceManager.loadBundle(BundleDbPersistenceManager.java:1161) at org.apache.jackrabbit.core.persistence.CSPersistenceManager.loadBundle(CSPersistenceManager.java:201) It looks that issue was introduced by resolving JCR-1632 Bundle binding deserialization problem -- Key: JCR-1766 URL: https://issues.apache.org/jira/browse/JCR-1766 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-core Affects Versions: core 1.4.6, 1.5 Reporter: Przemo Pakulski Fix For: core 1.4.6, 1.5 Attachments: JCR-1766.patch I'm trying to upgrade from 1.3.x to jackrabbit 1.4.x (branch) and have problems with existing repostories (probaly the same issue is with 1.5.x) Caused by: org.apache.jackrabbit.core.state.ItemStateException: failed to read bundle: deadbeef-face-babe-cafe-babecafebabe: java.lang.IllegalArgumentException: invalid namespaceURI specified at org.apache.jackrabbit.core.persistence.bundle.BundleDbPersistenceManager.loadBundle(BundleDbPersistenceManager.java:1229) at org.apache.jackrabbit.core.persistence.bundle.BundleDbPersistenceManager.loadBundle(BundleDbPersistenceManager.java:1161) It looks that issue was introduced by resolving JCR-1632 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1766) Bundle binding deserialization problem
[ https://issues.apache.org/jira/browse/JCR-1766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Przemo Pakulski resolved JCR-1766. -- Resolution: Fixed Fixed in rev. 698935 Bundle binding deserialization problem -- Key: JCR-1766 URL: https://issues.apache.org/jira/browse/JCR-1766 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-core Affects Versions: core 1.4.6, 1.5 Reporter: Przemo Pakulski Fix For: core 1.4.6, 1.5 Attachments: JCR-1766.patch I'm trying to upgrade from 1.3.x to jackrabbit 1.4.x (branch) and have problems with existing repostories (probaly the same issue is with 1.5.x) Caused by: org.apache.jackrabbit.core.state.ItemStateException: failed to read bundle: deadbeef-face-babe-cafe-babecafebabe: java.lang.IllegalArgumentException: invalid namespaceURI specified at org.apache.jackrabbit.core.persistence.bundle.BundleDbPersistenceManager.loadBundle(BundleDbPersistenceManager.java:1229) at org.apache.jackrabbit.core.persistence.bundle.BundleDbPersistenceManager.loadBundle(BundleDbPersistenceManager.java:1161) It looks that issue was introduced by resolving JCR-1632 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1766) Bundle binding deserialization problem
[ https://issues.apache.org/jira/browse/JCR-1766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12634458#action_12634458 ] Przemo Pakulski commented on JCR-1766: -- Merged to the 1.4 branch in revision 698938. Bundle binding deserialization problem -- Key: JCR-1766 URL: https://issues.apache.org/jira/browse/JCR-1766 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-core Affects Versions: core 1.4.6, 1.5 Reporter: Przemo Pakulski Fix For: core 1.4.6, 1.5 Attachments: JCR-1766.patch I'm trying to upgrade from 1.3.x to jackrabbit 1.4.x (branch) and have problems with existing repostories (probaly the same issue is with 1.5.x) Caused by: org.apache.jackrabbit.core.state.ItemStateException: failed to read bundle: deadbeef-face-babe-cafe-babecafebabe: java.lang.IllegalArgumentException: invalid namespaceURI specified at org.apache.jackrabbit.core.persistence.bundle.BundleDbPersistenceManager.loadBundle(BundleDbPersistenceManager.java:1229) at org.apache.jackrabbit.core.persistence.bundle.BundleDbPersistenceManager.loadBundle(BundleDbPersistenceManager.java:1161) It looks that issue was introduced by resolving JCR-1632 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1461) Deadlock on concurrent commit/checkin operations
[ https://issues.apache.org/jira/browse/JCR-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577929#action_12577929 ] Przemo Pakulski commented on JCR-1461: -- Hm, deadlock occured when running 2 threads only. How do you know that another thread was involved ? Deadlock on concurrent commit/checkin operations Key: JCR-1461 URL: https://issues.apache.org/jira/browse/JCR-1461 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-core Affects Versions: 1.3.3, 1.3.4 Reporter: Przemo Pakulski Priority: Critical Attachments: JCR-1461.patch, thread-dump.txt Running concurrently jackrabbit transactions including checkin operations leads to deadlock. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1461) Deadlock on concurrent commit/checkin operations
Deadlock on concurrent commit/checkin operations Key: JCR-1461 URL: https://issues.apache.org/jira/browse/JCR-1461 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-core Affects Versions: 1.3.3, 1.3.4 Reporter: Przemo Pakulski Running concurrently jackrabbit transactions including checkin operations leads to deadlock. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1461) Deadlock on concurrent commit/checkin operations
[ https://issues.apache.org/jira/browse/JCR-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Przemo Pakulski updated JCR-1461: - Attachment: thread-dump.txt Thread dump attached (2 threads only) Deadlock on concurrent commit/checkin operations Key: JCR-1461 URL: https://issues.apache.org/jira/browse/JCR-1461 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-core Affects Versions: 1.3.3, 1.3.4 Reporter: Przemo Pakulski Attachments: thread-dump.txt Running concurrently jackrabbit transactions including checkin operations leads to deadlock. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1461) Deadlock on concurrent commit/checkin operations
[ https://issues.apache.org/jira/browse/JCR-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Przemo Pakulski updated JCR-1461: - Priority: Critical (was: Major) Deadlock on concurrent commit/checkin operations Key: JCR-1461 URL: https://issues.apache.org/jira/browse/JCR-1461 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-core Affects Versions: 1.3.3, 1.3.4 Reporter: Przemo Pakulski Priority: Critical Attachments: thread-dump.txt Running concurrently jackrabbit transactions including checkin operations leads to deadlock. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-954) Allow to disable referential integrity checking for workspace
[ https://issues.apache.org/jira/browse/JCR-954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12573752#action_12573752 ] Przemo Pakulski commented on JCR-954: - +1, that will ensure that all internal classes (including SISM) and methods will be acessible in future relases Allow to disable referential integrity checking for workspace - Key: JCR-954 URL: https://issues.apache.org/jira/browse/JCR-954 Project: Jackrabbit Issue Type: New Feature Components: jackrabbit-core Reporter: Przemo Pakulski Priority: Minor Fix For: 1.3.4, 1.5 Attachments: JCR-954-patch.txt, JCR-954-simple.diff Some operations like clone, remove operating on huge subtree of nodes requires a lot of memory. To copy, clone, remove subtree all nodes are loaded into transient spaces. It allows such operations to be transactional, from other side it requires a lot of heap size and this memory size is directly dependent on the size of subtree (number of nodes). In result of this in some cases it is impossible to make such operations in one step. In our environment sometimes 1 GB of java heap is not enough to succesfully clone subtree from one workspace to another. You can always clone (copy, remove) tree in chunks, but if you have references between subtrees such approach fails. Possibilty of temporary disabling referential integrity checking for experienced JCR user could be very usefull then. Another use case is to allow to clone selected subtrees of the whole structure between worskpaces. In our application we need to clone only some selected subtrees from one workspace to another. But we can not do that because of existing references. We need to clone the whol estructure first, then remove all unwanted nodes, which is really time expensive and memory consuming. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-954) Allow to disable referential integrity checking for workspace
[ https://issues.apache.org/jira/browse/JCR-954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12573760#action_12573760 ] Przemo Pakulski commented on JCR-954: - Could we also include patch in 1.4 maintenance branch ? Allow to disable referential integrity checking for workspace - Key: JCR-954 URL: https://issues.apache.org/jira/browse/JCR-954 Project: Jackrabbit Issue Type: New Feature Components: jackrabbit-core Reporter: Przemo Pakulski Priority: Minor Fix For: 1.3.4, 1.5 Attachments: JCR-954-patch.txt, JCR-954-simple.diff Some operations like clone, remove operating on huge subtree of nodes requires a lot of memory. To copy, clone, remove subtree all nodes are loaded into transient spaces. It allows such operations to be transactional, from other side it requires a lot of heap size and this memory size is directly dependent on the size of subtree (number of nodes). In result of this in some cases it is impossible to make such operations in one step. In our environment sometimes 1 GB of java heap is not enough to succesfully clone subtree from one workspace to another. You can always clone (copy, remove) tree in chunks, but if you have references between subtrees such approach fails. Possibilty of temporary disabling referential integrity checking for experienced JCR user could be very usefull then. Another use case is to allow to clone selected subtrees of the whole structure between worskpaces. In our application we need to clone only some selected subtrees from one workspace to another. But we can not do that because of existing references. We need to clone the whol estructure first, then remove all unwanted nodes, which is really time expensive and memory consuming. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1436) Backport JCR-1209 : NodeImpl.checkout() calls save() two times
Backport JCR-1209 : NodeImpl.checkout() calls save() two times -- Key: JCR-1436 URL: https://issues.apache.org/jira/browse/JCR-1436 Project: Jackrabbit Issue Type: Improvement Components: versioning Affects Versions: 1.3.3 Reporter: Przemo Pakulski Priority: Minor Fix For: 1.3.4 Backport issue JCR-1209 (NodeImpl.checkout() calls save() two times) to 1.3 branch for 1.3.4 (separate issue to avoid re-opening JCR-1209 which was already released with 1.4). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-954) Allow to disable referential integrity checking for workspace
[ https://issues.apache.org/jira/browse/JCR-954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12572888#action_12572888 ] Przemo Pakulski commented on JCR-954: - I first proposed patch I've added the following method to RepositoryImpl class : * Enables/disables referential integrity check for workspace. * * @param workspaceName * @param checkIntegrityEnabled * @throws RepositoryException */ public void setCheckIntegrityEnabled(String workspaceName, boolean checkIntegrityEnabled) throws RepositoryException; To keep the patch simple, I created own wrapper for RepositorImpl class and moved this method to custom RepositoryImpl implementation, so I'm able to enable/disable referential integrity checking for any workspace programatically. Allow to disable referential integrity checking for workspace - Key: JCR-954 URL: https://issues.apache.org/jira/browse/JCR-954 Project: Jackrabbit Issue Type: New Feature Components: jackrabbit-core Reporter: Przemo Pakulski Priority: Minor Fix For: 1.3.4, 1.5 Attachments: JCR-954-patch.txt, JCR-954-simple.diff Some operations like clone, remove operating on huge subtree of nodes requires a lot of memory. To copy, clone, remove subtree all nodes are loaded into transient spaces. It allows such operations to be transactional, from other side it requires a lot of heap size and this memory size is directly dependent on the size of subtree (number of nodes). In result of this in some cases it is impossible to make such operations in one step. In our environment sometimes 1 GB of java heap is not enough to succesfully clone subtree from one workspace to another. You can always clone (copy, remove) tree in chunks, but if you have references between subtrees such approach fails. Possibilty of temporary disabling referential integrity checking for experienced JCR user could be very usefull then. Another use case is to allow to clone selected subtrees of the whole structure between worskpaces. In our application we need to clone only some selected subtrees from one workspace to another. But we can not do that because of existing references. We need to clone the whol estructure first, then remove all unwanted nodes, which is really time expensive and memory consuming. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1429) Backport JCR-1112: CacheManager interval between recalculation of cache sizes should be configurable
Backport JCR-1112: CacheManager interval between recalculation of cache sizes should be configurable Key: JCR-1429 URL: https://issues.apache.org/jira/browse/JCR-1429 Project: Jackrabbit Issue Type: New Feature Components: jackrabbit-core Affects Versions: 1.3.3 Reporter: Przemo Pakulski Priority: Minor Fix For: 1.3.4 Backport issue JCR-1112 (CacheManager interval between recalculation of cache sizes should be configurable) to 1.3 branch for 1.3.4 (separate issue to avoid re-opening JCR-1112 which has beed already released with 1.4). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1421) Backport JCR-1111 to 1.3 branch
Backport JCR- to 1.3 branch --- Key: JCR-1421 URL: https://issues.apache.org/jira/browse/JCR-1421 Project: Jackrabbit Issue Type: Improvement Components: versioning Affects Versions: 1.3.3, 1.3.1, 1.3 Reporter: Przemo Pakulski Fix For: 1.3.4 Backport issue JCR- (Accesss to version history results in reading all versions of versionable node) to 1.3 branch for 1.3.4 (separate issue to avoid re-opening JCR- which was already released with 1.4). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1421) Backport JCR-1111 to 1.3 branch
[ https://issues.apache.org/jira/browse/JCR-1421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Przemo Pakulski updated JCR-1421: - Attachment: JCR-1421.diff Backport patch attached. Backport JCR- to 1.3 branch --- Key: JCR-1421 URL: https://issues.apache.org/jira/browse/JCR-1421 Project: Jackrabbit Issue Type: Improvement Components: versioning Affects Versions: 1.3, 1.3.1, 1.3.3 Reporter: Przemo Pakulski Fix For: 1.3.4 Attachments: JCR-1421.diff Backport issue JCR- (Accesss to version history results in reading all versions of versionable node) to 1.3 branch for 1.3.4 (separate issue to avoid re-opening JCR- which was already released with 1.4). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1421) Backport JCR-1111 to 1.3 branch
[ https://issues.apache.org/jira/browse/JCR-1421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Przemo Pakulski resolved JCR-1421. -- Resolution: Fixed Resolved in rev. 631310 Backport JCR- to 1.3 branch --- Key: JCR-1421 URL: https://issues.apache.org/jira/browse/JCR-1421 Project: Jackrabbit Issue Type: Improvement Components: versioning Affects Versions: 1.3, 1.3.1, 1.3.3 Reporter: Przemo Pakulski Fix For: 1.3.4 Attachments: JCR-1421.diff Backport issue JCR- (Accesss to version history results in reading all versions of versionable node) to 1.3 branch for 1.3.4 (separate issue to avoid re-opening JCR- which was already released with 1.4). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-954) Allow to disable referential integrity checking for workspace
[ https://issues.apache.org/jira/browse/JCR-954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Przemo Pakulski updated JCR-954: Fix Version/s: 1.5 1.4.1 1.3.4 Priority: Minor (was: Major) Affects Version/s: 1.5 1.4.1 1.3.3 1.4 Allow to disable referential integrity checking for workspace - Key: JCR-954 URL: https://issues.apache.org/jira/browse/JCR-954 Project: Jackrabbit Issue Type: New Feature Components: jackrabbit-core Affects Versions: 1.3.3, 1.4, 1.4.1, 1.5 Reporter: Przemo Pakulski Priority: Minor Fix For: 1.3.4, 1.4.1, 1.5 Attachments: JCR-954-patch.txt Some operations like clone, remove operating on huge subtree of nodes requires a lot of memory. To copy, clone, remove subtree all nodes are loaded into transient spaces. It allows such operations to be transactional, from other side it requires a lot of heap size and this memory size is directly dependent on the size of subtree (number of nodes). In result of this in some cases it is impossible to make such operations in one step. In our environment sometimes 1 GB of java heap is not enough to succesfully clone subtree from one workspace to another. You can always clone (copy, remove) tree in chunks, but if you have references between subtrees such approach fails. Possibilty of temporary disabling referential integrity checking for experienced JCR user could be very usefull then. Another use case is to allow to clone selected subtrees of the whole structure between worskpaces. In our application we need to clone only some selected subtrees from one workspace to another. But we can not do that because of existing references. We need to clone the whol estructure first, then remove all unwanted nodes, which is really time expensive and memory consuming. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-954) Allow to disable referential integrity checking for workspace
[ https://issues.apache.org/jira/browse/JCR-954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12572697#action_12572697 ] Przemo Pakulski commented on JCR-954: - Without such option it is not possible to clone, import neither remove relatively big subtrees of nodes at all. I really need such functionality, but nobody even tried to address the real issue since 9 months already. Allow to disable referential integrity checking for workspace - Key: JCR-954 URL: https://issues.apache.org/jira/browse/JCR-954 Project: Jackrabbit Issue Type: New Feature Components: jackrabbit-core Affects Versions: 1.3.3, 1.4, 1.4.1, 1.5 Reporter: Przemo Pakulski Priority: Minor Fix For: 1.3.4, 1.4.1, 1.5 Attachments: JCR-954-patch.txt Some operations like clone, remove operating on huge subtree of nodes requires a lot of memory. To copy, clone, remove subtree all nodes are loaded into transient spaces. It allows such operations to be transactional, from other side it requires a lot of heap size and this memory size is directly dependent on the size of subtree (number of nodes). In result of this in some cases it is impossible to make such operations in one step. In our environment sometimes 1 GB of java heap is not enough to succesfully clone subtree from one workspace to another. You can always clone (copy, remove) tree in chunks, but if you have references between subtrees such approach fails. Possibilty of temporary disabling referential integrity checking for experienced JCR user could be very usefull then. Another use case is to allow to clone selected subtrees of the whole structure between worskpaces. In our application we need to clone only some selected subtrees from one workspace to another. But we can not do that because of existing references. We need to clone the whol estructure first, then remove all unwanted nodes, which is really time expensive and memory consuming. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-954) Allow to disable referential integrity checking for workspace
[ https://issues.apache.org/jira/browse/JCR-954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Przemo Pakulski updated JCR-954: Attachment: JCR-954-simple.diff Simpler version of patch attached : - no public api method, - no changes in functionality (integrity checking enabled by default), - just single flag with the setter in SharedItemStateManager class which allow to control this behaviour programatically by experienced developers. Allow to disable referential integrity checking for workspace - Key: JCR-954 URL: https://issues.apache.org/jira/browse/JCR-954 Project: Jackrabbit Issue Type: New Feature Components: jackrabbit-core Affects Versions: 1.3.3, 1.4, 1.4.1, 1.5 Reporter: Przemo Pakulski Priority: Minor Fix For: 1.3.4, 1.4.1, 1.5 Attachments: JCR-954-patch.txt, JCR-954-simple.diff Some operations like clone, remove operating on huge subtree of nodes requires a lot of memory. To copy, clone, remove subtree all nodes are loaded into transient spaces. It allows such operations to be transactional, from other side it requires a lot of heap size and this memory size is directly dependent on the size of subtree (number of nodes). In result of this in some cases it is impossible to make such operations in one step. In our environment sometimes 1 GB of java heap is not enough to succesfully clone subtree from one workspace to another. You can always clone (copy, remove) tree in chunks, but if you have references between subtrees such approach fails. Possibilty of temporary disabling referential integrity checking for experienced JCR user could be very usefull then. Another use case is to allow to clone selected subtrees of the whole structure between worskpaces. In our application we need to clone only some selected subtrees from one workspace to another. But we can not do that because of existing references. We need to clone the whol estructure first, then remove all unwanted nodes, which is really time expensive and memory consuming. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1253) Allow to configure autoCommit mode for BundleDB PM to avoid extra overhead when working in non clustered environment
[ https://issues.apache.org/jira/browse/JCR-1253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553394 ] Przemo Pakulski commented on JCR-1253: -- Thomas, I don't think so you can see noticeable difference using DerbyPM or any other local database, you should try/test database accessible through local network. Jukka, I'm using SQL server and jtds driver, there are for sure additional network calls. Morover, in current implemntation there is also the potential risk that if setting autocommit will throw exception then we could try to commit changeLog twice. And I still don't understand how autoCommt mode of private sql connection could affect jackrabbit cluster, could anyone explain this ? Allow to configure autoCommit mode for BundleDB PM to avoid extra overhead when working in non clustered environment Key: JCR-1253 URL: https://issues.apache.org/jira/browse/JCR-1253 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Affects Versions: 1.4 Reporter: Przemo Pakulski Priority: Minor Fix For: 1.4 Attachments: single_checkin.JPG, small_change_log.JPG BundleDB PMs keeps connection open in autoCommit mode and during every store operation turn off/on this flag introducing some overhead. '... the reason is that in a clustered environment, the 'select' statements must be committed as well, otherwise the tables remain locked. and instead of explicitly commit each time after a read, we used the autocommit as default and switch it off during store ...' We could add additional parameter which allows to configure autoCommit mode, by default it could work as before, but specifing additional parameter will change the behaviour. It's hard to say about exact numbers how much overhead it is, there are to many variables (network speed/latency, db server type, jdbc driver, change log size). For sure it means 2 extra network calls, which could be easily avoided. See attached example screen from JProfiler using MSSQL server, and small change logs; overhead is about 20%. Doing simple checkin on versionable node it could be even 40%. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1253) Allow to configure autoCommit mode for BundleDB PM to avoid extra overhead when working in non clustered environment
[ https://issues.apache.org/jira/browse/JCR-1253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Przemo Pakulski updated JCR-1253: - Attachment: JCR-1253.patch Patch proposal attached which allows to set autoCommit mode and eliminate related overhead. By default autoCommit mode is still set to true, ensuring that no changes are required on existing repositories. Allow to configure autoCommit mode for BundleDB PM to avoid extra overhead when working in non clustered environment Key: JCR-1253 URL: https://issues.apache.org/jira/browse/JCR-1253 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Affects Versions: 1.4 Reporter: Przemo Pakulski Priority: Minor Fix For: 1.4 Attachments: JCR-1253.patch, single_checkin.JPG, small_change_log.JPG BundleDB PMs keeps connection open in autoCommit mode and during every store operation turn off/on this flag introducing some overhead. '... the reason is that in a clustered environment, the 'select' statements must be committed as well, otherwise the tables remain locked. and instead of explicitly commit each time after a read, we used the autocommit as default and switch it off during store ...' We could add additional parameter which allows to configure autoCommit mode, by default it could work as before, but specifing additional parameter will change the behaviour. It's hard to say about exact numbers how much overhead it is, there are to many variables (network speed/latency, db server type, jdbc driver, change log size). For sure it means 2 extra network calls, which could be easily avoided. See attached example screen from JProfiler using MSSQL server, and small change logs; overhead is about 20%. Doing simple checkin on versionable node it could be even 40%. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1277) ConnectionRecoveryManager is created twice in DBDataStore init method
ConnectionRecoveryManager is created twice in DBDataStore init method - Key: JCR-1277 URL: https://issues.apache.org/jira/browse/JCR-1277 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-core Reporter: Przemo Pakulski Priority: Trivial Fix For: 1.4 It seems that after introducing pool, old initizialization of ConnectionRecoveryManager has not been removed. Index: DbDataStore.java === --- DbDataStore.java(revision 605626) +++ DbDataStore.java(working copy) @@ -479,8 +479,6 @@ initDatabaseType(); connectionPool = new Pool(this, maxConnections); ConnectionRecoveryManager conn = getConnection(); -conn = new ConnectionRecoveryManager(false, driver, url, user, password); -conn.setAutoReconnect(true); DatabaseMetaData meta = conn.getConnection().getMetaData(); log.info(Using JDBC driver + meta.getDriverName() + + meta.getDriverVersion()); meta.getDriverVersion(); Duplicated initialization should be removed , but i've never run this code yet. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1253) Allow to configure autoCommit mode for BundleDB PM to avoid extra overhead when working in non clustered environment
Allow to configure autoCommit mode for BundleDB PM to avoid extra overhead when working in non clustered environment Key: JCR-1253 URL: https://issues.apache.org/jira/browse/JCR-1253 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Affects Versions: 1.3.3, 1.4 Reporter: Przemo Pakulski Priority: Minor Fix For: 1.4 BundleDB PMs keeps connection open in autoCommit mode and during every store operation turn off/on this flag introducing some overhead. '... the reason is that in a clustered environment, the 'select' statements must be committed as well, otherwise the tables remain locked. and instead of explicitly commit each time after a read, we used the autocommit as default and switch it off during store ...' We could add additional parameter which allows to configure autoCommit mode, by default it could work as before, but specifing additional parameter will change the behaviour. It's hard to say about exact numbers how much overhead it is, there are to many variables (network speed/latency, db server type, jdbc driver, change log size). For sure it means 2 extra network calls, which could be easily avoided. See attached example screen from JProfiler using MSSQL server, and small change logs; overhead is about 20%. Doing simple checkin on versionable node it could be even 40%. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1253) Allow to configure autoCommit mode for BundleDB PM to avoid extra overhead when working in non clustered environment
[ https://issues.apache.org/jira/browse/JCR-1253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Przemo Pakulski updated JCR-1253: - Attachment: small_change_log.html store with small change log Allow to configure autoCommit mode for BundleDB PM to avoid extra overhead when working in non clustered environment Key: JCR-1253 URL: https://issues.apache.org/jira/browse/JCR-1253 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Affects Versions: 1.3.3, 1.4 Reporter: Przemo Pakulski Priority: Minor Fix For: 1.4 Attachments: small_change_log.html BundleDB PMs keeps connection open in autoCommit mode and during every store operation turn off/on this flag introducing some overhead. '... the reason is that in a clustered environment, the 'select' statements must be committed as well, otherwise the tables remain locked. and instead of explicitly commit each time after a read, we used the autocommit as default and switch it off during store ...' We could add additional parameter which allows to configure autoCommit mode, by default it could work as before, but specifing additional parameter will change the behaviour. It's hard to say about exact numbers how much overhead it is, there are to many variables (network speed/latency, db server type, jdbc driver, change log size). For sure it means 2 extra network calls, which could be easily avoided. See attached example screen from JProfiler using MSSQL server, and small change logs; overhead is about 20%. Doing simple checkin on versionable node it could be even 40%. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1253) Allow to configure autoCommit mode for BundleDB PM to avoid extra overhead when working in non clustered environment
[ https://issues.apache.org/jira/browse/JCR-1253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Przemo Pakulski updated JCR-1253: - Attachment: small_change_log.JPG Allow to configure autoCommit mode for BundleDB PM to avoid extra overhead when working in non clustered environment Key: JCR-1253 URL: https://issues.apache.org/jira/browse/JCR-1253 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Affects Versions: 1.3.3, 1.4 Reporter: Przemo Pakulski Priority: Minor Fix For: 1.4 Attachments: single_checkin.JPG, small_change_log.JPG BundleDB PMs keeps connection open in autoCommit mode and during every store operation turn off/on this flag introducing some overhead. '... the reason is that in a clustered environment, the 'select' statements must be committed as well, otherwise the tables remain locked. and instead of explicitly commit each time after a read, we used the autocommit as default and switch it off during store ...' We could add additional parameter which allows to configure autoCommit mode, by default it could work as before, but specifing additional parameter will change the behaviour. It's hard to say about exact numbers how much overhead it is, there are to many variables (network speed/latency, db server type, jdbc driver, change log size). For sure it means 2 extra network calls, which could be easily avoided. See attached example screen from JProfiler using MSSQL server, and small change logs; overhead is about 20%. Doing simple checkin on versionable node it could be even 40%. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1253) Allow to configure autoCommit mode for BundleDB PM to avoid extra overhead when working in non clustered environment
[ https://issues.apache.org/jira/browse/JCR-1253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Przemo Pakulski updated JCR-1253: - Attachment: single_checkin.JPG Allow to configure autoCommit mode for BundleDB PM to avoid extra overhead when working in non clustered environment Key: JCR-1253 URL: https://issues.apache.org/jira/browse/JCR-1253 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Affects Versions: 1.3.3, 1.4 Reporter: Przemo Pakulski Priority: Minor Fix For: 1.4 Attachments: single_checkin.JPG, small_change_log.JPG BundleDB PMs keeps connection open in autoCommit mode and during every store operation turn off/on this flag introducing some overhead. '... the reason is that in a clustered environment, the 'select' statements must be committed as well, otherwise the tables remain locked. and instead of explicitly commit each time after a read, we used the autocommit as default and switch it off during store ...' We could add additional parameter which allows to configure autoCommit mode, by default it could work as before, but specifing additional parameter will change the behaviour. It's hard to say about exact numbers how much overhead it is, there are to many variables (network speed/latency, db server type, jdbc driver, change log size). For sure it means 2 extra network calls, which could be easily avoided. See attached example screen from JProfiler using MSSQL server, and small change logs; overhead is about 20%. Doing simple checkin on versionable node it could be even 40%. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1253) Allow to configure autoCommit mode for BundleDB PM to avoid extra overhead when working in non clustered environment
[ https://issues.apache.org/jira/browse/JCR-1253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Przemo Pakulski updated JCR-1253: - Attachment: (was: small_change_log.html) Allow to configure autoCommit mode for BundleDB PM to avoid extra overhead when working in non clustered environment Key: JCR-1253 URL: https://issues.apache.org/jira/browse/JCR-1253 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Affects Versions: 1.3.3, 1.4 Reporter: Przemo Pakulski Priority: Minor Fix For: 1.4 BundleDB PMs keeps connection open in autoCommit mode and during every store operation turn off/on this flag introducing some overhead. '... the reason is that in a clustered environment, the 'select' statements must be committed as well, otherwise the tables remain locked. and instead of explicitly commit each time after a read, we used the autocommit as default and switch it off during store ...' We could add additional parameter which allows to configure autoCommit mode, by default it could work as before, but specifing additional parameter will change the behaviour. It's hard to say about exact numbers how much overhead it is, there are to many variables (network speed/latency, db server type, jdbc driver, change log size). For sure it means 2 extra network calls, which could be easily avoided. See attached example screen from JProfiler using MSSQL server, and small change logs; overhead is about 20%. Doing simple checkin on versionable node it could be even 40%. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1253) Allow to configure autoCommit mode for BundleDB PM to avoid extra overhead when working in non clustered environment
[
https://issues.apache.org/jira/browse/JCR-1253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547849
]
Przemo Pakulski commented on JCR-1253:
--
Notice, that I marked this improvement as MINOR, it does not affect overall
performance a lot. I simply don't like switching autoCommit mode every time if
it is not really needed (2 more chances to get SQLException :-))
Here is example code you can use (change log is small):
Credentials credentials = new SimpleCredentials(admin, admin
.toCharArray());
Session session = repository.login(credentials);
Node testNode = session.getRootNode().addNode(testNode);
session.save();
for (int i = 0; i 1; i++) {
testNode.setProperty(int, i);
testNode.save();
}
session.logout();
with this test handling of autoCommit mode takes about 25% of the time of store
method, basing on profiler reports. I'm testing 1.3.3 but there is no much
difference I think.
Allow to configure autoCommit mode for BundleDB PM to avoid extra overhead
when working in non clustered environment
Key: JCR-1253
URL: https://issues.apache.org/jira/browse/JCR-1253
Project: Jackrabbit
Issue Type: Improvement
Components: jackrabbit-core
Affects Versions: 1.3.3, 1.4
Reporter: Przemo Pakulski
Priority: Minor
Fix For: 1.4
Attachments: single_checkin.JPG, small_change_log.JPG
BundleDB PMs keeps connection open in autoCommit mode and during every store
operation turn off/on this flag introducing some overhead.
'... the reason is that in a clustered environment, the 'select' statements
must be committed as well, otherwise the tables remain locked. and
instead of explicitly commit each time after a read, we used the
autocommit as default and switch it off during store ...'
We could add additional parameter which allows to configure autoCommit mode,
by default it could work as before, but specifing additional parameter will
change the behaviour.
It's hard to say about exact numbers how much overhead it is, there are to
many variables (network speed/latency, db server type, jdbc driver, change
log size). For sure it means 2 extra network calls, which could be easily
avoided.
See attached example screen from JProfiler using MSSQL server, and small
change logs; overhead is about 20%. Doing simple checkin on versionable node
it could be even 40%.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1249) Improve updating of references to version storage
Improve updating of references to version storage - Key: JCR-1249 URL: https://issues.apache.org/jira/browse/JCR-1249 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Affects Versions: 1.3.3 Reporter: Przemo Pakulski Priority: Minor Fix For: 1.4 SharedItemStateManger in Update.end() methods notify virtual providers about changed node references. For now it notifies about every changed reference separately, it results in many calls to persistence manager and makes this operation not efficient. e.g. after importing xml including 15k of versionable nodes then saving changes using bundle MSSqlPersistenceManager updating references in version storage takes 27s on my env.; after proposed change doing the same in single call takes only 6 seconds. Any objectives if i'll propose my patch here ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1242) Improve serialization of NodeReferences for BundleDB PMs
[ https://issues.apache.org/jira/browse/JCR-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546711 ] Przemo Pakulski commented on JCR-1242: -- those methods are public so we can't really tell whether they're used or not. ItemStateBinding class is internal jackrabbit class located in org.apache.jackrabbit.core.persistence.bundle.util package. I'm pretty sure that it was created especially to handle serialization in family of bundle PMs. I've checked all dependencies and none of jackrabbit classes use those methods (read/writePropertyIds). Following your approach not to change any public methods in internal jackrabbit classes, you couldn't change a lot ... sorry, i can't follow you here. you changed ItemStateBinding's serialization format but you didn't increment the version. that's IMO incorrect (and dangerous). I've changed serialization format of node references only and introduced version which is stored in first byte. Before this change node references were serialized without any version, now VERSION_1 is used and based on this difference correct deserialization is used. I could introduce VERSION_2 for node references, but it was not necessary, and backward compatibilty is still guaranteed. ItemStateBinding now assumes that Serializer had been used previously; even worse, it assumes implementation details of Serializer. that's IMO a rather nasty hack. a cleaner solution would e.g. be to extend Serializer, optimize the serialization format and maintain a version id in order to guarantee backwards compatibility. For now BundleStateBinding is used for serialization of nodes/properies while Serializer is used for serialization of node references. I think that it is overlooking, and I wanted to remove Serializer dependency at all (from bundle PMs). ItemStateBinding/BundleStateBinding classes seem to be especially created to be responsible for that. IMO, ensuring backward compatibilty is always a bit hacky, because MUST assume previously stored format (and in consequence implementation). Generally, I can agree that it is not the cleanest/perfect solution, but partially because the initial implementation wasn't perfect either (dead/unused code in ItemStateBinding, duplicated code between Serializer/ItemStateBinding classes). Improve serialization of NodeReferences for BundleDB PMs Key: JCR-1242 URL: https://issues.apache.org/jira/browse/JCR-1242 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Affects Versions: 1.3.3, 1.4 Reporter: Przemo Pakulski Priority: Minor Fix For: 1.4 Attachments: JCR-1242.patch BudleDB PMs use currently Serializer class to serialize, deserialize node references. Those methods are unefficient, it use string representation of UUID, namespaceURI and localName. For UUID rawBytes should be used and for namespaceURI, localName namespaceIndex/nameIndex should be used to improve efficiency of serialization/deserialization. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1242) Improve serialization of NodeReferences for BundleDB PMs
Improve serialization of NodeReferences for BundleDB PMs Key: JCR-1242 URL: https://issues.apache.org/jira/browse/JCR-1242 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Affects Versions: 1.3.3, 1.4 Reporter: Przemo Pakulski Fix For: 1.4 BudleDB PMs use currently Serializer class to serialize, deserialize node references. Those methods are unefficient, it use string representation of UUID, namespaceURI and localName. For UUID rawBytes should be used and for namespaceURI, localName namespaceIndex/nameIndex should be used to improve efficiency of serialization/deserialization. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1242) Improve serialization of NodeReferences for BundleDB PMs
[ https://issues.apache.org/jira/browse/JCR-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Przemo Pakulski updated JCR-1242: - Attachment: JCR-1242.patch There is already ItemStateBinding class which should be used by bundleDB PMs, instead of Serializer class. Patch attached which contains : - update of readPropertyId, writePropertyId methods, it use now IndexedQName instead of QName for se/serialization of node references - update of readState method in ItemStateBinding class to ensure backward compatibility, - fix of readState method in ItemStateBinding class to ensure that correct version is used for deserialization, - updates of affected PMs *(BundleDBPersistenceManager,BundleFSPersistenceManager, Oracle9PersistenceManager). Improve serialization of NodeReferences for BundleDB PMs Key: JCR-1242 URL: https://issues.apache.org/jira/browse/JCR-1242 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Affects Versions: 1.3.3, 1.4 Reporter: Przemo Pakulski Fix For: 1.4 Attachments: JCR-1242.patch BudleDB PMs use currently Serializer class to serialize, deserialize node references. Those methods are unefficient, it use string representation of UUID, namespaceURI and localName. For UUID rawBytes should be used and for namespaceURI, localName namespaceIndex/nameIndex should be used to improve efficiency of serialization/deserialization. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1242) Improve serialization of NodeReferences for BundleDB PMs
[ https://issues.apache.org/jira/browse/JCR-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546226 ] Przemo Pakulski commented on JCR-1242: -- With proposed patch serialization/deserializations of node references is about 2 times faster than before, it is especially important (visible) when you operate on multiple referenceable/versionable nodes. Improve serialization of NodeReferences for BundleDB PMs Key: JCR-1242 URL: https://issues.apache.org/jira/browse/JCR-1242 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Affects Versions: 1.3.3, 1.4 Reporter: Przemo Pakulski Fix For: 1.4 Attachments: JCR-1242.patch BudleDB PMs use currently Serializer class to serialize, deserialize node references. Those methods are unefficient, it use string representation of UUID, namespaceURI and localName. For UUID rawBytes should be used and for namespaceURI, localName namespaceIndex/nameIndex should be used to improve efficiency of serialization/deserialization. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1242) Improve serialization of NodeReferences for BundleDB PMs
[ https://issues.apache.org/jira/browse/JCR-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546316 ] Przemo Pakulski commented on JCR-1242: -- thanks for the review stefan : - the serialization format used by ItemStateBinding is changed, but the changes are *not* backwards compatible (see read/writePropertyId(...)). read/writePropertyIds methods have not been ever used, there is no need to ensure backward compatibility thenIte - version of new serialization format is not incremented/persisted yes it is, only method affected is writeState(DataOutputStream out, NodeReferences state), first byte contains new version (if new format wouldn't be persistent I couldn't used this solution) - the proposed changes are IMO rather 'hacky'; for example ItemStateBinding#readState(..., NodeReferencesId, ...) assumes implementation details of Serializer#serialize(NodeReferences refs, ...) that's true, but to ensure 'backward compatibility' for bundle PMs readState method must assume sumothing :-), it assumes previous implementation, what do you suggest ? Improve serialization of NodeReferences for BundleDB PMs Key: JCR-1242 URL: https://issues.apache.org/jira/browse/JCR-1242 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Affects Versions: 1.3.3, 1.4 Reporter: Przemo Pakulski Priority: Minor Fix For: 1.4 Attachments: JCR-1242.patch BudleDB PMs use currently Serializer class to serialize, deserialize node references. Those methods are unefficient, it use string representation of UUID, namespaceURI and localName. For UUID rawBytes should be used and for namespaceURI, localName namespaceIndex/nameIndex should be used to improve efficiency of serialization/deserialization. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (JCR-1242) Improve serialization of NodeReferences for BundleDB PMs
[ https://issues.apache.org/jira/browse/JCR-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546316 ] ppakulski edited comment on JCR-1242 at 11/28/07 9:51 AM: thanks for the review stefan : - the serialization format used by ItemStateBinding is changed, but the changes are *not* backwards compatible (see read/writePropertyId(...)). read/writePropertyIds methods have not been ever used, there is no need to ensure backward compatibility thenIte - version of new serialization format is not incremented/persisted yes it is, only method affected is writeState(DataOutputStream out, NodeReferences state), first byte contains new version (if new format wouldn't be persistent I couldn't use this solution) - the proposed changes are IMO rather 'hacky'; for example ItemStateBinding#readState(..., NodeReferencesId, ...) assumes implementation details of Serializer#serialize(NodeReferences refs, ...) that's true, but to ensure 'backward compatibility' for bundle PMs readState method must assume something :-), it assumes previous implementation, what do you suggest ? was (Author: ppakulski): thanks for the review stefan : - the serialization format used by ItemStateBinding is changed, but the changes are *not* backwards compatible (see read/writePropertyId(...)). read/writePropertyIds methods have not been ever used, there is no need to ensure backward compatibility thenIte - version of new serialization format is not incremented/persisted yes it is, only method affected is writeState(DataOutputStream out, NodeReferences state), first byte contains new version (if new format wouldn't be persistent I couldn't used this solution) - the proposed changes are IMO rather 'hacky'; for example ItemStateBinding#readState(..., NodeReferencesId, ...) assumes implementation details of Serializer#serialize(NodeReferences refs, ...) that's true, but to ensure 'backward compatibility' for bundle PMs readState method must assume sumothing :-), it assumes previous implementation, what do you suggest ? Improve serialization of NodeReferences for BundleDB PMs Key: JCR-1242 URL: https://issues.apache.org/jira/browse/JCR-1242 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Affects Versions: 1.3.3, 1.4 Reporter: Przemo Pakulski Priority: Minor Fix For: 1.4 Attachments: JCR-1242.patch BudleDB PMs use currently Serializer class to serialize, deserialize node references. Those methods are unefficient, it use string representation of UUID, namespaceURI and localName. For UUID rawBytes should be used and for namespaceURI, localName namespaceIndex/nameIndex should be used to improve efficiency of serialization/deserialization. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (JCR-1242) Improve serialization of NodeReferences for BundleDB PMs
[ https://issues.apache.org/jira/browse/JCR-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546316 ] ppakulski edited comment on JCR-1242 at 11/28/07 9:51 AM: thanks for the review, stefan : - the serialization format used by ItemStateBinding is changed, but the changes are *not* backwards compatible (see read/writePropertyId(...)). read/writePropertyIds methods have not been ever used, there is no need to ensure backward compatibility thenIte - version of new serialization format is not incremented/persisted yes it is, only method affected is writeState(DataOutputStream out, NodeReferences state), first byte contains new version (if new format wouldn't be persistent I couldn't use this solution) - the proposed changes are IMO rather 'hacky'; for example ItemStateBinding#readState(..., NodeReferencesId, ...) assumes implementation details of Serializer#serialize(NodeReferences refs, ...) that's true, but to ensure 'backward compatibility' for bundle PMs readState method must assume something :-), it assumes previous implementation, what do you suggest ? was (Author: ppakulski): thanks for the review stefan : - the serialization format used by ItemStateBinding is changed, but the changes are *not* backwards compatible (see read/writePropertyId(...)). read/writePropertyIds methods have not been ever used, there is no need to ensure backward compatibility thenIte - version of new serialization format is not incremented/persisted yes it is, only method affected is writeState(DataOutputStream out, NodeReferences state), first byte contains new version (if new format wouldn't be persistent I couldn't use this solution) - the proposed changes are IMO rather 'hacky'; for example ItemStateBinding#readState(..., NodeReferencesId, ...) assumes implementation details of Serializer#serialize(NodeReferences refs, ...) that's true, but to ensure 'backward compatibility' for bundle PMs readState method must assume something :-), it assumes previous implementation, what do you suggest ? Improve serialization of NodeReferences for BundleDB PMs Key: JCR-1242 URL: https://issues.apache.org/jira/browse/JCR-1242 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Affects Versions: 1.3.3, 1.4 Reporter: Przemo Pakulski Priority: Minor Fix For: 1.4 Attachments: JCR-1242.patch BudleDB PMs use currently Serializer class to serialize, deserialize node references. Those methods are unefficient, it use string representation of UUID, namespaceURI and localName. For UUID rawBytes should be used and for namespaceURI, localName namespaceIndex/nameIndex should be used to improve efficiency of serialization/deserialization. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (JCR-1242) Improve serialization of NodeReferences for BundleDB PMs
[ https://issues.apache.org/jira/browse/JCR-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546316 ] ppakulski edited comment on JCR-1242 at 11/28/07 9:54 AM: thanks for the review, stefan : - the serialization format used by ItemStateBinding is changed, but the changes are *not* backwards compatible (see read/writePropertyId(...)). read/writePropertyIds methods have not been ever used, there is no need to ensure backward compatibility - version of new serialization format is not incremented/persisted yes it is, only method affected is writeState(DataOutputStream out, NodeReferences state), first byte contains new version (if new format wouldn't be persistent I couldn't use this solution) - the proposed changes are IMO rather 'hacky'; for example ItemStateBinding#readState(..., NodeReferencesId, ...) assumes implementation details of Serializer#serialize(NodeReferences refs, ...) that's true, but to ensure 'backward compatibility' for bundle PMs readState method must assume something :-), it assumes previous implementation, what do you suggest ? double wrapping of DataOutputStream's (i guess that's just an oversight) yes, double wrapping is a oversight, I originally prepared the patch for 1.3 branch (it's the version i'm currently using) was (Author: ppakulski): thanks for the review, stefan : - the serialization format used by ItemStateBinding is changed, but the changes are *not* backwards compatible (see read/writePropertyId(...)). read/writePropertyIds methods have not been ever used, there is no need to ensure backward compatibility thenIte - version of new serialization format is not incremented/persisted yes it is, only method affected is writeState(DataOutputStream out, NodeReferences state), first byte contains new version (if new format wouldn't be persistent I couldn't use this solution) - the proposed changes are IMO rather 'hacky'; for example ItemStateBinding#readState(..., NodeReferencesId, ...) assumes implementation details of Serializer#serialize(NodeReferences refs, ...) that's true, but to ensure 'backward compatibility' for bundle PMs readState method must assume something :-), it assumes previous implementation, what do you suggest ? double wrapping of DataOutputStream's (i guess that's just an oversight) yes, double wrapping is a oversight, I originally prepared the patch for 1.3 branch (it's the version i'm currently using) Improve serialization of NodeReferences for BundleDB PMs Key: JCR-1242 URL: https://issues.apache.org/jira/browse/JCR-1242 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Affects Versions: 1.3.3, 1.4 Reporter: Przemo Pakulski Priority: Minor Fix For: 1.4 Attachments: JCR-1242.patch BudleDB PMs use currently Serializer class to serialize, deserialize node references. Those methods are unefficient, it use string representation of UUID, namespaceURI and localName. For UUID rawBytes should be used and for namespaceURI, localName namespaceIndex/nameIndex should be used to improve efficiency of serialization/deserialization. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (JCR-1242) Improve serialization of NodeReferences for BundleDB PMs
[ https://issues.apache.org/jira/browse/JCR-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546316 ] ppakulski edited comment on JCR-1242 at 11/28/07 9:53 AM: thanks for the review, stefan : - the serialization format used by ItemStateBinding is changed, but the changes are *not* backwards compatible (see read/writePropertyId(...)). read/writePropertyIds methods have not been ever used, there is no need to ensure backward compatibility thenIte - version of new serialization format is not incremented/persisted yes it is, only method affected is writeState(DataOutputStream out, NodeReferences state), first byte contains new version (if new format wouldn't be persistent I couldn't use this solution) - the proposed changes are IMO rather 'hacky'; for example ItemStateBinding#readState(..., NodeReferencesId, ...) assumes implementation details of Serializer#serialize(NodeReferences refs, ...) that's true, but to ensure 'backward compatibility' for bundle PMs readState method must assume something :-), it assumes previous implementation, what do you suggest ? double wrapping of DataOutputStream's (i guess that's just an oversight) yes, double wrapping is a oversight, I originally prepared the patch for 1.3 branch (it's the version i'm currently using) was (Author: ppakulski): thanks for the review, stefan : - the serialization format used by ItemStateBinding is changed, but the changes are *not* backwards compatible (see read/writePropertyId(...)). read/writePropertyIds methods have not been ever used, there is no need to ensure backward compatibility thenIte - version of new serialization format is not incremented/persisted yes it is, only method affected is writeState(DataOutputStream out, NodeReferences state), first byte contains new version (if new format wouldn't be persistent I couldn't use this solution) - the proposed changes are IMO rather 'hacky'; for example ItemStateBinding#readState(..., NodeReferencesId, ...) assumes implementation details of Serializer#serialize(NodeReferences refs, ...) that's true, but to ensure 'backward compatibility' for bundle PMs readState method must assume something :-), it assumes previous implementation, what do you suggest ? Improve serialization of NodeReferences for BundleDB PMs Key: JCR-1242 URL: https://issues.apache.org/jira/browse/JCR-1242 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Affects Versions: 1.3.3, 1.4 Reporter: Przemo Pakulski Priority: Minor Fix For: 1.4 Attachments: JCR-1242.patch BudleDB PMs use currently Serializer class to serialize, deserialize node references. Those methods are unefficient, it use string representation of UUID, namespaceURI and localName. For UUID rawBytes should be used and for namespaceURI, localName namespaceIndex/nameIndex should be used to improve efficiency of serialization/deserialization. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1197) ItemManager cache is getting out of sync
[ https://issues.apache.org/jira/browse/JCR-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544795 ] Przemo Pakulski commented on JCR-1197: -- There is definitely problem with modCount attribute of ItemState. During each save this attribute is incremented by SharedItemStateManager, but sometimes after restore ItemState holded by Items in ItemManager cache still has different (old) valueo modCount. Then during next save operation exception is thrown. ItemManager cache is getting out of sync Key: JCR-1197 URL: https://issues.apache.org/jira/browse/JCR-1197 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-core Affects Versions: 1.3.3, 1.4 Reporter: Przemo Pakulski Priority: Critical Fix For: 1.4 Attachments: CheckoutFailure.java It seems that ItemManager cache is not maintained correctly. I'm getting InvalidItemStateException: 'propertyId' has been modified externally tryin restore/checkout versionable nodes in single thread. ItemState should be evicted from ItemStateManager cache when modified, it seems that status of ItemState is changed to MODIFIED, but itemState remains in the cache. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1227) Restore of empty multivalue property always changes property type to String
[ https://issues.apache.org/jira/browse/JCR-1227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Przemo Pakulski updated JCR-1227: - Affects Version/s: 1.4 Restore of empty multivalue property always changes property type to String --- Key: JCR-1227 URL: https://issues.apache.org/jira/browse/JCR-1227 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-core Affects Versions: 1.3.3, 1.4 Reporter: Tomek Dabrowski Attachments: restoreMultvalueProp.patch When you do a restore of empty multivalue property (OPV=COPY), restored property always has the String type (no matter of property type in frozen state). The solution is to set the property type from frozen state instead of retriving it from 'first' value. If mulitvalue does not have any values the type is set to UNDEFINED and finally changed to STRING in restore method. Attached patch with test case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1209) NodeImpl.checkot() calls save() two times
[ https://issues.apache.org/jira/browse/JCR-1209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12541273 ] Przemo Pakulski commented on JCR-1209: -- hm, I forgot that Node.save() method saves changes on the whole subtree. We could check if node has pending changes, if not call save once on node otherwise call save twice on properties level, but i'm not sure if it makes sense. NodeImpl.checkot() calls save() two times - Key: JCR-1209 URL: https://issues.apache.org/jira/browse/JCR-1209 Project: Jackrabbit Issue Type: Improvement Components: versioning Affects Versions: 1.3.3, 1.4 Reporter: Przemo Pakulski Priority: Minor Fix For: 1.4 Similar to JCR-975, The version related properties on a versionable node that is checked out are saved individually. There is no need to save them individually because checkd in node must not have pending changes and save() can be called safely on the node itself. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1197) ItemManager cache is getting out of sync
[
https://issues.apache.org/jira/browse/JCR-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12541292
]
Przemo Pakulski commented on JCR-1197:
--
Actually ItemManager is notified on ItemState changes (proper methods
stateModifeid, stateDiscarded are called), but those methods do not invalidate
the ItemManager cache.
I tried do evict item from cache in ItemManager by adding single line :
public void stateModified(ItemState modified) {
ItemImpl item = retrieveItem(modified.getId());
if (item != null) {
item.stateModified(modified);
+evictItem(modified.getId());
}
}
but it doesn't work, seems that observation mechanism (triggered after
disposing transient states, during stateMgr.update) needs this data still to
work properly.
Here is exception, after adding evict() in stateModified method :
Caused by: org.apache.jackrabbit.core.state.ItemStateException: Unable to
resolve path for item:
b0ec45fd-cf39-4ab5-bcd0-a8e95d06008f/{http://www.jcp.org/jcr/1.0}predecessors
at
org.apache.jackrabbit.core.observation.EventStateCollection.getPath(EventStateCollection.java:520)
at
org.apache.jackrabbit.core.observation.EventStateCollection.createEventStates(EventStateCollection.java:385)
at
org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:655)
at
org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:826)
at
org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:856)
at
org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:324)
at
org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:313)
at
org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:300)
at
org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:306)
at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1244)
ItemManager cache is getting out of sync
Key: JCR-1197
URL: https://issues.apache.org/jira/browse/JCR-1197
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-core
Affects Versions: 1.3.3, 1.4
Reporter: Przemo Pakulski
Priority: Critical
Fix For: 1.4
Attachments: CheckoutFailure.java
It seems that ItemManager cache is not maintained correctly. I'm getting
InvalidItemStateException: 'propertyId' has been modified externally tryin
restore/checkout versionable nodes in single thread.
ItemState should be evicted from ItemStateManager cache when modified, it
seems that status of ItemState is changed to MODIFIED, but itemState remains
in the cache.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1209) NodeImpl.checkot() calls save() two times
[ https://issues.apache.org/jira/browse/JCR-1209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12541293 ] Przemo Pakulski commented on JCR-1209: -- The idea was to speed up versioning operations like checkin/checkout I'll revert the changes for now. NodeImpl.checkot() calls save() two times - Key: JCR-1209 URL: https://issues.apache.org/jira/browse/JCR-1209 Project: Jackrabbit Issue Type: Improvement Components: versioning Affects Versions: 1.3.3, 1.4 Reporter: Przemo Pakulski Priority: Minor Fix For: 1.4 Similar to JCR-975, The version related properties on a versionable node that is checked out are saved individually. There is no need to save them individually because checkd in node must not have pending changes and save() can be called safely on the node itself. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1111) Accesss to version history results in reading all versions of versionable node
[ https://issues.apache.org/jira/browse/JCR-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12541025 ] Przemo Pakulski commented on JCR-: -- Well, you are right, I didn't give any chance to review it by anyone :-(. I can say that all test passes and I was working with this fix for some time. Accesss to version history results in reading all versions of versionable node -- Key: JCR- URL: https://issues.apache.org/jira/browse/JCR- Project: Jackrabbit Issue Type: Improvement Components: versioning Affects Versions: 1.4 Reporter: Przemo Pakulski Fix For: 1.4 Attachments: JCR-.patch InternalVersionHistoryImpl loads all versions at once during initialization. Because of that all versioning operations (incl. checkin, label, restore) are significantly slower when node has many versions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1197) ItemManager cache is getting out of sync
[ https://issues.apache.org/jira/browse/JCR-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12540799 ] Przemo Pakulski commented on JCR-1197: -- Marcel, after applying your fix Jackrabbit tests passes, but my application tests don't. It seems that by removing this line some events can be missed, and index is not rebuilt correclty (node can be indexed twice after restore). I think that problem is with caches that are not maintained correctly. I've tried to evict items from ItemManager cache during save(), but is hard to understand dependencies between all the caches, and I encountered another problem with dispatchindevents and HierarchyManager. ItemManager cache is getting out of sync Key: JCR-1197 URL: https://issues.apache.org/jira/browse/JCR-1197 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-core Affects Versions: 1.3.3, 1.4 Reporter: Przemo Pakulski Priority: Critical Fix For: 1.4 Attachments: CheckoutFailure.java It seems that ItemManager cache is not maintained correctly. I'm getting InvalidItemStateException: 'propertyId' has been modified externally tryin restore/checkout versionable nodes in single thread. ItemState should be evicted from ItemStateManager cache when modified, it seems that status of ItemState is changed to MODIFIED, but itemState remains in the cache. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1197) ItemManager cache is getting out of sync
[ https://issues.apache.org/jira/browse/JCR-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12540790 ] Przemo Pakulski commented on JCR-1197: -- There is a lot of layers in Jackrabbit, and almost each layer has own cache. It seems that caches are not invalidated properly. During save() method on ItemImpl transient item states are disposed from SessionItemStateManager, but it seems than ItemManager cache is not invalidated. Sometimes it works because ItemManager uses weak references, but in some cases it is causing problems like this. To make it work I needed to put such line : ((SessionImpl)session).getItemManager().dispose(); between restore and checkout in our code. This line clears ItemManager cache completely. ItemManager cache is getting out of sync Key: JCR-1197 URL: https://issues.apache.org/jira/browse/JCR-1197 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-core Affects Versions: 1.3.3, 1.4 Reporter: Przemo Pakulski Priority: Critical Fix For: 1.4 Attachments: CheckoutFailure.java It seems that ItemManager cache is not maintained correctly. I'm getting InvalidItemStateException: 'propertyId' has been modified externally tryin restore/checkout versionable nodes in single thread. ItemState should be evicted from ItemStateManager cache when modified, it seems that status of ItemState is changed to MODIFIED, but itemState remains in the cache. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1111) Accesss to version history results in reading all versions of versionable node
[ https://issues.apache.org/jira/browse/JCR-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Przemo Pakulski resolved JCR-. -- Resolution: Fixed Fix Version/s: 1.4 patch applied in rev. 592947 Accesss to version history results in reading all versions of versionable node -- Key: JCR- URL: https://issues.apache.org/jira/browse/JCR- Project: Jackrabbit Issue Type: Improvement Components: versioning Affects Versions: 1.4 Reporter: Przemo Pakulski Fix For: 1.4 Attachments: JCR-.patch InternalVersionHistoryImpl loads all versions at once during initialization. Because of that all versioning operations (incl. checkin, label, restore) are significantly slower when node has many versions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1209) NodeImpl.checkot() calls save() two times
NodeImpl.checkot() calls save() two times - Key: JCR-1209 URL: https://issues.apache.org/jira/browse/JCR-1209 Project: Jackrabbit Issue Type: Improvement Components: versioning Affects Versions: 1.3.3, 1.4 Reporter: Przemo Pakulski Priority: Minor Fix For: 1.4 Similar to JCR-975, The version related properties on a versionable node that is checked out are saved individually. There is no need to save them individually because checkd in node must not have pending changes and save() can be called safely on the node itself. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1209) NodeImpl.checkot() calls save() two times
[ https://issues.apache.org/jira/browse/JCR-1209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Przemo Pakulski resolved JCR-1209. -- Resolution: Fixed Fixed in revision: 592957 NodeImpl.checkot() calls save() two times - Key: JCR-1209 URL: https://issues.apache.org/jira/browse/JCR-1209 Project: Jackrabbit Issue Type: Improvement Components: versioning Affects Versions: 1.3.3, 1.4 Reporter: Przemo Pakulski Priority: Minor Fix For: 1.4 Similar to JCR-975, The version related properties on a versionable node that is checked out are saved individually. There is no need to save them individually because checkd in node must not have pending changes and save() can be called safely on the node itself. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1111) Accesss to version history results in reading all versions of versionable node
Accesss to version history results in reading all versions of versionable node -- Key: JCR- URL: https://issues.apache.org/jira/browse/JCR- Project: Jackrabbit Issue Type: Improvement Components: versioning Affects Versions: 1.4 Reporter: Przemo Pakulski InternalVersionHistoryImpl loads all versions at once during initialization. Because of that all versioning operations (incl. checkin, label, restore) are significantly slower when node has many versions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1111) Accesss to version history results in reading all versions of versionable node
[ https://issues.apache.org/jira/browse/JCR-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524767 ] Przemo Pakulski commented on JCR-: -- I'm working on patch to load versions when it is needed only. Accesss to version history results in reading all versions of versionable node -- Key: JCR- URL: https://issues.apache.org/jira/browse/JCR- Project: Jackrabbit Issue Type: Improvement Components: versioning Affects Versions: 1.4 Reporter: Przemo Pakulski InternalVersionHistoryImpl loads all versions at once during initialization. Because of that all versioning operations (incl. checkin, label, restore) are significantly slower when node has many versions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1112) CacheManager interval between recalculation of cache sizes should be configurable
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 Affects Versions: 1.4 Reporter: Przemo Pakulski Priority: Minor 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.
[jira] Updated: (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:all-tabpanel ] Przemo Pakulski updated JCR-1112: - Attachment: JCR-1112.txt Attached simple patch which allows to set the interval programmatically, and change the default interval to 10 seconds. 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 Affects Versions: 1.4 Reporter: Przemo Pakulski 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.
[jira] Commented: (JCR-954) Allow to disable referential integrity checking for workspace
[ https://issues.apache.org/jira/browse/JCR-954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500355 ] Przemo Pakulski commented on JCR-954: - I can agree that such feature is rather workaround, but this solution is quick and really works. As I wrote it will be not recommended to use it, it is only for experience JCR users which will be aware of any possible drawbacks. From other point of view using any relational database you can also temporarly disable constraint checking to speedup some bulk operations, then enable it again. And in some cases it is very helpfull. references are a core feature of jsr-170 which imo must not be compromised through public api methods. I dot't need it exposed through public API. What I need is to have some methods which I can call on any component (could be RepositoryImpl, or WorkspaceImpl). For now we have implemented this by extending SISM class and overriding some methods. But then our code is depenedent on Jackrabbit, and could stop work with newest versions. Consider a big subtree of items (1 mio items, eg.), which you might want to delete. Just switching off integrity checks does not help here I think it helps, because you can remove tree in steps without worrying about references. we should address the real issue instead. I really agree with you, but changing this could mean redesigning of jackrabbit core and it does not look that it could happen in the near future. Stefan, Felix, could you recommend any other feasible solution for my use cases? Allow to disable referential integrity checking for workspace - Key: JCR-954 URL: https://issues.apache.org/jira/browse/JCR-954 Project: Jackrabbit Issue Type: New Feature Components: core Reporter: Przemo Pakulski Fix For: 1.4 Attachments: JCR-954-patch.txt Some operations like clone, remove operating on huge subtree of nodes requires a lot of memory. To copy, clone, remove subtree all nodes are loaded into transient spaces. It allows such operations to be transactional, from other side it requires a lot of heap size and this memory size is directly dependent on the size of subtree (number of nodes). In result of this in some cases it is impossible to make such operations in one step. In our environment sometimes 1 GB of java heap is not enough to succesfully clone subtree from one workspace to another. You can always clone (copy, remove) tree in chunks, but if you have references between subtrees such approach fails. Possibilty of temporary disabling referential integrity checking for experienced JCR user could be very usefull then. Another use case is to allow to clone selected subtrees of the whole structure between worskpaces. In our application we need to clone only some selected subtrees from one workspace to another. But we can not do that because of existing references. We need to clone the whol estructure first, then remove all unwanted nodes, which is really time expensive and memory consuming. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-954) Allow to disable referential integrity checking for workspace
Allow to disable referential integrity checking for workspace - Key: JCR-954 URL: https://issues.apache.org/jira/browse/JCR-954 Project: Jackrabbit Issue Type: New Feature Components: core Reporter: Przemo Pakulski Fix For: 1.4 Some operations like clone, remove operating on huge subtree of nodes requires a lot of memory. To copy, clone, remove subtree all nodes are loaded into transient spaces. It allows such operations to be transactional, from other side it requires a lot of heap size and this memory size is directly dependent on the size of subtree (number of nodes). In result of this in some cases it is impossible to make such operations in one step. In our environment sometimes 1 GB of java heap is not enough to succesfully clone subtree from one workspace to another. You can always clone (copy, remove) tree in chunks, but if you have references between subtrees such approach fails. Possibilty of temporary disabling referential integrity checking for experienced JCR user could be very usefull then. Another use case is to allow to clone selected subtrees of the whole structure between worskpaces. In our application we need to clone only some selected subtrees from one workspace to another. But we can not do that because of existing references. We need to clone the whol estructure first, then remove all unwanted nodes, which is really time expensive and memory consuming. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-832) BundleDBPersistenceManager does not free blobStore resources
[
https://issues.apache.org/jira/browse/JCR-832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Przemo Pakulski updated JCR-832:
Attachment: JCR-832-patch.txt
Attached patch proposal. Abstract method destroy(PropertyState) added to
AbstractBundlePM and called during store. Method implemented in BundleDB PM to
ensure that blob resources are removed from underlying blobstore.
Not sure if something needs to be done in BundleFS PM, so method remains empty
there.
BundleDBPersistenceManager does not free blobStore resources
Key: JCR-832
URL: https://issues.apache.org/jira/browse/JCR-832
Project: Jackrabbit
Issue Type: Bug
Components: core
Affects Versions: 1.3
Reporter: Przemo Pakulski
Assignee: Tobias Bocanegra
Attachments: JCR-832-patch.txt
When removing binary property from node or removing node containing binary
property, resources occupied by binary property are not freed (orphaned
records remains in associated ${schemaObjectPrefix}BINVAL table).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-832) BundleDBPersistenceManager does not free blobStore resources
BundleDBPersistenceManager does not free blobStore resources
Key: JCR-832
URL: https://issues.apache.org/jira/browse/JCR-832
Project: Jackrabbit
Issue Type: Bug
Components: core
Affects Versions: 1.2.3
Reporter: Przemo Pakulski
When removing binary property from node or removing node containing binary
property, resources occupied by binary property are not freed (orphaned records
remains in associated ${schemaObjectPrefix}BINVAL table).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-832) BundleDBPersistenceManager does not free blobStore resources
[
https://issues.apache.org/jira/browse/JCR-832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Przemo Pakulski updated JCR-832:
Affects Version/s: (was: 1.2.3)
1.3
BundleDBPersistenceManager does not free blobStore resources
Key: JCR-832
URL: https://issues.apache.org/jira/browse/JCR-832
Project: Jackrabbit
Issue Type: Bug
Components: core
Affects Versions: 1.3
Reporter: Przemo Pakulski
When removing binary property from node or removing node containing binary
property, resources occupied by binary property are not freed (orphaned
records remains in associated ${schemaObjectPrefix}BINVAL table).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-720) TCK: NodeReadMethodsTest#testGetPrimaryItemItemNotFoundException selects wrong test data
TCK: NodeReadMethodsTest#testGetPrimaryItemItemNotFoundException selects wrong test data Key: JCR-720 URL: https://issues.apache.org/jira/browse/JCR-720 Project: Jackrabbit Issue Type: Bug Components: JCR TCK Reporter: Przemo Pakulski Method locateNodeWithoutPrimaryItem is used to locate recursively node which does not define a primary item, but this method calls internally locateNodeWithPrimaryItem instead of locateNodeWithoutPrimaryItem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-720) TCK: NodeReadMethodsTest#testGetPrimaryItemItemNotFoundException selects wrong test data
[ https://issues.apache.org/jira/browse/JCR-720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Przemo Pakulski updated JCR-720: Attachment: JCR-720-patch.txt Simple patch attached. TCK: NodeReadMethodsTest#testGetPrimaryItemItemNotFoundException selects wrong test data Key: JCR-720 URL: https://issues.apache.org/jira/browse/JCR-720 Project: Jackrabbit Issue Type: Bug Components: JCR TCK Reporter: Przemo Pakulski Attachments: JCR-720-patch.txt Method locateNodeWithoutPrimaryItem is used to locate recursively node which does not define a primary item, but this method calls internally locateNodeWithPrimaryItem instead of locateNodeWithoutPrimaryItem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-631) Change resources sequence during transaction commit.
[
http://issues.apache.org/jira/browse/JCR-631?page=comments#action_12458405 ]
Przemo Pakulski commented on JCR-631:
-
I simply tried to reaarange order of commits by swapping stateMgr and
versionMgr in txResources array (XASessionImpl class) :
txResources = new InternalXAResource[] {
((XAWorkspace) wsp).getXAResourceBegin(),
stateMgr, lockMgr, versionMgr,
((XAWorkspace) wsp).getXAResourceEnd()
};
But, after this change some tests using transactions fails (there is low level
failure when tests trying to cleanup testroot node).
Is there any evident reason why this sequence couldn't be changed ?
Change resources sequence during transaction commit.
Key: JCR-631
URL: http://issues.apache.org/jira/browse/JCR-631
Project: Jackrabbit
Issue Type: Improvement
Affects Versions: 1.0, 1.0.1, 1.1, 0.9
Reporter: Przemo Pakulski
It seems that during commmit of transaction first changes in version storage
are committed, followed by workspace changes.
If second transaction fail it leads to situation where some nodes in
workspace could have reference (base version for example) to nonexistenst
version in version storage. In such case this node is corrupted, cannot be
checked in anymore :-(.
Long term solution is make versioning operation fully transactional (see
JCR-630). In short term I think it is worth to change sequence of commit
operations on different resources to stores changes in version storage before
workspace changes.
It would be better to have some redundant data in version storage (not
referenced version) than broken reference in workspace I think.
Any comments ? Does it make sense ?
--
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-529) New versions added after a restore have bad version name
[ http://issues.apache.org/jira/browse/JCR-529?page=comments#action_12458415 ] Przemo Pakulski commented on JCR-529: - It seems that after applying patch test org.apache.jackrabbit.core.XATest.#testXAVersionsThoroughly fails. junit.framework.ComparisonFailure: checkin N1 uncommitted. Version Name expected:1.1.1 but was:1.0.1 at junit.framework.Assert.assertEquals(Assert.java:81) at org.apache.jackrabbit.core.XATest.check(XATest.java:1140) at org.apache.jackrabbit.core.XATest.testXAVersionsThoroughly(XATest.java:1080) 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 org.apache.jackrabbit.core.XATest.runTest(XATest.java:96) 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.RemoteTestRunner.runTests(RemoteTestRunner.java:474) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:342) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:194) New versions added after a restore have bad version name Key: JCR-529 URL: http://issues.apache.org/jira/browse/JCR-529 Project: Jackrabbit Issue Type: Bug Components: versioning Environment: Ubuntu Dapper Reporter: Paco Avila Assigned To: Tobias Bocanegra Attachments: AbstractVersionManager.diff, DummyVersion.java I add several versions to a node (1.0, 1.1, 1.2, 1.3, 1.4). Perform a restore to version 1.2 and add more versions. After that VersionHistory is like this: - 1.0 - 1.1 - 1.2 - 1.3 - 1.4 - 1.3.1 - 1.3.2 - 1.3.3 - 1.3.4 - 1.3.5 New versions should be 1.2.x no 1.3.x, isn't it? -- 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-672) Deadlock on concurrent save/checkin operations possible
[ http://issues.apache.org/jira/browse/JCR-672?page=comments#action_12457707 ] Przemo Pakulski commented on JCR-672: - It is occuring in trunk. I have checked 1.1 by accident then I couldn't change this ... Deadlock on concurrent save/checkin operations possible --- Key: JCR-672 URL: http://issues.apache.org/jira/browse/JCR-672 Project: Jackrabbit Issue Type: Bug Components: versioning Affects Versions: 1.1 Reporter: Przemo Pakulski Save and checkin operations are trying to acquire 2 locks in different order, what leads to deadlock. -save 1.SharedItemStateManager.acquireWriteLock 2.AbstractVersionManager.acquireWriteLock - locked -checkin 1.AbstractVersionManager.acquireWriteLock 2.SharedItemStateManager.acquireReadLock - locked Thread-4 prio=6 tid=0x0312d840 nid=0x824 in Object.wait() [0x03cef000..0x03cefa68] at java.lang.Object.wait(Native Method) - waiting on 0x23210968 (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock) at java.lang.Object.wait(Unknown Source) at EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock.acquire(Unknown Source) - locked 0x23210968 (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock) at org.apache.jackrabbit.core.version.AbstractVersionManager.acquireWriteLock(AbstractVersionManager.java:124) at org.apache.jackrabbit.core.version.VersionManagerImpl.setNodeReferences(VersionManagerImpl.java:413) at org.apache.jackrabbit.core.version.VersionItemStateProvider.setNodeReferences(VersionItemStateProvider.java:125) at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:699) at org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:810) at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:326) at org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:313) at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:302) at org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:295) at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1204) - locked 0x2332eaa0 (a org.apache.jackrabbit.core.XASessionImpl) at JrTestDeadlock.run(JrTestDeadlock.java:87) Thread-3 prio=6 tid=0x0312db18 nid=0xa04 in Object.wait() [0x03caf000..0x03cafae8] at java.lang.Object.wait(Native Method) - waiting on 0x232d1360 (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock) at java.lang.Object.wait(Unknown Source) at EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock.acquire(Unknown Source) - locked 0x232d1360 (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock) at org.apache.jackrabbit.core.state.SharedItemStateManager.acquireReadLock(SharedItemStateManager.java:1361) at org.apache.jackrabbit.core.state.SharedItemStateManager.hasItemState(SharedItemStateManager.java:270) at org.apache.jackrabbit.core.state.LocalItemStateManager.hasItemState(LocalItemStateManager.java:180) at org.apache.jackrabbit.core.state.XAItemStateManager.hasItemState(XAItemStateManager.java:252) at org.apache.jackrabbit.core.state.SessionItemStateManager.hasItemState(SessionItemStateManager.java:188) at org.apache.jackrabbit.core.ItemManager.itemExists(ItemManager.java:256) at org.apache.jackrabbit.core.NodeImpl.hasProperty(NodeImpl.java:1509) at org.apache.jackrabbit.core.version.InternalFrozenNodeImpl.checkin(InternalFrozenNodeImpl.java:276) at org.apache.jackrabbit.core.version.InternalFrozenNodeImpl.checkin(InternalFrozenNodeImpl.java:248) at org.apache.jackrabbit.core.version.InternalVersionHistoryImpl.checkin(InternalVersionHistoryImpl.java:440) at org.apache.jackrabbit.core.version.AbstractVersionManager.checkin(AbstractVersionManager.java:397) at org.apache.jackrabbit.core.version.VersionManagerImpl$2.run(VersionManagerImpl.java:289) at org.apache.jackrabbit.core.version.VersionManagerImpl$DynamicESCFactory.doSourced(VersionManagerImpl.java:611) - locked 0x2320c5d8 (a org.apache.jackrabbit.core.version.VersionManagerImpl$DynamicESCFactory) at org.apache.jackrabbit.core.version.VersionManagerImpl.checkin(VersionManagerImpl.java:285) at org.apache.jackrabbit.core.version.XAVersionManager.checkin(XAVersionManager.java:161) at org.apache.jackrabbit.core.NodeImpl.checkin(NodeImpl.java:2944) at
[jira] Updated: (JCR-352) Upgrade to Lucene 2.0
[ http://issues.apache.org/jira/browse/JCR-352?page=all ] Przemo Pakulski updated JCR-352: Attachment: updated-lucene2.patch Attached updated lucene2 patch. Patch had to be updated because of recent changes in indexing. Patch contains also fix for issues raised by Topi and Marcel . Since maven2 is used as build system it could be applied I think. Upgrade to Lucene 2.0 - Key: JCR-352 URL: http://issues.apache.org/jira/browse/JCR-352 Project: Jackrabbit Issue Type: Improvement Components: indexing Affects Versions: 1.0, 0.9, 1.0.1 Environment: All Reporter: Michael Young Assigned To: Jukka Zitting Priority: Minor Fix For: 1.2 Attachments: lucene2-pom.xml.patch, lucene2-project.xml.patch, lucene2.patch, updated-lucene2.patch We would like to upgrade to Lucene 1.9.1. There are jar conflicts when integrating with other projects such as Liferay Portal -- which uses v 1.9.1. -- 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-631) Change resources sequence during transaction commit.
Change resources sequence during transaction commit. Key: JCR-631 URL: http://issues.apache.org/jira/browse/JCR-631 Project: Jackrabbit Issue Type: Improvement Affects Versions: 0.9, 1.0, 1.0.1, 1.1 Reporter: Przemo Pakulski It seems that during commmit of transaction first changes in version storage are committed, followed by workspace changes. If second transaction fail it leads to situation where some nodes in workspace could have reference (base version for example) to nonexistenst version in version storage. In such case this node is corrupted, cannot be checked in anymore :-(. Long term solution is make versioning operation fully transactional (see JCR-630). In short term I think it is worth to change sequence of commit operations on different resources to stores changes in version storage before workspace changes. It would be better to have some redundant data in version storage (not referenced version) than broken reference in workspace I think. Any comments ? Does it make sense ? -- 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-631) Change resources sequence during transaction commit.
[ http://issues.apache.org/jira/browse/JCR-631?page=comments#action_12448719 ] Przemo Pakulski commented on JCR-631: - Sorry, i've made a mistake in first sentence. Should be : It seems that during commmit of transaction first changes in workspace are committed, followed by version storage changes. Change resources sequence during transaction commit. Key: JCR-631 URL: http://issues.apache.org/jira/browse/JCR-631 Project: Jackrabbit Issue Type: Improvement Affects Versions: 1.0, 1.0.1, 1.1, 0.9 Reporter: Przemo Pakulski It seems that during commmit of transaction first changes in version storage are committed, followed by workspace changes. If second transaction fail it leads to situation where some nodes in workspace could have reference (base version for example) to nonexistenst version in version storage. In such case this node is corrupted, cannot be checked in anymore :-(. Long term solution is make versioning operation fully transactional (see JCR-630). In short term I think it is worth to change sequence of commit operations on different resources to stores changes in version storage before workspace changes. It would be better to have some redundant data in version storage (not referenced version) than broken reference in workspace I think. Any comments ? Does it make sense ? -- 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-632) VersionManager lock not released in some circumstances
VersionManager lock not released in some circumstances
--
Key: JCR-632
URL: http://issues.apache.org/jira/browse/JCR-632
Project: Jackrabbit
Issue Type: Bug
Reporter: Przemo Pakulski
Priority: Critical
In some circumstances it is possible that lock is not released in
VersionManager.checkin method.
There is following block of code in checkin nethod :
aquireReadLock();
try {
.
} catch (IllegalStateException e) {
releaseReadLock();
throw new RepositoryException(Unable to start edit operation.);
}
Lock release should be in finally block to make sure that lock is released when
unexpected exception is thrown.
In our environment we are getting NPE in mentioned block of code, it results in
persisten lock.
No versioning operation is possible and our application server is running ot of
threads (all threads are locked).
--
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-595) Refactoring of the Persistence Managers
[ http://issues.apache.org/jira/browse/JCR-595?page=comments#action_12445876 ] Przemo Pakulski commented on JCR-595: - DatabasePersistenceManagers kept for compatibility (in old org.apache.jackrabbit.core.state.db package) doesn't work longer. Following exception is thrown during initailization of repository (file with schema cannot be found) : Testcase: testFillInSearchData(org.apache.jackrabbit.init.QueryTestData): Caused an ERROR Failed to get Repository instance.: javax.jcr.RepositoryException: Cannot instantiate persistence manager org.apache.jackrabbit.core.state.db.DerbyPersistenceManager: Configuration error: unknown schema 'derby': Configuration error: unknown schema 'derby' javax.jcr.RepositoryException: Failed to get Repository instance.: javax.jcr.RepositoryException: Cannot instantiate persistence manager org.apache.jackrabbit.core.state.db.DerbyPersistenceManager: Configuration error: unknown schema 'derby': Configuration error: unknown schema 'derby': javax.jcr.RepositoryException: Cannot instantiate persistence manager org.apache.jackrabbit.core.state.db.DerbyPersistenceManager: Configuration error: unknown schema 'derby': Configuration error: unknown schema 'derby' at org.apache.jackrabbit.test.RepositoryHelper.getRepository(RepositoryHelper.java:70) at org.apache.jackrabbit.test.RepositoryHelper.getProperty(RepositoryHelper.java:150) at org.apache.jackrabbit.test.AbstractJCRTest.getProperty(AbstractJCRTest.java:429) at org.apache.jackrabbit.test.AbstractJCRTest.setUp(AbstractJCRTest.java:254) at org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:393) Caused by: org.apache.jackrabbit.test.RepositoryStubException: javax.jcr.RepositoryException: Cannot instantiate persistence manager org.apache.jackrabbit.core.state.db.DerbyPersistenceManager: Configuration error: unknown schema 'derby': Configuration error: unknown schema 'derby' at org.apache.jackrabbit.core.JackrabbitRepositoryStub.getRepository(JackrabbitRepositoryStub.java:112) at org.apache.jackrabbit.test.RepositoryHelper.getRepository(RepositoryHelper.java:68) ... 15 more org.apache.jackrabbit.test.RepositoryStubException: javax.jcr.RepositoryException: Cannot instantiate persistence manager org.apache.jackrabbit.core.state.db.DerbyPersistenceManager: Configuration error: unknown schema 'derby': Configuration error: unknown schema 'derby' at org.apache.jackrabbit.core.JackrabbitRepositoryStub.getRepository(JackrabbitRepositoryStub.java:112) at org.apache.jackrabbit.test.RepositoryHelper.getRepository(RepositoryHelper.java:68) at org.apache.jackrabbit.test.RepositoryHelper.getProperty(RepositoryHelper.java:150) at org.apache.jackrabbit.test.AbstractJCRTest.getProperty(AbstractJCRTest.java:429) at org.apache.jackrabbit.test.AbstractJCRTest.setUp(AbstractJCRTest.java:254) at org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:393) Refactoring of the Persistence Managers --- Key: JCR-595 URL: http://issues.apache.org/jira/browse/JCR-595 Project: Jackrabbit Issue Type: Improvement Components: core Affects Versions: 1.1.1 Reporter: Tobias Bocanegra Assigned To: Tobias Bocanegra Priority: Minor Fix For: 1.1.1 Attachments: jackrabbit.465518.patch currently the persistence managers reside in: org.apache.jackrabbit.core.state org.apache.jackrabbit.core.state.db org.apache.jackrabbit.core.state.mem org.apache.jackrabbit.core.state.obj org.apache.jackrabbit.core.state.xml (org.apache.jackrabbit.core.state.util) there are also a lot of other classes that deal with states (eg: SharedItemStateManager) in the state package that do not relate to pms. i would like to move all persistencemanagers and pm related stuff to: org.apache.jackrabbit.core.persistence I'd keep the current classes as deprecated subclasses within jackrabbit-core.jar until Jackrabbit 2.0. There may (?) be people who are extending the existing classes, so I'd avoid breaking binary compatibility there even though we've never promised to actually honor compatiblity within o.a.j.core. -- 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-602) importXML still depends on Xerces
[ http://issues.apache.org/jira/browse/JCR-602?page=comments#action_12444603 ] Przemo Pakulski commented on JCR-602: - There are still tests dependent on Xercec in org.apache.jackrabbit.test.api package : - AbstractImportXmlTest - SerializationTest It will be nice to remove dependency from tests too. importXML still depends on Xerces - Key: JCR-602 URL: http://issues.apache.org/jira/browse/JCR-602 Project: Jackrabbit Issue Type: Bug Components: xml Affects Versions: 1.1 Reporter: Jukka Zitting Assigned To: Jukka Zitting Priority: Minor Fix For: 1.1.1 Przemo Pakulski commented on JCR-367: Jackrabbit-core is still dependent on Xerces directly during runtime, SessionImpl.importWorkspace, Workspacempl.importWorkspace methods contains folliwng lines : XMLReader parser = XMLReaderFactory.createXMLReader(org.apache.xerces.parsers.SAXParser); It works in maven1 probably because maven1 itself needs xerces to run test goal. I suggest reopening the issue. Creating a new issue since JCR-367 is already closed after the 1.1 release. -- 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-601) Delete workspace support
Delete workspace support Key: JCR-601 URL: http://issues.apache.org/jira/browse/JCR-601 Project: Jackrabbit Issue Type: Improvement Components: Jackrabbit API Affects Versions: 0.9, 1.0, 1.0.1, 1.1 Reporter: Przemo Pakulski Priority: Minor JackrabbitWorkspace interface defines method to create new workspace, but there is no method to remove workspace programatically. -- 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-601) Delete workspace support
[ http://issues.apache.org/jira/browse/JCR-601?page=comments#action_12444261 ] Przemo Pakulski commented on JCR-601: - It can be quite useful to be able remove workspace programatically, and we are interested in contributing patch for this feature. To implement his feature we are going to do following changes : - add deleteWorkspace method to JackrabbitWorkspace interface, - add deleteWorkspace method implementation to RepositoryImpl class, deleteWorkspace will contain : * check if workspace can be deleted if idle (no active session exists), * dispose workspace, delete workspace folder, * delete workspace resources including : FileSystem, PersistenceManager, SearchIndex, - to allow deleting workspace resources destroy method to all workspace related components (FileSystem, PersistenceManager, SearchIndex) will be added, and abstract classes will implement this method by throwing OperationNotSupported exception - add implementation of destroy methods for components used in default Jackrabbit configuration (LocalFileSystem, DerbyPM, lucene SearchIndex). Is there anything else that should be done if workspace is removed ? Any comments welcome. Delete workspace support Key: JCR-601 URL: http://issues.apache.org/jira/browse/JCR-601 Project: Jackrabbit Issue Type: Improvement Components: Jackrabbit API Affects Versions: 0.9, 1.0, 1.0.1, 1.1 Reporter: Przemo Pakulski Priority: Minor JackrabbitWorkspace interface defines method to create new workspace, but there is no method to remove workspace programatically. -- 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
