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
Views
Replies
Total Likes
I agree - it looks like a workflow permission issue:
javax.jcr.AccessDeniedException: OakAccess0000: Access denied
Is the user part of the workflow-users group?
Views
Replies
Total Likes
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.
Views
Replies
Total Likes
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
Views
Replies
Total Likes
There is no email associated with this workflow. But thanks for the reply.
Views
Replies
Total Likes
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,
Views
Replies
Total Likes
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.
Views
Replies
Total Likes
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.
Views
Replies
Total Likes
It ended up being a permissions issue. You need to open up the permissions for being able to write to the repository for offloading
Views
Likes
Replies
Views
Likes
Replies