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 Sr." <sc...@me.com> on 2016/03/01 01:02:10 UTC
Re: Random Failure to Deploy a File using AddOrUpdateNodeCommand
Sorry for the late reply but I got bogged down by a customer going live.
Here is the stack trace:
[ 122101] ERROR - plication.impl.ApplicationImpl - org.apache.sling.ide.io.ConnectorException: /content/dam/aembase/asset.jpg/jcr:content/renditions/cq5dam.web.1280.1280.jpeg
java.lang.RuntimeException: 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.publishModule(AbstractDeploymentManager.java:192)
at com.headwire.aem.tooling.intellij.communication.ServerConnectionManager.deployModule(ServerConnectionManager.java:493)
at com.headwire.aem.tooling.intellij.communication.ServerConnectionManager.deployModules(ServerConnectionManager.java:478)
at com.headwire.aem.tooling.intellij.action.DeployToServerAction$1$1.run(DeployToServerAction.java:99)
at com.intellij.openapi.application.impl.ApplicationImpl.runReadAction(ApplicationImpl.java:951)
at com.headwire.aem.tooling.intellij.action.DeployToServerAction$1.run(DeployToServerAction.java:68)
at com.intellij.openapi.progress.impl.CoreProgressManager$TaskRunnable.run(CoreProgressManager.java:563)
at com.intellij.openapi.progress.impl.CoreProgressManager$2.run(CoreProgressManager.java:142)
at com.intellij.openapi.progress.impl.CoreProgressManager.registerIndicatorAndRun(CoreProgressManager.java:446)
at com.intellij.openapi.progress.impl.CoreProgressManager.executeProcessUnderProgress(CoreProgressManager.java:392)
at com.intellij.openapi.progress.impl.ProgressManagerImpl.executeProcessUnderProgress(ProgressManagerImpl.java:54)
at com.intellij.openapi.progress.impl.CoreProgressManager.runProcess(CoreProgressManager.java:127)
at com.intellij.openapi.progress.impl.ProgressManagerImpl$1.run(ProgressManagerImpl.java:126)
at com.intellij.openapi.application.impl.ApplicationImpl$8.run(ApplicationImpl.java:366)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at org.jetbrains.ide.PooledThreadExecutor$1$1.run(PooledThreadExecutor.java:55)
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
Caused by: 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.jackrabbit.jcr2spi.state.ItemStateValidator.checkCollision(ItemStateValidator.java:594)
at org.apache.jackrabbit.jcr2spi.state.ItemStateValidator.checkAddNode(ItemStateValidator.java:392)
at org.apache.jackrabbit.jcr2spi.state.SessionItemStateManager.addNodeState(SessionItemStateManager.java:435)
at org.apache.jackrabbit.jcr2spi.state.SessionItemStateManager.visit(SessionItemStateManager.java:245)
at org.apache.jackrabbit.jcr2spi.operation.AddNode.accept(AddNode.java:79)
at org.apache.jackrabbit.jcr2spi.state.SessionItemStateManager.execute(SessionItemStateManager.java:215)
at org.apache.jackrabbit.jcr2spi.NodeImpl.createNode(NodeImpl.java:1454)
at org.apache.jackrabbit.jcr2spi.NodeImpl.addNode(NodeImpl.java:186)
at org.apache.sling.ide.impl.vlt.AddOrUpdateNodeCommand.createNode(AddOrUpdateNodeCommand.java:176)
at org.apache.sling.ide.impl.vlt.AddOrUpdateNodeCommand.update(AddOrUpdateNodeCommand.java:99)
at org.apache.sling.ide.impl.vlt.AddOrUpdateNodeCommand.execute0(AddOrUpdateNodeCommand.java:85)
at org.apache.sling.ide.impl.vlt.AddOrUpdateNodeCommand.execute0(AddOrUpdateNodeCommand.java:1)
at org.apache.sling.ide.impl.vlt.JcrCommand.execute(JcrCommand.java:68)
... 22 more
The delay in the save() does prevent the issue. That said I am not sure if it is related to the DAM as my test projects are
just that. I’ll keep you posted if I find other scenarios where it does fail.
- Andy
> On Feb 18, 2016, at 12:15 AM, Robert Munteanu <ro...@apache.org> 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
Re: Random Failure to Deploy a File using AddOrUpdateNodeCommand
Posted by Robert Munteanu <ro...@apache.org>.
On Thu, 2016-03-03 at 13:13 -0800, Andreas Schaefer Sr. wrote:
> I tried to do some testing in Eclipse but I cannot connect. Always
> get the exception
> Connection Refused.
>
> No repository found at http://localhost:4052/
> http://localhost:4052/server/-/jcr:root : java.net.ConnectException:
> Connection refused
> http://localhost:4052/crx/-/jcr:root : java.net.ConnectException:
> Connection refused
> No repository found at http://localhost:4052/
> http://localhost:4052/server/-/jcr:root : java.net.ConnectException:
> Connection refused
> http://localhost:4052/crx/-/jcr:root : java.net.ConnectException:
> Connection refused
>
> Any idea what I am doing wrong?
Sounds like you don't have a server running at http://localhost:4502 .
Robert
>
> - Andy
>
> > On Mar 3, 2016, at 7:57 AM, Robert Munteanu <ro...@apache.org>
> > wrote:
> >
> > On Thu, 2016-03-03 at 06:57 -0800, Andreas Schaefer Sr. wrote:
> > > Hi Robert
> > >
> > > Not sure why but I think this is a timing issue as a 100ms delay
> > > does
> > > prevent it for me.
> > >
> > > Ruben was suggesting to change the order of the updates where the
> > > /renditions/original is added last (after the other renditions)
> > > but I
> > > think that is just masking the problem once more.
> > I would not go there :-) First of all, this should be agnostic to
> > any
> > workflows or similar components running in a Sling instance.
> >
> > Second of all, reordering updates can be tricky - I've had bugs due
> > to
> > that.
> >
> > >
> > > I think this is a commit issue where IMPL-VLT is committing the
> > > change after each file and not after updating the entire batch. I
> > > would rather suggest to let the plugin control the commits so
> > > that
> > > the changes to the renditions are only visible to the workflow
> > > when
> > > all files including the renditions are updated.
> > Yes, that's a possible way out.
> >
> > > I created the ticket:
> > >
> > > https://issues.apache.org/jira/browse/SLING-5582
> > >
> > > Let me know if you need more info in the ticket.
> > Ack, let's continue the conversation other there.
> >
> > Thanks,
> >
> > Robert
> >
> > >
> > > Cheers - Andy
> > >
> > > >
> > > > On Mar 3, 2016, at 2:14 AM, Robert Munteanu <rombert@apache.org
> > > > >
> > > > wrote:
> > > >
> > > > On Wed, 2016-03-02 at 17:05 -0800, Andreas Schaefer Sr. wrote:
> > > > >
> > > > > 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.
> > > > I do test some projects which should trigger these issues but I
> > > > don't
> > > > see them at all. Not sure why ...
> > > >
> > > > Now that we understand the root cause, the next step for a fix
> > > > is
> > > > to
> > > > get a test that fails. Feel free to add create a Jira issue to
> > > > we
> > > > can
> > > > track this better.
> > > >
> > > > Thanks,
> > > >
> > > > Robert
> > > >
> > > > >
> > > > >
> > > > > - Andy
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Mar 2, 2016, at 4:09 PM, Andreas Schaefer Sr. <schaefera
> > > > > > @me.
> > > > > > com>
> > > > > > 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 <rombert@apac
> > > > > > > he.o
> > > > > > > rg>
> > > > > > > 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 <romber
> > > > > > > > > t@ap
> > > > > > > > > ache
> > > > > > > > > .org>
> > > > > > > > > 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
Re: Random Failure to Deploy a File using AddOrUpdateNodeCommand
Posted by "Andreas Schaefer Sr." <sc...@me.com>.
I tried to do some testing in Eclipse but I cannot connect. Always get the exception
Connection Refused.
No repository found at http://localhost:4052/
http://localhost:4052/server/-/jcr:root : java.net.ConnectException: Connection refused
http://localhost:4052/crx/-/jcr:root : java.net.ConnectException: Connection refused
No repository found at http://localhost:4052/
http://localhost:4052/server/-/jcr:root : java.net.ConnectException: Connection refused
http://localhost:4052/crx/-/jcr:root : java.net.ConnectException: Connection refused
Any idea what I am doing wrong?
- Andy
> On Mar 3, 2016, at 7:57 AM, Robert Munteanu <ro...@apache.org> wrote:
>
> On Thu, 2016-03-03 at 06:57 -0800, Andreas Schaefer Sr. wrote:
>> Hi Robert
>>
>> Not sure why but I think this is a timing issue as a 100ms delay does
>> prevent it for me.
>>
>> Ruben was suggesting to change the order of the updates where the
>> /renditions/original is added last (after the other renditions) but I
>> think that is just masking the problem once more.
>
> I would not go there :-) First of all, this should be agnostic to any
> workflows or similar components running in a Sling instance.
>
> Second of all, reordering updates can be tricky - I've had bugs due to
> that.
>
>>
>> I think this is a commit issue where IMPL-VLT is committing the
>> change after each file and not after updating the entire batch. I
>> would rather suggest to let the plugin control the commits so that
>> the changes to the renditions are only visible to the workflow when
>> all files including the renditions are updated.
>
> Yes, that's a possible way out.
>
>> I created the ticket:
>>
>> https://issues.apache.org/jira/browse/SLING-5582
>>
>> Let me know if you need more info in the ticket.
>
> Ack, let's continue the conversation other there.
>
> Thanks,
>
> Robert
>
>>
>> Cheers - Andy
>>
>>>
>>> On Mar 3, 2016, at 2:14 AM, Robert Munteanu <ro...@apache.org>
>>> wrote:
>>>
>>> On Wed, 2016-03-02 at 17:05 -0800, Andreas Schaefer Sr. wrote:
>>>>
>>>> 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.
>>> I do test some projects which should trigger these issues but I
>>> don't
>>> see them at all. Not sure why ...
>>>
>>> Now that we understand the root cause, the next step for a fix is
>>> to
>>> get a test that fails. Feel free to add create a Jira issue to we
>>> can
>>> track this better.
>>>
>>> Thanks,
>>>
>>> Robert
>>>
>>>>
>>>>
>>>> - Andy
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mar 2, 2016, at 4:09 PM, Andreas Schaefer Sr. <schaefera@me.
>>>>> com>
>>>>> 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 <rombert@apache.o
>>>>>> rg>
>>>>>> 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 <rombert@ap
>>>>>>>> ache
>>>>>>>> .org>
>>>>>>>> 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
>
Re: Random Failure to Deploy a File using AddOrUpdateNodeCommand
Posted by Robert Munteanu <ro...@apache.org>.
On Thu, 2016-03-03 at 06:57 -0800, Andreas Schaefer Sr. wrote:
> Hi Robert
>
> Not sure why but I think this is a timing issue as a 100ms delay does
> prevent it for me.
>
> Ruben was suggesting to change the order of the updates where the
> /renditions/original is added last (after the other renditions) but I
> think that is just masking the problem once more.
I would not go there :-) First of all, this should be agnostic to any
workflows or similar components running in a Sling instance.
Second of all, reordering updates can be tricky - I've had bugs due to
that.
>
> I think this is a commit issue where IMPL-VLT is committing the
> change after each file and not after updating the entire batch. I
> would rather suggest to let the plugin control the commits so that
> the changes to the renditions are only visible to the workflow when
> all files including the renditions are updated.
Yes, that's a possible way out.
> I created the ticket:
>
> https://issues.apache.org/jira/browse/SLING-5582
>
> Let me know if you need more info in the ticket.
Ack, let's continue the conversation other there.
Thanks,
Robert
>
> Cheers - Andy
>
> >
> > On Mar 3, 2016, at 2:14 AM, Robert Munteanu <ro...@apache.org>
> > wrote:
> >
> > On Wed, 2016-03-02 at 17:05 -0800, Andreas Schaefer Sr. wrote:
> > >
> > > 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.
> > I do test some projects which should trigger these issues but I
> > don't
> > see them at all. Not sure why ...
> >
> > Now that we understand the root cause, the next step for a fix is
> > to
> > get a test that fails. Feel free to add create a Jira issue to we
> > can
> > track this better.
> >
> > Thanks,
> >
> > Robert
> >
> > >
> > >
> > > - Andy
> > >
> > > >
> > > >
> > > >
> > > > On Mar 2, 2016, at 4:09 PM, Andreas Schaefer Sr. <schaefera@me.
> > > > com>
> > > > 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 <rombert@apache.o
> > > > > rg>
> > > > > 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 <rombert@ap
> > > > > > > ache
> > > > > > > .org>
> > > > > > > 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
Re: Random Failure to Deploy a File using AddOrUpdateNodeCommand
Posted by "Andreas Schaefer Sr." <sc...@me.com>.
Hi Robert
Not sure why but I think this is a timing issue as a 100ms delay does prevent it for me.
Ruben was suggesting to change the order of the updates where the /renditions/original is added last (after the other renditions) but I think that is just masking the problem once more.
I think this is a commit issue where IMPL-VLT is committing the change after each file and not after updating the entire batch. I would rather suggest to let the plugin control the commits so that the changes to the renditions are only visible to the workflow when all files including the renditions are updated.
I created the ticket:
https://issues.apache.org/jira/browse/SLING-5582
Let me know if you need more info in the ticket.
Cheers - Andy
> On Mar 3, 2016, at 2:14 AM, Robert Munteanu <ro...@apache.org> wrote:
>
> On Wed, 2016-03-02 at 17:05 -0800, Andreas Schaefer Sr. wrote:
>> 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.
>
> I do test some projects which should trigger these issues but I don't
> see them at all. Not sure why ...
>
> Now that we understand the root cause, the next step for a fix is to
> get a test that fails. Feel free to add create a Jira issue to we can
> track this better.
>
> Thanks,
>
> Robert
>
>>
>> - Andy
>>
>>>
>>>
>>> On Mar 2, 2016, at 4:09 PM, Andreas Schaefer Sr. <sc...@me.com>
>>> 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 <ro...@apache.org>
>>>> 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 <rombert@apache
>>>>>> .org>
>>>>>> 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
>
Re: Random Failure to Deploy a File using AddOrUpdateNodeCommand
Posted by Robert Munteanu <ro...@apache.org>.
On Wed, 2016-03-02 at 17:05 -0800, Andreas Schaefer Sr. wrote:
> 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.
I do test some projects which should trigger these issues but I don't
see them at all. Not sure why ...
Now that we understand the root cause, the next step for a fix is to
get a test that fails. Feel free to add create a Jira issue to we can
track this better.
Thanks,
Robert
>
> - Andy
>
> >
> >
> > On Mar 2, 2016, at 4:09 PM, Andreas Schaefer Sr. <sc...@me.com>
> > 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 <ro...@apache.org>
> > > 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 <rombert@apache
> > > > > .org>
> > > > > 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
Re: Random Failure to Deploy a File using AddOrUpdateNodeCommand
Posted by "Andreas Schaefer Sr." <sc...@me.com>.
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. <sc...@me.com> 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 <ro...@apache.org> 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 <ro...@apache.org>
>>>> 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
>
Re: Random Failure to Deploy a File using AddOrUpdateNodeCommand
Posted by "Andreas Schaefer Sr." <sc...@me.com>.
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 <ro...@apache.org> 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 <ro...@apache.org>
>>> 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
Re: Random Failure to Deploy a File using AddOrUpdateNodeCommand
Posted by Robert Munteanu <ro...@apache.org>.
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 <ro...@apache.org>
> > 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