AEM 6.1 Social Communities | Shadow nodes | Community
Skip to main content
Naveen_AEM_dev
Level 4
February 26, 2016
Solved

AEM 6.1 Social Communities | Shadow nodes

  • February 26, 2016
  • 8 replies
  • 2686 views

Can someone please tell me if the shadow nodes that are created (to apply ACL's) in the JCR for a social resource are specific to a particular installation? 

https://docs.adobe.com/docs/en/aem/6-1/develop/communities/scf/srp.html

If the shadow nodes are only applicable for the current publish instance where they are created, then in a publish farm implementation the shadow nodes that are created in each publisher need to be synced with all the publish instances.

Is my understanding correct?

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by JK_Kendall

The default behavior is to set up shadow nodes on a publish instance whenever the relevant subtree is referenced for a read or write.

Scenario : using MSRP with a TarMK publish farm.  

When a member posts UGC on pub1, shadow nodes are created in JCR on pub1.

The first time the UGC is read on pub2, if nothing is set up, the default behavior is to create the shadow nodes.

If you want other than the default behavior, you set it up on author instance and roll it forward, which is typically a manual CRXDE process.

Does this help?

- JK

8 replies

Jitendra_S_Toma
Level 10
February 26, 2016

Yes. That's correct. nodes which are created in different publish instances need to be synced.But, in AEM 6.1, There is no clustering supported with the TAR MK. In order to make every publisher synced, use MongoDB. 

---

Jitendra

Naveen_AEM_dev
Level 4
February 26, 2016

There is no MongoMK publish instance deployment recommended by Adobe and I think for this use case it may be an overkill.

Wouldn't reverse replicating the UGC ACL nodes back to author and then forward replicating them to the publishers be easier. This can be managed through an OSGI scheduler.

Thoughts anyone?

JK_Kendall
Level 9
February 26, 2016

If you have licensed and are using AEM Communities, then you don't need to do anything.

The information about the shadow nodes is provided to developers who used to look there for UGC in AEM 6.0.  While the nodes are still there for the purpose mentioned, the UGC is now in a common store (ASRP or MSRP).  In AEM 6.1, JSRP is not a common store.

If that is not helpful, please be more specific in regards to what you are trying to do.

- JK

Adobe Employee
February 28, 2016

It is recommended that you use MSRP with mongodb for storing UGC. MongoMK is not yet recommended for use on publish nodes for UGC.

Naveen_AEM_dev
Level 4
February 28, 2016

Just to be clear, I understand the the UGC itself is going to be stored in the central UGC store (which in my case would be MSRP) and not in the JCR.

I'm actually referring to the ACL nodes (shadow nodes) that will be created in the JCR in the /content/usergenerated/content irrespective of which type of SRP is being used.

My question is whether these shadow are specific to each publish instance and if there is any sort of implementation that is available OOTB to ensure that these shadow ACL nodes are in sync across different publish instances in a multi publish deployment topology.

Naveen_AEM_dev
Level 4
February 29, 2016

Hope my previous post clarified things.

Does anyone have any idea about these shadow nodes?

JK_Kendall
JK_KendallAccepted solution
Level 9
February 29, 2016

The default behavior is to set up shadow nodes on a publish instance whenever the relevant subtree is referenced for a read or write.

Scenario : using MSRP with a TarMK publish farm.  

When a member posts UGC on pub1, shadow nodes are created in JCR on pub1.

The first time the UGC is read on pub2, if nothing is set up, the default behavior is to create the shadow nodes.

If you want other than the default behavior, you set it up on author instance and roll it forward, which is typically a manual CRXDE process.

Does this help?

- JK

Naveen_AEM_dev
Level 4
March 1, 2016

Thanks Kendall that's precisely what I was looking for!