RE: Weirdest Tomcat Behavior Ever?
> -Original Message- > From: Christopher Schultz > Sent: Wednesday, December 2, 2020 10:21 AM > To: users@tomcat.apache.org > Subject: Re: Weirdest Tomcat Behavior Ever? > > Mark, > > On 11/26/20 05:14, Mark Thomas wrote: > > On 26/11/2020 04:57, Christopher Schultz wrote: > > > > > > > >>> After a normal clean-up the parent then calls close on the two file > >>> descriptors associated with the pipe for a second time." > >> > >> So the child cleans them up AND the parent cleans them up? Or the > >> parent cleans when up twice? The child should be able to call close() > >> as many times as it wants and only poison itself. Does the child > >> process ever exit()? > > > > With the caveat that some of the below is educated guess work because > > the strace was configured to look at the events we were interested in > > so I am having to fill in some of the gaps. > > > > The parent "process" is a Java thread currently in native code in a > > 3rd party library. > > > > The parent creates a pipe which comes with two file descriptors. One > > for the read end, one for the write end. > > > > The parent process then forks. The child process now has copies of the > > two file descriptors. (see man fork for more details). > > > > The parent closes its fd for the write end of the pipe. The child > > closes its fd for the read end of the pipe. > > > > The child writes to the pipe and the parent reads from it. > > > > The child exits and closes its fd for the write end of the pipe. > > > > The parent closes its fd for the read end of the pipe. > > > > At this point all is good. All the closes completely cleanly. > > Everything has been shutdown properly. > > +1 > > > The two fds allocated to the parent are back in the pool any may be > > reused by other threads in the JVM. > > > > The parent then attempts to close the fds associated with the pipe > > again. For each fd, if it has not been reallocated an EBADF error > > occurs. If it has been reallocated, it is closed thereby breaking > > whatever was using it legitimately. > > Thanks for clarifying this. I was confused and thinking you were saying that > the child process was the one breaking things, but it's the parent process. > Since the parent is the JVM (the long-running process), all hell breaks loose. > > >> The parent process must be the JVM process, right? And the parent > >> process (this native library, running within the JVM process) > >> double-closes file descriptors, with some measurable delay? > > > > Correct. In the instance where I did most of the log analysis the > > delay was about 0.1 seconds. In other logs I did observe longer delays > > with what looked like a very different failure mode. > > > >> That's the > >> only way this could make sense. And of course it mess mess everything > >> up in really *really* unpredictable ways. > > > > Yep. > > Fascinating. > > Thanks for the wild ride, Eric and Mark :) > > -chris > I case anyone thought I had forgotten about all this... sorry, no such luck. You’re stuck with me! Things have been quieter for the past several days because, at Mark's suggestion, we changed the nginx proxy and tomcat configurations to make them more tolerant of the underlying condition. Specifically, we configured nginx to use HTTP/1.1 instead of 1.0, enabled keepalives, and set maxKeepAliveRequests="-1" in server.xml. This reduced the frequency of the issue. The vendor was unable to dispute the quality of the analysis, so they accepted that the third-party component (which I can now name: PDFTron) could be the root cause. They disabled use of the component, and that seems to have quieting things down a bit more. We are still seeing occasional session disconnects, so it is possible that the component is leveraged for more than one function in their software and it was only disabled for a subset of them. The big difference now is that, instead of seeing a GET request from the proxy followed by a FIN from the upstream, now it’s a GET followed by an RST. We'll begin the packet captures and straces again on Monday. Mark, besides network and fd tracing, is there anything else you want from strace to make the analysis more certain? -Eric Disclaimer : This email and any files transmitted with it are confidential and intended solely for intended recipients. If you are not the named addressee you should not disseminate, distribute, copy or alter this email. Any views or opinions presented in this email are solely those of the author and might not represent those of Physician Select Management. Warning: Although Physician Select Management has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail:
Re: [EXTERNAL] Re: Can Tomcat 9 be FIPS compliant without OpenSSL?
George, On 12/4/20 14:22, George Stanchev wrote: -Original Message- From: Christopher Schultz Sent: Friday, December 04, 2020 10:58 AM To: users@tomcat.apache.org Subject: Re: [EXTERNAL] Re: Can Tomcat 9 be FIPS compliant without OpenSSL? George, On 12/3/20 21:59, George Stanchev wrote: Java's FIPS mode is "expirmental" feature that was removed in later Java versions. It was never certified (AFAIK). I've always found conflicting information about whether or not Java's crypto module was FIPS-certified or not. Sun/Oracle have documentation which suggests that, at least under some configurations, it IS certified, but there is precious little information about it. I suspect you can pay Oracle to give you the magic that makes it certified. I've never cared enough about it to actually try to find it out. I find FIPS to be a useless requirement that doesn't add any security beyond what usual best-practices would give you. But I don't do work in intelligence or military applications, so I'm allowed to thumb my nose at such things. GS: IBM's JCE is FIPS-certified but not Oracle's. Also, we should make a distinction between "certified" and "compliant". Yes, thanks for pointing that out. Certification is obtained by a long and laborious process by NIST. Compliancy is mainly self reporting. Look here https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8217911 for Oracle removing the "compliant" mode in Java 13. If you read through the task, you will see it states "Legacy applications might have used the experimental mode...". Me and you can have our opinions about FIPS, but the reality is that if you want to sell to government entities (and even some commercial entities) you really need FIPS support in your product. Sadly, yes. With the pluggability of Java's crypto interface, I seriously doubt Oracle is going to certify a JCE module in the future, esp. with free 3rd party solutions such as BCFIPS. Is BC actually certified? It seems unlikely to me that a group of volunteers from Australia are going to bother to go through that module-certification process. To me the only two viable options are via APR+OpenSSL 1.0.1/FIPS and BCFIPS. NIO+JSSE/OpenSSL ought to be okay, theoretically. The "AprLifecycleListener" is a misnomer; it really should be the "TcnativeLivecycleListener". You can use it to configure OpenSSL into FIPS mode and still use NIO+OpenSSL as your connector. > > GS: You are right, I might have misspoken by saying "APR". What I really meant is you need to have OpenSSL as in tcnative. The problem I faced back in the days was that the prebuilt binaries come with regular, non-FIPS OpenSSL and despite my long efforts I was never able to build it successfully and fully on Windows x64. Oh. You're on Windows. You're right, that will suck. The binaries packaged by ASF are definitely not going to be FIPS-certified. You'll have to build your own and then dynamically-link it to tcnative during the build. I found it non-trivial and the toolsets to be very specific, and even after following all instructions from several wikis and web pages I kept running into issues resulting in overall failure. Yes, the build process for OpenSSL is horrible. I have no idea why they decided to use Perl as their build system. On Windows? I have only tried to build the OpenSSL binary, not the FIPS-compliant module. Having done it on Linux (where it's "easy") I can say I'm glad I'm not responsible for doing it on Windows. Also, keep in mind that OpenSSL 1.0.1 is EOLed and the FIPS module is only available for that version line. OpenSSL still produces security fixes to paid support subscribers (we are) but they are not available for the general public. OpenSSL 3.0 will have a refreshed re-certified FIPS module but it is not due until later next year, so for now general public is left hanging with the last public version of 1.0.1+FIPS. :( This is why we can't have nice things. We have implemented the later and have ran into issues with RSA keys. First the C# BCPROV doesn't support 4096 bit RSA keys What? It's like the most popular configuration in the world right now. I know you can read more about it here: https://github.com/bcgit/bc-java/issues/616 See... this is why I say that FIPS is sometimes bad: they specifically disallow large keys. And that's ... more secure? *Sigh* (I know weird, but our config app is C# and we use BCFIPS/C# there) but that's OK, you can use Windows CNG or CAPI but of course you have to put the whole Windows in FIPS which is not prarctical all the time. > But second, and most important BCFIPS implements stricter FIPS requirement that an RSA key cannot be used for both encipherment and signature and BCFIPS really tracks the usage. That's appropriate, actually. What's the problem, there? GS: See my next comment with a link to technical explanation This, combined with the fact that Tomcat (8.5.someting about an year ago) doesn't really
RE: [EXTERNAL] Re: Can Tomcat 9 be FIPS compliant without OpenSSL?
-Original Message- From: Christopher Schultz Sent: Friday, December 04, 2020 10:58 AM To: users@tomcat.apache.org Subject: Re: [EXTERNAL] Re: Can Tomcat 9 be FIPS compliant without OpenSSL? George, On 12/3/20 21:59, George Stanchev wrote: > Java's FIPS mode is "expirmental" feature that was removed in later > Java versions. It was never certified (AFAIK). I've always found conflicting information about whether or not Java's crypto module was FIPS-certified or not. Sun/Oracle have documentation which suggests that, at least under some configurations, it IS certified, but there is precious little information about it. I suspect you can pay Oracle to give you the magic that makes it certified. I've never cared enough about it to actually try to find it out. I find FIPS to be a useless requirement that doesn't add any security beyond what usual best-practices would give you. But I don't do work in intelligence or military applications, so I'm allowed to thumb my nose at such things. GS: IBM's JCE is FIPS-certified but not Oracle's. Also, we should make a distinction between "certified" and "compliant". Certification is obtained by a long and laborious process by NIST. Compliancy is mainly self reporting. Look here https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8217911 for Oracle removing the "compliant" mode in Java 13. If you read through the task, you will see it states "Legacy applications might have used the experimental mode...". Me and you can have our opinions about FIPS, but the reality is that if you want to sell to government entities (and even some commercial entities) you really need FIPS support in your product. With the pluggability of Java's crypto interface, I seriously doubt Oracle is going to certify a JCE module in the future, esp. with free 3rd party solutions such as BCFIPS. > To me the only two viable options are via APR+OpenSSL 1.0.1/FIPS and BCFIPS. NIO+JSSE/OpenSSL ought to be okay, theoretically. The "AprLifecycleListener" is a misnomer; it really should be the "TcnativeLivecycleListener". You can use it to configure OpenSSL into FIPS mode and still use NIO+OpenSSL as your connector. GS: You are right, I might have misspoken by saying "APR". What I really meant is you need to have OpenSSL as in tcnative. The problem I faced back in the days was that the prebuilt binaries come with regular, non-FIPS OpenSSL and despite my long efforts I was never able to build it successfully and fully on Windows x64. I found it non-trivial and the toolsets to be very specific, and even after following all instructions from several wikis and web pages I kept running into issues resulting in overall failure. Also, keep in mind that OpenSSL 1.0.1 is EOLed and the FIPS module is only available for that version line. OpenSSL still produces security fixes to paid support subscribers (we are) but they are not available for the general public. OpenSSL 3.0 will have a refreshed re-certified FIPS module but it is not due until later next year, so for now general public is left hanging with the last public version of 1.0.1+FIPS. > We have implemented the later and have ran into issues with RSA keys. > First the C# BCPROV doesn't support 4096 bit RSA keys What? It's like the most popular configuration in the world right now. I know you can read more about it here: https://github.com/bcgit/bc-java/issues/616 > (I know weird, but our config app is C# and we use BCFIPS/C# there) > but that's OK, you can use Windows CNG or CAPI but of course you have > to put the whole Windows in FIPS which is not prarctical all the time. > > > > But second, and most important BCFIPS implements stricter FIPS > requirement that an RSA key cannot be used for both encipherment and > signature and BCFIPS really tracks the usage. That's appropriate, actually. What's the problem, there? GS: See my next comment with a link to technical explanation > This, combined with the fact that Tomcat (8.5.someting about an year > ago) doesn't really support multiple keys for SSL that can be > dynamically selected really leaves you with only DSA key. I'm curious what version that is, because Tomcat will definitely select the appropriate certificate from a set of RSA/DSA/ECDSA-based certs. GS: http://mail-archives.apache.org/mod_mbox/tomcat-users/201911.mbox/%3caa01aac6-fa82-a100-3d37-26b3521cb...@apache.org%3E GS: I never had a time to formalize the patch, to submit a BZ and attach it, which is a shame. I should perhaps do this > Now, BC does support a system property to disable this FIPS > requirement but now you are not FIPS compliant, strictly speaking. Well... FIPS is all about strictness. You can certainly use the OpenSSL FIPS module without entering FIPS mode, but, well, then you aren't actually using the FIPS module, then, are you. " Man: We have the most sophisticated door-locks money can buy! Woman: Who has access to the keys? Man: It's super secure!
Re: [EXTERNAL] Re: Can Tomcat 9 be FIPS compliant without OpenSSL?
George, On 12/3/20 21:59, George Stanchev wrote: Java's FIPS mode is "expirmental" feature that was removed in later Java versions. It was never certified (AFAIK). I've always found conflicting information about whether or not Java's crypto module was FIPS-certified or not. Sun/Oracle have documentation which suggests that, at least under some configurations, it IS certified, but there is precious little information about it. I suspect you can pay Oracle to give you the magic that makes it certified. I've never cared enough about it to actually try to find it out. I find FIPS to be a useless requirement that doesn't add any security beyond what usual best-practices would give you. But I don't do work in intelligence or military applications, so I'm allowed to thumb my nose at such things. To me the only two viable options are via APR+OpenSSL 1.0.1/FIPS and BCFIPS. NIO+JSSE/OpenSSL ought to be okay, theoretically. The "AprLifecycleListener" is a misnomer; it really should be the "TcnativeLivecycleListener". You can use it to configure OpenSSL into FIPS mode and still use NIO+OpenSSL as your connector. We have implemented the later and have ran into issues with RSA keys. First the C# BCPROV doesn't support 4096 bit RSA keys What? It's like the most popular configuration in the world right now. (I know weird, but our config app is C# and we use BCFIPS/C# there) but that's OK, you can use Windows CNG or CAPI but of course you have to put the whole Windows in FIPS which is not prarctical all the time. > > But second, and most important BCFIPS implements stricter FIPS requirement that an RSA key cannot be used for both encipherment and signature and BCFIPS really tracks the usage. That's appropriate, actually. What's the problem, there? This, combined with the fact that Tomcat (8.5.someting about an year ago) doesn't really support multiple keys for SSL that can be dynamically selected really leaves you with only DSA key. I'm curious what version that is, because Tomcat will definitely select the appropriate certificate from a set of RSA/DSA/ECDSA-based certs. Now, BC does support a system property to disable this FIPS requirement but now you are not FIPS compliant, strictly speaking. Well... FIPS is all about strictness. You can certainly use the OpenSSL FIPS module without entering FIPS mode, but, well, then you aren't actually using the FIPS module, then, are you. " Man: We have the most sophisticated door-locks money can buy! Woman: Who has access to the keys? Man: It's super secure! Nobody has access to the the keys because we never engage the locks! " Which, as FIPS-compliancy goes, might or might not be a problem as it is really a self-reporting. Also, no way to get PKCS12 keystores in FIPS mode so you're stuck with BCKFS or PEMs. I didn't realize tat PKCS12 doesn't work in FIPS mode. Why not? Thanks, -chris -Original Message- From: Amit Pande Sent: Tuesday, November 24, 2020 9:31 AM To: Tomcat Users List ; Avik Ray Subject: RE: [EXTERNAL] Re: Can Tomcat 9 be FIPS compliant without OpenSSL? Avik, Did you happen to try out the steps in README https://github.com/amitlpande/tomcat-9-fips here? I am looking for feedback from the community before I could add these steps (and some more) on Tomcat Security FAQ page. So, really appreciate your (and others') feedback. The steps above rely purely on JSSE and JCA/JCE providers, no OpenSSL use. These steps will enable a plain vanilla Tomcat to run in FIPS compliant mode. And as Chris mentioned below, we need to ensure any web app deployed within the Tomcat use FIPS compliant constructs. Thanks, Amit -Original Message- From: Christopher Schultz Sent: Friday, November 6, 2020 3:40 PM To: Tomcat Users List ; Avik Ray Subject: [EXTERNAL] Re: Can Tomcat 9 be FIPS compliant without OpenSSL? Avik, On 11/6/20 14:50, Avik Ray wrote: Thanks a lot Anil for the detailed readme, and Martin for pointing me to it. We have done most of these configs. Are these steps sufficient to ensure that all incoming and outgoing TLS connections are FIPS compliant? This isn't something that the Tomcat community can really comment on. If you have a requirement to be FIPS-compliant, then you will need to evaluate whether of not you have met that requirement yourself. Or is there also a need to compile an APR connector with an underlying implementation of openssl? You do not NEED to do this, but it is a possibility that will allow you to definitely put the crypto engine into "FIPS mode". Is the APR approach just an alternative to the JSSE approach covered in Anil's readme, and both hold equally good to be FIPS compliant? Theoretically, yes. It's also possible, I believe, to make The Sun/Oracle JSSE provider FIPS compliant. Hmm maybe not: https://stackoverflow.com/a/5047855/276232 (FYI Stephen Colebourne tends to know what he's talking about.) It's a little unclear to me whether or not this is
Re: embedded tomcat and context.xml
Rob, On 12/3/20 17:46, Rob Sargent wrote: Again, much appreciated feedback. (I never think what I'm doing is all that special) At this point, the fact that you are using embedded Tomcat is really just a detail that doesn't affect the greater question of how to manage your complex database pooling needs. Though two concurrent users would really be "wildly successful", each of those users will fire up hundreds (thousands if we get permission/capacity) of EC2 instances and start pounding the db, so I think connection pooling is in order. What do those EC2 instances actually do? Do they connect to your application (which connects to the db), or do they connect directly to the db? I contemplated managing my own pools but didn't want - the hassle of resetting the "search_path" for each connection if I used a single (initial) user (if I stuck with the tomcat pooler) - the overhead in terms of both my own code and actual resource consumption(minimum connection held etc) I would highly recommend that you abstract this away from your application with some kind of utility method like: public Connection getConnection(whatever args you need); Then you can change that method to do whatever is necessary. Maybe it's determine which pool to use, and use it. Maybe it's create a new connection every single time. Maybe it's a mixture of the two. so I switched to the dbcp2 PerUserPoolDataSourceFactory in the hope that the lookup for an available connection happens after I reset the user/db I think Phil said that doesn't work. You can call getConnection(username,password) but it won't pool those connections. I haven't read the code, but I suspect that is what happens. If you need to switch *databases*, there really is no way to do that. Besides, you'd never want to restrict yourself to using the *same* database connection(s) for more than one database, would you? You'd never be able to separate the databases onto separate servers, clusters, etc. I seem to recall that tomcat-pool can actually do this, but maybe it just implements the API and also just hands you a fresh connection every time with your username and password. (i.e. not actually pooling). (Recall that with postgres a db is just part of the same physical server, of which there will be only one and for me a user is associated with only one database.) Maybe you want to consider a multi-tenant database (tablespace/schema/etc.) instead of having a distinct one for each customer. Another option would be to spin-up a separate application (instance) for each customer, each with its own one-and-only-one db connection pool. Really great to hear that lookup() is not my biggest concern;) ;) -chris On 12/3/20 3:18 PM, Christopher Schultz wrote: Rob, On 12/3/20 11:03, Rob Sargent wrote: Thanks for you time. Your response goes a long way to explaining why there is so little specific information on embedding tomcat. Only programmers are interested in using embedded Tomcat, so having "Tomcat Embedded For Dummies" isn't terribly useful. (I don't mean to be insulting; I'm just trying to get my point across about "intro-level" content regarding Tomcat as an embedded product.) Embedding Tomcat into a product is done precisely because the standard deployment model (which lends itself to system admins who don't really need to know anything about Java programming) isn't sufficient for some special-case. Indeed, every Tomcat embedded instance is by definition a special-case so guides for "doing it" don't exist since nobody else knows exactly what you are trying to do. Really, just as I said. I had convinced myself from several items encountered on the web that an embedded tomcat instance would not read the standard conf/*.xml. If I hit any of those pages again I will react (either on the page or perhaps post here, if that would be appropriate). The best references for behavior of the Tomcat class would be: 1. The Tomcat javadoc and 2. The source code for the Tomcat class It's fairly readable, but most everything you need to read is in the Javadoc. TL/DR: at heart I’m struggling with the proper initialization and consumption of the dbpc2 datasource which I add programmatically and might consider using the context.xml version. Unless there is a particularly good reason not to use it, I would recommend using META-INF/context.xml. There are some really great reasons not to do that. For example, if you want to fetch your DBCP configuration from Kubernetes and then use that to dynamically-configure DBCP, then you'll probably have to forego XML-based configuration. A litany of small issues: > My @Resource(name, type) Datasource ds” doesn’t take (I have several more attempts planned) Ooh. I tend to avoid @Annotations and I'm not really sure how that one works, anyway. I'm not a good resource, here. Is that failure logged? Dunno. Is context.lookup() expensive? No. Tomcat's
Re: Examples failing
On Fri, Dec 4, 2020 at 2:05 PM Ibone Gonzalez Mauraza wrote: > Hi, > > The examples of async of the newest versions are failing. > This is fixed already: https://github.com/apache/tomcat/commit/0b5d5c91bafd3f61938917490ab531474dbb778a Rémy > When I try to run the test, I got the following error: > > tomcat_1 | 04-Dec-2020 12:36:55.183 WARNING [http-nio-8080-exec-6] > org.apache.catalina.connector.Request.startAsync Unable to start async > because the following classes in the processing chain do not support async > [org.apache.catalina.filters.HttpHeaderSecurityFilter] > tomcat_1 | java.lang.IllegalStateException: A filter or servlet of the > current chain does not support asynchronous operations. > tomcat_1 | at > org.apache.catalina.connector.Request.startAsync(Request.java:1696) > tomcat_1 | at > org.apache.catalina.connector.Request.startAsync(Request.java:1689) > tomcat_1 | at > org.apache.catalina.connector.RequestFacade.startAsync(RequestFacade.java:1031) > tomcat_1 | at async.Async0.service(Async0.java:48) > tomcat_1 | at javax.servlet.http.HttpServlet.service(HttpServlet.java:733) > tomcat_1 | at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231) > tomcat_1 | at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) > tomcat_1 | at > org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) > tomcat_1 | at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) > tomcat_1 | at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) > tomcat_1 | at > org.apache.catalina.filters.HttpHeaderSecurityFilter.doFilter(HttpHeaderSecurityFilter.java:126) > tomcat_1 | at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) > tomcat_1 | at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) > tomcat_1 | at > org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:109) > tomcat_1 | at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) > tomcat_1 | at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) > tomcat_1 | at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:199) > tomcat_1 | at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:97) > tomcat_1 | at > org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:544) > tomcat_1 | at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:143) > tomcat_1 | at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81) > tomcat_1 | at > org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:690) > tomcat_1 | at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:78) > tomcat_1 | at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343) > tomcat_1 | at > org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:616) > tomcat_1 | at > org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65) > tomcat_1 | at > org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:831) > tomcat_1 | at org.apache.tomcat.util.net > .NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1634) > tomcat_1 | at org.apache.tomcat.util.net > .SocketProcessorBase.run(SocketProcessorBase.java:49) > tomcat_1 | at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > tomcat_1 | at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > tomcat_1 | at > org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) > tomcat_1 | at java.base/java.lang.Thread.run(Thread.java:834) > > Regards, > Ibone. > >
Examples failing
Hi, The examples of async of the newest versions are failing. When I try to run the test, I got the following error: tomcat_1 | 04-Dec-2020 12:36:55.183 WARNING [http-nio-8080-exec-6] org.apache.catalina.connector.Request.startAsync Unable to start async because the following classes in the processing chain do not support async [org.apache.catalina.filters.HttpHeaderSecurityFilter] tomcat_1 | java.lang.IllegalStateException: A filter or servlet of the current chain does not support asynchronous operations. tomcat_1 | at org.apache.catalina.connector.Request.startAsync(Request.java:1696) tomcat_1 | at org.apache.catalina.connector.Request.startAsync(Request.java:1689) tomcat_1 | at org.apache.catalina.connector.RequestFacade.startAsync(RequestFacade.java:1031) tomcat_1 | at async.Async0.service(Async0.java:48) tomcat_1 | at javax.servlet.http.HttpServlet.service(HttpServlet.java:733) tomcat_1 | at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231) tomcat_1 | at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) tomcat_1 | at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) tomcat_1 | at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) tomcat_1 | at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) tomcat_1 | at org.apache.catalina.filters.HttpHeaderSecurityFilter.doFilter(HttpHeaderSecurityFilter.java:126) tomcat_1 | at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) tomcat_1 | at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) tomcat_1 | at org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:109) tomcat_1 | at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) tomcat_1 | at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) tomcat_1 | at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:199) tomcat_1 | at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:97) tomcat_1 | at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:544) tomcat_1 | at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:143) tomcat_1 | at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81) tomcat_1 | at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:690) tomcat_1 | at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:78) tomcat_1 | at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343) tomcat_1 | at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:616) tomcat_1 | at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65) tomcat_1 | at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:831) tomcat_1 | at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1634) tomcat_1 | at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) tomcat_1 | at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) tomcat_1 | at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) tomcat_1 | at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) tomcat_1 | at java.base/java.lang.Thread.run(Thread.java:834) Regards, Ibone.
