Re: Making classes available globally (Tomcat 7)
On 29/03/2020 18:02, James H. H. Lampert wrote: > Question: > > In order to serve a Content-Security-Policy header, we have installed a > filter in the context-level web.xml, that calls classes we've added to > our webapp. > > Is there a way to make new classes available globally, so they can be > used by a filter in the global conf/web.xml? Someplace we can put the > classes? Package them in a JAR and put the JAR in the /lib directory or put the class files (in the appropriate package structure) directly in the /lib directory. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Does Tomcat/Java get around the problem of 64K maximum client source ports?
> -Original Message- > From: André Warnier (tomcat/perl) > Sent: Saturday, March 28, 2020 5:35 PM > To: users@tomcat.apache.org > Subject: Re: Does Tomcat/Java get around the problem of 64K maximum > client source ports? > > On 27.03.2020 21:39, Eric Robinson wrote: > > FYI, I don't have 1800 tomcat instances on one server. I have about 100 > instances on each of 18 servers. > > When one of these (attempted) connections fails, do you not get some error > message which gives a clue as to what the failure is due to ? > (should be a log somewhere, no ?) > Hi André -- Yes, it does log a connection failure message. It's been a while since the last time it happened so I don't recall the exact wording of the error, but the gist of it is that it could create a TCP connection. > Also, just for info : > in the past, I have run into problems under Linux (no more connections > accepted, neither incoming nor outgoing) whenever the actual number of > TCP connections went above a certain number (maybe it was 64K). > A TCP connection goes through a number of states (which you see with a > netstat display), such as "ESTABLISHED" but also "TIME_WAIT", > "CLOSE_WAIT" etc.. In some of these states, the connection no longer has > any link to any process, but the connection still counts against the limit (of > the OS/TCP stack). > > The case I'm talking about was a bit like yours : a webapp running under > tomcat was making a connection to a remote host, but this connection was > wrapped inside an object of some kind. When the webapp no longer needed > the connection, it just discarded the wrapping object, which was left without > references to it, and thus candidate for destruction at some point. But the > discarded object never explicitly closed the underlying connection. > > Over a period of time, this left an accumulation of (no longer used) > connections in the "CLOSE_WAIT" state (closed by the remote host side, but > not by the webapp side), which just sat there until a GC happened, at which > time the destruction of these objects really happened, and some implicit > close was done at the OS level, which eliminated these pending underlying > CLOSE_WAIT connections. > And since the available heap was quite large, it took a long time before a GC > happened, which allowed such CLOSE_WAIT connections to accumulate in > the hundreds or thousands before being "recycled". > Until a certain number was reached, and then the host became all but > unreachable and very slow. > That was a long time ago, and thus a lot of Java versions and Linux versions > ago, so maybe something happened since then to avoid such a situation. > But maybe also, you are suffering of some similar phenomenon. > You could try to use netstat some more, and when you are having the > problem, you should count at ALL the TCP connections, including the ones in > CLOSE_WAIT, and just check if you do not have an obscene number of them > in total. There is definitely some limit number past which the OS starts > acting > funny. > > (Note : unlike for TIME_WAIT e.g., there is no time limit for a connection in > the CLOSE_WAIT state; it will stay in that state as long as the client side > has > not explicitly closed it, in some kind of zombie half-life) See e.g. : > https://users.cs.northwestern.edu/~agupta/cs340/project2/TCPIP_State_Tr > ansition_Diagram.pdf > I'm familiar with the issue you described above. In the past, we addressed it by decreasing the TIME_WAIT timer and/or by enabling TCP reuse. That helps some. > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org 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.
Making classes available globally (Tomcat 7)
Question: In order to serve a Content-Security-Policy header, we have installed a filter in the context-level web.xml, that calls classes we've added to our webapp. Is there a way to make new classes available globally, so they can be used by a filter in the global conf/web.xml? Someplace we can put the classes? -- James H. H. Lampert - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HttpServletRequest.getRemoteAddr() sometimes returns NULL on Tomcat 9.0.30 and HTTP/2 secure requests
On 29/03/2020 15:58, Manuel Dominguez Sarmiento wrote: > >> Do the streams with errors all share the same connection ID? I suspect >> an error on one stream is triggering the closure of the connection and >> what you are seeing is the fallout of closing the connection. > That makes sense and is kind of what we're suspecting. How can we check > the connection/stream id? Can this be logged by AccessLogValve? Not easily at the moment. That looks like something we should fix. I'll see what I can do for 9.0.34. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HttpServletRequest.getRemoteAddr() sometimes returns NULL on Tomcat 9.0.30 and HTTP/2 secure requests
Do the streams with errors all share the same connection ID? I suspect an error on one stream is triggering the closure of the connection and what you are seeing is the fallout of closing the connection. That makes sense and is kind of what we're suspecting. How can we check the connection/stream id? Can this be logged by AccessLogValve? *Manuel Dominguez Sarmiento *
Re: [EXTERNAL] Re: Query regarding bindOnInit default value..
Thanks for the inputs, Mark. Thanks, Amit > On Mar 29, 2020, at 5:06 PM, Mark Thomas wrote: > > On 29/03/2020 08:11, Amit Pande wrote: >> Hello all, >> >> I was exploring Tomcat configuration which doesn't accept requests until the >> web application is deployed. >> >> >> "bindOnInit" connector attributes when set to false, makes socket bind when >> the connector starts and not when the connector is initialized. >> >> Wanted to know, why the default value of this is not set to false? What are >> the use cases where the default of "true" is useful? > > When you want to change the connector configuration (stop, change > config, start) without refusing any new connections. Typically reverse > proxy scenarios. There should be some discussion on this in the archives > (quite a while ago now), I think around the time the feature was introduced. > >> Setting this value to false, I could see "connection refused" error on >> client side when they made requests to Tomcat when the application >> deployment was in-progress. >> When this is set to "true", all requests during when the application >> deployment wasn't complete, I could see failed SSL handshakes in access logs. > > That indicates that the time taken for the applications to deploy > exceeds the client read timeout (or write timeout if it is trying to > post something bigger than the network buffers can hold). > > Mark > > >> >> Wanted to understand more about the current default of true before I change >> the default. >> >> Thanks, >> Amit >> > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
Re: HttpServletRequest.getRemoteAddr() sometimes returns NULL on Tomcat 9.0.30 and HTTP/2 secure requests
On 28/03/2020 14:00, Manuel Dominguez Sarmiento wrote:
> Hi Mark, we're now on the latest 9.0.33 release and we still see this
> issue intermittently in our logs. Only on HTTP/2 secure requests.
>
> Please see the attached access logs (these represent all the cases for
> one whole day in one single high-volume server).
> Some of the following request fields are NULL (or -1) in these examples:
> - remoteAddr
> - remotePort
> - serverPort
> - requestURI
> - User-Agent
>
> Some requests are missing some of the fields, some of the requests are
> missing others. What is particularly interesting is that the errors are
> clustered around particular timestamps, pointing to some likely issue
> regarding object sharing across several requests.
Do the streams with errors all share the same connection ID? I suspect
an error on one stream is triggering the closure of the connection and
what you are seeing is the fallout of closing the connection.
Mark
>
> Please note that this is not just an issue at the AccessLogValve level.
> These fields contain invalid data while the request is being processed,
> so that is causing unexpected exceptions in our production code. The
> cases are few and isolated, but still this should be looked into.
>
> Any thoughts?
>
> *Manuel Dominguez Sarmiento*
>
> On 05/02/2020 14:12, Manuel Dominguez Sarmiento wrote:
>> Our filter is not doing anything fancy (and it has always worked
>> correctly before we ran into this bug). In pseudo-code:
>>
>> public doFilter(request, response) {
>>
>> String ip = request.getRemoteAddr();
>> boolean isProxy = isProxy(ip);
>> if (isProxy) {
>> String unwrappedIP = unwrapXForwardedFor(request);
>> chain.doFilter(new
>> MobileProxyHidingServletRequestWrapper(request, unwrappedIP), response);
>> } else {
>> chain.doFilter(request, response);
>> }
>> }
>>
>> All that MobileProxyHidingServletRequestWrapper is override
>> getRemoteAddr() returning unwrappedIP instead of delegating to the
>> actual request, while unwrapXForwardedFor() does what the name
>> suggests, which is processing X-Forwarded-For to obtain the
>> originating IP before it hit the detected proxy.
>>
>> *Manuel Dominguez Sarmiento*
>>
>> On 05/02/2020 10:28, Mark Thomas wrote:
>>> On 04/02/2020 22:27, Manuel Dominguez Sarmiento wrote:
We are getting the NPEs in a top-of-the-chain servlet filter which
decorates HttpServletRequest.getRemoteAddr() before actual servlet
processing. Only on HTTP/2 and in a very small number of cases. Perhaps
we should test 9.0.31 and see what happens. When is this new version due
for release?
>>> I'm just working through back-porting some changes and then I'll be
>>> starting the release process. It 9.0.31 should be available towards the
>>> beginning of next week.
>>>
>>> Can you expand on what your filter is doing? When is the call made to
>>> HttpServletRequest.getRemoteAddr() on the original request?
>>>
>>> Mark
>>>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Query regarding bindOnInit default value..
On 29/03/2020 08:11, Amit Pande wrote: > Hello all, > > I was exploring Tomcat configuration which doesn't accept requests until the > web application is deployed. > > > "bindOnInit" connector attributes when set to false, makes socket bind when > the connector starts and not when the connector is initialized. > > Wanted to know, why the default value of this is not set to false? What are > the use cases where the default of "true" is useful? When you want to change the connector configuration (stop, change config, start) without refusing any new connections. Typically reverse proxy scenarios. There should be some discussion on this in the archives (quite a while ago now), I think around the time the feature was introduced. > Setting this value to false, I could see "connection refused" error on client > side when they made requests to Tomcat when the application deployment was > in-progress. > When this is set to "true", all requests during when the application > deployment wasn't complete, I could see failed SSL handshakes in access logs. That indicates that the time taken for the applications to deploy exceeds the client read timeout (or write timeout if it is trying to post something bigger than the network buffers can hold). Mark > > Wanted to understand more about the current default of true before I change > the default. > > Thanks, > Amit > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Query regarding bindOnInit default value..
Hello all, I was exploring Tomcat configuration which doesn't accept requests until the web application is deployed. "bindOnInit" connector attributes when set to false, makes socket bind when the connector starts and not when the connector is initialized. Wanted to know, why the default value of this is not set to false? What are the use cases where the default of "true" is useful? Setting this value to false, I could see "connection refused" error on client side when they made requests to Tomcat when the application deployment was in-progress. When this is set to "true", all requests during when the application deployment wasn't complete, I could see failed SSL handshakes in access logs. Wanted to understand more about the current default of true before I change the default. Thanks, Amit
