4

I am trying to Implement clustering in liferay 6.2 using below Link

https://www.liferay.com/en_GB/documentation/liferay-portal/6.2/user-guide/-/ai/liferay-clustering-liferay-portal-6-2-user-guide-20-en

I had put below properties in both liferay server's portal-ext.properties and Pointing both Liferay server to same Database.

cluster.link.enabled=true

cluster.link.autodetect.address=localhost:3306

lucene.replicate.write=true

Now I added one portlet to a page from first Liferay instance and accessing the same page from Second Liferay instance(Using same userID) i am getting error message stating "Invalid authentication Token".It seems to be session replication problem in Cluster but not able to figure out how to resolve this.

Looking for help to figure out whats going wrong.

Thanks in Advance.

Liferay Beginner
  • 89
  • 3
  • 7

2 Answers2

7

You have a severe problem in your configuration, despite the already accepted answer (which I mostly disagree with).

You'll have to set up proper clustering on Liferay. In order for Liferay to find "the other" node, it uses Multicast (by default). And if you have multiple network cards but want/need one specific network card to be used for detecting the other node, you'll give the cluster.link.autodetect.address. Liferay will use this to see which network adapter is used (by your OS) to connect to that address and then use the resulting network adapter. If you have only one adapter, the default value www.google.com:80 is good. If you set this to localhost, Liferay will try to communicate with your other node(s) on localhost, thus only succeed if you have two Liferay processes running on the same machine - otherwise you'll have no cache synchronization at all.

As of the principles of Liferay Clustering, I'd recommend to go to the User's Guide and specifically not do session replication (e.g. the tomcat-configured session replication). 95% of users don't need it, it adds significant overhead to processing, eating the performance benefits of the second server. And while you're at it: Check some common pitfalls when clustering Liferay (but beware: There are more)

Edit: To answer your "Invalid Authentication Token" question: My advice is to implement sticky sessions - e.g. balance the session creation to a certain machine, then stick to it. The Authentication token is used for mitigating CSRF attacks. Not having it implies that your session replication doesn't work correctly. As I've laid out above, I don't recommend enabling session replication, thus sticky sessions are your best option IMHO.

Olaf Kock
  • 46,930
  • 8
  • 59
  • 90
  • Thanks for clarification.I have two Liferay process running on my localhost on different ports thats the reason i put 8080.i went throught these link before but not able to figure it out how to resolve this "Invalid authentication Token" error – Liferay Beginner Jul 12 '14 at 19:26
  • 1
    What's the purpose of clustering two instances on the same host? You'll neither get higher availability, nor better load covered. I can imagine only a test installation. However, especially with a test installation, there's no need to explicitly set the cluster.link.autodetect.address - if you're running on localhost I expect that you'll find the local installation on whatever network adapter Liferay is looking for it. If you ever change this to different machines without changing this setting, the two nodes won't find each other. – Olaf Kock Jul 13 '14 at 08:14
  • Sorry for delay in reply.yes i am testing this in my local machine.Could you please suggest me how to get rid of "Invalid authentication Token" error.Thanks in Advance – Liferay Beginner Jul 16 '14 at 20:20
3

Session clustering is implemented in Application Server, not in Liferay. You have either configure it manually on your AS, or enable sticky sessions on your Load Balancer.

There is a lot of articles about how to do it in Tomcat:

Te second article is very heavy, as far as I remember to run the basic session replication, all you need to do is to enable SimpleTcpCluster in tomcat configuration and add <distributable /> to web.xmls of all your web applications.

Krzysztof Gołębiowski
  • 619
  • 4
  • 10
  • well "session replication" is done in the application server, but proper "clustering" in Liferay involves quite some configuration on Liferay's side, thus I mostly disagree. In fact, most times the session replication is a bad idea - it's just a very expensive (performance-wise) quickfix, but should only be applied last (after successful proper Liferay clustering), or preferably never. – Olaf Kock Jul 11 '14 at 21:27
  • Hello Olaf, Thanks for your clarification. You are obviously right, there are much more things to be done to cluster Liferay properly (as it is said in the documentation that both the question author and you rely on). But could you please clarify how would you realize the clustering without properly dealing with sessions? I personally know two solutions to this problem. First is Sticky Session but... it does not give you a 100% failover (if the node is down, all it's sessions are lost), and what's more important it does not distribute the traffic equally across all nodes. – Krzysztof Gołębiowski Jul 12 '14 at 00:03
  • The second is previously mentioned session replication which doesn't have these both defects but adds some additional overhead to processing. So are there any other solutions that you know? – Krzysztof Gołębiowski Jul 12 '14 at 00:04
  • 1
    @KrzysztofGołębiowski sticky sessions solve most of the problems (all but unplanned downtime of one server). However, it is horrendously expensive. If you're clustering for load reasons, SR is a bad idea . You're better off with either stateless applications, client side state (e.g. cookies) or pushing state down to the business layer. Combine that with SSO and you have your failover. With enough traffic, statistics/probability help to level the load fairly evenly between the nodes. You're balancing on first contact, based on whatever you configure (traffic, requests, busyness, other) – Olaf Kock Jul 12 '14 at 20:33
  • @OlafKock Does it mean that I should run each Liferay instance on different subdomain (like www1, www2, etc.), implement crossdomain SSO and then load balance users at first-contact by redirecting each to one of the subdomains? Do I get it right? Is it a recommended way to implement LB within Liferay's deployment teams? I'm asking because it's different approach to LB than I know (and most of my Liferay's friends) and maybe we were doing it wrong. Do you have any statistics/experience about the performance profits caused by eradicating session replication? – Krzysztof Gołębiowski Jul 12 '14 at 22:16
  • @KrzysztofGołębiowski with the loadbalancer covering the virtual host www, there's no need for different subdomains. It will cover the sticky session until the original server isn't available anymore, then balance to the remaining appserver(s). The appserver will then redirect to the SSO, which will transparently redirect back (with authentication). I don't have the actual numbers, just the very strict recommendations from those that have them. – Olaf Kock Jul 13 '14 at 08:11
  • OK, I looked at a few of your Case Studies (https://www.liferay.com/products/liferay-portal/stories) and tried to figure out how it is done. I checked JSESSIONID and found out that in most cases the node name is appended. Example suffixes are as follows: *.lr*, *.blinky*, *.balancer2*, *.cms101* and finally *.node-lrdcom-vm-52* at liferay.com. I suspect that you use Sticky Sessions instead of Session Replication and I begin to understand (based on your experience) that stateless apps with SS is a good practice and I should use it more often in my projects. – Krzysztof Gołębiowski Jul 14 '14 at 09:16
  • But my doubts concern that part with SSO - I remember that logging on liferay.com depends on standard Liferay's login portlet (no SSO involved) so in this case we possibly don't have the session failover. So what do I need to implement your architecture - Is it achievable with standard Open Source components like Apache as an LB, CAS as an SSO and Liferay Community but just requires more advanced configuration, or do I need some enterprise tools like for example F5 hardware Load Balancers, Websphere etc. – Krzysztof Gołębiowski Jul 14 '14 at 09:17
  • SSO (and stateless apps/state in business layer) is only required if you *absolutely* want to make sure that no user ever looses a single bit of data when a node accidentally fails. For scheduled downtime you can easily utilize your loadbalancer to not direct new sessions to the appserver you want to shut down, then wait for the active sessions to trickle down to (close to) zero. But even if with session replication turned on, I'd still opt for sticky sessions, assuming that it at least doesn't require deserializing of the session state on each request. (to be measured/checked) – Olaf Kock Jul 18 '14 at 07:29
  • @OlafKock thanks for your suggestions, I corrected my approach to clustering a bit. I think I will leave all my doubts to the next DevCon (maybe this year I will manage to get at the unconference) :) – Krzysztof Gołębiowski Jul 18 '14 at 08:23
  • Great, looking forward to see you. Registration opens soon (expected next week) and Unconference will be limited (due to available space), so register early. For DevCon itself, registration will be virtually unlimited. – Olaf Kock Jul 18 '14 at 08:29