Re: Session handling problem
hi shane On 2/1/07, Shane Preater [EMAIL PROTECTED] wrote: Hi all, I am getting an intermittnet problem with jackrabbit sessions . Basically everything seems fine but every now and again when trying to acquire a session the system seems to lock up. what do you mean by 'lock up'? does the Repository.login call block? a dead-lock? anyway, a thread dump would help analyzing the issue... Are there any known issues with either: 1) Sharing sessions using commons-pooling? 2) Doing workspace scoped operations (clone etc) while other people are performing session scoped operations like saving nodes? These will probably not both be affecting the same node (Although I can not confirm this but based on the workflow our users perform it should not be the case) ? there's a known limitation/issue: calls to the persistence layer are effetively serialized in order to ensure data consistency.e.g. large workspace-scoped operations might affect performance of other concurrent workspace or session-scoped save operations. for more details see http://issues.apache.org/jira/browse/JCR-314 cheers stefan Any help would be great. Thanks, Shane.
Re: Session handling problem
It would appear that the call to login is blocking. But we have only experienced this in our live environment which I don't have direct access to so I am relying on second hand information. Also for this reason getting a thread dump is more difficult. Leave this with me and I will try and put some more logging into the system. Also I will see if the services team can grab me a thread dump. Although I wonder if the limitation you have linked me with could be my problem. I will do some more investigation and update you once I have a bit more information. Thanks for taking the time to give me some more ideas, Shane. On 01/02/07, Stefan Guggisberg [EMAIL PROTECTED] wrote: hi shane On 2/1/07, Shane Preater [EMAIL PROTECTED] wrote: Hi all, I am getting an intermittnet problem with jackrabbit sessions . Basically everything seems fine but every now and again when trying to acquire a session the system seems to lock up. what do you mean by 'lock up'? does the Repository.login call block? a dead-lock? anyway, a thread dump would help analyzing the issue... Are there any known issues with either: 1) Sharing sessions using commons-pooling? 2) Doing workspace scoped operations (clone etc) while other people are performing session scoped operations like saving nodes? These will probably not both be affecting the same node (Although I can not confirm this but based on the workflow our users perform it should not be the case) ? there's a known limitation/issue: calls to the persistence layer are effetively serialized in order to ensure data consistency.e.g. large workspace-scoped operations might affect performance of other concurrent workspace or session-scoped save operations. for more details see http://issues.apache.org/jira/browse/JCR-314 cheers stefan Any help would be great. Thanks, Shane.
[jira] Resolved: (JCR-726) Improve NodeTypeRegistry.effectiveNodeType()
[ https://issues.apache.org/jira/browse/JCR-726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bocanegra resolved JCR-726. -- Resolution: Fixed - introduced a new interface: EffectiveNodeTypeCache - renamed old implementation to EffectiveNodeTypeCacheImpl - created faster implementation BitsetENTCacheImpl that uses a bitset to store the nodetype names combination - did some fixes to the NodeTypeRegistry.getEffectiveNodeType() - improved a little bit the NodeImpl.isNodeType() the new bitset cache is about 25% faster than the old one, since it does not need to sort the nodetype names. the overhead for keeping the bitnumber-index for the nodetype names is minimal (and could be avoided completely, if built into the nodetype registry). due to a bug in the caching it could happen that the new calculated effective nodetype was not properly put back into the cache. measuring the Node.isNodeType() performance shows about 20% performance gain for simple nodes (where the bug mentioned above had no effect), and about 100 times faster results in the other cases. Improve NodeTypeRegistry.effectiveNodeType() Key: JCR-726 URL: https://issues.apache.org/jira/browse/JCR-726 Project: Jackrabbit Issue Type: Improvement Components: nodetype Affects Versions: 0.9, 1.0, 1.0.1, 1.1, 1.1.1, 1.2.1 Reporter: Tobias Bocanegra Assigned To: Tobias Bocanegra Priority: Minor The current getEffectiveNodeType() implementation has a minor bug that prevents from proper caching for certain nodetype combinations. further performance enhancements can be made to the effective node type 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-727) NamespaceRegistryTest uses an invalid URI as namespace URI
NamespaceRegistryTest uses an invalid URI as namespace URI -- Key: JCR-727 URL: https://issues.apache.org/jira/browse/JCR-727 Project: Jackrabbit Issue Type: Bug Components: test Reporter: Julian Reschke Priority: Trivial The test cases use www.apache.org/... as a namespace URI, but this is not a URI. Suggest to fix by using a proper URI, such as by prefixing with http://;. A related question is what our expectation is for JCR implementations. Are they allowed to reject something that doesn't parse as a URI according to RFC3986? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-727) NamespaceRegistryTest uses an invalid URI as namespace URI
[ https://issues.apache.org/jira/browse/JCR-727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke resolved JCR-727. Resolution: Fixed Fixed with revision 502263. NamespaceRegistryTest uses an invalid URI as namespace URI -- Key: JCR-727 URL: https://issues.apache.org/jira/browse/JCR-727 Project: Jackrabbit Issue Type: Bug Components: test Reporter: Julian Reschke Priority: Trivial The test cases use www.apache.org/... as a namespace URI, but this is not a URI. Suggest to fix by using a proper URI, such as by prefixing with http://;. A related question is what our expectation is for JCR implementations. Are they allowed to reject something that doesn't parse as a URI according to RFC3986? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-727) NamespaceRegistryTest uses an invalid URI as namespace URI
[ https://issues.apache.org/jira/browse/JCR-727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469519 ] Jukka Zitting commented on JCR-727: --- A related question is what our expectation is for JCR implementations. Are they allowed to reject something that doesn't parse as a URI according to RFC3986? I don't recall the JCR spec saying anything about this, but since XML namespace (http://www.w3.org/TR/REC-xml-names/) names are RFC 3986 URIs, I think it would be perfectly OK for a repository implementatino to only allow valid URIs. One concrete benefit of such a policy would be the avoidance of invalid namespace names in XML exports. In fact we may even want to consider enforcing this in Jackrabbit. PS. The www.apache.org/... name can actually be interpreted as a relative URI, and is only deprecated but not strictly prohibited by the current XML namespace spec. NamespaceRegistryTest uses an invalid URI as namespace URI -- Key: JCR-727 URL: https://issues.apache.org/jira/browse/JCR-727 Project: Jackrabbit Issue Type: Bug Components: test Reporter: Julian Reschke Priority: Trivial The test cases use www.apache.org/... as a namespace URI, but this is not a URI. Suggest to fix by using a proper URI, such as by prefixing with http://;. A related question is what our expectation is for JCR implementations. Are they allowed to reject something that doesn't parse as a URI according to RFC3986? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-727) NamespaceRegistryTest uses an invalid URI as namespace URI
[ https://issues.apache.org/jira/browse/JCR-727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469521 ] Julian Reschke commented on JCR-727: Just a nit: www.apache.org/... is a relative reference (http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.4.2), but not a URI (http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.3). NamespaceRegistryTest uses an invalid URI as namespace URI -- Key: JCR-727 URL: https://issues.apache.org/jira/browse/JCR-727 Project: Jackrabbit Issue Type: Bug Components: test Reporter: Julian Reschke Priority: Trivial The test cases use www.apache.org/... as a namespace URI, but this is not a URI. Suggest to fix by using a proper URI, such as by prefixing with http://;. A related question is what our expectation is for JCR implementations. Are they allowed to reject something that doesn't parse as a URI according to RFC3986? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-729) Index all binary properties
Index all binary properties --- Key: JCR-729 URL: https://issues.apache.org/jira/browse/JCR-729 Project: Jackrabbit Issue Type: Improvement Components: indexing Reporter: Jukka Zitting Priority: Minor Once the automatic MIME type detection requested by JCR-728 is implemented, Jackrabbit could well index all binary properties instead of just the jcr:data properties with related jcr:mimeTypes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Apache Jackrabbit 1.2.2 release plan
Hi, On 2/1/07, Jaka Jaksic [EMAIL PROTECTED] wrote: I've just created the issue JCR-725 (about making cache sizes in CacheManager configurable) and attached a proposed patch. Do you think it could be included in 1.2.2? In principle I'd rather not introduce feature changes in patch releases. I'll probably be targetting to release Jackrabbit 1.3 in March, and I'd prefer to include this change in 1.3 perhaps even with related options in the repository.xml configuration file. However, you're right in that the change is quite trivial, and I'm already breaking the strict bug fix policy in 1.2.2 by introducing clustering improvements, so if you're in a hurry with this then I can consider including the change already now. BR, Jukka Zitting
[jira] Commented: (JCR-728) Automatic MIME type detection
[ https://issues.apache.org/jira/browse/JCR-728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469540 ] Paco Avila commented on JCR-728: I'm currently evaluating http://jmimemagic.sourceforge.net/ but seems a bit limited in some cases. But is the best option for now. Automatic MIME type detection - Key: JCR-728 URL: https://issues.apache.org/jira/browse/JCR-728 Project: Jackrabbit Issue Type: Improvement Components: indexing Reporter: Jukka Zitting Priority: Minor Currently only the jcr:mimeType property is used to determine the MIME type and thus the applicable text extractor to use for indexing a document. If the jcr:mimeType property is not available or is set to a generic value like application/octet-stream, then the indexer could also use some heuristics based on the node name or magic numbers within the binary stream to determine the type of the document. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-728) Automatic MIME type detection
[ https://issues.apache.org/jira/browse/JCR-728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469541 ] Paco Avila commented on JCR-728: In Linux there are lots of magic definitions in the file /usr/share/file/magic. Automatic MIME type detection - Key: JCR-728 URL: https://issues.apache.org/jira/browse/JCR-728 Project: Jackrabbit Issue Type: Improvement Components: indexing Reporter: Jukka Zitting Priority: Minor Currently only the jcr:mimeType property is used to determine the MIME type and thus the applicable text extractor to use for indexing a document. If the jcr:mimeType property is not available or is set to a generic value like application/octet-stream, then the indexer could also use some heuristics based on the node name or magic numbers within the binary stream to determine the type of the document. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-728) Automatic MIME type detection
[ https://issues.apache.org/jira/browse/JCR-728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469546 ] Jukka Zitting commented on JCR-728: --- I've looked at jmimemagic too, but as you mentioned, it's a bit limited. It's also licensed under the LGPL, which makes it a bit troublesome for us. There's a recent codebase at http://hedges.net/archives/2006/11/08/java-shared-mime-info/ that seems pretty good, but the code is under the GPL. I recently discussed with some people form Apache Nutch about a project to implement the shared mime info standard from freedesktop.org (http://www.freedesktop.org/wiki/Standards_2fshared_2dmime_2dinfo_2dspec), and apparently someone already had some Apache-licensed code for that but I haven't yet seen it. I've been planning to propose an implementation project for the mime info standard in Apache Labs (http://labs.apache.org/), but if there's more interest within the Jackrabbit community we could also start working on it within the jackrabbit-text-extractors component. Automatic MIME type detection - Key: JCR-728 URL: https://issues.apache.org/jira/browse/JCR-728 Project: Jackrabbit Issue Type: Improvement Components: indexing Reporter: Jukka Zitting Priority: Minor Currently only the jcr:mimeType property is used to determine the MIME type and thus the applicable text extractor to use for indexing a document. If the jcr:mimeType property is not available or is set to a generic value like application/octet-stream, then the indexer could also use some heuristics based on the node name or magic numbers within the binary stream to determine the type of the document. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: What is difference between repository index and workspace index
Hi, On 2/1/07, wendy Lee [EMAIL PROTECTED] wrote: I just find the index size under repository directory is smaller than the workspace directory.Who can help me understand this.Thanks! The repository directory contains the index of the version store that is shared by all workspaces. Each workspace directory contains the index of content within that workspace. Thus you can expect the repository index to be smaller than a workspace index if you don't use versioning or if only a part of your content is versioned. BR, Jukka Zitting
RE: Apache Jackrabbit 1.2.2 release plan
Hi! I've just created the issue JCR-725 (about making cache sizes in CacheManager configurable) and attached a proposed patch. Do you think it could be included in 1.2.2? In principle I'd rather not introduce feature changes in patch releases. I'll probably be targetting to release Jackrabbit 1.3 in March, and I'd prefer to include this change in 1.3 perhaps even with related options in the repository.xml configuration file. However, you're right in that the change is quite trivial, and I'm already breaking the strict bug fix policy in 1.2.2 by introducing clustering improvements, so if you're in a hurry with this then I can consider including the change already now. Thank you for considering my patch for inclusion. We're not in that much of a hurry just yet. However, we will need to have a stable release of our product ready in March and it's not certain if Jackrabbit 1.3 will be ready and stable soon enough, and whether its release will fit into our releace cycle etc. That's why I'd like to see this patch squeezed into 1.2.2., if possible, just to be sure... But only if this doesn't cause much trouble for you. Obviously this fix is not something critical, so it's up to you to decide. Regards, Jaka
