Re: Weirdest Tomcat Behavior Ever?

2020-11-13 Thread Thomas Meyer



Am 13. November 2020 10:06:18 MEZ schrieb Mark Thomas :
>On 12/11/2020 14:19, Eric Robinson wrote:
>>> From: Mark Thomas 
>
>
>
>>> I keep coming back to this. Something triggered this problem (note
>that
>>> trigger not necessarily the same as root cause). Given that the app,
>Tomcat
>>> and JVM versions didn't change that again points to some other
>component.
>>>
>> 
>> Perfectly understandable. It's the oldest question in the diagnostic
>playbook. What changed? I wish I had an answer. Whatever it was, if
>impacted both upstream servers.
>> 
>>> Picking just one of the wild ideas I've had is there some sort of
>firewall, IDS,
>>> IPS etc. that might be doing connection tracking and is, for some
>reason,
>>> getting it wrong and closing the connection in error?
>>>
>> 
>> Three is no firewall or IDS software running on the upstreams. The
>only thing that comes to mind that may have been installed during that
>timeframe is Sophos antivirus and Solar Winds RMM. Sophos was the first
>thing I disabled when I saw the packet issues.
>
>ACK.
>
> The aim with this logging is to provide evidence of whether or not
> there is a file descriptor handling problem in the JRE. My
> expectation is that with these logs we will have reached the limit
>of
> what we can do with Tomcat but will be able to point you in the
>right
>>> direction for further investigation.
>
>I've had a chance to review these logs.
>
>To answer your (offlist) question about the HTTP/1.1 vs. HTTP/1.0 in
>the
>Nginx logs I *think* the Nginx logs are showing that the request
>received by Nginx is using HTTP/1.1.
>
>The logging does not indicate any issue with Java's handling of file
>descriptors. The file descriptor associated with the socket where the
>request fails is only observed to be associated with the socket where
>the request fails. There is no indication that the file descriptor is
>corrupted nor is there any indication that another thread tries to use
>the same file descriptor.
>
>I dug a little into the exception where the write fails:
>
>java.net.SocketException: Bad file descriptor (Write failed)
>   at java.net.SocketOutputStream.socketWrite0(Native Method)
>   at
>java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:111)
>   at java.net.SocketOutputStream.write(SocketOutputStream.java:155)
>   at
>org.apache.tomcat.util.net.JIoEndpoint$DebugOutputStream.write(JIoEndpoint.java:1491)
>   at
>org.apache.coyote.http11.InternalOutputBuffer.realWriteBytes(InternalOutputBuffer.java:247)
>   at
>org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:480)
>   at
>org.apache.coyote.http11.InternalOutputBuffer.endRequest(InternalOutputBuffer.java:183)
>...
>
>
>I took a look at the JRE source code. That exception is triggered by an
>OS level error (9, EBADF, "Bad file descriptor") when the JRE makes the
>OS call to write to the socket.
>
>Everything I have found online points to one of two causes for such an
>error:
>a) the socket has already been closed
>b) the OS has run out of file descriptors

Was it mentioned what OS is used? What Linux kernel version?
Are any security modules like SELinux or similar is in use?
It's maybe possible that a tracepoint exists that can be activated to get 
better understanding when the OS closes the socket.

>
>There is no indication that the JRE or Tomcat or the application is
>doing a)
>Previous investigations have ruled out b)
>
>The wireshark trace indicates that the socket is closed before the
>write
>takes place which suggests a) rather more than b). Even so, I'd be
>tempted to double check b) and maybe try running Tomcat with
>-XX:+MaxFDLimit just to be sure.
>
>If you haven't already, I think now is the time to follow Paul
>Carter-Brown's advice from earlier in this thread and use strace to see
>what is going on between the JRE and the OS. The aim being to answer
>the
>question "what is triggering the socket close"
>
>I can try and help interpret that log but I am far from an expert. You
>may want to seek help elsewhere.
>
>Mark
>
>-
>To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>For additional commands, e-mail: users-h...@tomcat.apache.org

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: RFC7807 ErrorReportValve

2020-07-06 Thread Thomas Meyer
Am 5. Juli 2020 11:28:40 MESZ schrieb Michael Osipov :
>Am 2020-07-02 um 21:30 schrieb Thomas Meyer:
>> Hi,
>> 
>> What are your opinions on providing a RFC7807 based ErrorReportValve
>as part of Tomcat default distribution?
>
>Thomas, this has been bugging me for a while. Let me share some
>thoughts 
>on this, I'll limit my experiences with Tomcat, Spring Web and Zalando 
>Problem (including it's web module):
>
>Mark, please correct me if my citation of the Servlet API is wrong.
>
>* The Servlet API has been designed where the only clients where
>browsers
>* The Servlet API mandates that all invocations of 
>HttpServletResponse#setError() must yield in a HTML page and this 
>*cannot* be changed by defult
>* Even if you write a REST API or explicitly use @RestController Spring
>
>will still invoke #setError() although it makes no sense. I consider 
>this to be a conceptual flaw in the Spring framework.
>
>Before we continue which issue do you want to solve? Tomcat produced 
>errors or by a framework?

It's about tomcat produced errors:

There are multiple webapps deployed to tomcat all under non-root context path.

Some webapps use spring framework, for these webapps an CustomErrorController 
is installed so always a JSON response in a given JSON layout is done.

Some webapps are pure servlet based, here an error-page entry in web.xml and an 
ErrrorSerlvet is used to also have the same JSON layout as above for all 
possible errors.

But because of some race condition in deployment scripts for multi node setup, 
some class files weren't copies correctly, and tomcat ErrorReportValve was 
triggered with NoClassDef error.

So much for the context.

I guess I'll write an JsonErrorReportValve and install it in lib/ so deployment 
will always response with same JSON layout in all circumstances, e.g. failed 
deployment or access to unknown context path.

>  As for the framework, I would prefer to file
>
>an issue with Spring Framework first and see what the devs say because 
>this would solely solve a symptom.
>
>Michael
>
>-
>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: Add custom Authenticator in context.xml

2020-07-06 Thread Thomas Meyer
Am 6. Juli 2020 14:14:59 MESZ schrieb Mark Thomas :
>On 04/07/2020 19:54, Thomas Meyer wrote:
>> Hi,
>> 
>> a while ago I did write a little POC of how to add a custom
>> authenticator scheme to tomcat.
>> 
>> this is what I did come up with:
>> https://github.com/thomasmey/BearerTokenAuthenticator
>> 
>> It's rather complicated solution!
>> Is there an more easy solution to add a custom authenticator scheme
>to a Context/context.xml? 
>
>How about:
>
>1. Extract the Authenticators.properties file from catalina.jar
>   (or from source)
>2. Edit it to reference the custom Authenticator
>3. Place it at $CATALINA_BASE/lib/org/apache/catalina/startup
>4. Add the JAR with the custom authenticator to $CATALINA_BASE/lib
>
>which would make it generally available to use in WEB-INF/web.xml

Okay, understand! Nice trick.

>
>Or
>
>1. Add it directly to context.xml as:
>
>
>   className="de.m3y3r.catalina.authenticator.BearerTokenAuthenticator" />
>

Ah, okay an Authenticator is also a Valve, I didn't think about this!

I will play around with this setup a bit. thanks for the hint!

>
>which you would need to do for each app that wants to use it (or set it
>in the global web.xml for all apps).
>
>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



Add custom Authenticator in context.xml

2020-07-04 Thread Thomas Meyer
Hi,

a while ago I did write a little POC of how to add a custom
authenticator scheme to tomcat.

this is what I did come up with:
https://github.com/thomasmey/BearerTokenAuthenticator

It's rather complicated solution!
Is there an more easy solution to add a custom authenticator scheme to a 
Context/context.xml? 

Mfg
thomas


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: RFC7807 ErrorReportValve

2020-07-03 Thread Thomas Meyer
Am 2. Juli 2020 21:45:53 MESZ schrieb Mark Thomas :
>On 02/07/2020 20:30, Thomas Meyer wrote:
>> Hi,
>> 
>> What are your opinions on providing a RFC7807 based ErrorReportValve
>as part of Tomcat default distribution?
>
>RFC 7807 looks to be application specific so support for that RFC looks
>to be better handled at the application level.

Mhh, okay, sad to hear.

The basic idea was to provide an ErrorReportValve that always responds with an 
JSON, given the use case that tomcat is sometimes used purely as an HTTP JSON 
based API server, aka. REST, this Valve would always return an JSON object and 
not suddenly an HTML page if for any reason something goes horrible wrong.

It would be a nice to have for tomcat to provide an out of the box support for 
this use case.

But yes the format of the JSON is hard to define generally, above RFC was one 
of the first search results :-)

Mfg
Thomas


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



RFC7807 ErrorReportValve

2020-07-02 Thread Thomas Meyer
Hi,

What are your opinions on providing a RFC7807 based ErrorReportValve as part of 
Tomcat default distribution?

With kind regards
Thomas

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Tomcat session replication

2020-07-01 Thread Thomas Meyer
Am 1. Juli 2020 12:21:46 MESZ schrieb Mark Thomas :
>On 01/07/2020 11:19, Thomas Meyer wrote:
>> Am 30. Juni 2020 11:07:36 MESZ schrieb Mark Thomas
>:
>>> On 29/06/2020 21:41, Christopher Schultz wrote:
>>>> Mark,
>>>>
>>>> On 6/27/20 05:29, Mark Thomas wrote:
>>>>> On 27/06/2020 10:19, Thomas Meyer wrote:
>>>>>> Hi,
>>>>>>
>>>>>> A few questions regarding tomcat session replication:
>>>>
>>>>> load-balancing and session replication are two separate parts of
>>>>> an overall clustering solution.
>>>>
>>>>>> 1) is the jvmRoute attribute on Engine object necessary for
>>>>>> session replication to work correctly?
>>>>
>>>>> No, but if you don't use it it places a number of restrictions on
>>>>> the web application behaviour and on the configuration of session
>>>>> replication.
>>>>
>>>>> The limitations are: - you need to use the DeltaManager (which
>>>>> doesn't scale as well as the BackupManager); - any requests made
>by
>>>>> the client that depend on the session MUST be issued in series,
>not
>>>>> in parallel; and
>>>>
>>>> This is only true of requests that would modify the session-state
>in
>>> a
>>>> way that needed to be deterministic, right? A bunch of GET requests
>>>> that don't change the session ought to be okay in parallel (as long
>>> as
>>>> any prior state-changing requests have completed _ those changes
>>>> replicated).
>>>
>>> Yes.
>>> You don't want state changes in parallel on different nodes.
>>> Any request that depends on a previous change in state can't be
>issued
>>> until the state changing request has completed and the changes
>>> replicated.
>>>
>>>>> - the session Manager must be configured to update all the other
>>>>> nodes in the cluster BEFORE the current request returns to the
>>>>> client.
>>>>
>>>> Same (negative) caveat here, right?
>>>
>>> Yes.
>>>
>>> Essentially you want channelSendOptions="6".
>> 
>> Hi,
>> 
>> Yes I'm using that option. But it still gives an error, but I may now
>found some hints what's going wrong:
>> 
>> When using Spring's ChangeSessionIdAuthStrategy it fails with unknown
>CSRF token.
>> 
>> It looks like the node fails to replicate, i.e. doesn't export, the
>session data after a changeSessionId call.
>> 
>> When using Spring's SessionFixationProtectionStrategy (which
>basically creates a new session and copy all attributes to the new
>session) it works correctly with tomcats session replication.
>> 
>> So it looks like calling changeSessionId fails to somehow replication
>the new session state to the remote nodes.
>> 
>> Looking at ManagerBase "session" attribute it's unclear if it
>contains only "internal session IDs" or external session IDs which do
>change.
>> 
>> The ReplicationValve seems to call manager.findSession with the
>internal ID.
>> 
>> Maybe somewhere something mixes up internal and external session IDs
>or forgets to update ManagerBase.session map.
>> 
>> Opinions?
>
>Maybe this:
>https://bz.apache.org/bugzilla/show_bug.cgi?id=64560


Yes, that's seems to be exactly the same problem!

And it's already fixed!

Thank you very much!

I'll update our tomcat version from 9.0.34 to the fixed version.

Regards
Thomas



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Tomcat session replication

2020-07-01 Thread Thomas Meyer
Am 30. Juni 2020 11:07:36 MESZ schrieb Mark Thomas :
>On 29/06/2020 21:41, Christopher Schultz wrote:
>> Mark,
>> 
>> On 6/27/20 05:29, Mark Thomas wrote:
>>> On 27/06/2020 10:19, Thomas Meyer wrote:
>>>> Hi,
>>>>
>>>> A few questions regarding tomcat session replication:
>> 
>>> load-balancing and session replication are two separate parts of
>>> an overall clustering solution.
>> 
>>>> 1) is the jvmRoute attribute on Engine object necessary for
>>>> session replication to work correctly?
>> 
>>> No, but if you don't use it it places a number of restrictions on
>>> the web application behaviour and on the configuration of session
>>> replication.
>> 
>>> The limitations are: - you need to use the DeltaManager (which
>>> doesn't scale as well as the BackupManager); - any requests made by
>>> the client that depend on the session MUST be issued in series, not
>>> in parallel; and
>> 
>> This is only true of requests that would modify the session-state in
>a
>> way that needed to be deterministic, right? A bunch of GET requests
>> that don't change the session ought to be okay in parallel (as long
>as
>> any prior state-changing requests have completed _ those changes
>> replicated).
>
>Yes.
>You don't want state changes in parallel on different nodes.
>Any request that depends on a previous change in state can't be issued
>until the state changing request has completed and the changes
>replicated.
>
>>> - the session Manager must be configured to update all the other
>>> nodes in the cluster BEFORE the current request returns to the
>>> client.
>> 
>> Same (negative) caveat here, right?
>
>Yes.
>
>Essentially you want channelSendOptions="6".

Hi,

Yes I'm using that option. But it still gives an error, but I may now found 
some hints what's going wrong:

When using Spring's ChangeSessionIdAuthStrategy it fails with unknown CSRF 
token.

It looks like the node fails to replicate, i.e. doesn't export, the session 
data after a changeSessionId call.

When using Spring's SessionFixationProtectionStrategy (which basically creates 
a new session and copy all attributes to the new session) it works correctly 
with tomcats session replication.

So it looks like calling changeSessionId fails to somehow replication the new 
session state to the remote nodes.

Looking at ManagerBase "session" attribute it's unclear if it contains only 
"internal session IDs" or external session IDs which do change.

The ReplicationValve seems to call manager.findSession with the internal ID.

Maybe somewhere something mixes up internal and external session IDs or forgets 
to update ManagerBase.session map.

Opinions?



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Small patch for mod_proxy_ajp

2020-06-29 Thread Thomas Meyer
Am 29. Juni 2020 22:13:10 MESZ schrieb Christopher Schultz 
:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA256
>
>All,
>
>IMO mod_proxy_balancer is missing an important feature, and that's the
>ability to tell the back-end Tomcat node the current status of the
>worke
>r.

Why would a tomcat Backend node want to have this information, what do you want 
to do?

Can you give an example please.

So when a node is disabled in mod proxy it won't receive any requests any more 
so how will this info reach the Backend Tomcat.

What is your goal?
>
>I've filed an enhancement in Bugzilla
>(https://bz.apache.org/bugzilla/show_bug.cgi?id=64338) for this and
>attached a small patch.
>
>I'd love for anyone who is interested in this to:
>
>1. Try the patch
>2. Try to get the status sent to Tomcat
>3. Vote for the patch (if it works!)
>4. Vote for back-port to 2.4.x branch
>
>Thanks!
>
>- -chris
>-BEGIN PGP SIGNATURE-
>Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
>iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl76S1YACgkQHPApP6U8
>pFgXNxAAhEX5ND4dIwfAjfoXCI016Elt8o3zGMiNi2KYS9KSZ0L5c/GkU1sBMjNF
>IcSHKzCTOiMC+IA/Z+2lS0pHi7ysAKgpnfklXcyneuEaY0/PpPpQ3MHtK7+v7VYA
>floLy/qzFK8PnYwEWFiwFKq1HEDES2mXiltwHva0TEhMf+N8Pny81avsLjri8hMA
>URHGW1+Pov101tf8pB0fxOz7Ts2iuytEEGFUAIz3ATq9VtStsXbhhZ1R4JFlj81o
>l75pxyhh72P8ZztJF6M/yWDP8tV8UO0XTjs6kSzcFiKDt3dC43aO9zkhRFCj/kMY
>gLylbQj8HJlv3r4+BZH0o+giVY/bmJ3ULQwFzxl/Bjj00UvK0PCan5DTIhhneBv+
>kTxcRUAZobP367QK3HWoQWsl0VMzrjBCxBaEXtVbW1fFqzw2gilg2GBok7RZe38p
>Ehu0WHgKpV0hRKtwWwZaAsdADqLbwaRCnwtZafdY8RwaeSp3eVaDlPQTjKPQ+Vzf
>XoTbh1SUKZQem77HBMpARMWNxp6bG22WhaZ+0aAuurs6mAzwAxuenjzjzlDC+nAS
>G50IDbkW1ukU/tBJtuhoRk1F7mMopTYLB4bHKnoc2kmSUiQlWhvkOP6FEE6gz5Fh
>osyvKMQfhtD9UcOktXTurNBpl6ZQNCxxZBdEMNr2kjv5QRtuKgA=
>=h+2E
>-END PGP SIGNATURE-
>
>-
>To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>For additional commands, e-mail: users-h...@tomcat.apache.org


-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Tomcat session replication

2020-06-29 Thread Thomas Meyer
Am 29. Juni 2020 22:54:12 MESZ schrieb Christopher Schultz 
:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA256
>
>Thomas,

Hi,

>
>On 6/27/20 05:52, Thomas Meyer wrote:
>> Am 27. Juni 2020 11:29:03 MESZ schrieb Mark Thomas
>> :
>>> On 27/06/2020 10:19, Thomas Meyer wrote:
>>>> Hi,
>>>>
>>>> A few questions regarding tomcat session replication:
>>>
>>> load-balancing and session replication are two separate parts of
>>> an overall clustering solution.
>>>
>>>> 1) is the jvmRoute attribute on Engine object necessary for
>>>> session
>>> replication to work correctly?
>>>
>>> No, but if you don't use it it places a number of restrictions on
>>> the web application behaviour and on the configuration of
>>> session replication.
>>>
>>> The limitations are: - you need to use the DeltaManager (which
>>> doesn't scale as well as the BackupManager);
>>
>> Yes, I'm using default DeltaManager as I will only have two pods
>> running Tomcat.
>>
>>> - any requests made by the client that depend on the session MUST
>>> be issued in series, not in parallel; and
>>
>> Not sure about this one, the app uses spring default security for
>> login. So need to check this one.
>
>This has more to do with how your web application itself works and
>less about your security framework. For example, if you have a
>web-1.0-style web application which is mostly user-driven GET and POST
>requests, then you are probably fine with the occasional
>user-initiated page RELOAD or STOP/RELOAD or STOP/RETRY event.
>
>But if you have a web-2.0 style
>websocket/AJAX/many-things-happening-at-once-style application, then
>you are probably going to have problems without sticky sessions.

Yes, okay understood.
Webapp is a traditional request/reply jsp app. So nothing fancy going on.

>
>>> - the session Manager must be configured to update all the other
>>> nodes in the cluster BEFORE the current request returns to the
>>> client.
>>
>> How to do that? I did have a look at Manager/DeltaManager
>> attributes but didn't see something that looks like above setting.
>> Can you plea point me in the right direction?
>
>http://tomcat.apache.org/tomcat-9.0-doc/cluster-howto.html#Cluster_Infor
>mation
>
>This is done using channelSendOptions on the  and
>mapSendOptions on the ReplicationValve. The default value is to be
>synchronous, which would be required, here. Synchronous means that the
>data is replicated before the response is completed to the client. You
>could also do asynchronous which would allow the request to complete
>and queue the replication for "later" (but probably pretty shortly
>thereafter).

Yes I also found out that simple tcp cluster had this option, but async is the 
default for some reason:

https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/ha/tcp/SimpleTcpCluster.java#L152

I tried ack and sync-ack but I still see "session not found errors".

I'll check replication valve setting.

In the meantime I also did enable tribes message logging, and tried to find out 
what goes wrong, but have not yet fully understand the problem.

The error seems to happen in springs csrf filter which stores a uuid token in 
the http sessions.
Also a change session id happens in between. Everything looks actually okay, 
but it doesn't work.

>
>>>> 2) does session replication only work correctly with sticky
>>>> load
>>> balancer routing?
>>>
>>> No. It works quite happily without it.
>>
>> Good to know.
>
>You might want to use sticky-sessions anyway.
>
>>>> My setup is 1) load balancer without sticky session routing
>>>> into kubernetes 2) two pods running tomcat with cloud member
>>>> provider, which see and
>>> find each other
>>>>
>>>> No jvmRoute attribute is set.
>>
>> Another question regarding jvmRoute: Even if my load balancer has
>> no sticky sessions, should I add jvmRoute attribute? I think I
>> could easily add the pod's name as jvmRoute.
>
>If it's no particular trouble, I would:
>
>1. Add jvmRoute
>2. Enable sticky sessions
>
>#2 just means that all requests for an session-holding client will be
>directed to a single Tomcat node. If fail-over is necessary, the other
>node will have the session-information that was last sent successfully
>and should be relatively up-to-date. The session-id will be changed
>upon fail-over and the user shouldn't really notice unless some
>replication message was lost.
>
>IMHO the o

Re: Tomcat session replication

2020-06-27 Thread Thomas Meyer
Am 27. Juni 2020 11:29:03 MESZ schrieb Mark Thomas :
>On 27/06/2020 10:19, Thomas Meyer wrote:
>> Hi,
>> 
>> A few questions regarding tomcat session replication:
>
>load-balancing and session replication are two separate parts of an
>overall clustering solution.
>
>> 1) is the jvmRoute attribute on Engine object necessary for session
>replication to work correctly?
>
>No, but if you don't use it it places a number of restrictions on the
>web application behaviour and on the configuration of session
>replication.
>
>The limitations are:
>- you need to use the DeltaManager (which doesn't scale as well as the
>  BackupManager);

Yes, I'm using default DeltaManager as I will only have two pods running Tomcat.

>- any requests made by the client that depend on the session MUST be
>  issued in series, not in parallel; and

Not sure about this one, the app uses spring default security for login. So 
need to check this one.

>- the session Manager must be configured to update all the other nodes
>  in the cluster BEFORE the current request returns to the client.

How to do that? I did have a look at Manager/DeltaManager attributes but didn't 
see something that looks like above setting. Can you plea point me in the right 
direction?

>
>> 2) does session replication only work correctly with sticky load
>balancer routing?
>
>No. It works quite happily without it.

Good to know.

>
>> 
>> My setup is
>> 1) load balancer without sticky session routing into kubernetes
>> 2) two pods running tomcat with cloud member provider, which see and
>find each other
>> 
>> No jvmRoute attribute is set.

Another question regarding jvmRoute:
Even if my load balancer has no sticky sessions, should I add jvmRoute 
attribute? I think I could easily add the pod's name as jvmRoute.

>> 
>> Above setup doesn't work and give strange errors for the distributed
>webapp which relies on http sessions.
>> 
>> Should above setup work? If not why and what do I need to fix?
>> 
>> Any hints of what logging to enable to debug the problem if any at
>all?
>
>Please show us how you have configured the session manager and
>clustering.

My setup is just go with the defaults:







In the logs I can see the member appears/disappears messages, which is a good 
thing I guess.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Tomcat session replication

2020-06-27 Thread Thomas Meyer
Hi,

A few questions regarding tomcat session replication:

1) is the jvmRoute attribute on Engine object necessary for session replication 
to work correctly?
2) does session replication only work correctly with sticky load balancer 
routing?

My setup is
1) load balancer without sticky session routing into kubernetes
2) two pods running tomcat with cloud member provider, which see and find each 
other

No jvmRoute attribute is set.

Above setup doesn't work and give strange errors for the distributed webapp 
which relies on http sessions.

Should above setup work? If not why and what do I need to fix?

Any hints of what logging to enable to debug the problem if any at all?
Mfg
Thomas

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: JNI memory leak?

2020-04-04 Thread Thomas Meyer
Am 4. April 2020 14:53:17 MESZ schrieb calder :
>On Fri, Apr 3, 2020 at 8:48 PM Mark Boon 
>wrote:
>>
>> For the past few months we’ve been trying to trace what looks like
>gradual memory creep. After some long-running experiments it seems due
>to memory leaking when
>> jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType,
>_jmethodID*, JNI_ArgumentPusher*, Thread*) is invoked. Somewhere.
>>
>> My environment is Tomcat running a proxy webapp. It does TLS
>termination,  authentication and then forwards the call to local
>services. It doesn’t do much else, it’s a relatively small application.
>>
>> Some (possibly relevant) versions and config parameters:
>> Tomcat 8.5
>> Java 8u241 (Oracle)
>> Heap size = 360Mb
>> MAX_ALLOC_ARENA=2
>> MALLOC_TRIM_THRESHOLD_=250048
>> jdk.nio.maxCachedBufferSize=25600
>>
>> We couldn’t find any proof of memory leaking on the Java side.
>> When we turn on NativeMemoryTracking=detail and we take a snapshot
>shortly after starting, we see (just one block shown):
>>
>> [0x03530e462f9a] JNIHandleBlock::allocate_block(Thread*)+0xaa
>> [0x03530e3f759a] JavaCallWrapper::JavaCallWrapper(methodHandle,
>Handle, JavaValue*, Thread*)+0x6a
>> [0x03530e3fa000] JavaCalls::call_helper(JavaValue*,
>methodHandle*, JavaCallArguments*, Thread*)+0x8f0
>> [0x03530e4454a1] jni_invoke_static(JNIEnv_*, JavaValue*,
>_jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*)
>[clone .isra.96] [clone .constprop.117]+0x1e1
>>  (malloc=33783KB type=Internal #110876)
>>
>> Then we run it under heavy load for a few weeks and take another
>snapshot:
>>
>> [0x03530e462f9a] JNIHandleBlock::allocate_block(Thread*)+0xaa
>> [0x03530e3f759a] JavaCallWrapper::JavaCallWrapper(methodHandle,
>Handle, JavaValue*, Thread*)+0x6a
>> [0x03530e3fa000] JavaCalls::call_helper(JavaValue*,
>methodHandle*, JavaCallArguments*, Thread*)+0x8f0
>> [0x03530e4454a1] jni_invoke_static(JNIEnv_*, JavaValue*,
>_jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*)
>[clone .isra.96] [clone .constprop.117]+0x1e1
>>  (malloc=726749KB type=Internal #2385226)
>>
>> While other blocks also show some variation, none show growth like
>this one. When I do some math on the number (726749KB - 33783KB) /
>(2385226 – 110876) it comes down to a pretty even 312 bytes per
>allocation.
>> And we leaked just under 700Mb. While not immediately problematic,
>this does not bode well for our customers who run this service for
>months.
>>
>> I’d like to avoid telling them they need to restart this service
>every two weeks to reclaim memory. Has anyone seen something like this?
>Any way it could be avoided?
>
>I'm a bit confused. Your stated title is "JNI Memory Leak?"
>Tomcat, to my intimate knowledge, does not use JNI (correct me if I'm
>rwong)
>( quick check
> user@stimpy:~/Desktop/tomcat-source/apache-tomcat-8.5.53-src> find .
>-name *.c -ls
> user@stimpy:~/Desktop/tomcat-source/apache-tomcat-8.5.53-src> find .
>-name *.cpp -ls
> user@stimpy:~/Desktop/tomcat-source/apache-tomcat-8.5.53-src> find .
>-name *.asm -ls
> user@stimpy:~/Desktop/tomcat-source/apache-tomcat-8.5.53-src> find .
>-name *.pas -ls
>}
>
>a) for the "snapshots" provided, there is NO reference to their
>association, ie, "what" code are those related to?
>b) could you run Mission Control or jvisualvm to locate a stack trace
>for this?
>
>We have two apps that use JNI and run via Tomcat (and another app
>server) - one is "so old" that it is limited to 32-bit . the one
>memory leak we have encountered was related to the "native side" (for
>us, the native-compiled Pascal side of things (we also use Assembly
>code) via Java's JNI code).
>
>So, ultimately, I'm confused why we think Tomcat is "to blame" as
>there is no evidence it uses JNI.
>It's my experience JNI memory issues are related to the Java JNI or
>proprietary native code.
>
>-
>To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>For additional commands, e-mail: users-h...@tomcat.apache.org

Hi,

I think jni is used via apr in tomcat.

Do you use apr http connector?
-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Client cert auth on demand

2020-02-29 Thread Thomas Meyer
Am 29. Februar 2020 13:10:13 MEZ schrieb Mark Thomas :
>On 29/02/2020 11:23, Michael Osipov wrote:
>> Am 2020-02-29 um 12:13 schrieb Mark Thomas:
>>> On 29/02/2020 11:07, Michael Osipov wrote:
 Am 2020-02-29 um 12:05 schrieb Mark Thomas:
> On 29/02/2020 10:40, Michael Osipov wrote:
>>>
>>> 
>>>
>> Tomcat does not support renegotiation of TLS contexts based
>> on URLs like HTTPd.
>
> Yes it does.
>
> If you specify CLIENT-CERT auth for a sub-set of URLs Tomcat will
> trigger a renegotiation when one of those URLs is requested.
>
> You don't have the same fine-grained control you have in httpd but
>you
> can replicate the typical use cases.

 Really? If I say require client cert auth on the connector, it will
>be
 enforced even on those contexts which do not require
>authentication?!
>>>
>>> If you required auth on the connector it always applies.
>>>
>>> However, if you don't require it at the connector level you can
>require
>>> it for a subset of URLs with security constraints and Tomcat will
>>> trigger any required renegotiations.
>> 
>> Mark,
>> 
>> this makes me wonder whether Tomcat properly implements RFC 7540,
>> section 9.2.1 and RFC 8740, section 3. From my understanding the
>> configuration you have described MUST fail here.
>
>Those aspects of those specs are implemented correctly. Authentication
>will fail for both HTTP/2 and TLS 1.3 if a web application level
>security constraint tries to trigger renegotiation.
>
>For HTTP/2 and/or TLS 1/3 you can only configure client certificate
>authentication on the Connector.

Hi,

Oh, I didn't know that. Why exactly is that? Becaus of the multiplexing on 
http2 or something in tls1.3, or asked the oth way around, will it fail only 
for http2 && tls1.3 or for http2 || tls1.3

>
>Mark
>
>-
>To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>For additional commands, e-mail: users-h...@tomcat.apache.org


-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Client cert auth on demand

2020-02-29 Thread Thomas Meyer
Am 27. Februar 2020 10:58:01 MEZ schrieb "Martynas Jusevičius" 
:
>Hi list,
>
>I'm using a Docker image based on tomcat:8.0-jre8. It serves as an
>end-user facing webapp but also as a REST API which authenticates
>using client certificates. The same URLs serve both purposes, however
>only administrators are using the API.
>
>The Connector is configured using clientAuth="want".
>This works fine with API calls which are run from shell scripts.
>In the browser however it prompts a certificate selection (if there
>are any client certs). This would not be a problem if the webapp would
>not be user-facing, but since it is the certificate prompt can be
>confusing to many users and increase our bounce rate.
>
>I'm looking for some workaround that would not require changing the
>whole design. For example asking for the client cert only when a
>certain flag is set, such as a query param or request header.
>Or somehow not asking for it but still accepting it :) But I guess
>that's not how TLS works...
>
>Any ideas? Thanks.
>
>
>Martynas
>atomgraph.com
>
>-
>To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>For additional commands, e-mail: users-h...@tomcat.apache.org

Hi,

Instead of configuring the container for client cert Auth change the webapp:
1) define a realm in local context.xml
2) add resp security constraint only for rest api calls

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: PooledConnection#connectUsingDriver, Thread.currentThread().getContextClassLoader() is null

2019-07-25 Thread Thomas Meyer
Am 25. Juli 2019 08:07:18 MESZ schrieb Clemens Wyss DEV :
>Note: I have moved this "issue" over to the tomcat-dev mailinglist ...
>
>-Ursprüngliche Nachricht-
>Von: Clemens Wyss DEV  
>Gesendet: Mittwoch, 24. Juli 2019 11:07
>An: 'Tomcat Users List' 
>Betreff: PooledConnection#connectUsingDriver,
>Thread.currentThread().getContextClassLoader() is null
>
>Context:
>Debian GNU/Linux 9 \n \l
>java version 1.8.0_162
>Tomcat 8.5.35
>
>From time to time we are facing the follwing exception (call stack):
>...
>Caused by: java.sql.SQLException: Unable to load class:
>org.mariadb.jdbc.Driver from
>ClassLoader:java.net.URLClassLoader@4c873330;ClassLoader:null
>at
>org.apache.tomcat.jdbc.pool.PooledConnection.connectUsingDriver(PooledConnection.java:292)
>at
>org.apache.tomcat.jdbc.pool.PooledConnection.connect(PooledConnection.java:212)
>at
>org.apache.tomcat.jdbc.pool.ConnectionPool.createConnection(ConnectionPool.java:736)
>at
>org.apache.tomcat.jdbc.pool.ConnectionPool.borrowConnection(ConnectionPool.java:668)
>at
>org.apache.tomcat.jdbc.pool.ConnectionPool.getConnection(ConnectionPool.java:198)
>at
>org.apache.tomcat.jdbc.pool.DataSourceProxy.getConnection(DataSourceProxy.java:132)
>at org.apache.torque.Torque.getConnection(Torque.java:924)
>... 53 common frames omitted
>Caused by: java.lang.ClassNotFoundException: Unable to load class:
>org.mariadb.jdbc.Driver from
>ClassLoader:java.net.URLClassLoader@4c873330;ClassLoader:null
>at
>org.apache.tomcat.jdbc.pool.ClassLoaderUtil.loadClass(ClassLoaderUtil.java:56)
>at
>org.apache.tomcat.jdbc.pool.PooledConnection.connectUsingDriver(PooledConnection.java:280)
>... 59 common frames omitted
>Caused by: java.lang.ClassNotFoundException: Classloader is null
>at
>org.apache.tomcat.jdbc.pool.ClassLoaderUtil.loadClass(ClassLoaderUtil.java:40)
>... 60 common frames omitted
>
>According to the code (in PooledConnection# connectUsingDriver)
>Thread.currentThread().getContextClassLoader() returns null
>
>Googling for " Thread.currentThread().getContextClassLoader() is null"
>the common demoniator seems to be `getContextClassLoader can be null`.
>If this is true there should be
>a) a null-check in PooledConnection# connectUsingDriver
>b) if null, then there should be a fallback-Classloader (the system
>class laoder?)
>
>WDYT ?
>
>Or any ideas why the given exception pops up from time to time
>
>Thx
>Clemens
>B�CB��[��X��ܚX�KK[XZ[
>�\�\��][��X��ܚX�P�X�]
>�\X�K�ܙ�B��܈Y][ۘ[��[X[��K[XZ[
>�\�\��Z[�X�]
>�\X�K�ܙ�B�
>
>-
>To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>For additional commands, e-mail: users-h...@tomcat.apache.org
>>

Hi,

Is the driver part of the web app or installed in tomcat's lib directory?

Does the error happen after startup of tomcat or after running for some time?

With kind regards
Thomas
-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: [ANN] Apache Tomcat 8.5.43 available

2019-07-10 Thread Thomas Meyer
Am 10. Juli 2019 13:06:50 MESZ schrieb Mark Thomas :

Hi,

>The notable changes since 8.5.42
>include:
>- Update to Tomcat Native 1.2.23 including Windows binaries built
>  with OpenSSL 1.1.1c

Btw. are the prebuild tomcat native libraries are also available from maven 
central?
If not, could they be made available?


With kind regards
Thomas

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



AW: Tomcat Hackathon - Brussels Belgium - 4/5 May 2019

2019-04-04 Thread Thomas Meyer
Hi,

a PropertySource that uses environment variables as source would be nice.
I.e. an OpenShift/Kubernetes Secret mapped into environemnt variables that can 
be used in server.xml or context.xml!

With Kind regards
Thomas


Von: Mark Thomas
Gesendet: Donnerstag, 4. April 2019 16:29
An: Tomcat Users List
Cc: Tomcat Developers List
Betreff: Tomcat Hackathon - Brussels Belgium - 4/5 May 2019

All,

You are invited!

As part of the EU-FOSSA 2 project[1], there will be a Tomcat Hackathon 
in Brussels, Belgium on 4-5 May 2019.[2]

The outline of the schedule is:
- general update on the status of the project
- hacking
- wrap-up
with the majority of the time spent hacking.

We are currently collating potential tasks on the wiki [3].

The EU-FOSSA 2 project is providing accommodation (on the basis of 2 
people sharing - you can request a single room if you want to pay the 
difference) and might be able to help with transport costs.

Space is limited so we are asking anyone who would like to attend this 
hackathon and contribute to the development of Tomcat to send an e-mail 
to priv...@tomcat.apache.org with the following information:

- First name
- Last name
- Email address
- Phone number
- City of departure
- Area you would like to work on
   (Feel free to add ideas directly to the wiki as well)

Time is fairly tight so if you are interested please let us know ASAP.

We hope to see you in Brussels

Mark
on behalf of the Apache Tomcat PMC


[1] https://joinup.ec.europa.eu/collection/eu-fossa-2
[2] https://eufossahackathon.bemyapp.com/
[3] https://cwiki.apache.org/confluence/display/TOMCAT/EU+FOSSA+May+2019


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org




How to add an header field to all requests unconditionally

2019-03-13 Thread Thomas Meyer

Hi,

what would be the easiest way to uncoditionally add an header field to  
all requests coming from a given connector?
I searched the provided Valves but there seems to be no support for my  
requirment.


with kind regards
thomas




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Thread.sleep CPU time

2017-05-10 Thread Thomas Meyer

> Am 10.05.2017 um 12:02 schrieb Oliver Fernandez 
> :
> 
> But, is it correct Thread to be sleep?

Basically yes. But Brendan Gregg had yesterday an interesting article about CPU 
utilization in modern OSes -  
http://brendangregg.com/blog/2017-05-09/cpu-utilization-is-wrong.html


> 
>> On 10 May 2017 at 10:43, Oliver Fernandez  
>> wrote:
>> So basically we can consider this time as CPU being idle, right?
>> 
>> 
>>> On 10 May 2017 at 10:15, Mark Thomas  wrote:
>>> On 10/05/17 09:02, Oliver Fernandez wrote:
>>> > Sorry about the image. Here's in text format
>>> >
>>> > 
>>> >
>>> >  - org.apache.tomcat.utils.trheads.TaskThreadWrappingRunnable.run() --->
>>> > 42% CPU. This is my webapp code. It's OK
>>> >
>>> >  - org.apache.coyote.AbstractProtocol$AsyncTimeout.run()
>>> > - AbstractProtocol.java:1138 [Wall Time]
>>> > java.lang.Thread.sleep(long) > 38% CPU
>>> >
>>> >  - 
>>> > org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run()
>>> > - ContainerBase.java:1355 [Wall Time] java.lang.Thread.sleep(long)
>>> > --> 19%
>>> 
>>> You are looking at wall time, not CPU time so those values look fine.
>>> For an explanation of the differences see the YourKit docs:
>>> https://www.yourkit.com/docs/java/help/times.jsp
>>> 
>>> Mark
>>> 
>>> 
>>> >
>>> >
>>> > I'm not sure what this means. is it just that the CPU is IDLE waiting
>>> > for other tasks to complete?
>>> >
>>> >
>>> > On 10 May 2017 at 09:53, Stevo Slavić >> > > wrote:
>>> >
>>> > Maybe sleep call is in a loop - busy waiting, and sleeping too
>>> > short. Sleep
>>> > longer, observe latency after the change. In Java 9 there will be 
>>> > extra
>>> > option
>>> > 
>>> > http://download.java.net/java/jdk9/docs/api/java/lang/Thread.html#onSpinWait--
>>> > 
>>> > 
>>> >
>>> > On Wed, May 10, 2017 at 9:44 AM, Oliver Fernandez <
>>> > oliver.fernan...@marfeel.com >
>>> > wrote:
>>> >
>>> > > While profiling my Tomcat app using YourKit, I noticed two Threads,
>>> > > consuming 57% of total CPU, in the method Thread.sleep()
>>> > >
>>> > > [image: Inline images 1]
>>> > >
>>> > > What's this Thread.sleep() about?
>>> > >
>>> > >
>>> > >
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> >
>>> > *Óliver Fernández*
>>> >
>>> > Principal Architect
>>> >
>>> >
>>> > Inline image 2
>>> >
>>> >
>>> >
>>> >
>>> > Marfeel Solutions S.L.
>>> >
>>> > Rambla Catalunya 35, Principal 2ª
>>> >
>>> > 08007 Barcelona, Spain
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > ES: (+34) 93 178 59 50  ext. 106
>>> >
>>> > US: (+1) 917-341-2540  ext. 106
>>> >
>>> > UK: (+44) 207-048-37-28  ext. 106
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > www.marfeel.com 
>>> >
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>> 
>> 
>> 
>> 
>> -- 
>> Óliver Fernández
>> Principal Architect
>> 
>> 
>> 
>> 
>> Marfeel Solutions S.L.
>> Rambla Catalunya 35, Principal 2ª
>> 08007 Barcelona, Spain
>> 
>> 
>> 
>> ES: (+34) 93 178 59 50 ext. 106
>> US: (+1) 917-341-2540 ext. 106
>> UK: (+44) 207-048-37-28 ext. 106
>> 
>> 
>> www.marfeel.com  
> 
> 
> 
> -- 
> Óliver Fernández
> Principal Architect
> 
> 
> 
> 
> Marfeel Solutions S.L.
> Rambla Catalunya 35, Principal 2ª
> 08007 Barcelona, Spain
> 
> 
> 
> ES: (+34) 93 178 59 50 ext. 106
> US: (+1) 917-341-2540 ext. 106
> UK: (+44) 207-048-37-28 ext. 106
> 
> 
> www.marfeel.com  


Tomcat base directory layout

2017-03-25 Thread Thomas Meyer
Hi,

Does there exists a small helper tool that can create the minimum necessary 
directories and files in a new CATALINA-BASE directory ? Or a template zip file 
or something like this?

Such a tool would be helpful, because I always struggle what directories are 
minimum necessary to  start a new instance.


With kind regards
Thomas

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Tomcat 8/Redhat Linux 6.6 /Kernal 2.6.32 - Memory Won't Release

2017-03-20 Thread Thomas Meyer



With kind regards
Thomas
> Am 17.03.2017 um 14:54 schrieb Christopher Schultz 
> :
>> Note that Java *never* gives any memory back to the OS, even when the
> heap-usage goes down. This is a Java thing, not a Tomcat thing.
> 

Are you sure about this? I think I've read otherwise somewhere. A quick google 
showed up this: http://stackoverflow.com/a/30464183

With kind regards
Thomas



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Spring fails with Tomcat 8.0.41 and unpackWARs=false

2017-03-08 Thread Thomas Meyer


Hi,

if anybody else is hitting this:

This commit seems to have broken the Spring when running under Tomcat  
with unpackWARs=false -  
https://github.com/apache/tomcat80/commit/7e767cc6efe79cdd367213da3c1f88711a29ad7a#diff-a72fb99b0729353084d2c437f749e718


I did open a Jira Bug report against Spring  
https://jira.spring.io/browse/SPR-15332 to track the issue.


with kind regards
thomas




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Best way to find out how many DB connections that are open at any given time

2017-01-12 Thread Thomas Meyer
You may also want to have a look at flexy pool - 
https://github.com/vladmihalcea/flexy-pool 

With kind regards
Thomas


With kind regards
Thomas

> Am 11.01.2017 um 01:36 schrieb Joleen Barker :
> 
> As always, thank you Christopher, I'll take a look at the slides.
> 
> And Thank you to the other for pointing me in some directions for this.
> 
> -Joleen
> 
> On Tue, Jan 10, 2017 at 3:19 PM, Christopher Schultz <
> ch...@christopherschultz.net> wrote:
> 
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>> 
>> Joleen,
>> 
>>> On 1/10/17 11:10 AM, Joleen Barker wrote:
>>> Hello All,
>>> 
>>> Details: Tomcat Version: 7.0.64.0 Java Version: 1.8.0 OS: AIX 6.1
>>> Database: Oracle 11
>>> 
>>> The web application installed on the server above makes data
>>> connections to run file transfers from point A to point B. The
>>> default Database connection setting that are set when the
>>> application server comes up are as follows:
>>> 
>>> DataBasePoolingFlag - APACHE MaxActive - 400 MaxIdle - 20 MinIdle -
>>> 10
>>> 
>>> We had an incident where all these connections were actually used
>>> up due to a script someone had that looped. I need to determine at
>>> any given point in time how many DB connections exist from the web
>>> application to the DB. There may be more than one way to do this. I
>>> am sure there is a DB command that could be run against the schema
>>> but the schema is pointed to by many servers. I am  wondering if
>>> there is a java command of some kind that I could run that may tell
>>> me how many connections are open at that time or possibly a tomcat
>>> or apache command.
>> 
>> This may be helpful:
>> 
>> http://people.apache.org/~schultz/ApacheCon%20NA%202016/Monitoring%20Apa
>> che%20Tomcat%20with%20JMX.pdf
>> 
>> Slides 15-16 show you where you can find the DataSource information
>> via JMX, and then later on in the presentation there are slides to
>> show how you can get that information via HTTP instead of JMX. Scripts
>> are provided to fetch a value at intervals, track values over time, etc.
>> 
>> - -chris
>> -BEGIN PGP SIGNATURE-
>> Comment: GPGTools - http://gpgtools.org
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>> 
>> iQIcBAEBCAAGBQJYdUHCAAoJEBzwKT+lPKRY8lAP/0C6wfLboz4K2MxaHR/86moX
>> sKIev9jV+wQ17n0nf1Wj1UA7GDGALye485Z2XMgIjlOaXmufVClfa3MWY07z+bv2
>> R67AmDQ797jlCwTAAhpaRtB0FJmX4cd0EnJkC9r03NCH+kPRIK8G91bkgn8ehw4L
>> x0jrgKO/N0UEpshNI/baPxRJRX7yr83g2ZHiKVoFAXM25rEcJNSPOkvlTkBxZ5Yv
>> RCQuobinJa9X64p8beYXSkO/9wbP+b5/wcUxpewfvByK9Hits+n33/Mbq5RpKlR7
>> vIHpwDJKlTo2/8ivIDHngIPiRQetlXEgwSWwN+5Fsr+V4bFSh6XnzIBAiB8SNoua
>> A9m71pyOoyQhdAAQzNfWwtLPWg9jrDaIRB7bj+HnbrKnCUa4rDyWfUDm4IwanfLW
>> QcDUggAgD151UstbSAQafLKJb0TBCWqHpIAvsJwCziOb6LnvtIf5xoLe7s48JZE9
>> 44YfDFI4qg0NSdP59vF/Z1Ho5sveScHrcgmB03BGWVunj9caclqKOWWnJOscAVLJ
>> UXQG0B6VvboLJRgKUU4/z0s1a2sOcTLRUz+H1Ib9giqLirI6NVYUSg0lEZdVm5BA
>> 0Ctwd6qD7G1j8e4ZiuChC3paCA0nYVhEea0dAVHXB+ZYER89yeoBzPkZnc/vWLEe
>> LO1AZaxZ2nDebk0ubBn9
>> =JgPw
>> -END PGP SIGNATURE-
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>> 
>> 


smime.p7s
Description: S/MIME cryptographic signature


Re: Custom Authenticator

2016-06-04 Thread Thomas Meyer
Am Mittwoch, den 01.06.2016, 09:29 -0400 schrieb Christopher Schultz:
> Thomas,
> 
> On 6/1/16 7:15 AM, Thomas Meyer wrote:
> > 
> > Hi,
> > 
> > How do I get a custom mapping set in 
> > ContextConfig.setCustomAuthenticators? ( 
> > https://tomcat.apache.org/tomcat-8.0-doc/api/org/apache/catalina/st
> > art
> up/ContextConfig.html#setCustomAuthenticators(java.util.Map)
> > 
> > 
> > 
> )
> > 
> > 
> > I want to add a custom mapping for lets say BEARER to a my
> > Authenticator. I searched the source code but nobody seems to call
> > this method. So how and where should this map be configured?
> Do you mean that you want to replace FORM or CLIENT-CERT in web.xml
> with BEARER and have it use your authenticator?
> 
> Would you be okay if you just ignored the  and installed
> your own authenticator? Because you can do that just by registering
> your CustomAuthenticatorValve in your valve chain for your
> application.


Hi,

I came up with this solution:

1.) use custom host implementation

in conf/server.xml in  add
className="de.m3y3r.catalina.core.CustomStandardHost" attribute

2.) webapp's web.xml - add login-config


  BEARER
  OAuthRealm


Apply security-constraint as usual. use role "**" if you just want
authentication.

3.) in webapp's context.xml define a suitable realm

https://localhost:8080/path/to/endpoint;
    clientId="username"
    clientSecret="password"/>

Code is here: https://github.com/thomasmey/BearerTokenAuthenticator

Feedback is welcome.

with kind regard
Thomas


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Custom Authenticator

2016-06-01 Thread Thomas Meyer

Hi,

How do I get a custom mapping set in  
ContextConfig.setCustomAuthenticators? (  
https://tomcat.apache.org/tomcat-8.0-doc/api/org/apache/catalina/startup/ContextConfig.html#setCustomAuthenticators(java.util.Map)  
)


I want to add a custom mapping for lets say BEARER to a my Authenticator.
I searched the source code but nobody seems to call this method. So  
how and where should this map be configured?


With kind regards
Thomas


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Question regarding parseRequestLine

2016-05-10 Thread Thomas Meyer
Hi,

I noticed that I can block tomcat 8 by opening 200 connection to the
http 1.1 connector and send 512 bytes of zero in each connection.

Tomcat 8 seems to block in parseRequestLine() method for 20 seconds
(connectionTimeout) and times out after that.

The blocking seems to happen while waiting for the http method name.

I looked up RFC 2616 and byte zero is as far as I understand not a
legal character for the http method name which are GET, PUT and so on
and extension token which is defined as token which is defined as all
characters excluding 0-31 and 127.
So why doesn't tomcat trash the connection when it detects an invalid
http method name?

Is this behaviour just a super tolerant implementation?

Bug or feature? I'm curious to know the background of this
behaviour/implementation!

With kind regards
Thomas

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org