deploy war files in a tomcat cluster

[Dallas Maverick, geändert vor 8 Jahren.]

I install apps/wars using the liferay web interface: control panel>apps/stores. Now I have a tomcat cluster, will I still be able to deploy apps using the web interface? If not, how do I download apps from the store and deploy it in my cluster? tomcat has a farmwardeployer tool, do I need it? If so, some instructions on how to configure and use it will be helpful.

Also, out of curious, why can't we set the tomcat deployment folder to a network share folder, so all nodes in the cluster will have access to the deployment folder? I thought Node copy the war file to a temp folder first anyway...

Has anyone deployed liferay in aws beanstalk? I read the blog, but I'm curious to see if it is a better/easier way than setting up a tomcat cluster. How easy it is to download and install new apps?

I'm using 6.2 ga 4, tomcat 7 on linux 64bit in AWS environment

Thank you.

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

You cannot use a shared deploy folder because one node would pick up the file and deploy it and the others would not be able to access it.

Liferay web interface will not push across to the other nodes.

You should drop the war (or for MarketPlace plugins download the .lpkg files from the MarketPlace and drop those instead) into each of the separate deploy directories.

Remember that Tomcat is not a full-fledged enterprise application server so it will not have all of the nice enterprise bells and whistles (and pricetag) that other app servers may have.

We use Tomcat because it is reliable and lightweight, not because of it's enterprise features. This is one case where you're going to have to stick with manual deployment.

[Dallas Maverick, geändert vor 8 Jahren.]

in tomcat 7 cluster configuration:

<Deployer className="org.apache.catalina.ha.deploy.FarmWarDeployer"
tempDir="/tmp/war-temp/"
deployDir="/tmp/war-deploy/"
watchDir="/tmp/war-listen/"
watchEnabled="false"/>

If I enable cluster and farmwardeployer, would it work? seems like the whole purpose of having this is to enable deploy one time to all nodes in a cluster instead of deploying the same stuff multiple times to each node in a cluster?

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

No, not really.

Liferay wars are thinned down wars as they do not include a complete set of jars in the WEB-INF/lib directory. When Liferay hot deployment occurs, it reads WEB-INF/liferay-plugin-package.properties to find dependent portal jars and adds those to the WEB-INF/lib directory. It also injects a servlet into WEB-INF/web.xml and may actually make other changes.

This process works for both your own custom plugins as well as plugins installed from the Liferay marketplace.

The FarmWarDeployer only works for complete wars, not the thinned down Liferay wars so deployment using the FarmWarDeployer will ultimately fail.

For your custom plugins there is a special build mode called "direct-deploy" that will build a complete war that would be compatible with FarmWarDeployer, but this path will not work for your MarketPlace plugins, you'd still be using manual deploy.

[Dallas Maverick, geändert vor 8 Jahren.]

good stuff. In that case, what's the benefit of creating tomcat clustering at all then? session replication is the only one comes to mind...If I don't care about user losing the session if application server crashes, what else a tomcat cluster would get me?

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

• Distributed load across multiple instances
• application availability/failover (if one instance goes down, other can remain up servicing requests)
• outage-safe cluster updates - When you deploy to tomcat you really should restart the instance to ensure the server comes up in a clean state and avoids the dreaded permgen error and other memory leaks. Using a cluster, you can take one node at a time out of the cluster, complete the deployment, restart and then put back into the cluster.
• increased capacity/throughput (since an instance will have an upper limit on max connections it can handle at one time before blocking).

Note that none of these have to do with session replication (which personally I suggest not using).

Good enough or you need more?

[Dallas Maverick, geändert vor 8 Jahren.]

Thank you. I think I need to confirm a point, liferay clustering does not really require tomcat/application server clustering, correct? The points you mentioned below applies to a liferay clustering environment with a load balancer in the front. Most benefits come from the usage of load balancer. I'm going to follow the liferay cluster guide to implement liferay clustering, however, I'm not planning on implement tomcat clustering, which requires work in the server.xml.

[Hitesh Baid, geändert vor 7 Jahren.]

First of all sorry for replying on this post.
As I couldn't see where to ask questions I am using this reply thread(help me with that if possible)
My question is where is the exploded war in liferay7. In earlier versions I could see in webapps folder of tomcat.
It was convenient to replace jsp pages.
Now I cannot see the exploded war. It is only available in osgi war module.
Please let me know where is the exploded app in liferay 7.

[Olaf Kock, geändert vor 7 Jahren.]

Hitesh Baid:

First of all sorry for replying on this post.

You can post a new thread in a matching subcategory of this message board. More important, you should avoid to crosspost or at least link them. I've answered on stackoverflow. Please let everybody know if you've crossposted elsewhere, to avoid more duplicate work.

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

Hitesh Baid:

My question is where is the exploded war in liferay7. In earlier versions I could see in webapps folder of tomcat.
It was convenient to replace jsp pages.

That was never the right way to change Liferay. Having done things the wrong way before, you're now stuck having to do things the right way.

If you had originally created a JSP hook, you would now just migrate to an OSGi fragment and it would have been a relatively easy migration.

But writing the JSP files directly? That was definitely in the "worst practice" category.

[Hitesh Baid, geändert vor 7 Jahren.]

It was convenient in development and for old portlets which has lots of jsp's.
Anyways migrating to OSGI is a good option but can't do that for all the old applications.
Will do it for new apps for sure.
Thanks.

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

Hitesh Baid:

It was convenient in development and for old portlets which has lots of jsp's.

It wasn't "convenient", it was lazy and it was and is bad practice and there is simply no excuse for it.

I know this will sound harsh, and honestly it is meant to. If any other developer happens upon this thread and starts to think it is okay to just edit JSP files inline, we need for them to know and understand this is not supported and it is absolutely discouraged.