[jira] Resolved: (JCR-614) Weird locking behaviour in CachingHierarchyManager
[ http://issues.apache.org/jira/browse/JCR-614?page=all ] Jukka Zitting resolved JCR-614. --- Resolution: Fixed Weird locking behaviour in CachingHierarchyManager -- Key: JCR-614 URL: http://issues.apache.org/jira/browse/JCR-614 Project: Jackrabbit Issue Type: Bug Components: core Affects Versions: 1.0.1, 1.1, 1.1.1 Reporter: Tobias Bocanegra Assigned To: Tobias Bocanegra Fix For: 1.2 in some of our itegration tests the repository sometime locks-up with a stacktrace like this: Thread-38 daemon prio=5 tid=0x08cb3908 nid=0xdd8 runnable [9fef000..9fefd90] at org.apache.jackrabbit.core.CachingHierarchyManager.removeLRU(CachingHierarchyManager.java:540) - waiting to lock 0x16a9b0e0 (a java.lang.Object) at org.apache.jackrabbit.core.CachingHierarchyManager.cache(CachingHierarchyManager.java:510) - locked 0x16a9b0e0 (a java.lang.Object) at org.apache.jackrabbit.core.CachingHierarchyManager.buildPath(CachingHierarchyManager.java:163) at org.apache.jackrabbit.HierarchyManagerImpl.buildPath(HierarchyManagerImpl.java:296) [...] although i think that this sacktrace is valid (a thread holding a monitor waiting to lock it again) this scenario shows up a lot during stress-testing. i assume it's the JIT that messesup synchornization. the fix is to remove the double monitor entry in this case. -- 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] Reopened: (JCR-617) CachingHieraarchyManager may serve moved items
[ http://issues.apache.org/jira/browse/JCR-617?page=all ] Jukka Zitting reopened JCR-617: --- CachingHieraarchyManager may serve moved items -- Key: JCR-617 URL: http://issues.apache.org/jira/browse/JCR-617 Project: Jackrabbit Issue Type: Bug Affects Versions: 1.1, 1.1.1 Reporter: Tobias Bocanegra Assigned To: Tobias Bocanegra Fix For: 1.2 There is a problem with weak referenced item states and event notification in the LocalItemStateManager. consider the following: - Session A traverses some nodes and fills-up the cache of the ChachingHierarchyManager - This also fills the weak-ref cache in Session A LocalItemStateManager. - Session B does some operations - At some point, GC decides to remove the weakly refferenced ItemStates in Session As LocalItemStateManager - Session B moves a node and saves the changes. - The SharedItemStateManager notifies all listeners that a node was modified - The LocalItemStateManager of Session A receives the event, but does not bubble it, because it does not have the item anymore in its cache - The CachingHierarchyManager of Session A never receives the modification event and still servers the items at the old location. Solution A: reconnect missing states in the LocalItemStateManager when an event is received. this has the drawback that a lot of state would be generated that are not needed. Solution B: add a new event 'nodeModified' that is only sent by the LocalItemStateManager if a 'stateModified' was received for which it does not have the item aymore. this has the drawback that alot more events are generated. Will implement solution B -- 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] Resolved: (JCR-617) CachingHieraarchyManager may serve moved items
[ http://issues.apache.org/jira/browse/JCR-617?page=all ] Jukka Zitting resolved JCR-617. --- Resolution: Fixed CachingHieraarchyManager may serve moved items -- Key: JCR-617 URL: http://issues.apache.org/jira/browse/JCR-617 Project: Jackrabbit Issue Type: Bug Affects Versions: 1.1, 1.1.1 Reporter: Tobias Bocanegra Assigned To: Tobias Bocanegra Fix For: 1.2 There is a problem with weak referenced item states and event notification in the LocalItemStateManager. consider the following: - Session A traverses some nodes and fills-up the cache of the ChachingHierarchyManager - This also fills the weak-ref cache in Session A LocalItemStateManager. - Session B does some operations - At some point, GC decides to remove the weakly refferenced ItemStates in Session As LocalItemStateManager - Session B moves a node and saves the changes. - The SharedItemStateManager notifies all listeners that a node was modified - The LocalItemStateManager of Session A receives the event, but does not bubble it, because it does not have the item anymore in its cache - The CachingHierarchyManager of Session A never receives the modification event and still servers the items at the old location. Solution A: reconnect missing states in the LocalItemStateManager when an event is received. this has the drawback that a lot of state would be generated that are not needed. Solution B: add a new event 'nodeModified' that is only sent by the LocalItemStateManager if a 'stateModified' was received for which it does not have the item aymore. this has the drawback that alot more events are generated. Will implement solution B -- 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] Resolved: (JCR-644) Node.isNodeType() throws if namespace is not defined.
[ http://issues.apache.org/jira/browse/JCR-644?page=all ] Jukka Zitting resolved JCR-644. --- Resolution: Won't Fix Node.isNodeType() throws if namespace is not defined. - Key: JCR-644 URL: http://issues.apache.org/jira/browse/JCR-644 Project: Jackrabbit Issue Type: Bug Components: nodetype Affects Versions: 1.0, 1.0.1, 1.1, 0.9 Reporter: Tobias Bocanegra Assigned To: Tobias Bocanegra eg: node.isNodeType(foo:MyNodeType) throws an exception if 'foo' is not defined. this is incorrect since an application should not need to check if the namespace exists before checking for a nodetype. it should return false. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-646) Misleading exception message for jcr:deref()
[ http://issues.apache.org/jira/browse/JCR-646?page=all ] Jukka Zitting updated JCR-646: -- Fix Version/s: 1.1.1 (was: 1.2) Merged the change also the the 1.1 branch in revision 480494 for inclusion in the 1.1.1 release. Misleading exception message for jcr:deref() Key: JCR-646 URL: http://issues.apache.org/jira/browse/JCR-646 Project: Jackrabbit Issue Type: Bug Affects Versions: 0.9, 1.0, 1.0.1, 1.1 Reporter: Marcel Reutegger Assigned To: Marcel Reutegger Priority: Trivial Fix For: 1.1.1 If the type of the second argument in a jcr:deref() function is not a String an InvalidQueryException is thrown with a misleading message: Wrong second argument type for jcr:like It should be rather something like: Second argument for jcr:deref must be a String -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-596) Keep jackrabbit jar/pom's updated at ibiblio
[ http://issues.apache.org/jira/browse/JCR-596?page=all ] Jukka Zitting updated JCR-596: -- Issue Type: Task (was: Improvement) Affects Version/s: (was: 1.1) (was: 1.2) (was: 1.1.1) Keep jackrabbit jar/pom's updated at ibiblio Key: JCR-596 URL: http://issues.apache.org/jira/browse/JCR-596 Project: Jackrabbit Issue Type: Task Components: maven Reporter: Darren Hartford Assigned To: Jukka Zitting Please keep jackrabbit updated on ibiblio or some other maven repository. jackrabbit-1.1 needs to be added. -- 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] Resolved: (JCR-596) Keep jackrabbit jar/pom's updated at ibiblio
[ http://issues.apache.org/jira/browse/JCR-596?page=all ] Jukka Zitting resolved JCR-596. --- Resolution: Fixed Ibiblio is up to date again. I've also fixed the POM errors that caused the issues with 1.1, so we shouldn't get the same problems again. Keep jackrabbit jar/pom's updated at ibiblio Key: JCR-596 URL: http://issues.apache.org/jira/browse/JCR-596 Project: Jackrabbit Issue Type: Task Components: maven Reporter: Darren Hartford Assigned To: Jukka Zitting Please keep jackrabbit updated on ibiblio or some other maven repository. jackrabbit-1.1 needs to be added. -- 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
[VOTE] Release Apache Jackrabbit 1.1.1
Hi, I have posted a candidate for the Apache Jackrabbit 1.1.1 release at http://people.apache.org/~jukka/jackrabbit/1.1.1/ See the included RELEASE-NOTES.txt file for details on release contents and latest changes. The release was made from the 1.1 branch after merging all the bug fixes listed in the release notes. Note that I included some last-minute trivial fixes (JCR-646, JCR-649) and dropped some issues (JCR-627) that were only introduced after 1.1. Please vote on releasing these packages as Apache Jackrabbit 1.1.1. The vote is open for the next 72 hours, and only votes from Jackrabbit committers are binding. The vote passes if at least three +1 votes are cast. [ ] +1 Release the packages as Apache Jackrabbit 1.1.1 [ ] -1 Do not release the packages because... BR, Jukka Zitting
Re: [VOTE] Release Apache Jackrabbit 1.1.1
Hi, On 11/29/06, Jukka Zitting [EMAIL PROTECTED] wrote: Please vote on releasing these packages as Apache Jackrabbit 1.1.1. The vote is open for the next 72 hours, and only votes from Jackrabbit committers are binding. The vote passes if at least three +1 votes are cast. [x] +1 Release the packages as Apache Jackrabbit 1.1.1 BR, Jukka Zitting
Jira guidelines
Hi, In order to make our issue tracker better support the release process I had to again tweak some issues as you've probably noticed by the number of recent Jira notifications. To make things easier I'd like to propose the following general guidelines for working with Jira issues: * Issue Type Generally only Bug issues are considered for inclusion in patch releases. * Affects Version(s) Use this when entering Bug reports. Select all the release numbers where you believe the reported issue to occur. If you don't know or if the issue was introduced just recently in trunk, just leave the field empty. Leave this field empty also when entering feature or improvement requests. Selecting also old release numbers makes it easier for people that are running older versions to quickly determine whether a reported bug affects their installation or not. * Fix Version(s) This field is essential for the release process. Generally you should fill it when resolving an issue; use the release numer of the release that's next planned from trunk (normally the next minor x.y release). If the issue is a bug report and you think the fix is safe enough to be included in a patch release (i.e. it shouldn't introduce any regressions), you can also select the next planned patch release number (x.y.z). You can also enter a target release number here already before the issue is fixed if you consider that the issue is essential for the release. This allows us to better track the progress towards a release. * Resolution Always use the resolution Fixed when resolving an issue that you've solved. All other resolutions will invalidate the issue so that it won't be included in any change histories or known issue lists. * Closing an issue Issues should be closed (as opposed to resolving them) only when they've been included in an official release. Thus only the release manager should ever need to close issues. Note that a closed issue should never be reopened since it's considered a part of an existing release. File a new issue that links back to the closed one if you find that the resolution in fact doesn't work. BR, Jukka Zitting
Re: [VOTE] Release Apache Jackrabbit 1.1.1
[x]+1 Release the packages as Apache Jackrabbit 1.1.1
[jira] Commented: (JCR-641) can't add lock token to session after 3 login/logout
[ http://issues.apache.org/jira/browse/JCR-641?page=comments#action_12454333 ] Stefan Guggisberg commented on JCR-641: --- pseudo code for reproducing the issue: - sessionA locks a node and retrieves the lock token - sessionA logs out (or lock token is removed from sessionA) - lock token is transfered to sessionB - sessionB logs out (or lock token is removed from sessionB) - lock token is transfered to sessionC - sessionC tries to unlock the node = LockException can't add lock token to session after 3 login/logout Key: JCR-641 URL: http://issues.apache.org/jira/browse/JCR-641 Project: Jackrabbit Issue Type: Bug Components: locks Affects Versions: 1.1 Environment: Linux Ubuntu Dapper Reporter: Paco Avila Assigned To: Stefan Guggisberg Priority: Critical Attachments: DummyLockToken.java, DummyLockToken.log, repository2.xml I login and lock a file and logout. Perfoms a new login and add the previous lock token to the current session because I want to unlock this file. This works fine. But if I do a new logout/login I can't unlock the file (the file is locked). It is best understanded looking at the test case. -- 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] Resolved: (JCR-641) can't add lock token to session after 3 login/logout
[ http://issues.apache.org/jira/browse/JCR-641?page=all ] Stefan Guggisberg resolved JCR-641. --- Fix Version/s: 1.2 Resolution: Fixed fixed in svn r480587 paco, thanks for reporting this issue! can't add lock token to session after 3 login/logout Key: JCR-641 URL: http://issues.apache.org/jira/browse/JCR-641 Project: Jackrabbit Issue Type: Bug Components: locks Affects Versions: 1.1 Environment: Linux Ubuntu Dapper Reporter: Paco Avila Assigned To: Stefan Guggisberg Priority: Critical Fix For: 1.2 Attachments: DummyLockToken.java, DummyLockToken.log, repository2.xml I login and lock a file and logout. Perfoms a new login and add the previous lock token to the current session because I want to unlock this file. This works fine. But if I do a new logout/login I can't unlock the file (the file is locked). It is best understanded looking at the test case. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-619) CacheManager (Memory Management in Jackrabbit)
[ http://issues.apache.org/jira/browse/JCR-619?page=all ] Xiaohua Lu updated JCR-619: --- Attachment: stack.txt I have been running a concurrent test on Nov. 28th code base. A deadlock has been encouterred. The setup of the test is : 1. 6000 file nodes flat under root node 2. 900 category nodes, three level deep under root node 3. 50 concurrent thread, each one perform one of the four queries : 3.1 select all file nodes 3.2 select all category nodes 3.3 select file nodes by file property 3.4 select category nodes by category property The tests only involved query, no add/delete/update are included. From the jstack.txt attached, you can see a few threads are blocking each other, it looks similar to what Tom reported a few weeks ago. CacheManager (Memory Management in Jackrabbit) -- Key: JCR-619 URL: http://issues.apache.org/jira/browse/JCR-619 Project: Jackrabbit Issue Type: New Feature Components: core Affects Versions: 1.1 Reporter: Thomas Mueller Assigned To: Stefan Guggisberg Fix For: 1.2 Attachments: cacheManager.txt, cacheManager2.txt, cacheManager5.txt, cacheManager6.txt, stack.txt Jackrabbit can run out of memory because the the combined size of the various caches is not managed. The biggest problem (for me) is the combined size of the o.a.j.core.state.MLRUItemStateCache caches. Each session seems to create a few (?) of those caches, and each one is limited to 4 MB by default. I have implemented a dynamic (cache-) memory management service that distributes a fixed amount of memory dynamically to all those caches. Here is the patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-648) NullpointerException in SessionItemStateManager
[
http://issues.apache.org/jira/browse/JCR-648?page=comments#action_12454351 ]
Stefan Guggisberg commented on JCR-648:
---
very strange indeed...
according to the stack trace the NPE is thrown on the following line
in SessionItemStateManager:
public void nodeModified(NodeState state) {
==if (state.getContainer() == this ||
!transientStore.contains(state.getId())) {
dispatcher.notifyNodeModified(state);
}
}
the 'state' variable must be null in this case ('transientStore' can't be null).
looking at the preceeding stack frames, 'state' can't be possibly null,
or i am missing something here...
LocalItemStateManager:
[...]
} else if (modified.isNode()) {
// if the state is not ours (and is not cached) it could have
// vanished from the weak-ref cache due to a gc. but there could
// still be some listeners (e.g. CachingHierarchyManager) that want
// to get notified.
dispatcher.notifyNodeModified((NodeState) modified);
}
[...]
if 'modified' would be null, the NPE would be thrown earlier (=
modified.isNode() )
i have no idea what can possibly lead to the above stack trace...
NullpointerException in SessionItemStateManager
---
Key: JCR-648
URL: http://issues.apache.org/jira/browse/JCR-648
Project: Jackrabbit
Issue Type: Bug
Components: core
Affects Versions: 1.1.1, 1.2
Environment: jackrabbit trunk in rev 479646
spring-modules-jcr 0.6 (probably not relevant)
Reporter: Christoph Kiehl
I got the following exception which is not reproducible and occured during a
large batch of write operations. Unfortunately I got no idea how this
happened. May be someone has an idea?
[2006-11-27 21:43:53,065, WARN ] {}
support.RemoteInvocationTraceInterceptor:80: Processing of RmiServiceExporter
remote call resulted in fatal exception:
com.subshell.sophora.content.server.IContentManager.importDocument
org.springframework.transaction.TransactionSystemException: Could not commit
JCR transaction; nested exception is java.lang.NullPointerException Caused
by:
java.lang.NullPointerException
at
org.apache.jackrabbit.core.state.SessionItemStateManager.nodeModified(SessionItemStateManager.java:878)
at
org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyNodeModified(StateChangeDispatcher.java:143)
at
org.apache.jackrabbit.core.state.LocalItemStateManager.stateModified(LocalItemStateManager.java:426)
at
org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateModified(StateChangeDispatcher.java:85)
at
org.apache.jackrabbit.core.state.SharedItemStateManager.stateModified(SharedItemStateManager.java:388)
at
org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateModified(StateChangeDispatcher.java:85)
at
org.apache.jackrabbit.core.state.SharedItemStateManager.stateModified(SharedItemStateManager.java:388)
at
org.apache.jackrabbit.core.state.ItemState.notifyStateUpdated(ItemState.java:241)
at
org.apache.jackrabbit.core.state.ChangeLog.persisted(ChangeLog.java:271)
at
org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:691)
at
org.apache.jackrabbit.core.state.XAItemStateManager.commit(XAItemStateManager.java:169)
at
org.apache.jackrabbit.core.version.XAVersionManager.commit(XAVersionManager.java:478)
at
org.apache.jackrabbit.core.TransactionContext.commit(TransactionContext.java:172)
at
org.apache.jackrabbit.core.XASessionImpl.commit(XASessionImpl.java:315)
at
org.springmodules.jcr.jackrabbit.support.JackRabbitUserTransaction.commit(JackRabbitUserTransaction.java:104)
at
org.springmodules.jcr.jackrabbit.LocalTransactionManager.doCommit(LocalTransactionManager.java:192)
at
org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:540)
at
org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:510)
at
org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:310)
at
org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:117)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:185)
at
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:89)
at
[jira] Reopened: (JCR-619) CacheManager (Memory Management in Jackrabbit)
[ http://issues.apache.org/jira/browse/JCR-619?page=all ] Stefan Guggisberg reopened JCR-619: --- reopening based on xiaohua's feed back (potential dead lock) CacheManager (Memory Management in Jackrabbit) -- Key: JCR-619 URL: http://issues.apache.org/jira/browse/JCR-619 Project: Jackrabbit Issue Type: New Feature Components: core Affects Versions: 1.1 Reporter: Thomas Mueller Assigned To: Stefan Guggisberg Fix For: 1.2 Attachments: cacheManager.txt, cacheManager2.txt, cacheManager5.txt, cacheManager6.txt, stack.txt Jackrabbit can run out of memory because the the combined size of the various caches is not managed. The biggest problem (for me) is the combined size of the o.a.j.core.state.MLRUItemStateCache caches. Each session seems to create a few (?) of those caches, and each one is limited to 4 MB by default. I have implemented a dynamic (cache-) memory management service that distributes a fixed amount of memory dynamically to all those caches. Here is the patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-648) NullpointerException in SessionItemStateManager
[
http://issues.apache.org/jira/browse/JCR-648?page=comments#action_12454355 ]
Christoph Kiehl commented on JCR-648:
-
I had a look as well and came to the same conclusion, but I thought post it
here. You guys have a better understanding of Jackrabbits internals.
I would suggest resolving this issue. I'll reopen it if the problem occurs
again. Maybe I can provide more information next time.
NullpointerException in SessionItemStateManager
---
Key: JCR-648
URL: http://issues.apache.org/jira/browse/JCR-648
Project: Jackrabbit
Issue Type: Bug
Components: core
Affects Versions: 1.1.1, 1.2
Environment: jackrabbit trunk in rev 479646
spring-modules-jcr 0.6 (probably not relevant)
Reporter: Christoph Kiehl
I got the following exception which is not reproducible and occured during a
large batch of write operations. Unfortunately I got no idea how this
happened. May be someone has an idea?
[2006-11-27 21:43:53,065, WARN ] {}
support.RemoteInvocationTraceInterceptor:80: Processing of RmiServiceExporter
remote call resulted in fatal exception:
com.subshell.sophora.content.server.IContentManager.importDocument
org.springframework.transaction.TransactionSystemException: Could not commit
JCR transaction; nested exception is java.lang.NullPointerException Caused
by:
java.lang.NullPointerException
at
org.apache.jackrabbit.core.state.SessionItemStateManager.nodeModified(SessionItemStateManager.java:878)
at
org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyNodeModified(StateChangeDispatcher.java:143)
at
org.apache.jackrabbit.core.state.LocalItemStateManager.stateModified(LocalItemStateManager.java:426)
at
org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateModified(StateChangeDispatcher.java:85)
at
org.apache.jackrabbit.core.state.SharedItemStateManager.stateModified(SharedItemStateManager.java:388)
at
org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateModified(StateChangeDispatcher.java:85)
at
org.apache.jackrabbit.core.state.SharedItemStateManager.stateModified(SharedItemStateManager.java:388)
at
org.apache.jackrabbit.core.state.ItemState.notifyStateUpdated(ItemState.java:241)
at
org.apache.jackrabbit.core.state.ChangeLog.persisted(ChangeLog.java:271)
at
org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:691)
at
org.apache.jackrabbit.core.state.XAItemStateManager.commit(XAItemStateManager.java:169)
at
org.apache.jackrabbit.core.version.XAVersionManager.commit(XAVersionManager.java:478)
at
org.apache.jackrabbit.core.TransactionContext.commit(TransactionContext.java:172)
at
org.apache.jackrabbit.core.XASessionImpl.commit(XASessionImpl.java:315)
at
org.springmodules.jcr.jackrabbit.support.JackRabbitUserTransaction.commit(JackRabbitUserTransaction.java:104)
at
org.springmodules.jcr.jackrabbit.LocalTransactionManager.doCommit(LocalTransactionManager.java:192)
at
org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:540)
at
org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:510)
at
org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:310)
at
org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:117)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:185)
at
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:89)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:185)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:209)
at $Proxy14.importDocument(Unknown Source)
at sun.reflect.GeneratedMethodAccessor18.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:318)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:203)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:162)
at
[jira] Commented: (JCR-647) NodeType.canRemoveItem does not consider residual definitions (JCR2SPI)
[ http://issues.apache.org/jira/browse/JCR-647?page=comments#action_12454370 ] angela commented on JCR-647: i had a closer look at the reference implementation (core) and found, that child item definitions combining residual and mandatory are not only ignored with the mentioned NodeType.canRemoveItem method but also during consistency checks upon Item.save(). regarding the patch: if multiple residual definitions exist, canRemoveItem may still (having the patch applied) return a wrong result, since from the itemName we cannot determine, which definition belongs to the item of the given name... i'd say, this is a problem of the specification. = i added new issues to JSR283 asking for clarification. NodeType.canRemoveItem does not consider residual definitions (JCR2SPI) --- Key: JCR-647 URL: http://issues.apache.org/jira/browse/JCR-647 Project: Jackrabbit Issue Type: Bug Components: SPI Reporter: Julian Reschke Priority: Minor Attachments: JCR-647.diff.txt JCR2SPI's NodeType.canRemoveItem() doesn't seem to work with residual definitions. This seems to be caused by EffectiveNodeTyoeImpl.checkRemoveItemConstraints not checking the unnamed definitions. -- 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-600) Repository does not release all resources on shutdown
[ http://issues.apache.org/jira/browse/JCR-600?page=comments#action_12454371 ] Torgeir Veimo commented on JCR-600: --- I've done a bit more testing and it does in-fact seem to work properly now, so I guess this issue can be resolved as fixed. Repository does not release all resources on shutdown - Key: JCR-600 URL: http://issues.apache.org/jira/browse/JCR-600 Project: Jackrabbit Issue Type: Bug Components: core Affects Versions: 1.0, 1.0.1, 1.1 Reporter: Marcel Reutegger Assigned To: Marcel Reutegger Priority: Minor Fix For: 1.1.1 Attachments: Screenshot_1.png, Screenshot_2.png When Jackrabbit is shutdown some java.util.Timer threads are still running in the background even though no tasks are scheduled. This prevents the GC from collecting the classes when Jackrabbit is redeployed within a web application. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (JCR-648) NullpointerException in SessionItemStateManager
Hi,
Just an idea... transientStore could be null. It is initialized after
addListener is called:
stateMgr.addListener(this);
...
transientStore = new ItemStateMap();
Thomas
On 11/29/06, Stefan Guggisberg (JIRA) [EMAIL PROTECTED] wrote:
[
http://issues.apache.org/jira/browse/JCR-648?page=comments#action_12454351 ]
Stefan Guggisberg commented on JCR-648:
---
very strange indeed...
according to the stack trace the NPE is thrown on the following line
in SessionItemStateManager:
public void nodeModified(NodeState state) {
==if (state.getContainer() == this ||
!transientStore.contains(state.getId())) {
dispatcher.notifyNodeModified(state);
}
}
the 'state' variable must be null in this case ('transientStore' can't be null).
looking at the preceeding stack frames, 'state' can't be possibly null,
or i am missing something here...
LocalItemStateManager:
[...]
} else if (modified.isNode()) {
// if the state is not ours (and is not cached) it could have
// vanished from the weak-ref cache due to a gc. but there could
// still be some listeners (e.g. CachingHierarchyManager) that want
// to get notified.
dispatcher.notifyNodeModified((NodeState) modified);
}
[...]
if 'modified' would be null, the NPE would be thrown earlier (=
modified.isNode() )
i have no idea what can possibly lead to the above stack trace...
NullpointerException in SessionItemStateManager
---
Key: JCR-648
URL: http://issues.apache.org/jira/browse/JCR-648
Project: Jackrabbit
Issue Type: Bug
Components: core
Affects Versions: 1.1.1, 1.2
Environment: jackrabbit trunk in rev 479646
spring-modules-jcr 0.6 (probably not relevant)
Reporter: Christoph Kiehl
I got the following exception which is not reproducible and occured during a
large batch of write operations. Unfortunately I got no idea how this happened.
May be someone has an idea?
[2006-11-27 21:43:53,065, WARN ] {}
support.RemoteInvocationTraceInterceptor:80: Processing of RmiServiceExporter
remote call resulted in fatal exception:
com.subshell.sophora.content.server.IContentManager.importDocument
org.springframework.transaction.TransactionSystemException: Could not commit
JCR transaction; nested exception is java.lang.NullPointerException Caused by:
java.lang.NullPointerException
at
org.apache.jackrabbit.core.state.SessionItemStateManager.nodeModified(SessionItemStateManager.java:878)
at
org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyNodeModified(StateChangeDispatcher.java:143)
at
org.apache.jackrabbit.core.state.LocalItemStateManager.stateModified(LocalItemStateManager.java:426)
at
org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateModified(StateChangeDispatcher.java:85)
at
org.apache.jackrabbit.core.state.SharedItemStateManager.stateModified(SharedItemStateManager.java:388)
at
org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateModified(StateChangeDispatcher.java:85)
at
org.apache.jackrabbit.core.state.SharedItemStateManager.stateModified(SharedItemStateManager.java:388)
at
org.apache.jackrabbit.core.state.ItemState.notifyStateUpdated(ItemState.java:241)
at
org.apache.jackrabbit.core.state.ChangeLog.persisted(ChangeLog.java:271)
at
org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:691)
at
org.apache.jackrabbit.core.state.XAItemStateManager.commit(XAItemStateManager.java:169)
at
org.apache.jackrabbit.core.version.XAVersionManager.commit(XAVersionManager.java:478)
at
org.apache.jackrabbit.core.TransactionContext.commit(TransactionContext.java:172)
at
org.apache.jackrabbit.core.XASessionImpl.commit(XASessionImpl.java:315)
at
org.springmodules.jcr.jackrabbit.support.JackRabbitUserTransaction.commit(JackRabbitUserTransaction.java:104)
at
org.springmodules.jcr.jackrabbit.LocalTransactionManager.doCommit(LocalTransactionManager.java:192)
at
org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:540)
at
org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:510)
at
org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:310)
at
org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:117)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:185)
at
Re: [VOTE] Release Apache Jackrabbit 1.1.1
[x] +1 Release the packages as Apache Jackrabbit 1.1.1 -- Torgeir Veimo [EMAIL PROTECTED]
[jira] Commented: (JCR-641) can't add lock token to session after 3 login/logout
[ http://issues.apache.org/jira/browse/JCR-641?page=comments#action_12454381 ] Paco Avila commented on JCR-641: This is a ugly bug, can be fixed in the 1.1.1 release? can't add lock token to session after 3 login/logout Key: JCR-641 URL: http://issues.apache.org/jira/browse/JCR-641 Project: Jackrabbit Issue Type: Bug Components: locks Affects Versions: 1.1 Environment: Linux Ubuntu Dapper Reporter: Paco Avila Assigned To: Stefan Guggisberg Priority: Critical Fix For: 1.2 Attachments: DummyLockToken.java, DummyLockToken.log, repository2.xml I login and lock a file and logout. Perfoms a new login and add the previous lock token to the current session because I want to unlock this file. This works fine. But if I do a new logout/login I can't unlock the file (the file is locked). It is best understanded looking at the test case. -- 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-641) can't add lock token to session after 3 login/logout
[ http://issues.apache.org/jira/browse/JCR-641?page=comments#action_12454390 ] Jukka Zitting commented on JCR-641: --- This is a ugly bug, can be fixed in the 1.1.1 release? Too late, the release has already been tagged. The fix will be in the 1.2 release. can't add lock token to session after 3 login/logout Key: JCR-641 URL: http://issues.apache.org/jira/browse/JCR-641 Project: Jackrabbit Issue Type: Bug Components: locks Affects Versions: 1.1 Environment: Linux Ubuntu Dapper Reporter: Paco Avila Assigned To: Stefan Guggisberg Priority: Critical Fix For: 1.2 Attachments: DummyLockToken.java, DummyLockToken.log, repository2.xml I login and lock a file and logout. Perfoms a new login and add the previous lock token to the current session because I want to unlock this file. This works fine. But if I do a new logout/login I can't unlock the file (the file is locked). It is best understanded looking at the test case. -- 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-619) CacheManager (Memory Management in Jackrabbit)
[ http://issues.apache.org/jira/browse/JCR-619?page=comments#action_12454399 ] Xiaohua Lu commented on JCR-619: I managed to reproduce the deadlock with 2 concurrent query. both query are select all category nodes. the test data is the same as before. The definition of data as as following : nt = 'http://www.jcp.org/jcr/nt/1.0' mix = 'http://www.jcp.org/jcr/mix/1.0' mvn = 'http://maven.net/jcr/mock' mvnnt = 'http://maven.net/jcr/nt/mock' [mvnnt:categoryHierarchyNode] nt:base [mvnnt:category] mvnnt:categoryHierarchyNode, mix:referenceable - mvn:description (string) - mvn:content (reference) multiple + * (mvnnt:categoryHierarchyNode) --- note : the content field will point to file node and it is not used in this test. the query both threads are trying to perform is //element (*, mvnnt:category) -- note : The query returned very quickly and the deadlock happened when both threads tried to iterate through the NoteIterator to make sure the returned result are of type mvnnt:category. The jstack output is as followings : Thread [EMAIL PROTECTED]: (state = BLOCKED) - org.apache.jackrabbit.core.state.CacheManager.cacheAccessed() @bci=18, line=77 (Interpreted frame) - org.apache.jackrabbit.core.state.MLRUItemStateCache.touch() @bci=34, line=222 (Compiled frame) - org.apache.jackrabbit.core.state.MLRUItemStateCache.retrieve(org.apache.jackrabbit.core.ItemId) @bci=8, line=97 (Compiled frame) - org.apache.jackrabbit.core.state.ItemStateReferenceCache.retrieve(org.apache.jackrabbit.core.ItemId) @bci=5, line=99 (Compiled frame) - org.apache.jackrabbit.core.state.XAItemStateManager.getItemState(org.apache.jackrabbit.core.ItemId) @bci=54, line=233 (Compiled frame) - org.apache.jackrabbit.core.state.SessionItemStateManager.getItemState(org.apache.jackrabbit.core.ItemId) @bci=56, line=165 (Compiled frame) - org.apache.jackrabbit.core.ItemManager.createItemInstance(org.apache.jackrabbit.core.ItemId) @bci=5, line=462 (Compiled frame) - org.apache.jackrabbit.core.ItemManager.getItem(org.apache.jackrabbit.core.ItemId) @bci=63, line=320 (Compiled frame) - org.apache.jackrabbit.core.query.lucene.NodeIteratorImpl.fetchNext() @bci=46, line=194 (Compiled frame) - org.apache.jackrabbit.core.query.lucene.NodeIteratorImpl.nextNodeImpl() @bci=21, line=103 (Compiled frame) - net.maven.cr.test.PerformanceQueryTest$ListCategoriesQueryTestContext.verify(javax.jcr.NodeIterator) @bci=25 (Interpreted frame) - net.maven.cr.test.PerformanceQueryTest.timingQuery(net.maven.cr.test.PerformanceQueryTest$QueryTestContext) @bci=34 (Interpreted frame) - net.maven.cr.test.PerformanceQueryTest.access$100(net.maven.cr.test.PerformanceQueryTest, net.maven.cr.test.PerformanceQueryTest$QueryTestContext) @bci=2 (Interpreted frame) - net.maven.cr.test.PerformanceQueryTest$TimedQueryTest.run() @bci=32 (Interpreted frame) Thread [EMAIL PROTECTED]: (state = BLOCKED) - org.apache.jackrabbit.core.state.MLRUItemStateCache.getMemoryUsed() @bci=6, line=245 (Compiled frame; information may be imprecise) - org.apache.jackrabbit.core.state.CacheManager$CacheInfo.init(org.apache.jackrabbit.core.state.Cache) @bci=21, line=212 (Interpreted frame) - org.apache.jackrabbit.core.state.CacheManager.resizeAll() @bci=136, line=107 (Compiled frame) - org.apache.jackrabbit.core.state.CacheManager.cacheAccessed() @bci=40, line=81 (Interpreted frame) - org.apache.jackrabbit.core.state.MLRUItemStateCache.touch() @bci=34, line=222 (Compiled frame) - org.apache.jackrabbit.core.state.MLRUItemStateCache.cache(org.apache.jackrabbit.core.state.ItemState) @bci=8, line=129 (Compiled frame) - org.apache.jackrabbit.core.state.ItemStateReferenceCache.cache(org.apache.jackrabbit.core.state.ItemState) @bci=48, line=114 (Compiled frame) - org.apache.jackrabbit.core.state.LocalItemStateManager.getNodeState(org.apache.jackrabbit.core.NodeId) @bci=31, line=99 (Compiled frame) - org.apache.jackrabbit.core.state.LocalItemStateManager.getItemState(org.apache.jackrabbit.core.ItemId) @bci=47, line=150 (Compiled frame) - org.apache.jackrabbit.core.state.XAItemStateManager.getItemState(org.apache.jackrabbit.core.ItemId) @bci=54, line=233 (Compiled frame) - org.apache.jackrabbit.core.state.SessionItemStateManager.getItemState(org.apache.jackrabbit.core.ItemId) @bci=56, line=165 (Compiled frame) - org.apache.jackrabbit.core.ItemManager.createItemInstance(org.apache.jackrabbit.core.ItemId) @bci=5, line=462 (Compiled frame) - org.apache.jackrabbit.core.ItemManager.getItem(org.apache.jackrabbit.core.ItemId) @bci=63, line=320 (Compiled frame) - org.apache.jackrabbit.core.query.lucene.NodeIteratorImpl.fetchNext() @bci=46, line=194 (Compiled frame) - org.apache.jackrabbit.core.query.lucene.NodeIteratorImpl.nextNodeImpl() @bci=21, line=103 (Compiled frame) - net.maven.cr.test.PerformanceQueryTest$ListCategoriesQueryTestContext.verify(javax.jcr.NodeIterator) @bci=25
[jira] Commented: (JCR-612) Restructure the Jackrabbit source tree
[ http://issues.apache.org/jira/browse/JCR-612?page=comments#action_12454442 ] Jukka Zitting commented on JCR-612: --- Jan Kuzniak: What are your preferences on how should I bring it here? I am thinking of one batch file or one ant file that when executed will copy files here and there. I'd most prefer a sequence of unix commands to execute, as I'd like to execute the changes manually if possible. An ant script or a batch file is fine as well, though I'll probably still evaluate it manually. Restructure the Jackrabbit source tree -- Key: JCR-612 URL: http://issues.apache.org/jira/browse/JCR-612 Project: Jackrabbit Issue Type: Improvement Reporter: Jukka Zitting Assigned To: Jukka Zitting Fix For: 1.2 Attachments: pomParent.zip Reintroduce some of the changes in JCR-157 as a more general restructuring to simplify the Jackrabbit project structure. See http://thread.gmane.org/gmane.comp.apache.jackrabbit.devel/9170/ for the rationale and discussion. The main parts of this restructuring would be: 1. Create a Jackrabbit super-project (artifactId: jackrabbit) in trunk/ 2. Use the super-project POM as the parent of all Jackrabbit component POMs 3. Move the contents of trunk/jackrabbit/src/site directly to trunk/src/site, and use the super-project to generate the web site 4. Create independent subprojects for the the jackrabbit-api and jackrabbit-commons components, moving the the corresponding parts of the source tree 5. Move the jcr-server subprojects on level up 6. Rename the subproject directories to match their artifactIds Note that this restructuring depends on JCR-611 and JCR-332, since the best way to implement this by utilizing a snapshot repository for the component dependencies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (JCR-610) Upgrade to Derby 10.2
[ http://issues.apache.org/jira/browse/JCR-610?page=all ] Jukka Zitting reassigned JCR-610: - Assignee: Jukka Zitting Upgrade to Derby 10.2 - Key: JCR-610 URL: http://issues.apache.org/jira/browse/JCR-610 Project: Jackrabbit Issue Type: Improvement Components: core Reporter: Jukka Zitting Assigned To: Jukka Zitting Fix For: 1.2 Apache Derby 10.2 was released recently. The release contains a number of improvements (including performance) and requires no special upgrade procedures. I suggest we upgrade to Derby 10.2 along with Lucene 2.0 (JCR-352) and Maven 2 (JCR-332). -- 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
