Re: AJP Connector not throwing EOFException

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Emanuel,

On 1/19/18 12:37 PM, Emanuel Hategan wrote:
> Forget about EOFException, that was my mistake in the first email
> (and subject). I'm interested in improved handling of aborted
> connections (at least most of them). That's my end goal.
> 
> read=-1 solely does not provide sufficient information to be able
> to distinguish between malformed request bodies and actual aborted 
> connections.

How is Tomcat supposed to determine the difference?

> That's why the ServletInputStream#readLine API says: Returns: an
> integer specifying the actual number of bytes read, or -1 if the
> end of the stream is reached Throws: IOException - if an input or
> output exception has occurred

End-of-stream is not an exceptional condition.

> I understand that detecting aborted connections is not always
> possible because of the missed handshakes but given that apache2
> and tomcat are most likely in the same local network and assuming
> the protocol closes sockets properly, as long as apache2 detects it
> tomcat should also.

You are talking about AJP, which does not close connections between
the reverse proxy (httpd) and Tomcat. So... what event are you looking
for that Tomcat can use to signal an error?

> I therefore think my expectation for an IOException when trying to
> read is justified.
> 
> Do you still think otherwise?

I do. It's not really up to Tomcat to verify that the client sent all
of the data it intended to send.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlpiXqodHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFihJQ/9HXNj4TycN6FXDZl5
0Gn5GY6y61rGkn2a+uzI8tDL/08Xf5/CsX/65MqIG3yc09DLRwkyzQ+jBVjrH1ES
6YGg8THT0RHZzokeT1x5dD2csgbP6ufx98rH4cnsXKEKlk7Ux7pQ4Qs4XdhBMFcJ
AAVMH6xBrtfQ3im/lxfSi/fDR3HF4u7z3WuLabneA2ZHzPvttpVFF9JkbW9JS/oU
2d4ESPjaPFvxJxM+P/7W/G0cSb2GEAuTyEgNqIELVwH1jx9K/zF2nuFA0RTvZ4Fe
H57q8FHd+lf8gR9XY1MSTWwVe6jF4sl1i0uWln8Pvct8Yiw6686Ibw0Vc4tX3Ohe
OfeJVKlGsTfJ76F3LP790GwtpP1lIjKe9/+wGQQjEw88/BElaM9FgKfG1s0yxx9p
gh4BiEwPLC1klRbbsjiWNyk+2b9awTf8UY0iHiuSkRT6T9gYW8MkirP71pw3Nb/o
9mbjd8qKioQZE7oK29n0prfk3PlZUlyeOTYxIlSjK7h2cs45GVrpa29sdArg3Eil
r6lfhfbIYj2YtGV1OEWVoV+ZB09IXCRYE2u7iBPqaaMz4Yuh64bmL/PJTk1YwHxK
psFGQ1j/a6338aP+rtBwNVprYspVQZQnwREvkjz+a8e7ogUIMFgJN+wh51iAOS43
pXGnGa3+KvMNfrGCGIV1iwbfSOo=
=sjFc
-END PGP SIGNATURE-

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

Re: Thread-safety with sessions

[Mark Thomas]

On 19/01/18 20:40, Christopher Schultz wrote:
> Mark,
> 
> On 1/19/18 3:04 AM, Mark Thomas wrote:
>> On 18/01/18 20:11, Christopher Schultz wrote:
>>> Speaking of "expensive" objects, we do have a "user" object in
>>> the session. If the user isn't there, we throw all kinds of
>>> exceptions and don't let "users" actually do anything except go
>>> to their login pages.
>>>
>>> So I expect that I can (a) always rely on a "user" attribute
>>> being in the session and (b) I can use that as my monitor.
> 
>> I'd check how it is wrapped before you do that. From memory, I'm
>> not sure the same wrapper will always be used.
> 
> That "user" attribute is application-defined. I don't believe Tomcat
> wraps any application objects that are stored in the session, does it?
> Or did I misunderstand your statement?

No. I mis-understood your use of 'we'. I thought you meant Tomcat.

Tomcat won't wrap an application defined objects.

Mark

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

Re: Thread-safety with sessions

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 1/19/18 3:04 AM, Mark Thomas wrote:
> On 18/01/18 20:11, Christopher Schultz wrote:
>> Speaking of "expensive" objects, we do have a "user" object in
>> the session. If the user isn't there, we throw all kinds of
>> exceptions and don't let "users" actually do anything except go
>> to their login pages.
>> 
>> So I expect that I can (a) always rely on a "user" attribute
>> being in the session and (b) I can use that as my monitor.
> 
> I'd check how it is wrapped before you do that. From memory, I'm
> not sure the same wrapper will always be used.

That "user" attribute is application-defined. I don't believe Tomcat
wraps any application objects that are stored in the session, does it?
Or did I misunderstand your statement?

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlpiV6AdHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFjo3Q//f26EdB+Xc5BP+P2x
HaYL4/U/re+ZobWVm1RDCl0MZtyouD8D6IugH+/G4HTDtHE2XB/M/8uin/wCfnbR
ay96rMgpJfbqjNjLf407dafIyWbrF5gwaefnpXvYurLr1XPOIaTbFA4Ky1wTlbMG
3xPtfLL8JbVFExINvLy/JWnKhigkKP76ANiT31rQC6VCA3CGNIFgFFogtI8FcSoD
Z3ZYbJJAGJcOUX5xQoVYa0kvtnHgtIlRan69gZIds6uZSskjjiUlc/Hbe/U0Tdlq
u01MM66cpoy6+tUnoIoy74jeNwiUu57q03WvUKI7DSxMBXW07aG2M2itfv9iqpYq
zQJZsWUal7eQc9p6jwPwpXDc0Swk/hTT1Ya81goBxLfnYAKplP8ujgzpQCc0e9Q+
TZ9hpAGEWYdkt3Jh0jfbUrYJmXjeEFxoPZIIZciRZx7cWoGpSp5luysF4dFSzaYU
PuhNSP1s7JY6b+4PE8sew71mOKuou2hwhjytbtt1Q4IBN9QPYJEA4AApy9yvhjmX
Y8Ow+3IZO0TuE6dnYcMzgB9L2qijc/8grsrZUXMZo4HIKdTxoO32aa+hMH1AOgrF
72Eppb+zhUzkss6CYTCN3mSq4ISSQ/zO7Io1vMT3ZpOX2fBkFwIsT2cYsYw8CGeJ
0tutnK+v4JYedEN4ttJsecfKLfk=
=tYJe
-END PGP SIGNATURE-

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

Supporting on-line deployment through JMX

[David Cleary]

We have web applications that require tailoring when being deployed. If Tomcat 
is running, we can start the context after tailoring with a deploy call to 
Manager. That is fine for development, but for production, the Manager web app 
is usually not there. Is there an mbean I can call that doesn't require the 
Manager web app?

Thanks
David Cleary
Progress Software

Re: Ajp Nio-thread stuck in loop and consuming a lot of cpu

[Mark Thomas]

On 19/01/2018 14:35, Toom Andreas wrote:
> Hi Mark,
> 
> Sorry for the late reply, it has been a couple of busy days.
> 
> We are running our application on two nodes and we have seen the issue on 
> both nodes. These machines are running quad core cpus. What we have usually 
> seen is that the application jvm process is consuming 100% (basically one 
> core) on one machine and 200% (2 cores) on the other machine. The cpu 
> usage/core usage seems to correlate quite well with the number of looping 
> threads that we can observe via jmx.
> 
> The load does not move between threads, it is pinned to the looping thread.
> 
> We have only observed this behavior on one application and only in 
> production. "Unfortunately" we did a deployment this week so both nodes have 
> been restarted which means that at the moment the cpu usage is down to almost 
> 0.
> 
> We are planning to update to Tomcat 8.5.x in the coming week (planned update, 
> not a forced update related to this issue). Are you aware of any major code 
> changes between the 8.0.x and 8.5.x branches related to this functionality  ?

There is a significant refactoring of the connectors between 8.0.x and
8.5.x to reduce code duplication, improve consistency of behaviour
between the implementations and to support HTTP/2.

Mark


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

Re: AJP Connector not throwing EOFException

[Emanuel Hategan]

Chris,

Emah,
>
> On 1/17/18 10:17 AM, emah wrote:
> > Chris,
> >
> >
> > Christopher Schultz-2 wrote
> >>> I'm running a tomcat 8.5.23 instance on ubuntu 16.04 (spring
> >>> boot application with embedded tomcat) configured with 2
> >>> connectors: Http11NioProtocol and AjpNioProtocol. The AJP one
> >>> is accessed through an apache2 instance configured with
> >>> mod_jk.It all works well in the normal use case.
> >>>
> >>> The application has code to look for the EOFExceptions during
> >>> read e.g. the client aborts the request which works well with
> >>> HTTP but not AJP. In my test I'm simulating this by closing
> >>> the connection half way through (some headers have been sent
> >>> but no body)
> >>>
> >>> The problem I'm seeing is an inconsistent behaviour for
> >>> CoyoteInputStream.read() The HTTP connector throws an
> >>> EOFException in this case while the AJP one just returns -1.
> >>>
> >>> The relevant call stack is this at
> >>> org.apache.coyote.ajp.AjpProcessor.refillReadBuffer(AjpProcessor.jav
> a:
> >>
> >>>
> >>>
> 684)
> >>>
> >>>
> >> at
> >>> org.apache.coyote.ajp.AjpProcessor$SocketInputBuffer.doRead(AjpProce
> ss
> >>
> >>>
> >>>
> or.java:1433)
> >>>
> >>>
> >> at org.apache.coyote.Request.doRead(Request.java:581)
> >>> at
> >>> org.apache.catalina.connector.InputBuffer.realReadBytes(InputBuffer.
> ja
> >>
> >>>
> >>>
> va:326)
> >>>
> >>>
> >> at
> >>> org.apache.catalina.connector.InputBuffer.checkByteBufferEof(InputBu
> ff
> >>
> >>>
> >>>
> er.java:642)
> >>>
> >>>
> >> at
> >>> org.apache.catalina.connector.InputBuffer.readByte(InputBuffer.java:
> 33
> >>
> >>>
> >>>
> 7)
> >>>
> >>>
> >> at
> >>> org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStre
> am
> >>
> >>>
> >>>
> .java:93)
> >>>
> >>> Now based on this old and unrelated thread
> >>> https://mail-archives.apache.org/mod_mbox/tomcat-users/201312.mbox/%
> 3C
> 
> >
> >>>
> >>>
> >> 15FF6F04-B4C9-4D9B-B1B3-5C10CA955AEE@
> >
> >> %3E
> >>>
> >>>
> >> I understand that the AJP connector is perfectly capable of
> >> raising an
> >>> EOFException but it's just not doing that for me.
> >>>
> >>> The documentation
> >>> https://tomcat.apache.org/tomcat-8.0-doc/config/ajp.html does
> >>> not suggest I need to do anything special.
> >>>
> >>> I guess it's possible that this has something to do with the
> >>> way apache2 talks to the AJP connector. Any help is
> >>> appreciated.
> >>
> >> Interesting.
> >>
> >> If your servlet simply reads the InputStream like this, you
> >> don't get an EOFException?
> >>
> >> ServletInputStream in = request.getInputStream(); for(;;)
> >> in.read();
> >>
> >> What part of the Servlet specification or Servlet API leads you
> >> to believe that EOFException should be thrown when the request
> >> has been completely read (or has been truncated, and no further
> >> data is available )?
> >>
> >> I don't see anything to suggest that such behavior is either
> >> required or expected.
> >>
> >> In fact, I'm surprised that the HTTP connector throws an
> >> EOFException instead of simply returning -1 like the API says it
> >> should.
> >>
> >> - -chris
> >
> > Let me first correct something I've said earlier:
> >
> > HTTP Connector will actually throw an IOException when ssl unwrap
> > fails (rather than an EOFException) in at
> > org.apache.tomcat.util.net.SecureNioChannel.read(SecureNioChannel.java
> :618)
> >
> >
> >
> at
> > org.apache.tomcat.util.net.NioBlockingSelector.read(NioBlockingSelecto
> r.java:173)
> >
> >
> >
> at
> > org.apache.tomcat.util.net.NioSelectorPool.read(NioSelectorPool.java:2
> 35)
> >
> >
> >
> at
> > org.apache.tomcat.util.net.NioSelectorPool.read(NioSelectorPool.java:2
> 16)
> >
> >
> >
> at
> > org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.fillReadBuffer
> (NioEndpoint.java:1241)
> >
> >
> >
> at
> > org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.read(NioEndpoi
> nt.java:1190)
> >
> >
> >
> at
> > org.apache.coyote.http11.Http11InputBuffer.fill(Http11InputBuffer.java
> :717)
> >
> >
> >
> at
> > org.apache.coyote.http11.Http11InputBuffer.access$300(Http11InputBuffe
> r.java:40)
> >
> >
> >
> at
> > org.apache.coyote.http11.Http11InputBuffer$SocketInputBuffer.doRead(Ht
> tp11InputBuffer.java:1072)
> >
> >
> >
> at
> > org.apache.coyote.http11.filters.IdentityInputFilter.doRead(IdentityIn
> putFilter.java:140)
> >
> >
> >
> at
> > org.apache.coyote.http11.Http11InputBuffer.doRead(Http11InputBuffer.ja
> va:261)
> >
> >
> >
> at org.apache.coyote.Request.doRead(Request.java:581)
> > at
> > org.apache.catalina.connector.InputBuffer.realReadBytes(InputBuffer.ja
> va:326)
> >
> >
> >
> at
> > org.apache.catalina.connector.InputBuffer.checkByteBufferEof(InputBuff
> er.java:642)
> >
> >
> >
> at
> > org.apache.catalina.connector.InputBuffer.readByte(InputBuffer.java:33
> 7)
> >
> >
> >
> at
> > org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream
> 

Re: release plan for tomcat 7.x for java9

[Violeta Georgieva]

Hi,

2018-01-19 14:18 GMT+02:00 Mukarram Baig :
>
> Thanks for the update, Mark.
>
> On 19/01/18 00:06, Mukarram Baig wrote:
> > Hey Mark
> >
> > Just wanted to see if there was an update to getting a new release.
>
> 9.0.x and 8.5.x are happening now. Best guess is 8.0.x and 7.0.x will
> follow.

We are currently voting Tomcat 7.0.84.
You may take a look at the proposed release, test it and provide feedback.

Here is a link to the voting
https://marc.info/?l=tomcat-dev=151637649125895=2

Regards,
Violeta

> Mark

Re: Tomcat release for java9

[Violeta Georgieva]

2018-01-19 18:45 GMT+02:00 Violeta Georgieva :
>
> Hi,
>
> 2018-01-19 15:17 GMT+02:00 Gupta, Shaina :
> >
> > Hello,
> >
> > Could you please let me know when can we expect a new release for
tomcat which would support java9.
> >
> > I can see that the endorsed directory related issue in tomcat 7.x for
running in java9 has been fixed in
https://github.com/apache/tomcat70/commit/e7ae8664922cd54fabe847527bad614bcd5ce301#diff-da184cf589a25174c11dc3f4dbaeb0b4
> >
>
> We are currently voting Tomcat 7.0.84.
> You may take a look at the proposed release, test it and provide feedback.
>

Here is a link to the voting
https://marc.info/?l=tomcat-dev=151637649125895=2

> Thanks,
> Violeta
>
> > Thanks,
> > Shaina
> >
> >
> >
> >   
> >
> > This message may contain confidential information protected by law. The
contents of this email are to be viewed only by the intended recipient. If
you received this message in error, notify the sender immediately and
delete the original message without printing. Product descriptions, pricing
and similar content is for information only and does not constitute an
offer, warranty or guarantee. Contracts with Arcesium are formed only by
written documents bearing the signature of its authorized representative.

Re: Tomcat release for java9

[Violeta Georgieva]

Hi,

2018-01-19 15:17 GMT+02:00 Gupta, Shaina :
>
> Hello,
>
> Could you please let me know when can we expect a new release for tomcat
which would support java9.
>
> I can see that the endorsed directory related issue in tomcat 7.x for
running in java9 has been fixed in
https://github.com/apache/tomcat70/commit/e7ae8664922cd54fabe847527bad614bcd5ce301#diff-da184cf589a25174c11dc3f4dbaeb0b4
>

We are currently voting Tomcat 7.0.84.
You may take a look at the proposed release, test it and provide feedback.

Thanks,
Violeta

> Thanks,
> Shaina
>
>
>
>   
>
> This message may contain confidential information protected by law. The
contents of this email are to be viewed only by the intended recipient. If
you received this message in error, notify the sender immediately and
delete the original message without printing. Product descriptions, pricing
and similar content is for information only and does not constitute an
offer, warranty or guarantee. Contracts with Arcesium are formed only by
written documents bearing the signature of its authorized representative.

Re: Accepted Encoding of Basic Auth Header

[tomcat]

On 19.01.2018 11:39, jose luis Calvo wrote:
NO ME ENVIEN MAS MENSAJES POR FAVOR

Para acabar con los mensajes, las intrucciones estan al final de cada mensaje :

To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org

Significa : desde el mismo buzón recibiendo estos mensajes no deseados, envia un correo a 
esta direccion, y es suficiente.





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

RE: Ajp Nio-thread stuck in loop and consuming a lot of cpu

[Toom Andreas]

Hi Rainer,

Thanks for your reply!

We did a restart of the application earlier this week and so far the cpu usage 
is at normal levels. If/when the cpu usage goes up I will check with your 
suggested parameters!

Best regards,
Andreas

-Original Message-
From: Rainer Jung [mailto:rainer.j...@kippdata.de] 
Sent: den 18 januari 2018 14:46
To: Tomcat Users List 
Subject: Re: Ajp Nio-thread stuck in loop and consuming a lot of cpu

Just an addition to one of Mark's questions:

Am 17.01.2018 um 22:20 schrieb Mark Thomas:
> Is it always the same threads generating the load or does it move 
> between threads?

Just in case Andreas is not aware: one can check with "top -H -p ".

Using -H lets top show one line per thread instead of one line per process. 
That way you can easily see CPU use per thread. The "-p " 
would simply filter to only show the threads in your java process (by using for 
 the process ID of your Tomcat java process).

Furthermore the PID column in "top -H" does not actually show the PID, but 
instead the thread IDs. If you convert that decimal numbers to hex, e.g. using 
the shell commandline

printf "0x%x\n" 

(and replacing  by the respective thread id of the lines that show high CPU 
usage), you get a hex number that will point you to the respective thread in 
the java thread dump by looking for tid=0x... in the thread header lines. The 
association between operating system thread number as shown in "top -H" and the 
tid in the Java thread dump does is stable during the lifetime of the process.

Regards,

Rainer

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

RE: Ajp Nio-thread stuck in loop and consuming a lot of cpu

[Toom Andreas]

Hi Mark,

Sorry for the late reply, it has been a couple of busy days.

We are running our application on two nodes and we have seen the issue on both 
nodes. These machines are running quad core cpus. What we have usually seen is 
that the application jvm process is consuming 100% (basically one core) on one 
machine and 200% (2 cores) on the other machine. The cpu usage/core usage seems 
to correlate quite well with the number of looping threads that we can observe 
via jmx.

The load does not move between threads, it is pinned to the looping thread.

We have only observed this behavior on one application and only in production. 
"Unfortunately" we did a deployment this week so both nodes have been restarted 
which means that at the moment the cpu usage is down to almost 0.

We are planning to update to Tomcat 8.5.x in the coming week (planned update, 
not a forced update related to this issue). Are you aware of any major code 
changes between the 8.0.x and 8.5.x branches related to this functionality  ?

Best regards,
Andreas

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: den 17 januari 2018 22:20
To: Tomcat Users List 
Subject: Re: Ajp Nio-thread stuck in loop and consuming a lot of cpu

On 16/01/18 23:21, Mark Thomas wrote:
> On 16/01/18 09:21, Toom Andreas wrote:
>> Hi Mark,
>>
>> We pulled out a CPU Call Tree using JVisualVM instead of YourKit and 
>> I have uploaded a screenshot of it here: https://imgur.com/a/mqYxn
>>
>> There is not much extra information compared to the java thread dump in my 
>> initial post but it highlights in which code branch/method call most of the 
>> cpu time is spent. Perhaps it will give some additional clues ? Let me know 
>> if you think that it is worthwhile to use YourKit instead of JVisualVM and I 
>> will try to get that for you instead.
> 
> Thanks. This has given me a couple of ideas. I need to do some more 
> testing. I hope to be able to get this done in the next day or so.

Unfortunately my ideas didn't pan out.

What levels of CPU usage are you observing?

Is it always the same threads generating the load or does it move between 
threads?

Can you reproduce this on a system you can attach a remote debugger to?

What we really need to do is understand the code path that is being taken and 
why. I can see the likely code path in the data we have so far but nothing that 
looks abnormal.

Mark


> 
> Mark
> 
> 
>>
>> Best regards,
>> Andreas
>>
>> -Original Message-
>> From: Mark Thomas [mailto:ma...@apache.org]
>> Sent: den 12 januari 2018 11:27
>> To: Tomcat Users List 
>> Subject: Re: Ajp Nio-thread stuck in loop and consuming a lot of cpu
>>
>> On 12/01/18 06:58, Toom Andreas wrote:
>>> Hi,
>>>
>>> We are having an issue with an application running Apache Tomcat 8.0.47 
>>> using Oracle Jvm 1.8.0.151 on Linux (RHEL 7). The Tomcat process is 
>>> consuming  cpu at a constant high level even though there is a low amount 
>>> of incoming traffic. When inspecting the process health using JMX 
>>> /JVisualVM CPU Sampler we see that there are 4 ajp-nio-exec threads 
>>> together with a NioBlockingSelector.BlockPoller thread that consume most of 
>>> the cpu.
>>
>> Are you able to determine the code path of the loop? A single stack trace 
>> can point us in the right direction but often the root cause can still be 
>> tricky to track down.
>>
>> A profiler such as YourKit in CPU tracing mode should be able to provide 
>> enough info to figure this out (and won't require any code changes to your 
>> system).
>>
>> Remote debugging is the other option but that is less ideal in production.
>>
>> Mark
>>
>>
>>>
>>> A stack trace of one of the ajp-io-exec threads looks like this:
>>>
>>> "ajp-nio-48317-exec-14233" - Thread t@201195
>>>java.lang.Thread.State: TIMED_WAITING
>>>  at sun.misc.Unsafe.park(Native Method)
>>>  - parking to wait for <342fab60> (a 
>>> java.util.concurrent.CountDownLatch$Sync)
>>>  at 
>>> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>>>  at 
>>> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
>>>  at 
>>> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
>>>  at 
>>> java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
>>>  at 
>>> org.apache.tomcat.util.net.NioEndpoint$KeyAttachment.awaitLatch(NioEndpoint.java:1400)
>>>  at 
>>> org.apache.tomcat.util.net.NioEndpoint$KeyAttachment.awaitReadLatch(NioEndpoint.java:1402)
>>>  at 
>>> org.apache.tomcat.util.net.NioBlockingSelector.read(NioBlockingSelector.java:185)
>>>   

RE: Ajp Nio-thread stuck in loop and consuming a lot of cpu

[Toom Andreas]

Hi Greg,

Thanks for looking into this issue. Unfortunately I am 100% sure we are running 
Tomcat 8.0.47 so the referenced patch/fix is already applied.

Best regards,
Andreas

-Original Message-
From: Greg Huber [mailto:gregh3...@gmail.com] 
Sent: den 18 januari 2018 14:56
To: Tomcat Users List 
Subject: Re: Ajp Nio-thread stuck in loop and consuming a lot of cpu

Following this thread, I run the same setup, apache/mod_jk/ tomcat.  There was 
a problem a while back where the cpu went to max for me,  as my server is slow 
and thread blocking more of a possibility.

https://bz.apache.org/bugzilla/show_bug.cgi?id=58151

Although this was in version 8.0.23, are you sure your using 8.0.47 jars?

Cheers Greg


On 18 January 2018 at 13:45, Rainer Jung  wrote:

> Just an addition to one of Mark's questions:
>
> Am 17.01.2018 um 22:20 schrieb Mark Thomas:
>
>> Is it always the same threads generating the load or does it move 
>> between threads?
>>
>
> Just in case Andreas is not aware: one can check with "top -H -p ".
>
> Using -H lets top show one line per thread instead of one line per 
> process. That way you can easily see CPU use per thread. The "-p "
> would simply filter to only show the threads in your java process (by 
> using for  the process ID of your Tomcat java process).
>
> Furthermore the PID column in "top -H" does not actually show the PID, 
> but instead the thread IDs. If you convert that decimal numbers to hex, e.g.
> using the shell commandline
>
> printf "0x%x\n" 
>
> (and replacing  by the respective thread id of the lines that show 
> high CPU usage), you get a hex number that will point you to the 
> respective thread in the java thread dump by looking for tid=0x... in 
> the thread header lines. The association between operating system 
> thread number as shown in "top -H" and the tid in the Java thread dump 
> does is stable during the lifetime of the process.
>
> Regards,
>
> Rainer
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Tomcat release for java9

[Gupta, Shaina]

Hello,

Could you please let me know when can we expect a new release for tomcat which 
would support java9.

I can see that the endorsed directory related issue in tomcat 7.x for running 
in java9 has been fixed in 
https://github.com/apache/tomcat70/commit/e7ae8664922cd54fabe847527bad614bcd5ce301#diff-da184cf589a25174c11dc3f4dbaeb0b4

Thanks,
Shaina



  

This message may contain confidential information protected by law. The 
contents of this email are to be viewed only by the intended recipient. If you 
received this message in error, notify the sender immediately and delete the 
original message without printing. Product descriptions, pricing and similar 
content is for information only and does not constitute an offer, warranty or 
guarantee. Contracts with Arcesium are formed only by written documents bearing 
the signature of its authorized representative.

Tomcat release for java9

[Gupta, Shaina]

Hello,

Could you please let me know when can we expect a new release for tomcat which 
would support java9.

I can see that the endorsed directory related issue in tomcat 7.x for running 
in java9 has been fixed in 
https://github.com/apache/tomcat70/commit/e7ae8664922cd54fabe847527bad614bcd5ce301#diff-da184cf589a25174c11dc3f4dbaeb0b4

Thanks,
Shaina



  

This message may contain confidential information protected by law. The 
contents of this email are to be viewed only by the intended recipient. If you 
received this message in error, notify the sender immediately and delete the 
original message without printing. Product descriptions, pricing and similar 
content is for information only and does not constitute an offer, warranty or 
guarantee. Contracts with Arcesium are formed only by written documents bearing 
the signature of its authorized representative.

Re: release plan for tomcat 7.x for java9

[Mukarram Baig]

Thanks for the update, Mark.

On 19/01/18 00:06, Mukarram Baig wrote:
> Hey Mark
>
> Just wanted to see if there was an update to getting a new release.

9.0.x and 8.5.x are happening now. Best guess is 8.0.x and 7.0.x will
follow.

Mark

Re: Accepted Encoding of Basic Auth Header

[jose luis Calvo]

NO ME ENVIEN MAS MENSAJES POR FAVOR

2018-01-19 11:21 GMT+01:00 Norbert Harrer :
> On 19.01.2018 09:10, Mark Thomas wrote:
>>
>> On 18/01/18 21:04, Norbert Harrer wrote:
>>>
>>> Hi.
>>>
>>> Which character encoding of user / password for the Basic Authentication
>>> Header is tomcat accepting?
>>>
>>> A pretty simple question, but I didn't find a clear answer after
>>> googling for quite a while.
>>>
>>> I know that there is no clear definition what should be used. For
>>> example browsers do it differently.
>>>
>>> An example:
>>>
>>> User: test
>>> Password: 123ö  (german umlaut o with two dots at the end)
>>>
>>> Firefox sends ISO-8859-1:
>>> Authorization: Basic dGVzdDoxMjP2
>>>
>>> Chrome sends UTF-8:
>>> Authorization: Basic dGVzdDoxMjPDtg==
>>>
>>> After trying it it seems tomcat accepts ISO-8859-1. Can this be
>>> configured?
>>
>> To a limited extend. See the following:
>>
>> https://bz.apache.org/bugzilla/show_bug.cgi?id=61280
>> http://tomcat.markmail.org/thread/wotey6yz64obije7
>>
>> http://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Basic_Authenticator_Valve/Attributes
>>
>> ...
>
>
> Thanks Mark.
>
> So if I understood the documents (and after studying BasicAuthenticator.java
> in Tomcat 7 and 8) it is as follows:
>
> Tomcat 7 uses ISO-8859-1 hardcoded
> Tomcat 8 implements RFC 7617, in which the server can ask the client to send
> the credential in UTF-8. This must be enabled via the Basic Authenticator
> Valve. Otherwise ISO-8859-1 is used.
>
> I wonder why Chrome is blindly sending UTF-8 instead of respecting RFC 7617.
>
> Regards,
> Norbert
>
>
> -
> 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: Accepted Encoding of Basic Auth Header

[Mark Thomas]

On 19/01/18 10:21, Norbert Harrer wrote:
> On 19.01.2018 09:10, Mark Thomas wrote:
>> On 18/01/18 21:04, Norbert Harrer wrote:
>>> Hi.
>>>
>>> Which character encoding of user / password for the Basic Authentication
>>> Header is tomcat accepting?
>>>
>>> A pretty simple question, but I didn't find a clear answer after
>>> googling for quite a while.
>>>
>>> I know that there is no clear definition what should be used. For
>>> example browsers do it differently.
>>>
>>> An example:
>>>
>>> User: test
>>> Password: 123ö  (german umlaut o with two dots at the end)
>>>
>>> Firefox sends ISO-8859-1:
>>> Authorization: Basic dGVzdDoxMjP2
>>>
>>> Chrome sends UTF-8:
>>> Authorization: Basic dGVzdDoxMjPDtg==
>>>
>>> After trying it it seems tomcat accepts ISO-8859-1. Can this be
>>> configured?
>> To a limited extend. See the following:
>>
>> https://bz.apache.org/bugzilla/show_bug.cgi?id=61280
>> http://tomcat.markmail.org/thread/wotey6yz64obije7
>> http://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Basic_Authenticator_Valve/Attributes
>>
>>
>> ...
> 
> Thanks Mark.
> 
> So if I understood the documents (and after studying
> BasicAuthenticator.java in Tomcat 7 and 8) it is as follows:
> 
> Tomcat 7 uses ISO-8859-1 hardcoded
> Tomcat 8 implements RFC 7617, in which the server can ask the client to
> send the credential in UTF-8. This must be enabled via the Basic
> Authenticator Valve. Otherwise ISO-8859-1 is used.

Not quite. All currently supported versions implement RFC 7617. (You
might want to check if the fix has made it into the latest release of
each. It is hasn't, releases for all versions should be out in the next
week or so.)

> I wonder why Chrome is blindly sending UTF-8 instead of respecting RFC
> 7617.

None of the browsers I tested respected the RFC. Based on past
experience, that doesn't surprise me.

Mark

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

Re: Accepted Encoding of Basic Auth Header

[Norbert Harrer]

On 19.01.2018 09:10, Mark Thomas wrote:

On 18/01/18 21:04, Norbert Harrer wrote:

Hi.

Which character encoding of user / password for the Basic Authentication
Header is tomcat accepting?

A pretty simple question, but I didn't find a clear answer after
googling for quite a while.

I know that there is no clear definition what should be used. For
example browsers do it differently.

An example:

User: test
Password: 123ö  (german umlaut o with two dots at the end)

Firefox sends ISO-8859-1:
Authorization: Basic dGVzdDoxMjP2

Chrome sends UTF-8:
Authorization: Basic dGVzdDoxMjPDtg==

After trying it it seems tomcat accepts ISO-8859-1. Can this be configured?

To a limited extend. See the following:

https://bz.apache.org/bugzilla/show_bug.cgi?id=61280
http://tomcat.markmail.org/thread/wotey6yz64obije7
http://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Basic_Authenticator_Valve/Attributes

...


Thanks Mark.

So if I understood the documents (and after studying 
BasicAuthenticator.java in Tomcat 7 and 8) it is as follows:


Tomcat 7 uses ISO-8859-1 hardcoded
Tomcat 8 implements RFC 7617, in which the server can ask the client to 
send the credential in UTF-8. This must be enabled via the Basic 
Authenticator Valve. Otherwise ISO-8859-1 is used.


I wonder why Chrome is blindly sending UTF-8 instead of respecting RFC 7617.

Regards,
Norbert


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

Re: roles stripped when using login() in tomcat 8.5 but not 8.0

[Robert J. Carr]

OK, thanks Mark, I'll try to come up with a test plan, but I'm seriously
pressed for time as this has eaten two full days.  Thanks again for the
help!

On Fri, Jan 19, 2018 at 12:14 AM, Mark Thomas  wrote:

> On 18/01/18 22:03, Robert J. Carr wrote:
> > (Bear with me as there are a lot of details; I'll try to be as clear as
> > possible)
> >
> > I've been setting up a simple application in tomcat 8.0 where some
> > resources are protected but others aren't.  I want to login using AJAX
> > instead of FORM or BASIC so I don't have any login-config specified in my
> > deployment descriptor (nor any security-roles defined).
> >
> > For testing, I have a custom form that sends login info asynchronously to
> > an unprotected login service which calls login().  On the same page as
> the
> > login form, I have a test button that makes an asynchronous request to a
> > protected resource (using a @ServletSecurity annotation).  As expected,
> > before calling login (and thus login()) I get a 403, but after doing the
> > login() I get a 200 and can see the response text.  This all works fine
> in
> > tomcat 8.0.
> >
> > However, when I try the application in tomcat 8.5, with the same server
> and
> > application config, something different happens.  I do the login and call
> > the protected resource and get the 200 as before, but now every
> subsequent
> > call to the protected resource returns a 403.  I thought maybe there was
> > something peculiar about this specific protected resource, but not the
> > case, any protected resource works the first time, but not subsequent
> times.
> >
> > To confirm what is going on, I created an unprotected resource that
> > provides auth info, and I can see after I login() it reports my username
> > and my affiliated roles (using isUserInRole() for known role names).
> And I
> > can refresh this info any number of times and it doesn't change.  But as
> > soon as I access a protected resource, twice, the unprotected auth info
> > still shows my username, but now my roles are stripped.
> >
> > Thinking there is something wrong with login(), I change to using BASIC
> and
> > run similar tests, never using the login() call, and everything works
> fine;
> > notably, I can access a protected resource more than once.
> >
> > Strangely, what I also unexpectedly noticed is now that I have BASIC
> > specified, when I do use login() things are working fine now even if I
> > never get a BASIC prompt.  So, I can access a protected resource more
> than
> > once.
> >
> > I know this sounds like a weird state issue, but I've restarted web
> > servers, browsers, deployed, undeployed, and redeployed apps dozens and
> > dozens of time.  And I even confirmed the 200 and subsequent 403 calls
> were
> > exactly the same; notably, both had the same session cookie information.
> >
> > So, if this isn't a tomcat bug, which of course I'm very hesitant to
> imply,
> > then maybe there is something that changed in the configuration that was
> > optional before but maybe isn't now?  Maybe I have to specify BASIC or
> FORM
> > even if I never plan to use it?  Any other suggestions?
>
> Create the simplest possible test case that demonstrates this so folks
> can investigate? There are enough moving parts that trying to reproduce
> this solely from your description is likely to miss something.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: roles stripped when using login() in tomcat 8.5 but not 8.0

[Robert J. Carr]

In my last (long) email I described how adding a BASIC login-config changes
things and the roles are no longer getting stripped when using login()
(even when never triggering a basic prompt).  I figured I'd use this as a
workaround until I figure out what is really going wrong.  However, now
I've noticed there is another problem, which may or may not be related.

As described before, when I first login using login() and have BASIC
configured it works as expected.  I can hit a protected resources as many
times as I want and it works fine and the roles remain intact.

But then I'll logout (again, all asynchronously from the same page) which
both invalidates the session and calls logout() on the request, try to hit
the protected resource, and get denied as expected.  But then when I login
using the same mechanism that worked before it seems to all work, but I'm
still denied access to the resource.  If I login *again*, then it works
fine.

Investigating, after I do that login (which is failing) I can see it makes
a principal available and creates a new session and I record the ID.  I can
see that session ID being sent in the cookies of the subsequent protected
resource request which returns the 401.  But when I do a logout I can pull
the same session that was created, but now the principal is null, even
though it existed when I logged in just moments before.

So, instead of the roles being stripped as before, in this case the entire
principal is being removed, but only when you login after an initial
successful login, or maybe after a logout() call?

I feel like I'm going crazy here.  None of this is happening in tomat 8.0.
It is all working as expected.  This is a minimal test application with
essentially a default tomcat config in both versions.

Was anything (significant) changed to login() between tomcat 8.5 and 9 that
could be related?

Thanks-
Robert

Re: release plan for tomcat 7.x for java9

[Mark Thomas]

On 19/01/18 00:06, Mukarram Baig wrote:
> Hey Mark
> 
> Just wanted to see if there was an update to getting a new release.

9.0.x and 8.5.x are happening now. Best guess is 8.0.x and 7.0.x will
follow.

Mark

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

Re: roles stripped when using login() in tomcat 8.5 but not 8.0

[Mark Thomas]

On 18/01/18 22:03, Robert J. Carr wrote:
> (Bear with me as there are a lot of details; I'll try to be as clear as
> possible)
> 
> I've been setting up a simple application in tomcat 8.0 where some
> resources are protected but others aren't.  I want to login using AJAX
> instead of FORM or BASIC so I don't have any login-config specified in my
> deployment descriptor (nor any security-roles defined).
> 
> For testing, I have a custom form that sends login info asynchronously to
> an unprotected login service which calls login().  On the same page as the
> login form, I have a test button that makes an asynchronous request to a
> protected resource (using a @ServletSecurity annotation).  As expected,
> before calling login (and thus login()) I get a 403, but after doing the
> login() I get a 200 and can see the response text.  This all works fine in
> tomcat 8.0.
> 
> However, when I try the application in tomcat 8.5, with the same server and
> application config, something different happens.  I do the login and call
> the protected resource and get the 200 as before, but now every subsequent
> call to the protected resource returns a 403.  I thought maybe there was
> something peculiar about this specific protected resource, but not the
> case, any protected resource works the first time, but not subsequent times.
> 
> To confirm what is going on, I created an unprotected resource that
> provides auth info, and I can see after I login() it reports my username
> and my affiliated roles (using isUserInRole() for known role names).  And I
> can refresh this info any number of times and it doesn't change.  But as
> soon as I access a protected resource, twice, the unprotected auth info
> still shows my username, but now my roles are stripped.
> 
> Thinking there is something wrong with login(), I change to using BASIC and
> run similar tests, never using the login() call, and everything works fine;
> notably, I can access a protected resource more than once.
> 
> Strangely, what I also unexpectedly noticed is now that I have BASIC
> specified, when I do use login() things are working fine now even if I
> never get a BASIC prompt.  So, I can access a protected resource more than
> once.
> 
> I know this sounds like a weird state issue, but I've restarted web
> servers, browsers, deployed, undeployed, and redeployed apps dozens and
> dozens of time.  And I even confirmed the 200 and subsequent 403 calls were
> exactly the same; notably, both had the same session cookie information.
> 
> So, if this isn't a tomcat bug, which of course I'm very hesitant to imply,
> then maybe there is something that changed in the configuration that was
> optional before but maybe isn't now?  Maybe I have to specify BASIC or FORM
> even if I never plan to use it?  Any other suggestions?

Create the simplest possible test case that demonstrates this so folks
can investigate? There are enough moving parts that trying to reproduce
this solely from your description is likely to miss something.

Mark

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

Re: Accepted Encoding of Basic Auth Header

[Mark Thomas]

On 18/01/18 21:04, Norbert Harrer wrote:
> Hi.
> 
> Which character encoding of user / password for the Basic Authentication
> Header is tomcat accepting?
> 
> A pretty simple question, but I didn't find a clear answer after
> googling for quite a while.
> 
> I know that there is no clear definition what should be used. For
> example browsers do it differently.
> 
> An example:
> 
> User: test
> Password: 123ö  (german umlaut o with two dots at the end)
> 
> Firefox sends ISO-8859-1:
> Authorization: Basic dGVzdDoxMjP2
> 
> Chrome sends UTF-8:
> Authorization: Basic dGVzdDoxMjPDtg==
> 
> After trying it it seems tomcat accepts ISO-8859-1. Can this be configured?

To a limited extend. See the following:

https://bz.apache.org/bugzilla/show_bug.cgi?id=61280
http://tomcat.markmail.org/thread/wotey6yz64obije7
http://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Basic_Authenticator_Valve/Attributes

Mark

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

Re: Thread-safety with sessions

[Mark Thomas]

On 18/01/18 20:11, Christopher Schultz wrote:
> Olaf,
> 
> On 1/18/18 1:28 PM, Olaf Kock wrote:
> 
>> On 18.01.2018 06:37, Christopher Schultz wrote:
>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>>>
>>> Mark,
>>>
>>> On 1/17/18 4:31 PM, Mark Thomas wrote:
 On 17/01/18 17:05, Christopher Schultz wrote:
> All,
>
> I have a use-case related to caching where I need to make
> sure that an operation only happens one time with respect to
> an object in the session. Basically, I want to build a cache
> and put it into the session, but it needs to be thread-safe
> enough that two threads can't see the object isn't there,
> build such an object, and then put it into the session
> (thereby overwriting each other).
> 
>> ...
> Yeah, I figured that. Otherwise, multi-threading basically
> couldn't happen. I'm surprised the servlet spec doesn't
> formally guarantee this because practically speaking, it's a
> requirement.
>> 
 It should always be the same object. Looking at the code, I
 don't see any obvious holes.

 For the record, relevant code includes: 
 o.a.catalina.connector.Request.getSession() 
 o.a.catalina.session.ManagerBase.createSession(String) 
 o.a.catalina.session.StandardSession.getSession()
>>> Could this be something we could formally guarantee (via 
>>> documentation)? I'd like to lobby the servlet EG for the same 
>>> guarantee, but getting it done in Tomcat is more immediately
>>> valuable for me :)
>> I'm not sure that this can be done in an unambiguous way,
>> especially not from the spec side: Assuming that objects might be
>> serialized out to disk (for memory reason, unused in 15 minutes but
>> not yet expired, cluster distribution etc) this would lead to quite
>> a few disambiguities. You say that your object creation should
>> happen once per session - is that per session AND machine? If
>> creation of that object has side effects, or the object itself has
>> state, your scenario might only be safe as long as there's no
>> clustering / session replication involved, but can't be assumed
>> when it is.
> 
> I would think the language would be something like "session objects
> within the JVM shall be == equals to each other when requested from
> the container" but I didn't think about the "serializing to [eg] disk"
> scenario. If you have a session obtained from the container, then have
> a long-running request or websocket handler and the container
> meanwhile persists the session elsewhere, some other thread would
> almost certainly get an object that is != the session object in the
> other thread.
> 
> Hmm. I wonder if that is a problem, now, for Tomcat.
> 
> The container is only "maintaining" a single session object ob behalf
> of its worker threads... if an application retains a reference they
> can get out of sync. There is no mechanism for the application to tell
> the container "hey, I need this session for quite a while into the
> future" and so the container might not know it is "in use".
> 
> As for long-running HTTP requests, I believe Tomcat knows whether the
> session is "currently" in use be a long-running request.

org.apache.catalina.session.StandardSession.ACTIVITY_CHECK

> But I'm not
> sure about WebSocket... that may depend upon exactly how the
> websocket-based service actually uses the session and/or obtains it.

WebSocket is a another issue. It needs special handling as WebSocket
requests do not maintain the HTTP session. That was a deliberate
decision of the WebSocket EG.

> For me, it doesn't matter: I have no session-persistence (except
> across restarts), I have no clustering, and I have no websocket usage.
> So at this point, this is an academic exercise for me.
> 
>> I'd say your safest bet is to validate the current
>> implementation's behavior - e.g. your exact version of tomcat - and
>> validate that it doesn't change in future versions. Based on Mark's
>> comments it doesn't look like this is an area where tomcat's
>> implementation would change soon. I'd just not expect it to be
>> over-specified in the servlet spec.
> 
> Given all of the possible complications, here, I think you are
> probably correct. It does present a problem for anyone who wants to do
> things like ensure thread-safety between invocations of server-side
> code using a shared session.
> 
> It seems I'm not the only one curious about this:
> 
> https://stackoverflow.com/questions/9802165/is-synchronization-within-an
> -httpsession-feasible
> 
> http://yet-another-dev.blogspot.com/2009/08/synchronizing-httpsession.ht
> ml
> 
>> There's another argument that the servlet level might be the wrong
>> level for creation of expensive objects, and that it's better
>> delegated to the business layer. I can't judge that in your case,
>> but quite often I've seen the servlet layer overly used for
>> business problems. I don't like this a lot - your problem might be
>> trivial to solve one or two layers down.