[jira] [Commented] (MTOMCAT-322) Use https upload file will fail

2021-01-12 Thread Martin Tzvetanov Grigorov (Jira) 


[ 
https://issues.apache.org/jira/browse/MTOMCAT-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17263956#comment-17263956
 ] 

Martin Tzvetanov Grigorov commented on MTOMCAT-322:
---

This exception means that the client (the browser) has closed the connection 
for some reason and the server (Tomcat) cannot consume the complete request 
body.

 

Please use [us...@tomcat.apache.org|mailto:us...@tomcat.apache.org] for more 
help.

I see nothing in this report related to the Maven plugin, so this issue should 
be closed.

> Use https upload file will fail
> ---
>
> Key: MTOMCAT-322
> URL: https://issues.apache.org/jira/browse/MTOMCAT-322
> Project: Apache Tomcat Maven Plugin
>  Issue Type: Question
>  Components: commons-lib
> Environment: apache tomcat 8.5 + java 11
>Reporter: 蔡英麟
>Assignee: Olivier Lamy
>Priority: Blocker
>
> Use Http upload file (size 38MB) is sucessfuly
> But  use HTTPS upload file is faild 
> error message:
> org.apache.catalina.connector.ClientAbortException: java.io.IOException: 
> Stream resetorg.apache.catalina.connector.ClientAbortException: 
> java.io.IOException: Stream reset at 
> org.apache.catalina.connector.InputBuffer.realReadBytes(InputBuffer.java:348) 
> at 
> org.apache.catalina.connector.InputBuffer.checkByteBufferEof(InputBuffer.java:663)
>  at org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:370) at 
> org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:183)
>  at 
> com.oreilly.servlet.multipart.BufferedServletInputStream.fill(BufferedServletInputStream.java:64)
>  at 
> com.oreilly.servlet.multipart.BufferedServletInputStream.readLine(BufferedServletInputStream.java:108)
>  at 
> com.oreilly.servlet.multipart.LimitedServletInputStream.readLine(LimitedServletInputStream.java:60)
>  at 
> com.oreilly.servlet.multipart.PartInputStream.fill(PartInputStream.java:97) 
> at 
> com.oreilly.servlet.multipart.PartInputStream.read(PartInputStream.java:195) 
> at 
> com.oreilly.servlet.multipart.PartInputStream.read(PartInputStream.java:156) 
> at com.oreilly.servlet.multipart.FilePart.write(FilePart.java:208) at 
> com.oreilly.servlet.multipart.FilePart.writeTo(FilePart.java:167) at 
> com.oreilly.servlet.MultipartRequest.(MultipartRequest.java:271) at 
> com.oreilly.servlet.MultipartRequest.(MultipartRequest.java:110) at 
> org.apache.jsp.management.upload_005ffw_005fact_jsp._jspService(upload_005ffw_005fact_jsp.java:145)
>  at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:71) at 
> javax.servlet.http.HttpServlet.service(HttpServlet.java:733) at 
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:476)
>  at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:386) 
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:330) at 
> javax.servlet.http.HttpServlet.service(HttpServlet.java:733) at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
>  at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
>  at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
>  at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
>  at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:199)
>  at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
>  at 
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:668)
>  at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139) 
> at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81) 
> at 
> org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:690)
>  at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
>  at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343) 
> at org.apache.coyote.http2.StreamProcessor.service(StreamProcessor.java:350) 
> at 
> org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
>  at org.apache.coyote.http2.StreamProcessor.process(StreamProcessor.java:69) 
> at org.apache.coyote.http2.StreamRunnable.run(StreamRunnable.java:35) at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
>  at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>  at 
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
>  at java.base/java.lang.Thread.run(Thread.java:834)Caused by: 
> java.

Re: "Missing" break in listenerStart?

2021-01-12 Thread Rémy Maucherat 
On Tue, Jan 12, 2021 at 5:49 PM Romain Manni-Bucau 
wrote:

> Hi all,
>
> I suspect it is intended but if so I wonder if it needs some toggle to
> disable that behavior: is the fact to not break when a listener (start)
> fails intended? ([1])
>
> An ASF friend hit that with 2 listeners and second one was failling after
> first one failed because it was depending on it.
>
> Since this is not uncommon I wonder if it should get a break once ok=false
> (issue can be listenerStop which should probably be independent of start
> chain behavior since some listener only impl it) or if we should have a
> flag in StandardContext to stop at first start failure.
>
> Anything already thought on it?
>

For all other subcomponents of the context, the behavior is: set ok to
false, log the error and continue. It should stay that way. However, since
a ServletContextListener is a Servlet API component, then the Servlet
specification is supposed to resolve this one way or the other, but I don't
think it does. In a similar case the language is "log and fail to deploy".
As this is application related it could be reasonable to stop there.

Rémy


>
> [1]
>
> https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/core/StandardContext.java#L4669
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>

[PROPOSAL] Change default SSLHostConfig.protocols

2021-01-12 Thread Christopher Schultz 

All,

For Tomcat 10 (only), I propose we change the default SSLHostConfig 
protocols attribute from the current "SSLv2Hello, TLSv1, TLSv1.1, 
TLSv1.2, TLSv1.3" to SSLv2Hello, TLSv1.2, TLSv1.3".


(That is, remove TLSv1 and TLSv1.1 from the default list.)

Any objections?

-chris

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

[jira] [Created] (MTOMCAT-322) Use https upload file will fail

2021-01-12 Thread Jira 
蔡英麟 created MTOMCAT-322:
---

 Summary: Use https upload file will fail
 Key: MTOMCAT-322
 URL: https://issues.apache.org/jira/browse/MTOMCAT-322
 Project: Apache Tomcat Maven Plugin
  Issue Type: Question
  Components: commons-lib
 Environment: apache tomcat 8.5 + java 11
Reporter: 蔡英麟
Assignee: Olivier Lamy


Use Http upload file (size 38MB) is sucessfuly

But  use HTTPS upload file is faild 
error message:
org.apache.catalina.connector.ClientAbortException: java.io.IOException: Stream 
resetorg.apache.catalina.connector.ClientAbortException: java.io.IOException: 
Stream reset at 
org.apache.catalina.connector.InputBuffer.realReadBytes(InputBuffer.java:348) 
at 
org.apache.catalina.connector.InputBuffer.checkByteBufferEof(InputBuffer.java:663)
 at org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:370) at 
org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:183)
 at 
com.oreilly.servlet.multipart.BufferedServletInputStream.fill(BufferedServletInputStream.java:64)
 at 
com.oreilly.servlet.multipart.BufferedServletInputStream.readLine(BufferedServletInputStream.java:108)
 at 
com.oreilly.servlet.multipart.LimitedServletInputStream.readLine(LimitedServletInputStream.java:60)
 at com.oreilly.servlet.multipart.PartInputStream.fill(PartInputStream.java:97) 
at com.oreilly.servlet.multipart.PartInputStream.read(PartInputStream.java:195) 
at com.oreilly.servlet.multipart.PartInputStream.read(PartInputStream.java:156) 
at com.oreilly.servlet.multipart.FilePart.write(FilePart.java:208) at 
com.oreilly.servlet.multipart.FilePart.writeTo(FilePart.java:167) at 
com.oreilly.servlet.MultipartRequest.(MultipartRequest.java:271) at 
com.oreilly.servlet.MultipartRequest.(MultipartRequest.java:110) at 
org.apache.jsp.management.upload_005ffw_005fact_jsp._jspService(upload_005ffw_005fact_jsp.java:145)
 at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:71) at 
javax.servlet.http.HttpServlet.service(HttpServlet.java:733) at 
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:476) 
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:386) at 
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:330) at 
javax.servlet.http.HttpServlet.service(HttpServlet.java:733) at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
 at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
 at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
 at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
 at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:199)
 at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
 at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:668)
 at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139) 
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81) 
at 
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:690)
 at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
 at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343) 
at org.apache.coyote.http2.StreamProcessor.service(StreamProcessor.java:350) at 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
 at org.apache.coyote.http2.StreamProcessor.process(StreamProcessor.java:69) at 
org.apache.coyote.http2.StreamRunnable.run(StreamRunnable.java:35) at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
 at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
 at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
 at java.base/java.lang.Thread.run(Thread.java:834)Caused by: 
java.io.IOException: Stream reset at 
org.apache.coyote.http2.Stream$StreamInputBuffer.doRead(Stream.java:1162) at 
org.apache.coyote.Request.doRead(Request.java:581) at 
org.apache.catalina.connector.InputBuffer.realReadBytes(InputBuffer.java:344) 
... 41 more



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

"Missing" break in listenerStart?

2021-01-12 Thread Romain Manni-Bucau 
Hi all,

I suspect it is intended but if so I wonder if it needs some toggle to
disable that behavior: is the fact to not break when a listener (start)
fails intended? ([1])

An ASF friend hit that with 2 listeners and second one was failling after
first one failed because it was depending on it.

Since this is not uncommon I wonder if it should get a break once ok=false
(issue can be listenerStop which should probably be independent of start
chain behavior since some listener only impl it) or if we should have a
flag in StandardContext to stop at first start failure.

Anything already thought on it?

[1]
https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/core/StandardContext.java#L4669

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book

Re: JDK 16 Early Access build 26 is now available

2021-01-12 Thread Rory O'Donnell 

Hi Mark,

Dev guys are still looking at this, not an easy fix !

One question, is this for OpenJDK 8 ?

Rgds,Rory

On 03/12/2020 08:57, Rory O'Donnell wrote:

Hi Mark,

The bug was updated, unable to reproduce , can you provide details ?

Rgds,Rory

On 30/11/2020 17:00, Rory O'Donnell wrote:

Hi Marc,

Let me see what we can do.

Rgds,Rory

On 30/11/2020 14:47, Mark Thomas wrote:

Hi Rory,

I have been (slowly) working my way through the currently open issues
and I found time time today to investigate this one:
https://urldefense.com/v3/__https://bz.apache.org/bugzilla/show_bug.cgi?id=63802__;!!GqivPVa7Brio!PccppzFjCMGwBbQzCDnWyF3kpvqgDVQZjxTwZ9Q1KyRdhCuJv1k7BsAkR2ME3DDHE2Y$ 



That led me to this OpenJDK bug:
https://bugs.openjdk.java.net/browse/JDK-8238279

I have spent some time looking at this and I can confirm that the
OpenJDK bug is present in the latest OpenJDK 8.

The issue looks to have been forgotten about. Is there anything you can
do to get the right people to have a look at it? There is a simple to
use reproduction case provided and if the bugs triggers it has very
serious consequences for Tomcat.

It would be really good to get a fix for this in Java 8.

Thanks,

Mark


On 30/11/2020 14:02, Rory O'Donnell wrote:

Thanks for the feedback Martin!

On 30/11/2020 09:37, Martin Grigorov wrote:

Hi Rory,

Apache Tomcat's build and tests pass with JDK 16 b26 on Ubuntu 
20.04.1

(x86_64 & aarch64)!

Regards,
Martin

On Fri, Nov 27, 2020 at 1:15 PM Rory O'Donnell
mailto:rory.odonn...@oracle.com>> wrote:

 Hi Mark,

 OpenJDK 16 Early Access build 26**is now available at
https://urldefense.com/v3/__http://jdk.java.net/16__;!!GqivPVa7Brio!PccppzFjCMGwBbQzCDnWyF3kpvqgDVQZjxTwZ9Q1KyRdhCuJv1k7BsAkR2MEZ3Rcy6Y$ 

 




   * These early-access , open-source builds are provided 
under the
       o GNU General Public License, version 2, with the 
Classpath

         Exception >.

   * Schedule: *JDK 16 Rampdown Phase One Starts on 2020/12/10 
[1] *


   * Features [1]: Most recent Integrations:
       o Integrated JEP 389: Foreign Linker API (Incubator)
         > with this release.
           + JEP 389 introduces an API that offers 
statically-typed,

             pure-Java access to native code.
           + This API, together with the JEP 383
             >, will considerably
             simplify the otherwise error-prone process of 
binding

to a
             native library.

 **

   * Release Notes [2]

   * Changes in recent builds that maybe of interest:
       o Build 26
           + JDK-8202343: *Disable TLS 1.0 and 1.1*
           + JDK-8251317:**Support for CLDR version 38**
           + JDK-8212879: Make JVMTI TagMap table concurrent
           + JDK-8236926: Concurrently uncommit memory in G1
           + JDK-8243559: Removed Root Certificates with 
1024-bit Keys
           + JDK-8253459: Argument index of zero or 
unrepresentable by

             int throws IllegalFormatException
           + JDK-8256643: Terminally deprecate ThreadGroup stop,
 destroy,
             isDestroyed, setDaemon and isDaemon
       o Build 25
           + JDK-8247781: Day period support added to java.time
formats
           + JDK-8202471: (ann) Cannot read type annotations on
generic
             receiver type's type variables *[**Reported by
ByteBuddy]*
           + JDK-8255947: [macos] Signed macOS jpackage app 
doesn't
             filter spurious '-psn' argument *[**Reported by 
JOSM]*

           + JDK-8256063: Module::getPackages returns the set of
 package
             names in this module

   * JDK 16 - topics of interest
       o Inside Java Episode 7 “The Vector API” with John Rose 
and

Paul
         Sandoz
           + 
https://urldefense.com/v3/__https://inside.java/2020/11/17/podcast-007/__;!!GqivPVa7Brio!PccppzFjCMGwBbQzCDnWyF3kpvqgDVQZjxTwZ9Q1KyRdhCuJv1k7BsAkR2MEtW5xauw$
 



> 



       o Biased locking Obsoletion update
           +
https://urldefense.com/v3/__https://inside.java/2020/11