Re: info: illegal access: this web application instance has been stopped already w/Parallel deployment
It looks like the in-flight requests are taking longer to complete than the unloadDelay configured for the Context. Mark On 07/01/2021 23:00, Усманов Азат Анварович wrote: > > Hi everyone! About a year ago I asked the following question on the > users-list about getting a illegal state exception when using parallel > deployment in tomcat 7 > https://www.mail-archive.com/users@tomcat.apache.org/msg133549.html > since I wasn't able to find a solution we kinda avoided using parallel > deployment on production enviroment.Recently I got back to that issue(which > is also can be seen when using tomcat in eclipse w\o parallel deployment) > I've been able to fix the issue with eclipse by changing reloadable=true> to ,but the question is how to > fix the error when using regular(non eclipse ) tomcat with parallel > deployment (just like I specified in the original question a year ago -link > above) > Since the non eclipse tomcat config doesn't use reloadable attribute, and the > default for reloadable is false I'm not sure what else to do?I wonder does > reloadable attrubute even playing any role when using it with parallel > deployment? Any help is appreciated. > С уважением, > Азат Усманов > Отдел разработки программного обеспечения > Казанский инновационный университет имени В.Г.Тимирясова > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
info: illegal access: this web application instance has been stopped already w/Parallel deployment
Hi everyone! About a year ago I asked the following question on the users-list about getting a illegal state exception when using parallel deployment in tomcat 7 https://www.mail-archive.com/users@tomcat.apache.org/msg133549.html since I wasn't able to find a solution we kinda avoided using parallel deployment on production enviroment.Recently I got back to that issue(which is also can be seen when using tomcat in eclipse w\o parallel deployment) I've been able to fix the issue with eclipse by changing to ,but the question is how to fix the error when using regular(non eclipse ) tomcat with parallel deployment (just like I specified in the original question a year ago -link above) Since the non eclipse tomcat config doesn't use reloadable attribute, and the default for reloadable is false I'm not sure what else to do?I wonder does reloadable attrubute even playing any role when using it with parallel deployment? Any help is appreciated. С уважением, Азат Усманов Отдел разработки программного обеспечения Казанский инновационный университет имени В.Г.Тимирясова
Re: Let's encrypt SSL config
Hi Ivan,
> Am 07.01.2021 um 20:42 schrieb i...@wordme.app:
>
> Hi,
>
> It drives me nuts now.
>
> I have created sym links to the PEM files. I made the PEM files readable for
> the tomcat user. I set the server.xml to use SSL. And the connector fails to
> start.
>
>
> protocol="org.apache.coyote.http11.Http11NioProtocol"
>
> maxThreads="200"
>
> scheme="https"
>
> secure="true"
>
> SSLEnabled="true"
>
> clientAuth="false"
>
> sslProtocol="TLS"
>
>
> sslImplementationName="org.apache.tomcat.util.net.openssl.OpenSSLImplementat
> ion"
>
> defaultSSLHostConfigName="mydomain.com"
>
>>
>
>protocols="+TLSv1,+TLSv1.1,+TLSv1.2">
>
>
> certificateKeyFile="conf/privkey.pem"
>
> certificateFile="conf/cert.pem"
>
> certificateChainFile="conf/chain.pem"
>
> type="UNDEFINED"
>
> />
>
>
>
>
>
>
Maybe want to try an absolute path like so: ${catalina.base}/conf/ or
${catalina.home}/conf/ ?
Peter
>
> I did try to change the type to RSA, to no avail. All I see in the log is:
>
> 02-Jan-2021 17:40:54.398 INFO [main] org.apache.coyote.AbstractProtocol.init
> Initializing ProtocolHandler ["https-openssl-nio-8443"]
>
> 02-Jan-2021 17:40:54.466 SEVERE [main]
> org.apache.catalina.util.LifecycleBase.handleSubClassException Failed to
> initialize component [Connector[HTTP/1.1-8443]]
>
> org.apache.catalina.LifecycleException: Protocol handler
> initialization failed
>
> at
> org.apache.catalina.connector.Connector.initInternal(Connector.java:1013)
>
> ... some lines removed
>
> at
> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:473)
>
> Caused by: java.lang.IllegalArgumentException
>
> at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJss
> eEndpoint.java:99)
>
> ... some lines are removed
>
> at
> org.apache.catalina.connector.Connector.initInternal(Connector.java:1010)
>
> ... 13 more
>
> Caused by: java.io.IOException
>
> at
> org.apache.tomcat.util.net.SSLUtilBase.getKeyManagers(SSLUtilBase.java:302)
>
> at
> org.apache.tomcat.util.net.openssl.OpenSSLUtil.getKeyManagers(OpenSSLUtil.ja
> va:98)
>
> at
> org.apache.tomcat.util.net.SSLUtilBase.createSSLContext(SSLUtilBase.java:247
> )
>
> at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJss
> eEndpoint.java:97)
>
> ... 20 more
>
>
>
> I've checked the SSLUtilBase.java code (tomcat 9.0.33):
>
> if (certificate.getCertificateFile() == null) {
>
> throw new IOException(sm.getString("jsse.noCertFile"));
>
> }
>
>
>
> I did try to copy the files instead of using sym links. No avail. Removed
> the comments from the cert files. No avail. It seems tomcat cannot find the
> files I've specified in the server.xml.
>
> What do I miss?
>
>
>
> Best Regards,
>
> Ivan
Let's encrypt SSL config
Hi,
It drives me nuts now.
I have created sym links to the PEM files. I made the PEM files readable for
the tomcat user. I set the server.xml to use SSL. And the connector fails to
start.
I did try to change the type to RSA, to no avail. All I see in the log is:
02-Jan-2021 17:40:54.398 INFO [main] org.apache.coyote.AbstractProtocol.init
Initializing ProtocolHandler ["https-openssl-nio-8443"]
02-Jan-2021 17:40:54.466 SEVERE [main]
org.apache.catalina.util.LifecycleBase.handleSubClassException Failed to
initialize component [Connector[HTTP/1.1-8443]]
org.apache.catalina.LifecycleException: Protocol handler
initialization failed
at
org.apache.catalina.connector.Connector.initInternal(Connector.java:1013)
... some lines removed
at
org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:473)
Caused by: java.lang.IllegalArgumentException
at
org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJss
eEndpoint.java:99)
... some lines are removed
at
org.apache.catalina.connector.Connector.initInternal(Connector.java:1010)
... 13 more
Caused by: java.io.IOException
at
org.apache.tomcat.util.net.SSLUtilBase.getKeyManagers(SSLUtilBase.java:302)
at
org.apache.tomcat.util.net.openssl.OpenSSLUtil.getKeyManagers(OpenSSLUtil.ja
va:98)
at
org.apache.tomcat.util.net.SSLUtilBase.createSSLContext(SSLUtilBase.java:247
)
at
org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJss
eEndpoint.java:97)
... 20 more
I've checked the SSLUtilBase.java code (tomcat 9.0.33):
if (certificate.getCertificateFile() == null) {
throw new IOException(sm.getString("jsse.noCertFile"));
}
I did try to copy the files instead of using sym links. No avail. Removed
the comments from the cert files. No avail. It seems tomcat cannot find the
files I've specified in the server.xml.
What do I miss?
Best Regards,
Ivan
Re: Browser complains of "weak signature algorithm" in cert on a new Tomcat installation. Does anybody here know anything about that sort of thing
Thanks to all, for both satisfying my morbid curiosity and verifying that it's the customer's problem, not mine. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Browser complains of "weak signature algorithm" in cert on a new Tomcat installation. Does anybody here know anything about that sort of thing
On Wed, Jan 06, 2021 at 03:34:17PM -0800, James H. H. Lampert wrote: > We just had our first Tomcat 8.5 installation on a customer's AS/400. > > The customer apparently has his own CA (they're a big company), and when > I installed SSL in their Tomcat, and tested it with a browser, it > complained, something to the general effect of "weak signature algorithm." > > While it's not really my problem (and is only connected to Tomcat by > virtue of it happening with a Tomcat server), I'm curious about what's > up with it, if anybody here is able and willing to explain it. The beginning of this page might be helpful: https://frasertweedale.github.io/blog-redhat/posts/2017-11-10-freeipa-changing-signature-algorithm.html Simply: the message is saying that the customer's CA signed this certificate in a way that's not now believed by the browser's authors to be sufficiently secure. I don't know what tools are available in the AS/400 environment, but here's how I would use OpenSSL on Linux to inspect a certificate: $ openssl x509 -noout -text -in /etc/ssl/certs/Verisign_Class_3_Public_Primary_Certification_Authority_-_G3.pem Certificate: Data: Version: 1 (0x0) Serial Number: 9b:7e:06:49:a3:3e:62:b9:d5:ee:90:48:71:29:ef:57 Signature Algorithm: sha1WithRSAEncryption Issuer: C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c) 1999 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3 Public Primary Certification Authority - G3 Validity Not Before: Oct 1 00:00:00 1999 GMT Not After : Jul 16 23:59:59 2036 GMT Subject: C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c) 1999 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3 Public Primary Certification Authority - G3 etc. The "Signature Algorithm" is what the message is about. Here it says that the certified public key was signed by hashing it with SHA1 and then encrypting the hash with the CA's RSA private key. I just remembered that your browser probably has a way to display details of a certificate, too. BTW that certificate above was issued in 1999, when SHA1 was considered sufficient. Certificates created today should be using a stronger hash. -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu signature.asc Description: PGP signature
Re: Parallel deploy with /manager/text servlet
On 06/01/2021 21:48, Manuel Dominguez Sarmiento wrote:
> Hi, our system consists on about 80+ webapps on different servers.
> Multiple webapps are deployed per Tomcat server remotely using the
> manager and host-manager webapps.
>
> This has been working fine for years, however some servers now have 5+
> webapps and they are taking a long time to start. We invoke the deploy
> command on the manager webapp in parallel for each webapp, in order to
> attempt a reduction in total server startup time. However the speedup is
> very modest. The servers have powerful Xeon multi-core servers so a
> parallel speedup should be possible.
>
> Looking at the source code for
> org.apache.catalina.manager.ManagerServlet we see that the following
> method is synchronized which would explain the behaviour we are seeing:
> protected synchronized void deploy
> (PrintWriter writer, String config, ContextName cn,
> String tag, boolean update, HttpServletRequest request,
> StringManager smClient) {
>
> Is there any real reason why this needs to be synchronized? Tomcat can
> deploy webapps in parallel when backgroundProcessorDelay is set to a
> positive number, but this is not useful when remotely deploying webapps
> using the manager webapp.
>
> Any ideas? Thanks
Some svn archaeology uncovered this commit comment:
"Known issue: locking occurs on an uploaded WAR, for reasons which
elude me right now."
The method level sync looks like an attempt to ensure that there aren't
parallel attempts to deploy a web application to the same path. I can't
think of any other reason. But locking on, essentially, the virtual
host, seems overly broad. A lock on the deployment path would be sufficient.
There are also calls to isServiced(), addServiced() and removeServiced()
which look to be trying to do the same thing which have their own issues
(not atomic, uses a List rather than a Set).
We do need to ensure that we don't get parallel attempts to service the
same web application. There is scope for all sorts of bad things to
happen if that is possible.
Overall, I think this can be fixed but it looks like some API changes
are going to be required which makes things a little more complicated.
It would be worth you opening a Bugzilla issue for this to make sure it
doesn't get forgotten about. The issues with the unsynchronized
deployment methods are sufficient - in my view - to class this as a bug
rather than an enhancement.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
