Configure ehcache in cluster Liferay DXP

[Patricia Hevia, geändert vor 6 Jahren.]

Hello,

I am working with Liferay DXP and I want to configure a cluster with two nodes.

I have configured in the portal-ex.properties in each node the jdbc and cluster link:

jdbc.default.driverClassName=oracle.jdbc.OracleDriver
jdbc.default.url=jdbc:oracle:thin:@myconexion:1521:XE
jdbc.default.username=myuser
jdbc.default.password=mypassword

cluster.link.enabled=true

Also, the document library and elasticsearch are the same for the two nodes.

In others Liferay versions, to configure the ehcache I used the Liferay Ehcache Cluster plugin but for Liferay DXP this plugin does not exist.

How should I configure ehcache for Liferay DXP?.

Thank you very much!.

Regards,
Patricia

[David H Nebinger, geändert vor 6 Jahren.]

Patricia Hevia:

In others Liferay versions, to configure the ehcache I used the Liferay Ehcache Cluster plugin but for Liferay DXP this plugin does not exist.

It is already integrated into DXP so you should be good to go.









Come meet me at the 2017 LSNA!

[Andrew Jardine, geändert vor 6 Jahren.]

That plugin, as far as I know was to provide a performance improvement over the stock implementation. As David said, it's in the box so you should be good. If it is not working then I would first start by making sure that multicast is enabled for your network interfaces and routes and that the default ports are allowing traffic. I also came across a case recently where one of the nodes was on a separate subnet which meant we have to adjust one of the configurations that came out of the box slightly for ehcache to replicate. It was an obscure setting and simple failed silently so it was a bugger to track down. If that is (possibly) your issue then let me know and I'll dig up the solution.

[David H Nebinger, geändert vor 6 Jahren.]

Eeek, I just came from the opposite - client had all environments on the same subnet and was using multicast and was wondering why schedulers weren't running, etc. Switching over to unicast got their nodes joining the right environment cluster and all was working fine.

It is never the case where you just blindly pick multicast in your production configuration and just assume things are going to work. You always want to make an educated determination about your clustering choice.









Come meet me at the 2017 LSNA!

[Andrew Jardine, geändert vor 6 Jahren.]

Fair enough -- but unicast is not without it's drawbacks as well. In the case I am referring to the client did in the end configure the settings such that the only servers that were listening for updates on the ports were the servers in the Liferay cluster so there was no worry about a bunch of irrelevant chatter coming across the lines. But your point is valid -- rather than just licking your finger and sticking it in the air, probably best to look at all the options and figure out which one is the best fit.

Sadly, I think most of what is going on out there consists of a lot of people holding up the number one

[David H Nebinger, geändert vor 6 Jahren.]

Personally, I always prefer unicast.

Yes, it is totally manual to set up. Yes, all nodes need to be updated when a new node is added.

But me? I hate ambiguity. I hate wondering what cluster a node ends up joining. I hate having to worry about whether the VM i'm on supports broadcast or not....

I always feel better spelling it all out and controlling what happens. But that's just me.








Come meet me at the 2017 LSNA!

[Andrew Jardine, geändert vor 6 Jahren.]

I think I know what the difference is. I'm lazy

.. but I think perhaps we have now hijacked this thread. Let's see if the original poster comes back after this rail roading ;)

[Patricia Hevia, geändert vor 6 Jahren.]

Thank you very much David and Andrew!!!

There was a problem with multicast in the network.

Thanks!