Re: [VOTE] Release Apache Tomcat 7.0.95
On Thu, Jul 11, 2019 at 8:39 PM Violeta Georgieva wrote: > The proposed Apache Tomcat 7.0.95 release is now available for voting. > > For full details, see the changelog: > https://ci.apache.org/projects/tomcat/tomcat7/docs/changelog.html > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.95/ > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-1223/ > The git tag is: > https://github.com/apache/tomcat/tree/7.0.95 > 647a7ebfa4922b9fa213fe642e6180395bbfc135 > > The proposed 7.0.95 release is: > [ ] Broken - do not release > [X] Stable - go ahead and release as 7.0.95 Stable > Rémy
[tomcat] branch master updated: Workaround java.util.logging (JUL) configuration
This is an automated email from the ASF dual-hosted git repository.
remm pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/master by this push:
new 821ad41 Workaround java.util.logging (JUL) configuration
821ad41 is described below
commit 821ad413f320bb26fd1e8c02f59723f519b12845
Author: remm
AuthorDate: Mon Jul 15 16:45:20 2019 +0200
Workaround java.util.logging (JUL) configuration
It seems the JUL configuration is not currently implemented in native
images, so workaround using the instructions from the GraalVM
documentation. Also supported is using a custom LogManager. I don't know
how to set it besides using the system property, so there is no way to
use JULI at the moment.
---
java/org/apache/catalina/startup/Tomcat.java | 13 +
webapps/docs/changelog.xml | 8 +++-
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/java/org/apache/catalina/startup/Tomcat.java
b/java/org/apache/catalina/startup/Tomcat.java
index 5431e02..21b2223 100644
--- a/java/org/apache/catalina/startup/Tomcat.java
+++ b/java/org/apache/catalina/startup/Tomcat.java
@@ -36,6 +36,7 @@ import java.util.Stack;
import java.util.jar.JarEntry;
import java.util.jar.JarFile;
import java.util.logging.Level;
+import java.util.logging.LogManager;
import java.util.logging.Logger;
import javax.servlet.Servlet;
@@ -72,6 +73,7 @@ import org.apache.catalina.util.ContextName;
import org.apache.catalina.util.IOTools;
import org.apache.tomcat.util.ExceptionUtils;
import org.apache.tomcat.util.buf.UriUtil;
+import org.apache.tomcat.util.compat.JreCompat;
import org.apache.tomcat.util.descriptor.web.LoginConfig;
import org.apache.tomcat.util.file.ConfigFileLoader;
import org.apache.tomcat.util.file.ConfigurationSource;
@@ -1386,6 +1388,17 @@ public class Tomcat {
return result;
}
+static {
+// Graal native images don't load any configuration except the VM
default
+if (JreCompat.isGraalAvailable()) {
+try (InputStream is = new FileInputStream(new
File(System.getProperty("java.util.logging.config.file",
"conf/logging.properties" {
+LogManager.getLogManager().readConfiguration(is);
+} catch (SecurityException | IOException e) {
+// Ignore, the VM default will be used
+}
+}
+}
+
/**
* Main executable method for use with a Maven packager.
* @param args the command line arguments
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index d1f80e7..7963b3b 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -90,7 +90,13 @@
-Improvements and workarounds for GraalVM native images. (remm)
+JNDI support for GraalVM native images. (remm)
+
+
+JSP runtime library support for GraalVM native images. (remm)
+
+
+java.util.logging configuration for GraalVM native images. (remm)
Update Checkstyle to 8.22. (markt)
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Graal and Tomcat Native
On Fri, Jul 12, 2019 at 11:21 AM Rémy Maucherat wrote: > In the native code, it crashes on: > https://github.com/apache/tomcat-native/blob/master/native/src/ssl.c#L635 > > I modified the code to: > double d = (((double)(rand()%RAND_MAX)/RAND_MAX)*(h-l)); > apr_snprintf(buf, sizeof(buf), "%.0f", d); > > And it cores on the apr_snprintf. I don't see how it is unsafe though. > > Ok, going back to it on Monday, things are magically going better (summary: everything works fine). The problem is "simply" that "--static" doesn't provide a working native image when using TLS. The problem also actually occurs with JSSE as well (since the EC support is also an external JNI library). Note: Not being able to statically link ties the native image to the platform it is built on (= not good for cloud in some cases, unless the target is good enough to build the binary), so that's not great and TLS becomes non viable in many cases. Rémy
[tomcat] branch master updated: Add JNI configuration
This is an automated email from the ASF dual-hosted git repository.
remm pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/master by this push:
new 5f32b50 Add JNI configuration
5f32b50 is described below
commit 5f32b5084921488cfbae8fe4d154919fd2678052
Author: remm
AuthorDate: Mon Jul 15 18:17:08 2019 +0200
Add JNI configuration
---
res/tomcat-maven/README.md | 2 +-
res/tomcat-maven/tomcat-jni.json | 8
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/res/tomcat-maven/README.md b/res/tomcat-maven/README.md
index b9e45a7..d2592cd 100644
--- a/res/tomcat-maven/README.md
+++ b/res/tomcat-maven/README.md
@@ -102,7 +102,7 @@ the substrate VM with the agent again.
Generate the final json files using native-image-configuration then use native
image using the generated reflection metadata:
```
$JAVA_HOME/bin/native-image-configure generate
--trace-input=$TOMCAT_MAVEN/target/trace-file.json
--output-dir=$TOMCAT_MAVEN/target
-$JAVA_HOME/bin/native-image --no-server --allow-incomplete-classpath
--enable-https
--initialize-at-build-time=org.eclipse.jdt,org.apache.el.parser.SimpleNode,javax.servlet.jsp.JspFactory,org.apache.jasper.servlet.JasperInitializer,org.apache.jasper.runtime.JspFactoryImpl
-H:+JNI -H:+ReportUnsupportedElementsAtRuntime -H:+ReportExceptionStackTraces
-H:EnableURLProtocols=jar -H:ConfigurationFileDirectories=$TOMCAT_MAVEN/target/
-H:ReflectionConfigurationFiles=$TOMCAT_MAVEN/tomcat-reflecti [...]
+$JAVA_HOME/bin/native-image --no-server --allow-incomplete-classpath
--enable-https
--initialize-at-build-time=org.eclipse.jdt,org.apache.el.parser.SimpleNode,javax.servlet.jsp.JspFactory,org.apache.jasper.servlet.JasperInitializer,org.apache.jasper.runtime.JspFactoryImpl
-H:+JNI -H:+ReportUnsupportedElementsAtRuntime -H:+ReportExceptionStackTraces
-H:EnableURLProtocols=http,https,jar
-H:ConfigurationFileDirectories=$TOMCAT_MAVEN/target/
-H:ReflectionConfigurationFiles=$TOMCAT_MAVEN/tomc [...]
./tomcat-maven-1.0 -Djava.library.path=$JAVA_HOME/jre/lib/amd64
-Dcatalina.base=. -Djava.util.logging.config.file=conf/logging.properties
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
```
diff --git a/res/tomcat-maven/tomcat-jni.json b/res/tomcat-maven/tomcat-jni.json
new file mode 100644
index 000..1ca1093
--- /dev/null
+++ b/res/tomcat-maven/tomcat-jni.json
@@ -0,0 +1,8 @@
+[
+{ "name":"org.apache.tomcat.jni.FileInfo" },
+{ "name":"org.apache.tomcat.jni.Sockaddr" },
+{ "name":"org.apache.tomcat.jni.FileInfo" },
+{ "name":"org.apache.tomcat.jni.Error" },
+{ "name":"org.apache.tomcat.jni.SSL",
"methods":[{"name":"newSSL","parameterTypes":["long","boolean"]}] },
+{ "name":"java.lang.String",
"methods":[{"name":"","parameterTypes":["byte[]"]},{"name":"getBytes","parameterTypes":[]}]
}
+]
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Http11NioProtocol deadlocks with useAsyncIO="true" and HTTPS/2.0
Hi, we had been running Tomcat 9.0.17 for quite some time on our high-load production servers, using the attached server.xml configuration. Upon upgrading to 9.0.21 we started experiencing many random deadlocks. We run performance advertising campaigns, and our conversion rates dropped to below half of what they usually are, which was an obvious consequence of our servers randomly locking up. Plus, it was very easy to reproduce the deadlocks, which seemed to "magically unlock" when opening a second tab/window and opening the same URL that was locked on the other window/tab. Doing this unlocked both windows/tabs at once, immediately. We found this was only happening on HTTPS, but NOT on HTTP. Furthermore, we found this was only happening when the browser negotiated an upgrade to HTTPS/2.0 Once we found this, we temporarily removed the className="org.apache.coyote.http2.Http2Protocol" /> configuration, and all was back to normal. However, we need HTTP/2, so we continued to look for a proper solution. Looking at the Tomcat changelog, we found there have been many changes since 9.0.17 related to useAsyncIO and HTTP/2. One particular change for 9.0.22 caught our attention: /"Remove a source of potential deadlocks when using HTTP/2 when the Connector is configured with useAsyncIO as true. (markt)" /We also found the following discussion thread, which describes issues similar to what we were experiencing:/ /http://mail-archives.apache.org/mod_mbox/tomcat-dev/201906.mbox/%3c20190606204631.bab6c8a...@gitbox.apache.org%3e/ / So we upgraded to 9.0.22 thinking that the deadlock would be gone. But alas, it was not. The deadlocks remained. We found that 9.0.20 changed the default for useAsyncIO from "false" to "true". So we changed useAsyncIO back to what it was when we were running 9.0.17 (false) and all is back to normal on 9.0.22 So the conclusion is: there are still deadlock bugs on the NIO connector with useAsyncIO="true" and upgrades to HTTP/2.0 Besides fixing them, we believe that the useAsyncIO default should be reverted to "false". Looking forward to the team's feedback. Thanks, -- Manuel Dominguez Sarmiento - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
CI is back
Hi, It seems CI is back up :) Great news ! However, there's something odd with the build: https://ci.apache.org/builders/tomcat-trunk/builds/4485/steps/compile/logs/stdio It's downloading NSIS 2.51 while it should be using 3.04. CI might be using some old properties here, right ? This should actually have failed earlier but before the CI wipe the existing NSIS download kept being used without checksum. https://ci.apache.org/builders/tomcat-trunk/builds/4458/steps/compile/logs/stdio testexist: [echo] Testing for /home/buildslave/slave/tomcat-trunk/basepath/nsis-2.51/makensis.exe Rémy
