Issue with setting up offloading for workflows

[#1]

I've setup offloading between two author instances. When I try to run the workflow (Image update asset) on the primary author instance, I see replication and reverse replication happening in the logs. However, the job never completes and renditions are not brought back to the primary author instance. Looks like this is a permissions issue...but what needs to be set? Here is an excerpt from the offloaded (worker) instance error log:

13.06.2017 11:42:44.945 *INFO* [Adobe Granite Offloading: Default Transporter] org.apache.jackrabbit.vault.fs.io.AutoSave Threshold of 1024 reached. saving approx 26 transient changes. 0 unresolved

13.06.2017 11:42:44.957 *ERROR* [Adobe Granite Offloading: Default Transporter] org.apache.jackrabbit.vault.fs.io.AutoSave error during auto save - retrying after refresh...

13.06.2017 11:42:44.971 *WARN* [Adobe Granite Offloading: Default Transporter] org.apache.jackrabbit.vault.fs.io.Importer Error while committing changes. Retrying import from checkpoint at /. Retries 9/10

13.06.2017 11:42:45.018 *INFO* [Adobe Granite Offloading: Default Transporter] org.apache.jackrabbit.vault.fs.io.AutoSave Threshold of 1024 reached. saving approx 26 transient changes. 0 unresolved

13.06.2017 11:42:45.030 *ERROR* [Adobe Granite Offloading: Default Transporter] org.apache.jackrabbit.vault.fs.io.AutoSave error during auto save - retrying after refresh...

13.06.2017 11:42:45.042 *ERROR* [Adobe Granite Offloading: Default Transporter] org.apache.jackrabbit.vault.fs.io.Importer Error while committing changes. Aborting.

13.06.2017 11:42:45.042 *ERROR* [Adobe Granite Offloading: Default Transporter] org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage Error during install.

...

13.06.2017 11:42:45.042 *ERROR* [Adobe Granite Offloading: Default Transporter] com.adobe.granite.offloading.impl.transporter.OffloadingDefaultTransporter javax.jcr.AccessDeniedException: OakAccess0000: Access denied

org.apache.jackrabbit.vault.packaging.PackageException: javax.jcr.AccessDeniedException: OakAccess0000: Access denied

        at org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:239)

        at org.apache.jackrabbit.vault.packaging.impl.JcrPackageImpl.extract(JcrPackageImpl.java:423)

        at org.apache.jackrabbit.vault.packaging.impl.JcrPackageImpl.install(JcrPackageImpl.java:392)

        at com.adobe.granite.offloading.impl.transporter.OffloadingDefaultTransporter.installPackage(OffloadingDefaultTransporter.java:576)

        at com.adobe.granite.offloading.impl.transporter.OffloadingDefaultTransporter.processJobInput(OffloadingDefaultTransporter.java:306)

        at com.adobe.granite.offloading.impl.transporter.OffloadingDefaultTransporter.processEvent(OffloadingDefaultTransporter.java:390)

        at com.adobe.granite.offloading.impl.OffloadingProcessor.run(OffloadingProcessor.java:256)

        at java.lang.Thread.run(Thread.java:745)

Caused by: javax.jcr.AccessDeniedException: OakAccess0000: Access denied

[#2]

I agree - it looks like a workflow permission issue:

javax.jcr.AccessDeniedException: OakAccess0000: Access denied

Is the user part of the  workflow-users group?

[#3]

I'm running as admin on the leader author instance. Would anything special need to happen for the workflow? admin is also the user for the replication agents.

[#4]

Just one question, do you have any email notification step in between which is being sent to a group. Then make sure that group has a user with a email id.

Not even sure if this is relevant to your problem. if not kindly ignore.

Thanks

[#5]

Hi,

In the offloading browser have you enabled the topic correctly?   If so go to the replication agent and verify the user it is using & password is correct, make sure agent is configured correctly.   Also look into replication log the issue is at offloading server not able to install.

Thanks,

[#6]

There is no email associated with this workflow. But thanks for the reply.

[#7]

From an offloading perspective, it's all setup correctly. I even had run about a dozen images using the DAM Update Asset workflow, and about 10 of them ran as expected (renditions created on worker instance, reverse replicated back to master). But for a few of them, I'm still seeing the Oak Access Denied error. So it's not consistent, which makes it worse, IMO.

[#8]

Hi,

I'm facing the same issue in 6.3 offloading workflow, could you please share how did you address the issue?

Thanks in advance.

[#9]

It ended up being a permissions issue. You need to open up the permissions for being able to write to the repository for offloading