tomcat http error code 502
Hi, using tomcat 8.5.42 and have the following questions * will tomcat log http error 502 in accesslog? * under what situation will tomcat return 502? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: jstl jar location
Thanks for the reference. So according to the spec [1], TLDs are scanned in JARs in WEB-INF/lib only. That explains why the TLDs of jstl-1.2.jar are not picked up when in the common classloader location. However 1 states that the container builds a map of platform TLDs. So I guess JSTL is not part of "JavaServer Pages Standard Tag Library"... Also, wouldn't the container build implicitly the Map Entries from forcing it to scan via tomcat.util.scan.StandardJarScanFilter.jarsToScan=... jstl*.jar...? George [1] The following order of precedence applies (from highest to lowest) when building the taglib map (see the following sections for details): 1. If the container is Java EE platform compliant, the Map Entries for the tag libraries that are part of the Java EE platform. This currently includes the JavaServer Pages Standard Tag Library libraries and the JavaServer Faces libraries. 2. Taglib Map in web.xml 3. Implicit Map Entries from TLDs ■ TLDs in JAR files in WEB-INF/lib ■ TLDs under WEB-INF 4. Implicit Map Entries from the Container -Original Message- From: Konstantin Kolinko Sent: Wednesday, October 21, 2020 4:07 AM To: Tomcat Users List Subject: Re: jstl jar location вт, 20 окт. 2020 г. в 22:31, George Stanchev : > > > I am hoping someone can shed some lights on a question. I did try to search > online and SO but haven't had luck in figure it out so hopefully it is a > quick answer from the people that know that stuff. We have an uber-lib folder > where we keep shared libraries in our TC85-hosted app. If we put jstl-1.2.jar > into that directory but not in the application /WEB-INF/lib directory, TC > generates [1]. If I move jstl into the application lib folder, it works. I > made sure jstl is excluded from jarsToSkip and included in jarsToScan. > > Is there any rule or switch that says that the JSP compiler cannot use the > parent CL to resolve the jstl URIs? There is a rule how JSP engine locates Tag Library Descriptor (TLD) files. See chapters "JSP.7.2 Tag Libraries", "JSP.7.3 The Tag Library Descriptor". Especially the "order of precedence" list in chapter "JSP.7.3.2 TLD resource path". It looks that you are relying on implicit declarations.of TLDs. https://cwiki.apache.org/confluence/display/TOMCAT/Specifications Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: FW: HTTP2: memory filled up fast on increasing the connections to 1000/2000 (Embedded tomcat 9.0.38)
Arshiya,
On 10/21/20 00:34, Arshiya Shariff wrote:
> Hi,
>
> Christopher, Please find the answer in-line:
> How... exactly?
> private String getRequestBody(HttpServletRequest request) throws IOException
> {
> StringBuilder sb = new StringBuilder();
> BufferedReader reader = request.getReader();
> try
> {
> String line;
> while( ( line = reader.readLine() ) != null )
> {
> sb.append( line ).append( '\n' );
Note that this may modify the incoming request. Are you sure you want to
return a value which does not match the exact POST body?
> }
> }
> finally
> {
> reader.close();
> }
> return sb.toString();
> }
>
Is that method run from within the asynchronous context or before you
begin async processing? I'm not an expert at servlet-async, but I think
you should be reading the request entirely before entering the async
context. Reading the request from async may cause problems.
Instead of using blocking reads of the request bbody in asynchronous
mode, you should do this:
request.getInputStream().setReadListener(new ReadListener() {
public void onoAllDataRead() { ... }
public void onDataAvailable() { ... }
public void onError(Throwable t) { ... }
});
> I am trying to reproduce the StackOverflowError with a sample
> application , Once it is reproduced I will share it across.
See https://www.slideshare.net/SimoneBordet/servlet-31-async-io
Specifically slides 43-53.
-chris
> -Original Message-
> From: Christopher Schultz
> Sent: Thursday, October 15, 2020 12:01 AM
> To: users@tomcat.apache.org
> Subject: Re: FW: HTTP2: memory filled up fast on increasing the connections
> to 1000/2000 (Embedded tomcat 9.0.38)
>
> Arshiya,
>
> On 10/14/20 01:23, Arshiya Shariff wrote:
>> Please find the answers in-line Mark.
>>
>> Http2 requests with message payload of 34KB are pumped from JMeter at
>> 20 TPS with 700 connections to an application with Embedded tomcat
>> - 9.0.39 (max-Threads : 200, all other values are the tomcat
>> defaults)
>>
>>> What does that URL do with the POSTed content? Ignore it? Read it
>>> from an InputStream? Read it via getParameter()?
>>
>> The posted content is read via BufferedReader reader =
>> request.getReader() and processed asynchronously
> How... exactly?
>> Is JMeter run on the same machine as Tomcat?
>> JMeter is run from a different machine.
>>
>> Do you use the JMeter GUI or the command line?
>> Launched via Command line (JMeter heap increased to 10 GB )
>>
>> What are the specs of the server(s) being used?
>> The server is a VM with 12 CPUs and 120 GB RAM
>>
>> Please let us know if you require more details.
>
> This would probabyl be easier if you'd just provide a test-case: a sample
> (simple!) web application which reproduces what you are reporting.
>
> -chris
>
>> -Original Message-
>> From: Mark Thomas
>> Sent: Monday, October 12, 2020 7:28 PM
>> To: users@tomcat.apache.org
>> Subject: Re: HTTP2: memory filled up fast on increasing the
>> connections to 1000/2000 (Embedded tomcat 9.0.38)
>>
>> On 12/10/2020 08:02, Arshiya Shariff wrote:
>>> Hi Mark ,
>>>
>>> The issue is reproduced with version 9.0.39 as well. Max threads in Tomcat
>>> is 200.
>>>
>>> Please find the case:
>>> Client:JMeter 5.2.1 (With http2 plugin)
>>> TPS: around 20
>>> No of users from JMeter : 700
>>> Message payload size: 6 KB to 34 KB
>>> Loop: Infinite
>>> We let the loop run infinitely and see the java.lang.StackOverflowError
>>> trace printed multiple times in the log within few minutes of starting the
>>> test.
>>
>> POSTing to what URL?
>>
>> What does that URL do with the POSTed content? Ignore it? Read it from an
>> InputStream? Read it via getParameter()?
>>
>> Is JMeter run on the same machine as Tomcat?
>>
>> Do you use the JMeter GUI or the command line?
>>
>> What are the specs of the server(s) being used?
>>
>> You need to provide the exact steps to recreate this issue on a clean
>> install of Tomcat 9.0.39 as provided by the ASF.
>>
>> Mark
>>
>>
>>> Please help us with this . What is the impact of StackOverflowError ?
>>>
>>> Thanks and Regards
>>> Arshiya Shariff
>>>
>>> -Original Message-
>>> From: Mark Thomas
>>> Sent: Friday, October 9, 2020 5:31 PM
>>> To: users@tomcat.apache.org
>>> Subject: Re: HTTP2: memory filled up fast on increasing the
>>> connections to 1000/2000 (Embedded tomcat 9.0.38)
>>>
>>> On 09/10/2020 12:32, Arshiya Shariff wrote:
Hi,
Mark , with the test runs that I performed over clean 9.0.x branch I was
not able to reproduce this.
>>>
>>> Good. But I'd really like to understand why...
>>>
But with 9.0.38 and the jars built from 9.0.x with hash:
c8ec2d4cde3a31b0e9df9a30e7915d77ba725545 ,
Re: jstl jar location
вт, 20 окт. 2020 г. в 22:31, George Stanchev : > > > I am hoping someone can shed some lights on a question. I did try to search > online and SO but haven't had luck in figure it out so hopefully it is a > quick answer from the people that know that stuff. We have an uber-lib folder > where we keep shared libraries in our TC85-hosted app. If we put jstl-1.2.jar > into that directory but not in the application /WEB-INF/lib directory, TC > generates [1]. If I move jstl into the application lib folder, it works. I > made sure jstl is excluded from jarsToSkip and included in jarsToScan. > > Is there any rule or switch that says that the JSP compiler cannot use the > parent CL to resolve the jstl URIs? There is a rule how JSP engine locates Tag Library Descriptor (TLD) files. See chapters "JSP.7.2 Tag Libraries", "JSP.7.3 The Tag Library Descriptor". Especially the "order of precedence" list in chapter "JSP.7.3.2 TLD resource path". It looks that you are relying on implicit declarations.of TLDs. https://cwiki.apache.org/confluence/display/TOMCAT/Specifications Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Virtual event focussed on Tomcat Security
On 16/10/2020 14:21, Robert Hicks wrote: > On Thu, Oct 15, 2020 at 2:01 PM Mark Thomas wrote: > >> On 29/09/2020 12:25, Mark Thomas wrote: >>> Hi all, >>> >>> We (the Tomcat community) have some funding from Google to help us >>> improve Tomcat security. Our original plan was to use the funding to >>> support an in-person security focussed hackathon. As you would expect, >>> those plans are on hold for now. We would, therefore, like to explore >>> the possibility of doing something virtually. >>> >>> The purpose of this email is to gather input from the community about >>> what such an event should look like. With that input we can put together >>> a plan for the event. So, over to you. What would your ideal virtual >>> event focussed on Tomcat Security look like? >> >> Summarising the suggestions so far: >> - application security / OWASP >> - making HTTP requests *from* Tomcat >> - SSO / SAML / OpenIDConnect >> >> The first two are more application security focussed and would not have >> to be Tomcat specific. >> >> The third is more likely to Tomcat specific depending on the extent to >> which the SSO mechanism ties into Tomcat's internals. >> >> All the suggestions so far have been for conference like presentations >> (if I am reading them correctly). >> >> Other possibilities: >> - hackathon to implement (with support from committers) new security >> features (no idea what these might be - suggestions welcome) >> >> - hackathon to run $tool_of_choice against Tomcat code base, review the >> results and fix (with committer support) those that need fixing. >> Suggestions as to tools to use welcome* >> >> Anything else you'd like to suggest that is related to Tomcat and security. >> >> There hasn't been any thought given to timing yet. >> >> Mark >> >> >> >> * I'll note that over the years most if not all of the major static >> analysis tools have been run against the Tomcat code base and the >> results have been very heavy on the false positives. Most of the work is >> likely to be separating the few useful results from a lot of noise. >> >> > Has a "when" been decided yet? No. We need to talk to the ASF conferences team to see when the hopin platform will be available. Mark > > Thanks, > > Bob > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: No thread name in AccessLogValve printed
On 20/10/2020 11:39, Michael Osipov wrote:
> Am 2020-10-20 um 11:44 schrieb Mark Thomas:
>> On 20/10/2020 10:10, Michael Osipov wrote:
>>> Folks,
>>>
>>> I have seen recently entried like this on our access logs:
2020-10-19T20:00:05.591 [null] xyz - "-" 400 - 0
2020-10-19T20:00:05.591 [null] abc- "-" 400 - 0
2020-10-19T20:00:05.592 [null] abc - "-" 400 - 0
2020-10-19T20:00:05.593 [null] abc - "-" 400 - 0
2020-10-19T20:00:05.616 [null] abc - "-" 400 - 0
>>>
>>> with pattern:
%{-MM-dd'T'HH:mm:ss.SSS}t [%I] %h %u %r %s %b %D
>>>
>>> While I am quite certain that these ary "security" scans at work
>>> I wonder why RequestInfo#getWorkerThreadName() is null.
>>> Is the request rejected because it is malformed because before it is
>>> handled to a worker?
>>
>> Have you tried looking at the source code? Callers of
>> RequestInfo.setWorkerThreadName() are likely to be enlightening.
>
> Yes, I did. It happens before the thread local is used.
Strictly, RequestInfo isn't a ThreadLocal. There is plumbing in place to
ensure there is a one-to-one mapping between Http11Processor, Request,
Response and RequestInfo (and other objects as well) and that that group
of objects is only accessed by one thread at a time.
> It happens in
> org.apache.coyote.http11.Http11Processor.prepareRequest() before a
> servlet is invoked. So the worker name has to be null here.
Processing is transferred to a worker thread as soon as the socket as
accepted / as soon as the Poller identifies there is data to process so
there is no need for the worker name to be null here.
>>> I am not sure whether "info != null &&
>>> info.getgetWorkerThreadName() != null" would be the right change here.
>>
>> That would address the symptom. There may be a better fix that addresses
>> (or at least gets closer) to the cause.
>
> Given the information above I am inclined to say that Thread#getName()
> would make sense here.
That would give the correct value but is more of an "address the
symptom" approach that an "address the root cause" approach.
I'd suggest looking at moving the RequestInfo.setWorkerThreadName()
calls to an earlier point in the processing chain so it was set when the
AccessLogValve tries to use it.
> Writing '-' does not make sense because every
> request is processed in some thread, isn't it?
Agreed. Although it is worth keeping in mind async requests and any
request where non-blocking IO is used may be processed by more than one
thread during the duration of the request. In those cases the thread
recorded is (I think) going to be the last container thread that handled
the request.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: jstl jar location
On 20/10/2020 20:30, George Stanchev wrote: > > I am hoping someone can shed some lights on a question. I did try to search > online and SO but haven't had luck in figure it out so hopefully it is a > quick answer from the people that know that stuff. We have an uber-lib folder > where we keep shared libraries in our TC85-hosted app. If we put jstl-1.2.jar > into that directory but not in the application /WEB-INF/lib directory, TC > generates [1]. If I move jstl into the application lib folder, it works. I > made sure jstl is excluded from jarsToSkip and included in jarsToScan. > > Is there any rule or switch that says that the JSP compiler cannot use the > parent CL to resolve the jstl URIs? I don't recall anything but I haven't checked the code or the specs for a definitive answer. How are you ensuring that the uber-lib folder is visible to web applications? Mark > > George > > > > [1] > Type Exception Report > Message The absolute uri: [http://java.sun.com/jsp/jstl/core] cannot be > resolved in either web.xml or the jar files deployed with this application > Description The server encountered an unexpected condition that prevented it > from fulfilling the request. > Exception > org.apache.jasper.JasperException: The absolute uri: > [http://java.sun.com/jsp/jstl/core] cannot be resolved in either web.xml or > the jar files deployed with this application > > org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:55) > > org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:293) > > org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:80) > org.apache.jasper.compiler.TagLibraryInfoImpl.generateTldResourcePath(TagLibraryInfoImpl.java:251) > > org.apache.jasper.compiler.TagLibraryInfoImpl.(TagLibraryInfoImpl.java:122) > > org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:431) > org.apache.jasper.compiler.Parser.parseDirective(Parser.java:489) > org.apache.jasper.compiler.Parser.parseElements(Parser.java:1445) > org.apache.jasper.compiler.Parser.parse(Parser.java:144) > > org.apache.jasper.compiler.ParserController.doParse(ParserController.java:244) > > org.apache.jasper.compiler.ParserController.parse(ParserController.java:105) > org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:203) > org.apache.jasper.compiler.Compiler.compile(Compiler.java:375) > org.apache.jasper.compiler.Compiler.compile(Compiler.java:351) > org.apache.jasper.compiler.Compiler.compile(Compiler.java:335) > > org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:597) > > org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:399) > > org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:386) > org.apache.jasper.servlet.JspServlet.service(JspServlet.java:330) > javax.servlet.http.HttpServlet.service(HttpServlet.java:733) > org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) > org.springframework.web.servlet.view.InternalResourceView.renderMergedOutputModel(InternalResourceView.java:168) > > org.springframework.web.servlet.view.AbstractView.render(AbstractView.java:304) > > org.springframework.web.servlet.DispatcherServlet.render(DispatcherServlet.java:1286) > org.springframework.web.servlet.DispatcherServlet.processDispatchResult(DispatcherServlet.java:1041) > org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:984) > > org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:901) > org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:970) > > org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:861) > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
