You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Andreas Schaefer (JIRA)" <ji...@apache.org> on 2016/03/03 16:44:18 UTC

[jira] [Commented] (SLING-5582) DAM Updates fail due to race conditions with Workflows in AEM

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

Andreas Schaefer commented on SLING-5582:
-----------------------------------------

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
>
> 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)