[jira] Commented: (JCR-1312) Get rid of DOM for XML support
[ https://issues.apache.org/jira/browse/JCR-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559856#action_12559856 ] Jukka Zitting commented on JCR-1312: Jackrabbit is not an XML parser project. Definitely agreed on that one. And yet you're proposing to add 350+ LOC with no other purpose than XML parsing. The code is nontrivial and I'm certainly not convinced that it doesn't have bugs or doesn't overlook some DOM semantics that we may or may not rely on. IMHO given advantages (memory footprint (1% of Xerces) and performance (40-60% of Xerces)) this is probably a small price to pay :-) I don't agree. JCR-1310 is a better way to drop the Xerces jar and the performance improvement is IMHO only relevant if it translates to real-world use cases. I don't see that happening here, especially in light of what Julian and Ian said, but feel free to prove me otherwise. I'd resolve this as Won't Fix. Get rid of DOM for XML support -- Key: JCR-1312 URL: https://issues.apache.org/jira/browse/JCR-1312 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-webdav Reporter: Felix Meschberger Currently the web dav library uses Xerces and DOM to parse and create XML data. This mechanism is well-known but has two major issues: It is slow and it has a big memory footprint. In order to solve these two issues, I suggest to drop the use of the W3C DOM in webdav in favor of something easier and more straight forward to use. One candidate could be (out of my head and based on my bias towards KXml) KDOM. See also http://www.kxml.org.ww See also JCR-1261 for more discussions on this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1312) Get rid of DOM for XML support
[ https://issues.apache.org/jira/browse/JCR-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559858#action_12559858 ] Felix Meschberger commented on JCR-1312: Yes, but most of these 350+ lines of code are copied and used elsewhere ... So chances are, they are very well tested. Given real-world performance figure requirements: I tested these while accessing the repository using Gnome VFS and browsing around in the repository and creating/deleting files ! So this is certainly kind of real-world. Get rid of DOM for XML support -- Key: JCR-1312 URL: https://issues.apache.org/jira/browse/JCR-1312 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-webdav Reporter: Felix Meschberger Currently the web dav library uses Xerces and DOM to parse and create XML data. This mechanism is well-known but has two major issues: It is slow and it has a big memory footprint. In order to solve these two issues, I suggest to drop the use of the W3C DOM in webdav in favor of something easier and more straight forward to use. One candidate could be (out of my head and based on my bias towards KXml) KDOM. See also http://www.kxml.org.ww See also JCR-1261 for more discussions on this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (JCR-1312) Get rid of DOM for XML support
Am Mittwoch, den 16.01.2008, 17:01 +0100 schrieb Thomas Mueller: Hi, My experience is that all XML parser are a little bit different. I don't know about you, but I did run into quite many problems because of XML parser incompatibilities. If we always use the same parser we would be sure we always get the same result on all systems. I believe that would be a big advantage, what do you think? Definitely +1, esp. since using JAXP you can never be sure, which parser you actually get and end up trying to workaround bugs of all venues ... For these reasons, I like small and simple ones doing what I need and not providing functionality I probably never will need (e.g. XNI) in the near feature Regards Felix Regards, Thomas
[jira] Commented: (JCR-1312) Get rid of DOM for XML support
[ https://issues.apache.org/jira/browse/JCR-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559859#action_12559859 ] Jukka Zitting commented on JCR-1312: copied and used elsewhere is a warning sign. We should be getting that functionality from a library, not duplicating it in our codebase. Did you see the 40-60% performance improvement when using VFS? If that's right (figures, test setup?), then yes, I'd be ready to even duplicate code! Get rid of DOM for XML support -- Key: JCR-1312 URL: https://issues.apache.org/jira/browse/JCR-1312 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-webdav Reporter: Felix Meschberger Currently the web dav library uses Xerces and DOM to parse and create XML data. This mechanism is well-known but has two major issues: It is slow and it has a big memory footprint. In order to solve these two issues, I suggest to drop the use of the W3C DOM in webdav in favor of something easier and more straight forward to use. One candidate could be (out of my head and based on my bias towards KXml) KDOM. See also http://www.kxml.org.ww See also JCR-1261 for more discussions on this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (JCR-1312) Get rid of DOM for XML support
Felix Meschberger wrote: Am Mittwoch, den 16.01.2008, 17:01 +0100 schrieb Thomas Mueller: Hi, My experience is that all XML parser are a little bit different. I don't know about you, but I did run into quite many problems because of XML parser incompatibilities. If we always use the same parser we would be sure we always get the same result on all systems. I believe that would be a big advantage, what do you think? Definitely +1, esp. since using JAXP you can never be sure, which parser you actually get and end up trying to workaround bugs of all venues ... We suffered from this problem in Cocoon for years - although we felt that using JAXP was the way to go. So we created a lot of workarounds for various bugs in the different implementations - which obviously is rather ugly. Then we decided to require a specific version of the parser which is as bug free as possible. So users had to put it up into the hell of lib/endorsed - and of course this created a bunch of other problems (users forgot about it or were not allowed etc.). So the final solution is to ensure to use the right version without relying on others (being it users or the jdk). The only way of achieving this however is to have an own classloader...so, although we are speaking of a webapp, the webapp creates its own classloader which loads acts classes from WEB-INF/classes and WEB-INF/lib *before* the parent classloader. Then you can put the JAXP impl into WEB-INF/lib and are done. Ok, heavy solution for such a problem. But it even gets better :) (stranger?): We also developed a maven plugin that created this classloader during development: every servlet, filter, listener etc. declared in web.xml gets wrapped by an own implementation using the custom classloader. So the whole thing is transparent (and therefore even more scary). Just to give another option/opinion. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: [jira] Commented: (JCR-1312) Get rid of DOM for XML support
Hi, getting that functionality from a library The problem I see is version conflicts. What if the application uses a different version of the same library. copied and used elsewhere Do these +350 lines mean completely avoiding version conflicts and removing one dependency? That would sounds OK to me. Personally, I really don't like copied source code inside the same project. using JAXP you can never be sure which parser you actually get Trying to support all XML parser implementations and versions sounds a bit like trying to support all SQL databases to me. What do other people think about using JAXP? Those links are a bit old: http://www.mail-archive.com/[EMAIL PROTECTED]/msg00787.html https://jaxp.dev.java.net/1.4/JAXP-Compatibility.html Regards, Thomas
[jira] Commented: (JCR-1312) Get rid of DOM for XML support
[ https://issues.apache.org/jira/browse/JCR-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559878#action_12559878 ] Felix Meschberger commented on JCR-1312: Test setup is: * I count the number of milliseconds used to parse the request or serialize the response inside the respective class (there are fortunately only two locations, one parsing and one serializing). To get somewhat meaningfull numbers, I force repeated parsing and serialization on a single request. * Server was a microsling setup, that is standard Simple WebDAV servlet configuration * Client and server was a Fedorar 7 machine running Java 5 I do not have the absolute numbers anymore... And yes, the improvement is just parsing and serializing, the other parameters were unchanged, that is completely ignoring and kernel networking latency etc. Get rid of DOM for XML support -- Key: JCR-1312 URL: https://issues.apache.org/jira/browse/JCR-1312 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-webdav Reporter: Felix Meschberger Currently the web dav library uses Xerces and DOM to parse and create XML data. This mechanism is well-known but has two major issues: It is slow and it has a big memory footprint. In order to solve these two issues, I suggest to drop the use of the W3C DOM in webdav in favor of something easier and more straight forward to use. One candidate could be (out of my head and based on my bias towards KXml) KDOM. See also http://www.kxml.org.ww See also JCR-1261 for more discussions on this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1319) NullPointerException when accessing the SimpleWebdavServlet at the prefix path
[ https://issues.apache.org/jira/browse/JCR-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated JCR-1319: --- Attachment: JCR-1319.patch Proposed patch. When actually appliying this patch, I get back a 404 instead of the NullPointerException. I think, this is ok. NullPointerException when accessing the SimpleWebdavServlet at the prefix path -- Key: JCR-1319 URL: https://issues.apache.org/jira/browse/JCR-1319 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-jcr-server Affects Versions: 1.4, 1.5 Reporter: Felix Meschberger Attachments: JCR-1319.patch When accessing the SimpleWebdavServlet with the root path, that is the same path as set with the resource-path-prefix, a NullPointerException is thrown: java.lang.NullPointerException at org.apache.jackrabbit.name.ParsingPathResolver.getQPath(ParsingPathResolver.java:91) at org.apache.jackrabbit.name.CachingPathResolver.getQPath(CachingPathResolver.java:74) at org.apache.jackrabbit.core.SessionImpl.getQPath(SessionImpl.java:601) at org.apache.jackrabbit.core.SessionImpl.getItem(SessionImpl.java:804) at org.apache.sling.jcr.api.internal.PooledSession.getItem(PooledSession.java:157) at org.apache.jackrabbit.webdav.simple.ResourceFactoryImpl.getNode(ResourceFactoryImpl.java:140) at org.apache.jackrabbit.webdav.simple.ResourceFactoryImpl.createResource(ResourceFactoryImpl.java:89) at org.apache.jackrabbit.webdav.server.AbstractWebdavServlet.service(AbstractWebdavServlet.java:187) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362) at org.ops4j.pax.web.service.internal.HttpServiceServletHandler.handle(HttpServiceServletHandler.java:51) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:722) at org.ops4j.pax.web.service.internal.HttpServiceContext.handle(HttpServiceContext.java:87) at org.ops4j.pax.web.service.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:63) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) at org.mortbay.jetty.Server.handle(Server.java:324) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:828) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:514) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380) at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228) at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:450) The problem seems to be that the ResourceFactoryImpl.createResource method (or rather the getNode method) is not prepared to a DavResourceLocator instance whose resourcePath is null. I could imagine, that the ResourceFactoryImpl.getNode() method might want to return the root node in this case ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1319) NullPointerException when accessing the SimpleWebdavServlet at the prefix path
NullPointerException when accessing the SimpleWebdavServlet at the prefix path -- Key: JCR-1319 URL: https://issues.apache.org/jira/browse/JCR-1319 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-jcr-server Affects Versions: 1.4, 1.5 Reporter: Felix Meschberger When accessing the SimpleWebdavServlet with the root path, that is the same path as set with the resource-path-prefix, a NullPointerException is thrown: java.lang.NullPointerException at org.apache.jackrabbit.name.ParsingPathResolver.getQPath(ParsingPathResolver.java:91) at org.apache.jackrabbit.name.CachingPathResolver.getQPath(CachingPathResolver.java:74) at org.apache.jackrabbit.core.SessionImpl.getQPath(SessionImpl.java:601) at org.apache.jackrabbit.core.SessionImpl.getItem(SessionImpl.java:804) at org.apache.sling.jcr.api.internal.PooledSession.getItem(PooledSession.java:157) at org.apache.jackrabbit.webdav.simple.ResourceFactoryImpl.getNode(ResourceFactoryImpl.java:140) at org.apache.jackrabbit.webdav.simple.ResourceFactoryImpl.createResource(ResourceFactoryImpl.java:89) at org.apache.jackrabbit.webdav.server.AbstractWebdavServlet.service(AbstractWebdavServlet.java:187) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362) at org.ops4j.pax.web.service.internal.HttpServiceServletHandler.handle(HttpServiceServletHandler.java:51) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:722) at org.ops4j.pax.web.service.internal.HttpServiceContext.handle(HttpServiceContext.java:87) at org.ops4j.pax.web.service.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:63) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) at org.mortbay.jetty.Server.handle(Server.java:324) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:828) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:514) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380) at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228) at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:450) The problem seems to be that the ResourceFactoryImpl.createResource method (or rather the getNode method) is not prepared to a DavResourceLocator instance whose resourcePath is null. I could imagine, that the ResourceFactoryImpl.getNode() method might want to return the root node in this case ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1046) Non-versionable children of a versionable node should not be updated when a merge fails
[ https://issues.apache.org/jira/browse/JCR-1046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bocanegra resolved JCR-1046. --- Resolution: Fixed fixed the failing tests (which were wrong and partially commented out!) Non-versionable children of a versionable node should not be updated when a merge fails --- Key: JCR-1046 URL: https://issues.apache.org/jira/browse/JCR-1046 Project: Jackrabbit Issue Type: Bug Components: versioning Affects Versions: 1.3, 1.3.1, 1.3.3, 1.4, 1.5 Reporter: Bob Wieler Assignee: Tobias Bocanegra Fix For: 1.5 Attachments: jcr1046.diff The JCR specification (JSR-170) includes a merge algorithm that is inconsistent with the functionality described elsewhere in the JCR specification. Specifically from JSR-170 section 8.2.10 Merge: In either case, (regardless of whether bestEffort is true or false) for each non-versionable node (including both referenceable and non-referenceable), if the merge result of its nearest versionable ancestor is update, or if it has no versionable ancestor, then it is updated to reflect the state of its corresponding node. Otherwise, it is left unchanged. The algorithm presented in 8.2.10.1 of the specification goes against the above statement as it does not take into consideration the merge result of the nearest versionable ancestor. One solution would be to have the doLeave(n) call that dofail(n, v') calls altered to only perform a merge on the versionable children rather than all of the children. The merging of all children (versionable and non-versionable) should only be done if the nearest parent is not in a failed merge state regardless of whether the failure occurred from the current merge operation or a previous merge operation. I will attach a patch file that makes what I think is the required change. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (JCR-1312) Get rid of DOM for XML support
Hi, On Jan 16, 2008 6:01 PM, Thomas Mueller [EMAIL PROTECTED] wrote: My experience is that all XML parser are a little bit different. I don't know about you, but I did run into quite many problems because of XML parser incompatibilities. If we always use the same parser we would be sure we always get the same result on all systems. I believe that would be a big advantage, what do you think? In Jackrabbit we only use a fairly standard subset of XML functionality, mainly just parsing and serialization of relatively simple XML documents. I think the only real XML parser incompatibility issue we've faced is the xmlns serialization issue, and we have good workarounds for that. So I don't see us having many problems with using standard JAXP, and given the classloading horrors described by Carsten I would very much prefer sticking with standard JAXP. BR, Jukka Zitting
[jira] Commented: (JCR-1312) Get rid of DOM for XML support
[ https://issues.apache.org/jira/browse/JCR-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559884#action_12559884 ] Jukka Zitting commented on JCR-1312: completely ignoring and kernel networking latency etc. That's my point. I would assume that the time taken by XML parsing is insignificant when compared to both HTTP processing above and JCR processing below. Even assuming zero network and disk latencies, I don't believe that XML parsing is taking more than a fraction of total request processing time. Even a 50% performance boost to XML parsing is not likely to give any visible changes to end user performance. Besides, CPU performance is seldom the bottleneck in applications today. Get rid of DOM for XML support -- Key: JCR-1312 URL: https://issues.apache.org/jira/browse/JCR-1312 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-webdav Reporter: Felix Meschberger Currently the web dav library uses Xerces and DOM to parse and create XML data. This mechanism is well-known but has two major issues: It is slow and it has a big memory footprint. In order to solve these two issues, I suggest to drop the use of the W3C DOM in webdav in favor of something easier and more straight forward to use. One candidate could be (out of my head and based on my bias towards KXml) KDOM. See also http://www.kxml.org.ww See also JCR-1261 for more discussions on this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (JCR-1312) Get rid of DOM for XML support
Hi, Am Donnerstag, den 17.01.2008, 11:53 +0200 schrieb Jukka Zitting: Hi, On Jan 16, 2008 6:01 PM, Thomas Mueller [EMAIL PROTECTED] wrote: My experience is that all XML parser are a little bit different. I don't know about you, but I did run into quite many problems because of XML parser incompatibilities. If we always use the same parser we would be sure we always get the same result on all systems. I believe that would be a big advantage, what do you think? In Jackrabbit we only use a fairly standard subset of XML functionality, mainly just parsing and serialization of relatively simple XML documents. I think the only real XML parser incompatibility issue we've faced is the xmlns serialization issue, and we have good workarounds for that. So I don't see us having many problems with using standard JAXP, and given the classloading horrors described by Carsten I would very much prefer sticking with standard JAXP. I am not totally fluent with the state nowadays: But hasn't there been a time, that Java 1.4 included a buggy Xerces version, which could only be replaced by hacking the boot class path ?? I may of course be completely wrong. Regards Felix
Re: [jira] Commented: (JCR-1312) Get rid of DOM for XML support
Felix Meschberger wrote: Hi, Am Donnerstag, den 17.01.2008, 11:53 +0200 schrieb Jukka Zitting: Hi, On Jan 16, 2008 6:01 PM, Thomas Mueller [EMAIL PROTECTED] wrote: My experience is that all XML parser are a little bit different. I don't know about you, but I did run into quite many problems because of XML parser incompatibilities. If we always use the same parser we would be sure we always get the same result on all systems. I believe that would be a big advantage, what do you think? In Jackrabbit we only use a fairly standard subset of XML functionality, mainly just parsing and serialization of relatively simple XML documents. I think the only real XML parser incompatibility issue we've faced is the xmlns serialization issue, and we have good workarounds for that. So I don't see us having many problems with using standard JAXP, and given the classloading horrors described by Carsten I would very much prefer sticking with standard JAXP. I am not totally fluent with the state nowadays: But hasn't there been a time, that Java 1.4 included a buggy Xerces version, which could only be replaced by hacking the boot class path ?? I may of course be completely wrong. Yes, 1.4 contains buggy Xerces versions (might be that latest 1.4 revisions are bug free), and no, it's not required to put the lib into the boot classpath. An own classloader which does parent last is sufficient. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: [jira] Commented: (JCR-1312) Get rid of DOM for XML support
Hi, On Jan 17, 2008 11:57 AM, Felix Meschberger [EMAIL PROTECTED] wrote: I am not totally fluent with the state nowadays: But hasn't there been a time, that Java 1.4 included a buggy Xerces version, which could only be replaced by hacking the boot class path ?? I may of course be completely wrong. That may be the case, but we've never seen bug reports about that, so I don't think this matters to us. Without seeing actual issues with Jackrabbit and JAXP I think this parser incompatibility stuff is mostly just FUD. BR, Jukka Zitting
[jira] Created: (JCR-1320) Support for Sybase
Support for Sybase -- Key: JCR-1320 URL: https://issues.apache.org/jira/browse/JCR-1320 Project: Jackrabbit Issue Type: New Feature Components: jackrabbit-core Affects Versions: 1.4 Reporter: Guido Jäkel To use Sybase as a database backend for all the components and different implementation, one need specific sybase.ddl-files to configure a schema sybase. Sybase don't seems to be compatible to one of the already existing schema. The following files are required: * org/apache/jackrabbit/core/persistence/db/sybase.ddl * org/apache/jackrabbit/core/persistence/bundle/sybase.ddl * org/apache/jackrabbit/core/fs/db/sybase.ddl * org/apache/jackrabbit/core/journal/sybase.ddl Thank you for support. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Deadlock in XA Environment
This is only a thought... there were some deadlock issues in 1.3 that were fixed in 1.3.1... assuming by 1.3 you mean 1.3 and not 1.3.1. From what I remember they were triggered under load with the ClusterNode turned on in the config. I don't think that you needed to be running in a cluster. JCR-924 might be one of the related jiras (from failing memory) :) Ian KÖLL Claus wrote: hi, we have some time now jackrabbit (1.3) running in our pruduction environment but without xa enabled. We are running on websphere 5.1 and i have configured now a j2c resource adapter for jackrabbit. it works fine till i try to modify a node in the repository in a global transaction. if i only try a search everything works fine. i have taken a thread dump with the deadlock situation. what i can see comes the deadlock from the DefaultISMLocking$ReadLockImpl Class hope somebodycan help BR, claus javacore.20080117.103807.536.txt
AW: Deadlock in XA Environment
sorry i forgot to say that i try with the new 1.4 release ... BR, claus -Ursprüngliche Nachricht- Von: KÖLL Claus [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 17. Jänner 2008 13:45 An: dev@jackrabbit.apache.org Betreff: Deadlock in XA Environment hi, we have some time now jackrabbit (1.3) running in our pruduction environment but without xa enabled. We are running on websphere 5.1 and i have configured now a j2c resource adapter for jackrabbit. it works fine till i try to modify a node in the repository in a global transaction. if i only try a search everything works fine. i have taken a thread dump with the deadlock situation. what i can see comes the deadlock from the DefaultISMLocking$ReadLockImpl Class hope somebodycan help BR, claus javacore.20080117.103807.536.txt
Re: Deadlock in XA Environment
there were some deadlock issues in 1.3 that were fixed in 1.3.1... assuming by 1.3 you mean 1.3 and not 1.3.1. If you want to stick with 1.3, try 1.3.3 instead of 1.3.1. If not, better upgrade to 1.4. Just a suggestion. Regards, Esteban Franqueiro [EMAIL PROTECTED] Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
AW: Deadlock in XA Environment
as written before this happens with jackrabbit 1.4 BR, claus -Ursprüngliche Nachricht- Von: Esteban Franqueiro [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 17. Jänner 2008 14:36 An: dev@jackrabbit.apache.org Betreff: Re: Deadlock in XA Environment there were some deadlock issues in 1.3 that were fixed in 1.3.1... assuming by 1.3 you mean 1.3 and not 1.3.1. If you want to stick with 1.3, try 1.3.3 instead of 1.3.1. If not, better upgrade to 1.4. Just a suggestion. Regards, Esteban Franqueiro [EMAIL PROTECTED] Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
[jira] Commented: (JCR-1320) Support for Sybase
[ https://issues.apache.org/jira/browse/JCR-1320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559962#action_12559962 ] Stefan Guggisberg commented on JCR-1320: AFAIK, sybase and mssql ddl syntax is pretty similar (not that surprising, knowing their common roots ;). see e.g. http://db.apache.org/ddlutils/databases/sybase.html http://db.apache.org/ddlutils/databases/sqlserver.html chances are pretty good that the existing mssql.ddl files also work with sybase. i don't have a sybase server at hand so i can't test it myself. i'd be great if you could test my assumption and report your findings. if the mssql.ddl files don't work for sybase i'd be happy to accept patches for sybase support ;) Support for Sybase -- Key: JCR-1320 URL: https://issues.apache.org/jira/browse/JCR-1320 Project: Jackrabbit Issue Type: New Feature Components: jackrabbit-core Affects Versions: 1.4 Reporter: Guido Jäkel To use Sybase as a database backend for all the components and different implementation, one need specific sybase.ddl-files to configure a schema sybase. Sybase don't seems to be compatible to one of the already existing schema. The following files are required: * org/apache/jackrabbit/core/persistence/db/sybase.ddl * org/apache/jackrabbit/core/persistence/bundle/sybase.ddl * org/apache/jackrabbit/core/fs/db/sybase.ddl * org/apache/jackrabbit/core/journal/sybase.ddl Thank you for support. -- 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-1320) Support for Sybase
[ https://issues.apache.org/jira/browse/JCR-1320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559962#action_12559962 ] [EMAIL PROTECTED] edited comment on JCR-1320 at 1/17/08 7:50 AM: - AFAIK, sybase and mssql ddl syntax is pretty similar (not that surprising, knowing their common roots ;). see e.g. http://db.apache.org/ddlutils/databases/sybase.html http://db.apache.org/ddlutils/databases/sqlserver.html chances are pretty good that the existing mssql.ddl files also work with sybase. i don't have a sybase server at hand so i can't test it myself. it would be great if you could test my assumption and report your findings. if the mssql.ddl files don't work for sybase i'd be happy to accept patches for sybase support ;) was (Author: [EMAIL PROTECTED]): AFAIK, sybase and mssql ddl syntax is pretty similar (not that surprising, knowing their common roots ;). see e.g. http://db.apache.org/ddlutils/databases/sybase.html http://db.apache.org/ddlutils/databases/sqlserver.html chances are pretty good that the existing mssql.ddl files also work with sybase. i don't have a sybase server at hand so i can't test it myself. i'd be great if you could test my assumption and report your findings. if the mssql.ddl files don't work for sybase i'd be happy to accept patches for sybase support ;) Support for Sybase -- Key: JCR-1320 URL: https://issues.apache.org/jira/browse/JCR-1320 Project: Jackrabbit Issue Type: New Feature Components: jackrabbit-core Affects Versions: 1.4 Reporter: Guido Jäkel To use Sybase as a database backend for all the components and different implementation, one need specific sybase.ddl-files to configure a schema sybase. Sybase don't seems to be compatible to one of the already existing schema. The following files are required: * org/apache/jackrabbit/core/persistence/db/sybase.ddl * org/apache/jackrabbit/core/persistence/bundle/sybase.ddl * org/apache/jackrabbit/core/fs/db/sybase.ddl * org/apache/jackrabbit/core/journal/sybase.ddl Thank you for support. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1321) The jcr.jar file is missing from the created war file.
The jcr.jar file is missing from the created war file. -- Key: JCR-1321 URL: https://issues.apache.org/jira/browse/JCR-1321 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-webapp Affects Versions: 1.4 Reporter: Adam Hope Priority: Blocker On deploying the war file the webapp is unable to run as the javax.jcr jar file has been omitted from the war. I added it to the war file locally and re-deployed the webapp and it now runs fine. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1323) When using QueryImpl.setLimit() and QueryImpl.setOffset(), then NodeIterator.getSize() reports wrong size
When using QueryImpl.setLimit() and QueryImpl.setOffset(), then NodeIterator.getSize() reports wrong size - Key: JCR-1323 URL: https://issues.apache.org/jira/browse/JCR-1323 Project: Jackrabbit Issue Type: Bug Affects Versions: 1.4 Environment: Linux, Java 6 Reporter: Martin Zdila When using QueryImpl.setLimit() and QueryImpl.setOffset(), then NodeIterator.getSize() reports wrong size. Returned size seems to be allways the same as the limit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1322) Cluster information is not persisted to database when connected to case sensitive MS SQL Server 2005
Cluster information is not persisted to database when connected to case
sensitive MS SQL Server 2005
Key: JCR-1322
URL: https://issues.apache.org/jira/browse/JCR-1322
Project: Jackrabbit
Issue Type: Bug
Components: clustering
Affects Versions: 1.3.3
Environment: Microsoft SQL Server 2005 on Windows Server. Database is
setup to be case-sensitive.
Reporter: Vijai Kalyan
After a call to Session::save, we observed that cluster information was not
written to the ${schemaObjectPrefix}JOURNAL and
${schemaObjectPrefix}GLOBAL_REVISION tables. We tested against Oracle 10
database servers and MS Sql Server 2005 servers. The problem was noticed only
with MS Sql Server 2005.
Initially, the problem was masked since the test was written as part of our
unit test environment and the exceptions generated by JDBC were not showing up
in the logs. A separate test with was carried out as shown by the code below
pre
import java.io.FileInputStream;
import javax.jcr.Node;
import javax.jcr.Repository;
import javax.jcr.Session;
import javax.jcr.SimpleCredentials;
import org.apache.jackrabbit.core.TransientRepository;
import org.apache.jackrabbit.core.config.RepositoryConfig;
public class Main
{
public static void main(String[] args)
throws Exception
{
System.setProperty(org.apache.jackrabbit.core.cluster.node_id,
testid);
RepositoryConfig config = RepositoryConfig.create(new
FileInputStream(repository.xml), repository);
Repository repository = new TransientRepository();
Session session = repository.login(new SimpleCredentials(username,
password.toCharArray()));
Node root = session.getRootNode();
root.addNode(node1);
root.addNode(node2);
root.addNode(node3);
session.save();
}
}
/pre
The configuration file used to configure the repository is attached.
After debugging this, we obtained the exceptions that were previously not
visible. Note that, JackRabbit continues to run (is that because the cluster
code is running in a separate thread?) even after this exception. The problem
was that the 'revision_id' field did not exist. The mssql.ddl schema file sets
up the table names in capitals. However, at least two of the SQL statements in
DatabaseJournal use lower case table names. For example:-
pre
updateGlobalStmt = con.prepareStatement(
update + schemaObjectPrefix + global_revision +
set revision_id = revision_id + 1);
selectGlobalStmt = con.prepareStatement(
select revision_id +
from + schemaObjectPrefix + global_revision);
/pre
An additional error is that the mssql.ddl file is missing the following:
pre
# Inserting the one and only revision counter record now helps avoiding race
conditions
insert into ${schemaObjectPrefix}GLOBAL_REVISION VALUES(0)
/pre
Fixing the above two issues, fixed the problem with MS SQL Server 2005.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1324) strange performance issue when using XPath query
strange performance issue when using XPath query Key: JCR-1324 URL: https://issues.apache.org/jira/browse/JCR-1324 Project: Jackrabbit Issue Type: Bug Components: query Affects Versions: 1.4 Environment: Java 6, Linux Reporter: Martin Zdila I have following structure in my repository: jcr:root gfr:devices gfr:device gfr:capabilityMap There are cca 4000 gfr:device nodes. Each gfr:device has only one gfr:capabilityMap. Each gfr:capabilityMap has average 20 properties. Here are some interesting results: 1. ((QueryImpl) query).setLimit(30); ((QueryImpl) query).setOffset(anyLimit); 1.1 executing query //gfr:capabilityMap and fetching nodes takes cca 20-80ms 1.2 executing query /jcr:root/gfr:devices/gfr:device/gfr:capabilityMap and fetching nodes takes cca 2000ms Why does this take longer time if the only difference is more specific path? I would expect even shorter time of execution and not this. 2. now without proprietary limit/offset 2.1 //gfr:capabilityMap cca 150-200ms 2.2 /jcr:root/gfr:devices/gfr:device/gfr:capabilityMap cca 14000ms!!! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1312) Get rid of DOM for XML support
[ https://issues.apache.org/jira/browse/JCR-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12560103#action_12560103 ] Padraic Hannon commented on JCR-1312: - All of our current CQ publish instances are currently CPU bound. So, while, XML performance may not be the central issue, anything we can do to reduce CPU overhead would be helpful for us here. Get rid of DOM for XML support -- Key: JCR-1312 URL: https://issues.apache.org/jira/browse/JCR-1312 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-webdav Reporter: Felix Meschberger Currently the web dav library uses Xerces and DOM to parse and create XML data. This mechanism is well-known but has two major issues: It is slow and it has a big memory footprint. In order to solve these two issues, I suggest to drop the use of the W3C DOM in webdav in favor of something easier and more straight forward to use. One candidate could be (out of my head and based on my bias towards KXml) KDOM. See also http://www.kxml.org.ww See also JCR-1261 for more discussions on this issue. -- 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-1312) Get rid of DOM for XML support
[ https://issues.apache.org/jira/browse/JCR-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12560103#action_12560103 ] hannonpi edited comment on JCR-1312 at 1/17/08 2:04 PM: -- All of our current CQ publish instances are currently CPU bound. So, while, XML performance may not be the central issue, anything we can do to reduce CPU overhead would be helpful for us here. That being said it seems that kxml's (and perhaps jixb's) pull parser approach has given us performance gains and lower footprints when compared to jaxb and other mechanisms (http://www.ibm.com/developerworks/library/x-databdopt2/ for info on jixb). was (Author: hannonpi): All of our current CQ publish instances are currently CPU bound. So, while, XML performance may not be the central issue, anything we can do to reduce CPU overhead would be helpful for us here. Get rid of DOM for XML support -- Key: JCR-1312 URL: https://issues.apache.org/jira/browse/JCR-1312 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-webdav Reporter: Felix Meschberger Currently the web dav library uses Xerces and DOM to parse and create XML data. This mechanism is well-known but has two major issues: It is slow and it has a big memory footprint. In order to solve these two issues, I suggest to drop the use of the W3C DOM in webdav in favor of something easier and more straight forward to use. One candidate could be (out of my head and based on my bias towards KXml) KDOM. See also http://www.kxml.org.ww See also JCR-1261 for more discussions on this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1196) Optimize queries for DescendantSelfAxisWeight/ChildAxisQuery
[ https://issues.apache.org/jira/browse/JCR-1196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12560259#action_12560259 ] Christoph Kiehl commented on JCR-1196: -- Description for slow ChildAxisQuery by Martin Zdila (JCR-1324): I have following structure in my repository: jcr:root gfr:devices gfr:device gfr:capabilityMap There are cca 4000 gfr:device nodes. Each gfr:device has only one gfr:capabilityMap. Each gfr:capabilityMap has average 20 properties. Here are some interesting results: 1. ((QueryImpl) query).setLimit(30); ((QueryImpl) query).setOffset(anyLimit); 1.1 executing query //gfr:capabilityMap and fetching nodes takes cca 20-80ms 1.2 executing query /jcr:root/gfr:devices/gfr:device/gfr:capabilityMap and fetching nodes takes cca 2000ms Why does this take longer time if the only difference is more specific path? I would expect even shorter time of execution and not this. 2. now without proprietary limit/offset 2.1 //gfr:capabilityMap cca 150-200ms 2.2 /jcr:root/gfr:devices/gfr:device/gfr:capabilityMap cca 14000ms!!! Optimize queries for DescendantSelfAxisWeight/ChildAxisQuery Key: JCR-1196 URL: https://issues.apache.org/jira/browse/JCR-1196 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core, query Reporter: Ard Schrijvers A query like /documents/en/news//[EMAIL PROTECTED] order by @modificationDate when there are many nodes ( 1.000) in /documents/en/news becomes very slow. I think the bottleneck is in something like recursive filters in lucene. First off all I'll try to find some stastistics about the performance, and describe the bottleneck. After that, a solution must be found, where we need to keep in mind that 1) these queries run faster and scale better (obviously) 2) moving a node must stay a cheap operation Also see: http://www.nabble.com/Search-performance--%3A-MultiIndex-tf4695559.html#a13421949 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1324) strange performance issue when using XPath query
[ https://issues.apache.org/jira/browse/JCR-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christoph Kiehl resolved JCR-1324. -- Resolution: Duplicate Assignee: Christoph Kiehl Thanks for reporting but this is a knows issue and a duplicate of JCR-1196. Please ask on the mailing list before creating issues. strange performance issue when using XPath query Key: JCR-1324 URL: https://issues.apache.org/jira/browse/JCR-1324 Project: Jackrabbit Issue Type: Bug Components: query Affects Versions: 1.4 Environment: Java 6, Linux Reporter: Martin Zdila Assignee: Christoph Kiehl I have following structure in my repository: jcr:root gfr:devices gfr:device gfr:capabilityMap There are cca 4000 gfr:device nodes. Each gfr:device has only one gfr:capabilityMap. Each gfr:capabilityMap has average 20 properties. Here are some interesting results: 1. ((QueryImpl) query).setLimit(30); ((QueryImpl) query).setOffset(anyLimit); 1.1 executing query //gfr:capabilityMap and fetching nodes takes cca 20-80ms 1.2 executing query /jcr:root/gfr:devices/gfr:device/gfr:capabilityMap and fetching nodes takes cca 2000ms Why does this take longer time if the only difference is more specific path? I would expect even shorter time of execution and not this. 2. now without proprietary limit/offset 2.1 //gfr:capabilityMap cca 150-200ms 2.2 /jcr:root/gfr:devices/gfr:device/gfr:capabilityMap cca 14000ms!!! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
