InvalidItemStateException on clustering jackrabbit
Dear all,
I'm a test engeneer in Japan.
We deploy jackrabbit-webapp 1.4 for our application to store pdf documents.
And I am reserching how to use jackrabbit on clustering servers.
In our test on clustering jackrabbit with shared repository on MySQL5.1,
An InvalidItemStateException occurs when registering documents
simultaneously from 2 nodes.
--
>Caused by: javax.jcr.InvalidItemStateException:
> cafebabe-cafe-babe-cafe-babecafebabe has been modified externally
> at org.apache.jackrabbit.rmi.server.ServerObject.getRepositoryException
> (ServerObject.java:104)
> at
org.apache.jackrabbit.rmi.server.ServerSession.save(ServerSession.java:212)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
--
It seems very serious, but check SQL trace from MySQL, this failed
connection
issues only some select and gives up.
--
> 5 Query SHOW WARNINGS
> 5 Query /* mysql-connector-java-5.1.7 ( Revision: ${svn.Revision} )
*/SELECT @@session.auto_increment_increment
> 5 Query SHOW COLLATION
> 5 Query SET character_set_results = NULL
> 5 Query SET autocommit=1
> 5 Query select BUNDLE_DATA from PM_WS_BUNDLE where NODE_ID =
x'CAFEBABECAFEBABECAFEBABECAFEBABE'
> 5 Query select BUNDLE_DATA from PM_WS_BUNDLE where NODE_ID =
x'C74FA522295945668895FDDFA07BDEF1'
> 5 Query select BUNDLE_DATA from PM_WS_BUNDLE where NODE_ID =
x'2F0E18E2B49343CDADE6B6A5A01F74FE'
--
So, this connection does nothing harm to the repository,
and after a few seconds, same API call succeeds and documents
can be stored and read.
I have tried transaction-isolation setting at my.ini, then,
tried to use Oracle10, but same Exception occurs.
Then, this should be jackrabbit problem, I think.
I've tried FineGrainedISMLocking of jackrabbit, but nothing changed...
It seemes to me that there are many users operating jackrabbit
on clustering servers and no one have met this problem.
So I think something is wrong with us( =repository.xml)...
<<< Please help us. Any suggestion is appreciated. >>>
But Yesterday, I found JCR-1940, it is still opened...
> (JCR-1940)
> Date: Jan 19, 2009 4:41:35 am
> Reporter: Richa Khurana
> Priority: Blocker
>
> We have a enabled jackrabbit clustering. In this mode following
exception occurswhen 2 users simultaneouly add documents to Jack rabbit
repository registeredwith node id 1 and 2 respectively-
>
> 14:59:55,312 ERROR [DocumentHelper] Exception occurred while adding a
manuallyuploaded document to the jackrabbit:
> javax.jcr.InvalidItemStateException:
cafebabe-cafe-babe-cafe-babecafebabe hasbeen modified externally
> at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1109)
> at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:846)
...If there is no measure, we have to add some codes to catch this Exception
and retry after a few random seconds.
But I think it should be the last measure.
Thank you for reading long question.
Takahiro OGAWA
[jira] Commented: (JCR-1952) DOMException: NAMESPACE_ERR thrown when exporting document view
[
https://issues.apache.org/jira/browse/JCR-1952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12673042#action_12673042
]
Grégory Joseph commented on JCR-1952:
-
JBoss 4.2.2 and 5.0.0 have a {{xalan.jar}} in their {{lib/endorsed}} folder.
Removing it solved the problem for me.
> DOMException: NAMESPACE_ERR thrown when exporting document view
> ---
>
> Key: JCR-1952
> URL: https://issues.apache.org/jira/browse/JCR-1952
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: xml
>Affects Versions: 1.5.2
>Reporter: Lóránt Pintér
>
> When I try to export some nodes with ExportDocumentView I get a DOMException
> with Jackrabbit 1.5.2. Version 1.4.6 works fine. Xerces version was 2.8.1.
> Code:
> Document document = documentBuilder.newDocument();
> Element exportElement = (Element)
> document.appendChild(document.createElement("Export"));
> Result result = new DOMResult(exportElement);
> TransformerHandler transformerHandler =
> saxTransformerFactory.newTransformerHandler();
> transformerHandler.setResult(result);
> session.exportDocumentView(workflowNode.getPath(), transformerHandler, true,
> false);
> Exception:
> org.w3c.dom.DOMException: NAMESPACE_ERR: An attempt is made to create or
> change an object in a way which is incorrect with regard to namespaces.
> at org.apache.xerces.dom.CoreDocumentImpl.checkDOMNSErr(Unknown Source)
> at org.apache.xerces.dom.AttrNSImpl.setName(Unknown Source)
> at org.apache.xerces.dom.AttrNSImpl.(Unknown Source)
> at org.apache.xerces.dom.CoreDocumentImpl.createAttributeNS(Unknown
> Source)
> at org.apache.xerces.dom.ElementImpl.setAttributeNS(Unknown Source)
> at
> com.sun.org.apache.xalan.internal.xsltc.trax.SAX2DOM.startElement(SAX2DOM.java:194)
> at
> com.sun.org.apache.xml.internal.serializer.ToXMLSAXHandler.closeStartTag(ToXMLSAXHandler.java:204)
> at
> com.sun.org.apache.xml.internal.serializer.ToSAXHandler.flushPending(ToSAXHandler.java:277)
> at
> com.sun.org.apache.xml.internal.serializer.ToXMLSAXHandler.startElement(ToXMLSAXHandler.java:646)
> at
> com.sun.org.apache.xalan.internal.xsltc.trax.TransformerHandlerImpl.startElement(TransformerHandlerImpl.java:263)
> at
> org.apache.jackrabbit.commons.xml.Exporter.startElement(Exporter.java:438)
> at
> org.apache.jackrabbit.commons.xml.DocumentViewExporter.exportNode(DocumentViewExporter.java:76)
> at
> org.apache.jackrabbit.commons.xml.Exporter.exportNode(Exporter.java:298)
> at
> org.apache.jackrabbit.commons.xml.Exporter.exportNodes(Exporter.java:214)
> at
> org.apache.jackrabbit.commons.xml.DocumentViewExporter.exportNode(DocumentViewExporter.java:77)
> at
> org.apache.jackrabbit.commons.xml.Exporter.exportNode(Exporter.java:295)
> at org.apache.jackrabbit.commons.xml.Exporter.export(Exporter.java:144)
> at
> org.apache.jackrabbit.commons.AbstractSession.export(AbstractSession.java:461)
> at
> org.apache.jackrabbit.commons.AbstractSession.exportDocumentView(AbstractSession.java:241)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Jackrabbit 1.5.3 release plan
I'm trying to figure out what causes JCR-1952 - unless it's something stupid on my part, it seems pretty much like a blocker bug, even though it doesn't happen on all platforms. Cheers, -g https://issues.apache.org/jira/browse/JCR-1952 On Feb 10, 2009, at 5:00 PM, Jukka Zitting wrote: Hi, Fixes are again accumulating in the trunk and there seems to be some demand for a new patch release. So I'm planning to do a 1.5.3 release next week. I'll be going through the issue tracker for candidate fixes to be included in the 1.5 branch, but any input on what fixes you'd like to see in the release is of course welcome. BR, Jukka Zitting
Re: Jackrabbit 1.5.3 release plan
Hi Jukka, if that https://issues.apache.org/jira/browse/JCR-1959 would be easy to solve it would be nice if it would be part of the 1.5.3 realease. Bye, Sandro Jukka Zitting schrieb: Hi, Fixes are again accumulating in the trunk and there seems to be some demand for a new patch release. So I'm planning to do a 1.5.3 release next week. I'll be going through the issue tracker for candidate fixes to be included in the 1.5 branch, but any input on what fixes you'd like to see in the release is of course welcome. BR, Jukka Zitting
[jira] Commented: (JCR-1952) DOMException: NAMESPACE_ERR thrown when exporting document view
[
https://issues.apache.org/jira/browse/JCR-1952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12673014#action_12673014
]
Grégory Joseph commented on JCR-1952:
-
We encounter a similar issue when using JR 1.5 with JBoss - namespaces are
declared twice in the first node.
> DOMException: NAMESPACE_ERR thrown when exporting document view
> ---
>
> Key: JCR-1952
> URL: https://issues.apache.org/jira/browse/JCR-1952
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: xml
>Affects Versions: 1.5.2
>Reporter: Lóránt Pintér
>
> When I try to export some nodes with ExportDocumentView I get a DOMException
> with Jackrabbit 1.5.2. Version 1.4.6 works fine. Xerces version was 2.8.1.
> Code:
> Document document = documentBuilder.newDocument();
> Element exportElement = (Element)
> document.appendChild(document.createElement("Export"));
> Result result = new DOMResult(exportElement);
> TransformerHandler transformerHandler =
> saxTransformerFactory.newTransformerHandler();
> transformerHandler.setResult(result);
> session.exportDocumentView(workflowNode.getPath(), transformerHandler, true,
> false);
> Exception:
> org.w3c.dom.DOMException: NAMESPACE_ERR: An attempt is made to create or
> change an object in a way which is incorrect with regard to namespaces.
> at org.apache.xerces.dom.CoreDocumentImpl.checkDOMNSErr(Unknown Source)
> at org.apache.xerces.dom.AttrNSImpl.setName(Unknown Source)
> at org.apache.xerces.dom.AttrNSImpl.(Unknown Source)
> at org.apache.xerces.dom.CoreDocumentImpl.createAttributeNS(Unknown
> Source)
> at org.apache.xerces.dom.ElementImpl.setAttributeNS(Unknown Source)
> at
> com.sun.org.apache.xalan.internal.xsltc.trax.SAX2DOM.startElement(SAX2DOM.java:194)
> at
> com.sun.org.apache.xml.internal.serializer.ToXMLSAXHandler.closeStartTag(ToXMLSAXHandler.java:204)
> at
> com.sun.org.apache.xml.internal.serializer.ToSAXHandler.flushPending(ToSAXHandler.java:277)
> at
> com.sun.org.apache.xml.internal.serializer.ToXMLSAXHandler.startElement(ToXMLSAXHandler.java:646)
> at
> com.sun.org.apache.xalan.internal.xsltc.trax.TransformerHandlerImpl.startElement(TransformerHandlerImpl.java:263)
> at
> org.apache.jackrabbit.commons.xml.Exporter.startElement(Exporter.java:438)
> at
> org.apache.jackrabbit.commons.xml.DocumentViewExporter.exportNode(DocumentViewExporter.java:76)
> at
> org.apache.jackrabbit.commons.xml.Exporter.exportNode(Exporter.java:298)
> at
> org.apache.jackrabbit.commons.xml.Exporter.exportNodes(Exporter.java:214)
> at
> org.apache.jackrabbit.commons.xml.DocumentViewExporter.exportNode(DocumentViewExporter.java:77)
> at
> org.apache.jackrabbit.commons.xml.Exporter.exportNode(Exporter.java:295)
> at org.apache.jackrabbit.commons.xml.Exporter.export(Exporter.java:144)
> at
> org.apache.jackrabbit.commons.AbstractSession.export(AbstractSession.java:461)
> at
> org.apache.jackrabbit.commons.AbstractSession.exportDocumentView(AbstractSession.java:241)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1944) Privilege content representation should be of property type NAME
[ https://issues.apache.org/jira/browse/JCR-1944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12672976#action_12672976 ] angela commented on JCR-1944: - > I don't think we should merge this to 1.5 no, rather not. > BTW, do you think this should be noted in the 1.6 release notes for > people who are already trying out the new security code? I'm not sure > how big an impact the changed property type will cause. big. that's why i scheduled it for 2.0.0. but after all the 283 implementation is still work in progress and Issue #JCR-1588 has not been closed up to now. unless the spec is finalized there may be any kind of changes that break backwards compability. listing in in the release notes may still be a good idea. > Privilege content representation should be of property type NAME > > > Key: JCR-1944 > URL: https://issues.apache.org/jira/browse/JCR-1944 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-core, security >Affects Versions: 1.5.0 >Reporter: angela >Assignee: angela > Fix For: 1.6.0 > > > the content representation of jcr privileges should reflect that fact that > privilege names changed from simple string to JCR name. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1967) Impossible comparison in NodeTypeImpl
[
https://issues.apache.org/jira/browse/JCR-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12672973#action_12672973
]
angela commented on JCR-1967:
-
> Classifying this as an improvement
agreed... i was already tempted to make that change :)
> Impossible comparison in NodeTypeImpl
> -
>
> Key: JCR-1967
> URL: https://issues.apache.org/jira/browse/JCR-1967
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-jcr2spi
>Affects Versions: 1.6.0
>Reporter: Dave Brosius
>Assignee: angela
>Priority: Trivial
> Fix For: 1.6.0
>
>
> org.apache.jackrabbit.jcr2spi.nodetype.NodeTypeImpl does
> public boolean isNodeType(Name nodeTypeName) {
> return getName().equals(nodeTypeName) ||
> ent.includesNodeType(nodeTypeName);
> }
> as getName() is a string and nodeTypeName is a Name this will always be
> false. Perhaps you meant
> public boolean isNodeType(Name nodeTypeName) {
> return getName().equals(nodeTypeName.getLocalName()) ||
> ent.includesNodeType(nodeTypeName);
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1958) Enhanced JCR remoting (extending webdav SPI impl, basic remoting servlet)
[ https://issues.apache.org/jira/browse/JCR-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12672972#action_12672972 ] angela commented on JCR-1958: - rev. 743713 extended webapp to contain: - add overview of the batch read/write functionality /jackrabbit/webdav-remoting.jsp - some general introduction explaining the basics /jackrabbit/remoting/index.jsp - add examples (links on remoting/index.jsp) > Enhanced JCR remoting (extending webdav SPI impl, basic remoting servlet) > - > > Key: JCR-1958 > URL: https://issues.apache.org/jira/browse/JCR-1958 > Project: Jackrabbit Content Repository > Issue Type: New Feature > Components: jackrabbit-jcr-server, jackrabbit-webapp, sandbox >Reporter: angela >Assignee: angela >Priority: Minor > Fix For: 1.6.0 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1958) Enhanced JCR remoting (extending webdav SPI impl, basic remoting servlet)
[ https://issues.apache.org/jira/browse/JCR-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved JCR-1958. - Resolution: Fixed > Enhanced JCR remoting (extending webdav SPI impl, basic remoting servlet) > - > > Key: JCR-1958 > URL: https://issues.apache.org/jira/browse/JCR-1958 > Project: Jackrabbit Content Repository > Issue Type: New Feature > Components: jackrabbit-jcr-server, jackrabbit-webapp, sandbox >Reporter: angela >Assignee: angela >Priority: Minor > Fix For: 1.6.0 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1958) Enhanced JCR remoting (extending webdav SPI impl, basic remoting servlet)
[ https://issues.apache.org/jira/browse/JCR-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated JCR-1958: Component/s: sandbox jackrabbit-webapp jackrabbit-jcr-server Fix Version/s: 1.6.0 > Enhanced JCR remoting (extending webdav SPI impl, basic remoting servlet) > - > > Key: JCR-1958 > URL: https://issues.apache.org/jira/browse/JCR-1958 > Project: Jackrabbit Content Repository > Issue Type: New Feature > Components: jackrabbit-jcr-server, jackrabbit-webapp, sandbox >Reporter: angela >Assignee: angela >Priority: Minor > Fix For: 1.6.0 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Jackrabbit 1.5.3 release plan
http://issues.apache.org/jira/browse/JCR-1554 but I think this already in... thx! Philipp -- View this message in context: http://www.nabble.com/Jackrabbit-1.5.3-release-plan-tp21936668p21973262.html Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
JCR meetup in Amsterdam?
Hi, [cross-posting since this is for both Jackrabbit and Sling people] Last year we had a JCR meetup event during the ApacheCon in Amsterdam [1]. Now there's a chance of doing one again this year during the ApacheCon at the end of March [2]. The three-hour event would take place in the evening either on Monday 23rd or on Tuesday 24th. The location is the Mövenpick hotel in central Amsterdam. The meetup will only happen if we can find enough attendees, presentations and sponsors. Please let me know, preferably already by the end of this week, if you'd be interested in participating. [ ] I'd like to attend on Monday, March 23 [ ] I'd like to attend on Tuesday, March 24 Presentations can be anything JCR-related and may last between five minutes and about half an hour. [ ] I'd like to present X on Monday, March 23 [ ] I'd like to present X on Tuesday, March 24 The event will be free for everyone to attend, but we still need to cover the rent of the meeting room and other related costs. To cover these costs we're looking for companies to sponsor the event. Sponsoring is not expensive, and by sponsoring you get to support the Jackrabbit and Sling projects and get your name attached to the event. You can contact me for more details. [1] http://wiki.apache.org/jackrabbit/JcrMeetupApril2008 [2] http://www.eu.apachecon.com/c/aceu2009/ BR, Jukka Zitting
[jira] Created: (JCR-1977) authentication order has changed from 1.4.x to 1.5.x
authentication order has changed from 1.4.x to 1.5.x
Key: JCR-1977
URL: https://issues.apache.org/jira/browse/JCR-1977
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: jackrabbit-core
Affects Versions: 1.5.2, 1.5.0
Environment: JBoss 4.0.5 + deployed Liferay 4.2.2 on any Platform
Reporter: Thomas Fromm
Priority: Critical
In 1.4.x inside RepositoryImpl.login(...) at first the local configuration is
checked for configured LoginModules and after it was unsuccessful, the JAAS
component is asked:
AuthContext authCtx;
LoginModuleConfig lmc = repConfig.getLoginModuleConfig();
if (lmc == null) {
authCtx = new AuthContext.JAAS(repConfig.getAppName(),
credentials);
} else {
...
With 1.5.x this behaviour has moved to SimpleSecurityManager.init(..) and is
changed:
LoginModuleConfig loginModConf = config.getLoginModuleConfig();
authCtxProvider = new AuthContextProvider(config.getAppName(),
loginModConf);
if (authCtxProvider.isJAAS()) {
log.info("init: using JAAS LoginModule configuration for " +
config.getAppName());
} else if (authCtxProvider.isLocal()) {
...
The problem is with JBoss JAAS implemantation, that authCtxProvider.isJAAS()
is always true.
Because for any reason, the result of
Configuration.getAppConfigurationEntry(appName) is never empty,
when a jaas.config is specified for Liferay. Using different appName takes no
effect, always the configuration inside the jaas.config is used.
I think still first the local configuration should be concerned, before using
JAAS.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Using a repository manager (Was: [jira] Created: (JCRSITE-11) Prevent accidental release deployments)
Hi, +1 We just have to inform our downstream SNAPSHOT testers, that the well-known apache snapshot repository is not used by our snapshots any more and how they would have to configure to use the new repository.a.o Regards Felix Jukka Zitting schrieb: > Hi, > > On Mon, Feb 9, 2009 at 1:28 PM, Jukka Zitting (JIRA) wrote: >> The Maven people are currently setting up a new repository.apache.org >> repository >> manager that nicely supports staged deployment. [...] > > I have now requested access to this repository manager (see INFRA-1899 > [1]). I'm planning to try how well it works for deploying snapshots > from our Hudson builds and for staging and publishing official > releases. > > If it works fine, then I would propose that we use > repository.apache.org to replace the current m2-snapshot-repository as > the location of our snapshots and that we modify our release processes > to use the repository manager for staging and reviewing release > candidates. > > [1] https://issues.apache.org/jira/browse/INFRA-1899 > > BR, > > Jukka Zitting >
