WorkflowLauncherListener Is in same workflow for "Node Removed" launcher

I will investigate this and follow up here. 

We have encountered a similar problem although in our case we have only one node launcher that listens to the node modification event for the group node type and activates that group upon modification. We use the OOB activate content model to trigger the activation on the group node modification. The workflow does not seem to complete even after waiting for a day.  Since it's just s a simple activation, the workflow should not take this long for it to complete.  Any help in debugging this issue would be greatly appreciated.

539528    01.05.2015 13:41:03.426 *INFO* [Workflow Starter Thread] com.adobe.granite.workflow.core.launcher.WorkflowLauncherListener Is in same workflow: /etc/workflow/models/activate-content/jcr:content/model payload: /home/groups/xxxusers/xxxx-bloggers

It looks like Im getting similar behaviour when single launcher tries to run the same workflow with different payloads

Is that illegal behaviour as well?

There shouldn't be any restrictions for running many workflows with different payloads from a single launcher, I would expect that to always work.  For instance if you upload a few images to DAM they will all run workflows to generate renditions of the image.

Have you narrowed the problem down further or found anything in your log?  

Will

Yep, I thought there shouldn't be, but it doesn't look like that's the case......

I have a remote app that deletes bunch of pages from one site using WebDav and a workflow should delete corresponding pages from another.

All it does is loops through nodes to be deleted and calls myNode.remove(). So far so good, but once I call session.save() CQ5 starts throwing warning messages in logs similar to the one below for every node that doesn't get synchronized:

*INFO* [Workflow Starter Thread] com.adobe.granite.workflow.core.launcher.WorkflowLauncherListener Is in same workflow: /etc/workflow/models/sync-mobile-product-pages/jcr:content/model payload: /content/my-content-1

Now I have at least three problems with this behaviour:

1. Workflow is not executed at all and No Errors are added to Notifications, meaning that these pages are just lost and site administrators have no way to find that something is wrong.....
2. Only one concurrent execution of a given launcher?? That is just not good enough... They could have at least implemented a queue or something....
3. INFO level log for lost data?????

Hi,

I think what's happening is you're encountering a limitation of the node removed capabilities of the workflow launcher. Is the path "/content/my-content-1" in your example the node you deleted, or is it a node that is a parent of the node(s) you deleted?  

When a complete structure is removed a workflow is only launched where the parent node actually exists.  ie:

if the node /a/b/c is deleted where there was structure /a/b/c/d/e then we would only attempt to fire one launcher and the payload would be /a/b/c/d

This is implemented this way partly because of a limitation with JCR events as well as to make sure too many workflows are not started when an entire tree is deleted.

Is it possible for you to start these workflows directly using the workflow api when you remove these nodes?  For the node removal case starting workflows yourself will always be less problematic.

Hope this helps,

Will

The structure I have is /content/mySite/superCategory/category/product

I have a remote app that does real-time update of products(would be low load). Also in case there are some anomalies or structure of product pages has changed that remote app has an ability to remove all products and recreate them without touching categories as they are populated within CQ5(high load on cq5).

I wish there was a better way to delete bunch of products, for example delete by using jcr-sql2 or something. but even if it was possible then I would get into the same problem while recreating the products again...

Anyway, I "band-aided" the problem for now by removing workflows altogether and moving that functionality in that remote app. Something I wanted to avoid doing as it doesn't look like as clean solution, but at least it works...

We saw a similar "com.adobe.granite.workflow.core.launcher.WorkflowLauncherListener Is in same workflow" message. Turns out our custom workflow invocation found in /etc/workflow/instances was till in a "RUNNING" state. Now to figure out what the workflow has to do to set it to "COMPLETED"...

Turns out our custom workflow contains a node attribute called PROCESS which defines the classname of the process. In that same node, there should be an attribute called PROCESS_AUTO_ADVANCE set to 'true'. It seems that the Model Definition UI didn't set this attribute when saving the workflow (AEM 6.1).