JDK 13 - Early Access build 20 is available

[Rory O'Donnell]

Hi Mark,


 *OpenJDK builds *- JDK 13 - Early Access build 20 is available at
 http://jdk.java.net/13/

 * These early-access , open-source builds are provided under the
 o GNU General Public License, version 2, with the Classpath
   Exception .
 * Changes in this build
   

 * Release notes [1]


 *Significant changes since the last availability email*

 * build 20
 o Removal of T-Systems Deutsche Telekom Root CA 2 certificate
   (JDK-8222137)
 o Add new FileSystems.newFileSystem methods (JDK-8218875)
 o Enhance auto vectorization for x86 (JDK-8222074)
 o Remove CollectorPolicy and its subclasses (JDK-8198505)
 o Drop support for pre JDK 1.4 SocketImpl implementations
   (JDK-8216978)
 * build 19
 o add support for generating method handles from a variable symbol
   (JDK-8222744)
 o mark new VM option AllowRedefinitionToAddOrDeleteMethods as
   deprecated (JDK-8222934)
 * build 18
 o Improve String::equals warmup characteristics (JDK-8215017)
 o [Containers] Improve systemd slice memory limit support
   (JDK-8217338)


   Bug fixes for issues reported by Open Source Projects

 * build 20
 o assert(Compile::current()->live_nodes() <
   Compile::current()->max_node_limit()) failed: Live Node limit
   exceeded limit (JDK-8219520)
 o C2: MemNode::can_see_stored_value() ignores casts which carry
   control dependency (JDK-8219902)
 o New fix of the deadlock in sun.security.ssl.SSLSocketImpl
   (JDK-8219991)


 JEP updates since last email

 * JEP 350: Dynamic CDS Archives  
   istargeted for JDK 13.
 * JEP 351: ZGC: Uncommit Unused Memory
    istargeted for JDK 13
 * JEP 353: Reimplement the Legacy Socket API
    moved to Candidate
 * JEP 354: Switch Expressions  moved
   to Candidate.


 OpenJDK Committers’ Workshop, 1–2 August 2019 [2]

Rgds,Rory

[1] http://jdk.java.net/13/release-notes
[2] https://mail.openjdk.java.net/pipermail/announce/2019-April/000269.html

--
Rgds, Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin, Ireland

Re: [tomcat] branch master updated: Make sure timeout elapses before calling a timeout

[Mark Thomas]

On 09/05/2019 21:53, Mark Thomas wrote:
> On 05/05/2019 09:37, r...@apache.org wrote:
>> 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 6232d82  Make sure timeout elapses before calling a timeout
>> 6232d82 is described below
>>
>> commit 6232d82cc5db73e5da5392d6ec6d9d01ce65c85e
>> Author: remm 
>> AuthorDate: Sun May 5 10:37:05 2019 +0200
>>
>> Make sure timeout elapses before calling a timeout
>> 
>> It seems there are extra stream notify as although 0 bytes have been
>> allocated only a few ms have passed when there is a failure.
> 
> I think something else is going on here. I'm still trying to figure it out.

I can't reproduce the test failure - either with the code or some code
written to explicitly test this scenario. However, I do believe I know
what the problem is.

backLogStreams is a concurrent Map of Stream to int[]. The int[] is a
two element array where the first element is number of bytes the stream
requires and the second is the number allocated.

I believe the issue occurs as follows:
- Thread A requests more bytes for Stream A than are available in the
  connection window
- Stream A is placed into the backlog
- Thread A enters streamA.wait()
- Thread B processes a Window update message
- Thread B allocates some bytes to streamA
- Thread B calls streamA.notify()
- Thread A exits the wait but, because the elements of the int[] are not
  volatile, it does not see the window update
- Thread A treats existing the wait without an allocation as a timeout

I've left out the obtaining and releasing of locks on streamA and the
Http2UpgradeHandler for clarity but I'll note that some reads of the
allocation occur outside of any lock

The above description is consistent with a known failure trace:
https://ci.apache.org/projects/tomcat/tomcat9/logs/4288/TEST-org.apache.coyote.http2.TestHttp2Section_5_3.NIO2.txt

My plan is as follows:
- revert the "check it has really timed out fix"
- modify the access to the allocation so that updates to the allocation
  are guaranteed to be visible after the wait() exits

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[tomcat] branch master updated (df2424e -> 229b2a1)

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt pushed a change to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git.


from df2424e  Fix javadoc too.
 new 6a0ad7d  Revert 6232d82 prior to implementing an alternative fix
 new a573d93  Fix concurrency issue that lead to intermittent h2 5.3 test 
failures
 new 229b2a1  Enable debug logging for h2 in case of further failures

The 3 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 conf/logging.properties   |  2 +-
 java/org/apache/coyote/http2/Http2UpgradeHandler.java | 12 +++-
 webapps/docs/changelog.xml|  3 ++-
 3 files changed, 10 insertions(+), 7 deletions(-)


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[tomcat] 01/03: Revert 6232d82 prior to implementing an alternative fix

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git

commit 6a0ad7d15662346f907432831721e3e3b2282096
Author: Mark Thomas 
AuthorDate: Fri May 10 10:15:07 2019 +0100

Revert 6232d82 prior to implementing an alternative fix
---
 java/org/apache/coyote/http2/Http2UpgradeHandler.java | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/java/org/apache/coyote/http2/Http2UpgradeHandler.java 
b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
index 2db837a..213b884 100644
--- a/java/org/apache/coyote/http2/Http2UpgradeHandler.java
+++ b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
@@ -752,7 +752,6 @@ class Http2UpgradeHandler extends AbstractStream implements 
InternalHttpUpgradeH
 // this thread until after this thread enters wait()
 int allocation = 0;
 synchronized (stream) {
-long writeTimeout = protocol.getWriteTimeout();
 do {
 synchronized (this) {
 if (!stream.canWrite()) {
@@ -805,17 +804,16 @@ class Http2UpgradeHandler extends AbstractStream 
implements InternalHttpUpgradeH
 // Connection level window is empty. Although this
 // request is for a stream, use the connection
 // timeout
+long writeTimeout = protocol.getWriteTimeout();
 if (writeTimeout < 0) {
 stream.wait();
 } else {
-long t1 = System.currentTimeMillis();
 stream.wait(writeTimeout);
-writeTimeout -= (System.currentTimeMillis() + 
1 - t1);
 // Has this stream been granted an allocation
 // Note: If the stream in not in this Map then 
the
 //   requested write has been fully 
allocated
 int[] value = backLogStreams.get(stream);
-if (writeTimeout <= 0 && value != null && 
value[1] == 0) {
+if (value != null && value[1] == 0) {
 if (log.isDebugEnabled()) {
 
log.debug(sm.getString("upgradeHandler.noAllocation",
 connectionId));


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[tomcat] 03/03: Enable debug logging for h2 in case of further failures

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git

commit 229b2a169505672ef288204ed59cb6e2723e595c
Author: Mark Thomas 
AuthorDate: Fri May 10 10:21:53 2019 +0100

Enable debug logging for h2 in case of further failures
---
 conf/logging.properties | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/logging.properties b/conf/logging.properties
index e8b7b16..fc52083 100644
--- a/conf/logging.properties
+++ b/conf/logging.properties
@@ -73,7 +73,7 @@ 
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/host-manager].ha
 #org.apache.jasper.compiler.TldLocationsCache.level = FINE
 
 # To see debug messages for HTTP/2 handling, uncomment the following line:
-#org.apache.coyote.http2.level = FINE
+org.apache.coyote.http2.level = FINE
 
 # To see debug messages for WebSocket handling, uncomment the following line:
 #org.apache.tomcat.websocket.level = FINE


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[tomcat] 02/03: Fix concurrency issue that lead to intermittent h2 5.3 test failures

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git

commit a573d936cc390b09e4e2a37795761c0c3eac819e
Author: Mark Thomas 
AuthorDate: Fri May 10 10:21:31 2019 +0100

Fix concurrency issue that lead to intermittent h2 5.3 test failures
---
 java/org/apache/coyote/http2/Http2UpgradeHandler.java | 6 +-
 webapps/docs/changelog.xml| 3 ++-
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/java/org/apache/coyote/http2/Http2UpgradeHandler.java 
b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
index 213b884..c2cf4da 100644
--- a/java/org/apache/coyote/http2/Http2UpgradeHandler.java
+++ b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
@@ -812,7 +812,11 @@ class Http2UpgradeHandler extends AbstractStream 
implements InternalHttpUpgradeH
 // Has this stream been granted an allocation
 // Note: If the stream in not in this Map then 
the
 //   requested write has been fully 
allocated
-int[] value = backLogStreams.get(stream);
+int[] value;
+// Ensure allocations made in other threads 
are visible
+synchronized (this) {
+value = backLogStreams.get(stream);
+}
 if (value != null && value[1] == 0) {
 if (log.isDebugEnabled()) {
 
log.debug(sm.getString("upgradeHandler.noAllocation",
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index a115137..a0d7616 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -60,7 +60,8 @@
 this. (remm)
   
   
-Filter out some cases of incorrect HTTP/2 connection timeout. (remm)
+Fix concurrency issue that lean to incorrect HTTP/2 connection timeout.
+(remm/markt)
   
   
 Avoid useless exception wrapping in async IO. (remm)


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[tomcat] branch master updated: Update to Graal 19

[remm]

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 6bb8ad5  Update to Graal 19
6bb8ad5 is described below

commit 6bb8ad5bd3347465de28fbb0225c728a0a623754
Author: remm 
AuthorDate: Fri May 10 11:55:16 2019 +0200

Update to Graal 19

The previous version was 1.0 RC 16, that's progress. Thankfully, there's
still as many issues as before. Start working around the ones that will
"never" be fixed using JreCompat (JMX and URL stream handlers). Document
the new process.
---
 java/org/apache/catalina/startup/Tomcat.java|  8 +++-
 java/org/apache/catalina/webresources/StandardRoot.java |  9 ++---
 java/org/apache/tomcat/util/compat/GraalCompat.java |  4 ++--
 java/org/apache/tomcat/util/compat/JreCompat.java   | 10 ++
 java/org/apache/tomcat/util/modeler/Registry.java   |  7 ++-
 res/tomcat-maven/README.md  | 14 +++---
 res/tomcat-maven/pom.xml|  2 +-
 webapps/docs/changelog.xml  |  8 
 8 files changed, 47 insertions(+), 15 deletions(-)

diff --git a/java/org/apache/catalina/startup/Tomcat.java 
b/java/org/apache/catalina/startup/Tomcat.java
index 2309109..71d923a 100644
--- a/java/org/apache/catalina/startup/Tomcat.java
+++ b/java/org/apache/catalina/startup/Tomcat.java
@@ -1391,6 +1391,12 @@ public class Tomcat {
  * @throws Exception if an error occurs
  */
 public static void main(String[] args) throws Exception {
+// Process some command line parameters
+for (int i = 0; i < args.length; i++) {
+if (args[i].equals("--no-jmx")) {
+Registry.disableRegistry();
+}
+}
 org.apache.catalina.startup.Tomcat tomcat = new 
org.apache.catalina.startup.Tomcat();
 // Create a Catalina instance and let it parse the configuration files
 // It will also set a shutdown hook to stop the Server when needed
@@ -1439,7 +1445,7 @@ public class Tomcat {
 } else if (args[i].equals("--await")) {
 await = true;
 } else if (args[i].equals("--no-jmx")) {
-Registry.disableRegistry();
+// This was already processed before
 } else {
 throw new 
IllegalArgumentException(sm.getString("tomcat.invalidCommandLine", args[i]));
 }
diff --git a/java/org/apache/catalina/webresources/StandardRoot.java 
b/java/org/apache/catalina/webresources/StandardRoot.java
index ba2bf39..0f5058e 100644
--- a/java/org/apache/catalina/webresources/StandardRoot.java
+++ b/java/org/apache/catalina/webresources/StandardRoot.java
@@ -45,6 +45,7 @@ import org.apache.catalina.util.LifecycleMBeanBase;
 import org.apache.juli.logging.Log;
 import org.apache.juli.logging.LogFactory;
 import org.apache.tomcat.util.buf.UriUtil;
+import org.apache.tomcat.util.compat.JreCompat;
 import org.apache.tomcat.util.http.RequestUtil;
 import org.apache.tomcat.util.res.StringManager;
 
@@ -694,9 +695,11 @@ public class StandardRoot extends LifecycleMBeanBase 
implements WebResourceRoot
 }
 
 protected void registerURLStreamHandlerFactory() {
-// Ensure support for jar:war:file:/ URLs will be available (required
-// for resource JARs in packed WAR files).
-TomcatURLStreamHandlerFactory.register();
+if (!JreCompat.isGraalAvailable()) {
+// Ensure support for jar:war:file:/ URLs will be available 
(required
+// for resource JARs in packed WAR files).
+TomcatURLStreamHandlerFactory.register();
+}
 }
 
 @Override
diff --git a/java/org/apache/tomcat/util/compat/GraalCompat.java 
b/java/org/apache/tomcat/util/compat/GraalCompat.java
index f6636c7..bfa7b02 100644
--- a/java/org/apache/tomcat/util/compat/GraalCompat.java
+++ b/java/org/apache/tomcat/util/compat/GraalCompat.java
@@ -25,10 +25,10 @@ class GraalCompat extends JreCompat {
 static {
 boolean result = false;
 try {
-Class nativeImageClazz = 
Class.forName("org.graalvm.nativeimage");
+Class nativeImageClazz = 
Class.forName("org.graalvm.nativeimage.ImageInfo");
 result = (nativeImageClazz.getMethod("inImageCode").invoke(null) 
== Boolean.TRUE);
 } catch (ClassNotFoundException e) {
-// Must be Java 8
+// Must be Graal
 } catch (ReflectiveOperationException | IllegalArgumentException e) {
 // Should never happen
 }
diff --git a/java/org/apache/tomcat/util/compat/JreCompat.java 
b/java/org/apache/tomcat/util/compat/JreCompat.java
index f507b11..ffe2223 100644
--- a/java/org/apache/tomcat/util/compat/JreCompat.java
+++ b/java/org/apache/tomcat/util/compat/JreCompat.j

buildbot failure in on tomcat-trunk

[buildbot]

The Buildbot has detected a new failure on builder tomcat-trunk while building 
tomcat. Full details are available at:
https://ci.apache.org/builders/tomcat-trunk/builds/4324

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: silvanus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-commit' 
triggered this build
Build Source Stamp: [branch master] 229b2a169505672ef288204ed59cb6e2723e595c
Blamelist: Mark Thomas 

BUILD FAILED: failed compile_1

Sincerely,
 -The Buildbot




-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: buildbot failure in on tomcat-trunk

[Mark Thomas]

On 10/05/2019 10:55, build...@apache.org wrote:
> The Buildbot has detected a new failure on builder tomcat-trunk while 
> building tomcat. Full details are available at:
> https://ci.apache.org/builders/tomcat-trunk/builds/4324

Hmmm. Looks like my analysis was off. Investigating now...

Mark


> 
> Buildbot URL: https://ci.apache.org/
> 
> Buildslave for this Build: silvanus_ubuntu
> 
> Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-commit' 
> triggered this build
> Build Source Stamp: [branch master] 229b2a169505672ef288204ed59cb6e2723e595c
> Blamelist: Mark Thomas 
> 
> BUILD FAILED: failed compile_1
> 
> Sincerely,
>  -The Buildbot
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[tomcat] branch master updated: Minor Graal workarounds and robustness

[remm]

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 aa73fa0  Minor Graal workarounds and robustness
aa73fa0 is described below

commit aa73fa021267bfee65b0aa79c22057941ef5b210
Author: remm 
AuthorDate: Fri May 10 13:59:13 2019 +0200

Minor Graal workarounds and robustness

It goes up to the webapp start now. Still having problems with CL
resources though, among many other items.
---
 .../apache/catalina/loader/ParallelWebappClassLoader.java |  3 ++-
 .../org/apache/catalina/loader/WebappClassLoaderBase.java | 10 ++
 java/org/apache/catalina/util/CharsetMapper.java  | 15 ++-
 java/org/apache/jasper/compiler/Localizer.java|  5 +++--
 java/org/apache/naming/StringManager.java |  5 -
 java/org/apache/tomcat/util/compat/JreCompat.java |  1 -
 res/tomcat-maven/README.md|  3 ++-
 7 files changed, 27 insertions(+), 15 deletions(-)

diff --git a/java/org/apache/catalina/loader/ParallelWebappClassLoader.java 
b/java/org/apache/catalina/loader/ParallelWebappClassLoader.java
index 2235229..a71d26d 100644
--- a/java/org/apache/catalina/loader/ParallelWebappClassLoader.java
+++ b/java/org/apache/catalina/loader/ParallelWebappClassLoader.java
@@ -19,13 +19,14 @@ package org.apache.catalina.loader;
 import org.apache.catalina.LifecycleException;
 import org.apache.juli.logging.Log;
 import org.apache.juli.logging.LogFactory;
+import org.apache.tomcat.util.compat.JreCompat;
 
 public class ParallelWebappClassLoader extends WebappClassLoaderBase {
 
 private static final Log log = 
LogFactory.getLog(ParallelWebappClassLoader.class);
 
 static {
-boolean result = ClassLoader.registerAsParallelCapable();
+boolean result = !JreCompat.isGraalAvailable() && 
ClassLoader.registerAsParallelCapable();
 if (!result) {
 
log.warn(sm.getString("webappClassLoaderParallel.registrationFailed"));
 }
diff --git a/java/org/apache/catalina/loader/WebappClassLoaderBase.java 
b/java/org/apache/catalina/loader/WebappClassLoaderBase.java
index a8a079e..1ee573b 100644
--- a/java/org/apache/catalina/loader/WebappClassLoaderBase.java
+++ b/java/org/apache/catalina/loader/WebappClassLoaderBase.java
@@ -137,7 +137,9 @@ public abstract class WebappClassLoaderBase extends 
URLClassLoader
 private static final String CLASS_FILE_SUFFIX = ".class";
 
 static {
-ClassLoader.registerAsParallelCapable();
+if (!JreCompat.isGraalAvailable()) {
+ClassLoader.registerAsParallelCapable();
+}
 JVM_THREAD_GROUP_NAMES.add(JVM_THREAD_GROUP_SYSTEM);
 JVM_THREAD_GROUP_NAMES.add("RMI Runtime");
 }
@@ -1215,7 +1217,7 @@ public abstract class WebappClassLoaderBase extends 
URLClassLoader
 @Override
 public Class loadClass(String name, boolean resolve) throws 
ClassNotFoundException {
 
-synchronized (getClassLoadingLock(name)) {
+synchronized (JreCompat.isGraalAvailable() ? this : 
getClassLoadingLock(name)) {
 if (log.isDebugEnabled())
 log.debug("loadClass(" + name + ", " + resolve + ")");
 Class clazz = null;
@@ -1234,7 +1236,7 @@ public abstract class WebappClassLoaderBase extends 
URLClassLoader
 }
 
 // (0.1) Check our previously loaded class cache
-clazz = findLoadedClass(name);
+clazz = JreCompat.isGraalAvailable() ? null : 
findLoadedClass(name);
 if (clazz != null) {
 if (log.isDebugEnabled())
 log.debug("  Returning class from cache");
@@ -2323,7 +2325,7 @@ public abstract class WebappClassLoaderBase extends 
URLClassLoader
 if (clazz != null)
 return clazz;
 
-synchronized (getClassLoadingLock(name)) {
+synchronized (JreCompat.isGraalAvailable() ? this : 
getClassLoadingLock(name)) {
 clazz = entry.loadedClass;
 if (clazz != null)
 return clazz;
diff --git a/java/org/apache/catalina/util/CharsetMapper.java 
b/java/org/apache/catalina/util/CharsetMapper.java
index 1d6df62..f0efd5a 100644
--- a/java/org/apache/catalina/util/CharsetMapper.java
+++ b/java/org/apache/catalina/util/CharsetMapper.java
@@ -23,6 +23,7 @@ import java.util.Locale;
 import java.util.Properties;
 
 import org.apache.tomcat.util.ExceptionUtils;
+import org.apache.tomcat.util.compat.JreCompat;
 
 
 
@@ -69,11 +70,15 @@ public class CharsetMapper {
  *  resource could not be loaded for any reason.
  */
 public CharsetMapper(String name) {
-try (InputStream stream = this.getClass().getResourceAsStream(name)) {
-map.load(stream);
-} catch (Throwable t) {
-ExceptionUtils.handleThrowable(t);
- 

[tomcat] branch master updated: Update docs again

[remm]

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 6e94fd0  Update docs again
6e94fd0 is described below

commit 6e94fd045c9d65165f33b52d61e7c9a5317922e8
Author: remm 
AuthorDate: Fri May 10 14:31:20 2019 +0200

Update docs again

Failed to make CL resources work, no real idea why. Will look at it
again later. I'll write a container for the native image once it works
better.
---
 res/tomcat-maven/README.md | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/res/tomcat-maven/README.md b/res/tomcat-maven/README.md
index 0796b33..f4f8ea9 100644
--- a/res/tomcat-maven/README.md
+++ b/res/tomcat-maven/README.md
@@ -84,22 +84,21 @@ Note: Graal support in Tomcat is not functional yet.
 
 Download Graal native-image and tools.
 ```
-export JAVA_HOME=/path...to/graalvm-ce-19.0.0
-export TOMCAT_MAVEN=/path...to/tomcat-maven
+export JAVA_HOME=/absolute...path...to/graalvm-ce-19.0.0
+export TOMCAT_MAVEN=/absolute...path...to/tomcat-maven
 cd $JAVA_HOME/bin
 ./gu install native-image
 ```
 Run Tomcat with the agent in full trace mode.
 ```
+cd $TOMCAT_MAVEN
 $JAVA_HOME/bin/java 
-agentlib:native-image-agent=trace-output=./target/trace-file.json -jar 
./target/tomcat-maven-1.0.jar
 ```
-Then exercise necessary paths of your service with the Tomcat configuration.
+Then exercise necessary paths of your service with the Tomcat configuration. 
Do not try to run any JSPs.
 
-Generate the final json using native-image-configuration then use native image 
using the generated reflection metadata.
+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=./target/trace-file.json --output-dir=./target
-$JAVA_HOME/bin/native-image --allow-incomplete-classpath 
-H:+ReportUnsupportedElementsAtRuntime 
-H:ConfigurationFileDirectories=$TOMCAT_MAVEN/target/ 
-H:ReflectionConfigurationFiles=$TOMCAT_MAVEN/tomcat-reflection.json -jar 
target/tomcat-maven-1.0.jar
-./tomcat-maven-1.0 --no-jmx -Dcatalina.base=. 
-Djava.util.logging.config.file=conf/logging.properties 
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
+$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 --allow-incomplete-classpath 
-H:+ReportUnsupportedElementsAtRuntime 
-H:ConfigurationFileDirectories=$TOMCAT_MAVEN/target/ 
-H:ReflectionConfigurationFiles=$TOMCAT_MAVEN/tomcat-reflection.json -jar 
$TOMCAT_MAVEN/target/tomcat-maven-1.0.jar
+./tomcat-maven-1.0 -Dcatalina.base=. 
-Djava.util.logging.config.file=conf/logging.properties 
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
 ```
-Note: -H:ConfigurationFileDirectories does not appear to work properly, so it 
could be needed to add the content of reflect-config.json
- to tomcat-reflection.json.


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[tomcat] branch master updated: Increase timeouts to reduce test failures with debug logging

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt 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 619ded4  Increase timeouts to reduce test failures with debug logging
619ded4 is described below

commit 619ded412c98262238544e50d8acbd690101
Author: Mark Thomas 
AuthorDate: Fri May 10 13:30:47 2019 +0100

Increase timeouts to reduce test failures with debug logging
---
 test/org/apache/coyote/http2/Http2TestBase.java | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/test/org/apache/coyote/http2/Http2TestBase.java 
b/test/org/apache/coyote/http2/Http2TestBase.java
index 3a0c8d9..ed15314 100644
--- a/test/org/apache/coyote/http2/Http2TestBase.java
+++ b/test/org/apache/coyote/http2/Http2TestBase.java
@@ -536,11 +536,11 @@ public abstract class Http2TestBase extends 
TomcatBaseTest {
 Connector connector = getTomcatInstance().getConnector();
 Http2Protocol http2Protocol = new Http2Protocol();
 // Short timeouts for now. May need to increase these for CI systems.
-http2Protocol.setReadTimeout(2000);
-http2Protocol.setWriteTimeout(2000);
-http2Protocol.setKeepAliveTimeout(5000);
-http2Protocol.setStreamReadTimeout(1000);
-http2Protocol.setStreamWriteTimeout(1000);
+http2Protocol.setReadTimeout(4000);
+http2Protocol.setWriteTimeout(4000);
+http2Protocol.setKeepAliveTimeout(1);
+http2Protocol.setStreamReadTimeout(2000);
+http2Protocol.setStreamWriteTimeout(2000);
 http2Protocol.setMaxConcurrentStreams(maxConcurrentStreams);
 connector.addUpgradeProtocol(http2Protocol);
 }


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[tomcat] branch master updated: Log stream id as well

[remm]

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 06c7095  Log stream id as well
06c7095 is described below

commit 06c7095e76bcb87ba0dcafcb427ec6de4e16bdcf
Author: remm 
AuthorDate: Fri May 10 17:02:13 2019 +0200

Log stream id as well
---
 java/org/apache/coyote/http2/Http2UpgradeHandler.java | 2 +-
 java/org/apache/coyote/http2/LocalStrings.properties  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/java/org/apache/coyote/http2/Http2UpgradeHandler.java 
b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
index c2cf4da..7b0964d 100644
--- a/java/org/apache/coyote/http2/Http2UpgradeHandler.java
+++ b/java/org/apache/coyote/http2/Http2UpgradeHandler.java
@@ -820,7 +820,7 @@ class Http2UpgradeHandler extends AbstractStream implements 
InternalHttpUpgradeH
 if (value != null && value[1] == 0) {
 if (log.isDebugEnabled()) {
 
log.debug(sm.getString("upgradeHandler.noAllocation",
-connectionId));
+connectionId, 
stream.getIdentifier()));
 }
 // No allocation
 // Close the connection. Do this first 
since
diff --git a/java/org/apache/coyote/http2/LocalStrings.properties 
b/java/org/apache/coyote/http2/LocalStrings.properties
index 4191ae1..174093c 100644
--- a/java/org/apache/coyote/http2/LocalStrings.properties
+++ b/java/org/apache/coyote/http2/LocalStrings.properties
@@ -128,7 +128,7 @@ upgradeHandler.init=Connection [{0}], State [{1}]
 upgradeHandler.initialWindowSize.invalid=Connection [{0}], Illegal value of 
[{1}] ignored for initial window size
 upgradeHandler.invalidPreface=Connection [{0}], Invalid connection preface
 upgradeHandler.ioerror=Connection [{0}]
-upgradeHandler.noAllocation=Connection [{0}], Timeout waiting for allocation
+upgradeHandler.noAllocation=Connection [{0}], Stream [{1}], Timeout waiting 
for allocation
 upgradeHandler.noNewStreams=Connection [{0}], Stream [{1}], Stream ignored as 
no new streams are permitted on this connection
 upgradeHandler.notifyAll=Connection [{0}], Stream [{1}], notifyAll() called to 
release StreamOutputBuffer
 upgradeHandler.pause.entry=Connection [{0}] Pausing


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [tomcat] branch master updated: Make sure timeout elapses before calling a timeout

[Rémy Maucherat]

On Fri, May 10, 2019 at 11:14 AM Mark Thomas  wrote:

> On 09/05/2019 21:53, Mark Thomas wrote:
> > On 05/05/2019 09:37, r...@apache.org wrote:
> >> 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 6232d82  Make sure timeout elapses before calling a timeout
> >> 6232d82 is described below
> >>
> >> commit 6232d82cc5db73e5da5392d6ec6d9d01ce65c85e
> >> Author: remm 
> >> AuthorDate: Sun May 5 10:37:05 2019 +0200
> >>
> >> Make sure timeout elapses before calling a timeout
> >>
> >> It seems there are extra stream notify as although 0 bytes have been
> >> allocated only a few ms have passed when there is a failure.
> >
> > I think something else is going on here. I'm still trying to figure it
> out.
>
> I can't reproduce the test failure - either with the code or some code
> written to explicitly test this scenario. However, I do believe I know
> what the problem is.
>
> backLogStreams is a concurrent Map of Stream to int[]. The int[] is a
> two element array where the first element is number of bytes the stream
> requires and the second is the number allocated.
>
> I believe the issue occurs as follows:
> - Thread A requests more bytes for Stream A than are available in the
>   connection window
> - Stream A is placed into the backlog
> - Thread A enters streamA.wait()
> - Thread B processes a Window update message
> - Thread B allocates some bytes to streamA
> - Thread B calls streamA.notify()
> - Thread A exits the wait but, because the elements of the int[] are not
>   volatile, it does not see the window update
> - Thread A treats existing the wait without an allocation as a timeout
>
> I've left out the obtaining and releasing of locks on streamA and the
> Http2UpgradeHandler for clarity but I'll note that some reads of the
> allocation occur outside of any lock
>
> The above description is consistent with a known failure trace:
>
> https://ci.apache.org/projects/tomcat/tomcat9/logs/4288/TEST-org.apache.coyote.http2.TestHttp2Section_5_3.NIO2.txt
>
> My plan is as follows:
> - revert the "check it has really timed out fix"
> - modify the access to the allocation so that updates to the allocation
>   are guaranteed to be visible after the wait() exits
>

I agree there's something wrong, but the current algorithm may not be
robust enough because anything notifying the stream object will break it.

>From the logs, the problem (looking only at test 5_3) is with stream 19.
When the test passes, the stream was never actually backloged. When it
fails, it was and the window update frame read does not cause the backlog
release (so when Stream.incrementWindowSize does notifyAll, it breaks).

The trace is:
at
org.apache.coyote.http2.AbstractStream.incrementWindowSize(AbstractStream.java:121)
at org.apache.coyote.http2.Stream.incrementWindowSize(Stream.java:251)
at
org.apache.coyote.http2.Http2UpgradeHandler.incrementWindowSize(Http2UpgradeHandler.java:1533)
at
org.apache.coyote.http2.Http2AsyncUpgradeHandler.incrementWindowSize(Http2AsyncUpgradeHandler.java:39)
at
org.apache.coyote.http2.Http2Parser.readWindowUpdateFrame(Http2Parser.java:416)
at
org.apache.coyote.http2.Http2AsyncParser$FrameCompletionHandler.completed(Http2AsyncParser.java:269)

Rémy

buildbot success in on tomcat-trunk

[buildbot]

The Buildbot has detected a restored build on builder tomcat-trunk while 
building tomcat. Full details are available at:
https://ci.apache.org/builders/tomcat-trunk/builds/4327

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: silvanus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-commit' 
triggered this build
Build Source Stamp: [branch master] 06c7095e76bcb87ba0dcafcb427ec6de4e16bdcf
Blamelist: remm 

Build succeeded!

Sincerely,
 -The Buildbot




-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [tomcat] branch master updated: Make sure timeout elapses before calling a timeout

[Mark Thomas]

On 10/05/2019 16:26, Rémy Maucherat wrote:
> On Fri, May 10, 2019 at 11:14 AM Mark Thomas  wrote:
> 
>> On 09/05/2019 21:53, Mark Thomas wrote:
>>> On 05/05/2019 09:37, r...@apache.org wrote:
 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 6232d82  Make sure timeout elapses before calling a timeout
 6232d82 is described below

 commit 6232d82cc5db73e5da5392d6ec6d9d01ce65c85e
 Author: remm 
 AuthorDate: Sun May 5 10:37:05 2019 +0200

 Make sure timeout elapses before calling a timeout

 It seems there are extra stream notify as although 0 bytes have been
 allocated only a few ms have passed when there is a failure.
>>>
>>> I think something else is going on here. I'm still trying to figure it
>> out.
>>
>> I can't reproduce the test failure - either with the code or some code
>> written to explicitly test this scenario. However, I do believe I know
>> what the problem is.
>>
>> backLogStreams is a concurrent Map of Stream to int[]. The int[] is a
>> two element array where the first element is number of bytes the stream
>> requires and the second is the number allocated.
>>
>> I believe the issue occurs as follows:
>> - Thread A requests more bytes for Stream A than are available in the
>>   connection window
>> - Stream A is placed into the backlog
>> - Thread A enters streamA.wait()
>> - Thread B processes a Window update message
>> - Thread B allocates some bytes to streamA
>> - Thread B calls streamA.notify()
>> - Thread A exits the wait but, because the elements of the int[] are not
>>   volatile, it does not see the window update
>> - Thread A treats existing the wait without an allocation as a timeout
>>
>> I've left out the obtaining and releasing of locks on streamA and the
>> Http2UpgradeHandler for clarity but I'll note that some reads of the
>> allocation occur outside of any lock
>>
>> The above description is consistent with a known failure trace:
>>
>> https://ci.apache.org/projects/tomcat/tomcat9/logs/4288/TEST-org.apache.coyote.http2.TestHttp2Section_5_3.NIO2.txt
>>
>> My plan is as follows:
>> - revert the "check it has really timed out fix"
>> - modify the access to the allocation so that updates to the allocation
>>   are guaranteed to be visible after the wait() exits
>>
> 
> I agree there's something wrong, but the current algorithm may not be
> robust enough because anything notifying the stream object will break it.

I think we have / had multiple bugs here. That hasn't been helping.

> From the logs, the problem (looking only at test 5_3) is with stream 19.
> When the test passes, the stream was never actually backloged. When it
> fails, it was and the window update frame read does not cause the backlog
> release (so when Stream.incrementWindowSize does notifyAll, it breaks).

I see what you mean. Waiting on the stream object for the stream window
update and the connection window update isn't going to work.

If you can see a solution - do let me know. My instinct is that this is
going to be a tricky one to fix.

Is this a regression that needs to be fixed? Or should I go ahead with
the releases. Personally, I'm leaning towards going ahead.

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [tomcat] branch master updated: Make sure timeout elapses before calling a timeout

[Rémy Maucherat]

On Fri, May 10, 2019 at 5:41 PM Mark Thomas  wrote:

> On 10/05/2019 16:26, Rémy Maucherat wrote:
> > On Fri, May 10, 2019 at 11:14 AM Mark Thomas  wrote:
> >
> >> On 09/05/2019 21:53, Mark Thomas wrote:
> >>> On 05/05/2019 09:37, r...@apache.org wrote:
>  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 6232d82  Make sure timeout elapses before calling a timeout
>  6232d82 is described below
> 
>  commit 6232d82cc5db73e5da5392d6ec6d9d01ce65c85e
>  Author: remm 
>  AuthorDate: Sun May 5 10:37:05 2019 +0200
> 
>  Make sure timeout elapses before calling a timeout
> 
>  It seems there are extra stream notify as although 0 bytes have
> been
>  allocated only a few ms have passed when there is a failure.
> >>>
> >>> I think something else is going on here. I'm still trying to figure it
> >> out.
> >>
> >> I can't reproduce the test failure - either with the code or some code
> >> written to explicitly test this scenario. However, I do believe I know
> >> what the problem is.
> >>
> >> backLogStreams is a concurrent Map of Stream to int[]. The int[] is a
> >> two element array where the first element is number of bytes the stream
> >> requires and the second is the number allocated.
> >>
> >> I believe the issue occurs as follows:
> >> - Thread A requests more bytes for Stream A than are available in the
> >>   connection window
> >> - Stream A is placed into the backlog
> >> - Thread A enters streamA.wait()
> >> - Thread B processes a Window update message
> >> - Thread B allocates some bytes to streamA
> >> - Thread B calls streamA.notify()
> >> - Thread A exits the wait but, because the elements of the int[] are not
> >>   volatile, it does not see the window update
> >> - Thread A treats existing the wait without an allocation as a timeout
> >>
> >> I've left out the obtaining and releasing of locks on streamA and the
> >> Http2UpgradeHandler for clarity but I'll note that some reads of the
> >> allocation occur outside of any lock
> >>
> >> The above description is consistent with a known failure trace:
> >>
> >>
> https://ci.apache.org/projects/tomcat/tomcat9/logs/4288/TEST-org.apache.coyote.http2.TestHttp2Section_5_3.NIO2.txt
> >>
> >> My plan is as follows:
> >> - revert the "check it has really timed out fix"
> >> - modify the access to the allocation so that updates to the allocation
> >>   are guaranteed to be visible after the wait() exits
> >>
> >
> > I agree there's something wrong, but the current algorithm may not be
> > robust enough because anything notifying the stream object will break it.
>
> I think we have / had multiple bugs here. That hasn't been helping.
>
> > From the logs, the problem (looking only at test 5_3) is with stream 19.
> > When the test passes, the stream was never actually backloged. When it
> > fails, it was and the window update frame read does not cause the backlog
> > release (so when Stream.incrementWindowSize does notifyAll, it breaks).
>
> I see what you mean. Waiting on the stream object for the stream window
> update and the connection window update isn't going to work.
>
> If you can see a solution - do let me know. My instinct is that this is
> going to be a tricky one to fix.
>
> Is this a regression that needs to be fixed? Or should I go ahead with
> the releases. Personally, I'm leaning towards going ahead.
>

I'm not sure. I don't think it happens without async [for whatever timing
reason].

Rémy

Re: [tomcat] branch master updated: Make sure timeout elapses before calling a timeout

[Mark Thomas]

On 10/05/2019 16:50, Rémy Maucherat wrote:
> On Fri, May 10, 2019 at 5:41 PM Mark Thomas  wrote:
> 
>> On 10/05/2019 16:26, Rémy Maucherat wrote:
>>> On Fri, May 10, 2019 at 11:14 AM Mark Thomas  wrote:
>>>
 On 09/05/2019 21:53, Mark Thomas wrote:
> On 05/05/2019 09:37, r...@apache.org wrote:
>> 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 6232d82  Make sure timeout elapses before calling a timeout
>> 6232d82 is described below
>>
>> commit 6232d82cc5db73e5da5392d6ec6d9d01ce65c85e
>> Author: remm 
>> AuthorDate: Sun May 5 10:37:05 2019 +0200
>>
>> Make sure timeout elapses before calling a timeout
>>
>> It seems there are extra stream notify as although 0 bytes have
>> been
>> allocated only a few ms have passed when there is a failure.
>
> I think something else is going on here. I'm still trying to figure it
 out.

 I can't reproduce the test failure - either with the code or some code
 written to explicitly test this scenario. However, I do believe I know
 what the problem is.

 backLogStreams is a concurrent Map of Stream to int[]. The int[] is a
 two element array where the first element is number of bytes the stream
 requires and the second is the number allocated.

 I believe the issue occurs as follows:
 - Thread A requests more bytes for Stream A than are available in the
   connection window
 - Stream A is placed into the backlog
 - Thread A enters streamA.wait()
 - Thread B processes a Window update message
 - Thread B allocates some bytes to streamA
 - Thread B calls streamA.notify()
 - Thread A exits the wait but, because the elements of the int[] are not
   volatile, it does not see the window update
 - Thread A treats existing the wait without an allocation as a timeout

 I've left out the obtaining and releasing of locks on streamA and the
 Http2UpgradeHandler for clarity but I'll note that some reads of the
 allocation occur outside of any lock

 The above description is consistent with a known failure trace:


>> https://ci.apache.org/projects/tomcat/tomcat9/logs/4288/TEST-org.apache.coyote.http2.TestHttp2Section_5_3.NIO2.txt

 My plan is as follows:
 - revert the "check it has really timed out fix"
 - modify the access to the allocation so that updates to the allocation
   are guaranteed to be visible after the wait() exits

>>>
>>> I agree there's something wrong, but the current algorithm may not be
>>> robust enough because anything notifying the stream object will break it.
>>
>> I think we have / had multiple bugs here. That hasn't been helping.
>>
>>> From the logs, the problem (looking only at test 5_3) is with stream 19.
>>> When the test passes, the stream was never actually backloged. When it
>>> fails, it was and the window update frame read does not cause the backlog
>>> release (so when Stream.incrementWindowSize does notifyAll, it breaks).
>>
>> I see what you mean. Waiting on the stream object for the stream window
>> update and the connection window update isn't going to work.
>>
>> If you can see a solution - do let me know. My instinct is that this is
>> going to be a tricky one to fix.
>>
>> Is this a regression that needs to be fixed? Or should I go ahead with
>> the releases. Personally, I'm leaning towards going ahead.
>>
> 
> I'm not sure. I don't think it happens without async [for whatever timing
> reason].

I've just pushed a fix. The tests seem more stable now locally but I am
going to keep running them. Thanks for the pointer. The issue was
obvious as soon as I read your email.

Given the issue has been there for a while, unless anyone objects I am
going to go ahead with the releases.

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [tomcat] branch master updated: Make sure timeout elapses before calling a timeout

[Rémy Maucherat]

On Fri, May 10, 2019 at 8:01 PM Mark Thomas  wrote:

> I've just pushed a fix. The tests seem more stable now locally but I am
> going to keep running them. Thanks for the pointer. The issue was
> obvious as soon as I read your email.
>
> Given the issue has been there for a while, unless anyone objects I am
> going to go ahead with the releases.
>

Excellent. Gitbox seems out of sync again [I hope nobody starts using it,
or we'll end up running into trouble ...], so no CI run for now, but I'm
certain it's the right fix [it works for me locally and I could "reliably"
reproduce the issue with "test-only" and enough runs of the 5_3 test]. My
original hack doesn't look so bad retrospectively since it is equivalent to
waiting for the right notify, but it's a good thing to drop weird hacks.

Rémy

[tomcat] branch master updated: Disable debug logging for h2

[markt]

This is an automated email from the ASF dual-hosted git repository.

markt 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 f18f7b3  Disable debug logging for h2
f18f7b3 is described below

commit f18f7b32d015d2519f66b639058fe71595305531
Author: Mark Thomas 
AuthorDate: Fri May 10 20:26:34 2019 +0100

Disable debug logging for h2
---
 conf/logging.properties | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/logging.properties b/conf/logging.properties
index fc52083..e8b7b16 100644
--- a/conf/logging.properties
+++ b/conf/logging.properties
@@ -73,7 +73,7 @@ 
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/host-manager].ha
 #org.apache.jasper.compiler.TldLocationsCache.level = FINE
 
 # To see debug messages for HTTP/2 handling, uncomment the following line:
-org.apache.coyote.http2.level = FINE
+#org.apache.coyote.http2.level = FINE
 
 # To see debug messages for WebSocket handling, uncomment the following line:
 #org.apache.tomcat.websocket.level = FINE


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [tomcat] branch master updated: Make sure timeout elapses before calling a timeout

[Mark Thomas]

On 10/05/2019 20:02, Rémy Maucherat wrote:
> On Fri, May 10, 2019 at 8:01 PM Mark Thomas  wrote:
> 
>> I've just pushed a fix. The tests seem more stable now locally but I am
>> going to keep running them. Thanks for the pointer. The issue was
>> obvious as soon as I read your email.
>>
>> Given the issue has been there for a while, unless anyone objects I am
>> going to go ahead with the releases.
>>
> 
> Excellent. Gitbox seems out of sync again [I hope nobody starts using it,
> or we'll end up running into trouble ...],

Gitbox is currently down so at least nothing can get out of sync.

> so no CI run for now, but I'm
> certain it's the right fix [it works for me locally and I could "reliably"
> reproduce the issue with "test-only" and enough runs of the 5_3 test]. My
> original hack doesn't look so bad retrospectively since it is equivalent to
> waiting for the right notify, but it's a good thing to drop weird hacks.

I still see some failures but they are genuine timeouts due to what
looks like GC pauses. I've disabled debug logging again. That might help.

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[tomcat] branch master updated: Minor fix

[remm]

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 83bd9a9  Minor fix
83bd9a9 is described below

commit 83bd9a92462b21567af5b3219e75c173e844e611
Author: remm 
AuthorDate: Fri May 10 23:57:50 2019 +0200

Minor fix

Trigger a build.
---
 res/tomcat-maven/README.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/res/tomcat-maven/README.md b/res/tomcat-maven/README.md
index f4f8ea9..411f65a 100644
--- a/res/tomcat-maven/README.md
+++ b/res/tomcat-maven/README.md
@@ -92,7 +92,7 @@ cd $JAVA_HOME/bin
 Run Tomcat with the agent in full trace mode.
 ```
 cd $TOMCAT_MAVEN
-$JAVA_HOME/bin/java 
-agentlib:native-image-agent=trace-output=./target/trace-file.json -jar 
./target/tomcat-maven-1.0.jar
+$JAVA_HOME/bin/java 
-agentlib:native-image-agent=trace-output=$TOMCAT_MAVEN/target/trace-file.json 
-jar target/tomcat-maven-1.0.jar
 ```
 Then exercise necessary paths of your service with the Tomcat configuration. 
Do not try to run any JSPs.
 


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: javax.tools based JSP compiler

[Emmanuel Bourg]

Le 09/05/2019 à 00:34, Mark Thomas a écrit :

> +1
> 
> Need to remove the @author tags and add some info on how to configure
> jasper to use them.

Ok will do.


> A few daft questions:
> 
> 1. If we used the JSR199Complier by default would that allow us to
> remove the Eclipse compiler as a dependency?

The JSR199 compiler has some drawbacks :
- It requires a full JDK (the Eclipse compiler just needs a JRE). This
will be less of an issue in the future since there is no JRE anymore
after Java 8.
- It doesn't reuse an existing classloader, it builds its classpath from
a list of files. I haven't checked if it works with non-expanded war
files, but I guess it doesn't. And it's probably slower (but that may be
negligible compared to the compilation time).
- I'm not sure about the performance, ECJ was known to be faster than
javac in the past but I don't know if it's still true today.

So no I don't think it can replace the Eclipse compiler yet.


> 2. Why would anyone use the JavacCompiler in preference to JSR199Complier?

The JSR199 compiler will indeed render the Ant based one obsolete. It'll
make javac directly usable without the Ant dependency.

Emmanuel Bourg

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[tomcat] branch master updated (83bd9a9 -> a10dcad)

[remm]

This is an automated email from the ASF dual-hosted git repository.

remm pushed a change to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git.


from 83bd9a9  Minor fix
 add a10dcad  First request !

No new revisions were added by this update.

Summary of changes:
 res/tomcat-maven/README.md  |  2 +-
 res/tomcat-maven/tomcat-reflection.json |  9 +
 res/tomcat-maven/tomcat-resource.json   | 19 +++
 3 files changed, 29 insertions(+), 1 deletion(-)
 create mode 100644 res/tomcat-maven/tomcat-resource.json


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Fwd: Apache Tomcat9 download

[Chris Lambertus]

> Begin forwarded message:
> 
> From: Marc Larouche 
> Subject: Apache Tomcat9 download
> Date: May 10, 2019 at 7:09:43 AM PDT
> To: webmas...@apache.org
> 
> The main site's download links are not working for any of the versions. Can 
> you please fix so I can get the latest update?
> thank you
> Marc
> 
> -- 
> "Do good to others not because of who they are, but because of who you are.."
> 
> Marc J Larouche - Senior IT InfoSec Specialist
> CISSP | CEHv9 | Security+ |  Secure Infrastructure Specialist | IT Operations 
> Specialist | CCNA |  MCSA 2008R2 | MCTS SQL 2008/2012 | CTT+ | Linux+ | 
> Project + | Network + | A+
> http://www.linkedin.com/in/marcjlarouche 
> 
> 
> Sir Winston Churchill,
> “Success is the ability to go from one failure to another with no loss of 
> enthusiasm.”
>