[
https://issues.apache.org/jira/browse/SLING-5582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15177975#comment-15177975
]
Robert Munteanu edited comment on SLING-5582 at 3/3/16 3:53 PM:
----------------------------------------------------------------
This is the stacktrace of the exception:
{noformat}
Caused by: org.apache.sling.ide.io.ConnectorException:
/content/dam/aembase/asset.jpg/jcr:content/renditions/cq5dam.web.1280.1280.jpeg
at
com.headwire.aem.tooling.intellij.communication.AbstractDeploymentManager.execute(AbstractDeploymentManager.java:347)
at
com.headwire.aem.tooling.intellij.communication.AbstractDeploymentManager.publishModule(AbstractDeploymentManager.java:137)
... 19 more
Caused by: org.apache.sling.ide.transport.RepositoryException:
javax.jcr.ItemExistsException: Cannot add child node
'cq5dam.web.1280.1280.jpeg' to
/content/dam/aembase/asset.jpg/jcr:content/renditions: colliding with
same-named existing node.
at org.apache.sling.ide.impl.vlt.JcrResult.failure(JcrResult.java:33)
at org.apache.sling.ide.impl.vlt.JcrCommand.execute(JcrCommand.java:80)
at
org.apache.sling.ide.transport.TracingCommand.execute(TracingCommand.java:45)
at
com.headwire.aem.tooling.intellij.communication.AbstractDeploymentManager.execute(AbstractDeploymentManager.java:336)
... 20 more
{noformat}
It is caused by the session.save() method call in JcrCommand:
{code:java}
@Override
public Result<T> execute() {
Session session = null;
try {
session = repository.login(credentials);
T result = execute0(session);
// try {
// Thread.sleep(100);
// } catch(InterruptedException e) {
// }
session.save();
return JcrResult.success(result);
} catch (LoginException e) {
return JcrResult.failure(e);
} catch (RepositoryException e) {
return JcrResult.failure(e);
} catch (IOException e) {
return JcrResult.failure(e);
} finally {
if (session != null)
session.logout();
}
}
{code}
In my environment adding the delay (commented out above) does solve it most of
the time but that's still a bandaid. If the session is provided to the
JcrCommand and the save() is called when the plugin has done a logical group
(all files inside a DAM asset etc) the problem should not arise anymore.
was (Author: schaefa):
This is the stacktrace of the exception:
Caused by: org.apache.sling.ide.io.ConnectorException:
/content/dam/aembase/asset.jpg/jcr:content/renditions/cq5dam.web.1280.1280.jpeg
at
com.headwire.aem.tooling.intellij.communication.AbstractDeploymentManager.execute(AbstractDeploymentManager.java:347)
at
com.headwire.aem.tooling.intellij.communication.AbstractDeploymentManager.publishModule(AbstractDeploymentManager.java:137)
... 19 more
Caused by: org.apache.sling.ide.transport.RepositoryException:
javax.jcr.ItemExistsException: Cannot add child node
'cq5dam.web.1280.1280.jpeg' to
/content/dam/aembase/asset.jpg/jcr:content/renditions: colliding with
same-named existing node.
at org.apache.sling.ide.impl.vlt.JcrResult.failure(JcrResult.java:33)
at org.apache.sling.ide.impl.vlt.JcrCommand.execute(JcrCommand.java:80)
at
org.apache.sling.ide.transport.TracingCommand.execute(TracingCommand.java:45)
at
com.headwire.aem.tooling.intellij.communication.AbstractDeploymentManager.execute(AbstractDeploymentManager.java:336)
... 20 more
It is caused by the session.save() method call in JcrCommand:
@Override
public Result<T> execute() {
Session session = null;
try {
session = repository.login(credentials);
T result = execute0(session);
// try {
// Thread.sleep(100);
// } catch(InterruptedException e) {
// }
session.save();
return JcrResult.success(result);
} catch (LoginException e) {
return JcrResult.failure(e);
} catch (RepositoryException e) {
return JcrResult.failure(e);
} catch (IOException e) {
return JcrResult.failure(e);
} finally {
if (session != null)
session.logout();
}
}
In my environment adding the delay (commented out above) does solve it most of
the time but that's still a bandaid. If the session is provided to the
JcrCommand and the save() is called when the plugin has done a logical group
(all files inside a DAM asset etc) the problem should not arise anymore.
> DAM Updates fail due to race conditions with Workflows in AEM
> -------------------------------------------------------------
>
> Key: SLING-5582
> URL: https://issues.apache.org/jira/browse/SLING-5582
> Project: Sling
> Issue Type: Bug
> Components: IDE
> Affects Versions: Sling Eclipse IDE 1.0.10
> Reporter: Andreas Schaefer
> Fix For: Sling Eclipse IDE 1.1.2
>
>
> In my IntelliJ plugin an update of a DAM entry I sometimes run into an
> exception while updating rendition files. This seems to be caused by the DAM
> Workflows inside AEM which is triggered as soon as the original file is
> updated. This is probably due to the fact that the "impl-vlt" code is
> committing a change after each and every command and so the workflow is
> triggered right away causing problems with the updates of the rendition files.
> I would think this is not just an issue of DAM assets but in general an issue
> with any node that can trigger a workflow.
> From my point of view the plugin should be able to control the commits so
> that a logical group like a DAM asset can be update in single step.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
