Re: [VOTE] Release Apache Jackrabbit 1.2.2
Hi, well, the issue may leave the repository in an unusable state: in more detail, the root node might contain an entry in its child node entry list with no corresponding child node. Is that critical enough? Cheers Dominique On 2/19/07, Jukka Zitting [EMAIL PROTECTED] wrote: Hi, On 2/19/07, Dominique Pfister [EMAIL PROTECTED] wrote: I was just pointed to some clustering issue, occurring with simultaneous processes that add/delete children on the same parent node. I was able to identify the source of this error and to fix it, and I would be very glad to include this fix in the upcoming 1.2.2 release. Could you defer the release for 1 or 2 days, or is it already too late? Too late, unless the issue is a critical enough to justify voting -1 in the ongoing release vote. I'm planning to release 1.3 already in March, but if there's demand to get a fix for this issue out already before that, then an earlier 1.2.3 patch release is definitely possible. BR, Jukka Zitting
[RESULT] [VOTE] Release Apache Jackrabbit 1.2.2
Hi, On 2/16/07, Jukka Zitting [EMAIL PROTECTED] wrote: Please vote on releasing these packages as Apache Jackrabbit 1.2.2. The vote is open for the next 72 hours, and only votes from Jackrabbit committers are binding. The vote passes if at least three +1 votes are cast. The vote passes with four binding +1 votes and one non-binding +1 vote. The binding votes were: +1 Jukka Zitting +1 Stefan Guggisberg +1 Tobias Bocanegra +1 Marcel Reutegger The non-binding vote was: +1 Fabrizio Giustina Thanks for voting! I'll proceed to make the public release announcement tomorrow once the release has been replicated through the mirroring system. I'll also push the release artifacts to the Maven repositories. BR, Jukka Zitting
Re: SPI: repositoryService.isGranted()
Hi Julian,
I agree, the method should be changed to take an absolute path. or was there a
reason why we used ItemId there?
regards
marcel
Julian Reschke wrote:
Hi,
I was recently refactoring my permission check support and came across
the following issue:
public boolean isGranted(SessionInfo sessionInfo, ItemId itemId,
String[] actions) throws RepositoryException;
The problem here is that in some cases (such as in add_node and
set_property), the ItemId may refer to an item that doesn't exist (yet),
so it's impossible for the transient layer to decide whether to produce
a NodeId or an ItemId.
Now in some case (such as when actions is {add_node}), the transient
layer could make an assumption about the type of the id based on the
action to be checked. However, this will get ugly when several actions
are checked in a single method call.
Thus, wouldn't it make sense to change the method signature to
public boolean isGranted(SessionInfo sessionInfo, Path absPath,
String[] actions) throws RepositoryException;
instead?
Re: [VOTE] Release Apache Jackrabbit 1.2.2
Hi, On 2/20/07, Dominique Pfister [EMAIL PROTECTED] wrote: well, the issue may leave the repository in an unusable state: in more detail, the root node might contain an entry in its child node entry list with no corresponding child node. Is that critical enough? As far as I understood the problem only affects a specific concurrent use case when clustering is enabled. Thus I'd label it as a major issue but not critical, especially since clustering is still marked as a beta feature for the 1.2 branch. Please file it as a bug report for this and I'll consider making a 1.2.3 release once the issue is fixed. BR, Jukka Zitting
[jira] Created: (JCR-751) Update Jackrabbit API JavaDoc on http://jackrabbit.apache.org
Update Jackrabbit API JavaDoc on http://jackrabbit.apache.org - Key: JCR-751 URL: https://issues.apache.org/jira/browse/JCR-751 Project: Jackrabbit Issue Type: Task Components: docs Reporter: Michael Singer Priority: Trivial Update the JavaDoc on http://jackrabbit.apache.org to the latest release version of jackrabbit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-752) Test cases leak sessions
Test cases leak sessions
Key: JCR-752
URL: https://issues.apache.org/jira/browse/JCR-752
Project: Jackrabbit
Issue Type: Bug
Components: test
Reporter: Julian Reschke
Priority: Minor
Many of the JCR test cases currently leak Sessions when an exception occurs
during the setUp() method. For some repository implementations, lots of
non-closed Session objects can cause subsequent test cases not to run at all
(because of no additional Sessions being available).
For instance, in org.apache.jackrabbit.test.api.SetValueBinaryTest:
protected void setUp() throws Exception {
super.setUp();
// initialize some binary value
data = createRandomString(10).getBytes();
value = superuser.getValueFactory().createValue(new
ByteArrayInputStream(data));
// create a new node under the testRootNode
node = testRootNode.addNode(nodeName1, testNodeType);
// create a new single-value property and save it
property1 = node.setProperty(propertyName1,
superuser.getValueFactory().createValue(new ByteArrayInputStream(new byte[0])));
superuser.save();
}
This code should be enhanced like this:
protected void setUp() throws Exception {
super.setUp();
try {
// initialize some binary value
data = createRandomString(10).getBytes();
value = superuser.getValueFactory().createValue(new
ByteArrayInputStream(data));
// create a new node under the testRootNode
node = testRootNode.addNode(nodeName1, testNodeType);
// create a new single-value property and save it
property1 = node.setProperty(propertyName1,
superuser.getValueFactory().createValue(new ByteArrayInputStream(new byte[0])));
superuser.save();
}
catch (RepositoryException ex) {
super.cleanUp();
throw ex;
}
}
This applies to many other test cases as well, some of which also allocate an
additional Session which would need to be logged out as well.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-753) Creation of JavaDoc fails on jackrabbit-jcr-server
Creation of JavaDoc fails on jackrabbit-jcr-server -- Key: JCR-753 URL: https://issues.apache.org/jira/browse/JCR-753 Project: Jackrabbit Issue Type: Bug Components: docs Reporter: Michael Singer Priority: Minor Attachments: javadoc-log.txt The creation of JavaDoc fails on project jackrabbit-jcr-server if the command mvn javadoc:javadoc is called on the latest checkout of jackrabbit. See attached log... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-753) Creation of JavaDoc fails on jackrabbit-jcr-server
[ https://issues.apache.org/jira/browse/JCR-753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Singer updated JCR-753: --- Attachment: javadoc-log.txt Creation of JavaDoc fails on jackrabbit-jcr-server -- Key: JCR-753 URL: https://issues.apache.org/jira/browse/JCR-753 Project: Jackrabbit Issue Type: Bug Components: docs Reporter: Michael Singer Priority: Minor Attachments: javadoc-log.txt The creation of JavaDoc fails on project jackrabbit-jcr-server if the command mvn javadoc:javadoc is called on the latest checkout of jackrabbit. See attached log... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Errors with new cluster feature
I'm working on some tests to reproduce this issue. However looking at the
code in 1.2.1, in method commit() of FileJournal.java, I can't find the lock
operation on the global revision file. Here is the code:
public void commit() throws JournalException {
try {
out.writeChar('\0');
out.close();
long nextRevision = record.getNextRevision();
FileRecordLog recordLog = new FileRecordLog(journal);
if (!recordLog.isNew()) {
if (nextRevision - recordLog.getFirstRevision()
maximumSize) {
switchLogs();
recordLog = new FileRecordLog(journal);
}
}
recordLog.append(record);
tempLog.delete();
globalRevision.set(nextRevision);
instanceRevision.set(nextRevision);
} catch (IOException e) {
String msg = Unable to close journal log + tempLog + : +
e.getMessage();
throw new JournalException(msg);
} finally {
out = null;
globalRevision.unlock();
writeMutex.release();
}
}
The call to globalRevision.set (that implies a lock) is done after the call
to recordLog.append() so I think the write is not protected. I'm rather new
to JCR and jackrabbit so maybe I'm missing something but the cluster feature
is very important for our product. I'm going to develop some classes to test
basic cluster operation and hope it helps to further improve in this area.
Regards,
On 19/02/07, Dominique Pfister [EMAIL PROTECTED] wrote:
Hi Miguel,
writing to the journal log file should only be possible after having
obtained an exclusive lock on the global revision file (R), located in
the same directory as the journal log file (L). The exact sequence of
operations is as follows:
- exclusive lock is obtained on R
- journal entry appended to log file L
- revision counter is updated in R
- exclusive lock is released on R
This should rule out simultaneous writes to the log file L.
Are you easily able to reproduce this issue, starting with an empty
journal file? I could eliminate some small issues in the not yet
released 1.2.2 branch, but I still would be very glad to know more
about how and when this problem arises...
Kind regards
Dominique
On 2/14/07, Miguel Ángel Jiménez [EMAIL PROTECTED] wrote:
Hi,
I'm trying the new cluster feature of Jackrabbit 1.2.1 and found some
issues. Using FileJournal to synchronize state between instances, we are
experiencing some errors that point to a possible corruption of the log
file:
2007-02-14 10:34:00,911 ERROR [org.apache.jackrabbit.core.RepositoryImpl
]
Unable to start clustered node, forcing shutdown...
org.apache.jackrabbit.core.cluster.JournalException: Unable to iterate
over
modified records: malformed input around byte 178
at org.apache.jackrabbit.core.cluster.FileJournal.sync(
FileJournal.java
:313)
at org.apache.jackrabbit.core.cluster.ClusterNode.sync(
ClusterNode.java
:217)
at org.apache.jackrabbit.core.cluster.ClusterNode.start(
ClusterNode.java
:164)
at org.apache.jackrabbit.core.RepositoryImpl.init(
RepositoryImpl.java
:308)
at org.apache.jackrabbit.core.RepositoryImpl.create(
RepositoryImpl.java
:573)
at
org.apache.jackrabbit.core.jndi.BindableRepository.createRepository(
BindableRepository.java:174)
at org.apache.jackrabbit.core.jndi.BindableRepository.init(
BindableRepository.java:138)
at org.apache.jackrabbit.core.jndi.BindableRepository.create(
BindableRepository.java:125)
at
org.apache.jackrabbit.core.jndi.BindableRepositoryFactory.createInstance
(
BindableRepositoryFactory.java:59)
at org.apache.jackrabbit.core.jndi.RegistryHelper.registerRepository
(
RegistryHelper.java:60)
at
com.germinus.xpression.cms.jcr.EmbeddedRepositoryFactory.getRepository(
EmbeddedRepositoryFactory.java:50)
at com.germinus.xpression.cms.jcr.JCRUtil.initRepository(
JCRUtil.java
:243)
...
Caused by: java.io.UTFDataFormatException: malformed input around byte
178
at java.io.DataInputStream.readUTF(DataInputStream.java:639)
at org.apache.jackrabbit.core.cluster.FileRecord.readCreator(
FileRecord.java:242)
at org.apache.jackrabbit.core.cluster.FileRecord.init(
FileRecord.java
:106)
at org.apache.jackrabbit.core.cluster.FileRecordCursor.next(
FileRecordCursor.java:101)
at org.apache.jackrabbit.core.cluster.FileJournal.sync(
FileJournal.java
:303)
... 130 more
Perhaps I'm wrong but looks like two instances are writing the file
simultaneously. Is this behaviour known or misconfiguration? The journal
log
is placed in a shared folder on a Linux machine and exported by SAMBA to
the
instances. I have tested the lock file capabilities of the shared
filesystem
and they are ok.
--
Miguel.
--
Miguel.
[jira] Updated: (JCR-754) Exception when concurrently adding nodes with JCA and XA transactions
[ https://issues.apache.org/jira/browse/JCR-754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrzej Dengusiak updated JCR-754: -- Attachment: dms_test_case.zip I'm attaching file containing EJB with a method adding nodes and other files for deployment on JBoss and a simple code running 20 threads running that EJB method concurrently. Exception when concurrently adding nodes with JCA and XA transactions - Key: JCR-754 URL: https://issues.apache.org/jira/browse/JCR-754 Project: Jackrabbit Issue Type: Bug Components: core, jca, transactions, versioning Affects Versions: 1.2.1 Environment: JBoss 4.0.3SP1, Java 1.4.2_12-b03, Reporter: Andrzej Dengusiak Priority: Blocker Attachments: dms_test_case.zip We're using Jackrabbit 1.2.1 with JCA, versioning and XA transactions on JBoss 4.0.3SP1. Everything works fine as long as there is only one user accessing repository and adding nodes at a given time. But sometimes if there are more users concurrently adding nodes under the same node, following error occurs: 2007-02-16 17:39:30,545 INFO [STDOUT] Caused by: javax.jcr.RepositoryException: 14fad421-1276-47b2-b667-50b2013944e3: 14fad421-1276-47b2-b667-50b2013944e3 2007-02-16 17:39:30,545 INFO [STDOUT]at org.apache.jackrabbit.core.version.NodeStateEx.store(NodeStateEx.java:504) 2007-02-16 17:39:30,595 INFO [STDOUT]at org.apache.jackrabbit.core.version.AbstractVersionManager.createVersionHistory(AbstractVersionManager.java:306) 2007-02-16 17:39:30,595 INFO [STDOUT]at org.apache.jackrabbit.core.version.XAVersionManager.createVersionHistory(XAVersionManager.java:144) 2007-02-16 17:39:30,595 INFO [STDOUT]at org.apache.jackrabbit.core.ItemImpl.initVersionHistories(ItemImpl.java:771) 2007-02-16 17:39:30,595 INFO [STDOUT]at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1181) 2007-02-16 17:39:30,595 INFO [STDOUT]at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:821) 2007-02-16 17:39:30,595 INFO [STDOUT]at org.apache.jackrabbit.jca.JCASessionHandle.save(JCASessionHandle.java:178) 2007-02-16 17:39:30,595 INFO [STDOUT]at xxx.dms.helpers.DmsHelper.saveSession(DmsHelper.java:131) 2007-02-16 17:39:30,595 INFO [STDOUT]at xxx.dms.ejb.DmsSessionBean.addDocumentMetadata(DmsSessionBean.java:173) 2007-02-16 17:39:30,595 INFO [STDOUT]at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 2007-02-16 17:39:30,595 INFO [STDOUT]at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 2007-02-16 17:39:30,595 INFO [STDOUT]at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 2007-02-16 17:39:30,595 INFO [STDOUT]at java.lang.reflect.Method.invoke(Method.java:324) 2007-02-16 17:39:30,595 INFO [STDOUT]at org.jboss.invocation.Invocation.performCall(Invocation.java:359) 2007-02-16 17:39:30,595 INFO [STDOUT]at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:237) 2007-02-16 17:39:30,595 INFO [STDOUT]at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:158) 2007-02-16 17:39:30,595 INFO [STDOUT]at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:169) 2007-02-16 17:39:30,595 INFO [STDOUT]at org.jboss.ws.server.ServiceEndpointInterceptor.invoke(ServiceEndpointInterceptor.java:64) 2007-02-16 17:39:30,595 INFO [STDOUT]at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63) 2007-02-16 17:39:30,655 INFO [STDOUT]at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121) 2007-02-16 17:39:30,655 INFO [STDOUT]at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:350) 2007-02-16 17:39:30,655 INFO [STDOUT]at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181) 2007-02-16 17:39:30,655 INFO [STDOUT]at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:168) 2007-02-16 17:39:30,655 INFO [STDOUT]at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205) 2007-02-16 17:39:30,655 INFO [STDOUT]at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:136) 2007-02-16 17:39:30,655 INFO [STDOUT]at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:648) 2007-02-16 17:39:30,655 INFO [STDOUT]at
Re: Errors with new cluster feature
Hi Miguel,
On 2/20/07, Miguel Ángel Jiménez [EMAIL PROTECTED] wrote:
The call to globalRevision.set (that implies a lock) is done after the call
to recordLog.append() so I think the write is not protected. I'm rather new
to JCR and jackrabbit so maybe I'm missing something but the cluster feature
is very important for our product. I'm going to develop some classes to test
basic cluster operation and hope it helps to further improve in this area.
Well, the method FileJournal.prepare() exclusively locks the global revision:
public void prepare() throws JournalException {
globalRevision.lock(false);
...
}
and this method is called before the actual FileJournal.commit().
In Jackrabbit 1.2.2, a DatabaseJournal has been added, that stores its
record in a shared database. If the persistence managers you're using
already share a standalone database, this might be an option.
Kind regards
Dominique
Re: DBConfiguration at runtime?
Hi, On 2/20/07, Malligarjunan Sidduraj [EMAIL PROTECTED] wrote: Can I configure the db info at the runtime? Any API available in JCR/Jackrabbit? Is there any other way available to configure the db info rather than configuring in repository.xml No. There's been some discussion about making the configuration model more flexible, but as of now all configuration changes must be done in the XML files and activated by restarting the repository. BR, Jukka Zitting
[jira] Created: (JCR-755) Add Bundle Persistence Managers
Add Bundle Persistence Managers --- Key: JCR-755 URL: https://issues.apache.org/jira/browse/JCR-755 Project: Jackrabbit Issue Type: Improvement Components: core Affects Versions: 1.3 Reporter: Tobias Bocanegra Assigned To: Tobias Bocanegra Priority: Minor we (day software) offer our set of bundle persistence managers to the jackrabbit project. those pms combine the node and property states into a single bundle and store them together. this improves performance and reduces storage-memory overhead (no exact numbers available). The bundle pms also have a bundle-cache that does a memory sensitive caching of the bundles and a negative cache for non-existent bundles. small binary properties are inlined into the bundle rather than stored in the blobstore. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Bundle Persistence Manager
hi, we (day software) offer our set of bundle persistence managers to the jackrabbit project. those pms combine the node and property states into a single bundle and store them together. this improves performance and reduces storage-memory overhead (no exact numbers available). The bundle pms also have a bundle-cache that does a memory sensitive caching of the bundles and a negative cache for non-existent bundles. small binary properties are inlined into the bundle rather than stored in the blob store. i created a jira issue for this [JCR-755] regards, toby [JCR-755] http://issues.apache.org/jira/browse/JCR-755 -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
[jira] Created: (JCR-756) Concurrent add/remove child node operations in a cluster may corrupt repository.
Concurrent add/remove child node operations in a cluster may corrupt repository. Key: JCR-756 URL: https://issues.apache.org/jira/browse/JCR-756 Project: Jackrabbit Issue Type: Bug Components: core Affects Versions: 1.2.1 Reporter: Dominique Pfister Assigned To: Dominique Pfister Concurrent add/remove child node operations in a cluster may store an inconsistent list of child node entries, i.e. an entry in the list may appear that has no associated node. This eventually results in an ItemNotFoundException, the next time one of these bogus entries is accessed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Bundle Persistence Manager
Hi, On 2/20/07, Tobias Bocanegra [EMAIL PROTECTED] wrote: we (day software) offer our set of bundle persistence managers to the jackrabbit project. those pms combine the node and property states into a single bundle and store them together. this improves performance and reduces storage-memory overhead (no exact numbers available). The bundle pms also have a bundle-cache that does a memory sensitive caching of the bundles and a negative cache for non-existent bundles. small binary properties are inlined into the bundle rather than stored in the blob store. Excellent, this will be a welcome addition to Jackrabbit! With my PMC chair hat on: Since this is a codebase that has been in development outside the ASF, we need to follow the IP clearance process described in http://incubator.apache.org/ip-clearance/. The exact steps to follow are: 1. You attach the contributed code in JCR-755 (preferably as a single file so we can use a MD5 or SHA1 checksum to accurately refer to it) 2. You call a vote for the Jackrabbit PMC to accept the contribution (this is required to ensure that the PMC is committed to taking over the maintenance of the codebase) 3. Day files a software grant (http://www.apache.org/licenses/software-grant.txt) for the contributed code. 4. The ASF Secretary acknowledgest the grant. 5. I fill in the the IP clearance form and call a vote for the Incubator PMC to check and accept the clearance. 6. Once accepted, I'll notify you of the green light to proceed. 7. You resolve JCR-755 by adding the contributed code to the Jackrabbit codebase. Let me know if you need help with any of the procedural details. We should apply the same process also to the packaging codebase for JCR-733. PS. We should have done this already when the SPI codebase was introduced. The ASF board noted about this, but the issue was not critical enough to require after-the-fact actions. In any case we should do things by the book this time. BR, Jukka Zitting
[jira] Created: (JCR-757) Allow multiple producers to feed/consume journal
Allow multiple producers to feed/consume journal Key: JCR-757 URL: https://issues.apache.org/jira/browse/JCR-757 Project: Jackrabbit Issue Type: New Feature Affects Versions: 1.2.1 Reporter: Dominique Pfister Assigned To: Dominique Pfister Priority: Minor Some clustered application based on jackrabbit might want to append custom records to the central journal in order to synchronize all nodes. Therefore, journal should provide support for multiple consumers/producers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-755) Add Bundle Persistence Managers
[ https://issues.apache.org/jira/browse/JCR-755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bocanegra updated JCR-755: - Attachment: JCR-755.patch.gz Patch that contains the new bundle persistence managers. Add Bundle Persistence Managers --- Key: JCR-755 URL: https://issues.apache.org/jira/browse/JCR-755 Project: Jackrabbit Issue Type: Improvement Components: core Affects Versions: 1.3 Reporter: Tobias Bocanegra Assigned To: Tobias Bocanegra Priority: Minor Attachments: JCR-755.patch.gz we (day software) offer our set of bundle persistence managers to the jackrabbit project. those pms combine the node and property states into a single bundle and store them together. this improves performance and reduces storage-memory overhead (no exact numbers available). The bundle pms also have a bundle-cache that does a memory sensitive caching of the bundles and a negative cache for non-existent bundles. small binary properties are inlined into the bundle rather than stored in the blobstore. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[VOTE] Include BundlePersistenceManager Contribution [JCR-755]
(once again, official :-) we (day software) offer our set of bundle persistence managers to the jackrabbit project. those persistence managers combine the node and property states into a single bundle and store them together. this improves performance and reduces storage-memory overhead (no exact numbers available). The bundle persistence managers also have a bundle-cache that does a memory sensitive caching of the bundles and a negative cache for non-existent bundles. small binary properties are inlined into the bundle rather than stored in the blob store. patch: http://issues.apache.org/jira/secure/attachment/12351599/JCR-755.patch.gz md5: a8accf17e35d1dec52f5b4fcc277bb9e Please vote on including those persistence managers to the Apache Jackrabbit codebase. The vote is open for the next 72 hours, and only votes from Jackrabbit committers are binding. The vote passes if at least three +1 votes and no vetos are cast. [ ] +1 Include [JCR-775] into Apache Jackrabbit Codebase [ ] -1 Do not include the classes because... regards, toby -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
Re: [VOTE] Include BundlePersistenceManager Contribution [JCR-755]
Hi, On 2/20/07, Tobias Bocanegra [EMAIL PROTECTED] wrote: Please vote on including those persistence managers to the Apache Jackrabbit codebase. +1 BR, Jukka Zitting
[jira] Assigned: (JCR-749) Add myqsql ddl for clustering (DatabaseJournal)
[ https://issues.apache.org/jira/browse/JCR-749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominique Pfister reassigned JCR-749: - Assignee: Dominique Pfister Add myqsql ddl for clustering (DatabaseJournal) --- Key: JCR-749 URL: https://issues.apache.org/jira/browse/JCR-749 Project: Jackrabbit Issue Type: Improvement Components: core Affects Versions: 1.2.2 Reporter: fabrizio giustina Assigned To: Dominique Pfister Priority: Minor Attachments: mysql.ddl the default ddl for clustering does't work with mysql, so it would be nice to include a mysql specific ddl also for clustering. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-749) Add myqsql ddl for clustering (DatabaseJournal)
[ https://issues.apache.org/jira/browse/JCR-749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominique Pfister resolved JCR-749. --- Resolution: Fixed Thank you very much for your contribution. I added mysql.ddl to revision 509624. Add myqsql ddl for clustering (DatabaseJournal) --- Key: JCR-749 URL: https://issues.apache.org/jira/browse/JCR-749 Project: Jackrabbit Issue Type: Improvement Components: core Affects Versions: 1.2.2 Reporter: fabrizio giustina Assigned To: Dominique Pfister Priority: Minor Attachments: mysql.ddl the default ddl for clustering does't work with mysql, so it would be nice to include a mysql specific ddl also for clustering. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-756) Concurrent add/remove child node operations in a cluster may corrupt repository.
[ https://issues.apache.org/jira/browse/JCR-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominique Pfister updated JCR-756: -- Attachment: Create.java Create.java: Sample application that creates nodes and properties below the root node. Concurrent add/remove child node operations in a cluster may corrupt repository. Key: JCR-756 URL: https://issues.apache.org/jira/browse/JCR-756 Project: Jackrabbit Issue Type: Bug Components: core Affects Versions: 1.2.1 Reporter: Dominique Pfister Assigned To: Dominique Pfister Attachments: Create.java, Remove.java Concurrent add/remove child node operations in a cluster may store an inconsistent list of child node entries, i.e. an entry in the list may appear that has no associated node. This eventually results in an ItemNotFoundException, the next time one of these bogus entries is accessed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-756) Concurrent add/remove child node operations in a cluster may corrupt repository.
[ https://issues.apache.org/jira/browse/JCR-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominique Pfister updated JCR-756: -- Attachment: Remove.java Remove.java: Sample application that deletes nodes below the root node Concurrent add/remove child node operations in a cluster may corrupt repository. Key: JCR-756 URL: https://issues.apache.org/jira/browse/JCR-756 Project: Jackrabbit Issue Type: Bug Components: core Affects Versions: 1.2.1 Reporter: Dominique Pfister Assigned To: Dominique Pfister Attachments: Create.java, Remove.java Concurrent add/remove child node operations in a cluster may store an inconsistent list of child node entries, i.e. an entry in the list may appear that has no associated node. This eventually results in an ItemNotFoundException, the next time one of these bogus entries is accessed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-756) Concurrent add/remove child node operations in a cluster may corrupt repository.
[ https://issues.apache.org/jira/browse/JCR-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominique Pfister updated JCR-756: -- Attachment: repository.xml Sample repository.xml configuration that might be used for both create and remove sample application. Concurrent add/remove child node operations in a cluster may corrupt repository. Key: JCR-756 URL: https://issues.apache.org/jira/browse/JCR-756 Project: Jackrabbit Issue Type: Bug Components: core Affects Versions: 1.2.1 Reporter: Dominique Pfister Assigned To: Dominique Pfister Attachments: Create.java, Remove.java, repository.xml Concurrent add/remove child node operations in a cluster may store an inconsistent list of child node entries, i.e. an entry in the list may appear that has no associated node. This eventually results in an ItemNotFoundException, the next time one of these bogus entries is accessed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-756) Concurrent add/remove child node operations in a cluster may corrupt repository.
[ https://issues.apache.org/jira/browse/JCR-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominique Pfister resolved JCR-756. --- Resolution: Fixed Problem identified to be the following during an update: 1) When a journal update is started, the clustered instance syncs with journal contents. This might change the SharedItemStateManager's states 2) Later on, eventual, non-conflicting changes are merged to the local states. 3) Finally, the journal update is prepared. This might again trigger an external update from the journal and change the shared states . However, these changes are not merged to the local states. 4) The local states are pushed blindly to the shared states, potentially overwriting a previous change. Fixed by locking the journal in 1) instead of 3). This still allows non-conflicting merge, but only once. An even better, less blocking approach would iteratively merge the changes seen in external updates to the local states. Thanks a lot to Rafał Kwiecień for reporting this bug and providing the test classes. Fixed in revision 509624. Concurrent add/remove child node operations in a cluster may corrupt repository. Key: JCR-756 URL: https://issues.apache.org/jira/browse/JCR-756 Project: Jackrabbit Issue Type: Bug Components: core Affects Versions: 1.2.1 Reporter: Dominique Pfister Assigned To: Dominique Pfister Attachments: Create.java, Remove.java, repository.xml Concurrent add/remove child node operations in a cluster may store an inconsistent list of child node entries, i.e. an entry in the list may appear that has no associated node. This eventually results in an ItemNotFoundException, the next time one of these bogus entries is accessed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-757) Allow multiple producers to feed/consume journal
[ https://issues.apache.org/jira/browse/JCR-757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominique Pfister resolved JCR-757. --- Resolution: Fixed Added consumer/producer functionality to the journal and moved the associated classes to o.a.j.core.journal. Fixed in revision 509624. Allow multiple producers to feed/consume journal Key: JCR-757 URL: https://issues.apache.org/jira/browse/JCR-757 Project: Jackrabbit Issue Type: New Feature Affects Versions: 1.2.1 Reporter: Dominique Pfister Assigned To: Dominique Pfister Priority: Minor Some clustered application based on jackrabbit might want to append custom records to the central journal in order to synchronize all nodes. Therefore, journal should provide support for multiple consumers/producers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r509624 [1/3] - in /jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core: ./ cluster/ config/ journal/ state/
Hi, On 2/20/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Log: JCR-749 Add mysql ddl for clustering (DatabaseJournal) JCR-756 Concurrent add/remove child node operations in a cluster may corrupt repository JCR-757 Allow multiple producers to feed/consume journal If possible, please avoid such commits that combine fixes to multiple separate issues. Such commits make it hard to track which issue was the cause of a specific change and to selectively merge bug fixes to maintenance branches. In addition the combined size of the multi-issue changeset makes any kind of review quite difficult. BR, Jukka Zitting
[jira] Created: (JCR-758) QueryResult's RowIterator.getSize returned the wrong size of the results after I implemented my own AccessManager
QueryResult's RowIterator.getSize returned the wrong size of the results after I implemented my own AccessManager - Key: JCR-758 URL: https://issues.apache.org/jira/browse/JCR-758 Project: Jackrabbit Issue Type: Bug Affects Versions: 1.2.1 Reporter: Xiaohua Lu The background is I have implemented my own AccessManager. After executing a query and get back the RowIterator from the result, if I call rowiterator.getSize, it will return the size of all nodes matching my query (without honoring the access control) . But if I iterate through the result, I find lots of duplicates in the results; and if I filter out those duplicate, the final result is quite off the original number from RowIteartor.getSize() BTW, I also disabled Doc Order sorting. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-758) QueryResult's RowIterator.getSize returned the wrong size of the results after I implemented my own AccessManager
[ https://issues.apache.org/jira/browse/JCR-758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12474497 ] Marcel Reutegger commented on JCR-758: -- Can you please provide a test case that shows this behaviour? Thank you. QueryResult's RowIterator.getSize returned the wrong size of the results after I implemented my own AccessManager - Key: JCR-758 URL: https://issues.apache.org/jira/browse/JCR-758 Project: Jackrabbit Issue Type: Bug Affects Versions: 1.2.1 Reporter: Xiaohua Lu The background is I have implemented my own AccessManager. After executing a query and get back the RowIterator from the result, if I call rowiterator.getSize, it will return the size of all nodes matching my query (without honoring the access control) . But if I iterate through the result, I find lots of duplicates in the results; and if I filter out those duplicate, the final result is quite off the original number from RowIteartor.getSize() BTW, I also disabled Doc Order sorting. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-759) handling of namespace registrations in AbstractJCRTest
handling of namespace registrations in AbstractJCRTest -- Key: JCR-759 URL: https://issues.apache.org/jira/browse/JCR-759 Project: Jackrabbit Issue Type: Bug Components: JCR TCK Reporter: Julian Reschke Priority: Minor The TCK tests allow to specify namespace prefix/URI registrations to be made at startup. Good. The issue here is that AbstractJCRTest.setUp() essentially gives up when a namespace URI is already registered, but uses a different prefix. There are at least two ways to fix this: 1) overwrite the entry in the namespace registery, or 2) get the prefix, and substitute it later on when reading in JCR names. Alternatively, it could just record the desired mappings, and automatically set them on session scope (that would also have the benefit that the success of many tests would be de-coupled from the ability to write to the permanent namespace registry). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-556) Refactoring of the BackupTool
[ https://issues.apache.org/jira/browse/JCR-556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Toper updated JCR-556: -- Attachment: VisitorPattern200207.patch Hi, I still haven't quit working on the backup tool. Thanks to Jukka, I have found a much easier solution to backup the workspace content: work at the persistence manager level directly. But to achieve this idea, I had to write a Visitor pattern to the PersistenceManager system. I needed a fast iteration on all nodes in order to backup them with a small memory footprint (restore can take longer so it is less of an issue). I couldn't reuse the Visitor facilities provided by the JCR API since I need to work at a much lower level. This is the patch I now propose to the Jackrabbit community. It is composed of 3 files: - ItemStateVisitor is an interface. A visitor of an ItemState must implement it - VisitableItemStateCollection is an interface. Every class implementing this interface can be visited by an ItemStateVisitor. (Those classes are more general than - A patch to DatabasePersistenceManager implementing VisitableItemStateCollection. With it most repository are backup ready. It will be used also as a proof of concept code for other contributors who might want to implement the visitor interface to others peristence manager. If this patch is accepted, I will finish working on the backup/restore method of the backup tool (those are the last steps) and add a fallback code so all repository can be backuped albeit in a slower way. BR, Nico Refactoring of the BackupTool - Key: JCR-556 URL: https://issues.apache.org/jira/browse/JCR-556 Project: Jackrabbit Issue Type: Improvement Reporter: Nicolas Toper Priority: Minor Attachments: BIO.patch, patch-backup-040906.txt, patch-jr-010906-NodeVersionHistoriesUpdatableStateManager.txt, patch-jr-010906-PropInfo.txt, patch-jr-010906-RepositoryImpl.txt, patch-jr-010906-SysViewImporter.txt, patch-jr-010906-VersionManagerImpl.txt, PropInfo.patch, VisitorPattern200207.patch The BackupTool has still some refactoring to perform. I will propose the patch on this new issue since we cannot change the JCR-442 (Google wants to see a place where all the Google SoC work is). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Errors with new cluster feature
Thanks again for the response. I have another issue about FileJournal. In
our test environment, we have several instances doing concurrent
modifications to the repository and have been able to trace what I see as a
possible bug in log file rotation. It seems that the renaming of old files
is not working as expected. For example, journal.log.1 does not get renamed
to journal.log.2 when rotating the current log file. I think the problem is
class FileJournal method switchLogs:
String newName = name.substring(0, sep + 1) + String.valueOf(version + 1);
file.renameTo(new File(newName));
The new name does not preserve the original path of the renamed file.
Wouldn't be better to do...
String newName = name.substring(0, sep + 1) + String.valueOf(version + 1);
file.renameTo(new File(root, newName));
... or something similar? Makes it sense to you?
Thanks for the advance on the new DatabaseJournal. I'm looking forward to
this solution as it suits well with our current deployment model.
Kind regards,
On 20/02/07, Dominique Pfister [EMAIL PROTECTED] wrote:
Hi Miguel,
On 2/20/07, Miguel Ángel Jiménez [EMAIL PROTECTED] wrote:
The call to globalRevision.set (that implies a lock) is done after the
call
to recordLog.append() so I think the write is not protected. I'm rather
new
to JCR and jackrabbit so maybe I'm missing something but the cluster
feature
is very important for our product. I'm going to develop some classes to
test
basic cluster operation and hope it helps to further improve in this
area.
Well, the method FileJournal.prepare() exclusively locks the global
revision:
public void prepare() throws JournalException {
globalRevision.lock(false);
...
}
and this method is called before the actual FileJournal.commit().
In Jackrabbit 1.2.2, a DatabaseJournal has been added, that stores its
record in a shared database. If the persistence managers you're using
already share a standalone database, this might be an option.
Kind regards
Dominique
--
Miguel.
Re: Bundle Persistence Manager
On Feb 20, 2007, at 7:18 AM, Jukka Zitting wrote: 3. Day files a software grant (http://www.apache.org/licenses/software-grant.txt) for the contributed code. It is sufficient for Day to send an addendum to the existing grant. In other words, ask David to send email to Jim Jagielski (and cc the jackrabbit dev list) that says the additional code also falls under our existing grant agreement. While he is doing that, he should also add the names of our new employees to the Day CCLA. PS. We should have done this already when the SPI codebase was introduced. The ASF board noted about this, but the issue was not critical enough to require after-the-fact actions. In any case we should do things by the book this time. I thought we did. David Nuescheler sent his message to this list saying that it was a contribution under the existing CCLA, and that is sufficient for Apache legal. David is the official contact. Roy
Re: [VOTE] Include BundlePersistenceManager Contribution [JCR-755]
+1 Roy
Re: Bundle Persistence Manager
Hi, On 2/20/07, Roy T. Fielding [EMAIL PROTECTED] wrote: On Feb 20, 2007, at 7:18 AM, Jukka Zitting wrote: 3. Day files a software grant (http://www.apache.org/licenses/software-grant.txt) for the contributed code. It is sufficient for Day to send an addendum to the existing grant. In other words, ask David to send email to Jim Jagielski (and cc the jackrabbit dev list) that says the additional code also falls under our existing grant agreement. While he is doing that, he should also add the names of our new employees to the Day CCLA. OK, good. PS. We should have done this already when the SPI codebase was introduced. The ASF board noted about this, but the issue was not critical enough to require after-the-fact actions. In any case we should do things by the book this time. I thought we did. David Nuescheler sent his message to this list saying that it was a contribution under the existing CCLA, and that is sufficient for Apache legal. David is the official contact. OK, so that's cleared. Thanks. BR, Jukka Zitting
[jira] Commented: (JCR-758) QueryResult's RowIterator.getSize returned the wrong size of the results after I implemented my own AccessManager
[ https://issues.apache.org/jira/browse/JCR-758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12474567 ] Paco Avila commented on JCR-758: Big news! I have the same weird issue. I am trying to make a minimal test case. The duplicate nodes are nodes which the quering session have no permissions and the returned node is a duplicate of the last returned node where the session can read. It is a bit confusing to explain and my english is poor. If the query is done by a super user session, the returned nodes are the good nodes. If the query is performed by a limited user session, the number of returned nodes are the same (amazing!!), but the forbidden nodes are not returned (of course) and these nodes are filled with the other readed nodes. QueryResult's RowIterator.getSize returned the wrong size of the results after I implemented my own AccessManager - Key: JCR-758 URL: https://issues.apache.org/jira/browse/JCR-758 Project: Jackrabbit Issue Type: Bug Affects Versions: 1.2.1 Reporter: Xiaohua Lu The background is I have implemented my own AccessManager. After executing a query and get back the RowIterator from the result, if I call rowiterator.getSize, it will return the size of all nodes matching my query (without honoring the access control) . But if I iterate through the result, I find lots of duplicates in the results; and if I filter out those duplicate, the final result is quite off the original number from RowIteartor.getSize() BTW, I also disabled Doc Order sorting. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Include BundlePersistenceManager Contribution [JCR-755]
+1 regards, david
