JcrRunner using VM (instead of RMI)?

Experience Manager (PaaS/OnPrem)
1

Hi all,

We’d like to get rid of RMI within our Hippo project, but we’re using a custom JcrRunner which still depends on the RMI protocol. Is there any way to force the JcrRunner to use the “vm” protocol? Our purpose is to extract some JCR data every once in a while (currently using a JCR SQL query).

Thanks in advance!

Kind regards,
Robin.

2

Hi,

not as far as I am aware. It would have to run in the same VM for that to work. However, if you explain your use case a bit more we may be able to suggest alternatives. You could set up a rest service to get the data, you could make a specialized perspective, content exim tool…There are probably many ways of achieving the same.

3

Hi Robin,

JcrRunner is bound to RMI.
Could you perhaps migrate yours to Groovy Updater Script [1] instead?
You can possibly reuse your custom visitor if any in a groovy updater script, and you can schedule it to be executed too. [2]

Regards,

Woonsan

[1] https://www.onehippo.org/library/concepts/update/groovy-update-script-examples.html
[2] https://onehippo-forge.github.io/hippo-utilities/repository/updater-exec-sched-job.html

4

Thanks for your swift responses!

I’ll try to explain in a bit more detail what we’re trying to do.

During releases to PROD, our frontend machines are taken out of the load balancer and upgraded. During this period, form data will still be filled out and stored on the remaining front end machine. Before upgrading this last frontend machine, we’ll need to retrieve the form data that has been submitted in the meantime, so that it can be merged with the other form data.

Since the form data is stored on the front end servers, a REST service may not be the safest way to go about this. A groovy script could actually be a viable option.

5

Formdata is stored in the repository. You should only have one repository so I don’t see why you need to merge data. Unless you have separated your site/cms and have the frontend running in a dmz. In that case see:

6

I understand this may sound overly complicated, but for rollback purposes we do happen to have two different repositories during the upgrade. Simplifying our release process is always high on our agenda, but for the time being we’ll have to cope with this situation.

7

In that case I think we can help you:

IIUC you have what we call a blue/green deployment scenario. This module was made for this case

8

Interesting!
I’ll have a closer look.

Cheers,
Robin.