Fetching Node Property during replication

Exactly..

but in third step during the replication i need the property to be available in my code.

it isnt published yet but it is in the process.. at that time the need to fetch this property.

is it possible?

Just wondering, why not use replication preprocessor?
Do you see any issue?

Hi Manish,

ok, understood. So let's rephrase it into:

1) On author, you add a property "prop" to node "/home/mysite/en/jcr:content"

2) On author, this page is replicated (either through code, or triggered by an user)

3) On any publish, during replication, custom code needs to read the property "prop" on /home/mysite/en/jcr:content

So, how are you hooking into this process, that you can say "during the replication"? What API do you use (or want to use) to achieve this? And if you post your complete usecase, we might come up with a better and simpler solution.

Jörg

Hi edubey,

even if i preprocess it, will i be able to get property in publish instance from author?

i havent used it before. Correct me if i am wrong, doesnt it just check everything before replication?

but not actually replication.

Hi Jorg,

i have created an agent which reads replication and then triggers akamai cache invalidate.

i am adding a check rule for author to decide if they need this content to be invalidated at akamai.

hence i am adding a property at page level and thinking to read that property during replication on publish and validate the akamai cache request.

Regards,

Manish

Hi Manish,

what do you mean with "which reads replication and then triggers akamai cache invalidation"? Have you created your own dedicated endpoint (similar to /bin/receive, but different), which reads the changed page from the headers? Then I understand the problems you are facing.

What about creating a new replication agent on publish, which has the trigger "on receive" set? This is only triggered when an incoming replication has already been processed. When you invalidate through a HTTP call, you can either build a custom transport handler (if you want to create the connection on your own) or just a custom content builder (if you need to build a custom payload format), but you don't need to implement the complete logic on your own.

Jörg

I have done exactly what you have written in second paragraph.

i have created my own contentBuilder and transportHandler.

i have created an agent on publish to process this akamai invalidate on RECEIVE.

but this invalidation process will be triggered as soon as it receives the replication, dont you think it will be too late for my code in publish to read this check property from author?

i tried this way but i was not able to read this check property during first replication.

OK, now I understand.

OnReceive agents are triggered by Sling Events ("com/adobe/granite/replication"), and for every replication a new session is being opened. Technically it should see all changes of sessions which happened before the creation of this session. And I think that the Sling Event is being sent after the replication data has been persisted, the session available to your custom transporthandler and content builder should be able to see the data written by the incoming replication.

Do your contentbuilder and transport handler use a new session for their work? Potentially long-running?

Jörg

Hi Jorg,

Yes, I am using a new session in order to create a ReplicationContent only in ContentBuilder.

Just passing the created content to transport handler and making a call to akamai.

Regards,

Manish

That's really strange, because then the session save of the replication receiver thread and the creation of your session must overlap.

Maybe you can add debug statemnets to your code, and also enable DEBUG logging on repo writes (see [1] how to do it); then you can compare timestamps of the save and the time of the creation of your session.

[1] What is writing to my Oak repository? | Things on a content management system