Re: Setting up HTTP/2 with no SSL connector ?

[Mark Thomas]

On 30 March 2017 20:53:06 BST, Laurent Perez  wrote:
>Thank you Mark.
>
>h2c is enabled : 30-Mar-2017 21:30:33.373 INFOS [main]
>org.apache.coyote.http11.AbstractHttp11Protocol.configureUpgradeProtocol
>The ["http-nio-8080"] connector has been configured to support HTTP
>upgrade
>to [h2c]
>
>However org.apache.catalina.connector.Request#newPushBuilder returns
>null.
>Processor is a Http11Processor and it does not override the return
>false
>of org.apache.coyote.AbstractProcessor#isPushSupported. It's as if the
>upgrade did not plug in.
>
>Using the apr+ssl connector, same client works fine (i.e pushBuilder is
>not
>null).
>
>Client is Chrome 56. Where could I check in tomcat source to see if the
>client is sending the h2c upgrade token ?

I'm fairly sure most browsers including chrome do not support h2c.

Chrome developer tools should show you the network traffic.

Mark


>
>laurent
>
>
>
>On Thu, Mar 30, 2017 at 9:07 PM, Mark Thomas  wrote:
>>
>> On 30/03/17 18:02, Laurent Perez wrote:
>> > Hi
>> >
>> > I managed to run the servlets/serverpush/simpleimage HTTP/2 push
>example
>> > from Tomcat 9 trunk with the SSL Http11AprProtocol connnector and
>> > > > className="org.apache.coyote.http2.Http2Protocol"/>.
>> >
>> > Now I would like to enable HTTP/2 but without SSL : my certificates
>are
>> > either hosted under my load balancer or Apache itself, and I do not
>require
>> > SSL between mod_proxy and Tomcat.
>> >
>> > But org.apache.coyote.AbstractProcessor#isPushSupported then
>returns
>false,
>> > as if the UpgradeProtocol did not fire.
>> >
>> > Is it possible to enable HTTP/2 with no SSL connector ?
>>
>> Yes. You need to add the  block to an HTTP
>> connector. You should see in the start-up log that h2c is enabled via
>> HTTP Upgrade.
>>
>> Mark
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>
>
>
>--
>http://cv.laurentperez.fr
>J2EE, HTML5, JS, CSS3


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

Re: Ways to identify poorly designed client aplications sending request to Tomcat !

[Olaf Kock]

Am 30.03.2017 um 21:51 schrieb Utkarsh Dave:
> Hi Andre,
>
> I suppose we should read 1.2 GB here ? Yes
> Anyway, why do you say "which is enough" ? How do you know ? By the past
> test results. that we have been doing on each application
> And do not top-post. How do we know what you are responding to ? By
> scrolling up and down ?
Wow, despite the ask to not-top-post you not only continue to top-post,
but embed your answers in the lines that Andre wrote... This is really
hard to read.

Let's summarize what we have so far:
You have a tomcat that has 58 applications deployed, runs on 1.2 GB
heapspace, has been tested earlier to work with these settings.
I'm assuming that you've updated one or the other application since the
test that you have done in order to determine that the memory settings
are sufficient - maybe even updated some of the third party applications
in there.
This might be the point where you have an argument to validate if your
test results are still correct - e.g. if 1.2 GB are still enough for
your current setup.

As I said before, a leak can only be considered a leak when it goes
steadily up - otherwise it could be a deliberate tradeoff decision of
memory vs processing time. Or a byproduct of a changed implementation in
a new version.

And if you haven't updated any of the applications, libraries or tomcat
since you measured: Your load might have gone up, using up more
resources, triggering GC more often, eating up your resources.

Does this summary give you hints what to do? If it doesn't: Try adding
heapspace, you might need it. If the problem goes away you don't have a
leak, you've just reached the limit of your current setup. It's
astonishing to me anyway that you are able to host that number of
applications with only 1.2GB of heapspace. They must not be big.

Olaf

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

Re: Setting up HTTP/2 with no SSL connector ?

[Olaf Kock]

Am 30.03.2017 um 21:53 schrieb Laurent Perez:
> Client is Chrome 56. Where could I check in tomcat source to see if the
> client is sending the h2c upgrade token ?
>>> I managed to run the servlets/serverpush/simpleimage HTTP/2 push example
>>> from Tomcat 9 trunk with the SSL Http11AprProtocol connnector and
>>> >> className="org.apache.coyote.http2.Http2Protocol"/>.
>>>
>>> Now I would like to enable HTTP/2 but without SSL : my certificates are
>>> either hosted under my load balancer or Apache itself, and I do not
>>> require SSL between mod_proxy and Tomcat.
I'm not sure if this is still about the same topic: You mentioned first
that it's about unencrypted traffic between httpd and tomcat, now
Chrome56 comes into the game. According to
https://en.wikipedia.org/wiki/HTTP/2#Encryption, Chrome won't initiate
any unencrypted HTTP/2 connection and I'm not sure if this is what
you're testing/bypassing Apache with in order to just test the connector.

Olaf

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

Intercepting WebSocket ping messages

[Robert Lewis]

Is there a way to intercept a ping message to send a pong? I need to do
this synchronize sends to the endpoint.

I tried

session.addMessageHandler(new
javax.websocket.MessageHandler.Whole() {

@Override
public void onMessage(PongMessage message) {
System.out.println("hi");
}

});


And

@OnMessage public void onPong(PongMessage message) {}

Re: Setting up HTTP/2 with no SSL connector ?

[Laurent Perez]

Thank you Mark.

h2c is enabled : 30-Mar-2017 21:30:33.373 INFOS [main]
org.apache.coyote.http11.AbstractHttp11Protocol.configureUpgradeProtocol
The ["http-nio-8080"] connector has been configured to support HTTP upgrade
to [h2c]

However org.apache.catalina.connector.Request#newPushBuilder returns null.
Processor is a Http11Processor and it does not override the return false
of org.apache.coyote.AbstractProcessor#isPushSupported. It's as if the
upgrade did not plug in.

Using the apr+ssl connector, same client works fine (i.e pushBuilder is not
null).

Client is Chrome 56. Where could I check in tomcat source to see if the
client is sending the h2c upgrade token ?

laurent



On Thu, Mar 30, 2017 at 9:07 PM, Mark Thomas  wrote:
>
> On 30/03/17 18:02, Laurent Perez wrote:
> > Hi
> >
> > I managed to run the servlets/serverpush/simpleimage HTTP/2 push example
> > from Tomcat 9 trunk with the SSL Http11AprProtocol connnector and
> >  > className="org.apache.coyote.http2.Http2Protocol"/>.
> >
> > Now I would like to enable HTTP/2 but without SSL : my certificates are
> > either hosted under my load balancer or Apache itself, and I do not
require
> > SSL between mod_proxy and Tomcat.
> >
> > But org.apache.coyote.AbstractProcessor#isPushSupported then returns
false,
> > as if the UpgradeProtocol did not fire.
> >
> > Is it possible to enable HTTP/2 with no SSL connector ?
>
> Yes. You need to add the  block to an HTTP
> connector. You should see in the start-up log that h2c is enabled via
> HTTP Upgrade.
>
> Mark
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>



--
http://cv.laurentperez.fr
J2EE, HTML5, JS, CSS3

Re: Ways to identify poorly designed client aplications sending request to Tomcat !

[Utkarsh Dave]

Hi Andre,

I suppose we should read 1.2 GB here ? Yes
Anyway, why do you say "which is enough" ? How do you know ? By the past
test results. that we have been doing on each application
And do not top-post. How do we know what you are responding to ? By
scrolling up and down ?

On Thu, Mar 30, 2017 at 10:43 AM, André Warnier (tomcat) 
wrote:

> On 30.03.2017 19:36, Utkarsh Dave wrote:
>
>> Thanks Olaf and Suvendu for the response.
>> We are using 1.2 MB of heap size which is enough and haven't created an
>> issue so far.
>>
>
> I suppose we should read 1.2 GB here ?
> Anyway, why do you say "which is enough" ? How do you know ?
> And do not top-post. How do we know what you are responding to ? By
> scrolling up and down ?
>
>
>
>
>> On Thu, Mar 30, 2017 at 9:51 AM, Suvendu Sekhar Mondal > >
>> wrote:
>>
>> Memory heap dump generated is of
 Size: 787.3 MB Classes: 139k Objects: 19.3m Class Loader: 1.6k

>>>
>>> Overview shows 580.9 MB occupied by remainder's.

>>>
>>> Problem suspect:-
 465 MB occupied by remainder

>>>
>>> Remainder section has retained a good chunk of memory. That indicates
>>> lots of small objects are being created by different apps. Your "Live
>>> Set" is not very big. What is the heap size? You also mentioned,
>>> Tomcat process was consuming high CPU. If you have small heap and all
>>> of it is filled up by live objects then JVM will run frequent GC to
>>> clean up some space. In that case CPU usage will be high for Tomcat
>>> process.
>>>
>>> As Olaf indicated, you can try to increase heap size and see if the
>>> problem goes away. But before that, I am curious to see what heap and
>>> GC settings you are using. Please post that info.
>>>
>>> Thanks!
>>> Suvendu
>>>
>>> On Thu, Mar 30, 2017 at 2:01 PM, Olaf Kock  wrote:
>>>
 Am 30.03.2017 um 01:33 schrieb Utkarsh Dave:

> Hello all,
>
> My tomcat (7.0.72) hosts several web aplications in the server (based
> in
> linux 6.8).
>
 [...]

> Memory heap dump generated is of
> Size: 787.3 MB Classes: 139k Objects: 19.3m Class Loader: 1.6k
>
 The combination of "hosts several web applications" and a heap space of
 this size does not convince me of a leak - it might be the memory
 requirement of one of the webapps. A leak is typically something that
 grows uncontrolled until you run out of heapspace, no matter how much
 you grow the available space.

> In the thread dumps I see these threads repeatedly. I wonder these
>
 pointing
>>>
 to com.rsa.sslj.x.
>
 You seem to be handling https requests from Tomcat. If you're not happy
 with the implementation of this endpoint/protocol you should move this
 to an Apache httpd or similar and just forward to tomcat, so that tomcat
 does not deal with encryption.

 As a conclusion: Your problem might not be poorly designed clients, it
 might be poorly equipped servers - I'd try to double the memory
 allocated to Tomcat's heap and potentially tune the garbage collector.
 If you run into problems, you might also identify one of the
 webapplications that eats up your resources (no matter what the clients
 do).

 Olaf

 -
 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
>>>
>>>
>>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: how to access HTTPServletRequest in RealmBase

[tomcat]

On 30.03.2017 20:10, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Konstantin,

On 3/30/17 4:19 AM, Konstantin Kolinko wrote:

2017-03-30 11:02 GMT+03:00 Jan Vávra :

Hello, I have written a custom Realm and I need to access to the
request headers. The authentication should be computed from
client certificate + id from custom http header X-IdUser. Can I
somehow access to the HTTPServletRequest instance  ?


Not possible, by design.

An Authenticator (a valve) can access request and its headers. A
Realm cannot.


I've always been frustrated by this, and it's one reason I do not use
Tomcat's build-in authentication. I need to log authentication
failures and their sources (IP address) and this information is simply
not available through the Tomcat-provided APIs.

I think there is definitely an opportunity here for improvement.



A naive question or three (I can't really ask any other kind in Java) :

1) what is calling the following method ?
https://tomcat.apache.org/tomcat-8.0-doc/api/org/apache/catalina/realm/DataSourceRealm.html#authenticate%28java.lang.String,%20java.lang.String%29

2) And (assuming that if you want to do non-standard things in the Realm, it means that 
you are writing your own custom Realm), isn't there a possibility for any caller of (1) 
above, to pass anything it wants in the "credentials" argument ?

(such as a caller IP address, the content of a HTTP header, etc.)
(to be parsed out and used by the authenticate method, for logging e.g.)

3) and, still assuming much, might one then perhaps use this element to specify a class 
which would perform ditto parsing, prior to the authentication itself ?

http://tomcat.apache.org/tomcat-9.0-doc/config/credentialhandler.html



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

Re: LDAP authentication for Tomcat's webapp 'Opengrok'

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Alfie,

On 3/27/17 7:07 AM, Alfie Patolilic wrote:
>> Tomcat Version : 6.0.36

You need to upgrade. Current 6.0.x version if 6.0.51. Current stable
version is (IMO) 8.0.42.

>> I have a question on how I am able to set the following,
>> regarding the web application that runs under Apache Tomcat,
>> 'Opengrok'. The idea is to set a hostname for
>> 'localhost:8080/grok', so when users try and access the page via
>> the hostname, they are prompted for authentication of their
>> username and password.
>> 
>> I have currently configured the server.xml to connect to LDAP. I
>>  have added below the configuration on my server.xml. I am unsure
>> as to where to go from here, how I will be able to link the
>> hostname. I have changed some values in the information given for
>> security purposes.
>> 
>>  > className="org.apache.catalina.realm.LockOutRealm"> > className="org.apache.catalina.realm.UserDatabaseRealm"
>> resourceName="UserDatabase"/> > className="org.apache.catalina.realm.JNDIRealm" debug="99" 
>> connectionURL="ldap:// " connectionName="ldap@company " 
>> connectionPassword="password" referrals="follow" 
>> userBase="DC=" userSearch="(sAMAccountName={0})" 
>> userSubtree="true" roleBase="DC=" roleName="cn" 
>> roleSubtree="true" roleSearch="(member={0})" 
>> allRolesMode="strictAuthOnly" /> 

Does the application understand anything about LDAP authentication, or
are you asking how Tomcat can be configured to request the username
and password for the user?

The LDAP backend is just the way that the authentication and
authorization is performed. Credential-gathering is typically
performed using one of the following:

1. HTTP Basic "authentication"
2. HTTP Digest "authentication"
3. FORM login (username/password in a web form)
4. SSL/TLS client certificate

Which of the above did you have in mind? If you are just slapping
authentication on top of an existing application that doesn't have its
own login process, then I would recommend using HTTP Basic
"authentication" (I use parens around "authentication" because it's
not authenticating at all... it's just providing credentials that the
server can use for authentication). When using HTTP Basic
"authentication" it is absolutely required that you use TLS to encrypt
the channel.

>> I have checked the web for blogs and asked other tomcat groups
>> but was not able to get any answers.
>> 
>> I am aware that the version of Apache Tomcat I am using is 
>> outdated and has reached its end of life. Though necessary, I 
>> cannot update to a newer version of the application due to some 
>> issues.

You need to resolve those issues. Any software product that has
security components cannot be trusted after it reaches end-of-life.
Any EOL'd product should be considered known-vulnerable as soon as
that EOL date arrives.

> I meant that currently, I can access opengrok via
> localhost:8080/grok.
> 
> I am planning on configuring a hostname called 'grok.company.com' 
> which redirects to localhost:8080/grok.

Redirects or proxies? Adding a redirect will only work for users who
are sitting at your actual computer (localhost).

> When they access grok using grok.company.com, they will be
> prompted with a userid and password using LDAP.

Is there a reason not to require a username and password for all
users, regardless of the hostname they use to access the application?

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

iQIcBAEBCAAGBQJY3V7CAAoJEBzwKT+lPKRYtIIQAKyR04cPJRlHbAj98YHfNmht
0OONt5mOyTsvtrK5qQ/SCpYBVaSQc36/lZuzStjVM45VLleKa7zjRhz8Rru6zywp
nOGF0UySkI+/gAUIQVPeySx5e7JhvTDbcjvVyPV8kO2vWn3+XJb0wTmIwdwslNLo
sshP0vJBqq9YkgnzGm97GfKNhw5ZsHlV+HZqx/ASynEn4vQ4saSFjkFFin2naogy
TNilBBGnVBErVyvf4oPgMQRaqDyt70hME5e02EyZWCsijYYKl1/aQZDIFrTvVDQD
sCc4EM5/0RUp3JUAhgz4klPUhCEmTXikonliqQOWoz5vIm7rZTkcP1CMlIbXrBST
BvSZh23HNqmrUsgfqdoN05xOJ0vFjeB02ezDwWBpl7pxJ9kB0WCJYdusy94p4ixN
XJZic8sBQA7ijSRBGy4MgynPPQ4lnX94vR6eu0tcqZd/QUOXI75d3FoXpDiyrFci
2q51wv/4rHKFeLzg1GO6XmMdqBMcEkt6u9TX0QZSKxXV6mFsUIzG4EPk+8xcbsNM
SRGy91sRtUWgFdpJyov/QsSpxXLaLISsLuR3gW5kX6v5IBpFA0aWLBvYsLUhCZR5
NMEULjea6kSppTVE2CqHHJykmDQcYSK+YCuW/0XNkbuf/AVqb1WJhBdM1GowT4NN
Ivxb5EnyXg/9XeI09It+
=WjqC
-END PGP SIGNATURE-

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

Re: Ways to identify poorly designed client aplications sending request to Tomcat !

[Utkarsh Dave]

Hi Chris

What makes you say that? Past cases, I saw where implementation or not
using the JSESSION was making the connection over and over again for
multiple transactions

What JVM are you using?
We using Orcale JDK 1.7.0.131

Yes, 58 applications.
On Thu, Mar 30, 2017 at 12:01 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Utkarsh,
>
> On 3/29/17 7:33 PM, Utkarsh Dave wrote:
> > Hello all,
> >
> > My tomcat (7.0.72) hosts several web aplications in the server
> > (based in linux 6.8). There are many clients or 3rd party
> > applications working as client to my server (having tomcat and web
> > applications). There are instances when poorly designed client
> > application can affect severly to Tomcat. Connections/sessions not
> > being reused or closed is one of them.
>
> If you have too many sessions, you have two options:
>
> 1. Lower the session-timeout (default: 30min)
> 2. Identify places in the code where sessions are being created but do
> not need to be created
>
> > My question is the way to prove/identify such symptoms of the 3rd
> > party applications.
> >
> > I have a situation where all the applications and web/GUI access
> > slows down and tomcat shows as consuming 100% cpu (even though
> > overall CPU is less) My diagnosis shows memory tests for tomcat
> > failing (less than 100KB of free heap left), And so i generated
> > memory heap dump and thread dumps. Below are the results. Based on
> > below, does this qualify for a poorly socket implemetation ? Any
> > thoughts will be helpful.
>
> What makes you say that?
>
> > Memory heap dump generated is of Size: 787.3 MB Classes: 139k
> > Objects: 19.3m Class Loader: 1.6k
> >
> > Overview shows 580.9 MB occupied by remainder's.
> >
> > Problem suspect:- 465 MB occupied by remainder
> >
> > 152.2 MB- leak suspect 1 6 instances of
> > "com.sun.xml.bind.v2.runtime.JAXBContextImpl", loaded by
> > "org.apache.catalina.loader.WebappClassLoader @ 0xacc38e98" occupy
> > 159,582,744 (19.33%) bytes.
>
> It's certainly possible that JAXB and/or your XML-pasring library
> could be leaking memory. Older XML parsers would keep the whole XML
> document text pinned in memory if some other part of the code grabbed
> a single XML attribute and hung-onto the reference. This was actually
> fixed in the implementation of String.substring, I believe.
>
> What JVM are you using?
>
> > 91 MB- leak suspect 2 58 instances of
> > "org.apache.catalina.loader.WebappClassLoader", loaded by
> > "java.net.URLClassLoader @ 0xa6b8e038" occupy 95,396,344 (11.56%)
> > bytes
>
> How many applications do you have loaded in the same JVM? If you have
> 58, then that's how many WebappClassLoader objects we'd expect to be
> present. If you have less than that, you probably have applications
> that are not undeploying or reloading cleanly.
>
> > 79.1 MB - leak suspect 3 4 instances of "com.rsa.sslj.x.aO", loaded
> > by "sun.misc.Launcher$ExtClassLoader @ 0xa6b763b0" occupy
> > 82,968,424 (10.05%) bytes.
>
> Is that a 3rd-party JSSE library?
>
> > In the thread dumps I see these threads repeatedly. I wonder these
> > pointing to com.rsa.sslj.x.
> >
> > "http-bio-8443-exec-230" daemon prio=10 tid=0x1130a400 nid=0x411b
> > runnable [0x01be1000] java.lang.Thread.State: RUNNABLE at
> > java.net.SocketInputStream.socketRead0(Native Method) at
> > java.net.SocketInputStream.read(SocketInputStream.java:153) at
> > java.net.SocketInputStream.read(SocketInputStream.java:122) at
> > com.rsa.sslj.x.ap.c(Unknown Source) at com.rsa.sslj.x.ap.a(Unknown
> > Source) at com.rsa.sslj.x.ap.b(Unknown Source) at
> > com.rsa.sslj.x.ap.b(Unknown Source) at
> > com.rsa.sslj.x.al.read(Unknown Source) at
> > org.apache.coyote.http11.InternalInputBuffer.fill(InternalInputBuffer.
> java:519)
> >
> >
> at
> > org.apache.coyote.http11.InternalInputBuffer.fill(InternalInputBuffer.
> java:504)
> >
> >
> at
> > org.apache.coyote.http11.Http11Processor.setRequestLineReadTimeout(Htt
> p11Processor.java:168)
> >
> >
> at
> > org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp1
> 1Processor.java:998)
> >
> >
> at
> > org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(A
> bstractProtocol.java:637)
> >
> >
> at
> > org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint
> .java:318)
> >
> >
> - - locked <0x8f1f68d8> (a org.apache.tomcat.util.net.SocketWrapper)
> > at
> > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.j
> ava:1145)
> >
> >
> at
> > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.
> java:615)
> >
> >
> at
> > org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThr
> ead.java:61)
> >
> >
> at java.lang.Thread.run(Thread.java:745)
>
> That looks like a 3rd-party JSSE library. What do you need that for?
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - 

Re: Setting up HTTP/2 with no SSL connector ?

[Mark Thomas]

On 30/03/17 18:02, Laurent Perez wrote:
> Hi
> 
> I managed to run the servlets/serverpush/simpleimage HTTP/2 push example
> from Tomcat 9 trunk with the SSL Http11AprProtocol connnector and
>  className="org.apache.coyote.http2.Http2Protocol"/>.
> 
> Now I would like to enable HTTP/2 but without SSL : my certificates are
> either hosted under my load balancer or Apache itself, and I do not require
> SSL between mod_proxy and Tomcat.
> 
> But org.apache.coyote.AbstractProcessor#isPushSupported then returns false,
> as if the UpgradeProtocol did not fire.
> 
> Is it possible to enable HTTP/2 with no SSL connector ?

Yes. You need to add the  block to an HTTP
connector. You should see in the start-up log that h2c is enabled via
HTTP Upgrade.

Mark


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

Re: Ways to identify poorly designed client aplications sending request to Tomcat !

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Utkarsh,

On 3/29/17 7:33 PM, Utkarsh Dave wrote:
> Hello all,
> 
> My tomcat (7.0.72) hosts several web aplications in the server
> (based in linux 6.8). There are many clients or 3rd party
> applications working as client to my server (having tomcat and web
> applications). There are instances when poorly designed client
> application can affect severly to Tomcat. Connections/sessions not
> being reused or closed is one of them.

If you have too many sessions, you have two options:

1. Lower the session-timeout (default: 30min)
2. Identify places in the code where sessions are being created but do
not need to be created

> My question is the way to prove/identify such symptoms of the 3rd
> party applications.
> 
> I have a situation where all the applications and web/GUI access
> slows down and tomcat shows as consuming 100% cpu (even though
> overall CPU is less) My diagnosis shows memory tests for tomcat
> failing (less than 100KB of free heap left), And so i generated
> memory heap dump and thread dumps. Below are the results. Based on
> below, does this qualify for a poorly socket implemetation ? Any
> thoughts will be helpful.

What makes you say that?

> Memory heap dump generated is of Size: 787.3 MB Classes: 139k
> Objects: 19.3m Class Loader: 1.6k
> 
> Overview shows 580.9 MB occupied by remainder's.
> 
> Problem suspect:- 465 MB occupied by remainder
> 
> 152.2 MB- leak suspect 1 6 instances of
> "com.sun.xml.bind.v2.runtime.JAXBContextImpl", loaded by 
> "org.apache.catalina.loader.WebappClassLoader @ 0xacc38e98" occupy 
> 159,582,744 (19.33%) bytes.

It's certainly possible that JAXB and/or your XML-pasring library
could be leaking memory. Older XML parsers would keep the whole XML
document text pinned in memory if some other part of the code grabbed
a single XML attribute and hung-onto the reference. This was actually
fixed in the implementation of String.substring, I believe.

What JVM are you using?

> 91 MB- leak suspect 2 58 instances of
> "org.apache.catalina.loader.WebappClassLoader", loaded by 
> "java.net.URLClassLoader @ 0xa6b8e038" occupy 95,396,344 (11.56%)
> bytes

How many applications do you have loaded in the same JVM? If you have
58, then that's how many WebappClassLoader objects we'd expect to be
present. If you have less than that, you probably have applications
that are not undeploying or reloading cleanly.

> 79.1 MB - leak suspect 3 4 instances of "com.rsa.sslj.x.aO", loaded
> by "sun.misc.Launcher$ExtClassLoader @ 0xa6b763b0" occupy
> 82,968,424 (10.05%) bytes.

Is that a 3rd-party JSSE library?

> In the thread dumps I see these threads repeatedly. I wonder these
> pointing to com.rsa.sslj.x.
> 
> "http-bio-8443-exec-230" daemon prio=10 tid=0x1130a400 nid=0x411b
> runnable [0x01be1000] java.lang.Thread.State: RUNNABLE at
> java.net.SocketInputStream.socketRead0(Native Method) at
> java.net.SocketInputStream.read(SocketInputStream.java:153) at
> java.net.SocketInputStream.read(SocketInputStream.java:122) at
> com.rsa.sslj.x.ap.c(Unknown Source) at com.rsa.sslj.x.ap.a(Unknown
> Source) at com.rsa.sslj.x.ap.b(Unknown Source) at
> com.rsa.sslj.x.ap.b(Unknown Source) at
> com.rsa.sslj.x.al.read(Unknown Source) at 
> org.apache.coyote.http11.InternalInputBuffer.fill(InternalInputBuffer.
java:519)
>
> 
at
> org.apache.coyote.http11.InternalInputBuffer.fill(InternalInputBuffer.
java:504)
>
> 
at
> org.apache.coyote.http11.Http11Processor.setRequestLineReadTimeout(Htt
p11Processor.java:168)
>
> 
at
> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp1
1Processor.java:998)
>
> 
at
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(A
bstractProtocol.java:637)
>
> 
at
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint
.java:318)
>
> 
- - locked <0x8f1f68d8> (a org.apache.tomcat.util.net.SocketWrapper)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.j
ava:1145)
>
> 
at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.
java:615)
>
> 
at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThr
ead.java:61)
>
> 
at java.lang.Thread.run(Thread.java:745)

That looks like a 3rd-party JSSE library. What do you need that for?

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

iQIcBAEBCAAGBQJY3VX/AAoJEBzwKT+lPKRY6yoP/1p46IDHftMpRIx2aUpdkTan
TCoiYtrwFGJ6o4WhPIVg7GNWv4p3aQr+Rkdtd1+b5ege2rAy75dB+to0CmvN8M1g
AxiXjQ5Ct1B6rP1LOGPrSZNM+3Urk0Gw8g50k1rMl/7/K79XqvA3bH2zjeSm4u/w
fY3veBg4Bru6nPCGmyUX+r8kfMOdIiNbiLDE2DDuBO7z4HLFms9Zd50XpcJw+e4J
rCpRRwqEI7RrhnaB5iASiUmKVUX6MCSQtAqHL6zHC+1nknj4rDAYHSuJsA/UoIuJ
Uuz6rlUfH9pZHf9iQ9Aw2K+zSjjW3QcsFkD/MUQs4sa/X80sXRKfWBkHvOl5IPjj
zzh/X5tlYFuHtkMHqRFx2jlX71geVa9TBbu/aOEG78AJSWNAEH97JHXQ9dKuB64P
VtyJAe3/Gtnelrb5kPrO7dN7bvQWwA/g2zQOlojZjP7MSLmBhd+Utvnustwa96ji

Re: how to access HTTPServletRequest in RealmBase

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Konstantin,

On 3/30/17 4:19 AM, Konstantin Kolinko wrote:
> 2017-03-30 11:02 GMT+03:00 Jan Vávra :
>> Hello, I have written a custom Realm and I need to access to the
>> request headers. The authentication should be computed from
>> client certificate + id from custom http header X-IdUser. Can I
>> somehow access to the HTTPServletRequest instance  ?
> 
> Not possible, by design.
> 
> An Authenticator (a valve) can access request and its headers. A
> Realm cannot.

I've always been frustrated by this, and it's one reason I do not use
Tomcat's build-in authentication. I need to log authentication
failures and their sources (IP address) and this information is simply
not available through the Tomcat-provided APIs.

I think there is definitely an opportunity here for improvement.

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

iQIcBAEBCAAGBQJY3UoGAAoJEBzwKT+lPKRYngYP/2d9bQ7Br8vfBd3Mta0GYpPk
psBNuDCcujkz4rUy0t/1k5ttiCI7coTjkt7joeeMH47A6mhJTbeGGAG+xm/5+Nc4
1lx7kzjDG9fbsrpXzGM3uQT46oikFuHrhzF09E0vAKRyG8mzgc/6jo+oo6M6hdeo
RreEe5Fvl1jLHRQTTeSDOdoQ+lDDkwWSS27mmTt8QlDEYdRrJTZZ8thO0LtlZlov
+RZB9OtDjl1nriHzBLGmL+Ea2IlctUxTYRuTdynm+IgQzbznMdAfUEwPmYab19RC
cxFlm8LcVMT+5UG0JM0xLj1y2NO9+sd+lsvwzv6nNPCXdHQ5raj0IWFX/122wI/U
HQFai0pax+XRfCJ+nUFldrROyvPiIQAPOHDRsXOlJOOUDrdXXB4kPya8TwvMRfYp
+ueoai3AAExdpT+M8ctto5k97ROw1mwvrWK4nOdKM0nOQ2AMAhTzn0YbDmYjzmgQ
Zy8cfBfR5PKL6nBcMjw6BZYZQ+OGSA5vq3Ha+uY6Gk+45TgT3QmYJgeZMUR6auDk
URiHtDJCBP/8L+7BbjFaQtgK0NT2WTez4Lt1UbPSQzzCsqGGvpmo5ZGxw5BFkfBX
oMTct5G4WKrf8jRq+SV4hZtjCZ/AFAdWMzSWg6MddtboIH3rAWaqiaTIv9DYFuRK
n1I4+e6VN9BoKfNfhxvL
=KTR1
-END PGP SIGNATURE-

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

Re: Ways to identify poorly designed client aplications sending request to Tomcat !

[tomcat]

On 30.03.2017 19:36, Utkarsh Dave wrote:

Thanks Olaf and Suvendu for the response.
We are using 1.2 MB of heap size which is enough and haven't created an
issue so far.


I suppose we should read 1.2 GB here ?
Anyway, why do you say "which is enough" ? How do you know ?
And do not top-post. How do we know what you are responding to ? By scrolling 
up and down ?




On Thu, Mar 30, 2017 at 9:51 AM, Suvendu Sekhar Mondal 
wrote:


Memory heap dump generated is of
Size: 787.3 MB Classes: 139k Objects: 19.3m Class Loader: 1.6k



Overview shows 580.9 MB occupied by remainder's.



Problem suspect:-
465 MB occupied by remainder


Remainder section has retained a good chunk of memory. That indicates
lots of small objects are being created by different apps. Your "Live
Set" is not very big. What is the heap size? You also mentioned,
Tomcat process was consuming high CPU. If you have small heap and all
of it is filled up by live objects then JVM will run frequent GC to
clean up some space. In that case CPU usage will be high for Tomcat
process.

As Olaf indicated, you can try to increase heap size and see if the
problem goes away. But before that, I am curious to see what heap and
GC settings you are using. Please post that info.

Thanks!
Suvendu

On Thu, Mar 30, 2017 at 2:01 PM, Olaf Kock  wrote:

Am 30.03.2017 um 01:33 schrieb Utkarsh Dave:

Hello all,

My tomcat (7.0.72) hosts several web aplications in the server (based in
linux 6.8).

[...]

Memory heap dump generated is of
Size: 787.3 MB Classes: 139k Objects: 19.3m Class Loader: 1.6k

The combination of "hosts several web applications" and a heap space of
this size does not convince me of a leak - it might be the memory
requirement of one of the webapps. A leak is typically something that
grows uncontrolled until you run out of heapspace, no matter how much
you grow the available space.

In the thread dumps I see these threads repeatedly. I wonder these

pointing

to com.rsa.sslj.x.

You seem to be handling https requests from Tomcat. If you're not happy
with the implementation of this endpoint/protocol you should move this
to an Apache httpd or similar and just forward to tomcat, so that tomcat
does not deal with encryption.

As a conclusion: Your problem might not be poorly designed clients, it
might be poorly equipped servers - I'd try to double the memory
allocated to Tomcat's heap and potentially tune the garbage collector.
If you run into problems, you might also identify one of the
webapplications that eats up your resources (no matter what the clients
do).

Olaf

-
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







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

Re: Ways to identify poorly designed client aplications sending request to Tomcat !

[Utkarsh Dave]

Thanks Olaf and Suvendu for the response.
We are using 1.2 MB of heap size which is enough and haven't created an
issue so far.

On Thu, Mar 30, 2017 at 9:51 AM, Suvendu Sekhar Mondal 
wrote:

> >Memory heap dump generated is of
> >Size: 787.3 MB Classes: 139k Objects: 19.3m Class Loader: 1.6k
>
> >Overview shows 580.9 MB occupied by remainder's.
>
> >Problem suspect:-
> >465 MB occupied by remainder
>
> Remainder section has retained a good chunk of memory. That indicates
> lots of small objects are being created by different apps. Your "Live
> Set" is not very big. What is the heap size? You also mentioned,
> Tomcat process was consuming high CPU. If you have small heap and all
> of it is filled up by live objects then JVM will run frequent GC to
> clean up some space. In that case CPU usage will be high for Tomcat
> process.
>
> As Olaf indicated, you can try to increase heap size and see if the
> problem goes away. But before that, I am curious to see what heap and
> GC settings you are using. Please post that info.
>
> Thanks!
> Suvendu
>
> On Thu, Mar 30, 2017 at 2:01 PM, Olaf Kock  wrote:
> > Am 30.03.2017 um 01:33 schrieb Utkarsh Dave:
> >> Hello all,
> >>
> >> My tomcat (7.0.72) hosts several web aplications in the server (based in
> >> linux 6.8).
> > [...]
> >> Memory heap dump generated is of
> >> Size: 787.3 MB Classes: 139k Objects: 19.3m Class Loader: 1.6k
> > The combination of "hosts several web applications" and a heap space of
> > this size does not convince me of a leak - it might be the memory
> > requirement of one of the webapps. A leak is typically something that
> > grows uncontrolled until you run out of heapspace, no matter how much
> > you grow the available space.
> >> In the thread dumps I see these threads repeatedly. I wonder these
> pointing
> >> to com.rsa.sslj.x.
> > You seem to be handling https requests from Tomcat. If you're not happy
> > with the implementation of this endpoint/protocol you should move this
> > to an Apache httpd or similar and just forward to tomcat, so that tomcat
> > does not deal with encryption.
> >
> > As a conclusion: Your problem might not be poorly designed clients, it
> > might be poorly equipped servers - I'd try to double the memory
> > allocated to Tomcat's heap and potentially tune the garbage collector.
> > If you run into problems, you might also identify one of the
> > webapplications that eats up your resources (no matter what the clients
> > do).
> >
> > Olaf
> >
> > -
> > 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: Tracking down a Basic.sendBinary() issue

[Robert Lewis]

Ok. We do lock all our calls to Basic.sendBinary(), also it seems like
moving to Tomcat 8.5 fixes the issue. No proof yet why. Since it always
happens on our last write out to a client which should trigger a client
ack, the client will immediately send an ack back to us (which seems to
trigger the problem), and was thinking it was possibly because the read /
write on one thread happened before we were finished the onWritePossible
call at the container level.

"From experience, timing issues tend to be triggered by non-container
threads.":
Yes, but the fact that doWrite() was moved out of the sync block to fix a
deadlock situation indicates otherwise.

Ping on every call fixes the problem for us, and we will be working to move
to 8.5 soon anyway.

Thanks,
 -Rob


On Thu, Mar 30, 2017 at 1:09 PM, Mark Thomas  wrote:

> On 29/03/17 04:04, Robert Lewis wrote:
> > Thanks Mark. I will take a look at the test you linked in (seems like
> Clint
> > already is).
> >
> > I have a question regarding your previous note "The short version is that
> > it is possible that there are two threads". On 8.0.38, doWrite() sets
> it's
> > scoped handler and buffers to the class level instance, then proceeds to
> > call onWritePossible(true). onWritePossible creates a new local variable
> > that seems like it copies the class level buffers state (not sure if this
> > is a deep clone or not, i'll have to test this), but it does not
> replicate
> > the handler reference. If onWritePossible() is busy working writing the
> > buffers to the socket and another thread calls doWrite(), that class
> level
> > state will be swapped before onWritePossible is finished, resulting in a
> > possible race condition for a swapped out buffer or handler.
> >
> > Not claiming to know the code as well as those who maintain it, but it
> > would be nice to know if someone thinks this could happen resulting in
> > unexpected behavior (eg. we are writing to a socket and the the read
> thread
> > responds with a write on another thread).
>
> There are checks much higher up the stack that should throw an
> IllegalStateException (from memory) if you try and write two messages at
> once.
>
> From experience, timing issues tend to be triggered by non-container
> threads. A typical pattern is that the first thread has some unexpected
> side-effects that impact on the second thread - often because of
> unexpected execution order.
>
> > Curious why onWritePossible(true) is not called with the doWrite() state?
> > (eg. onWritePossible(true, buffers, handler))?
>
> The callers don't all have that information.
>
> > This is just an observation at this point so looking for an opinion on
> > whether or not something described above could happen. If what was stated
> > (that a write and a read / response write) can operate on two threads, I
> > don't see why not.
> >
> > Continuing to run off and play with the tests you have linked.
>
> Again from experience unless you have some clues to point you in the
> right direction, finding these issues via code inspection is hard.
> Equally, a reproducible test case is rare. What tends to happen is a
> more iterative approach that starts with an occasionally failing test
> case and a combination of debugging, logging and extra debug statements
> is used to narrow down the location of the problem.
>
> Mark
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Tracking down a Basic.sendBinary() issue

[Mark Thomas]

On 29/03/17 04:04, Robert Lewis wrote:
> Thanks Mark. I will take a look at the test you linked in (seems like Clint
> already is).
> 
> I have a question regarding your previous note "The short version is that
> it is possible that there are two threads". On 8.0.38, doWrite() sets it's
> scoped handler and buffers to the class level instance, then proceeds to
> call onWritePossible(true). onWritePossible creates a new local variable
> that seems like it copies the class level buffers state (not sure if this
> is a deep clone or not, i'll have to test this), but it does not replicate
> the handler reference. If onWritePossible() is busy working writing the
> buffers to the socket and another thread calls doWrite(), that class level
> state will be swapped before onWritePossible is finished, resulting in a
> possible race condition for a swapped out buffer or handler.
> 
> Not claiming to know the code as well as those who maintain it, but it
> would be nice to know if someone thinks this could happen resulting in
> unexpected behavior (eg. we are writing to a socket and the the read thread
> responds with a write on another thread).

There are checks much higher up the stack that should throw an
IllegalStateException (from memory) if you try and write two messages at
once.

>From experience, timing issues tend to be triggered by non-container
threads. A typical pattern is that the first thread has some unexpected
side-effects that impact on the second thread - often because of
unexpected execution order.

> Curious why onWritePossible(true) is not called with the doWrite() state?
> (eg. onWritePossible(true, buffers, handler))?

The callers don't all have that information.

> This is just an observation at this point so looking for an opinion on
> whether or not something described above could happen. If what was stated
> (that a write and a read / response write) can operate on two threads, I
> don't see why not.
> 
> Continuing to run off and play with the tests you have linked.

Again from experience unless you have some clues to point you in the
right direction, finding these issues via code inspection is hard.
Equally, a reproducible test case is rare. What tends to happen is a
more iterative approach that starts with an occasionally failing test
case and a combination of debugging, logging and extra debug statements
is used to narrow down the location of the problem.

Mark


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

Setting up HTTP/2 with no SSL connector ?

[Laurent Perez]

Hi

I managed to run the servlets/serverpush/simpleimage HTTP/2 push example
from Tomcat 9 trunk with the SSL Http11AprProtocol connnector and
.

Now I would like to enable HTTP/2 but without SSL : my certificates are
either hosted under my load balancer or Apache itself, and I do not require
SSL between mod_proxy and Tomcat.

But org.apache.coyote.AbstractProcessor#isPushSupported then returns false,
as if the UpgradeProtocol did not fire.

Is it possible to enable HTTP/2 with no SSL connector ?

Thanks
laurent




-- 
http://cv.laurentperez.fr
J2EE, HTML5, JS, CSS3

Re: Ways to identify poorly designed client aplications sending request to Tomcat !

[Suvendu Sekhar Mondal]

>Memory heap dump generated is of
>Size: 787.3 MB Classes: 139k Objects: 19.3m Class Loader: 1.6k

>Overview shows 580.9 MB occupied by remainder's.

>Problem suspect:-
>465 MB occupied by remainder

Remainder section has retained a good chunk of memory. That indicates
lots of small objects are being created by different apps. Your "Live
Set" is not very big. What is the heap size? You also mentioned,
Tomcat process was consuming high CPU. If you have small heap and all
of it is filled up by live objects then JVM will run frequent GC to
clean up some space. In that case CPU usage will be high for Tomcat
process.

As Olaf indicated, you can try to increase heap size and see if the
problem goes away. But before that, I am curious to see what heap and
GC settings you are using. Please post that info.

Thanks!
Suvendu

On Thu, Mar 30, 2017 at 2:01 PM, Olaf Kock  wrote:
> Am 30.03.2017 um 01:33 schrieb Utkarsh Dave:
>> Hello all,
>>
>> My tomcat (7.0.72) hosts several web aplications in the server (based in
>> linux 6.8).
> [...]
>> Memory heap dump generated is of
>> Size: 787.3 MB Classes: 139k Objects: 19.3m Class Loader: 1.6k
> The combination of "hosts several web applications" and a heap space of
> this size does not convince me of a leak - it might be the memory
> requirement of one of the webapps. A leak is typically something that
> grows uncontrolled until you run out of heapspace, no matter how much
> you grow the available space.
>> In the thread dumps I see these threads repeatedly. I wonder these pointing
>> to com.rsa.sslj.x.
> You seem to be handling https requests from Tomcat. If you're not happy
> with the implementation of this endpoint/protocol you should move this
> to an Apache httpd or similar and just forward to tomcat, so that tomcat
> does not deal with encryption.
>
> As a conclusion: Your problem might not be poorly designed clients, it
> might be poorly equipped servers - I'd try to double the memory
> allocated to Tomcat's heap and potentially tune the garbage collector.
> If you run into problems, you might also identify one of the
> webapplications that eats up your resources (no matter what the clients
> do).
>
> Olaf
>
> -
> 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: Websocket & Logging

[Mark Thomas]

On 30/03/17 16:56, Addy D wrote:
> On Thu, Mar 30, 2017 at 8:49 PM, Konstantin Kolinko 
> wrote:
> 
>> 2017-03-30 12:15 GMT+03:00 Addy D :
>>> I can see following in log, while starting tomcat:
>>>
>>> Mar 30, 2017 2:33:22 PM
>>> org.springframework.web.socket.server.support.WebSocketHandlerMapping
>>> registerHandler
>>> INFO: Mapped URL path [/call] onto handler of type [class
>>> org.springframework.web.socket.server.support.
>> WebSocketHttpRequestHandler]
>>>
>>> Same kind of logs are also available when I run my Spring boot
>> application,
>>> in this app I am able to connect to wss://localhost:8443/call.



> No my application is not "ROOT",

The the URL you quote above won't work.

> i have my application as "myapp" but I
> have a similar (almost same, I am moving spring boot app to tomcat)
> spring-boot application which works fine with embedded tomcat in it with
> the same url, in fact in application startup time, I see "/call" getting
> registered in the tomcat log. as shown below.

You have two options.

1. Rename myapp.war to ROOT.war

2. Use wss://localhost:8443/myappp/call to access your service

I'd also recommend a careful read of the Servlet specification,
particularly section 3.5 along with this page from the Tomcat docs:
http://tomcat.apache.org/tomcat-8.5-doc/config/context.html#Naming

Mark

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

Re: Websocket & Logging

[Konstantin Kolinko]

2017-03-30 18:56 GMT+03:00 Addy D :
> On Thu, Mar 30, 2017 at 8:49 PM, Konstantin Kolinko 
> wrote:
>
>> 2017-03-30 12:15 GMT+03:00 Addy D :
>> > I can see following in log, while starting tomcat:
>> >
>> > Mar 30, 2017 2:33:22 PM
>> > org.springframework.web.socket.server.support.WebSocketHandlerMapping
>> > registerHandler
>> > INFO: Mapped URL path [/call] onto handler of type [class
>> > org.springframework.web.socket.server.support.
>> WebSocketHttpRequestHandler]
>> >
>> > Same kind of logs are also available when I run my Spring boot
>> application,
>> > in this app I am able to connect to wss://localhost:8443/call.
>>
>> 1. Rules:
>> http://tomcat.apache.org/lists.html#tomcat-users
>> -> 6. Top-posting is bad.
>>
>> 2. What is the name of your web application? Is it "ROOT"?
>> FAQ:
>> https://wiki.apache.org/tomcat/HowTo#How_do_I_make_my_
>> web_application_be_the_Tomcat_default_application.3F
>>
>
> Sorry for top-posting.
> No my application is not "ROOT", i have my application as "myapp" but I
> have a similar (almost same, I am moving spring boot app to tomcat)
> spring-boot application which works fine with embedded tomcat in it with
> the same url, in fact in application startup time, I see "/call" getting
> registered in the tomcat log. as shown below.

You wrote earlier that you tried the following URL:

> The exact url I am trying to hit is : wss://localhost:8443/call

If you application is named "myapp" then you must use the following URL:

wss://localhost:8443/myapp/call

> Mar 30, 2017 2:33:22 PM
> org.springframework.web.socket.server.support.WebSocketHandlerMapping
> registerHandler
> INFO: Mapped URL path [/call] onto handler of type [class
> org.springframework.web.socket.server.support.WebSocketHttpRequestHandler]

That is not an absolute path.
That is a path relative to your web application (relative to "context
root" as the Servlet specification says).

http://docs.oracle.com/javaee/7/api/javax/servlet/ServletContext.html#getContextPath--

> D:\Servers\tomcat-8.5.9\

Current is 8.5.12, with 8.5.13 expected in a few days (tomorrow?).

Best regards,
Konstantin Kolinko

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

Re: Websocket & Logging

[Addy D]

On Thu, Mar 30, 2017 at 8:49 PM, Konstantin Kolinko 
wrote:

> 2017-03-30 12:15 GMT+03:00 Addy D :
> > I can see following in log, while starting tomcat:
> >
> > Mar 30, 2017 2:33:22 PM
> > org.springframework.web.socket.server.support.WebSocketHandlerMapping
> > registerHandler
> > INFO: Mapped URL path [/call] onto handler of type [class
> > org.springframework.web.socket.server.support.
> WebSocketHttpRequestHandler]
> >
> > Same kind of logs are also available when I run my Spring boot
> application,
> > in this app I am able to connect to wss://localhost:8443/call.
>
> 1. Rules:
> http://tomcat.apache.org/lists.html#tomcat-users
> -> 6. Top-posting is bad.
>
> 2. What is the name of your web application? Is it "ROOT"?
> FAQ:
> https://wiki.apache.org/tomcat/HowTo#How_do_I_make_my_
> web_application_be_the_Tomcat_default_application.3F
>
> Best regards,
> Konstantin Kolinko
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Sorry for top-posting.
No my application is not "ROOT", i have my application as "myapp" but I
have a similar (almost same, I am moving spring boot app to tomcat)
spring-boot application which works fine with embedded tomcat in it with
the same url, in fact in application startup time, I see "/call" getting
registered in the tomcat log. as shown below.

Mar 30, 2017 2:33:22 PM
org.springframework.web.socket.server.support.WebSocketHandlerMapping
registerHandler
INFO: Mapped URL path [/call] onto handler of type [class
org.springframework.web.socket.server.support.WebSocketHttpRequestHandler]

Same logs are there when I run my spring boot application, further more I
also tried about enabling logging in tomcat, so I can investigate the issue
further but I am not able to start full logging in tomcat as well, (I tried
modifying logging.properties, but the log levels are already set to FINE, I
am not sure what to do with it).

Re: Websocket & Logging

[Konstantin Kolinko]

2017-03-30 12:15 GMT+03:00 Addy D :
> I can see following in log, while starting tomcat:
>
> Mar 30, 2017 2:33:22 PM
> org.springframework.web.socket.server.support.WebSocketHandlerMapping
> registerHandler
> INFO: Mapped URL path [/call] onto handler of type [class
> org.springframework.web.socket.server.support.WebSocketHttpRequestHandler]
>
> Same kind of logs are also available when I run my Spring boot application,
> in this app I am able to connect to wss://localhost:8443/call.

1. Rules:
http://tomcat.apache.org/lists.html#tomcat-users
-> 6. Top-posting is bad.

2. What is the name of your web application? Is it "ROOT"?
FAQ:
https://wiki.apache.org/tomcat/HowTo#How_do_I_make_my_web_application_be_the_Tomcat_default_application.3F

Best regards,
Konstantin Kolinko

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

Re: Websocket & Logging

[Addy D]

I can see following in log, while starting tomcat:

Mar 30, 2017 2:33:22 PM
org.springframework.web.socket.server.support.WebSocketHandlerMapping
registerHandler
INFO: Mapped URL path [/call] onto handler of type [class
org.springframework.web.socket.server.support.WebSocketHttpRequestHandler]

Same kind of logs are also available when I run my Spring boot application,
in this app I am able to connect to wss://localhost:8443/call.



On Thu, Mar 30, 2017 at 11:16 AM, Addy D 
wrote:

> Well, I haven't change the code, the thing was working with Spring boot
> (embedded tomcat) I just moved the code/app to an actual tomcat server.
>
> By trying the link from websocket.org I just wanted to confirm that
> nothing is wrong with my Java Script code or browser. I now come to a
> conclusion that something either on tomcat  or application side is missing.
>
> On Thu, Mar 30, 2017 at 12:43 AM, Igal @ Lucee.org  wrote:
>
>> That means that the Endpoint at websocket.org is configured correctly.
>>
>> How doe that help troubleshooting your Endpoint?
>>
>> Igal Sapir
>> Lucee Core Developer
>> Lucee.org 
>>
>> On 3/29/2017 12:10 PM, Addy D wrote:
>>
>>> No, I tried something different, I tried this url wss://
>>> echo.websocket.org,
>>> this one is working.
>>>
>>> On Wed, Mar 29, 2017 at 11:49 PM, Igal @ Lucee.org 
>>> wrote:
>>>
>>> Can you access it in a non-secure protocol?  i.e. ws:// instaed of
 wss://?

 Testing that can help eliminate possible issues.

 Igal Sapir
 Lucee Core Developer
 Lucee.org 


 On 3/29/2017 11:17 AM, Addy D wrote:

 The exact url I am trying to hit is : wss://localhost:8443/call
>
>
> On Wed, Mar 29, 2017 at 10:58 PM, Igal @ Lucee.org 
> wrote:
>
> On 3/29/2017 2:17 AM, Addy D wrote:
>
>> Hello all,
>>
>>> I am facing an issue in my application, I want to know following
>>> things.
>>>
>>> 1. The tomcat is returning 404 for upgrade header (request to
>>> upgrade to
>>> websocket protocol). Do I need to configure anything here?
>>>
>>> What's the Endpoint that you've set up (and how did you set it up)?
>>>
>> What is the exact URL that you're trying to hit with the ws://
>> request?
>>
>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>>
>>
>>
>

Re: Ways to identify poorly designed client aplications sending request to Tomcat !

[Olaf Kock]

Am 30.03.2017 um 01:33 schrieb Utkarsh Dave:
> Hello all,
>
> My tomcat (7.0.72) hosts several web aplications in the server (based in
> linux 6.8).
[...]
> Memory heap dump generated is of
> Size: 787.3 MB Classes: 139k Objects: 19.3m Class Loader: 1.6k
The combination of "hosts several web applications" and a heap space of
this size does not convince me of a leak - it might be the memory
requirement of one of the webapps. A leak is typically something that
grows uncontrolled until you run out of heapspace, no matter how much
you grow the available space.
> In the thread dumps I see these threads repeatedly. I wonder these pointing
> to com.rsa.sslj.x.
You seem to be handling https requests from Tomcat. If you're not happy
with the implementation of this endpoint/protocol you should move this
to an Apache httpd or similar and just forward to tomcat, so that tomcat
does not deal with encryption.

As a conclusion: Your problem might not be poorly designed clients, it
might be poorly equipped servers - I'd try to double the memory
allocated to Tomcat's heap and potentially tune the garbage collector.
If you run into problems, you might also identify one of the
webapplications that eats up your resources (no matter what the clients
do).

Olaf

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

Re: how to access HTTPServletRequest in RealmBase

[Konstantin Kolinko]

2017-03-30 11:02 GMT+03:00 Jan Vávra :
> Hello,
>  I have written a custom Realm and I need to access to the request headers.
> The authentication should be computed from client certificate + id from
> custom http header X-IdUser. Can I somehow access to the HTTPServletRequest
> instance  ?

Not possible, by design.

An Authenticator (a valve) can access request and its headers. A Realm cannot.

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

how to access HTTPServletRequest in RealmBase

[Jan Vávra]

Hello,
 I have written a custom Realm and I need to access to the request 
headers. The authentication should be computed from client certificate + 
id from custom http header X-IdUser. Can I somehow access to the 
HTTPServletRequest instance  ?


Jan.

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

Re: Websocket & Logging

[Addy D]

Well, I haven't change the code, the thing was working with Spring boot
(embedded tomcat) I just moved the code/app to an actual tomcat server.

By trying the link from websocket.org I just wanted to confirm that nothing
is wrong with my Java Script code or browser. I now come to a conclusion
that something either on tomcat  or application side is missing.

On Thu, Mar 30, 2017 at 12:43 AM, Igal @ Lucee.org  wrote:

> That means that the Endpoint at websocket.org is configured correctly.
>
> How doe that help troubleshooting your Endpoint?
>
> Igal Sapir
> Lucee Core Developer
> Lucee.org 
>
> On 3/29/2017 12:10 PM, Addy D wrote:
>
>> No, I tried something different, I tried this url wss://
>> echo.websocket.org,
>> this one is working.
>>
>> On Wed, Mar 29, 2017 at 11:49 PM, Igal @ Lucee.org 
>> wrote:
>>
>> Can you access it in a non-secure protocol?  i.e. ws:// instaed of wss://?
>>>
>>> Testing that can help eliminate possible issues.
>>>
>>> Igal Sapir
>>> Lucee Core Developer
>>> Lucee.org 
>>>
>>>
>>> On 3/29/2017 11:17 AM, Addy D wrote:
>>>
>>> The exact url I am trying to hit is : wss://localhost:8443/call


 On Wed, Mar 29, 2017 at 10:58 PM, Igal @ Lucee.org 
 wrote:

 On 3/29/2017 2:17 AM, Addy D wrote:

> Hello all,
>
>> I am facing an issue in my application, I want to know following
>> things.
>>
>> 1. The tomcat is returning 404 for upgrade header (request to upgrade
>> to
>> websocket protocol). Do I need to configure anything here?
>>
>> What's the Endpoint that you've set up (and how did you set it up)?
>>
> What is the exact URL that you're trying to hit with the ws:// request?
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
>
>
>