[jira] [Commented] (JCR-3239) Removal of a top level node doesn't update the hierarchy manager's cache.

["Jan Haderka (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/JCR-3239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14021734#comment-14021734 ] 

Jan Haderka commented on JCR-3239:
----------------------------------

Hi Dominique,

here's the code involved (I tried to remove as mush as possible to make it clear and easy to read).

{code}
String fullPath; // target path where we want to import the xml
String resourceName; // location of the xml file on classpath

String basePath = StringUtils.substringBeforeLast(fullPath, "/");

// remove existing if found
InputStream stream = BootstrapUtil.class.getResourceAsStream(resourceName);
if (session.itemExists(fullPath)) {
    session.getRootNode().getNode(fullPath).remove();
}

// Import XML
session.importXml(basePath, stream, ImportUUIDBehavior.IMPORT_UUID_COLLISION_THROW);
{code}

Alternatively, we might execute import also via:
{code}
// Import XML
XMLReader reader = XMLReaderFactory.createXMLReader(org.apache.xerces.parsers.SAXParser.class.getName());
ContentHandler handler = session.getImportContentHandler(basepath, ImportUUIDBehavior.IMPORT_UUID_COLLISION_THROW);
reader.setContentHandler(handler);
reader.parse(new InputSource(stream));
{code}

but the result is same.

Please note that those failures are semi-random, nearly impossible to reproduce on systems where Derby is used as DB backing the repo, while occurring more often with MySQL or Oracle as repo backing DB.

Let me know if you need more information.

Jan

> Removal of a top level node doesn't update the hierarchy manager's cache.
> -------------------------------------------------------------------------
>
>                 Key: JCR-3239
>                 URL: https://issues.apache.org/jira/browse/JCR-3239
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core
>    Affects Versions: 2.2.11, 2.4
>            Reporter: Philipp Bärfuss
>
> *Problem*
> Scenario in which I encounter the problem:
> - given a node 'test' under root (/test)
> - re-imported the node after a deletion (all in-session operations) 
> {code}
> session.removeItem("/test")
> session.getImportXML("/", stream, ImportUUIDBehavior.IMPORT_UUID_COLLISION_THROW)
> {code}
> Result: throws an ItemExistsException
> If the same operations are executed deeper in the hierarchy (for instance /foo/bar) then the code works perfectly fine.
> *Findings*
> - session.removeItem informs the hierachy manager (via listener)
> --> CachingHierarchyManager.nodeRemoved(NodeState, Name, int, NodeId)
> - but the root node (passed as state) is not in the cache and hence the entry of the top level node is not removed
> --> CachingHierarchyManager: 458 
> - while trying to import the method SessionImporter.startNode(NodeInfo, List<PropInfo>) calls session.getHierarchyManager().getName(id) (line 400)
> - the stall information causes a uuid collision (the code expects an exception if the node doesn't exist but in this case it returns the name of the formerly removed node)
> Note: session.itemExists() and session.getNode() work as expected (the former returns false, the later throws an ItemNotFound exception)
> Note: I know that a different import behavior (replace existing) would solve the issue but I can't be 100% sure that the UUID match so I favor collision throw in my case.



--
This message was sent by Atlassian JIRA
(v6.2#6252)