Hi Shawn,
only some aspects answered for now, inline:
On 25.03.2018 19:31, Shawn Heisey wrote:
On 3/25/2018 3:15 AM, Olaf Kock wrote:
* Liferay comes (optionally) bundled with Tomcat to ease
installation, however, the tomcat in there will be your own and is up
to you to upgrade. Yes, new versions of Liferay will come with new
versions of Tomcat, but new versions of Liferay won't be released
because a new version of Tomcat is available. Running on an old
Tomcat is your decision, not Liferay's. And the tomcat committers
have done a great job providing drop-in-backwards-compatible newer
versions. Of course, you'll need to validate, but the bundled version
is no excuse to not upgrade Tomcat
Thank you for your response!
I know that the Tomcat version is basically ours to use or replace.
Upgrading Tomcat may be perfectly safe for Liferay itself, but we
cannot be sure that it is completely safe for the applications we've
written using Liferay.
good - I just wanted to make sure that this is well known. Many people
are not aware of this fact, when everything comes neatly bundled
together - but indeed, it's nothing than a vanilla tomcat with an
application preinstalled (and a few lines of extra configuration - you
can see an easy diff when you download the same tomcat version in vanilla)
Many of our sites are still using Liferay 6.1. The customers on those
platforms are so risk-averse that they haven't allowed us to migrate
them to 6.2 yet. We want to get everything upgraded to the latest
Liferay version, but the upgrade from 6.1 to 6.2 was very
challenging. We expect an upgrade to 7.x to be more difficult.
The difficulty of an upgrade is typically directly proportional to the
level of customization (and the technique used for the customization).
But that's nothing for the tomcat list.
If somebody can give me evidence to assure me that upgrading Tomcat
and using configuration X will solve the problem, then I will pursue
that. I can't justify an upgrade because it MIGHT fix the problem.
Going to the latest Tomcat 7 release should be so straightforward that I
assume it's part of the debugging process you're in, just in order to
check if you're stuck with an issue there. With the positive side effect
that you get all fixes, even the ones that you didn't know you should have.
* Liferay's default configuration (as configured through the setup
wizard) configures the database with an internal connection, not
using an appserver-configured pool. Please confirm that you manually
configured Liferay for the appserver-provided pool.
We are using Liferay's configuration in portal-ext.properties for the
Liferay database. The pools configured in tomcat are used for our
application, not Liferay itself. The only complaint I have about
Liferay's pool is that it seems to use more connections than I think
should be necessary. But it IS re-using the pool (all connections are
idle less than one minute), so it's not on my radar at the moment.
The connections in the tomcat pools are NOT being re-used like I
expect them to.
Liferay can be configured with URL/user/password/driver, or with a JNDI
name - the later naturally referring to a container-provided pool. Both
configurations are in portal-ext.properties.
Can I configure additional pools in portal-ext.properties for our
application to use? If so, is that recommended? That will probably
require code changes, but if it solves our difficulties, I'm not
opposed to it. We already need to touch all of that code anyway to
adjust how we're closing JDBC resources. Maybe we should find a new
way to handle connection pooling.
I rather prefer to configure pools through the container. But yes, you
can configure pools in Liferay's configuration as well. Ctrl-F "pool" in
https://docs.liferay.com/portal/6.2/propertiesdoc/portal.properties.html
(AFAIK no changes between 6.1 and 6.2)
* It might help looking at the pool/connection states through JMX, so
that you can determine which pool is active on which size.
Does JMX work for pools other than the one for Liferay? As soon as I
can work out exactly where to add the remote JMX properties, I can
give that a try. If it's easy for you to tell me best practices for
adjusting the java commandline for startup, please do.
Just look at what's available by default. I never needed to add more,
rather needed to find the relevant info. Plenty of information
everywhere for enabling/connecting through JMX.
Olaf
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
