Running two instances of liferay

[Mitko Zafirovski, geändert vor 11 Jahren.]

I have a problem because i am running two instance of liferay connected two the same data base. One is the admin portal and one is the front end. The problem occurs when i use some of liferays custom features on one server because it is not updated on the other. For example from the back end the admin disables a users account. In the same time if the user is logged in or recently loged in the change has not occured. Same thing happens with adding or removing a role to a user or adjusting permission to pages. I was wondering is there any way i can fore liferay to check this things constantly or any other solution of how to prompt the other server to get the new changes from the database?

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

You don't have two instances, you have a partially implemented cluster. You're missing the clustering of the indices and repository.

Since you're not clustering those, each has their own index of user information and, unless you manually trigger the index update in the 2nd instance, it will not get updated. Liferay will often times go to the index rather than hitting the database.

This is exactly the scenario you're hitting.

The question is, why two instances on the same database? Your admins will have special privileges on the standard instance, permissions the users don't have.

The reality is that the systems are actually mirrors, and not separate instances. If you drop portlet A on a page in the admin instance, it is mirrored to the user instance. If you deploy portlets only to the admin instance and place them on a page, the user instance will show 'portlet has been undeployed' boxes on them if the admin logs into the user instance. Documents and images that you load in the admin instance wouldn't be available in the user instance and would show up as broken links.

It's really just a poor implementation, and your boss should probably let you go...

[Mitko Zafirovski, geändert vor 11 Jahren.]

The actualy architectural design and have 2 instaces is not my doing, but at this point of time i have to deal with it. I know its not the correct way but this is how it is done atm. Its not a mirror since the contain different portlets and the pages that are on one place are not on the other. But this is was not my question. I know this is a bad scenario but at this point i am trying to salvage what is left of it, and that is why i asked if someone can tell me how to either force liferay to ignore thouse index for permiision( which is a very bad scenario because its not good to querry the data base constantly) or how i can pass the updates for those indexes from one server to another

[Hitoshi Ozawa, geändert vor 11 Jahren.]

Its not a mirror since the contain different portlets and the pages that are on one place are not on the other.

This implies that even is liferay instances are using the same database server, they are using a different database schema. That is, you have 2 different instances of liferay running which are not setup to interoperate. Because they are 2 distinct liferay instances, you will not be able to share data between them out of the box.

If you want to share user and organization between these 2 liferay instances, you'll need to setup to use LDAP and import/export users and organizations.

[Milen Dyankov, geändert vor 11 Jahren.]

Unlike David, I'm not going to judge you or your setup not knowing the details. I'm not sure what exactly you mean by "two instance of liferay connected two the same data base". Is it the same database schema (manning the two instances are using the exact same tables) or there are 2 different schemes in the same database?

If it's the first case then, technically speaking, David is right - you have partly configured cluster. You'll have to go ahead and cluster the cache and index as well. Depending on which Liferay version you use you may also need to cluster JCR or whatever you DL and/or IG storage is. This will effectively result in a fully functional cluster - meaning both instances will have exactly the same data (configuration, pages, content, ....). Then you'll have to add/configure a proxy layer (apache, nginix, HAProxy, ...) to direct your end-users to the first instance and your administrators to the second one (eventually administrators can access second instance directly). This way you can create rules on the proxy layer to disable/forbid access to sensitive URLs for end-users. I've seen this kind of setup enforced by systems administrators in many corporations and since it seems they consider it more secure not to relay on application's permissions where they don't have to.

In the second case (different database schemes) then there are two independent portals. It may at first seem that they can by synchronized on database level (replication, db links, triggers, ... ) but this is not the case as Liferay uses heavily caches and indexes to avoid unnecessary db calls. Depending on what you need to sync, you may try to investigate Liferay's remote staging or implement a custom synchronization via web services.

[Mitko Zafirovski, geändert vor 11 Jahren.]

Yes its basically the first case both liferay's are connect to the same schema. Not sure what was the intitial reason to do this but i know at a certain point of time this was needed in order to be able to hook a same liferay class on different ways based on which server is used. Thanks Milen Dyankov this seems like a viable solution since we have filters implemented for accessible pages on a given url. I will propose this solution since i think it will solve the problems

[Hitoshi Ozawa, geändert vor 11 Jahren.]

As Milen wrote too, you'll have to configure your 2 liferay instances to cluster if you're sharing the same database schema. Liferay uses a common primary id numbering scheme in database tables. If you don't cluster these, you may end up with duplicate ids if there are contents entered in both instances.

The most common reason to clustering liferay is to increase availability and to increase capable load.