[jira] Commented: (JCR-388) add support for RFC 3253 to the simple server
[ https://issues.apache.org/jira/browse/JCR-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500040 ] angela commented on JCR-388: i reviewed the second patch jeremi uploaded and had a couple of comments. as far as i know there is no additional patch available that would address those issues. regards angela add support for RFC 3253 to the simple server - Key: JCR-388 URL: https://issues.apache.org/jira/browse/JCR-388 Project: Jackrabbit Issue Type: New Feature Components: webdav Affects Versions: 0.9 Reporter: jeremi Joslin Assignee: angela Priority: Minor Attachments: patch_rfc3253.zip, Review.txt, rfc.zip http://www.ietf.org/rfc/rfc3253.txt -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Transactions in jackrabbit using RMI?
Hi, I am connecting to a repository through RMI. Repository returnns me org.apache.jackrabbit.rmi.client.ClientSession upon login. I want to perform operations on repository in the form of transactions. Can I do that using the UserTransaction object? If yes then how can I initialize the following object reference? UserTransaction utx = ? Also, the org.apache.jackrabbit.rmi.client.ClientSession object cannot be cast to org.apache.jackrabbit.core.XASession. How should I accomplish transactions in this scenario? Thanks. -- View this message in context: http://www.nabble.com/Transactions-in-jackrabbit-using-RMI--tf3838709.html#a10868859 Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
Re: Running Jackrabbit JCRTestSuite with a database
Hi Pablo, Pablo Rios wrote: Why aren't the test namespace (among others) and custom node types of this test suite registered when using a DatabaseFileSystem ? How are the ns_reg.properties and custom_nodetypes.xml resource files processed ? the jackrabbit checkout uses predefined namespaces and node type definitions, which are located here: jackrabbit-core/applications/test/repository/namespaces/ns_reg.properties.install jackrabbit-core/applications/test/repository/namespaces/custom_nodetypes.xml.install if you use a DatabaseFileSystem you need to register the namespaces and node types manually before you run the tests. the tck-candidate contribution already contains such a setup procedure. See: http://svn.apache.org/repos/asf/jackrabbit/trunk/contrib/tck-candidate regards marcel
[jira] Commented: (JCR-929) Under Heavy load in a Cluster HTTP Threads Block and stall requests
[ https://issues.apache.org/jira/browse/JCR-929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500059 ] Ian Boston commented on JCR-929: That appears to have fixed this problem, in the internal lock and unlock methods I have added an effective lockAndSync if and only if the event channel is notified of the lock or unlock which would cause a lock and sync after the lock manager jvm lock had been aquired. So deadlocks can't happen as you predicted. I notice there may be some more places where this can happen. The NodeTypeRegistry and the NameSpaceRegistry I have some additional errors appearing when the path can't be built due to nonexistant child nodes, leading me to believe that something might be being dropped. Unfortunately, I don't have net access and my blackberry won't hook up to OSX so I can't send a patch till Saturday at the earliest. Sorry Ian Sent from my Pearl, sorry about the briefness and spelling! Under Heavy load in a Cluster HTTP Threads Block and stall requests --- Key: JCR-929 URL: https://issues.apache.org/jira/browse/JCR-929 Project: Jackrabbit Issue Type: Bug Components: core Affects Versions: 1.3 Environment: 2 Node Cluster, OSX, JDK 1.5 with DatabaseJournal, DatabasePersistanceManager, all content in DB, using WebDAV to load Reporter: Ian Boston Assignee: Dominique Pfister Attachments: catalina.out.node1.txt, catalina.out.node2.txt Under Heavy load created by mounting both nodes in the cluster in OSX Finder and then uploading large numebers of files to each node at the same time ( a few 1000), eventually one of the nodes stops responding and the Finder mount timesout and disconnects. Once that happens that node becomes unusable. More mount attempts will prompt for a password indicating HTTP is still running, but will timeout once the connection is authenticated. Access by the Web Browser will prompt for a password, conenct and provide a once only listing of any collection in the workspace. If you try to refresh that collection, the HTTP request hangs forever. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-951) OracleFileSystem uses getClass().getResourceAsStream to load schema file
[ https://issues.apache.org/jira/browse/JCR-951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg reassigned JCR-951: - Assignee: Stefan Guggisberg OracleFileSystem uses getClass().getResourceAsStream to load schema file Key: JCR-951 URL: https://issues.apache.org/jira/browse/JCR-951 Project: Jackrabbit Issue Type: Improvement Components: core Affects Versions: 1.3.1 Reporter: Marcel May Assignee: Stefan Guggisberg Priority: Minor Fix For: 1.3.1 Attachments: jackrabbit.542562.patch.txt org.apache.jackrabbit.core.fs.db.OracleFileSystem loads the schema via getClass().getResourceAsStream(...). This makes it impossible to extend the class without either copying the schema ddl file, or overwriting checkSchema(...), as the schema file is not accessible. The solution is to use OracleFilesystem.class.getResourceAsStream(...). See JCR-595 which fixed this already for org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-950) The move method doesn't remove the source node
[ https://issues.apache.org/jira/browse/JCR-950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg reassigned JCR-950: - Assignee: Dominique Pfister (was: Stefan Guggisberg) passing on to the CachingHierarchyManager expert ;) The move method doesn't remove the source node -- Key: JCR-950 URL: https://issues.apache.org/jira/browse/JCR-950 Project: Jackrabbit Issue Type: Bug Components: core Affects Versions: 1.3 Reporter: Christophe Lombart Assignee: Dominique Pfister Attachments: MoveTest.java Here is a small unit test that demonstrate that the method move doesn't remove the source node. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-953) Support for transactions when using JCR over RMI.
Support for transactions when using JCR over RMI. - Key: JCR-953 URL: https://issues.apache.org/jira/browse/JCR-953 Project: Jackrabbit Issue Type: Improvement Components: rmi Reporter: Berry van Halderen Priority: Minor At this time, the sessions obtained from o.a.j.rmi.client.LocalAdapterFactory do not implement the methods for the XASession. Therefor the RMI access layer does not support a transactional session. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-953) Support for transactions when using JCR over RMI.
[ https://issues.apache.org/jira/browse/JCR-953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500111 ] Berry van Halderen commented on JCR-953: I think the only thing that needed to be implemented is to extend both client and server side decorator stubs to implement the XAResource interface. The client, when asked for the getXAResource() can just return itself. In the implementation of the XAResource interface the client stub can just call the server side stub over RMI. The server side stub just forwards the call to the actual session. This works because the transaction IDs (Xid) are serializable, and can be passed over RMI. The transactions themselves are managed at the client side. I will be providing a proposal patch for this shortly. Support for transactions when using JCR over RMI. - Key: JCR-953 URL: https://issues.apache.org/jira/browse/JCR-953 Project: Jackrabbit Issue Type: Improvement Components: rmi Reporter: Berry van Halderen Priority: Minor At this time, the sessions obtained from o.a.j.rmi.client.LocalAdapterFactory do not implement the methods for the XASession. Therefor the RMI access layer does not support a transactional session. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-951) OracleFileSystem uses getClass().getResourceAsStream to load schema file
[ https://issues.apache.org/jira/browse/JCR-951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg resolved JCR-951. --- Resolution: Fixed thanks for the patch! fixed as suggested and applied same change to DatabaseFileSystem BundleDbPersistenceManager as well. fixed in svn r542831. OracleFileSystem uses getClass().getResourceAsStream to load schema file Key: JCR-951 URL: https://issues.apache.org/jira/browse/JCR-951 Project: Jackrabbit Issue Type: Improvement Components: core Affects Versions: 1.3.1 Reporter: Marcel May Assignee: Stefan Guggisberg Priority: Minor Fix For: 1.3.1 Attachments: jackrabbit.542562.patch.txt org.apache.jackrabbit.core.fs.db.OracleFileSystem loads the schema via getClass().getResourceAsStream(...). This makes it impossible to extend the class without either copying the schema ddl file, or overwriting checkSchema(...), as the schema file is not accessible. The solution is to use OracleFilesystem.class.getResourceAsStream(...). See JCR-595 which fixed this already for org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Resolved: (JCR-951) OracleFileSystem uses getClass().getResourceAsStream to load schema file
Hi Stefan! Thanks alot, that was fast. Another question - the wiki pages (http://wiki.apache.org/jackrabbit/JackRabbitOnTomcat) mention org.apache.jackrabbit.core.fs.db.JNDIOracleDatabaseFileSystem and org.apache.jackrabbit.core.state.db.JNDIOracleDatabasePersistenceManager . It seems theses classes do not exist in the trunk. Would you accept those implementations, or was there a decision against these implementations? I could open an issue for these and provide a patch, too. Cheers, Marcel Stefan Guggisberg (JIRA) wrote: [ https://issues.apache.org/jira/browse/JCR-951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg resolved JCR-951. --- Resolution: Fixed thanks for the patch! fixed as suggested and applied same change to DatabaseFileSystem BundleDbPersistenceManager as well. fixed in svn r542831. OracleFileSystem uses getClass().getResourceAsStream to load schema file Key: JCR-951 URL: https://issues.apache.org/jira/browse/JCR-951 Project: Jackrabbit Issue Type: Improvement Components: core Affects Versions: 1.3.1 Reporter: Marcel May Assignee: Stefan Guggisberg Priority: Minor Fix For: 1.3.1 Attachments: jackrabbit.542562.patch.txt org.apache.jackrabbit.core.fs.db.OracleFileSystem loads the schema via getClass().getResourceAsStream(...). This makes it impossible to extend the class without either copying the schema ddl file, or overwriting checkSchema(...), as the schema file is not accessible. The solution is to use OracleFilesystem.class.getResourceAsStream(...). See JCR-595 which fixed this already for org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.
[jira] Resolved: (JCR-950) The move method doesn't remove the source node
[ https://issues.apache.org/jira/browse/JCR-950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominique Pfister resolved JCR-950. --- Resolution: Fixed There was some bad assumption in the PathMap (located in jackrabbit-jcr-commons): after moving /node1 to /result, the CachingHierarchyManager determined that its internal representation of the root tnode had become invalid and therefore told its PathMap to remove it. The PathMap has some check to prevent the root node from being completely removed, but unfortunately forgot to remove its children and associated object, which left an orphaned node1 child in the root node's children map. Fixed in revision 542838. The move method doesn't remove the source node -- Key: JCR-950 URL: https://issues.apache.org/jira/browse/JCR-950 Project: Jackrabbit Issue Type: Bug Components: core Affects Versions: 1.3 Reporter: Christophe Lombart Assignee: Dominique Pfister Attachments: MoveTest.java Here is a small unit test that demonstrate that the method move doesn't remove the source node. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Resolved: (JCR-951) OracleFileSystem uses getClass().getResourceAsStream to load schema file
hi marcel, On 5/30/07, Marcel May [EMAIL PROTECTED] wrote: Hi Stefan! Thanks alot, that was fast. Another question - the wiki pages (http://wiki.apache.org/jackrabbit/JackRabbitOnTomcat) mention org.apache.jackrabbit.core.fs.db.JNDIOracleDatabaseFileSystem and org.apache.jackrabbit.core.state.db.JNDIOracleDatabasePersistenceManager . i don't know anything about those classes. personally i don't think it's a good idea to use externally managed datasources in jackrabbit's persistence layer. jackrabbit needs absolute and exclusive control over the underlying database connection. jackrabbit is not a 'database application' but infrastucture with special requirements wrt its persistence layer. It seems theses classes do not exist in the trunk. Would you accept those implementations, or was there a decision against these implementations? I could open an issue for these and provide a patch, too. feel free to do so if you don't agree with my rationale. cheers stefan Cheers, Marcel Stefan Guggisberg (JIRA) wrote: [ https://issues.apache.org/jira/browse/JCR-951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg resolved JCR-951. --- Resolution: Fixed thanks for the patch! fixed as suggested and applied same change to DatabaseFileSystem BundleDbPersistenceManager as well. fixed in svn r542831. OracleFileSystem uses getClass().getResourceAsStream to load schema file Key: JCR-951 URL: https://issues.apache.org/jira/browse/JCR-951 Project: Jackrabbit Issue Type: Improvement Components: core Affects Versions: 1.3.1 Reporter: Marcel May Assignee: Stefan Guggisberg Priority: Minor Fix For: 1.3.1 Attachments: jackrabbit.542562.patch.txt org.apache.jackrabbit.core.fs.db.OracleFileSystem loads the schema via getClass().getResourceAsStream(...). This makes it impossible to extend the class without either copying the schema ddl file, or overwriting checkSchema(...), as the schema file is not accessible. The solution is to use OracleFilesystem.class.getResourceAsStream(...). See JCR-595 which fixed this already for org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.
[jira] Commented: (JCR-388) add support for RFC 3253 to the simple server
[ https://issues.apache.org/jira/browse/JCR-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500164 ] jeremi Joslin commented on JCR-388: --- no sorry i haven't updated the patch. add support for RFC 3253 to the simple server - Key: JCR-388 URL: https://issues.apache.org/jira/browse/JCR-388 Project: Jackrabbit Issue Type: New Feature Components: webdav Affects Versions: 0.9 Reporter: jeremi Joslin Assignee: angela Priority: Minor Attachments: patch_rfc3253.zip, Review.txt, rfc.zip http://www.ietf.org/rfc/rfc3253.txt -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (JCR-944) potential memory leak
[ https://issues.apache.org/jira/browse/JCR-944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaohua Lu closed JCR-944. -- Resolution: Invalid potential memory leak - Key: JCR-944 URL: https://issues.apache.org/jira/browse/JCR-944 Project: Jackrabbit Issue Type: Bug Affects Versions: 1.3 Reporter: Xiaohua Lu we are doing some stress test and noticed instances of access manager and login manager we provided for Jackrabbit are not GCed. According to heap snapshot (from JProfiler), they are traced back to RepositoryImpl RepositoryImp - HashMap - RepositoryImpl$WorkspaceInfo - SharedItemStateManager - StateChangeDispatcher - CopyOnWriteArrayList - XAItemStateManager - StateChangeDispatcher - CopyOnWriteDispatcher - SessionItemStateManager - StateChangeDispatcher - CopyOnWriteArrayList - ItemManager - XASessionImpl - AuthContext - our LoginModule Impl Since RepositoryImpl is always kept in memory, so all instances of our login module are not GCed even after requests have been served. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-954) Allow to disable referential integrity checking for workspace
Allow to disable referential integrity checking for workspace - Key: JCR-954 URL: https://issues.apache.org/jira/browse/JCR-954 Project: Jackrabbit Issue Type: New Feature Components: core Reporter: Przemo Pakulski Fix For: 1.4 Some operations like clone, remove operating on huge subtree of nodes requires a lot of memory. To copy, clone, remove subtree all nodes are loaded into transient spaces. It allows such operations to be transactional, from other side it requires a lot of heap size and this memory size is directly dependent on the size of subtree (number of nodes). In result of this in some cases it is impossible to make such operations in one step. In our environment sometimes 1 GB of java heap is not enough to succesfully clone subtree from one workspace to another. You can always clone (copy, remove) tree in chunks, but if you have references between subtrees such approach fails. Possibilty of temporary disabling referential integrity checking for experienced JCR user could be very usefull then. Another use case is to allow to clone selected subtrees of the whole structure between worskpaces. In our application we need to clone only some selected subtrees from one workspace to another. But we can not do that because of existing references. We need to clone the whol estructure first, then remove all unwanted nodes, which is really time expensive and memory consuming. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-832) BundleDBPersistenceManager does not free blobStore resources
[
https://issues.apache.org/jira/browse/JCR-832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Przemo Pakulski updated JCR-832:
Attachment: JCR-832-patch.txt
Attached patch proposal. Abstract method destroy(PropertyState) added to
AbstractBundlePM and called during store. Method implemented in BundleDB PM to
ensure that blob resources are removed from underlying blobstore.
Not sure if something needs to be done in BundleFS PM, so method remains empty
there.
BundleDBPersistenceManager does not free blobStore resources
Key: JCR-832
URL: https://issues.apache.org/jira/browse/JCR-832
Project: Jackrabbit
Issue Type: Bug
Components: core
Affects Versions: 1.3
Reporter: Przemo Pakulski
Assignee: Tobias Bocanegra
Attachments: JCR-832-patch.txt
When removing binary property from node or removing node containing binary
property, resources occupied by binary property are not freed (orphaned
records remains in associated ${schemaObjectPrefix}BINVAL table).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
