RE: HTTP2: How to check if the client aborted a request
I am also interested in this. In my case, we added an "Abort Request" link to the placeholder page that is displayed while the calculation is on-going, but naturally nobody ever clicks on it. :O I am solidly In favor of anything that fixes this. Sam Denton (he/him) Advisor, Solutions Architect Mobile (314) 827-4017 24x7 SBS Suppot (405) 312-9936 Advanced Leave Notice: NONE -Original Message- From: Robin Stevens Sent: Tuesday, March 14, 2023 4:01 AM To: users@tomcat.apache.org Subject: HTTP2: How to check if the client aborted a request Use case / problem: The frontend is doing requests that trigger heavy calculations in the backend. Often these requests get cancelled by the frontend before the backend has finished doing the calculations. The cancellation of the requests is done by using an AbortController (https://developer.mozilla.org/en-US/docs/Web/API/AbortController) to abort the fetch (similar to this example https://developer.mozilla.org/en-US/docs/Web/API/AbortController/abort#examples). When aborting a fetch that happens over HTTP2, an RST_FRAME is send to the server. I'm trying to figure out how to detect in the backend that such an RST_FRAME has been received, and stop doing my calculation. This is done in a Spring Boot Application using the embedded Tomcat webserver, but I would already be glad if I can get a pointer on how to get this information in Tomcat through public apis. I'm hopeful I can figure out the integration with Spring myself. Investigation: What I already found is that the RST_FRAME is received in the backend, at which point the state in the org.apache.coyote.http2.StreamStateMachine switches to CLOSED_RST_TX. After that state switch, the org.apache.coyote.http2.StreamStateMachine#canWrite method returns false which I think is the information I need. After all, if the result of my calculation cannot be written to the stream, there is no point in doing it. The problem is that this information is hidden behind a bunch of package visible/protected classes and methods so I cannot access it without relying on reflection and implementation details. And I couldn't find anything in the source code that exposes this information publicly. So I'm not even sure I'm on the right track here. Does anybody has a pointer on how to obtain this info through official APIs, or to some documentation related to this that I might have missed ? Thanks, Robin - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: EOL of Apache Tomcat 8.5 & 9
This is probably answered somewhere, but will Tomcat 9 support Jakarta EE as well as Java EE? Sam Denton Advisor, Solutions Architect Mobile (314) 827-4017 24x7 SBS Suppot (405) 312-9936 Advanced Leave Notice: I will be out from Fri, 12/23, thru Fri, 12/30 -Original Message- From: Mark Thomas Sent: Tuesday, December 13, 2022 8:31 AM To: users@tomcat.apache.org Subject: Re: EOL of Apache Tomcat 8.5 & 9 done today (I keep getting distracted with other things). It will be 31 March 2024. Tomcat 9 is a special case. As the last major Tomcat version that supports Java EE (Tomcat 10 onwards supports Jakarta EE) we plan to handle it differently. The exact plan is somewhat vague as implementation is still multiple years (best guess 4+ years) away so while I have described this plan several times on the users list, don't be surprised if the details aren't always the same. 9.0.x will reach EOL in the usual way. Best guess for that is 31 March 2027 but that could be out by at least a year. At that point 9.10.x will be created which will: - continue to support Java EE 8 - be as closely aligned to the 10.1.x code base as it can be while still supporting the Java EE 8 API To put it another way, 9.10.x will have all changes seen between 9.0.x and 10.1.x apart from the Java EE API which will remain unchanged. HTH, Mark On 13/12/2022 14:09, Voon Siang Loong wrote: > Hi team, > > What is the planned EOL Date for Apache Tomcat 8.5 & Apache Tomcat 9? Any > rough estimation? > Thanks! > > Regards, > Voon >
RE: AW: Maybe a stupid (Windows related) question
I believe that "2>&1 1>D:\orx.debug\work_rii_tomcat\test.log" will first redirect stderr to stdout, and then redirect stdout to the file, leaving stderr pointing to the original stdout, which is presumably the terminal. Try "1>D:\orx.debug\work_rii_tomcat\test.log 2>&1" -Original Message- From: Rony G. Flatscher (Apache) Sent: Wednesday, March 23, 2022 6:12 AM To: users@tomcat.apache.org Subject: Re: AW: Maybe a stupid (Windows related) question On 23.03.2022 11:45, Thomas Hoffmann (Speed4Trade GmbH) wrote: >> -Ursprüngliche Nachricht- >> Von: Rony G. Flatscher (Apache) >> Gesendet: Mittwoch, 23. März 2022 11:34 >> An: users@tomcat.apache.org >> Betreff: Re: Maybe a stupid (Windows related) question >> >> On 22.03.2022 20:18, Christopher Schultz wrote: >> >> ... cut ... >> >>> You still can't really "background" the process the way you can on >>> *nix. Sure, you can get your command-prompt back, but if you kill >>> cmd.exe, so does your child process die. And if you log out, that process >> dies as well. >> >> The problem is different: redirecting stderr and stdout does not redirect in >> this scenario (employing %CATALINA_HOME%\bin\startup.bat), rather >> output statements to stderr >> (System.err.println(...)) and stdout (System.out.println(...)) gets still >> displayed in the Tomcat window. >> >> This involves (at least in my experiments) editing bin\startup.bat and/or >> bin\catalina.bat which should not be necessary if understanding Tomcat's >> philsophy correctly. If adjustments are necessary it is advised to supply a >> "bin\setup.bat" script to do so. >> >> So what I would be looking for is either a configuration change or an >> environment variable to set which allows redirecting stdout and stderr to >> appropriate log files as is done with the service version by default. >> >>> Using the Windows Service is really the best way to do it on Windows. >> The use case is testing Tomcat 10 in various ways, including running it in >> debug mode and attaching via IntelliJ for inspection. >> >> ---rony >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org > The bat-file uses the line: > call "%EXECUTABLE%" start %CMD_LINE_ARGS% > > At this place you might be able to redirect the output: > call "%EXECUTABLE%" start %CMD_LINE_ARGS% > out.log > > You could also try to pass the redirect param to the argument of startup.bat, > don’t know if this works, e.g. > startup.bat " > out.log" startup.bat uses start to run catalina.bat in a new cmd window with: call "%EXECUTABLE%" start %CMD_LINE_ARGS% catalina.bat then starts Tomcat as: %_EXECJAVA% %CATALINA_LOGGING_CONFIG% %LOGGING_MANAGER% %JAVA_OPTS% %CATALINA_OPTS% %DEBUG_OPTS% -D%ENDORSED_PROP%="%JAVA_ENDORSED_DIRS%" -classpath "%CLASSPATH%" -Dcatalina.base="%CATALINA_BASE%" -Dcatalina.home="%CATALINA_HOME%" -Djava.io.tmpdir="%CATALINA_TMPDIR%" %MAINCLASS% %CMD_LINE_ARGS% 2>&1 1> D:\orx.debug\work_rii_tomcat\test.log This does not work. ---rony - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
