You may not be aware yet, but there’s a new liferay feature called Portlet Sandboxing. You can
find the “Portlet Sandbox EE” plugin in the Liferay Marketplace. This feature was designed to isolate portlets applications from liferay and other portlets. The theory is that a poorly written portlet should not take down the entire site.
This is done by running a separate JVM isolating those portlet applications. The additional JVM is running an embedded tomcat server with liferay (ROOT.war) and only those sandboxed portlet apps. Due to the nature of this setup, you can no longer use JNDI mapped datasources. You’ll need to use the c3p0 connection pool and configure them within your portal-ext.properties file. This will likely be an issue for some customers.
Once the “Portlet Sandbox EE” plugin is deployed, you’ll have access to a new “SPI Administration” control panel screen. This will allow you to declare one or more sandbox environments. For each environment, you’ll be asked to specify some basic Tomcat settings like worker threads, port, and JVM arguments. If desired, that’s where you can enable access to JConsole for your sandbox JVM. You will then define what portlet applications are going to be sandboxed.
The current feature only supports sandboxing portlet and web plugins. You can’t sandbox hooks. However, I did run some tests and your liferay service hooks will still fire if initiated through a sandboxed portlet. The sandbox portlet can still utilize all the same LocalServiceUtil objects.
You now have a Liferay Master Portal Process (MPP) and a Portlet Sandboxed Container (PSC) running within a separate JVM. This PSC process can only be started/stopped through the control panel. However, liferay will automatically shutdown/startup the PSC when you restart the MPP.
Here’s an interesting note. You can shutdown the PSC process and your sandboxed portlets will still run fine. Keep in mind that they are deployed in both environments. They will only run within the sandboxed environment if the PSC is running.
You’ll need to understand that this feature will only protect liferay from your sandbox portlets crashing the JVM. It won’t help much if the sandboxed portlet does something to crash your external dependencies such as your database, solr, etc. You still need to be careful when installing questionable portlet applications you find online.
Here’s some open questions I have not answered yet, possibly for a future blog. How well does this feature work in a clustered environment? As a simple example, will this work if I have 2 (or more) instances of liferay behind a load balancer? When I login to liferay and declare a “sandboxed” JVM, will it create one on each instance of liferay? I would also like to test how well does this feature work with a clustered EHCache configuration?
There are so many questions to answer on this feature. I think the concept is a great idea. My biggest concern would be around site performance. How much overhead does this feature come with? I guess we’ll need to do some more performance testing around feature.