I went ahead and took out any changed resource that contains a path with /renditions/ but not /renditions/original
That solves the issue if a workflow is present and active but, of course, if the workflow is not enabled then there will be no renditions. We could make it configurable to ignore renditions. That said I am wondering why this wasn’t discovered earlier. I am pretty sure if AEM has more latency or is executing slower it will not surface as delaying it did the trick. - Andy > > On Mar 2, 2016, at 4:09 PM, Andreas Schaefer Sr. <[email protected]> wrote: > > Hi Robert > > Yes, the Workflow are the most likely culprit as I did not encounter a > problem when the Workflow were disabled but as soon as I switched them back > on the error was back. > > So I am wondering if the /renditions folder should be replicated at all. > > BTW the error occurs even if the renditions were in place inside AEM. So both > the Create / Update Node workflows will cause this issue. > > Cheers - Andy Schaefer > >> On Mar 2, 2016, at 3:16 AM, Robert Munteanu <[email protected]> wrote: >> >> On Mon, 2016-02-29 at 16:02 -0800, Andreas Schaefer Sr. wrote: >>> Sorry for the late reply but I got bogged down by a customer going >>> live. >>> >>> Here is the stack trace: >>> >>> 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. >>> >> >> Thanks for the stack trace. My current theory is the following: >> >> - your project holds locally assets and their generated renditions >> - the asset generating the error does not exist remotely ( and by >> extension neither do its renditions ) >> - the asset is uploaded first and then the renditions start being >> generated ( via AEM workflows ) >> - at the same time, the plugin tries to upload the renditions >> >> Can you try disabling the DAM workflows that generate the renditions >> and see if this occurs? >> >> If that's the real reason, we can probably find a way around it. >> >> Thanks, >> >> Robert >> >>> >>> - Andy >>> >>>> >>>> On Feb 18, 2016, at 12:15 AM, Robert Munteanu <[email protected]> >>>> wrote: >>>> >>>> Hi Andy, >>>> >>>> On Wed, 2016-02-17 at 19:41 -0500, Andreas Schaefer Sr. wrote: >>>>> >>>>> Hi >>>>> >>>>> During the development of the IntelliJ plugin I ran into some >>>>> random >>>>> failures to deploy. >>>>> Looking deeper I save that the failure is happening when >>>>> session.save() is called and >>>>> to my surprise a slight delay (Thread.sleep(100)) does fix it on >>>>> my >>>>> Mac. >>>>> >>>>> The code is in JcrCommand inside the impl-vlt module. This is the >>>>> change that make it >>>>> work for me: >>>>> >>>>> @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); >>>>> The exception I see is a ItemExistsException and was thrown for a >>>>> folder and rendition file in the DAM. >>>> >>>> Can you add a stack trace? Does this only happen for DAM assets + >>>> renditions? >>>> >>>> Robert >
