Re: disable sandbox tomcat9
The README file explains how to override the systemd configuration. You can either add ReadWritePaths directives [1] to grant access to more paths, or set ProtectSystem=false [2] to disable the sandboxing completely. Emmanuel Bourg [1] https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ReadWritePaths= [2] https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectSystem= On 24/09/2020 03:15, Cristiano Albiero Berni wrote: > Hi, > > Tomcat 9 package install on Ubuntu 20.04 lts server. > I need to disable the sandbox. It's a problem when adding a new filesystem. > I need to get it NO sandboxing to all the "/" > including different filesystems. > > How could I do that? > > > Or > https://salsa.debian.org/java-team/tomcat9/blob/master/debian/README.Debian > in this link have how to override. > > How cold I add a wildcard folder. Like /home* (/home, /home02, /home03) > > > thanks a lot. > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
disable sandbox tomcat9
Hi, Tomcat 9 package install on Ubuntu 20.04 lts server. I need to disable the sandbox. It's a problem when adding a new filesystem. I need to get it NO sandboxing to all the "/" including different filesystems. How could I do that? Or https://salsa.debian.org/java-team/tomcat9/blob/master/debian/README.Debian in this link have how to override. How cold I add a wildcard folder. Like /home* (/home, /home02, /home03) thanks a lot.
Re: Low throughput with HTTP2
On 23/09/2020 15:50, Berneburg, Cris J. - US wrote: > Hi Mark > > Thanks for taking the time to explain that to me. :-) > > A few more questions, if you don't mind. > > cjb> TC thinks the stream should be closed when the client > cjb> thinks the stream is still open? Basically RST_STREAM > cjb> is a keep-alive? > > mt> No. The stream closed cleanly. The client is sending > mt> RST_STREAM due to what is suspected to be a client bug. > mt> RFC 7540 says the server must ignore such frames and can, > mt> if a frame is received a significant period after the > mt> stream closed, treat it as a protocol error (and close > mt> the connection). > > mt> Separately, the server should (as per the RFC) retain > mt> state for closed streams to support prioritisation. > > mt> Currently Tomcat uses a single Map to track the state of > mt> closed streams for priority and to identify streams have > mt> been closed for an *in*significant amount of time. > > mt> The issues immediately at hand are: > mt> - how that Map is pruned (it is currently too aggressive) > > What would you consider "less aggressive"? Not reducing the number of streams below the maximum number of concurrent streams. > Would aggressiveness depend on system load? Possibly. The less it does so, the better. But, for example, if Tomcat is processing 10k req/s just keeping track of the last 30s is potentially 300k streams. How to do that efficiently for all usage patterns is a problem that needs some thought. > mt> - that under high load a "significant period" becomes a > mt> few milliseconds > > Sounds like "significant period" varies depending on system load. At the moment there is a fairly direct inverse relationship. Ideally there should be no relationship. Not sure how achievable that is at the moment. > mt> currently memory footprint of a closed stream is much > mt> larger than it needs to be > > How could the closed stream footprint be reduced? Could the structure > holding a closed stream: > > a. Be replaced with a smaller one? Potentially. > b. De-reference other objects no longer needed? Hmm... that might lead to > NPE's and thus unnecessary null checking. Tried that. Lots of NPE regressions to the point that I reverted the change to look for a better solution. > c. Or did you already have something in mind? A form of a). I'm looking at this now. > mt> while we have all the plumbing to correctly determine > mt> relative priority and use it when allocating window > mt> updates in the case where the connection flow control > mt> window is smaller than the total data the streams want > mt> to send - we don't use it to prioritise streams when > mt> flow control windows are not an issue > > Is that an FYI or a to-do? Both. I started to look at this a while ago but it gets very complex quite quickly. It would be simpler if we were just serving static content. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Low throughput with HTTP2
Hi Mark Thanks for taking the time to explain that to me. :-) A few more questions, if you don't mind. cjb> TC thinks the stream should be closed when the client cjb> thinks the stream is still open? Basically RST_STREAM cjb> is a keep-alive? mt> No. The stream closed cleanly. The client is sending mt> RST_STREAM due to what is suspected to be a client bug. mt> RFC 7540 says the server must ignore such frames and can, mt> if a frame is received a significant period after the mt> stream closed, treat it as a protocol error (and close mt> the connection). mt> Separately, the server should (as per the RFC) retain mt> state for closed streams to support prioritisation. mt> Currently Tomcat uses a single Map to track the state of mt> closed streams for priority and to identify streams have mt> been closed for an *in*significant amount of time. mt> The issues immediately at hand are: mt> - how that Map is pruned (it is currently too aggressive) What would you consider "less aggressive"? Would aggressiveness depend on system load? mt> - that under high load a "significant period" becomes a mt> few milliseconds Sounds like "significant period" varies depending on system load. mt> currently memory footprint of a closed stream is much mt> larger than it needs to be How could the closed stream footprint be reduced? Could the structure holding a closed stream: a. Be replaced with a smaller one? b. De-reference other objects no longer needed? Hmm... that might lead to NPE's and thus unnecessary null checking. c. Or did you already have something in mind? mt> while we have all the plumbing to correctly determine mt> relative priority and use it when allocating window mt> updates in the case where the connection flow control mt> window is smaller than the total data the streams want mt> to send - we don't use it to prioritise streams when mt> flow control windows are not an issue Is that an FYI or a to-do? -- Cris Berneburg CACI Senior Software Engineer This electronic message contains information from CACI International Inc or subsidiary companies, which may be company sensitive, proprietary, privileged or otherwise protected from disclosure. The information is intended to be used solely by the recipient(s) named above. If you are not an intended recipient, be aware that any review, disclosure, copying, distribution or use of this transmission or its contents is prohibited. If you have received this transmission in error, please notify the sender immediately. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Issue in unpacking files
The response was inline: The mailing list server does not allow embedded images. Please use some image pastebin service. Or if this is plain text then better just copy/paste it. On Wed, Sep 23, 2020 at 3:35 PM Mohan T wrote: > Hi, > > I am not able to see any response in the mail received. > > Please treat the file name deployed as ems.war and not ems.wzr. > > Thanks > > Mohan > > > -Original Message- > From: Martin Grigorov > Sent: Wednesday, September 23, 2020 6:00 PM > To: Tomcat Users List > Subject: Re: Issue in unpacking files > > Warning : This is an External Email. Check reliability of sender & email > id mentioned in ; > use caution with links and attachments – IMG Team > > > > > > > Hi, > > On Wed, Sep 23, 2020 at 3:03 PM Mohan T wrote: > > > Dear All, > > > > > > > > We have two environments where in one the .war file is getting > > extracted and on the other it is not. See the below for your > > reference. The file being deployed is ems.wzr > > > > > > > > We are using apache-tomcat-8.5.35. Any pointers would be of great help. > > > > > > > > Catalinabase0 - Here it has been correctly deployed - > > > > > > > > > > > > Catalinabase1 – Here it has not been deployed correctly - > > > > > > > > > > The mailing list server does not allow embedded images. > Please use some image pastebin service. > Or if this is plain text then better just copy/paste it. > > > > > > > > > > DISCLAIMER: This communication contains information which is > > confidential and the copyright of Ramco Systems Ltd, its subsidiaries > > or a third party (“Ramco”). This email may also contain legally > privileged information. > > Confidentiality and legal privilege attached to this communication are > > not waived or lost by reason of mistaken delivery to you.This email is > > intended to be read or used by the addressee only. If you are not the > > intended recipient, any use, distribution, disclosure or copying of > > this email is strictly prohibited without the express written approval > > of Ramco. Please delete and destroy all copies and email Ramco at > > le...@ramco.com immediately. Any views expressed in this communication > > are those of the individual sender, except where the sender > > specifically states them to be the views of Ramco. Except as required > > by law, Ramco does not represent, warrant and/or guarantee that the > > integrity of this communication has been maintained nor that the > > communication is free of errors, virus, interception or interference. > > If you do not wish to receive such communications, please forward this > > communication to market...@ramco.com and express your wish not to > receive such communications henceforth. > > > DISCLAIMER: This communication contains information which is confidential > and the copyright of Ramco Systems Ltd, its subsidiaries or a third party > (“Ramco”). This email may also contain legally privileged information. > Confidentiality and legal privilege attached to this communication are not > waived or lost by reason of mistaken delivery to you.This email is intended > to be read or used by the addressee only. If you are not the intended > recipient, any use, distribution, disclosure or copying of this email is > strictly prohibited without the express written approval of Ramco. Please > delete and destroy all copies and email Ramco at le...@ramco.com > immediately. Any views expressed in this communication are those of the > individual sender, except where the sender specifically states them to be > the views of Ramco. Except as required by law, Ramco does not represent, > warrant and/or guarantee that the integrity of this communication has been > maintained nor that the communication is free of errors, virus, > interception or interference. If you do not wish to receive such > communications, please forward this communication to market...@ramco.com > and express your wish not to receive such communications henceforth. > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
RE: Issue in unpacking files
Hi, I am not able to see any response in the mail received. Please treat the file name deployed as ems.war and not ems.wzr. Thanks Mohan -Original Message- From: Martin Grigorov Sent: Wednesday, September 23, 2020 6:00 PM To: Tomcat Users List Subject: Re: Issue in unpacking files Warning : This is an External Email. Check reliability of sender & email id mentioned in ; use caution with links and attachments – IMG Team Hi, On Wed, Sep 23, 2020 at 3:03 PM Mohan T wrote: > Dear All, > > > > We have two environments where in one the .war file is getting > extracted and on the other it is not. See the below for your > reference. The file being deployed is ems.wzr > > > > We are using apache-tomcat-8.5.35. Any pointers would be of great help. > > > > Catalinabase0 - Here it has been correctly deployed - > > > > > > Catalinabase1 – Here it has not been deployed correctly - > > > > The mailing list server does not allow embedded images. Please use some image pastebin service. Or if this is plain text then better just copy/paste it. > > > > DISCLAIMER: This communication contains information which is > confidential and the copyright of Ramco Systems Ltd, its subsidiaries > or a third party (“Ramco”). This email may also contain legally privileged > information. > Confidentiality and legal privilege attached to this communication are > not waived or lost by reason of mistaken delivery to you.This email is > intended to be read or used by the addressee only. If you are not the > intended recipient, any use, distribution, disclosure or copying of > this email is strictly prohibited without the express written approval > of Ramco. Please delete and destroy all copies and email Ramco at > le...@ramco.com immediately. Any views expressed in this communication > are those of the individual sender, except where the sender > specifically states them to be the views of Ramco. Except as required > by law, Ramco does not represent, warrant and/or guarantee that the > integrity of this communication has been maintained nor that the > communication is free of errors, virus, interception or interference. > If you do not wish to receive such communications, please forward this > communication to market...@ramco.com and express your wish not to receive > such communications henceforth. > DISCLAIMER: This communication contains information which is confidential and the copyright of Ramco Systems Ltd, its subsidiaries or a third party (“Ramco”). This email may also contain legally privileged information. Confidentiality and legal privilege attached to this communication are not waived or lost by reason of mistaken delivery to you.This email is intended to be read or used by the addressee only. If you are not the intended recipient, any use, distribution, disclosure or copying of this email is strictly prohibited without the express written approval of Ramco. Please delete and destroy all copies and email Ramco at le...@ramco.com immediately. Any views expressed in this communication are those of the individual sender, except where the sender specifically states them to be the views of Ramco. Except as required by law, Ramco does not represent, warrant and/or guarantee that the integrity of this communication has been maintained nor that the communication is free of errors, virus, interception or interference. If you do not wish to receive such communications, please forward this communication to market...@ramco.com and express your wish not to receive such communications henceforth. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Issue in unpacking files
Hi, On Wed, Sep 23, 2020 at 3:03 PM Mohan T wrote: > Dear All, > > > > We have two environments where in one the .war file is getting extracted > and on the other it is not. See the below for your reference. The file > being deployed is ems.wzr > > > > We are using apache-tomcat-8.5.35. Any pointers would be of great help. > > > > Catalinabase0 - Here it has been correctly deployed - > > > > > > Catalinabase1 – Here it has not been deployed correctly - > > > > The mailing list server does not allow embedded images. Please use some image pastebin service. Or if this is plain text then better just copy/paste it. > > > > DISCLAIMER: This communication contains information which is confidential > and the copyright of Ramco Systems Ltd, its subsidiaries or a third party > (“Ramco”). This email may also contain legally privileged information. > Confidentiality and legal privilege attached to this communication are not > waived or lost by reason of mistaken delivery to you.This email is intended > to be read or used by the addressee only. If you are not the intended > recipient, any use, distribution, disclosure or copying of this email is > strictly prohibited without the express written approval of Ramco. Please > delete and destroy all copies and email Ramco at le...@ramco.com > immediately. Any views expressed in this communication are those of the > individual sender, except where the sender specifically states them to be > the views of Ramco. Except as required by law, Ramco does not represent, > warrant and/or guarantee that the integrity of this communication has been > maintained nor that the communication is free of errors, virus, > interception or interference. If you do not wish to receive such > communications, please forward this communication to market...@ramco.com > and express your wish not to receive such communications henceforth. >
Issue in unpacking files
Dear All,
We have two environments where in one the .war file is getting extracted and on
the other it is not. See the below for your reference. The file being deployed
is ems.wzr
We are using apache-tomcat-8.5.35. Any pointers would be of great help.
Catalinabase0 - Here it has been correctly deployed -
[cid:image001.png@01D691CF.3AD650B0]
[cid:image002.png@01D691CF.3AD650B0]
Catalinabase1 - Here it has not been deployed correctly -
[cid:image003.png@01D691CF.3AD650B0]
[cid:image004.png@01D691CF.3AD650B0]
DISCLAIMER: This communication contains information which is confidential and
the copyright of Ramco Systems Ltd, its subsidiaries or a third party
("Ramco"). This email may also contain legally privileged information.
Confidentiality and legal privilege attached to this communication are not
waived or lost by reason of mistaken delivery to you.This email is intended to
be read or used by the addressee only. If you are not the intended recipient,
any use, distribution, disclosure or copying of this email is strictly
prohibited without the express written approval of Ramco. Please delete and
destroy all copies and email Ramco at le...@ramco.com immediately. Any views
expressed in this communication are those of the individual sender, except
where the sender specifically states them to be the views of Ramco. Except as
required by law, Ramco does not represent, warrant and/or guarantee that the
integrity of this communication has been maintained nor that the communication
is free of errors, virus, interception or interference. If you do not wish to
receive such communications, please forward this communication to
market...@ramco.com and express your wish not to receive such communications
henceforth.
Re: Request for a tip with NoClassDefFoundError
NoClassDefFoundError means that the class in question threw an exception
during its static initialisation phase. Then later on whenever some code
tries to access the class statically or create an instance the JVM will
throw a NoClassDefFoundError. This is not the same as a class not found
which relates to classloading issues.
To debug a NoClassDefFoundError, look at the logs when the class was first
used and see if it threw an error initialising. Also look at the source of
the class and see if any static blocks or static variables could fail e.g.:
public class MyClass {
private static String someString = doSomething();
private static String doSomething() {
// access some server . If network is down an exception would be thrown
throw new RuntimeException();
}
}
The above code would cause a NoClassDefFoundError whenever someone tries to
use MyClass.
Paul
On Wed, Sep 23, 2020 at 10:00 AM Michal Rysavy wrote:
> Hello,
>
> I would like to ask for any tips that can help us to solve the problem with
> NoClassDefFoundError.
>
> We have a specific problem with an application (Documentum) on Tomcat
> (running as a container on OpenShift). Sometimes we have many
> NoClassDefFoundError on classes that are loaded via network from the
> backend application.
> The biggest problem is that an error is unpredictable, it occurs only when
> starting an application under high load and not always. Sometimes there are
> few occurrences and sometimes there are thousands occurrences and sometimes
> nothing (during the same load).
> But we can't repeat the problem in a non-production environment, even with
> the same or higher load of performance tests. More precisely, we had this
> error on non-prod several times, but with negligible occurrence, randomly
> and with different application configuration only that is not suitable for
> production.
>
> Class reported with NoClassDefFoundError is not always the same, but always
> this class can be found in the appropriate jar file in the application
> cache of received jars. When we had classloader verbose enabled, I think
> that we saw that the class was loaded (but we must recheck this). More
> precisely, at the same time the problematic class (stated as
> NoClassDefFoundError) is the same, but after the next restart under high
> load there is another problematic class.
>
> We are running Tomcat 9.0.29 on OpenJDK Runtime Environment (build
> 1.8.0_222-b10) - with almost the default configuration.
> We are planning a Tomcat & Java update but now we can't test it before
> production, because we can't reproduce this error on the non-prod.
>
> So I would like to ask if there are some tuning tips that we can try for a)
> prevention of occurrence in production and b) ensuring occurence in
> non-production
>
> Many thanks for any tips.
>
> Kind Regards,
> Michal Rysavy
>
> Some examples of occurence (other occurrences have another classes as
> NoClassDefFoundError / ClassNotFoundException):
>
> EXAMPLE 1/4
> ===
> com.emc.documentum.fs.rt.ServiceException:
> com/fasterxml/jackson/databind/deser/std/FactoryBasedEnumDeserializer.
> com.fasterxml.jackson.databind.deser.std.FactoryBasedEnumDeserializer
> at
> com.ness.documentum.csas.ws
> .v01.recordservice.CsRecordServiceWebService.esSearchRecord(CsRecordServiceWebService.java:662)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
>
> com.sun.xml.ws.api.server.InstanceResolver$1.invoke(InstanceResolver.java:246)
> at com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:146)
> at
>
> com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:257)
> at
>
> com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:93)
> at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:598)
> at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:557)
> at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:542)
> at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:439)
> at
> com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:243)
> at
>
> com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:471)
> at
> com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:244)
> at
>
> com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:135)
> at
>
> com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doGet(WSServletDelegate.java:129)
> at
>
> com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doPost(WSServletDelegate.java:160)
> at
> com.sun.xml.ws.transport.http.servlet.WSServlet.doPost(WSServlet.java:75)
> at j
Request for a tip with NoClassDefFoundError
Hello, I would like to ask for any tips that can help us to solve the problem with NoClassDefFoundError. We have a specific problem with an application (Documentum) on Tomcat (running as a container on OpenShift). Sometimes we have many NoClassDefFoundError on classes that are loaded via network from the backend application. The biggest problem is that an error is unpredictable, it occurs only when starting an application under high load and not always. Sometimes there are few occurrences and sometimes there are thousands occurrences and sometimes nothing (during the same load). But we can't repeat the problem in a non-production environment, even with the same or higher load of performance tests. More precisely, we had this error on non-prod several times, but with negligible occurrence, randomly and with different application configuration only that is not suitable for production. Class reported with NoClassDefFoundError is not always the same, but always this class can be found in the appropriate jar file in the application cache of received jars. When we had classloader verbose enabled, I think that we saw that the class was loaded (but we must recheck this). More precisely, at the same time the problematic class (stated as NoClassDefFoundError) is the same, but after the next restart under high load there is another problematic class. We are running Tomcat 9.0.29 on OpenJDK Runtime Environment (build 1.8.0_222-b10) - with almost the default configuration. We are planning a Tomcat & Java update but now we can't test it before production, because we can't reproduce this error on the non-prod. So I would like to ask if there are some tuning tips that we can try for a) prevention of occurrence in production and b) ensuring occurence in non-production Many thanks for any tips. Kind Regards, Michal Rysavy Some examples of occurence (other occurrences have another classes as NoClassDefFoundError / ClassNotFoundException): EXAMPLE 1/4 === com.emc.documentum.fs.rt.ServiceException: com/fasterxml/jackson/databind/deser/std/FactoryBasedEnumDeserializer. com.fasterxml.jackson.databind.deser.std.FactoryBasedEnumDeserializer at com.ness.documentum.csas.ws.v01.recordservice.CsRecordServiceWebService.esSearchRecord(CsRecordServiceWebService.java:662) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.sun.xml.ws.api.server.InstanceResolver$1.invoke(InstanceResolver.java:246) at com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:146) at com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:257) at com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:93) at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:598) at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:557) at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:542) at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:439) at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:243) at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:471) at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:244) at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:135) at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doGet(WSServletDelegate.java:129) at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doPost(WSServletDelegate.java:160) at com.sun.xml.ws.transport.http.servlet.WSServlet.doPost(WSServlet.java:75) at javax.servlet.http.HttpServlet.service(HttpServlet.java:660) at javax.servlet.http.HttpServlet.service(HttpServlet.java:741) 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:53) 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:202) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:526) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92) at o
Re: Low throughput with HTTP2
Hi, I've debugged further with Wireshark: 1) Golang: https://pasteboard.co/Jsnvx1z.png (SETTINGS, HEADERS+DATA) 2) Nodejs: https://pasteboard.co/JsnwRNV.png (SETTINGS, HEADERS+PARTIAL DATA, DATA) 3) Rust: https://pasteboard.co/JsnxvKGU.png (SETTINGS, HEADERS+PARTIAL DATA+DATA) 4) Netty: https://pasteboard.co/JsnxYJp.png (SETTINGS+HEADERS+DATA) 5) Tomcat: https://pasteboard.co/JsnyjpA.png (SETTINGS, HEADERS, DATA) >From the images above you can see that only Tomcat sends two separate packets for HEADERS and DATA frames. All others put several frames into one packet. Netty puts the SETTINGS, the HEADERS and the DATA into one TCP packet. I guess this is the reason for the high throughput Node.js writes the HEADERS and PARTIAL DATA in one packet and the actual DATA in a separate one Rust also uses PARTIAL DATA but puts the actual one in the same TCP packet Tomcat's way is spec compliant but most probably is also a reason for the lower throughput. More findings: I've debugged Netty code and it never receives RST_STREAM with CANCEL error at https://github.com/martin-g/http2-server-perf-tests/blob/2f628c407e2ea29be99e756a61e555d88addaa01/java/netty-http2-test/src/main/java/com/example/netty/http2/Http2ServerResponseHandler.java#L30 I've looked at Golang net code and found that it will send RST_STREAM with CANCEL if there is a problem reading the body: https://github.com/tsenart/vegeta/issues/540#issuecomment-696757695 It is not clear to me whether this is about the request body or response body. But since the unit test uses Transport.RoundTrip() I think it is about the response body. So, it looks like Tomcat sends a DATA frame which is not liked by Golang net package code and Golang sends this CANCEL error that causes the problems. The DATA frames in Wireshark look good to me, but I've made them by using Firefox as a client to be able to decrypt TLS in Wireshark (SSLKEYLOGFILE) Martin
