Liferay with multiple tenancy for business reasons

Liferay instances - properties etc.?

up vote down votefavorit

We are looking into Liferay with multiple tenancy for business reasons for  disparate audiences. I have some questions around this. I'd appreciate some insight on the following questions: From the question/post liferay and more instances, it seems like there are constraints  around Portal properties where some are global versus instance specific. Is there any list or insight on what properties are global Liferay scoped versus instance specific? From the post on Liferay portal instances, it seems like > The preferred way to configure  a portal instance is through the Control Panel. From talking to various people, it also seems like sharding with portal instances  has some performance known issues. It is recommended to turn off sharding  when using instances.  Does anyone know which Liferay properties to use to turn the sharding off or  if sharding is  off in Liferay 6.2 by default (if so, which properties to review to confirm that  sharding is off)? Is there a limit on how many instances we can use? We may be using atleast 3-4  instances  to start with. Any know known issues with number of instances? Thanks a lot for any information on this. Ans-Here is what I found from another source in case it helps someone: One of the first and most important things to remember about portal properties is  that they are always overridden by any settings made in the Liferay Control Panel.  The reason why is that any configuration done in the Control Panel is saved directly to  the database and the configuration set in the database is always read after the portal properties have been imported, thus overriding them. Once a configuration has been  done in the Control Panel, that setting can never again be modified or altered by a  portal property. This does make one wonder why there are two places to make setting configuration  changes and why the Control Panel trumps the portal properties file every time.  The reason why this is done is directly related to your first question regarding  global and scoped settings. The portal-ext.properties file is often used to set configuration for that physical  bundle of Liferay; every instance of Liferay on that physical bundle will inherit those  settings, but those settings will not be automatically inherited by any other Liferay  node or bundle of the same instance. The Control Panel is often used to set configuration for that instance of the Liferay  Portal; every node connecting to that instance will inherit these settings and override  any values set in the portal properties, but those settings will only be inherited by  other nodes connecting to the same instance. In other words... - The Control Panel settings are used for the Liferay instance. -  The portal properties settings are used for the Liferay bundle - The Control Panel  settings will always override the portal properties settings This does allow some control on how to set default properties for the bundle or node,  as well as to save configuration for the entire instance. As an example, you will want  to use the portal properties to configure cluster settings, the database connection  settings, document library connections, as well as other performance/system settings. However, you will also be given a choice of where to configure settings such as the  mail server. If you set it in the portal properties, every instance of Liferay on that node  will have those settings automatically, which may not be desirable depending your  goals. If you set it in the Control Panel, then ever Liferay node connecting to that  instance will get those settings automatically, but the portal properties will not modify  those settings again. Now, there is a way to create an instance specific portal properties file that will have  values only read by that instance of Liferay. Please note that this does complicate  things even further and it may not be desirable for your goals. The following property  and its definition explain how to accomplish this: # # Each portal instance can have its own overriden property file following # the convention portal-companyWebId.properties. To enable this feature, set # the "company-id-properties" system property to true. # # To enable: # # java ... -Dcompany-id-properties=true # # The read order will now be: portal.properties, then portal-ext.properties, # and then portal-liferay.com.properties. # # Note that not all properties can have different values per company. This # functionality is only available for legacy reasons. The preferred way to # configure a portal instance is through the Control Panel. # include-and-override=portal-${easyconf:companyId}.properties include-and-override=${liferay.home}/portal-${easyconf:companyId}.properties The choice is yours on where you want to configure your portal settings and with the  above knowledge I believe you will be able to make the best decision for your goals. In regards to sharding, sharding is disabled by default and has to be manually  configured via portal properties as well as via the database itself. This is a slightly  older wiki article on how to enable database sharding support in Liferay, https://www.liferay.com/community/wiki/-/wiki/Main/Database+Sharding.  For reference, here are some of the properties that need to altered: ## ## Sharded  Databases ## # # Set the database that is to be used for the default company and globally # used tables in a sharded environment. # shard.default.name=default # # Specify an algorithm for selecting a new shard on portal instance # creation. Use ManualShardSelector for shard selection via the web # interface. # shard.selector=com.liferay.portal.dao.shard.RoundRobinShardSelector #shard.selector=com.liferay.portal.dao.shard.ManualShardSelector ## ## Spring ## # # Input a list of comma delimited Spring configurations. These will be # loaded after the bean definitions specified in the contextConfigLocation # parameter in web.xml. # # Note that there is a special case for hibernate-spring.xml and # jpa-spring.xml. Even though both files are specified, only one will # actually load at runtime based on the property "persistence.provider". # spring.configs=\ META-INF/base-spring.xml,\ \ META-INF/hibernate-spring.xml,\ META-INF/infrastructure-spring.xml,\ META-INF/management-spring.xml,\ \ META-INF/util-spring.xml,\ \ META-INF/jpa-spring.xml,\ \ META-INF/executor-spring.xml,\ \ META-INF/audit-spring.xml,\ META-INF/cluster-spring.xml,\ META-INF/editor-spring.xml,\ META-INF/jcr-spring.xml,\ META-INF/ldap-spring.xml,\ META-INF/messaging-core-spring.xml,\ META-INF/messaging-misc-spring.xml,\ META-INF/mobile-device-spring.xml,\ META-INF/notifications-spring.xml,\ META-INF/poller-spring.xml,\ META-INF/rules-spring.xml,\ META-INF/scheduler-spring.xml,\ META-INF/search-spring.xml,\ META-INF/workflow-spring.xml,\ \ META-INF/counter-spring.xml,\ META-INF/mail-spring.xml,\ META-INF/portal-spring.xml,\ META-INF/portlet-container-spring.xml,\ META-INF/staging-spring.xml,\ META-INF/virtual-layouts-spring.xml,\ \ META-INF/monitoring-spring.xml,\ \ #META-INF/dynamic-data-source-spring.xml,\ #META-INF/shard-data-source-spring.xml,\ #META-INF/memcached-spring.xml,\ \ classpath*:META-INF/ext-spring.xml In regards to the number of instances allowed, there are no hard limits but please  note that each instance will be competing for the same amount of resources and  performance degradation will likely occur. This does make performance tuning  even more important than normal to avoid undesirable performance. As an FYI - from testing I found that the following properties to configure the  Announcement portlet template etc. is only possible via the portal-ext.properties  file and not via the control panel. So if the values of the properties are different  between instances than you will need a company specific properties file. Hope this helps!                                                  or A Note of Liferay Portal Instances Liferay provides us facility to run more than one portal instance on a single server. Liferay comes with one  inbuilt portal instance, which is names 'Liferay' and its web id is 'liferay.com', however it can be  modified with following properties in portal-ext.properties file: 1 2 company.default.name=Liferay company.default.web.id=liferay.com Note: There are several other properties regarding portal instances present in portal.properties as well  which can be referred in Liferay Portal SRC. If we login as administrator (generally test@liferay.com), and go to control panel we can see list of  all available portal instances in 'Portal Instances' section inside 'Server' category. Here we will see a table  with atlest one entry (inbuilt one) , lets know what the column of this table depicts: Instance ID: It’s a numeric Id, generated by code automatically at the time of Instance creation.  Internally this Instance ID is referred as 'companyid' in the database table. We can see all available  instances in database table 'company'. Web ID: It’s a user-generated ID for the instance. It can be anything relevant but a general convention is to use the domain name. Virtual Host: Domain name which is to be configured in the network kept here. This domain name is referred when users are directed to our Liferay server, and the same enables Liferay to resolve request for proper portal instance. Mail Domain: The domain name to be used as mail host for this instance kept here. Liferay will use this to send email notifications from the portal, and the same is used for creating the default test user as test@mail-domain.com# of Users: Depicts current number of users on particular portal instance. Max # of Users: Depicts total number of users allowed on particular portal instance. Active: Depicts if the portal instance active or not (Yes / No). Enough of theory, lets experience it. Startup the server and replicate the following steps: Login as administrator. (test@liferay.com/test will work) Navigate to Manage → Control Panel → Portal Instances section in 'Server' category. By default only one portal instance will be listed. To add new, click on add button fill up  the form fields. Say you have created 'newinstance.com'. Assuming that you are working on your local system, you have to edit the host file  (%SYSTEMROOT%\ System32\ drivers\ etc\ hosts). Add the following in the file: 1 127.0.0.1 newinstance.com If you are in network then you can map the entry with the IP address of the server on which  Liferay is running and try. Start the browser (restart in case already running) and put 'newinstance.com:<PORT>' in  address bar. What you see now in the new portal instance. You can login as test@<domainname>, (test@newinstance.com in out case). This is the  admin user of the instance. As an administrator you cannot see the 'Server' category in  Control Panel, which means new instance can be created only from main portal instance. If we dig in further, we will come to know that we can have different properties file for each portal  instances. To enable this feature, set the "company-id-properties" system property to true.  The read order will now be: portal.properties, then portal-ext.properties, and then portal-liferay.com. properties. Note that not all properties can have different values per company. This functionality is  only available for legacy reasons. The preferred way to configure a portal instance is through the  Control Panel. Handling Portal Instances in Custom Code: In real life scenario, we may need to process data differently for each Portal Instance in our custom  code. So have a look on small code snippet: 1 2 3 4 5 if(themeDisplay.getCompany().getWebId().equalsIgnoreCase(PropsUtil .get("company.default.web.id "))){  // do something }else if(themeDisplay.getCompany().getWebId().equalsIgnoreCase("<Your  custom portal instance web id>"))){  // do something else } Hope you enjoyed the reading.