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 <[email protected]> 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 <[email protected]>
>>> 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 <[email protected]
>>>>>> 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
> 

Reply via email to