Re: [jr3] Exception Handling
== Use Error Codes == What about using something like a hash code (for example of the current stack trace) as error code? These would then automatically serve as hash tags for Google searches. That is, errors pasted into a discussion forum would be indexed by Google. Searching for 'Error 6df8c9ef2aa1cf7b04b52939b7c1cd7e' would then practically unambiguously lead to that post. Michael
Re: [jr3] Delayed Repository Initialization
On Mon, Mar 1, 2010 at 5:41 AM, Thomas Müller thomas.muel...@day.com wrote: The question is: should Jackrabbit 3 *require* (like now) that the credentials for the storage are included in the repository configuration? I think for some storage backends it should not require that. Instead (only in those cases), it should initialize the I am not clear what credentials you are refering to and how current jackrabbit works with backend login. If it's related to storage backend, it need always store on repository level. Repository initialisation will need the backend credential to ensure db schema is there. Session login credential shouldn't related to backend storage such as jdbc username/password. Unless we designed to map jcr session user to jdbc user. -Guo
Re: [jr3] Exception Handling
I wouldn't call it error code, then: every time something changes either in the calling code or in the code throwing the exception, you'll get a different hash code. Dominique On Mon, Mar 1, 2010 at 10:32 AM, Michael Dürig michael.due...@day.com wrote: == Use Error Codes == What about using something like a hash code (for example of the current stack trace) as error code? These would then automatically serve as hash tags for Google searches. That is, errors pasted into a discussion forum would be indexed by Google. Searching for 'Error 6df8c9ef2aa1cf7b04b52939b7c1cd7e' would then practically unambiguously lead to that post. Michael
Re: [jr3] Exception Handling
On Mon, Mar 1, 2010 at 9:32 AM, Michael Dürig michael.due...@day.com wrote: What about using something like a hash code (for example of the current stack trace) as error code? These would then automatically serve as hash A good sample to deal with error messages: http://publib.boulder.ibm.com/infocenter/ltscnnct/v2r0/topic/com.ibm.connections.25.help/r_error_codes_news.html For a given error message: CLFWX0019E: PUT HTTP method is not supported for this URL. It contain a prefix CLFWX tell which component is coming from, and it end with E means error. (W=Warn, I= Info) The rest of the error message are supposed to be translated to other languages. So even for none English users, we can still tell what's going wrong from the error code. -Guo
Re: [jr3] Delayed Repository Initialization
Hi, I am not clear what credentials you are refering to I refer to the database user name and password that are currently stored in the repository.xml (except when using JNDI): http://jackrabbit.apache.org/api/1.5/org/apache/jackrabbit/core/persistence/bundle/BundleDbPersistenceManager.html # param name=user value=/ # param name=password value=/ and how current jackrabbit works with backend login Currently, Jackrabbit requires to be able to create a database connection when initializing. If it's related to storage backend, it need always store on repository level. It depends on what you mean with repository level. It doesn't make sense to store the user name and password of the database inside the database (I hope you agree :-) I would like to make repository.xml optional. To do that, the user name and password for the database need to be stored somewhere else. One solution is to provide them when creating the repository object. Example: String factoryClass = ...; String url = ...?user=sapassword=xyz; RepositoryFactory factory = (RepositoryFactory) Class.forName(factoryClass).newInstance(); MapString, String parameters = new HashMapString, String(); parameters.put(url, url); Repository rep = factory.getRepository(parameters); In this case the user name and password are included in the repository URL. This solution is almost what we have how (except there is no repository.xml). What I propose is: Jackrabbit should support the following use case as well: String factoryClass = ...; String url = ...; RepositoryFactory factory = (RepositoryFactory) Class.forName(factoryClass).newInstance(); MapString, String parameters = new HashMapString, String(); parameters.put(url, url); Repository rep = factory.getRepository(parameters); Session session = rep.login(new SimpleCredentials(sa, xyz.toCharArray())); Here, the user name and password of the storage backend (for example a relational database) are not included in the repository URL. Instead, they are supplied in the first session that logs into the repository. Currently this use case is not supported. I suggest that Jackrabbit 3 support this as a possible use case (not necessarily as the default use case). Unless we designed to map jcr session user to jdbc user. Not necessarily. The Delayed Repository Initialization is not related to how Jackrabbit works internally. Jackrabbit might still use only one JDBC connection for the whole repository. Or it might use a JDBC connection pool. Or it might use one JDBC connection per session. Regards, Thomas
Re: [jr3] Exception Handling
Dominique Pfister wrote: I wouldn't call it error code, then: every time something changes either in the calling code or in the code throwing the exception, you'll get a different hash code. Agreed, the stack trace might be too unstable. But I still like the idea of using something cryptic for error codes. To see what I mean try Googling for error 1 and error 0x800cccff. The second query gives much more precise results. OTOH it needn't be the error code. We could also include it just at what it is, a hash tag. Michael Dominique On Mon, Mar 1, 2010 at 10:32 AM, Michael Dürig michael.due...@day.com wrote: == Use Error Codes == What about using something like a hash code (for example of the current stack trace) as error code? These would then automatically serve as hash tags for Google searches. That is, errors pasted into a discussion forum would be indexed by Google. Searching for 'Error 6df8c9ef2aa1cf7b04b52939b7c1cd7e' would then practically unambiguously lead to that post. Michael
Re: [jr3] Exception Handling
On Sun, Feb 28, 2010 at 16:41, Thomas Müller thomas.muel...@day.com wrote: == Use Error Codes == Currently exception message are hardcoded (in English). When using error codes, exception messages could be translated. I'm not saying we should translate them ourselves, but if somebody wants to, he could. == Include the Jackrabbit Version in Exceptions == This is mainly to simplify support: it's very easy to say what version was used when somebody posts an exception message. Example: Repository is closed [1000-3.0.1003] - this would mean error code 1000, Jackrabbit version 3.0, build 1003. The build number alone would be enough, but for the user it may be better to also include the version. Also, it will allow looking at the source code without having to download the source code of the correct version, even without having to install an IDE. I wrote a simple JavaScript application: http://www.h2database.com/html/sourceError.html - if you paste an exception in the 'Input' text area, it will link to the source code and display additional information. +1 I like the result that error stack trace analysis can be automated then. This makes it much faster for a dev knowing the internal code to spot any error, w/o having to find the proper version of a source file first (and w/o having to ask for the jackrabbit version on the list). Regards, Alex -- Alexander Klimetschek alexander.klimetsc...@day.com
Re: [jr3] Delayed Repository Initialization
Hi, -1 on defining this on this isolated level. This should be part of a broader concept of how to architect/structure JR3 and its backend connections. Regards Felix On 28.02.2010 16:40, Thomas Müller wrote: Currently Jackrabbit initializes the repository storage (persistence manager) when creating the repository object. If the repository data is stored in relational database, then the database connection is opened at that time. I suggest to allow delayed initialization (allow, not require). For some storage backends, the repository could initialize when opening the first session. Example: 1) String url = jdbc:...; RepositoryFactory factory = (RepositoryFactory) Class.forName(factoryClass).newInstance(); MapString, String parameters = new HashMapString, String(); parameters.put(url, url); Repository rep = factory.getRepository(parameters); 2) String user = ..., password = ...; Session session = rep.login(new SimpleCredentials(user, password.toCharArray())); This example uses a relational database as the storage. When creating the repository object, user name and password are unknown, so the repository could not initialize at that time. Only when the first user logs in, the user name and password are known. In this case, the user name and password of the session would match the user name and password of the storage backend, but that's actually not a requirement (it's just an example). The current Jackrabbit architecture doesn't support this 'delayed initialization' use case yet. I suggest that Jackrabbit 3 should support such delayed initialization. Whether or not we will implement storage backends that actually do use this mechanism is another question. Regards, Thomas
Re: [jr3] Delayed Repository Initialization
On Mon, Mar 1, 2010 at 11:50, Thomas Müller thomas.muel...@day.com wrote: String factoryClass = ...; String url = ...?user=sapassword=xyz; RepositoryFactory factory = (RepositoryFactory) Class.forName(factoryClass).newInstance(); MapString, String parameters = new HashMapString, String(); parameters.put(url, url); Repository rep = factory.getRepository(parameters); In this case the user name and password are included in the repository URL. This solution is almost what we have how (except there is no repository.xml). What I propose is: Jackrabbit should support the following use case as well: String factoryClass = ...; String url = ...; RepositoryFactory factory = (RepositoryFactory) Class.forName(factoryClass).newInstance(); MapString, String parameters = new HashMapString, String(); parameters.put(url, url); Repository rep = factory.getRepository(parameters); Session session = rep.login(new SimpleCredentials(sa, xyz.toCharArray())); Here, the user name and password of the storage backend (for example a relational database) are not included in the repository URL. Instead, they are supplied in the first session that logs into the repository. Currently this use case is not supported. I suggest that Jackrabbit 3 support this as a possible use case (not necessarily as the default use case). Couldn't this be done by a special wrapping Repository implementation? Supposing the configuration of the actual RepositoryImpl is dynamically configurable w/o repository.xml, as it is planned. I think the use case for short configs via URL (like ...?user=sapassword=xyz above) is valid and it's a good idea to support that. For performance reasons in a production instance it probably doesn't make a big difference, since there will typically be at least one (admin) session immediately logging in once the repository is up. Regards, Alex -- Alexander Klimetschek alexander.klimetsc...@day.com
Re: [jr3] Delayed Repository Initialization
Hi, Currently Jackrabbit doesn't support relayed initialization. Unless I misunderstood Felix, he would also like to get rid of this restriction. Just to clarify: my suggestion is *not* about requiring the repository is initialized when the first session is opened. It's also *not* about requiring that the JCR credentials are used to login to the backend storage (in most cases that's not a good idea). This idea is about *allowing* delayed repository initialization. The examples I gave are just for illustration and show *one* possible use case. Couldn't this be done by a special wrapping Repository implementation? That's problematic. Such a wrapper would have quite some overhead. The JCR API is not easily wrapable if you want to do it correctly: you would have to wrap almost every JCR interface and method, including Node and Property. That would be a relatively large memory overhead. You could use the Java proxy mechanism, but that is relatively slow (uses reflection). Regards, Thomas
[jira] Commented: (JCR-2524) Reduce memory usage of DocIds
[ https://issues.apache.org/jira/browse/JCR-2524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12839717#action_12839717 ] Marcel Reutegger commented on JCR-2524: --- Some memory stats from a real life system: a fully populated DocId cache for 300'000 nodes consumes about 6MB of heap. Reduce memory usage of DocIds - Key: JCR-2524 URL: https://issues.apache.org/jira/browse/JCR-2524 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-core Reporter: Marcel Reutegger Priority: Minor Implementations of DocIds are used to cache parent child relations of nodes in the index. Usually there are a lot of duplicate objects because a DocId instance is used to identify the parent of a node in the index. That is, sibling nodes will all have DocIds with the same value. Currently a new DocId instance is created for each node. Caching the most recently used DocIds and reuse them might help to reduce the memory usage. Furthermore there are DocIds that could be represented with a short instead of an int when possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jr3] Delayed Repository Initialization
On Mon, Mar 1, 2010 at 14:42, Thomas Müller thomas.muel...@day.com wrote: Couldn't this be done by a special wrapping Repository implementation? That's problematic. Such a wrapper would have quite some overhead. The JCR API is not easily wrapable if you want to do it correctly: you would have to wrap almost every JCR interface and method, including Node and Property. Only if you want to support credentials from Session.login() to be used dynamically for repository configuration, eg. as credentials for a JDBC connection. If all you want is to support short URLs in the RepositoryFactory.getRepository() you don't need to override Session... and as I just noticed, you can obviously do this in the RepositoryFactory (if it knows about JR's RepositoryImpl and can do dynamic configuration). So my +1 was a bit off... I don't see much use in this atm. If it is easy to change jr to allow for lazy initialization along the way, ok, but I wouldn't see this as having less priority compared to other planned changes in j3. Regards, Alex -- Alexander Klimetschek alexander.klimetsc...@day.com
[jira] Commented: (JCR-1248) Helper Method to escape illegal XPath Search Term
[ https://issues.apache.org/jira/browse/JCR-1248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12839819#action_12839819 ] Paco Avila commented on JCR-1248: - A query like this will fail: //element(*, nt:base)[jcr:contains(., 'test[')] Specification JSR-170 at point 6.6.5.2 says that literal instances like single quote ( ' ), double quote ( ) and hyphen ( - ) must be escaped with a backslash ( \ ), and backslash itself should be escaped as a double backslash ( \\ ). Also, I have noted that some chars like [ and ] need to be escaped also. Helper Method to escape illegal XPath Search Term - Key: JCR-1248 URL: https://issues.apache.org/jira/browse/JCR-1248 Project: Jackrabbit Content Repository Issue Type: New Feature Components: jackrabbit-jcr-commons Reporter: Claus Köll Assignee: Claus Köll Priority: Minor Fix For: 1.5.0 Attachments: patch.txt If you try to perform a search like this //element(*, nt:base)[jcr:contains(., 'test!')] you get this exception javax.jcr.RepositoryException: Exception building query: org.apache.jackrabbit.core.query.lucene.fulltext.ParseException: Encountered EOF at line 1, column 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-1248) Helper Method to escape illegal XPath Search Term
[ https://issues.apache.org/jira/browse/JCR-1248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12839819#action_12839819 ] Paco Avila edited comment on JCR-1248 at 3/1/10 7:38 PM: - A query like this will fail: //element(*, nt:base)[jcr:contains(., 'test \ done')] Specification JSR-170 at point 6.6.5.2 says that literal instances like single quote ( ' ), double quote ( ) and hyphen ( - ) must be escaped with a backslash ( \ ), and backslash itself should be escaped as a double backslash ( \\ ). Also, I have noted that some chars like [ and ] need to be escaped also. was (Author: monkiki): A query like this will fail: //element(*, nt:base)[jcr:contains(., 'test[')] Specification JSR-170 at point 6.6.5.2 says that literal instances like single quote ( ' ), double quote ( ) and hyphen ( - ) must be escaped with a backslash ( \ ), and backslash itself should be escaped as a double backslash ( \\ ). Also, I have noted that some chars like [ and ] need to be escaped also. Helper Method to escape illegal XPath Search Term - Key: JCR-1248 URL: https://issues.apache.org/jira/browse/JCR-1248 Project: Jackrabbit Content Repository Issue Type: New Feature Components: jackrabbit-jcr-commons Reporter: Claus Köll Assignee: Claus Köll Priority: Minor Fix For: 1.5.0 Attachments: patch.txt If you try to perform a search like this //element(*, nt:base)[jcr:contains(., 'test!')] you get this exception javax.jcr.RepositoryException: Exception building query: org.apache.jackrabbit.core.query.lucene.fulltext.ParseException: Encountered EOF at line 1, column 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-2524) Reduce memory usage of DocIds
[ https://issues.apache.org/jira/browse/JCR-2524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated JCR-2524: -- Status: Patch Available (was: Open) Reduce memory usage of DocIds - Key: JCR-2524 URL: https://issues.apache.org/jira/browse/JCR-2524 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-core Reporter: Marcel Reutegger Priority: Minor Attachments: JCR-2524.patch Implementations of DocIds are used to cache parent child relations of nodes in the index. Usually there are a lot of duplicate objects because a DocId instance is used to identify the parent of a node in the index. That is, sibling nodes will all have DocIds with the same value. Currently a new DocId instance is created for each node. Caching the most recently used DocIds and reuse them might help to reduce the memory usage. Furthermore there are DocIds that could be represented with a short instead of an int when possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-2524) Reduce memory usage of DocIds
[ https://issues.apache.org/jira/browse/JCR-2524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated JCR-2524: -- Attachment: JCR-2524.patch Proposed patch. Reduce memory usage of DocIds - Key: JCR-2524 URL: https://issues.apache.org/jira/browse/JCR-2524 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-core Reporter: Marcel Reutegger Priority: Minor Attachments: JCR-2524.patch Implementations of DocIds are used to cache parent child relations of nodes in the index. Usually there are a lot of duplicate objects because a DocId instance is used to identify the parent of a node in the index. That is, sibling nodes will all have DocIds with the same value. Currently a new DocId instance is created for each node. Caching the most recently used DocIds and reuse them might help to reduce the memory usage. Furthermore there are DocIds that could be represented with a short instead of an int when possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-2524) Reduce memory usage of DocIds
[ https://issues.apache.org/jira/browse/JCR-2524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12839855#action_12839855 ] Marcel Reutegger commented on JCR-2524: --- Forgot to mention that the proposed patch reduces the memory usage to about a third. Reduce memory usage of DocIds - Key: JCR-2524 URL: https://issues.apache.org/jira/browse/JCR-2524 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-core Reporter: Marcel Reutegger Priority: Minor Attachments: JCR-2524.patch Implementations of DocIds are used to cache parent child relations of nodes in the index. Usually there are a lot of duplicate objects because a DocId instance is used to identify the parent of a node in the index. That is, sibling nodes will all have DocIds with the same value. Currently a new DocId instance is created for each node. Caching the most recently used DocIds and reuse them might help to reduce the memory usage. Furthermore there are DocIds that could be represented with a short instead of an int when possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1697) Simple Google style query
[ https://issues.apache.org/jira/browse/JCR-1697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12839860#action_12839860 ] Paco Avila commented on JCR-1697: - The GQL.execute() returns a RowIterator and would be nice to return a QueryResult, so I can make a result.getColumnNames() to get the returned column names. Or perhaps better, make public the method which translates the GQL query to XPath so I can pass it to the QueryManager and execute it. Simple Google style query - Key: JCR-1697 URL: https://issues.apache.org/jira/browse/JCR-1697 Project: Jackrabbit Content Repository Issue Type: New Feature Components: jackrabbit-jcr-commons Reporter: Marcel Reutegger Priority: Minor Fix For: 1.5.0 In the Sling project there's a need for a simple query language. See SLING-573. I've created a parser that translates the simple query into an XPath query statement and executes it on a JCR workspace. I'll commit it to the jackrabbit-jcr-commons module. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1697) Simple Google style query
[ https://issues.apache.org/jira/browse/JCR-1697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12839864#action_12839864 ] Paco Avila commented on JCR-1697: - Another option is to handle these kind of queries internally making possible to run it as: queryManager.createQuery(statement, type); Where type could be gql in this case, and the statement a GQL query. Simple Google style query - Key: JCR-1697 URL: https://issues.apache.org/jira/browse/JCR-1697 Project: Jackrabbit Content Repository Issue Type: New Feature Components: jackrabbit-jcr-commons Reporter: Marcel Reutegger Priority: Minor Fix For: 1.5.0 In the Sling project there's a need for a simple query language. See SLING-573. I've created a parser that translates the simple query into an XPath query statement and executes it on a JCR workspace. I'll commit it to the jackrabbit-jcr-commons module. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1697) Simple Google style query
[ https://issues.apache.org/jira/browse/JCR-1697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12839877#action_12839877 ] johann sorel commented on JCR-1697: --- GQL has no relation with JCR. it is just a candidate amoung several others (like Common Query Language or Contextual Query Language) to write a query. See : http://www.loc.gov/standards/sru/specs/cql.html CQL and GQL are not part of the JCR, and having the Google name in it does give it any rights to live in the JCR common module. If you need another query language I suggest you add it in a different module, this way you won't force everyone to have it if they don't want it. Some of my projects rely on the jcr-commun module and I hope it will remain dedicated to pure JCR. Simple Google style query - Key: JCR-1697 URL: https://issues.apache.org/jira/browse/JCR-1697 Project: Jackrabbit Content Repository Issue Type: New Feature Components: jackrabbit-jcr-commons Reporter: Marcel Reutegger Priority: Minor Fix For: 1.5.0 In the Sling project there's a need for a simple query language. See SLING-573. I've created a parser that translates the simple query into an XPath query statement and executes it on a JCR workspace. I'll commit it to the jackrabbit-jcr-commons module. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-2525) NodeState and NodeStateListener deadlock
NodeState and NodeStateListener deadlock Key: JCR-2525 URL: https://issues.apache.org/jira/browse/JCR-2525 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Affects Versions: 1.6.1, 1.6.0 Reporter: Frederic Guilbeault Priority: Critical Java stack information for the threads listed above: === jmssecondaryApplnJobExecutor-8: at org.apache.jackrabbit.core.state.NodeState.getChildNodeEntry(NodeState.java:300) - waiting to lock 0x9e6c6d08 (a org.apache.jackrabbit.core.state.NodeState) at org.apache.jackrabbit.core.CachingHierarchyManager.nodeModified(CachingHierarchyManager.java:316) - locked 0xa09882a8 (a java.lang.Object) at org.apache.jackrabbit.core.CachingHierarchyManager.stateModified(CachingHierarchyManager.java:293) at org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateModified(StateChangeDispatcher.java:111) at org.apache.jackrabbit.core.state.SessionItemStateManager.stateModified(SessionItemStateManager.java:889) at org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateModified(StateChangeDispatcher.java:111) at org.apache.jackrabbit.core.state.LocalItemStateManager.stateModified(LocalItemStateManager.java:452) at org.apache.jackrabbit.core.state.XAItemStateManager.stateModified(XAItemStateManager.java:602) at org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateModified(StateChangeDispatcher.java:111) at org.apache.jackrabbit.core.state.SharedItemStateManager.stateModified(SharedItemStateManager.java:400) at org.apache.jackrabbit.core.state.ItemState.notifyStateUpdated(ItemState.java:244) at org.apache.jackrabbit.core.state.ChangeLog.persisted(ChangeLog.java:297) at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:749) at org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:1115) at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:351) at org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:354) at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:326) at org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:325) at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:) - locked 0x9b1b0be0 (a org.apache.jackrabbit.core.XASessionImpl) at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:915) at org.apache.jackrabbit.jca.JCASessionHandle.save(JCASessionHandle.java:180) ... at sun.reflect.GeneratedMethodAccessor1067.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:36) at sun.reflect.GeneratedMethodAccessor110.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:243) at javax.management.modelmbean.RequiredModelMBean.invokeMethod(RequiredModelMBean.java:1074) at javax.management.modelmbean.RequiredModelMBean.invoke(RequiredModelMBean.java:955) at org.springframework.jmx.export.SpringModelMBean.invoke(SpringModelMBean.java:88) at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164) at org.jboss.mx.modelmbean.RequiredModelMBeanInvoker.invoke(RequiredModelMBeanInvoker.java:127) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.system.server.jmx.LazyMBeanServer.invoke(LazyMBeanServer.java:291) at javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:288) at $Proxy692.doDiscoveryNow(Unknown Source) ... at org.springframework.jms.listener.AbstractMessageListenerContainer.doInvokeListener(AbstractMessageListenerContainer.java:531) at org.springframework.jms.listener.AbstractMessageListenerContainer.invokeListener(AbstractMessageListenerContainer.java:466) at org.springframework.jms.listener.AbstractMessageListenerContainer.doExecuteListener(AbstractMessageListenerContainer.java:435) at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:322) at
[jira] Commented: (JCR-2525) NodeState and NodeStateListener deadlock
[ https://issues.apache.org/jira/browse/JCR-2525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12839913#action_12839913 ] Frederic Guilbeault commented on JCR-2525: -- Proposed solution would be to introduce a method with NodeStateListener to return a monitor object or null, if not required. Then NodeState would always lock the NodeStateListener monitor first, and itself second. This way the lock order would always be: First NodeStateListener, Second NodeState. NodeState and NodeStateListener deadlock Key: JCR-2525 URL: https://issues.apache.org/jira/browse/JCR-2525 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Affects Versions: 1.6.0, 1.6.1 Reporter: Frederic Guilbeault Priority: Critical Java stack information for the threads listed above: === jmssecondaryApplnJobExecutor-8: at org.apache.jackrabbit.core.state.NodeState.getChildNodeEntry(NodeState.java:300) - waiting to lock 0x9e6c6d08 (a org.apache.jackrabbit.core.state.NodeState) at org.apache.jackrabbit.core.CachingHierarchyManager.nodeModified(CachingHierarchyManager.java:316) - locked 0xa09882a8 (a java.lang.Object) at org.apache.jackrabbit.core.CachingHierarchyManager.stateModified(CachingHierarchyManager.java:293) at org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateModified(StateChangeDispatcher.java:111) at org.apache.jackrabbit.core.state.SessionItemStateManager.stateModified(SessionItemStateManager.java:889) at org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateModified(StateChangeDispatcher.java:111) at org.apache.jackrabbit.core.state.LocalItemStateManager.stateModified(LocalItemStateManager.java:452) at org.apache.jackrabbit.core.state.XAItemStateManager.stateModified(XAItemStateManager.java:602) at org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateModified(StateChangeDispatcher.java:111) at org.apache.jackrabbit.core.state.SharedItemStateManager.stateModified(SharedItemStateManager.java:400) at org.apache.jackrabbit.core.state.ItemState.notifyStateUpdated(ItemState.java:244) at org.apache.jackrabbit.core.state.ChangeLog.persisted(ChangeLog.java:297) at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:749) at org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:1115) at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:351) at org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:354) at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:326) at org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:325) at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:) - locked 0x9b1b0be0 (a org.apache.jackrabbit.core.XASessionImpl) at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:915) at org.apache.jackrabbit.jca.JCASessionHandle.save(JCASessionHandle.java:180) ... at sun.reflect.GeneratedMethodAccessor1067.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:36) at sun.reflect.GeneratedMethodAccessor110.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:243) at javax.management.modelmbean.RequiredModelMBean.invokeMethod(RequiredModelMBean.java:1074) at javax.management.modelmbean.RequiredModelMBean.invoke(RequiredModelMBean.java:955) at org.springframework.jmx.export.SpringModelMBean.invoke(SpringModelMBean.java:88) at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164) at org.jboss.mx.modelmbean.RequiredModelMBeanInvoker.invoke(RequiredModelMBeanInvoker.java:127) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.system.server.jmx.LazyMBeanServer.invoke(LazyMBeanServer.java:291) at javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:288) at $Proxy692.doDiscoveryNow(Unknown Source) ... at
