Re: mod_proxy_ajp equivalent for JK_LB_ACTIVATION?

2020-03-06 Thread Rainer Jung

Hi Chris,

no, the status unfortunately is not available as an Apache env var.

mod_proxy_ajp has a builtin provision for automatic env var forwarding: 
alle env vars named AJP_SOMETHING will be forwarded as request attribute 
SOMETHING. But I see no easy way of detecting drain mode and setting an 
env var and there seems to be nothing builtin. I remember having added 
the forwarding for the LB activation to mod_jk many years ago but well 
after mod_proxy_ajp was done by Mladen. It seems to be one of the 
missing features in mod_proxy_ajp.


But of course it could be added ...

Regards,

Rainer

Am 06.03.2020 um 16:34 schrieb Christopher Schultz:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

At $work, we use mod_jk for proxying and I'd like to move to
mod_proxy_ajp with an eye toward moving to mod_proxy_http eventually.

We use the JK_LB_ACTIVATION state to perform load-balanced
node-draining[1] for maintenance and I'm trying to find out how to get
mod_proxy to give me its current status.

I don't see anything in the documentation for mod_proxy_balancer or
mod_proxy_ajp.

- From the balancer-manager, I can see that there are several items of
status metadata that might be useful:

- - worker "draining mode"
- - worker "disabled" state
- - worker "hot standby" state
- - worker "stopped" state

Each worker has a "status" value, which can be any of D/S/I/R/H/E/N
but it also looks like each of those can be set independently. So the
worker can be in "hot standby" + "error" states. Hmm.

Is that state available in an environment variable I can forward-over
to the origin node?

- -chris


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



Re: secureRandom... using [SHA1PRNG] ..took (up to) 20 minutes

2019-12-30 Thread Rainer Jung
It depends a bit on the major Java version you are using, but have a 
look at this page:


https://cwiki.apache.org/confluence/display/TOMCAT/HowTo+FasterStartUp#HowToFasterStartUp-EntropySource

Regards,

Rainer

Am 30.12.2019 um 05:01 schrieb Vince Stewart:

I started recently using my my java app with embedded Tomcat / 8.0.28 on a
debian VPS (DigitalOcean).

Unfortunately, it can take up to 20 minutes to launch into action from the
time you start execution. The issue relates to "Creation of SecureRandom
instance ... using SHA1PRNG".  Slowness has been described and explained in
Stackoverflow.

My tomcat has otherwise been so reliable that I have had no motivation to
keep it upgraded.  Can anyone advise if some change will apply if I upgrade
to the latest version 8.

Otherwise, is there a configuration change I could employ.

Many thanks,


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



Re: Apache SSI breaks with tomcat-connectors-1.2.43 or newer

2019-09-30 Thread Rainer Jung
_match::jk_uri_worker_map.c (1010): exit
[Mon Sep 30 15:04:03 2019][3906:140148297873536] [trace] 
map_uri_to_worker_ext::jk_uri_worker_map.c (1208): exit
[Mon Sep 30 15:04:03 2019][3906:140148297873536] [debug] 
jk_map_to_storage::mod_jk.c (4039): no match for /test-ssi/index.shtml found
[Mon Sep 30 15:04:03 2019][3906:140148297873536] [debug] 
jk_servlet_normalize::jk_util.c (2184): URI on entering 
jk_servlet_normalize: []
[Mon Sep 30 15:04:03 2019][3906:140148297873536] [emerg] 
jk_servlet_normalize::jk_util.c (2188): [] does not start with '/'.
[Mon Sep 30 15:04:03 2019][3906:140148297873536] [debug] 
jk_servlet_normalize::jk_util.c (2184): URI on entering 
jk_servlet_normalize: []
[Mon Sep 30 15:04:03 2019][3906:140148297873536] [emerg] 
jk_servlet_normalize::jk_util.c (2188): [] does not start with '/'.
[Mon Sep 30 15:04:04 2019][3926:140148297873536] [trace] 
jk_child_init::mod_jk.c (3440): enter
[Mon Sep 30 15:04:04 2019][3926:140148297873536] [trace] 
do_shm_open::jk_shm.c (548): enter
[Mon Sep 30 15:04:04 2019][3926:140148297873536] [debug] 
do_shm_open::jk_shm.c (679): Attached shared memory 
/etc/httpd/logs/jk.shm.3905 [7] size=1024 workers=0 free=0 
addr=0x7f76d1838000
[Mon Sep 30 15:04:04 2019][3926:140148297873536] [trace] 
do_shm_open_lock::jk_shm.c (459): enter
[Mon Sep 30 15:04:04 2019][3926:140148297873536] [debug] 
do_shm_open_lock::jk_shm.c (473): Duplicated shared memory lock 
/etc/httpd/logs/jk.shm.3905.lock
[Mon Sep 30 15:04:04 2019][3926:140148297873536] [trace] 
do_shm_open_lock::jk_shm.c (475): exit
[Mon Sep 30 15:04:04 2019][3926:140148297873536] [trace] 
do_shm_open::jk_shm.c (723): exit
[Mon Sep 30 15:04:04 2019][3926:140148297873536] [debug] 
jk_child_init::mod_jk.c (3463): Initialized mod_jk/1.2.44
[Mon Sep 30 15:04:04 2019][3926:140148297873536] [trace] 
jk_child_init::mod_jk.c (3464): exit




On Wed, Sep 18, 2019 at 7:24 AM Rainer Jung <mailto:rainer.j...@kippdata.de>> wrote:


Am 17.09.2019 um 17:44 schrieb Ezsra McDonald:
 > Hello,
 >
 > Environment:
 > OS: CentOS 7
 > Apache: Apache/2.4.6 (CentOS)
 > Working Connector: tomcat-connectors-1.2.42
 >
 > When we installed the latest version of the connector, 1.2.46 at
this time,
 > some of our customer Server Side Includes stopped working. SSIs using
 > the  directives produce the following error in
the log
 > files:
 >
 > unable to include "layout/includes/headernav.html" in parsed file
 > /var/www/html/horses/index.shtml, subrequest setup returned 400,
referer:
 > http://10.211.55.44/horses/
 >
 > When we roll back to tomcat-connectors-1.2.42 the SSI works.
 >
 > We do not know why tomcat-connectors impact mod_include.
 >
 > Any assistance would be appreciated.

It seems you can easily reproduce. Can you set JkLogLevel to trace and
run one request that shows the failure? Then provide the resulting
mod_jk log file plus your mod_jk configuration (all Jk... diractives
plus workers.properties plus uriworkermap.properties or similar if
in use).

Thanks and regards,

Rainer



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



Re: [OT] TLSv1.3 in TC8.5 + Azul Java 8

2019-09-23 Thread Rainer Jung

Am 06.08.2019 um 18:37 schrieb George Stanchev:

So it seems to work. For whoever is interested to try, the openjsse comes prebundled with Azul's 
distro, all you need to do is run with -XX:+UseOpenJSSE command line option. On TC side, I added 
"TLSv1.3" to "sslEnabledProtocols":

sslEnabledProtocols="+TLSv1 +TLSv1.1 +TLSv1.2 +TLSv1.3"

Also not sure if I had to but also added the 1.3 ciphers under ciphers 
attribute:

ciphers="TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, 
TLS_CHACHA20_POLY1305_SHA256,"


Concerning TLS 1.3 support, one can also use OpenJSSE with other Java 8 
based builds of OpenJDK, eg. RedHat's build or Adopt. To enable OpenJSSE 
with those, you can eg. (tried with TC9, should work for TC 8.5 as well):


- Include the openjsse jar into your CLASSPATH

- Add

  -Djava.security.properties=${CATALINA_BASE}/conf/java.security

  to your CATALINA_OPTS

- Put the following line into the new file 
${CATALINA_BASE}/conf/java.security:


  security.provider.4=org.openjsse.net.ssl.OpenJSSE

The number 4 in that line is taken from the file java.security installed 
with Java 8. It should be jre/lib/security/java.security and the line 
your are looking (and that gets overwritten by the above) for is


  security.provider.4=com.sun.net.ssl.internal.ssl.Provider

The number "4" can vary and must be adjusted accordingly above.

That should be enough to enable TLS 1.3. If you haven't explicitly set 
protocols or ciphers in server.xml, there's no need to set them for TLS 
1.3. You can check the TLS version you clients use by adding the 
followoing column to your AccessLogValve pattern:


  %{org.apache.tomcat.util.net.secure_protocol_version}r

For TLS 1.3 the value will be "TLSv1.3".

Note that to enable HTTP/2 there is a small TC patch needed I am working 
on. That is due to the simplistic ALPN detection we currently use in TC, 
which is simply checking the Java version number, not effective APN 
support in JSSE.



I am getting some socket warnings though [1]. Anyone knows if those are benign?


It seems to me, that you have taken those warnings from the output you 
get, when enable Java TLS debugging using -Djavax.net.debug=all or 
similar. I can see those warninhgs as well, but I do also get them when 
using plain Java 11. So they are not a backport artefact.


Regards,

Rainer



[1]

ERROR 2019-08-02 13:25:31,425 [SYSERR] -- [] 
javax.net.ssl|DEBUG|01|main|2019-08-02 13:24:51.000 
MDT|SSLCipher.java:436|jdk.tls.keyLimits:  entry = AES/GCM/NoPadding KeyUpdate 
2^37. AES/GCM/NOPADDING:KEYUPDATE = 137438953472
javax.net.ssl|DEBUG|03|Finalizer|2019-08-02 13:24:51.228 
MDT|SSLSocketImpl.java:473|duplex close of SSLSocket
javax.net.ssl|WARNING|03|Finalizer|2019-08-02 13:24:51.230 
MDT|SSLSocketImpl.java:494|SSLSocket duplex close failed (
"throwable" : {
   java.net.SocketException: Socket is not connected
 at java.net.Socket.shutdownOutput(Socket.java:1553)
 at 
org.openjsse.sun.security.ssl.BaseSSLSocketImpl.shutdownOutput(BaseSSLSocketImpl.java:233)
 at 
org.openjsse.sun.security.ssl.SSLSocketImpl.duplexCloseOutput(SSLSocketImpl.java:561)
 at 
org.openjsse.sun.security.ssl.SSLSocketImpl.close(SSLSocketImpl.java:479)
 at 
org.openjsse.sun.security.ssl.BaseSSLSocketImpl.finalize(BaseSSLSocketImpl.java:276)
 at java.lang.System$2.invokeFinalize(System.java:1270)
 at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:102)
 at java.lang.ref.Finalizer.access$100(Finalizer.java:34)
 at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:217)}

)
javax.net.ssl|DEBUG|03|Finalizer|2019-08-02 13:24:51.230 
MDT|SSLSocketImpl.java:473|duplex close of SSLSocket
javax.net.ssl|WARNING|03|Finalizer|2019-08-02 13:24:51.230 
MDT|SSLSocketImpl.java:494|SSLSocket duplex close failed (
"throwable" : {
   java.net.SocketException: Socket is not connected
 at java.net.Socket.shutdownOutput(Socket.java:1553)
 at 
org.openjsse.sun.security.ssl.BaseSSLSocketImpl.shutdownOutput(BaseSSLSocketImpl.java:233)
 at 
org.openjsse.sun.security.ssl.SSLSocketImpl.duplexCloseOutput(SSLSocketImpl.java:561)
 at 
org.openjsse.sun.security.ssl.SSLSocketImpl.close(SSLSocketImpl.java:479)
 at 
org.openjsse.sun.security.ssl.BaseSSLSocketImpl.finalize(BaseSSLSocketImpl.java:276)
 at java.lang.System$2.invokeFinalize(System.java:1270)
 at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:102)
 at java.lang.ref.Finalizer.access$100(Finalizer.java:34)
 at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:217)}

)
javax.net.ssl|DEBUG|3E|https-jsse-nio-8243-exec-2|2019-08-02 13:25:31.164 
MDT|SSLExtensions.java:132|Ignore unknown or unsupported extension (
"unknown extension (13,172)": {

}
)
javax.net.ssl|DEBUG|3E|https-jsse-nio-8243-exec-2|2019-08-02 13:25:31.164 
MDT|SSLExtensions.java:132|Ignore unknown or unsupported extension (
"unknown extension (22)": {

}
)

Re: Apache SSI breaks with tomcat-connectors-1.2.43 or newer

2019-09-18 Thread Rainer Jung

Am 17.09.2019 um 17:44 schrieb Ezsra McDonald:

Hello,

Environment:
OS: CentOS 7
Apache: Apache/2.4.6 (CentOS)
Working Connector: tomcat-connectors-1.2.42

When we installed the latest version of the connector, 1.2.46 at this time,
some of our customer Server Side Includes stopped working. SSIs using
the  directives produce the following error in the log
files:

unable to include "layout/includes/headernav.html" in parsed file
/var/www/html/horses/index.shtml, subrequest setup returned 400, referer:
http://10.211.55.44/horses/

When we roll back to tomcat-connectors-1.2.42 the SSI works.

We do not know why tomcat-connectors impact mod_include.

Any assistance would be appreciated.


It seems you can easily reproduce. Can you set JkLogLevel to trace and 
run one request that shows the failure? Then provide the resulting 
mod_jk log file plus your mod_jk configuration (all Jk... diractives 
plus workers.properties plus uriworkermap.properties or similar if in use).


Thanks and regards,

Rainer


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



Re: Massive Startup Time after Server Reboot

2019-05-18 Thread Rainer Jung
Most likely it hangs waiting for enough entropy for random number 
generator seeding.


Try whether the problem goes away if you add

  -Djava.security.egd=file:/dev/urandom

to you process flags. If you are using older Java than Java 8 (not 
possible for Tomcat 9 but just in case you also have older software 
stacks running), then it would be


  -Djava.security.egd=file:/dev/./urandom

The cryptic /./ is not a typo, you would need it for Java before Java 8.

If this doesn't help, then you should try capturing a few stack dumps 
(thread dumps) during the long startup time. People here can help 
interpret them.


Regards,

Rainer

Am 18.05.2019 um 21:55 schrieb Jerry Malcolm:
This is a weird one.  It started a few months ago.   I have TC 9 running 
on Windows Server 16.  After I reboot the entire server, Tomcat takes 
forever on startup.  It normally starts in about 30 seconds.  But after 
a server reboot it takes up to 15 minutes... chugging along at a snail's 
pace starting up all of the apps on all of the virtual hosts.  It always 
finally gets there with everything successfully running.  Other servers 
on the same box (Apache, JAMES, ISC BIND, MySQL) don't have any problem 
starting up.  CPU, Disk, Memory, etc. usages are barely showing on the 
performance graphs.  There's nothing in the Catalina log or system.err 
other than showing a couple of minute gap in the time stamp between each 
app as it starts up.  If I need to reboot again later, it boots again in 
about 30 sec as expected.


First question... any ideas off the top of your head that might be 
causing this?


Second question... is there any other logging I can turn on that might 
explain what TC is blocking on?


Thanks.

Jerry


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



Re: Apache httpd / tomcat AJP connector(s?)

2019-05-09 Thread Rainer Jung

Am 08.05.2019 um 10:14 schrieb Mark Thomas:

On 07/05/2019 13:37, André Warnier (tomcat) wrote:

Hi.

On 26.04.2019 18:16, Mark Thomas wrote:

On 24/04/2019 10:58, André Warnier (tomcat) wrote:

Hi.

This is somewhat of an arcane question and somewhat straddling httpd and
tomcat, so if I'm on the wrong list for this, just let me know.


Here is fine. We can always move the thread if necessary.


The question is : is there any particular reason why the combination
mod_proxy + mod_proxy_ajp (in httpd), does not seem to follow the
ProxyPreserveHost directive, when proxying something from httpd to
tomcat ?


None that I am aware of.

I've complete a quick test with httpd 2.4.34 and Tomcat 9.0.x and I see
the host header is passed via AJP as expected.

I suggest wireshark to look at what is on the wire.


I haven't done a wireshark trace yet.
But as a cheap approximation for now, I tried to use the (tomcat) Access
Log to see what was going on, and there I hit another (but I believe
related) issue :

According to :
http://tomcat.apache.org/tomcat-8.5-doc/config/valve.html#Access_Log_Valve
some patterns available are :
- %p - Local port on which this request was received.
and
- %{xxx}p write local (server) port (xxx==local) or remote (client) port
(xxx=remote)

So if I understand this right, "%{local}p" should print the same as
"%p", and both should be "the local port on which this request was
received".


When using AJP the original values as received by httpd and passed by
AJP are injected into the Tomcat request so things like redirects are
generated correctly without additional configuration.

It is one of those scenarios where things happen by "magic" which are
great when it works bur can make debugging more complicated.

Mark


Don't know whether it really helps, but long time ago I but some infos on

http://tomcat.apache.org/connectors-doc/common_howto/proxy.html

Concerning %p versus %{local}p and %{remote}p: I think the idea is %p is 
just the originally supported format and now also the short form of 
%{local}p. The various sub types of %p (local and remote) IMHO were 
added later similar to what the Apache web server supports.


Regards,

Rainer

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



Re: Is there a limit to mod_jk?

2019-04-25 Thread Rainer Jung

Am 25.04.2019 um 06:22 schrieb John Larsen:

Hello,

Is there a limit to the number of workers instances mod_jk can handle?


There will be limits due to general file descriptor limits, each TCP 
connection counts as a file descriptor. But I am not aware of a limit on 
the number of workers per se.



I currently have 38 tomcat instances running on a machine. I have had up to
75 in the past, but this machine I keep getting bind exception errors but
lsof -i :port comes up empty when that particular tomcat is offline.


These numbers do not look that high. A nasty limit on some linuxes is 
the number of processes (maxproc or ulimit -u). It is counted per user 
and despite its name it actually counts tasks, and each thread in each 
process of a user is such a task. So it actually counts the number of 
threads in all processes fo some user id. The first process that hits 
the limit will only observe, that it can not start a new thread. 
Typically this will result in very unexpected behavior.



Im at loss as to what is causing it. Usually bind exceptions is when
another java process is running on the same port - but not the case here.
Even if i shutdown apache where mod_jk isnt being used tells me this is
really unrelated to mod_jk


How exactly does the exception look like (full stack)?


mod_jk.log:
[Thu Apr 25 04:14:07.458 2019] [30178:139932601325312] [error]
ajp_service::jk_ajp_common.c (2796): (w314) connecting to tomcat failed
(rc=-3, errors=2, client_errors=0).
[Thu Apr 25 04:14:07.458 2019] [30178:139932601325312] [info]
jk_handler::mod_jk.c (2991): Service error=-3 for worker=w314

I tried updating mod_jk to 1.2.46


There should be additional log lines directly above the snippet you 
showed here. Could you provide a more complete snippet?


Regards,

Rainer


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



Re: Crash in http connector random once a day

2019-03-14 Thread Rainer Jung
In each of the four thread dumps, there are (the same) 4 threads 
connected to and waiting for an answer from a PHP FCGI backend behind 
Tomcat. You need to investigate, why that backend isn't sending a 
response (or takes so long for it).


Regards,

Rainer

Am 14.03.2019 um 14:11 schrieb Daniel Castilla | thin(k)design:

From: Daniel Castilla | thin(k)design [mailto:d...@thin-k-design.com]
Sent: Thursday, March 14, 2019 12:37 PM
To: Jäkel, Guido ; users@tomcat.apache.org
Subject: Re: Crash in http connector random once a day

Dear Guido,

thanks for the reply. The requests are reaching tomcat, and a thread
is always started, if I look at the current threads on the tomcat
manager I see the following, there are 4 threads that are processing
since 2+ hours:

R ? ? ? ? ? ?
S 16 ms 0 KB 0 KB 0:0:0:0:0:0:0:1 0:0:0:0:0:0:0:1 localhost GET /manager/status 
HTTP/1.1
S 7256779 ms 0 KB 33 KB 0:0:0:0:0:0:0:1 0:0:0:0:0:0:0:1 localhost POST 
/cloudworx/?method=words=17385 HTTP/1.1
S 7274046 ms 0 KB 33 KB 0:0:0:0:0:0:0:1 0:0:0:0:0:0:0:1 localhost POST 
/cloudworx/?method=words=18986 HTTP/1.1
S 7228088 ms 0 KB 33 KB 0:0:0:0:0:0:0:1 0:0:0:0:0:0:0:1 localhost POST 
/cloudworx/?method=words=10560 HTTP/1.1
R ? ? ? ? ? ?
S 7290093 ms 0 KB 33 KB 0:0:0:0:0:0:0:1 0:0:0:0:0:0:0:1 localhost POST 
>/cloudworx/?method=words=10560 HTTP/1.1

I'm not sure what other metrics would be helpful, but your Unix script
wouldn't help much, as I am on a Windows Server 2012 and I would like
to avoid installing Cygwin or something similar.


Dear Daniel,

the script just read-out the same core data and does some pretty print. You may 
do it by your own by doing a HTTP-Request against


URL='http://'${CREDS}'@'${HOST}':'${PORT}'/manager/jmxproxy?qry=Catalina:type=RequestProcessor,*'


What is interesting from your snippet that there are POST Request "in Service" 
(i.e. Progress) since more than 2h. And you told that the ID is unique, but there are two 
times a '10560'.

Is there a database service involved in the backend?

BTW: In addition to pull static thread dumps you may use JVisualVM to get a 
live view to the threads.


Dear Guido and Mark,

the same Id '10560' appears twice in the URL as the same request was
retried for two times, the third time it worked.
The other two URLs had only one retry, the second time it worked.

You can find a complete thread dump here (I hope the link gets
through): 
https://drive.google.com/file/d/1kfSoJovb0bPHWxg-fh6zD8hTGJ6STq2Z/view?usp=sharing

I had to restart tomcat now in order to access the jmxproxy as it
wasn't active in the user roles, so the active "problem" processes are
gone for now. But it will happen again, at latest tomorrow.

I tried JVisualVM, but I am no Java Expert and don't know what to search for...

Thanks
Daniel


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



Re: Followup2: Changed behaviour of Tomcat Deployment/Context/Lifecycle Manager concerning symbolic links

2019-03-11 Thread Rainer Jung

Am 11.03.2019 um 08:09 schrieb Michael Osipov:

Am 2019-03-10 um 22:29 schrieb Mark Thomas:

On 10/03/2019 20:54, Michael Osipov wrote:

Am 2019-03-10 um 12:16 schrieb Mark Thomas:

On 10/03/2019 09:08, Guido Jäkel wrote:

Dear John, Hi Rainer,

Thank you for your hints. I leaned to used this features on Github
locate the commit - it's

 https://github.com/apache/tomcat/commit/fd2abbb525660a9968694afd99a58f8c22cb54c6 




and it was committed by Mark Thomas. I don't know about the Tomcat
project policies, but IMHO in the commit comment there was not any
real hit for the motivation for the change or any reference to an
issue ticket or a pull request. There's just one sentence for the
changelog:

  Ensure that a canonical path is always used for the docBase
of a Context
  to ensure consistent behaviour. (markt)

But I can't get any idea from that what the author (Mark?) want to
say with the terms "ensure" and "consistent". And it's classified as
a "fix", but up to now I was not able to find the use case that is
said to be fixed with this.

  From my point of view, the change lead to something what might be
termed with "inconsistent", because now the link name is used as
docBase, but the link destination is used to decide concrete aspects
of Context loading.



@Rainer: I familiarize me with the blame/history feature and have
located the commit with this. But now, please tell me how to object
against this change? Should I prepare a Git pull request against the
master repository? Should I open an Issue somewhere? And how to
locate the discussion that lead to this change? This should be tied
to prevent flapping and respect and arrange with the motivation there.


Changes aren't made on a whim.  It is recommended that you investigate
why a change was made before objecting to it.

When a commit message in isolation appears to be missing context then
that context can normally be found on the dev@ list. The 24 hours of
dev@ traffic leading up to this commit should provide all the necessary
background.


There aren't any. I see the commit mail in Thunderbird, but no
discussion on the change:

Message-Id: <20181003111609.0b0143a0...@svn01-us-west.apache.org>

So, what now?


The context is there on the dev@ list in the 24 hours leading up to that
commit.


Sorry, I seem to be blind. Can you point me to the discussion? I can't 
find anything in my tomcat-dev folder.


I think Mark refers to this one:

https://marc.info/?l=tomcat-dev=153856675022101=2

Regards,

Rainer


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



Re: Followup2: Changed behaviour of Tomcat Deployment/Context/Lifecycle Manager concerning symbolic links

2019-03-09 Thread Rainer Jung

Hi Guido,

Am 09.03.2019 um 10:09 schrieb Guido Jäkel:

Dear Mark,

thank you for comments and hints. I would say I have a wide knowledge about 
hard and software. But as I'm not working as a software developer, I'm not 
familiar with a lot of things in deep. I also don't have key-ready workbenches 
or buildchains. But I'll try to locate the corresponding commit using web 
access to the git. May I also contact you afterwards for further steps? Should 
I try to open an issue on the git or should I start a discussion in the Tomcat 
developer mailing list?


To add small hints: the project is available on Github, which provides 
an easy web interface for basic code archeology. E.g. the class you 
metioned can be viewed at


https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/startup/ContextConfig.java

and that page contains buttons for "Blame" - which shows when and in 
which commit each line was changes last, and also "History" which shows 
the list of changes applied to that file.


The above link if for master (TC 9), but analogous pages exist for each 
branch, e.g.


https://github.com/apache/tomcat/blob/8.5.x/java/org/apache/catalina/startup/ContextConfig.java

Regards,

Rainer


On 08.03.19 21:58, Mark Thomas wrote:

On 08/03/2019 11:59, Jäkel, Guido wrote:

Good news!

I reverted the change and this solve my issue at once, i.e. all former 
installed applications will start up as expected.

So, please what was the reason or intention here to shift from  getPath() to  
getCanonicalPath()  in case of a link (detected by !file.isAbsolute() )? What's the 
motivation to "fully expand" the path here at Java level instead of delegating 
this to the underlying OS?


Tomcat is an open source project. git (and svn that we used until
recently) provides a feature that lets you identify the most recent
commit associated with any line of code. Every commit includes a log
message. That is usually where you'd find an explanation for why a
commit was made. Have you tried looking?

Mark



greetings

Guido


(I'm going to check this out right now)

May somebody point me to a ticket for the commit of this change and/or an issue 
ticket leading to this change? I want to know
the motivation for this change and I want to please to find a solution to keep 
the old behavior. Because in my eyes, the current
is inconsistent: For the context naming and so on, the well-known behavior is 
kept -- the context is named by the naming of the
link itself and not of it's destination. And therefore, this should also hold 
for all other aspects


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



Re: loss of connection with mod_jk(tomcat connector)

2019-02-06 Thread Rainer Jung

Hi Rajendra,

Am 06.02.2019 um 12:36 schrieb Rathore, Rajendra:

Hi Mark,

I am stuck and due to below issue unable to update to latest tomcat connector, 
can you please share your finding, let me know if you need anything from my 
side, I also raise issue https://bz.apache.org/bugzilla/show_bug.cgi?id=63075 
but there is no progress on it.


as Mark already wrote, your mod_jk log file shows, that many of your 
tomcat instances are down.


You have configured a load balancer with 9 members, listening on 
localhost ports 8010-8018, but of these 9 tomcat instances only the one 
listening on port 8010 was up. So some requests work, because they were 
forwarded coincidentally to the working port, others fail, because they 
were forwarded to one of the 8 ports were nothing is listening and even 
their failover failed, because when only one out of 9 ports work, 
chances are very high, that the failover also hits a port where nothing 
listens.


mod_jk remembers the failing workers (ports) for some time and will not 
retry to use them, but as I wrote in the ticket, you have a broken 
JkShmFile, so mod_jk balancers can not correctly work. Fix that problem 
first and make sure your ports are actually listening.


Regards,

Rainer


-Original Message-
From: Rathore, Rajendra 
Sent: 17 January 2019 10:33 AM
To: Tomcat Users List 
Subject: RE: loss of connection with mod_jk(tomcat connector)

External email from: users-return-266670-rarathore=ptc@tomcat.apache.org

Hi Mark,

We configure multiple tomcat and based on the configuration start other tomcat, 
since one tomcat running fine but after some time it will stop communicating, 
this problem we face from Tomcat Connector 1.2.46 version onwards, for 1.2.43 
it works fine, please let me know if I need to enable extra loggers that will 
help out to understand the problem better,

Thanks and Regards,
Rajendra Rathore
9922701491

-Original Message-
From: Mark Thomas 
Sent: 17 January 2019 05:05 AM
To: Tomcat Users List 
Subject: Re: loss of connection with mod_jk(tomcat connector)

External email from: users-return-29-rarathore=ptc@tomcat.apache.org

On 16/01/2019 12:26, Rathore, Rajendra wrote:

Hi Team,

  


we are using Apache Http server with basic authentication, when we try
to send some request to apache for authentication it will fail with
401 error and when we check the JK Status,

we found that status was not proper means instead of 'OK' state it was
'Awaiting..'. We are facing this issue with tomcat connector 1.2.46,
it worked with 1.2.43. I attached our log files for your reference,
please let me know if you need anything else.


Logs show the Tomcat instances aren't listening on the configured host/ports.

Mark


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



Re: latest situation with escaped path delimiters in URI

2019-02-04 Thread Rainer Jung

Am 03.02.2019 um 22:20 schrieb Garret Wilson:
Hi, all. I've stumbled on a situation I need some clarity on. As is 
typical, there's all sorts of information floating around, most of it 
more than a decade old, with no indication of what the current status is.


Our team is creating a RESTful API (using JAX-RS implemented by 
RESTEasy) to a general semantic framework in which each "thing" is 
identified by a URI. (The framework is URF , but that's 
a story for another day. It's analogous to RDF.) Basically we want to 
issue a GET to https://example.com/{thingURI}/description to get back 
info about the "thing".


If we want to look up the thing identified by 
https://example.info/foobar, we would need to issue a request to 
https://example.com/https%3A%2F%2Fexample.info%2Ffoobar/description . 
That should be completely legal and spec-compliant, and has been since 
web time began.


You no doubt already know the problem: Tomcat won't allow encoded 
slashes unless one sets system property 
org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH to true. 
Apparently this there was a bug somewhere in Tomcat 6 
 
(back in 2007!) when used behind a proxy, as Mark explained on Stack 
Overflow . Tomcat 6 is 
really old, and Mark's Stack Overflow message seems to hint that it's 
not an issue anymore.


I'm not one to blindly change a setting unless I know what it's doing, 
and complain/advocate for change if it's no longer relevant. So I'm full 
of questions:


  * Is this even an issue anymore? Of not, is there a reason not to make
    org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH default to 
true?

  * If this setting is still needed in some cases, is there any way to
    control it without resorting to a system property? (System
    properties are not very flexible, and Tomcat has many layers of more
    manipulable settings, as you all would know better than me.)
  * If we enable encoded slashes in Tomcat, do we need to do anything in
    Apache to get this to work if we put it in front of Tomcat? One
    really old Stack Overflow post
     indicated that there
    used to be a bug with AllowEncodedSlashes not being inherited by
    Apache virtual hosts. See also
    https://issues.sonatype.org/browse/NEXUS-10570 .


Looking at the code in server/core.c in the current 2.4.x, merging 
config is implemented in merge_core_dir_configs() and indeed the 
sessiongs for AllowEncodedSlashes  are not inherited from the global 
server into virtual hosts but instead overwritten by what is set in the 
virtual host inluding its default values. So yes, you need to explicitly 
set it in virtual hosts. This has been fixed in trunk in 2013 
(r1496339), but was not ported back to 2.4 probably due to compatibility 
reasons.



  * Do we need special configuration of mod_kj? (I haven't connected
    Apache to Tomcat in a while; I'm not sure the current best
    practices. I'll have to read up on that.) The connectors
    documentation
     is
    mentioning things like ForwardURIEscaped, which looks like it may be
    related.


In addition to Mark's response: once your web server config needs to 
change the original URL, e.g. by mod_rewrite, it will likely decode at 
least parts of the URL to operate on a normalized URL. Once that 
happens, there's no obvious way back to an encoded URL that is 
consistent with the original one. Encoding is not really the reverse of 
decoding, eg. when a character does not have to be encoded, but was 
encoded in the original URL, the sequence decode then encode will not 
encode it back.


You might want to set AllowEncodedSlashes NoDecode and test it.

See http://tomcat.apache.org/connectors-doc/common_howto/proxy.html, 
especially "URL Encoding" and for details of some of the 
non-recommeneded options 
http://tomcat.apache.org/connectors-doc/reference/apache.html especially 
"Forwarding".


I'm not even sure I asked all the right questions, but basically: I want 
to uses encoded slashes in my request URIs. What's the latest situation 
on that?


Regards,

Rainer

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



Re: help installing mod_jk on Centos 7 on a Google Cloud server

2018-11-21 Thread Rainer Jung

> Nov 21 18:32:37 server2 httpd[24339]: Invalid command 'JkWorkersFile',
> perhaps misspelled or defined by a module not included in the server
> configuration

That means that there was no LoadModule line for mod_jk before that 
config line. You originally posted the first config line "LoadModule 
jk_module modules/mod_jk.so" bus either the module was located somewhere 
else, or - more likely - during this attempt here the LoadModule line wa 
sno longer in place.



[Wed Nov 21 15:54:19.916294 2018] [jk:warn] [pid 11957] No JkShmFile
defined in httpd.conf. Using default /etc/httpd/logs/jk-runtime-status
[Wed Nov 21 15:54:19.916632 2018] [jk:emerg] [pid 11957] Initializing
shm:/etc/httpd/logs/jk-runtime-status.11957 errno=13. Unable to start due
to shared memory failure.
[Wed Nov 21 15:54:19.916639 2018] [jk:emerg] [pid 11957] Initializing
shm:/etc/httpd/logs/jk-runtime-status.11957 errno=13. Unable to start due
to shared memory failure.


errno=13 means access error, so the user who runs the httpd server does 
not have rights to create a shared memory file at 
/etc/httpd/logs/jk-runtime-status.11957. Have a look at 
/etc/httpd/logs/, check whether it exists and whether the httpd runtime 
user has full rights on the directory. If you can not get rights there, 
choose another path where you have rights and set it using


JkShmFile "/path/to/my/jk-runtime-status"


[Wed Nov 21 15:54:19 2018] [11957:140478724515968] [warn]
jk_map_handle_duplicates::jk_map.c (456): Duplicate key $


That is weired and doesn't match the config you posted. Especially since 
you didn't use either a worker mapping properties file not any JkMount 
directive. So either with the above problems fixed, i would not expect 
you mod_jk to get any requests passed over from httpd to handle them.


Also the config in your workers.properties doesn't look really good. i 
suggest you look at the exaple config you received inside 
tomcat-connectors-1.2.46-src.tar.gz and start form there. But first fix 
the above first two errors.


Regards,

Rainer

Am 21.11.2018 um 19:41 schrieb Lou Wallace:

Hey Greg,

Thanks for the info. I changed both httpd.conf and workers.properties to
your settings. Got the same error msg when I restarted httpd.

When I checked journalist I get

● httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor
preset: disabled)
Active: failed (Result: exit-code) since Wed 2018-11-21 18:32:37 UTC;
3min 51s ago
  Docs: man:httpd(8)
man:apachectl(8)
   Process: 24340 ExecStop=/bin/kill -WINCH ${MAINPID} (code=exited,
status=1/FAILURE)
   Process: 24339 ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND
(code=exited, status=1/FAILURE)
  Main PID: 24339 (code=exited, status=1/FAILURE)
Nov 21 18:32:37 server2 systemd[1]: Starting The Apache HTTP Server...
Nov 21 18:32:37 server2 httpd[24339]: AH00526: Syntax error on line 63 of
/etc/httpd/conf/httpd.conf:
Nov 21 18:32:37 server2 httpd[24339]: Invalid command 'JkWorkersFile',
perhaps misspelled or defined by a module not included in the server
configuration
Nov 21 18:32:37 server2 systemd[1]: httpd.service: main process exited,
code=exited, status=1/FAILURE
Nov 21 18:32:37 server2 kill[24340]: kill: cannot find process ""
Nov 21 18:32:37 server2 systemd[1]: httpd.service: control process exited,
code=exited status=1
Nov 21 18:32:37 server2 systemd[1]: Failed to start The Apache HTTP Server.
Nov 21 18:32:37 server2 systemd[1]: Unit httpd.service entered failed state.
Nov 21 18:32:37 server2 systemd[1]: httpd.service failed.



On Wed, Nov 21, 2018 at 11:31 AM Greg Huber  wrote:


For my centos/mod._jk I use :

/etc/httpd/conf.d/my.conf :

...
JkWorkersFile "/etc/httpd/conf.d/workers.properties"
JkLogFile "/etc/httpd/logs/mod_jk.log"
JkShmFile "/etc/httpd/logs/jk-runtime-status.log"
JkLogLevel info
JkLogStampFormat "[%a %b %d %H:%M:%S %Y]"

JkMount  / worker1
JkMount  /* worker1


workers.properties :
# Define 1 real worker using ajp13
worker.list=worker1
# Set properties for worker1 (ajp13)
worker.worker1.type=ajp13
worker.worker1.host=localhost
worker.worker1.port=8009
worker.worker1.socket_keepalive=1


On Wed, 21 Nov 2018 at 16:19, Lou Wallace  wrote:


Hi Everyone,

So still having issues with mod_jk. I have downloaded

wget



http://www.eu.apache.org/dist/tomcat/tomcat-connectors/jk/tomcat-connectors-1.2.46-src.tar.gz

wget



http://www.eu.apache.org/dist/tomcat/tomcat-connectors/jk/tomcat-connectors-1.2.46-src.tar.gz.sha1


and make install, and everything seems fine

I then edited the httpd.conf file and added

LoadModule jk_module modules/mod_jk.so

JkWorkersFile "/etc/httpd/conf/workers.properties"
JkLogFile "/var/log/mod_jk.log"
JkLogLevel  info
JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories
JkRequestLogFormat "%w %V %T"

then I edited workers.properties and added

worker.list=app1,app2

worker.app1.type=ajp13

Re: precompile JSPs failure issue - Tomcat community

2018-11-06 Thread Rainer Jung

Am 06.11.2018 um 10:10 schrieb Rathore, Rajendra:

Hi Rainer/Chris,

I tried below command, it also fails with same error,
Please find attached output of strace command, I am unable to found any help 
from that file or I might not have much idea about it, can you please check it 
and let me know your finding, mean while is there any way to run the jspc 
command in single thread model like 8.5.32 tomcat version.


I see

10807 clone(child_stack=0x7f53af001fb0, 
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, 
parent_tidptr=0x7f53af0029d0, tls=0x7f53af002700, 
child_tidptr=0x7f53af0029d0) = -1 EAGAIN (Resource temporarily unavailable)


I'm not sure, whether that is actualy the same error that you eported 
originally "unable to create new native thread" or whether you now got a 
different error logged?


The man pages for the clone() system call says:

  EAGAIN Too many processes are already running; see fork(2)

and the fork() man page says:

  EAGAIN fork() cannot allocate sufficient memory to copy the parent's 
page tables and allocate a task structure for the child.


  EAGAIN It  was  not  possible  to create a new process because the 
caller's RLIMIT_NPROC resource limit was encountered.  To exceed this 
limit, the process must have either the CAP_SYS_ADMIN or the 
CAP_SYS_RESOURCE capability.


So I would - as already mentioned - check you nproc limit (output of 
"ulimit -u" and "ulimit -u -h") and I would also *reduce* the heap size 
a lot.


Regards,

Rainer



Thanks and Regards,
Rajendra Rathore
9922701491

-Original Message-
From: Christopher Schultz 
Sent: 02 November 2018 06:48 PM
To: users@tomcat.apache.org
Subject: Re: precompile JSPs failure issue - Tomcat community

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Rainer,

On 11/2/18 06:20, Rainer Jung wrote:

You can control the number of threads using -threadCount. By default
the number is equals to the number of cores the operating system show
to the JVM.


x 2


You might want to use a smaller number to see whether that helps.

I suggest you also check your Linux system limits on processes per
user. That system limit on Linux in fact limits threads per user.
So if such a limit is set and your user has other processes with many
threads running, you might need to increase this limit.

In addition you can run your ant process with

strace -f -o /var/tmp/strace.out HERE_COMES_YOUR_ANT_COMMAND &

Then after you get the error, you can check the strace.out file for
system call errors. The file will be big, but most probably the error
is relatively close to the end.


- -chris


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



Re: precompile JSPs failure issue - Tomcat community

2018-11-02 Thread Rainer Jung

Am 02.11.2018 um 11:23 schrieb Rathore, Rajendra:

Hi Rainer,

We never face this issue with tomcat 8.5.32 and from 8.5.33 it will causing the 
issue and it happen on both OS Window and Linux, it will be blocking for us 
because we are not able to update tomcat to latest on and it had some security 
issue fixed in it, please let me know how should I proceed from here.


Others have already pointed you at

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

This introduced a new feature to JspC to make the compilation 
multi-threaded. Before this change it was always done on only one thread.


The good: it will make the compilation of your many JSPs faster.

The bad: it seems to create a yet to understand new problem for you.

I suggest you follow the hints, that I gave in my previous mail.

Regards,

Rainer


Thanks and Regards,
Rajendra Rathore
9922701491

-Original Message-
From: Rainer Jung 
Sent: 02 November 2018 03:50 PM
To: Tomcat Users List ; Rathore, Rajendra 

Subject: Re: precompile JSPs failure issue - Tomcat community

Am 02.11.2018 um 10:57 schrieb Rathore, Rajendra:

Hi Mark,

I tried with tomcat 8.5.33 and face the same issue, I logged a bug
also
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbz.ap
ache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D62879data=02%7C01%7Crar
athore%40ptc.com%7C80d42185b225483c061508d640accfbb%7Cb9921086ff774d0d
828acb3381f678e2%7C0%7C0%7C636767508304565081sdata=FGguJAuq0y%2Ft
TMNTsd%2Fezc6yTbuOD5wxzlNWdYs8wFI%3Dreserved=0

Please let me know how should I proceed here?

Thanks and Regards,
Rajendra Rathore
9922701491

-Original Message-
From: Rathore, Rajendra 
Sent: 01 November 2018 06:10 PM
To: Tomcat Users List 
Subject: RE: precompile JSPs failure issue - Tomcat community

Hi Chao,

We already tried it and it still failing.

Thanks and Regards,
Rajendra Rathore
9922701491

-Original Message-
From: Guang Chao 
Sent: 01 November 2018 06:07 PM
To: Tomcat Users List 
Subject: Re: precompile JSPs failure issue - Tomcat community

On Thu, Nov 1, 2018 at 7:13 PM Rathore, Rajendra  wrote:


Hi Mark,

I am suspecting the same in 8.5.33 tomcat, do you still won't me to
check it on tomcat 8.5.33?



How about increasing your perm memory?




Thanks and Regards,
Rajendra Rathore
9922701491

-Original Message-
From: Guang Chao 
Sent: 01 November 2018 03:41 PM
To: Tomcat Users List 
Subject: Re: precompile JSPs failure issue - Tomcat community

On Thu, Nov 1, 2018 at 5:33 PM Mark Thomas  wrote:


On 01/11/2018 09:21, Rathore, Rajendra wrote:

Hi Team,



We have precompileJSPs tests that include compilation of around
4000 jsp files. After upgrading to Tomcat *8.5.34* from Tomcat
*8.5.32* we are facing an *Error:*/java.lang.OutOfMemoryError:
unable to create new native thread /



The machines on which tests were executed have *16GB* of RAM, out
of which around *13GB* was free.

The precompileJSPs tests were executed on Tomcat *8.5.34* by
setting ANT_OPTS from -Xmx4096m to -Xmx10240m, But Still the result
was /OutOfMemoryError./

/ /

However, We successfully tested precompileJSPs tests for Tomcat
*8.5.32 *with ANT_OPTS as -Xmx384m



Can someone please have a look into this issue?


Have you looked at the change log for the changes between 8.5.32 and
8.5.34 that might be relevant?



It could be changelog in 8.5.33

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbz.a
p
ache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D53011data=02%7C01%7Cra
r
athore%40ptc.com%7Cc0bce30fc877421ebd6808d63ff6f1f2%7Cb9921086ff774d0
d
828acb3381f678e2%7C0%7C0%7C636766727188877636sdata=diEmx1WNaWPvH
%
2FGMd8Ex%2B4AgZCaGxcC6fez5UD%2FEF1c%3Dreserved=0

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbz.a
p
ache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D53492data=02%7C01%7Cra
r
athore%40ptc.com%7Cc0bce30fc877421ebd6808d63ff6f1f2%7Cb9921086ff774d0
d
828acb3381f678e2%7C0%7C0%7C636766727188877636sdata=rl1N7m5upe4E7
A
3zTAx4oht2cjUHfuDoNCWoOHKfkrs%3Dreserved=0





Have you tried testing with 8.5.33 to narrow down the version in
which the issue first appears?

Mark


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




--
Guang <
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fjavad
e
vnotes.com%2Fjava-string-to-datedata=02%7C01%7Crarathore%40ptc.c
o
m%7Cc0bce30fc877421ebd6808d63ff6f1f2%7Cb9921086ff774d0d828acb3381f678
e
2%7C0%7C0%7C636766727188877636sdata=lEQmu2kFIquRsA5rAeVw17HYosy6
O
03GGZvt6d6CWCA%3Dreserved=0







--
Guang
<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fjavad
evnotes.com%2Fjava-string-comparedata=02%7C01%7Crarathore%40ptc.c
om%7C80d42185b225483c061508d640accfbb%7Cb9921086ff774d0d828acb3381f678
e2%7C0%7C0%7C636767508304565081sdata=Cx%2BDIalffZ3EcaSb7oPQVPx5sl
JFqdnMg8r2A10E6M8%3Dreserved

Re: precompile JSPs failure issue - Tomcat community

2018-11-02 Thread Rainer Jung

Am 02.11.2018 um 10:57 schrieb Rathore, Rajendra:

Hi Mark,

I tried with tomcat 8.5.33 and face the same issue, I logged a bug also
https://bz.apache.org/bugzilla/show_bug.cgi?id=62879

Please let me know how should I proceed here?

Thanks and Regards,
Rajendra Rathore
9922701491

-Original Message-
From: Rathore, Rajendra 
Sent: 01 November 2018 06:10 PM
To: Tomcat Users List 
Subject: RE: precompile JSPs failure issue - Tomcat community

Hi Chao,

We already tried it and it still failing.

Thanks and Regards,
Rajendra Rathore
9922701491

-Original Message-
From: Guang Chao 
Sent: 01 November 2018 06:07 PM
To: Tomcat Users List 
Subject: Re: precompile JSPs failure issue - Tomcat community

On Thu, Nov 1, 2018 at 7:13 PM Rathore, Rajendra  wrote:


Hi Mark,

I am suspecting the same in 8.5.33 tomcat, do you still won't me to
check it on tomcat 8.5.33?



How about increasing your perm memory?




Thanks and Regards,
Rajendra Rathore
9922701491

-Original Message-
From: Guang Chao 
Sent: 01 November 2018 03:41 PM
To: Tomcat Users List 
Subject: Re: precompile JSPs failure issue - Tomcat community

On Thu, Nov 1, 2018 at 5:33 PM Mark Thomas  wrote:


On 01/11/2018 09:21, Rathore, Rajendra wrote:

Hi Team,



We have precompileJSPs tests that include compilation of around
4000 jsp files. After upgrading to Tomcat *8.5.34* from Tomcat
*8.5.32* we are facing an *Error:*/java.lang.OutOfMemoryError:
unable to create new native thread /



The machines on which tests were executed have *16GB* of RAM, out
of which around *13GB* was free.

The precompileJSPs tests were executed on Tomcat *8.5.34* by
setting ANT_OPTS from -Xmx4096m to -Xmx10240m, But Still the
result was /OutOfMemoryError./

/ /

However, We successfully tested precompileJSPs tests for Tomcat
*8.5.32 *with ANT_OPTS as -Xmx384m



Can someone please have a look into this issue?


Have you looked at the change log for the changes between 8.5.32 and
8.5.34 that might be relevant?



It could be changelog in 8.5.33

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbz.ap
ache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D53011data=02%7C01%7Crar
athore%40ptc.com%7Cc0bce30fc877421ebd6808d63ff6f1f2%7Cb9921086ff774d0d
828acb3381f678e2%7C0%7C0%7C636766727188877636sdata=diEmx1WNaWPvH%
2FGMd8Ex%2B4AgZCaGxcC6fez5UD%2FEF1c%3Dreserved=0

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbz.ap
ache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D53492data=02%7C01%7Crar
athore%40ptc.com%7Cc0bce30fc877421ebd6808d63ff6f1f2%7Cb9921086ff774d0d
828acb3381f678e2%7C0%7C0%7C636766727188877636sdata=rl1N7m5upe4E7A
3zTAx4oht2cjUHfuDoNCWoOHKfkrs%3Dreserved=0





Have you tried testing with 8.5.33 to narrow down the version in
which the issue first appears?

Mark


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




--
Guang <
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fjavade
vnotes.com%2Fjava-string-to-datedata=02%7C01%7Crarathore%40ptc.co
m%7Cc0bce30fc877421ebd6808d63ff6f1f2%7Cb9921086ff774d0d828acb3381f678e
2%7C0%7C0%7C636766727188877636sdata=lEQmu2kFIquRsA5rAeVw17HYosy6O
03GGZvt6d6CWCA%3Dreserved=0







--
Guang 

B CB  [  
X  ܚX KK[XZ[
  \ \  ][  X  ܚX P X ]
  \X K ܙ B  ܈Y][ۘ[  [X[  K[XZ[
  \ \  Z[ X ]
  \X K ܙ B


You can control the number of threads using -threadCount. By default the 
number is equals to the number of cores the operating system show to the 
JVM. You might want to use a smaller number to see whether that helps.


I suggest you also check your Linux system limits on processes per user. 
That system limit on Linux in fact limits threads per user. So if such a 
limit is set and your user has other processes with many threads 
running, you might need to increase this limit.


In addition you can run your ant process with

strace -f -o /var/tmp/strace.out HERE_COMES_YOUR_ANT_COMMAND &

Then after you get the error, you can check the strace.out file for 
system call errors. The file will be big, but most probably the error is 
relatively close to the end.


Regards,

Rainer


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



Re: mod_jk endpoints

2018-10-21 Thread Rainer Jung

Am 22.10.2018 um 00:53 schrieb Jerry Malcolm:

On 10/21/2018 3:17 AM, Mark Thomas wrote:


We provide the Windows binaries because the build process is more 
involved, most users don't have the necessary toolchain  easily 
available and we only need to provide one binary for all Windows 
platforms (ok we provide several binaries with different build options 
but it is still a small, manageable number).



Mark,

Does you mean that I can use the Windows binary dll that is in the 
mod_jk iis binaries download if I'm running Apache and Tomcat on a Win 
Server platform instead of using mod_jk.so?


No, IIS binaries can not be used as module binaries for Apache httpd on 
Windows. But you typically get module binaries from the same sources 
that provide Apache httpd on Windows for you. The problem there is, that 
the module and the web server must be build with compatibel compiler 
setups. Therefore it is best to get them from the same providers (like 
Apache Lounge or others).


Regards,

Rainer


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



Re: mod_jk endpoints

2018-10-21 Thread Rainer Jung

Am 22.10.2018 um 00:43 schrieb Jerry Malcolm:

On 10/21/2018 7:27 AM, Rainer Jung wrote:

Plus:

mod_http2 uses additional threads per Apache httpd process. Look for 
H2Workers, H2MinWorkers and H2MaxWorkers in the mod_http2 docs. By 
default it seems you get ThreadsPerChild normal http worker threads 
plus ThreadsPerChild HTTP/2 worker threads.


So the old-style assumption of mod_jk, that it is enough to provide as 
many backend connections per httpd process, as normal httpd worker 
threads are configured (ThreadsPerChild), does no longer apply for 
HTTP/2.


You could try increasing the mod_jk pool size (connection_pool_size) 
to 2*ThreadsPerChild, but you might also want to consider switching to 
mod_proxy.


Regards,

Rainer


Rainer,

I've done some reading up on mpm, http/2, etc.  But it's given me more 
questions than answers.  I need a bit of education help sorting this out.


Back to the original problem.  I need to understand these mod_jk log 
entries (there are hundreds of them...):


[Sun Oct 21 17:15:19 2018] [10116:5456] [warn] 
ajp_get_endpoint::jk_ajp_common.c (3229): Unable to get the free 
endpoint for worker worker1 from 64 slots


That means the size of the per process connection pool used to connect 
to Tomcat "worker1" is 64 and all 64 connections were busy when another 
one was needed. Probably this 64 was not configured by you but instead 
auto-sized via ThreadsPerChild (MPM sizing). From what I understand 
about the HTTP/2 implementation by mod_http2, you should try in doubling 
the number of endpoints by setting 
worker.worker1.connection_pool_size=128 in workers.properties without 
changing ThreadsPerChild. Some info on the param can be found at 
http://tomcat.apache.org/connectors-doc/reference/workers.html.


What you need to keep in mind: it is also possible, that the real 
culprit is, that already 64 connections from one Apache process to the 
backend were busy. That could mean, that the requests became too slow in 
Tomcat or more likely in your application running in Tomcat. So I would 
suggest you also take thread dumps, in this case of Tomcat worker1, when 
the above message happens frequently to find out, what those 64 
concurrent requests are doing (that use up all 64 possible connections).


[Sun Oct 21 17:15:19 2018] [10116:5456] [error] jk_handler::mod_jk.c 
(2744): Could not get endpoint for worker=worker1
[Sun Oct 21 17:15:19 2018] [10116:5456] [info] jk_handler::mod_jk.c 
(2806): Service error=0 for worker=worker1


These two are just follow-up messages of the above.

a) what does a 'free endpoint' represent?  Is it an httpd thread that it 
can't get?  Is it a connection to Tomcat?  Something else?


Connection from a specific Apache httpd process to Tomcat. These 
endpoints=connections are pooled per Apache process. The number of 
connections can be configured via worker.WORKER_NAME.connection_pool_size.



b) it says it has 64 of whatever it's looking for what is a 'slot'?


Just a synonym for endpoint. By slot in that message is meant an item in 
the pool.


I currently have no mpm enabled.  I am running on WAMP (May2018 
download).   From what I can tell after much digging, Apache Windows 
does not use prefork, worker, or event mpm and rather has it's own WinNT 
mpm.  The default config file has only two parms for WinNT. But this mpm 
config file is commented out by default.  I'll enable it.


Ah, Windows. So unlike Unix/Linux we do only have a single child 
process, which does all the work. The number 64 is the default number of 
threads in this child for Windows.




     ThreadsPerChild    150
     MaxConnectionsPerChild   0



OK, after that you have 150 threads in the one and only Apache httpd 
child process, that does all the work. mod_jk will automatically also 
set the number of endpoints (slots) = the connection_pool_size to 150, 
if not configured by you otherwise.


You suggested increasing connection_pool_size.  Is there a way to see 
what pool size is set to by default?  The docs talk about iis, iPlanet, 
etc defaults.  But it's not clear what it's set to for my default 
config.  Is there some kind of config dump option for mod_jk?


Configure a status worker. It has plenty of interesting info. For 
monitoring it is enough to configure a read-only status worker. See 
http://tomcat.apache.org/connectors-doc/reference/status.html.


You also suggested moving to mod_proxy.  You really lost me there. I 
found info on how to config proxy, etc.  But I couldn't find anything 
about how proxy differs from non-proxy.  What problem does it solve? And 
how would it potentially fix my issue?


mod_jk and mod_proxy are simply two different ways of connecting Apache 
httpd to backend Tomcats. mod_jk uses a special protocol named AJP13 
(and an AJP connector in Tomcat which understands that protocol). 
mod_proxy simply uses HTTP or HTTPS and the normal HTTP/HTTPS connector 
in Tomcat. mod_jk is provided by the Tomcat project and configured 

Re: mod_jk endpoints

2018-10-21 Thread Rainer Jung

Am 21.10.2018 um 10:17 schrieb Mark Thomas:

On October 21, 2018 7:38:25 AM UTC, Greg Huber  wrote:

So I'm using the 2016 1.2.40 version.


Think you have to build mod_jk to use the latest and greatest,


Correct.

We stopped providing binary builds for anything other than Windows because 
there were just too many combinations. And it is relatively simple to build on 
Linux.

We provide the Windows binaries because the build process is more involved, 
most users don't have the necessary toolchain  easily available and we only 
need to provide one binary for all Windows platforms (ok we provide several 
binaries with different build options but it is still a small, manageable 
number).


this is
what
I have in my notes (also from the website docs):

mod_jk.so build
yum install httpd-devel
download tomcat-connectors-x.x.xx-src.tar.gz
extract and cd into the native folder
cd /opt/apache-tomcat/tomcat-connectors-x.x.xx-src/native
./configure --with-apxs=/usr/bin/apxs
make
copy file ./apache-2.0/mod_jk.so to /etc/httpd/modules
make clean

(I only have a pretty much standard workers.properties so can't help
much.)

On Sun, 21 Oct 2018 at 02:01, Jerry Malcolm 
wrote:


Thanks for the responses to my earlier post about websockets/JSPs.
Http/2 is definitely the right answer for my issue there.

HTTP/2 solved the problem with the throttling the multiple parallel
requests with the browser connection limits.  But now opening that
throttle has now exposed a different problem at the server.  Quick
refresh I have an app that does not have many concurrent users at
this time.  However it does periodically have a very large number of
concurrent requests (AJAX/REST) from a single client.

I now realize that with the browser limiting concurrent requests in
HTTP/1.1, mod_jk was not getting overwhelmed.  But now that the
floodgates have opened with HTTP/2, I realize that I have some

serious

configuration problems with mod_jk.  The requests are clogging up in
mod_jk, timing out, and logging errors something like "cannot get
endpoint for worker".  It then takes about 5 minutes for the clog to
clear out before mod_jk is functional again for the other virtual

hosts

I'm hosting.

Specifics... I'm using Apache 2.4.33, Tomcat 9.0.  I tried to

download

the latest mod_jk.so.  The latest mod_jk for httpd on the binaries
download site is from 2016.  All the versions for the past 2 years

are

iis only... I assume that's ok???  So I'm using the 2016 1.2.40

version.


My question is how do I increase the number of 'endpoints' that
mod_jk has access to?  Is that a TC configuration or

workers.properties

setting?  I want to make sure mod_jk has enough resources/endpoints

to

pass (i.e.not 'block') all the requests it receives.  Once mod_jk is
passing everything, I realize the flood might hit TC, and I may be

back

asking about increasing TC resources.  But for now, I just want to

get

mod_jk opened up.


We need to see the configuration for:

- httpd mpm / threads / processes
- workers.proprties
- Tomcat's AJP connector


Plus:

mod_http2 uses additional threads per Apache httpd process. Look for 
H2Workers, H2MinWorkers and H2MaxWorkers in the mod_http2 docs. By 
default it seems you get ThreadsPerChild normal http worker threads plus 
ThreadsPerChild HTTP/2 worker threads.


So the old-style assumption of mod_jk, that it is enough to provide as 
many backend connections per httpd process, as normal httpd worker 
threads are configured (ThreadsPerChild), does no longer apply for HTTP/2.


You could try increasing the mod_jk pool size (connection_pool_size) to 
2*ThreadsPerChild, but you might also want to consider switching to 
mod_proxy.


Regards,

Rainer


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



Re: OCSP stapling in tomcat 7 with APR

2018-10-17 Thread Rainer Jung
Redirect when accessing http://ocsp.comodoca.com could simply be a 
trailing slash redirect (Location: http://ocsp.comodoca.com/). You 
better use http://ocsp.comodoca.com/ (note the slash at the end of the URL).


Regards,

Rainer

Am 17.10.2018 um 15:09 schrieb Усманов Азат Анварович:

SSLLabs  test still shows "OCSP stapling no" even with the latest version 
openssl

I've tried to test it manually and got an error


  openssl ocsp -issuer /home/idis/authorities.crt  -cert /home/idis/STAR

 
_ieml_ru.crt -text -url http://ocsp.comodoca.com
OCSP Request Data:
 Version: 1 (0x0)
 Requestor List:
 Certificate ID:
   Hash Algorithm: sha1
   Issuer Name Hash: 7AE13EE8A0C42A2CB428CBE7A605461940E2A1E9
   Issuer Key Hash: 90AF6A3A945A0BD890EA125673DF43B43A28DAE7
   Serial Number: F078CB8E2F4E5A678BFB9065A9611B57
 Request Extensions:
 OCSP Nonce:
 041002914B015477EC5C503D4FD630D616F3
Error querying OCSP responder
140179572442880:error:27076072:OCSP routines:parse_http_line1:server response 
er  
   
ror:crypto/ocsp/ocsp_ht.c:260:Code=301

Not sure what might be the problem?
301 looks like a http error  Moved Permamently   which is strange  because
i tried to access   http://ocsp.comodoca.com via wget

  wget  http://ocsp.comodoca.com
--2018-10-17 16:03:12--  http://ocsp.comodoca.com/
Устанавливается соединение с 192.168.1.2:3128... соединение установлено.
Запрос Proxy послан, ожидается ответ... 200 OK
Длина: 5 [application/ocsp-response]
Saving to: «index.html.7»

100%[===>]
 5   --.-K/s   в 0s

2018-10-17 16:03:12 (488 KB/s) - «index.html.7» saved [5/5]

[root] ~# less index.html.7
0^C
^A^A
index.html.7 (END)
any ideas what might be the problem?



От: Усманов Азат Анварович 
Отправлено: 15 октября 2018 г. 18:20:14
Кому: users@tomcat.apache.org
Тема: Re: OCSP stapling in tomcat 7 with APR

how do I make sure ocsp is enabled on tomcat native

when I try to pass --enable-ocsp to tomcat native configure i get unrecognized 
option warning


   ./configure  --with-apr=/usr/local/apr 
--with-java-home=/usr/java/jdk1.7.0_79 -with-ssl=/usr/local/openssl 
--enable-ocsp
configure: WARNING: unrecognized options: --enable-ocsp
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking target system type... x86_64-pc-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking for working mkdir -p... yes
Tomcat Native Version: 1.2.17
checking for chosen layout... tcnative
checking for APR... yes
configure: APR 1.6.5 detected.
   setting CC to "gcc"
   setting CPP to "gcc -E"
   setting LIBTOOL to "/usr/local/apr/build-1/libtool"
checking JAVA_HOME... /usr/java/jdk1.7.0_79
   adding "-I/usr/java/jdk1.7.0_79/include" to TCNATIVE_PRIV_INCLUDES
checking for JDK os include directory...  linux
   adding "-I/usr/java/jdk1.7.0_79/include/linux" to TCNATIVE_PRIV_INCLUDES
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for OpenSSL library... using openssl from 
/usr/local/openssl/${exec_prefix}/lib and /usr/local/openssl/include
checking OpenSSL library version >= 1.0.2... ok
checking for OpenSSL DSA support... yes
   adding "-I/usr/local/openssl/include" to TCNATIVE_PRIV_INCLUDES
   setting TCNATIVE_LDFLAGS to "-L/usr/local/openssl/lib 
-Wl,-rpath,/usr/local/openssl/lib -lssl -lcrypto"
   adding "-DHAVE_OPENSSL" to CFLAGS
   setting TCNATIVE_LIBS to ""
   setting TCNATIVE_LIBS to " /usr/local/apr/lib/libapr-1.la -lrt -lcrypt  
-lpthread"
checking for apr_pollset_wakeup in -lapr-1... yes
   adding "-DHAVE_POLLSET_WAKEUP" to CFLAGS
configure: creating ./config.status
config.status: creating tcnative.pc
config.status: creating Makefile
config.status: executing default commands
configure: WARNING: unrecognized options: --enable-ocsp




От: Mark Thomas 
Отправлено: 15 октября 2018 г. 15:01:58
Кому: users@tomcat.apache.org
Тема: Re: OCSP stapling in tomcat 7 with APR

On 14/10/18 18:45, Усманов Азат Анварович wrote:

Hello everyone! I have  an java 7 web app running on tomcat 7 with 

Re: Load Balancing to Tomcat Workers

2018-10-04 Thread Rainer Jung

Just adding a bit below ...

Am 03.10.2018 um 22:40 schrieb Christopher Schultz:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Loai,

On 10/3/18 16:07, Loai Abdallatif wrote:

Hello,

I have configures web server with jk load balancer to tomcat
server (192.168.237.11) with two containers  worker 0, worker1) the
problem is that the web application session seems keep rotating
between both workers but I need session stickeness, means the
client will be connected to the same worker which doesn't occur ,


Sticky sessions are the default.


the workers.properties file has this content :
worker.list=EVOUCHER_LB, jk-status, jk-manager, EVOUCHER_LB #
Define worker0 -- appserver1 worker.worker_app1.type=ajp13
worker.worker_app1.host=192.168.237.11
worker.worker_app1.port=8009
worker.worker_app1.socket_timeout=1200
worker.worker_app1.connection_pool_size=1
worker.worker_app1.connection_pool_timeout=1300
worker.worker_app1.lbfactor=1
worker.worker_app1.redirect=worker_app2
worker.worker_app1.sticky_session=1


You haven't specified a route name. Is the jvmRoute for your
192.168.237.11 set to "worker_app1"? If not, you'll have to set
worker.worker_app1.route=routeName and do the same in your 
for your jvmRoute attribute.


#
#Define worker1 -- appserver1 worker.worker_app2.type=ajp13
worker.worker_app2.host=192.168.237.11
worker.worker_app2.port=8109
worker.worker_app2.socket_timeout=1200
worker.worker_app2.connection_pool_size=1
worker.worker_app2.connection_pool_timeout=1300
worker.worker_app2.lbfactor=1
worker.worker_app2.redirect=worker_app1
worker.worker_app2.sticky_session=1


Same here.

Read the workers.properties documentation[1] for these settings just
to make sure you understand everything before you start changing
things. Specifically, read the introduction to the "Load Balancing
Directives" section (which specifically, in RED TEXT, warns you about
setting these parameters and making sure they agree). Read about the
"route" attribute and also read about "redirect" (which shouldn't be
necessary unless there is a specific reason to fail-over to one worker
specifically, as opposed to one in particular). The only use-case I
can think of for "redirect" is when you are using the BackupManager
for session-clustering.


I don't see a balancer worker defined (type lb) and configured. Some of 
the attributes you set belong to a balancer worker. I suggest reading


http://tomcat.apache.org/connectors-doc/common_howto/loadbalancers.html

The point about setting jvmRoute in your Tomcat's server.xml is very 
important.


A good starting point for a mod_jk config is here:

http://svn.apache.org/viewvc/tomcat/jk/trunk/conf/

The files are also contained in the source release of mod_jk available under

https://tomcat.apache.org/download-connectors.cgi

Regards,

Rainer





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



Re: jk_handler::mod_jk.c (2917): Could not get endpoint for worker ...

2018-09-21 Thread Rainer Jung

Am 15.09.2018 um 12:50 schrieb Clemens Wyss DEV:

Hi all,
we are seeing quite a few:
"[Mon Sep 10 15:19:46 2018] [27562:140532026529536] [error] jk_handler::mod_jk.c 
(2917): Could not get endpoint for worker=testAPJ"

errors in our md_jk.log. Worker properties are as follwos:

...
worker.list=testAPJ

worker.testAPJ.port=8009
worker.testAPJ.host=127.0.0.1
worker.testAPJ.type=ajp13
worker.testAPJ.socket_keepalive=1
worker.testAJP.connection_pool_timeout=600
...

At that point Apache seems to be stuck/struggling (but our tomcat does not seem 
to be under pressure). Restarting Apache solves the issue ... till it pops up 
again ...

What is happening? What needs tob e tuned?

Apache 2.4.34, tried both event- and worker-MPM


Assuming this is mod_jk 1.2.44? Are there more setting for worker testAPJ?

Normally mod_jk creates as many local connection structures (named 
endpoints) in each Apache httpd child process, as that process has 
worker threads. When an httpd worker thread wants to talk to tomcat, it 
retrieves such an endpoint and uses it to create and handle the 
commnunication.


The error you observe means, that all endpoints were already in use. 
Since we create as many structures as there are worker threads - 
everything is per httpd process, this should not happen (and I don't 
remember any case were it did happen).


Ideas what could go wrong:

- setting the worker property connection_pool_size or the deprecated 
cachesize for worker testAPJ to a smaller value than your httpd 
ThreadsPerChild (32 from your config snippet). If not set, mod_jk 
automatically detects the number of httpd worker threads


- setting connection_acquire_timeout to a small value. By default it is 
equals to retries*retry_interval which in turn by default is equals to 
2*100 milliseconds. mod_jk will retry getting an endpoint before it 
shows you error message "retries" times with a sleep pause of 
"retry_interval" milliseconds but no longer than 
connection_acquire_timeout milliseconds.


- retrieving and endpoint must acquire a lock first. On some platforms 
locking can lead to problems like false positives in deadlock detection. 
But i think this can't happen here since the code doesn't check the 
return value of the locking.


- memory shortage leading to failing allocations (not likely but possible)

Do you see any other log messages? Any ones in the httpd error log or 
especially the mod_jk log? There should be a WARN message of type 
"Unable to get the free endpoint for worker %s from %u slots" but maybe 
more before that final problem happens? What do you see with JkLogLevel 
info?


Does the problem happen under high load or when your backend gets slow? 
What does "netstat -anp | grep 8009" show when the hang occurs?


Regards,

Rainer

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



Re: [mod_jk] No data for "LE" (last error timestamp) column in lb status

2018-07-23 Thread Rainer Jung

Hi Chris,

Am 20.07.2018 um 16:29 schrieb Christopher Schultz:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

I've got a lb worker with two balanced nodes. One of the nodes has a
non-zero value for the "Err" (errors) field, but there is a blank
entry for the "LE" (last error timestamp) field.

I'm using mod_jk 1.2.41 on x86-64 Linux.

The whole XML record (with some things redacted is here):



I don't see any information about the "last error timestamp" in the
raw data. Does this field actually exist?


At least there is code in jk_status.c to handle it. And if it is empty 
in the HTML view, the same condition will drop it from the other views.


But it works different for a rway AJP worker and an lb member:

- raw AJP worker (not in an lb):

The underlying field is a "volatile time_t error_time" defined in 
jk_shm.h as part of the struct jk_shm_ajp_worker.


It gets set in jk_ajp_common.c to time(NULL) whenever either an AJP 
worker goes into error state or its busy count is above the limit. The 
field never gets reset.


It is used in jk_status.c to print the LE column and also for XML and 
properties output.



- AJP worker as a member in an lb:

The underlying field is a "volatile time_t first_error_time" defined in 
jk_shm.h as part of the struct jk_shm_lb_sub_worker.


It gets set in jk_ajp_common.c to time(NULL) whenever either an AJP 
worker goes into error state or its busy count is above the limit. The 
field gets reset when a worker leaves the error state (probably the case 
in your situation) and when you reset the worker statistics via the 
status worker. The fields can get set before the worker goes into error, 
namely if error_escalation_time allows to ignore errors for some time 
before setting an erred worker into error state.


All in all I would say the filed is less useful for lb members than for 
raw AJP workers.


Regards,

Rainer

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



Re: tomcat jmx questions / help

2018-03-29 Thread Rainer Jung

Hi Chris,

Am 28.03.2018 um 21:06 schrieb Christopher Schultz:

Also, for some background:
https://tomcat.apache.org/presentations.html

Search the page for "jmx".


Good stuff, thanks for the pointer!

Regards,

Rainer


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



Re: tomcat jmx questions / help

2018-03-28 Thread Rainer Jung

I hope my below answers are all correct, but most should be.

Am 28.03.2018 um 20:25 schrieb Greg Kaszycki:

Tomcat version 7.0.82

I have some questions about tomcat monitoring and jmx.  The short version
is that I am trying to get session information about users logged into my
app.

I see documentation about different ways to get to the jmx beans but I
don't understand the relationship between them.

http://localhost:8080/ takes me to the tomcat homepage and I can click on
the manager button and get to a page with some links to application folders
(I've set my role).  Do they use jmx beans?


No.


I can also do like:  http://localhost:8080/manager/text/sessions?path=/.
and it returns number of sessions.  Is that accessing an mbean?  How does
that name relate to the folders under the tomcat manager folder?


No access to mbeans. No relation to folders. URIs can either point to 
static content, JSPs or to servlets( code) that dynamically enerate the 
responses. Your example points to a servlet, so no relation with 
folders. How does Tomcat know, which URI relates to which servlet? 
That's described in the servlet specification (standards document) and 
one way is declaring servlets and their mapping path in the config file 
WEB-INF/web.xml inside the webapp.



I can also access
http://localhost:8080/manager/jmxproxy/?get=java.lang.type=Memory=HeapMemoryUsage
and get memory usage stats.  Is that accessing an mbean?


Yes. The same web.xml file mapps the URI /jmxproxy underneath the 
manager webapp to the so called JMXProxy servlet. That servlet typically 
produces all it's responses from data retrieved internally from MBeans. 
In the above case you are retrieving the attribute named HeapMemoryUsage 
form an MBean named java.lang.type=Memory (I think it should be: 
java.lang:type=Memory).



I also don't see how these names relates to going to jconsole and looking
at the mbean tab and accessing Catalina/Manager/examples/localhost.  The
names of the attributes in jconsole don't seem to match the names of the
beans that I can access like the memory example above.


They should without your typo. In jconsole you should find a MBean group 
named java.lang and if you open that patr of the MBean tree, you will 
finde the Memory-MBean there. You other path 
"Catalina/Manager/examples/localhost" seems to be totally unrelated (or 
I have not fully understood your question).



I found that memory example above online, but where are these beans
documented?  The documentation in


Some of the MBeans - for example the Memory MBean - are part of any Java 
process, not just Tomcat. So expect them to be documented in generic 
Java docs. Since not only Tomcat, but also applications can create their 
own additional MBean, these basic Java MBeans that always exist are also 
called "platform mbeans". The first hit in a search engine points to


https://docs.oracle.com/javase/7/docs/technotes/guides/management/mxbeans.html

which starts describing how to access mbeans for developers, but in the 
second part of the document also introduces to the data contained in 
some of the platform MBeans. In addition to docs, it is always very 
instructive to simply use a tool like JConsole (or more modern 
JVisualVM) to click through the MBean tree and observe what's there. 
Start with an easy setup, where you run Tomcat and these GUI tools on 
the same machine.


The Tomcat specific MBeans are listen in 
https://tomcat.apache.org/tomcat-9.0-doc/funcspecs/mbean-names.html, but 
I don't know how current that document is. It also gives no hints, what 
data is actually contained in those MBeans. Most of the MBean attributes 
have very descriptive names, so again browsing through the tree helps a bit.



https://tomcat.apache.org/tomcat-7.0-doc/monitoring.html said I could also
access it through a url like:
service:jmx:rmi:///jndi/rmi://localhost:8081/jmxrmi but I could not get
that to work.  Would that access the same bean(s) as the other examples?


I would start interactively with JConsole or JVisualVM to get an idea 
what's there. You can also get a full textual dump with


https://tomcat.apache.org/tomcat-9.0-doc/funcspecs/mbean-names.html?qry=*:*

That command and some more is explained e.g. in 
https://tomcat.apache.org/tomcat-9.0-doc/manager-howto.html


Then you need to decide, via which network protocol you want to access 
MBean data remotely. You could either use an agent deployed as a webapp 
inside Tomcat, speak http(s) to Tomcat and the agent retrieves the data 
internally via JVM and returns a textual representation. The manager 
webapp JMXProxy servlet is one such agent, but it has some deficiencies.


You could also look at Jolokia (Open Source), which provides a more 
powerful other such agent.


Alternatively you can also use JMX as a remote network protocol, but 
that is a bit more subtle to configure and get it secure etc. Your 
mentioned not-working URL fits into this realm. As I said, that's the 
harder way and you 

Re: Thread state differences according to Tomcat 7, 8 version.

2018-03-27 Thread Rainer Jung

See below

Am 27.03.2018 um 07:50 schrieb 이의준:

Hi !

English is not my native language; please excuse typing errors.

Why is Tomcat not handling requests with 8 versions, but in the RUNNABLE
state, not the TIME_WAITING state of the Tomcat 7 version?

Please confirm that this operation works normally.

  


#Tomcat 7.0.75  jdk 1.7.0.65

  


#server.xml

 

 

  


#There are more than 40 threads with the following stacks:

  


"ajp-apr-7009-exec-111" #10247 daemon prio=5 os_prio=0
tid=0x7fa6b811f000 nid=0x2f51 waiting on condition [0x7fa6aa7b8000]

java.lang.Thread.State: TIMED_WAITING (parking)

at sun.misc.Unsafe.park(Native Method)

- parking to wait for  <0x83769178> (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)

at
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)

at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitN
anos(AbstractQueuedSynchronizer.java:2078)

at
java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:467)

at
org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:86)

at
org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:32)

at
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066
)

at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:11
27)

at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:6
17)

at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.ja
va:61)

at java.lang.Thread.run(Thread.java:745)


These are thread idle in the thread pool.


Tomcat 8.0.44 jdk 1.8.0.131

  


#server.xml

 

 

  


There are more than 50 threads with the following stacks:

  


"ajp-apr-7009-exec-1083" #19321 daemon prio=5 os_prio=0
tid=0x7fcd1405d800 nid=0x19fe runnable [0x7fcc373f2000]

java.lang.Thread.State: RUNNABLE

at org.apache.tomcat.jni.Socket.recvbb(Native Method)

at
org.apache.coyote.ajp.AjpAprProcessor.readSocket(AjpAprProcessor.java:256)

at
org.apache.coyote.ajp.AjpAprProcessor.read(AjpAprProcessor.java:197)

at
org.apache.coyote.ajp.AbstractAjpProcessor.readMessage(AbstractAjpProcessor.
java:1091)

at
org.apache.coyote.ajp.AbstractAjpProcessor.process(AbstractAjpProcessor.java
:804)

at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(Abstrac
tProtocol.java:684)

at
org.apache.tomcat.util.net.AprEndpoint$SocketWithOptionsProcessor.run(AprEnd
point.java:2458)

- locked <0xf6bce3a0> (a
org.apache.tomcat.util.net.AprEndpoint$AprSocketWrapper)

at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:11
42)

at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:6
17)

at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.ja
va:61)

at java.lang.Thread.run(Thread.java:748)



These are threads which are busy from the point of view of the thread 
pool, but what they are doing is waiting for more data to arrive on a 
connection they handle.


So the two groups of threads you have chosen are really in a different 
state, not only Tomcat or Java version wise.


Regards,

Rainer

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



Re: mod_jk: sessions connecting although worker is oset to DIS

2018-03-23 Thread Rainer Jung

Am 23.03.2018 um 11:19 schrieb Martin Knoblauch:

Hi Rainer,

  so basically I took the Apache path and ended up with the following brute
force method:

RewriteCond "%{REQUEST_METHOD}" "GET"
RewriteRule ^/xxx/facelets/logon.xhtml$ - [E=login_jsid:%{HTTP_COOKIE}]
CustomLog "/opt/xxx/apache2/logs/login_log" xxxlogheader env=login_jsid
RequestHeader unset Cookie env=login_jsid

GET requests on the login page from the same client/browser now end up on
different nodes.

Looking at JK_STICKY_IGNORE, this seems also to work as well:


RewriteCond "%{REQUEST_METHOD}" "GET"
RewriteRule ^/xxx/facelets/logon.xhtml$ - [E=JK_STICKY_IGNORE]
CustomLog "/opt/xxx/apache2/logs/login_log" xxxlogheader
env=JK_STICKY_IGNORE

I like this actually better, as it does not need to mess with the Cookie.
This is better when components like SiteMinder (for SSO) are involved. I
will give that into our testing/integration environments to see whether we
have any bad side effects.

So thanks again for the valuable input. I will also have a look at the
filter/valve suggestions. But they look more intrusive and getting approval
[did I say big professional organisation somewhere :-)] for that might be
more difficult.


Thanks for the feedback, let us know if you run into surprises :)

As I understand Chris, he plans to backport the tomcat valve so that it 
will be a configurable standard part of all supported Tomcat versions. 
That at least would lower the future cost of getting it used in 
enterprise environments (from code addition down to config addition).


Regards,

Rainer

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



Re: mod_jk: sessions connecting although worker is oset to DIS

2018-03-22 Thread Rainer Jung

Am 22.03.2018 um 15:07 schrieb Rainer Jung:

Am 22.03.2018 um 11:58 schrieb Martin Knoblauch:

Hi,

  we have this annoying problem that although Tomcat workers are set 
to DIS

state in mod_jk, there are new connections being opened. This prevents us
from "idle down" Tomcats in a timely fashion. This hurts when a 
restart is

needed. While our empathy for human clients is pretty limited, we care a
lot about our automated workloads :-)

Our setup: Apache 2.4.x frontend -> mod_jk(1.2.42) balancer, sticky
sessions -> a bunch of Tomcat 7 (yes I know. Oldie but Goldie :-) 
workers.


  As far as I understand, the problem arises with HTTP(S) clients that 
cache
the session cookies. If such a client tries to open a new connection 
to the

backend, the old cookie passes to a DIS worker even if it is no longer
valid on the Tomcat side. Tomcat/Application then sees that the cookie is
not valid and doles out a new cookie which then allows the new connection
to be established.

  My idea is now to delete existing session cookies for certain request
pattern on the Apache frontend. If it works, it should force mod_jk to a
new ACT Tomcat. But I am nor really fond of messing with the Apache
configuration, as the reason lies on the mod_jk/Tomcat side.

  So if anybody has another suggestion I would love to hear it. Before I
forget, changing the application itself is not an option.


Either your idea, or - if those unwanted new request flows start with a 
specific URL, e.g. a login - mark those URLs specifically as not using 
the cookie. If you are using a uriworkermap.properties, look for 
"sticky_ignore" below 
http://tomcat.apache.org/connectors-doc/reference/uriworkermap.html#Rule%20extensions. 
If you are instead using JkMount style maps, look for JK_STICKY_IGNORE 
in 
http://tomcat.apache.org/connectors-doc/reference/apache.html#Advanced%20Environment%20Variables. 



Whenever you set the Apache environment variable JK_STICKY_IGNORE during 
a request execution, mod_jk will ignore the cookie and distribute like 
if it didn't see one. Such environment variables (different from Unix 
environment variables) can be set e.g. with mod_setenvif based on 
request properties and also with mod_rewrite as a [E=] side effect.


But that would only help if you can describe request properties that 
alow you to decide - based on the request alone - whether the cookie 
needs to be ignored or not. You can use any request info including all 
headers for that decision. What is not possible, is to first check, 
whether the session is valid.


You could also write a filter that checks the cookie for validity in 
Tomcat and if it is not valid, reply with a self-referential redirect 
including a Set-Cookie-Header that deletes the cookie. This filter 
should be written, such that it does not itself create a new session.


Plus I vaguely remember Chris (Schultz) has written such code that yould 
be used pretty generic. Chris, am I right? If I am not mistaken, it is 
actually here:


http://home.apache.org/~schultz/lbdf/

Regards,

Rainer

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



Re: mod_jk: sessions connecting although worker is oset to DIS

2018-03-22 Thread Rainer Jung

Am 22.03.2018 um 11:58 schrieb Martin Knoblauch:

Hi,

  we have this annoying problem that although Tomcat workers are set to DIS
state in mod_jk, there are new connections being opened. This prevents us
from "idle down" Tomcats in a timely fashion. This hurts when a restart is
needed. While our empathy for human clients is pretty limited, we care a
lot about our automated workloads :-)

Our setup: Apache 2.4.x frontend -> mod_jk(1.2.42) balancer, sticky
sessions -> a bunch of Tomcat 7 (yes I know. Oldie but Goldie :-) workers.

  As far as I understand, the problem arises with HTTP(S) clients that cache
the session cookies. If such a client tries to open a new connection to the
backend, the old cookie passes to a DIS worker even if it is no longer
valid on the Tomcat side. Tomcat/Application then sees that the cookie is
not valid and doles out a new cookie which then allows the new connection
to be established.

  My idea is now to delete existing session cookies for certain request
pattern on the Apache frontend. If it works, it should force mod_jk to a
new ACT Tomcat. But I am nor really fond of messing with the Apache
configuration, as the reason lies on the mod_jk/Tomcat side.

  So if anybody has another suggestion I would love to hear it. Before I
forget, changing the application itself is not an option.


Either your idea, or - if those unwanted new request flows start with a 
specific URL, e.g. a login - mark those URLs specifically as not using 
the cookie. If you are using a uriworkermap.properties, look for 
"sticky_ignore" below 
http://tomcat.apache.org/connectors-doc/reference/uriworkermap.html#Rule%20extensions. 
If you are instead using JkMount style maps, look for JK_STICKY_IGNORE 
in 
http://tomcat.apache.org/connectors-doc/reference/apache.html#Advanced%20Environment%20Variables.


Whenever you set the Apache environment variable JK_STICKY_IGNORE during 
a request execution, mod_jk will ignore the cookie and distribute like 
if it didn't see one. Such environment variables (different from Unix 
environment variables) can be set e.g. with mod_setenvif based on 
request properties and also with mod_rewrite as a [E=] side effect.


But that would only help if you can describe request properties that 
alow you to decide - based on the request alone - whether the cookie 
needs to be ignored or not. You can use any request info including all 
headers for that decision. What is not possible, is to first check, 
whether the session is valid.


You could also write a filter that checks the cookie for validity in 
Tomcat and if it is not valid, reply with a self-referential redirect 
including a Set-Cookie-Header that deletes the cookie. This filter 
should be written, such that it does not itself create a new session.


HTH,

Rainer



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



Re: Tomcat on Power I

2018-03-19 Thread Rainer Jung

Am 19.03.2018 um 14:24 schrieb Christopher Schultz:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Danny,

On 3/19/18 5:42 AM, Danny Rodius wrote:

has anyone tried tomcat on Power i systems?


Which OS?


Probably the OP means System i, aka iSeries, aka AS/400.


There is at least one guy here who uses Tomcat on AS/400, but I think
he has had better luck with a *NIX OS on the same hardware. I'm not
precisely sure how all that works.

Theoretically, if there is a Java Virtual Machine for the
OS/architecture, then Tomcat should run on it.


Regards,

Rainer

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



Re: Tomcat7 with jre 1.7 error during starting

2018-01-26 Thread Rainer Jung

Am 26.01.2018 um 12:08 schrieb Rajesh Cherukuri:

HI

we have a existing  running tomcat version 5 running on solaris with out
any issues ,  recently we have  installed tomcat 7 on the same solaris 10
server  with no application deployed , and configured java version as
jre1.6 in setenv.sh  i couldn't start the tomcats after my installation ,
and below is the error what i get when i start tomcat with java1.7  later i
tired the to configure the java version as 1.8 , i still get the same error
but slightly different error but both are failing at "

*org.apache.catalina.util.ExtensionValidator.getManifest(ExtensionValidator.java:402)*
 can some one let me know if there are any pre-requisites to run a
tomcat on 7 on Soalris  10 ,


there should be no problem running a recent Tomcat 7 with an unchanged 
Oracle HotSpot Java 6, 7 or 8 on Solaris 10. I regularly do this.


Maybe you unpacked a downloaded tarball using Solaris tar? Solaris tar 
has a very specific way of handling long path names and is not 
compatible with gnu tar. Most tarballs noadays are packed using gnu tar 
and should be unpacked with gnu tar as well. Otherwise files can be 
missing or created with a wrong file name.


gnu tar for Solaris should be installed under /usr/sfw/bin/gtar.

Regards,

Rainer


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



Re: Technology Information Request - Apache Tomcat 7.0

2018-01-23 Thread Rainer Jung

Hi Pradipto,

the question was answered by Mark Thomas just a few days ago in the 
following mail thread:


https://marc.info/?t=15163382301=1=2

Regards,

Rainer

Am 23.01.2018 um 11:39 schrieb Mukherjee,Pradipto:

Hi,

Greetings of the day!

My name is Pradipto Mukherjee from Gartner Inc.

We in Gartner, deliver technology research to global technology business 
leaders to make informed decisions on key initiatives.

As part of our technology research, we maintain an internal library of various 
IT technologies, wherein we maintain vendor lifecycle information for the 
technologies present in the library.

While working on some Apache's technologies, we were unable to verify the 
Lifecycle Support dates of the technology, Apache Tomcat 7.0 .

We were able to find the obsolete dates of version 6.0 and 8.0 from the link 
below and hence, would appreciate if we could get more information on the 
obsolete/end of life date for version 7.0 of Apache Tomcat.

https://tomcat.apache.org/tomcat-80-eol.html
https://tomcat.apache.org/tomcat-60-eol.html


Thanks,
Pradipto Mukherjee
Research Analyst
CEB is now Gartner
6th Floor, Tower 10-B,
DLF Cyber City, Gurgaon 122002, INDIA
Email: pradipto.mukher...@gartner.com
Direct: +91-1244796316
Web: http://gartner.com/ceb




This e-mail message, including any attachments, is for the sole use of the 
person to whom it has been sent, and may contain information that is 
confidential or legally protected. If you are not the intended recipient or 
have received this message in error, you are not authorized to copy, 
distribute, or otherwise use this message or its attachments. Please notify the 
sender immediately by return e-mail and permanently delete this message and any 
attachments. Gartner makes no warranty that this e-mail is error or virus free.



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



Re: StoreConfig default registry misspelling

2018-01-22 Thread Rainer Jung

Am 22.01.2018 um 08:53 schrieb Rémy Maucherat:

On Mon, Jan 22, 2018 at 8:35 AM, d3coder  wrote:


I can't enable StoreConfigLifecycleListener with default settings because
of misspelling in class name in default server-registry.xml
XML line 138 - storeFactoryClass="org.apache.catalina.storeconfig.
OpenSSLConfSF"
storeFactoryClass should be org.apache.catalina.
storeconfig.SSLHostConfigSF
or SSLHostConfigSF class should be renamed to OpenSSLConfSF.



You can probably file a BZ, the class seems to be missing from r1805550. As
a workaround since you're not using OpenSSLConf you should replace that
store factory with the generic
org.apache.catalina.storeconfig.StoreFactoryBase.


Sorry for the inconcenience and thanks for letting us/me know. I forgot 
to commit that class and did it just now in r1821932 for TC 9 and 
r1821935 for TC 8.5. They will be part of 9.0.5 resp. 8.5.28 in about a 
month. The class is small though and should be compatible with a wide 
range of TC 8.5 and 9 versions. If you can compile Tomcat yourself, you 
can add this class to the storeconfig folder:


/**
 * Licensed to the Apache Software Foundation (ASF) under one or more
 * contributor license agreements.  See the NOTICE file distributed with
 * this work for additional information regarding copyright ownership.
 * The ASF licenses this file to You under the Apache License, Version 2.0
 * (the "License"); you may not use this file except in compliance with
 * the License.  You may obtain a copy of the License at
 *
 *  http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

package org.apache.catalina.storeconfig;

import java.io.PrintWriter;

import org.apache.tomcat.util.net.openssl.OpenSSLConf;
import org.apache.tomcat.util.net.openssl.OpenSSLConfCmd;

/**
 * Store OpenSSLConf
 */
public class OpenSSLConfSF extends StoreFactoryBase {

/**
 * Store nested OpenSSLConfCmd elements.
 * {@inheritDoc}
 */
@Override
public void storeChildren(PrintWriter aWriter, int indent, Object 
aOpenSSLConf,

StoreDescription parentDesc) throws Exception {
if (aOpenSSLConf instanceof OpenSSLConf) {
OpenSSLConf openSslConf = (OpenSSLConf) aOpenSSLConf;
// Store nested  elements
OpenSSLConfCmd[] openSSLConfCmds = 
openSslConf.getCommands().toArray(new OpenSSLConfCmd[0]);

storeElementArray(aWriter, indent + 2, openSSLConfCmds);
}
}

}

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

2018-01-18 Thread Rainer Jung

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: GC allocation failure

2018-01-04 Thread Rainer Jung

Am 04.01.2018 um 18:20 schrieb Christopher Schultz:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ambica,

On 1/4/18 11:17 AM, Sanka, Ambica wrote:

I am seeing below highlighted errors in native_err logs in all my
tomcat applications. I also increased memory for the VM from 4GB to
8GB. Still seeing those. When do we get that errors? I am reading
online that when program asks for memory and java cannot give,
that's when we see them. Please suggest. Java HotSpot(TM) 64-Bit
Server VM (25.20-b23) for linux-amd64 JRE (1.8.0_20-b26), built on
Jul 30 2014 13:13:52 by "java_re" with gcc 4.3.0 20080428 (Red Hat
4.3.0-8) Memory: 4k page, physical 8061572k(2564740k free), swap
4063228k(4063228k free)

CommandLine flags: -XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/opt/apache/ancillariesmonitoring/logs/
-XX:InitialHeapSize=128985152 -XX:MaxHeapSize=268435456
-XX:+PrintGC -XX:+PrintGCTimeStamps -XX:+UseCompressedClassPointers
-XX:+UseCompressedOops -XX:+UseParallelGC


Others have commented on those messages you received, but nobody
mentioned your heap configuration. In the above command-line
arguments, you have specified both the minimum and maximum heap
memory. You have expressed those values in bytes which makes it
somewhat hard to read what they actually are, but this is what you


I *think* the JVM top line in GC output always shows bytes, even if you 
were using other units in the original switches.



have in readable units:

- -XX:InitialHeapSize=128M -XX:MaxHeapSize=256M


but yes, that is a valid point!


So you aren't using an 8GiB heap. You aren't even using a 4GiB heap.
You are using a 256 *megabyte* heap. If you really want an 8GiB heap,
you'll need to set it properly in your command-line arguments.

Note that setting the initial heap size to anything other than the
maximum heap size just makes the JVM take longer to get the heap
generations sized appropriately. For a long-running server process, I
think it never makes any sense to set initial < max heap size. Always
set them to the same value so that the heap itself does not have to be
expanded/resized during heap allocations.


Regards,

Rainer


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



Re: GC allocation failure

2018-01-04 Thread Rainer Jung

Hi Ambica,

Am 04.01.2018 um 17:17 schrieb Sanka, Ambica:

I am seeing below highlighted errors in native_err logs in all my tomcat 
applications. I also increased memory for the VM from 4GB to 8GB. Still seeing 
those. When do we get that errors?
I am reading online that when program asks for memory and java cannot give, 
that's when we see them. Please suggest.
Java HotSpot(TM) 64-Bit Server VM (25.20-b23) for linux-amd64 JRE (1.8.0_20-b26), built 
on Jul 30 2014 13:13:52 by "java_re" with gcc 4.3.0 20080428 (Red Hat 4.3.0-8)
Memory: 4k page, physical 8061572k(2564740k free), swap 4063228k(4063228k free)
CommandLine flags: -XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=/opt/apache/ancillariesmonitoring/logs/ 
-XX:InitialHeapSize=128985152 -XX:MaxHeapSize=268435456 -XX:+PrintGC 
-XX:+PrintGCTimeStamps -XX:+UseCompressedClassPointers -XX:+UseCompressedOops 
-XX:+UseParallelGC
3.203: [GC (Allocation Failure)  31744K->6311K(121856K), 0.0097261 secs]
3.578: [GC (Allocation Failure)  38055K->12368K(121856K), 0.0089875 secs]
3.756: [GC (Allocation Failure)  44112K->19589K(121856K), 0.0100339 secs]
3.897: [GC (Allocation Failure)  51333K->25872K(153600K), 0.0092326 secs]
4.172: [GC (Allocation Failure)  89360K->38878K(153600K), 0.0152940 secs]
4.417: [GC (Allocation Failure)  102366K->50311K(148480K), 0.0148816 secs]
4.594: [GC (Allocation Failure)  95367K->49903K(151040K), 0.0197327 secs]
4.765: [GC (Allocation Failure)  94959K->50213K(148992K), 0.0149008 secs]
4.946: [GC (Allocation Failure)  96293K->52257K(150528K), 0.0172634 secs]
5.129: [GC (Allocation Failure)  98337K->53118K(151040K), 0.0139426 secs]
5.313: [GC (Allocation Failure)  102270K->53234K(152064K), 0.0122307 secs]
5.498: [GC (Allocation Failure)  102386K->53579K(153088K), 0.0166336 secs]
5.655: [GC (Allocation Failure)  104779K->54486K(153600K), 0.0161735 secs]
6.885: [GC (Allocation Failure)  105686K->51523K(153600K), 0.0123126 secs]


These messages are normal, as long as there are not other problems or 
errors they are nothing to worry about.


Java manages memory in regions of different sizes and meaning. 
Allocation for new objects is done in the so-called eden space. This 
memory region is managed in a very simple way. The JVM allocates from it 
until it is full (not enough free space left for the current 
allocation). Then it interrupts the application and runs a Garbage 
Collection (GC) for this memory region, copying any objects which are 
still alive from this region into another one (typically into one of the 
two survivor spaces). At the end of the GC run, eden will be fully 
cleared and the application can continue, again allocating from eden.


The above message is shown, whenever a GC run for eden happens. The 
reason for the GC run is shown, here "(Allocation Failure)". The GC for 
eden in your case takes about 10-20 milliseconds and runs about 4-5 
times per second. The string "Failure" is somewhat misleading, the 
failed allocation will be retried and typically succeeds once the GC 
finishes.


Although you can adjust eden size with specific JVM flags, you probably 
have only set the heap size, which is the combined size of several JVM 
memory regions. In that case the JVM will try to auto-tune eden size. If 
you want to set eden size explicitly, you might need to do more 
measurements to deduce good settings from those. That would be a 
somewhat more difficult and not Tomcat specific topic.


Unrelated: note that you JVM 8 patch level 20 is very old.

Regards,

Rainer

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



Re: Is there any way to make a little delay or sequencing of the requests coming to tomcat.

2017-11-01 Thread Rainer Jung

Am 01.11.2017 um 10:53 schrieb Olaf Kock:


On 01.11.2017 06:00, Chaitanya Sabbineni wrote:

I had a application where multiple requests are coming at same time
because of which 1 request is overridden by other.Is so can Any one 
let me

know if there is a way to achieve this.

Tomcat easily handles simultaneous requests - it rather looks like your 
application can't do so. A common cause for this are servlets that keep 
state in member variables.
I'd say, the way to fix it is to debug your application, not 
artificially limit the number of requests that you can accept.


Yes, I should have also said that. You can limit concurrency, but 
concurrency is how you typically achieve performance and is something 
not to prevent, but to make it work instead.


So in this case the semaphore valve is just a dirty workaround, not the 
solution you should aim for.


Regards,

Rainer


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



Re: Is there any way to make a little delay or sequencing of the requests coming to tomcat.

2017-11-01 Thread Rainer Jung

Am 01.11.2017 um 06:00 schrieb Chaitanya Sabbineni:


I had a application where multiple requests are coming at same time
because of which 1 request is overridden by other.Is so can Any one let me
know if there is a way to achieve this.


Maybe this:

https://tomcat.apache.org/tomcat-8.5-doc/config/valve.html#Semaphore_Valve

Regards,

Rainer

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



TLS client auth accepted CA [Was: 2 Way SSL integration with Webservices - Inbound connection not trusted]

2017-08-16 Thread Rainer Jung

Am 16.08.2017 um 09:09 schrieb Jose María Zaragoza:

Hi:

2017-08-16 6:59 GMT+02:00 Vinoth Raja :

Hi Chris,

In the above conversation, the server presents the list of acceptable
client certificates to the client. Does that happen for you?

[ Yes . It prints the list of acceptable certificate when
certificateVerification is set to required. It prints the acceptable
certificates from cacerts.


Sorry for this semi-offtopic ,
but I'm interested about the list of DN of CA sent by TLS server in
SERVER HELLO message.
I mean the list under "Acceptable client certificate CA names" header
(output text in Cris' mail )

How I can set it in Tomcat 8.5 ? Does it works either JSSE & native TLS ?
How is the client behaviour if it doesnt have an certificate signed by
an "acceptable CA" ?


It should work automatically with either JSSE or native TLS 
implementation. It is based on the trust configuration in the 
SSLHostConfig. So when you configure it using the OpenSSL config style, 
it would be the attributes caCertificateFile and/or caCertificatePath, 
using JSSE style config it would be the attributes truststoreFile or 
trustManagerClassName.


I wrote "should", because we found a bug in 8.5 when using JSSE style 
config but OpenSSL implementation. That combination is supported but 
Tomcat would not announce the acceptable CA subjects to the client 
during the handshake. That means, if the client has only one certificate 
to present, it should not be a problem, but if it has multiple 
certificates it is missing the standard way to choose a good one.


The fix for that bug was committed a few days ago to trunk (TC 9), and 
backport to TC 8.5 will happen soon. But the fix needs an additional 
method in the tcnative part, which first has to get released as tcnative 
1.2.13 to make the fix complete. But as I said the bug only shows up 
when mixing JSSE style config with native impl. The other combinations 
should work fine.


As Christopher wrote, you can also check the handshake with "openssl 
s_client" to see what the server announces.


Regards,

Rainer

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



Re: Small question on mod_jk load balancing methon "Next"

2017-08-09 Thread Rainer Jung

Am 09.08.2017 um 11:50 schrieb Martin Knoblauch:

On Fri, Aug 4, 2017 at 11:47 PM, Rainer Jung <rainer.j...@kippdata.de>
wrote:


Hi Martin,

Am 04.08.2017 um 10:53 schrieb Martin Knoblauch:


Hi,

 just need some clarification on the mod_jk load blanacing method "Next".
The documentation states:

"If method is set to N[ext] the balancer will again use the number of
sessions to find the best worker. All remarks concerning the Session
method
apply as well. The difference to the Session method is how the session
count is handled in the sliding time window. The Next method does not
divide by 2, instead it subtracts the current minimum number. This should
effectively result in a round-robin session balancing, thus the name Next.
Under high load, the two session balancing methods will result in a
similar
distribution, but Next will be better if you need to distribute small
numbers of sessions. "

 What exactly is the "current minimum number"? How is the minimum taken?
From all workers in the balancer set, or only the ACTive ones? I know, I
should look it up in the code :-)



I looked up the code I wrote 6 years ago.

First: when using the session base lb methods, mod_jk needs to estimate
session counts. No lb method of mod_jk contacts the backends to get real
data, instead mod_jk uses the request info it sees to estimate the backend
situation.

For session based methods, mod_jk counts requests, that do not include a
session id assuming that those are exactly the ones that create new
sessions. Of course:

a) a session id can be outdated, meaning mod_jk would not count the
request as session creating but in fact it would create a new one. One can
at least configure mod_jk to be aware of login pages which will always
create a new session (see http://tomcat.apache.org/conne
ctors-doc/reference/uriworkermap.html and http://tomcat.apache.org/conne
ctors-doc/reference/apache.html and there look for "sticky_ignore").

b) a request without a session ID might not actually create a session,
depending on app details. There are additional config options to teach
mod_jk which URIs do not create sessions (see
http://tomcat.apache.org/connectors-doc/reference/uriworkermap.html and
http://tomcat.apache.org/connectors-doc/reference/apache.html and there
look for "stateless").

c) sessions time out in backends and users can log out. mod_jk does not
track that. One can remove the session cookie during the logout, so that
the "new" requests from that user will be counted by the mod_jk session
counter.

Because of these problems I typically recommend to stick to the default lb
method (request counting, not session counting). But sometimes apps have
resource usage dominated by sessions and then a "session" based lb method
can help, especially if you find a configuration which keeps the effect of
a)-c) above small.

Since all counting methods, not only session based ones, would count stuff
since the last restart of mod_jk, but the current backend load situation
depends much more on stuff that happened recently, we try to get rid of
past counts by reducing the counters regularly. By default this happens
once per minute and is done in a way that the counters are divided by 2
once per minute. That way old counter increases contribute less and less to
the current counter value. For the session based method this would mean we
assume half of the counted sessions die after one minute, 50% of the rest
during the next minute etc. Note that the counters are integers, so e.g. a
counter value of 1 will after division by 2 result in a new value 0. Most
often that is no problem, because on a loaded system numbers are big and
rounding down doesn't change a lot.

The next request without session id will be send to the worker with the
smallest such "session" counter.

The "Next" message varies that procedure by not dividing by 2 every
minute, but instead subtracting the minimum value of the backend counters.
Assume after the first minute, your 4 backends have "session" counters 2,
3, 3 and 2. Then the minimum is 2, so after the minute we correct the
values to 0, 1, 1 and 0. Then we add for the next minute new sessions to
that counter and again subtract the new minimum etc.

When would that be helpful? It was for an application with really huge
sessions but small session numbers. There was a risk that if for a minute
only 0 or one sessions were created on the backends, after dividing by 2
all workers were again 0.

You can actually track the counters via the status worker, were they are
exposed as column "V" (load balancer value).

Regards,

Rainer



Hi Rainer,

 thanks a lot for the comprehensive write-up. Very useful. Just it does not
answer my question on which workers are considered when determining the
"minimum number" :-) Will all workers be considered, or only those in ACT
state?


Ah, I didn't get that question, beca

Re: Small question on mod_jk load balancing methon "Next"

2017-08-04 Thread Rainer Jung

Hi Martin,

Am 04.08.2017 um 10:53 schrieb Martin Knoblauch:

Hi,

 just need some clarification on the mod_jk load blanacing method "Next".
The documentation states:

"If method is set to N[ext] the balancer will again use the number of
sessions to find the best worker. All remarks concerning the Session method
apply as well. The difference to the Session method is how the session
count is handled in the sliding time window. The Next method does not
divide by 2, instead it subtracts the current minimum number. This should
effectively result in a round-robin session balancing, thus the name Next.
Under high load, the two session balancing methods will result in a similar
distribution, but Next will be better if you need to distribute small
numbers of sessions. "

 What exactly is the "current minimum number"? How is the minimum taken?
From all workers in the balancer set, or only the ACTive ones? I know, I
should look it up in the code :-)


I looked up the code I wrote 6 years ago.

First: when using the session base lb methods, mod_jk needs to estimate 
session counts. No lb method of mod_jk contacts the backends to get real 
data, instead mod_jk uses the request info it sees to estimate the 
backend situation.


For session based methods, mod_jk counts requests, that do not include a 
session id assuming that those are exactly the ones that create new 
sessions. Of course:


a) a session id can be outdated, meaning mod_jk would not count the 
request as session creating but in fact it would create a new one. One 
can at least configure mod_jk to be aware of login pages which will 
always create a new session (see 
http://tomcat.apache.org/connectors-doc/reference/uriworkermap.html and 
http://tomcat.apache.org/connectors-doc/reference/apache.html and there 
look for "sticky_ignore").


b) a request without a session ID might not actually create a session, 
depending on app details. There are additional config options to teach 
mod_jk which URIs do not create sessions (see 
http://tomcat.apache.org/connectors-doc/reference/uriworkermap.html and 
http://tomcat.apache.org/connectors-doc/reference/apache.html and there 
look for "stateless").


c) sessions time out in backends and users can log out. mod_jk does not 
track that. One can remove the session cookie during the logout, so that 
the "new" requests from that user will be counted by the mod_jk session 
counter.


Because of these problems I typically recommend to stick to the default 
lb method (request counting, not session counting). But sometimes apps 
have resource usage dominated by sessions and then a "session" based lb 
method can help, especially if you find a configuration which keeps the 
effect of a)-c) above small.


Since all counting methods, not only session based ones, would count 
stuff since the last restart of mod_jk, but the current backend load 
situation depends much more on stuff that happened recently, we try to 
get rid of past counts by reducing the counters regularly. By default 
this happens once per minute and is done in a way that the counters are 
divided by 2 once per minute. That way old counter increases contribute 
less and less to the current counter value. For the session based method 
this would mean we assume half of the counted sessions die after one 
minute, 50% of the rest during the next minute etc. Note that the 
counters are integers, so e.g. a counter value of 1 will after division 
by 2 result in a new value 0. Most often that is no problem, because on 
a loaded system numbers are big and rounding down doesn't change a lot.


The next request without session id will be send to the worker with the 
smallest such "session" counter.


The "Next" message varies that procedure by not dividing by 2 every 
minute, but instead subtracting the minimum value of the backend 
counters. Assume after the first minute, your 4 backends have "session" 
counters 2, 3, 3 and 2. Then the minimum is 2, so after the minute we 
correct the values to 0, 1, 1 and 0. Then we add for the next minute new 
sessions to that counter and again subtract the new minimum etc.


When would that be helpful? It was for an application with really huge 
sessions but small session numbers. There was a risk that if for a 
minute only 0 or one sessions were created on the backends, after 
dividing by 2 all workers were again 0.


You can actually track the counters via the status worker, were they are 
exposed as column "V" (load balancer value).


Regards,

Rainer

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



Re: Tomcat 9 M22 doesn't stop

2017-07-22 Thread Rainer Jung

Am 22.07.2017 um 22:48 schrieb Mark Eggers:

On 7/22/2017 12:50 AM, Aurélien Terrestris wrote:

Hello,

I'm trying the latest Tomcat (9.0.0.M22) with all the default settings and
applications. When shutting down, it doesn't stop and I'm staying with a
java process which cannot handle any request.
When setting the CATALINA_PID and trying a shutdown -force, it ends in
killing the process.



Here is the catalina.out, with a thread-dump done 20 minutes after the
shutdown :

18-Jul-2017 08:49:50.110 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Server
version:Apache Tomcat/9.0.0.M22
18-Jul-2017 08:49:50.112 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Server
built:  Jun 21 2017 09:44:18 UTC
18-Jul-2017 08:49:50.112 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Server
number: 9.0.0.0
18-Jul-2017 08:49:50.112 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log OS
Name:   Linux
18-Jul-2017 08:49:50.112 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log OS
Version:3.10.0-514.el7.x86_64
18-Jul-2017 08:49:50.112 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log
Architecture:  amd64
18-Jul-2017 08:49:50.113 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Java
Home:
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.131-3.b12.el7_3.x86_64/jre
18-Jul-2017 08:49:50.113 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log JVM
Version:   1.8.0_131-b12
18-Jul-2017 08:49:50.113 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log JVM
Vendor:Oracle Corporation
18-Jul-2017 08:49:50.113 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log
CATALINA_BASE: /home/testusr/cluster/apache-tomcat-9.0.0.M22
18-Jul-2017 08:49:50.113 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log
CATALINA_HOME: /home/testusr/cluster/apache-tomcat-9.0.0.M22
18-Jul-2017 08:49:50.113 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Command line
argument:
-Djava.util.logging.config.file=/home/testusr/cluster/9/conf/logging.properties
18-Jul-2017 08:49:50.113 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Command line
argument: -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
18-Jul-2017 08:49:50.113 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Command line
argument: -Djdk.tls.ephemeralDHKeySize=2048
18-Jul-2017 08:49:50.113 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Command line
argument: -Djava.protocol.handler.pkgs=org.apache.catalina.webresources
18-Jul-2017 08:49:50.113 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Command line
argument: -Dcatalina.base=/home/testusr/cluster/9
18-Jul-2017 08:49:50.114 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Command line
argument: -Dcatalina.home=/home/testusr/cluster/9
18-Jul-2017 08:49:50.114 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Command line
argument: -Djava.io.tmpdir=/home/testusr/cluster/9/temp
18-Jul-2017 08:49:50.114 INFO [main]
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent The APR based
Apache Tomcat Native library which allows optimal performance in production
environments was not found on the java.library.path:
[/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib]
18-Jul-2017 08:49:50.191 INFO [main]
org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler
["http-nio-127.0.0.1-8080"]
18-Jul-2017 08:49:50.210 INFO [main]
org.apache.tomcat.util.net.NioSelectorPool.getSharedSelector Using a shared
selector for servlet write/read
18-Jul-2017 08:49:50.213 INFO [main]
org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler
["ajp-nio-127.0.0.1-8009"]
18-Jul-2017 08:49:50.215 INFO [main]
org.apache.tomcat.util.net.NioSelectorPool.getSharedSelector Using a shared
selector for servlet write/read
18-Jul-2017 08:49:50.218 INFO [main]
org.apache.catalina.startup.Catalina.load Initialization processed in 495 ms
18-Jul-2017 08:49:50.239 INFO [main]
org.apache.catalina.core.StandardService.startInternal Starting service
[Catalina]
18-Jul-2017 08:49:50.239 INFO [main]
org.apache.catalina.core.StandardEngine.startInternal Starting Servlet
Engine: Apache Tomcat/9.0.0.M22
18-Jul-2017 08:49:50.248 INFO [main]
org.apache.catalina.startup.HostConfig.deployDirectory Deploying web
application directory
[/home/testusr/cluster/apache-tomcat-9.0.0.M22/webapps/ROOT]
18-Jul-2017 08:52:23.690 WARNING [main]
org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom Creation
of SecureRandom instance for session ID generation using [SHA1PRNG] took
[153,172] milliseconds.
18-Jul-2017 08:52:23.705 INFO [main]
org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web
application directory
[/home/testusr/cluster/apache-tomcat-9.0.0.M22/webapps/ROOT] 

Re: TLS handshake performance

2017-05-18 Thread Rainer Jung

Am 18.05.2017 um 16:03 schrieb john.e.gr...@wellsfargo.com.INVALID:

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org]
Sent: Thursday, May 18, 2017 8:47 AM
To: users@tomcat.apache.org
Subject: Re: TLS handshake performance

This time to the right list...

On 18/05/2017 06:04, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 5/17/17 5:31 PM, Mark Thomas wrote:

I got asked in the corridor at TomcatCon earlier today what the
relative performance of the TLS handshake was with 8.5.x, the NIO
connector and JSSE vs OpenSSL TLS implementation.

I'm curious about what exactly "TLS handshake" was intended to mean
(by the person who asked the question) in this context.


They are using Tomcat in a scenario where clients are making single requests
(so keep alve doesn't help). Given that the handshake uses asymmetric
encryption which is more expensive that symmetric encryption (which is why
the handshake is used to establish a shared secret so symmetric encryption
can used for the actual data) they wanted a sense of the performance
benefit - if any - of NIO and 8.5.x with OpenSSL vs NIO and 8.5.x with JSSE.


The handshake itself does not perform any bulk transfer of encrypted
data, so the negotiated cipher suite does not matter. However...


Tested with: ab -n 1000 -c 2 -f TLS1.2 -Z
ECDHE-RSA-AES128-GCM-SHA256 https://localhost:8443/test.txt


Here the cipher suite matters very much, since the client is not only
performing the TLS handshake but also transferring the client's
request to the server and the server's response back to the client. >
Support for a particular algorithm may dominate the benchmark, here.


Agreed. But it is the handshake that dominates the timings (if you add -k to
use keep-alive the req/sec are an order of magnitude higher).

The cipher suite was the default one chosen by by one of the configs (I
forget which).

The cipher suite will affect the results since it also impacts the enctrpyion
used during the handshake but for any 'reaosnably' secure cipher suite, I'd
expect similar results in terms of the relative performance.




What about SSL session reuse?  Did you have any way of disabling that?  If 
you're testing against a single server, you'll get 100% reuse, which makes a 
big difference in the CPU load (lower) on the server.  If your real world case 
involves dozens or hundreds of servers behind a load balancer, you get almost 
no reuse.


Session reuse does not work magically. The client and the server have to 
support it, being it using a session cache and IDs or using TLS session 
tickets.


I am pretty sure, that "ab", the client used during these tests, does 
not support TLS session reuse.


Regards,

Rainer

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



Re: [ANN] New committer: Michael Osipov

2017-05-08 Thread Rainer Jung

Am 08.05.2017 um 10:08 schrieb Mark Thomas:

On behalf of the Tomcat committers I am pleased to announce that
Michael Osipov (michaelo) has been voted in as a new Tomcat committer.

Please join me in welcoming him.


Congrats and welcome!

Rainer

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



Re: tuning to accommodate Apache 2.4 event mpm

2017-04-28 Thread Rainer Jung

Am 27.04.2017 um 22:21 schrieb Mark Thomas:

On 27/04/17 20:08, John Cartwright - NOAA Federal wrote:

Thanks for your reply Mark!  My sysadmin tells me just that we're
using "the defaults" for event_mpm.  However we are still using the
BIO AJP connector:



Is there a way I can tell from the Tomcat side when there is thread starvation?


You'd need to look at the number of active connections. If it gets to
300 then you likely have a problem.

netstat might be the least invasive way of doing that. Other options
include the Manager app, JMX and thread dumps.

Switching to NIO will allow you to server more connections with the same
number of threads.


I assume you are using the latest mod_jk version?

The current version of mod_jk also counts the total connection number 
(sum of connections from all Apache child processes to your Tomcat) and 
makes it available via the status worker for monitoring. The counting 
was a bit buggy in older versions, but should be correct in the latest one.


Event MPM and mod_jk: the relevant phase in Apache is the handler phase, 
where the actual request forwarding is done by mod_jk. Things do not 
really need to change in the handler phase for proxying modules with 
event MPM. mod_jk does not need to know about the MPM or behave 
specific, the forwarding runs synchronously. By default mod_jk uses as 
many connections per Apache process as you have worker threads per 
Apache process configured. On the Tomcat side with BIO you need as many 
threads for the AJP connector as all you Apache fronting that Tomcat 
might have threads in total. Using the NIO connector on the Tomcat side 
is indeed better than BIO especially when you expect lots of concurrency 
(many Apache threads configured). Make sure you also use a recent Tomcat 
patch level then.


What messages did you get in your mod_jk error log?

For the mod_jk config, a good starter is the config files we bundle with 
the source download of mod_jk. You can also find them under


http://svn.apache.org/viewvc/tomcat/jk/trunk/conf/

These files set timeouts etc.

Regards,

Rainer

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



Re: rotate catalina.out

2017-04-13 Thread Rainer Jung

Am 13.04.2017 um 14:57 schrieb shivashankar manukondu:

Is there any possibility loss the log information in case if we use any
external tools like Log4j, logrotete


I suggest you make the adjustment to your conf/logging.properties that I 
mentioned. You should also make sure, that no application log 
configuration uses a stdout, console etc. appender. As a result, your 
catalina.out will no longer receive log messages, only if a developer 
decided to directly write to STDOUT instead of using a log framework.


Log4j is no external tool. logrotate and similar are and yes, depending 
on details there is sometimes a risk of using log information due to 
external rotation.


Regards,

Rainer


On Wed, Apr 12, 2017 at 4:32 PM, Rainer Jung <rainer.j...@kippdata.de>
wrote:


Am 12.04.2017 um 16:15 schrieb Mark Thomas:


On 12/04/17 14:13, shivashankar manukondu wrote:


Hi,

Do we have any default catalina.out
<https://wiki.apache.org/tomcat/FAQ/Logging#Q10> rotation in the tomcat8
without using any external tool like Log4J or logrotate.



No. But since catalina.out is only what is written to stdout is should
be mostly (ideally entirely) empty.



Aren't we currently still copying everything to STDOUT by default?

In logging.properties:

.handlers = 1catalina.org.apache.juli.AsyncFileHandler,
java.util.logging.ConsoleHandler

So once people switch this to production style config

.handlers = 1catalina.org.apache.juli.AsyncFileHandler

your statement would apply.

Regards,

Rainer


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



Re: rotate catalina.out

2017-04-12 Thread Rainer Jung

Am 12.04.2017 um 16:15 schrieb Mark Thomas:

On 12/04/17 14:13, shivashankar manukondu wrote:

Hi,

Do we have any default catalina.out
 rotation in the tomcat8
without using any external tool like Log4J or logrotate.


No. But since catalina.out is only what is written to stdout is should
be mostly (ideally entirely) empty.


Aren't we currently still copying everything to STDOUT by default?

In logging.properties:

.handlers = 1catalina.org.apache.juli.AsyncFileHandler, 
java.util.logging.ConsoleHandler


So once people switch this to production style config

.handlers = 1catalina.org.apache.juli.AsyncFileHandler

your statement would apply.

Regards,

Rainer

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



Re: [ANN] New committer: Emmanuel Bourg

2017-01-20 Thread Rainer Jung

Am 20.01.2017 um 18:12 schrieb Mark Thomas:

On behalf of the Tomcat committers I am pleased to announce that
Emmanuel Bourg (ebourg) has been voted in as a new Tomcat committer.

Please join me in welcoming him.


Congratulations and welcome!

Rainer

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



Re: Maintaining Session with Apache RewriteRule

2016-12-24 Thread Rainer Jung

Am 24.12.2016 um 19:58 schrieb Jerry Malcolm:

Mark,

Thanks, but what can I do to correct it?



On 12/24/2016 11:09 AM, Mark Thomas wrote:

On 24/12/2016 16:08, Jerry Malcolm wrote:

I have an app that runs in a single WAR file deployment (single webapp
context).  I added some Apache RewriteRule statements to hide the actual
URLs for pages in the webapp.  All of the rules still resolve to the
single WAR file context.  But the problem is now I get a different
session on each page.  I need to pass a session variable from page to
page.  Everything worked with a single session until I moved to the
RewriteRule statements.  Am I missing some flag in the RewriteRule or a
Tomcat config option that will allow me to keep one session even with
RewriteRules in effect?

Here's one of the Apache statements:

  RewriteRule ^/precheckout$
/order/jsp/user/termsandconditions.jsp[PT]

What am I missing?

You are missing that the session cookie has a path and your rewrite
rules are changing the path and therefore preventing the client from
returning cookie.


http://httpd.apache.org/docs/2.4/en/mod/mod_proxy.html#proxypassreversecookiepath

Regards,

Rainer


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



Re: Reset a single mod_jk worker counter

2016-12-05 Thread Rainer Jung

Hi Chris,

Am 05.12.2016 um 22:25 schrieb Christopher Schultz:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

Ping. I'd really like to be able to do this. Is it currently possible?

When locating this message to reply to it, I found essentially the
same message posted by me back in May. :)

Thanks,
- -chris

On 11/21/16 9:24 AM, Christopher Schultz wrote:

All,

When using the mod_jk status worker in read-write mode, you can
edit a worker (or sub-worker for an lb worker) and adjust certain
settings like the timeouts, lbfactor, etc. You can also reset the
stats on the worker back to zero.

I'm interested in resetting the "errors" stat but not the remaining
stat s.

Is that possible?


No, not currently. Since long term stats IMHO mostly make sense when 
grabbing them regularly via some monitoring, what's bad about resetting 
the other stats as well, so that at least all numbers give a consistent 
view?


Regards,

Rainer


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



Re: log4j2 configuration in Tomcat 8.5.8

2016-12-05 Thread Rainer Jung

Am 05.12.2016 um 08:32 schrieb frank.pien...@materna.de:

It's a little bit frustrating to configure Tomcat 8.5.8 with log4j2.
I put the following jars in $CATALINA_HOME/lib
log4j 2 core (log4j-core-2.6.2.jar)
log4j 2 api (log4j-api-2.6.2.jar)
Delete the file $CATALINA_HOME/conf/logging.properties
Put the new log4j 2 config file (log4j2.xml) in $CATALINA_HOME/lib



 



  
%d %p %c{1.} [%t] %m%n
  


  
   

  

  
 

  

No errors but the created catalina.out file is empty and the console layout 
doesn't change
What else to check or change?
THX Frank


Currently you need to put three log4j2 jar files into the CLASSPATH (not 
the lib directory):


- core
- api
- jul bridge

Next put your log4j2.xml in some special directory and add that 
directory to the CLASSPATH as well.


Since in 8.5 Log4J integration is via its jul bridge it must be loadable 
by jul, that's why CLASSPATH and not just the lib directory.


Finally add the following system property to inform jul that it should 
log via log4j2:


-Djava.util.logging.manager=org.apache.logging.log4j.jul.LogManager

for instance by setting LOGGING_MANAGER to that value. To reduce 
confusion I suggest to also set LOGGING_CONFIG to some dummy value, e.g. 
-Dnop.


See:

http://logging.apache.org/log4j/2.x/log4j-jul/index.html

There is a (minor) flaw currently in this integration: the location info 
(class name, method name, line number) will be wrong and always point to 
a fixed position in Tomcat Juli instead of the "real" class calling the 
log method.


For more details about this problem see also:

http://marc.info/?t=14774015512=1=2

Regards,

Rainer

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



Re: Load balancing problem with activation=disabled

2016-10-18 Thread Rainer Jung



Am 18.10.2016 um 10:10 schrieb Kozak, Milos:

Hi,

I am debugging a mod_jk load-balancing configuration which has been used a lot, 
but for two nodes only. Currently, we made a change for more nodes, and we are 
facing problem.

Original idea was to have one PROD and DR servers such that all requests are 
handled by PROD and if PROD goes down DR takes over. In order to do that we 
used activation=disabled for DR worker, such that:


worker.list=jkstatus,lbhierarchy
worker.jkstatus.type=status
worker.lbhierarchy.type=lb
worker.lbhierarchy.balance_workers=hierarchy-1,hierarchy-2

worker.hierarchy-1.type=ajp13
worker.hierarchy-1.host=host1
worker.hierarchy-1.port=8009
worker.hierarchy-1.socket_timeout=0
worker.hierarchy-1.socket_keepalive=False
worker.hierarchy-1.retries=2
worker.hierarchy-1.connection_pool_timeout=0
worker.hierarchy-1.lbfactor=1
worker.hierarchy-1.redirect=hierarchy-2

worker.hierarchy-2.type=ajp13
worker.hierarchy-2.host=host2
worker.hierarchy-2.port=8009
worker.hierarchy-2.socket_timeout=0
worker.hierarchy-2.socket_keepalive=False
worker.hierarchy-2.retries=2
worker.hierarchy-2.connection_pool_timeout=0
worker.hierarchy-2.lbfactor=1
worker.hierarchy-2.activation=disabled


However, the current demand is to have four servers which are chained. 
Basically, we try to have one PROD and 3 DR servers. Each DR is activated when 
the previous worker goes down. Therefore, we prepared configuration like this:



worker.list=jkstatus,lbhierarchy,lb2hierarchy
worker.jkstatus.type=status
worker.lbhierarchy.type=lb
worker.lbhierarchy.balance_workers=hierarchy-1,hierarchy-2,hierarchy-3,hierarchy-4

worker.hierarchy-1.type=ajp13
worker.hierarchy-1.host=host
worker.hierarchy-1.port=8009
worker.hierarchy-1.socket_timeout=0
worker.hierarchy-1.socket_keepalive=False
worker.hierarchy-1.retries=2
worker.hierarchy-1.connection_pool_timeout=0
worker.hierarchy-1.lbfactor=1
worker.hierarchy-1.redirect=hierarchy-2

worker.hierarchy-2.type=ajp13
worker.hierarchy-2.host=host
worker.hierarchy-2.port=8010
worker.hierarchy-2.socket_timeout=0
worker.hierarchy-2.socket_keepalive=False
worker.hierarchy-2.retries=2
worker.hierarchy-2.connection_pool_timeout=0
worker.hierarchy-2.lbfactor=1
worker.hierarchy-2.activation=disabled
worker.hierarchy-2.redirect=hierarchy-3

worker.hierarchy-3.type=ajp13
worker.hierarchy-3.host=host
worker.hierarchy-3.port=8011
worker.hierarchy-3.socket_timeout=0
worker.hierarchy-3.socket_keepalive=False
worker.hierarchy-3.retries=2
worker.hierarchy-3.connection_pool_timeout=0
worker.hierarchy-3.lbfactor=1
worker.hierarchy-3.activation=disabled
worker.hierarchy-3.redirect=hierarchy-4

worker.hierarchy-4.type=ajp13
worker.hierarchy-4.host=host12
worker.hierarchy-4.port=10603
worker.hierarchy-4.socket_timeout=0
worker.hierarchy-4.socket_keepalive=False
worker.hierarchy-4.retries=2
worker.hierarchy-4.connection_pool_timeout=0
worker.hierarchy-4.lbfactor=1
worker.hierarchy-4.activation=disabled
worker.hierarchy-4.redirect=hierarchy-1

Initially, 3 servers are disabled and redirect is specified.

Problem occurs when hierarchy-3 worker goes down because hierarchy-4 never gets 
initiated and mod_jk log says that:
All tomcat instances failed, no more workers left

However, workers list is like this:
worker.lbhierarchy.balance_workers=hierarchy-1,hierarchy-2,hierarchy-3,hierarchy-4

Which means we have got more than 3 workers hence we have more workers left... 
Here is log where I tried to take down workers one by one:

[Tue Oct 18 09:51:30.623 2016] [31890:139909801125856] [info] 
ajp_service::jk_ajp_common.c (2773): (hierarchy-1) sending request to tomcat 
failed (recoverable), because of error during request sending (attempt=1)
[Tue Oct 18 09:51:30.724 2016] [31890:139909801125856] [info] 
jk_open_socket::jk_connect.c (817): connect to HOST:8009 failed (errno=111)
[Tue Oct 18 09:51:30.724 2016] [31890:139909801125856] [info] 
ajp_connect_to_endpoint::jk_ajp_common.c (1068): (hierarchy-1) Failed opening 
socket to (HOST:8009) (errno=111)
[Tue Oct 18 09:51:30.724 2016] [31890:139909801125856] [error] 
ajp_send_request::jk_ajp_common.c (1728): (hierarchy-1) connecting to backend 
failed. Tomcat is probably not started or is listening on the wrong port 
(errno=111)
[Tue Oct 18 09:51:30.724 2016] [31890:139909801125856] [info] 
ajp_service::jk_ajp_common.c (2773): (hierarchy-1) sending request to tomcat 
failed (recoverable), because of error during request sending (attempt=2)
[Tue Oct 18 09:51:30.724 2016] [31890:139909801125856] [error] 
ajp_service::jk_ajp_common.c (2794): (hierarchy-1) connecting to tomcat failed 
(rc=-3, errors=5, client_errors=0).
[Tue Oct 18 09:51:30.724 2016] [31890:139909801125856] [info] 
service::jk_lb_worker.c (1595): service failed, worker hierarchy-1 is in error 
state
[Tue Oct 18 09:51:30.724 2016] [31890:139909801125856] [info] 
jk_open_socket::jk_connect.c (817): connect to HOST:8010 failed (errno=111)
[Tue Oct 18 09:51:30.724 2016] [31890:139909801125856] [info] 

Re: Tomcat 8, AJP 1.3 UTF-8/ISO-8859-1 conversion problem

2016-10-17 Thread Rainer Jung

Am 17.10.2016 um 22:38 schrieb Mark Juszczec:

On Mon, Oct 17, 2016 at 8:20 AM, Rainer Jung <rainer.j...@kippdata.de>
wrote:


Am 17.10.2016 um 12:35 schrieb Mark Juszczec:


On Mon, Oct 17, 2016 at 4:29 AM, Mark Thomas <ma...@apache.org> wrote:



A small hint. I'd expect those to be % encoded.



Thank you very much for your reply.

I've been thinking the problem is lack of % encoding after reading:

*"Default encoding for GET*
The character set for HTTP query strings (that's the technical term for
'GET parameters') can be found in sections 2 and 2.1 the "URI Syntax"
specification. The character set is defined to be US-ASCII
<http://en.wikipedia.org/wiki/ASCII>. Any character that does not map to
US-ASCII must be encoded in some way. Section 2.1 of the URI Syntax
specification says that characters outside of US-ASCII must be encoded
using
 % escape sequences: each character is encoded as a literal % followed by
the two hexadecimal codes which indicate its character code. Thus, a
(US-ASCII
character code 97 = 0x61) is equivalent to %61. There *is no default
encoding for URIs* specified anywhere, which is why there is a lot of
confusion when it comes to decoding these values. "

from http://wiki.apache.org/tomcat/FAQ/CharacterEncoding#Q8

Do you know if there's a way to force something (mod_jk, mod_rewrite or
something else) to % encode the data being fed into the AJP port?



You can force nod_jk to %-encode the URI before forwarding:

JkOptions +ForwardURIEscaped



I've tried adding +ForwardURIEscaped in my conf file as follows:

# JkOptions indicate to send SSL KEY SIZE,
JkOptions +ForwardKeySize +ForwardURIEscaped -ForwardDirectories

I would have expected mod_jk log to show the data % encoded, but it does
not:

text: J O Ë ‹ L
hex: 0x4a 0x4f 0xc3 0x8b 0x4c

I had expected to see something like:

JO%C3%8BL

Is that reasonable?  Does it make sense?


Yes.


Could something be turning off the encoding?  Do the headers values need to
be set to something specific?


Did you put the directive into the correct VirtualHost?

Regards,

Rainer

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



Re: Apache mod_jk connector question about alias

2016-10-17 Thread Rainer Jung

Am 17.10.2016 um 19:16 schrieb Marc Chamberlin:

Hello -  My apologies if this has already been asked or the wrong mail
list, but Google is not coming up with an answer for me, so here goes...

I am trying to set up the mod_jk connector between an Apache HTTPD
server and Tomcat with the intent of supporting virtual hosts, and
serving static content from the Apache server and forwarding jsp and
servlet requests to Tomcat. Typical scenario I know...

Most of this I have working but the trouble I am having is with the use
an Alias directive for the Apache server. Following instructions for the
JSP examples that came with my distribution for Tomcat 8, I created a
configuration for


 

  # The following line makes apache aware of the location of
  # the /jsp-examples context
  Alias /jsp-examples "/srv/tomcat/webapps/examples/jsp"

  
Options Indexes  FollowSymLinks
AllowOverride None
# Controls who can get stuff from this server.

Require all granted


Order allow,deny
Allow from all

  

  # Mounted stuff goes via tomcat (ajp13)
  JkMount /jsp-examples tomcatWorker1
  JkMount /jsp-examples/* tomcatWorker1
  # Serve html, css, js, jpg, png and gif using Apache
  JkUnMount /*.html tomcatWorker1
  JkUnMount /*.css tomcatWorker1
  JkUnMount /*.js tomcatWorker1
  JkUnMount /*.jpg  tomcatWorker1
  JkUnMount /*.png  tomcatWorker1
  JkUnMount /*.gif  tomcatWorker1



I am actually defining this in the context of a virtual host and if
necessary I can post its configuration as well.

Using the JK debug level and monitoring the mod_jk.log file I can see
what is going wrong, I just don't know how to rectify it -


[Mon Oct 17 09:28:01.145 2016] [30237:139868423546816] [debug]
ajp_connection_tcp_send_message::jk_ajp_common.c (1208): sending to
ajp13 pos=4 len=469 max=8192
[Mon Oct 17 09:28:01.145 2016] [30237:139868423546816] [debug]
ajp_connection_tcp_send_message::jk_ajp_common.c (1208):  12 34 01
D1 02 02 00 08 48 54 54 50 2F 31 2E 31  - .4..HTTP/1.1
[Mon Oct 17 09:28:01.145 2016] [30237:139868423546816] [debug]
ajp_connection_tcp_send_message::jk_ajp_common.c (1208): 0010 00 00 0E
2F 6A 73 70 2D 65 78 61 6D 70 6C 65 73  - .../jsp-examples
[Mon Oct 17 09:28:01.145 2016] [30237:139868423546816] [debug]
ajp_connection_tcp_send_message::jk_ajp_common.c (1208): 0020 2F 00 00
0D 31 39 32 2E 31 36 38 2E 31 30 2E 31  - /...192.168.10.1


This excerpt shows that the Apache server is sending a message to the
Tomcat worker telling it to find a resource "/jsp-examples" which of
course doesn't really exist and so Tomcat reports a "Not Found" failure.
What I want is for the Apache server to send the actual location that
this alias is mapped to i.e. "/examples/jsp", which is what actually
exists in the Tomcat context. I can fool Tomcat into handling this alias
request by creating a link named jsp-examples -> examples/jsp within the
Tomcat webapps directory but that seems like a hack and not something I
want to have to do/maintain for all the other resources I will want to
handle via alias commands.

Is there a magic incantation that I am missing?  Thanks in advance for
suggestions/help Marc...


Alias maps URIs to local file system directories.
JkMount maps URIs to remote back end requests.

You can not change JkMount forwarding using Alias (except that if you 
have a comflict between Alias and JkMount only one of them wins).


As far as I understand you are not really trying to map requests to the 
local web server file system, but instead want to forward to a Tomcat 
back end but change the URI path which is used when accessing Apache to 
something else being used to acces Tomcat. E.g. the URI 
/jsp-examples/something gets used when accessing Apache and mod_jk 
should send this request as /examples/jsp/something to the Tomcat back end.


If you really need to change URIs, then often mod_proxy is much easier 
to set up, because it has specific directives for this (ProxyPass etc.).


With mod_jk you would first need to use mod_rewrite RewriteRules to 
change the URI, and then JkMount to forward them. More details can be 
found at


http://tomcat.apache.org/connectors-doc/common_howto/proxy.html#URL%20Rewriting

The rest of this docs page might be useful as well.

Regards,

Rainer

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



Re: Tomcat 8, AJP 1.3 UTF-8/ISO-8859-1 conversion problem

2016-10-17 Thread Rainer Jung

Am 17.10.2016 um 12:35 schrieb Mark Juszczec:

On Mon, Oct 17, 2016 at 4:29 AM, Mark Thomas  wrote:


On 17/10/2016 08:30, Mark Thomas wrote:

On 16/10/2016 19:09, Mark Juszczec wrote:

Hello

I have Tomcat 8.0.28 running on CentOS Linux 7.2.1511 behind Apache

2.4.6


I'm using AJP 1.3 for communication between Apache and Tomcat

Its all powered by Java 1.8

I'm having a problem with international characters when I send them as

the

request *URI* (which is used by GET requests and this is a GET request).

Let's say I get the string AOËL

mod_jk log  logs the bytes with the message

 "ajp_connection_tcp_send_message::jk_ajp_common.c (1208): sending to

ajp13

pos=4 len=1411 max=8192" (at
ajp_connection_tcp_send_message::jk_ajp_common.c) shows them to be:

  41 4f c3 8b 4c

AFAIK this means the correct bytes are being sent to AJP.  Is that

correct?


That is the correct UTF-8 byte encoding for the characters AOËL.


A small hint. I'd expect those to be % encoded.



Thank you very much for your reply.

I've been thinking the problem is lack of % encoding after reading:

*"Default encoding for GET*
The character set for HTTP query strings (that's the technical term for
'GET parameters') can be found in sections 2 and 2.1 the "URI Syntax"
specification. The character set is defined to be US-ASCII
. Any character that does not map to
US-ASCII must be encoded in some way. Section 2.1 of the URI Syntax
specification says that characters outside of US-ASCII must be encoded using
 % escape sequences: each character is encoded as a literal % followed by
the two hexadecimal codes which indicate its character code. Thus, a (US-ASCII
character code 97 = 0x61) is equivalent to %61. There *is no default
encoding for URIs* specified anywhere, which is why there is a lot of
confusion when it comes to decoding these values. "

from http://wiki.apache.org/tomcat/FAQ/CharacterEncoding#Q8

Do you know if there's a way to force something (mod_jk, mod_rewrite or
something else) to % encode the data being fed into the AJP port?


You can force nod_jk to %-encode the URI before forwarding:

JkOptions +ForwardURIEscaped

(see http://tomcat.apache.org/connectors-doc/webserver_howto/apache.html)

You might need to experiment whether that really fixes your issues, e.g. 
when parts of the URI are already %-encoded etc.


Regards,

Rainer

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



Re: [OT] ECDHE cipher suites missing on Amazon Linux / OpenJDK 7 and 8 ??

2016-10-06 Thread Rainer Jung

Am 06.10.2016 um 00:18 schrieb Christopher Schultz:

On 10/5/16 6:13 PM, Christopher Schultz wrote:

On 10/5/16 4:52 PM, Rainer Jung wrote:

Am 05.10.2016 um 21:11 schrieb Christopher Schultz:

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256

All,

Apologies for off-topic post, but lots of folks here have lots
of different experiences and maybe someone has come across
this.

I've got a few servers in Amazon EC2 running Amazon Linux. I'm
using the OpenJDK package, and I have versions 1.7.0 and 1.8.0
running side-by-side:

$ java -version java version "1.7.0_111" OpenJDK Runtime
Environment (amzn-2.6.7.2.68.amzn1-i386 u111-b01) OpenJDK
Client VM (build 24.111-b01, mixed mode, sharing)

$ java8 -version openjdk version "1.8.0_101" OpenJDK Runtime
Environment (build 1.8.0_101-b13) OpenJDK Server VM (build
25.101-b13, mixed mode)

For some reason, a whole slew of crypto support is flat-out
/missing/ from those packages (java-1.7.0-openjdk and
java-1.8.0-openjdk). Here's what I get when I run my SSLInfo
tool on the box:

...

If I run this on another box where Oracle's Java has been
installed, I get the full compliment:

...

The security policy has these algorithms disabled:

jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize
< 768

I'm okay with all those.

I've installed the "Java Unlimited Strength Policy Files"
which may or may not have been necessary (in general) but that
doesn't enable the ECDH/ECDHE cipher suites, anyway.

The only promising suggestion I've read online is to install
the Bouncy Castle crypto provider, except that provider is 100%
Java and I'd prefer to get (what little) acceleration the
native implementation can provide.

Do I need to abandon OpenJDK in order to get a decent
selection of cipher suites? Or is there a package I have not
installed, or a setting I haven't tweaked somewhere to get this
working?



Coincidentally I an currently involved in a project which forced
 customers to download EC support for OpenJDK as a separate
package due to license limitations. EC support in Oracle JDK is
provided by the Sun EC provider which consists of a jar file
sunec.jar plus (and therein lies the real impl) a native library
(libsunec.so on Unix/Linux). These files seem to have been
removed from OpenJDK due to license restrictions or policies.


I'm in such luck that you are fighting this battle as well!

In my install of Java 8, I do in fact have sunec.jar: -rw-r--r-- 1
root root   30460 Jul 20 22:30 sunec.jar

The Java 7 package does not contain sunec.jar.

Of the 38 shared libs in Java 8 and the 41 libs for Java 7, none
of them have "sun" anywhere in their name. So it looks like the
native components are not available, at least not form the packages
I've installed thus far.


I found two texts related to this:



http://armoredbarista.blogspot.de/2013/10/how-to-use-ecc-with-openjdk

.





html



and



https://bugzilla.redhat.com/show_bug.cgi?id=1167153



I do not know, whether AWS really does not include the Sun EC
jar file and/or library (then your observation would be explained
by this) or whether the root cause on AWS is something else.


I had the thought to simply steal the libsunec.so from my Oracle
Java 8 on another system to see if it would work. But for reasons
that are beyond my explanation the server in question is a
32-bit OS with a 32-bit JVM on it, and I don't have another machine
with that library handy. I'll have to get crafty.


I have another AWS server that *is* 64-bit and I was able to
successfully steal the .so from another Linux x86-64 server which had
an Oracle JDK installed. It seems to work, but I'd prefer something
that wasn't so obviously hacky. I might even be violating some kind of
license agreement or something. Lawyers: I was just testing this for
entertainment purposes, and have definitely rolled-back to a compliant
configuration.


Looking around I found the official license. On the official Oracle Java 
download site


   http://www.oracle.com/technetwork/java/javase/downloads/index.html

there is a link "Third Party Licenses". It gets you to a page with one 
link per Major Java version. For 7 and 8 it contains the info, that 
libsunec.so is licensed under the LGPL license.


Regards,

Rainer

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



Re: [OT] ECDHE cipher suites missing on Amazon Linux / OpenJDK 7 and 8 ??

2016-10-05 Thread Rainer Jung

Am 05.10.2016 um 21:11 schrieb Christopher Schultz:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

Apologies for off-topic post, but lots of folks here have lots of
different experiences and maybe someone has come across this.

I've got a few servers in Amazon EC2 running Amazon Linux. I'm using
the OpenJDK package, and I have versions 1.7.0 and 1.8.0 running
side-by-side:

$ java -version
java version "1.7.0_111"
OpenJDK Runtime Environment (amzn-2.6.7.2.68.amzn1-i386 u111-b01)
OpenJDK Client VM (build 24.111-b01, mixed mode, sharing)

$ java8 -version
openjdk version "1.8.0_101"
OpenJDK Runtime Environment (build 1.8.0_101-b13)
OpenJDK Server VM (build 25.101-b13, mixed mode)

For some reason, a whole slew of crypto support is flat-out /missing/
from those packages (java-1.7.0-openjdk and java-1.8.0-openjdk).
Here's what I get when I run my SSLInfo tool on the box:

$ java -showversion -classpath libs/chadis-tools-1.55.jar
com.chadis.tools.security.SSLInfo
java version "1.7.0_111"
OpenJDK Runtime Environment (amzn-2.6.7.2.68.amzn1-i386 u111-b01)
OpenJDK Client VM (build 24.111-b01, mixed mode, sharing)

Supported SSL Protocols:
  TLSv1 (SunJSSE)
  TLSv1.1 (SunJSSE)
  TLSv1.2 (SunJSSE)
Default Cipher Name
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
*   SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
SSL_DHE_DSS_WITH_DES_CBC_SHA
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
*   SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_RSA_WITH_DES_CBC_SHA
SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA
SSL_DH_anon_EXPORT_WITH_RC4_40_MD5
SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
SSL_DH_anon_WITH_DES_CBC_SHA
SSL_DH_anon_WITH_RC4_128_MD5
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_RSA_EXPORT_WITH_RC4_40_MD5
*   SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_RSA_WITH_DES_CBC_SHA
SSL_RSA_WITH_NULL_MD5
SSL_RSA_WITH_NULL_SHA
SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_RC4_128_SHA
*   TLS_DHE_DSS_WITH_AES_128_CBC_SHA
*   TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
*   TLS_DHE_DSS_WITH_AES_256_CBC_SHA
*   TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
*   TLS_DHE_RSA_WITH_AES_128_CBC_SHA
*   TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
*   TLS_DHE_RSA_WITH_AES_256_CBC_SHA
*   TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DH_anon_WITH_AES_128_CBC_SHA
TLS_DH_anon_WITH_AES_128_CBC_SHA256
TLS_DH_anon_WITH_AES_256_CBC_SHA
TLS_DH_anon_WITH_AES_256_CBC_SHA256
*   TLS_EMPTY_RENEGOTIATION_INFO_SCSV
TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5
TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA
TLS_KRB5_EXPORT_WITH_RC4_40_MD5
TLS_KRB5_EXPORT_WITH_RC4_40_SHA
TLS_KRB5_WITH_3DES_EDE_CBC_MD5
TLS_KRB5_WITH_3DES_EDE_CBC_SHA
TLS_KRB5_WITH_DES_CBC_MD5
TLS_KRB5_WITH_DES_CBC_SHA
TLS_KRB5_WITH_RC4_128_MD5
TLS_KRB5_WITH_RC4_128_SHA
*   TLS_RSA_WITH_AES_128_CBC_SHA
*   TLS_RSA_WITH_AES_128_CBC_SHA256
*   TLS_RSA_WITH_AES_256_CBC_SHA
*   TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_NULL_SHA256

Note the complete lack of ECDH or ECDHE cipher suites. Now again with
Java 8:

$ java8 -showversion -classpath libs/chadis-tools-1.55.jar
com.chadis.tools.security.SSLInfo
openjdk version "1.8.0_101"
OpenJDK Runtime Environment (build 1.8.0_101-b13)
OpenJDK Server VM (build 25.101-b13, mixed mode)

Supported SSL Protocols:
  TLS (SunJSSE)
  TLSv1 (SunJSSE)
  TLSv1.1 (SunJSSE)
  TLSv1.2 (SunJSSE)
Default Cipher Name
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
*   SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
SSL_DHE_DSS_WITH_DES_CBC_SHA
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
*   SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_RSA_WITH_DES_CBC_SHA
SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA
SSL_DH_anon_EXPORT_WITH_RC4_40_MD5
SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
SSL_DH_anon_WITH_DES_CBC_SHA
SSL_DH_anon_WITH_RC4_128_MD5
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_RSA_EXPORT_WITH_RC4_40_MD5
*   SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_RSA_WITH_DES_CBC_SHA
SSL_RSA_WITH_NULL_MD5
SSL_RSA_WITH_NULL_SHA
SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_RC4_128_SHA
*   TLS_DHE_DSS_WITH_AES_128_CBC_SHA
*   TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
*   TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
*   TLS_DHE_DSS_WITH_AES_256_CBC_SHA
*   TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
*   TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
*   TLS_DHE_RSA_WITH_AES_128_CBC_SHA
*   TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
*   TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
*   TLS_DHE_RSA_WITH_AES_256_CBC_SHA
*   TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
*   TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DH_anon_WITH_AES_128_CBC_SHA
TLS_DH_anon_WITH_AES_128_CBC_SHA256
TLS_DH_anon_WITH_AES_128_GCM_SHA256
TLS_DH_anon_WITH_AES_256_CBC_SHA
TLS_DH_anon_WITH_AES_256_CBC_SHA256

Re: Increased memory consumption due to url encoding

2016-08-12 Thread Rainer Jung

Am 11.08.2016 um 21:16 schrieb Jose María Zaragoza:

2016-08-10 14:29 GMT+02:00 Lazar Kirchev :

Hello Christopher,

I tried with 32 MB and even 24 MB heap and the CPU usage and response time
remained the almost the same (the difference is negligible) as with 1 GB
heap. The cumulative allocated memory for the HeapByteBuffer remains about
400 MB, but of course the frequency of GCs is increased.



A newbie question:

if you tried with 32 MB ( I guess -Xmx size ) , why is not raised an OOM error ?
are those 400MB allocated outside heap ?


Allocation size is not the same as size of objects in memory. An 
allocation of 400 MB during some test means the sum of the sizes of all 
objects that were created was 400 MB. The life time of those objects 
could be very short. So it is possible that only few of them were in 
memory at the same time.


An extreme example: suppose you create 1000 objects per second (or one 
per millisecond) each of size 10 KB. That means you have an allocation 
rate of 10 MB/s or after one minute 600 MB. Assume further that each 
object only lives 5 milliseconds, because it maybe is created and used 
only inside a method that runs very short. Then at each point in time 
about 5 of those objects exist which makes up only 50 KB of memory.


For many java programs the popular slogan "most objects die young" is 
correct, which means you can have high allocation rates with relatively 
small memory. Allocation is relatively cheap in Java. As always details 
go far beyond such simplistic slogans.


Regards,

Rainer

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



Re: mod_jk errors

2016-07-15 Thread Rainer Jung

Am 12.07.2016 um 19:44 schrieb Wayne Li:

Hi,

I have a servlet/jsp application running on tomcat 7.0.47. There are no
static html files.
Now I am try to use apache 2.4.7 (Ubuntu)
as the front and forward eveything to tomcat. I installed mod_jk using
Ubuntu's software
center.. Things are working. But I have errors in
/var/log/apache2/mod_jk.log:

[Mon Jul 11 20:19:32.261 2016] [1175:140389159810944] [info]
init_jk::mod_jk.c (3365): mod_jk/1.2.37 initialized
[Mon Jul 11 20:19:32.279 2016] [1175:140389159810944] [error]
extension_fix::jk_uri_worker_map.c (564): Could not find worker with name
'jk-manager' in uri map post processing.
[Mon Jul 11 20:19:32.279 2016] [1175:140389159810944] [error]
extension_fix::jk_uri_worker_map.c (564): Could not find worker with name
'jk-status' in uri map post processing.
[Mon Jul 11 20:19:32.386 2016] [1177:140389159810944] [info]
init_jk::mod_jk.c (3365): mod_jk/1.2.37 initialized
[Mon Jul 11 20:19:32.386 2016] [1177:140389159810944] [error]
extension_fix::jk_uri_worker_map.c (564): Could not find worker with name
'jk-manager' in uri map post processing.
[Mon Jul 11 20:19:32.386 2016] [1177:140389159810944] [error]
extension_fix::jk_uri_worker_map.c (564): Could not find worker with name
'jk-status' in uri map post processing.

If I add the following lines, the errors go away:

worker.list=jk-status
worker.jk-status.type=status
worker.jk-status.read_only=true
worker.list=jk-manager
worker.jk-manager.type=status

But the added line read funny. The same thing appears on the left-side of
the equal sign twice.
Are they correct? Do I need these lines? Can I ignore the errors?

Any information would be appreciated. Thanks in advance.


In addition to André's excellent tutorial: mod_jk knows that some 
properties configured via workers.properties take (comma-separated) 
lists as values. Since sometimes maintaining these lists is error-prone, 
it allows you to define the properties multiple times and will collect 
all given values into one big list. That makes maintaining hte list a 
more modular job.


In your case the following is exactly equivalent:

Either:

worker.list=jk-status,jk-manager,myworker

Or:

worker.list=jk-status
#Some more config items concerning jk-status
worker.list=jk-manager
#Some more config items concerning jk-manager
worker.list=myworker
#Some more config items concerning myworker

In both cases the internal value of worker.list after parsing the 
complete file will be "jk-status,jk-manager,myworker".


So what look a bit funny to you was supposed to be helpful ;)

Can you ignore the errors: No.

- If you don't want the jk-status and/or jk-manager worker features, 
then look for the JkMount directives where you referenced them (or 
entried in a uriworkermap.properties file but that's rarely used).


- If you want to use the jk-status and/or jk-manager workers, you need 
to define them in workers.properties like you did above.


Regards,

Rainer

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



Re: [somewhat OT] mod-jk + ssl: requests are not forward to tomcat correctly

2016-07-12 Thread Rainer Jung

Am 12.07.2016 um 12:06 schrieb André Warnier (tomcat):

On 12.07.2016 01:39, Wayne Li wrote:

Probably the quickest : download these files, install them on your

server, and change the above links.
Like : create a sub-directory "/js" of your webapp, and install them
there.
Then change the above links to : href="js/jquery.mobile-1.4.5.min.css"

Yes. It works. Thanks.

It is okay for now. but, if I do not want host these files, what should I
do? Can you point a direction for me please?



I just wante to make some personal comments here, to what you write above :

You are saying that you do not really want to "host" those files on your
server, and that you (presumably) would like to continue to link to them
directly on the jquery host.
But I believe that there are a few considerations to take into account
here, on the practical, ethical, and security levels :

Basically, if you do this, then it means that any browser, anywhere,
that is using your application, will now (try to) access and download
these files directly from the jquery server, instead of from your server.

1) ethical aspect :
Users of your application will now be using the resources and bandwidth
of a server that is not yours, and which is supported by someone else.
That someone else may not like this very much.
I had a (quick and not exhaustive) look at the jquery website, and I did
not find anything which explicitly discourages people from doing this.
And it may well be that they actually encourage people to do this (maybe
they are pleased to have a lot of traffic).

But I believe that before doing something like this, you may want to at
least ask them if this is ok, or what they recommend. And in particular
in this case, since jquery is a non-profit, open-source resource for
which you do not pay in the first place.

2) practical aspect :
By doing this, your application becomes dependent on the fact that any
of your user's browsers would actually be able to access that external
server, which is not under your control. There could be some firewall
rule which prevents such an access (now, or at any time in the future).
That server could be down for maintenance; it could be re-organised, so
that the files are no longer at that specific URL location; the file
content could be changed, so that things do no longer work in exactly
the same way; etc..
As you have just found out, even some browser rules (which can change
over time) may prevent access to these files.
And I know of some websites which take active measures to prevent people
doing this (using their resources in such a way), for example by
checking the "Referer" of the access to their resources.

Another practical aspect, is that if something does not work anymore in
one of your applications, your users will come to you for an
explanation; and it may be time-consuming, in a case like this, to find
out what exactly isn't working.

3) security aspect :
If anyone managed to replace the content of that file (again, this is
not under your control), they would be able to "inject" malicious
content into your application.
And to the world at large, this would at first look as if it was your
application which is the culprit.

These are my personal opinions only.  But for the reasons above, I would
rather host myself the resources needed by my applications.


and

4) Privacy: the owner of the external server (here: jquery) is able to 
track who is visiting your site. Your visitors might not like this.


Regards,

Rainer


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



Re: mod-jk (1.2.37) crashes Apache 2 (2.4.7) occasionally with a buffer overflow on Ubuntu 14.04 x64

2016-06-29 Thread Rainer Jung

Am 29.06.2016 um 11:58 schrieb Michael Diener:

I get occasional Apache 2 crashes being caused by mod_jk and I'm running
out of ideas about the cause of the problem. I hope somebody here can point
me in the right direction.


Can you reproduce? Does it also happen on a test system?


tomcat6 6.0.39-1

libapache2-mod-jk 1:1.2.37-3


Latest we provide in the project is 1.2.41. It is pretty easy to compile 
yourself and would be an interesting check to see, whether it is just an 
old already fixed problem.



apache2 2.4.7-1ubuntu4

java version "1.6.0_45"
Java(TM) SE Runtime Environment (build 1.6.0_45-b06)
Java HotSpot(TM) 64-Bit Server VM (build 20.45-b01, mixed mode)

/var/log/apache2/error.log



 buffer overflow detected ***: /usr/sbin/apache2 terminated===
Backtrace:
=/lib/x86_64-linux-gnu/libc.so.6(+0x7329f)[0x7fe9aa7de29f]/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7fe9aa875bbc]/lib/x86_64-linux-gnu/libc.so.6(+0x109a90)[0x7fe9aa874a90]/lib/x86_64-linux-gnu/libc.so.6(+0x10ab07)[0x7fe9aa875b07]/usr/lib/apache2/modules/mod_jk.so(jk_open_socket+0x8d8)[0x7fe9a7c60cb8]/usr/lib/apache2/modules/mod_jk.so(ajp_connect_to_endpoint+0x65)[0x7fe9a7c7bf75]/usr/lib/apache2/modules/mod_jk.so(+0x36422)[0x7fe9a7c7d422]/usr/lib/apache2/modules/mod_jk.so(+0x1674c)[0x7fe9a7c5d74c]/usr/sbin/apache2(ap_run_handler+0x40)[0x7fe9ab65fbe0]/usr/sbin/apache2(ap_invoke_handler+0x69)[0x7fe9ab660129]/usr/sbin/apache2(ap_process_async_request+0x20a)[0x7fe9ab6756ca]/usr/sbin/apache2(+0x69500)[0x7fe9ab672500]/usr/sbin/apache2(ap_run_process_connection+0x40)[0x7fe9ab669220]/usr/lib/apache2/modules/mod_mpm_event.so(+0x681b)[0x7fe9a783981b]/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7fe9aab38184]/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fe9aa86537d]*
=== Memory map: 
7fe68800-7fe68806a000 rw-p  00:00 0
7fe68806a000-7fe68c00 ---p  00:00 0
...
7fffa6c27000-7fffa6c48000 rw-p  00:00 0 [stack]
7fffa6c86000-7fffa6c88000 r-xp  00:00 0 [vdso]
ff60-ff601000 r-xp  00:00 0 [vsyscall]
[Wed Jun 29 05:01:50.052325 2016] [core:notice] [pid 1747:tid
140641581987712] AH00051: child pid 17018 exit signal Aborted (6), possible
coredump in /etc/apache2

The log indicates there might be a coredump, but there is not.


Configure your system so that it writes core dump files, look at the 
core dump file with "gdb", e.g. running "thread apply all bt full" and 
provide the output.


Likely your httpd is running as a suid process (started as root but the 
children switch uid to something else, like www or similar). You have to 
enable core dump for suid processes explicitly in your Linux.



There is no log in /var/log/apache2/mod_jk.log at the same time.

/var/log/tomcat6/catalina.out

Jun 29, 2016 5:01:49 AM org.apache.jk.common.ChannelSocket processConnection
WARNING: processCallbacks status 2
Jun 29, 2016 5:01:49 AM org.apache.jk.common.ChannelSocket processConnection
WARNING: processCallbacks status 2

The Tomcat log indicates AFAIK that the client connection has been lost.

/etc/libapache2-mod-jk/httpd-jk.conf



JkWorkersFile /etc/libapache2-mod-jk/workers.properties
JkLogFile /var/log/apache2/mod_jk.log
JkLogLevel warn
JkShmFile /var/log/apache2/jk-runtime-status



/etc/libapache2-mod-jk/workers.properties


The next lines look like they are coming from very old and partially 
nonsense recipies. Your crash won't be a result of those but you should 
probably start to create your config based on what's inside the conf 
folder of our source distribution for mod_jk. The files can also be 
found under http://svn.apache.org/viewvc/tomcat/jk/trunk/conf/.



workers.tomcat_home=/usr/share/tomcat6
workers.java_home=/usr/lib/jvm/java-6-sun
ps=/

worker.list=loadbalancer

worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers=ajp13_worker,ajp13_worker2
worker.loadbalancer.sticky_session=0

worker.ajp13_worker.port=xxx
worker.ajp13_worker.host=localhost
worker.ajp13_worker.type=ajp13
worker.ajp13_worker.lbfactor=50


If you don't really need the increased max_packet_size, you should 
comment it out here and the packetSize below and retry. Those settings 
are not so common. There were also changes related to them in newer 
versions.



worker.ajp13_worker.max_packet_size=65536


Not crash related, but I don't like the general socket_timeout. Look at 
the configs proposed above. They use lots of good timeouts, but 
socket_timeout is not one of them.



worker.ajp13_worker.socket_timeout=300
worker.ajp13_worker.ping_mode=A
worker.ajp13_worker.secret=xxx
worker.ajp13_worker.fail_on_status=503
worker.ajp13_worker.connection_pool_size=32768

#worker.ajp13_worker.activation=disabled
worker.ajp13_worker.redirect=ajp13_worker2

worker.ajp13_worker2.port=xxx
worker.ajp13_worker2.host=otherhost
worker.ajp13_worker2.type=ajp13
worker.ajp13_worker2.lbfactor=1
worker.ajp13_worker2.max_packet_size=65536

Re: mod JK ho to rout all content to tomcat except for a few static folders

2016-06-20 Thread Rainer Jung

Am 20.06.2016 um 18:32 schrieb Campbell, Lance:

Neither of these options will work for me:
1) no-jk is only supported for: "Starting with mod_jk 1.2.6 for Apache 2.x and 
1.2.19 for Apache 1.3"


So? You wrote your versions are

Apache 2.2.15
mod_jk  1.2.41

and isn't 1.2.41 >= 1.2.6? So the no-jk feature is supported. Why do you 
think it is not?



2) The urls that get sent to Tomcat are unkown.  This is a dynamic content 
driven site.


1) and 2) both work once you know which URIs you want to exclude form 
forwarding. You wrote "except for three directories that contain static 
content" so I guess you are able to describe those URIs to exclude e.g. 
by one to three URI prefixes?


The examples Anthony gave are correct, so if your URIs to exclude start 
e.g. with /img/, /css/ and /static/, you could either


JkUnMount /img/* *
JkUnMount /css/* *
JkUnMount /static/* *

or

SetEnvIf Request_URI "/img/*" no-jk
SetEnvIf Request_URI "/css/*" no-jk
SetEnvIf Request_URI "/static/*" no-jk

I slightly prefer the JkUnMount way, because it is a bit easier to 
read/understand if you put it close to your JkMount in the config file. 
The second way is convenient if the exclusion rules get more complex, 
because you can do tricky stuff with environment variables (no-jk).


Regards,

Rainer


-Original Message-
From: Anthony Biacco [mailto:abia...@handll.com]
Sent: Monday, June 20, 2016 10:29 AM
To: Tomcat Users List 
Subject: Re: mod JK ho to rout all content to tomcat except for a few static 
folders

On Mon, Jun 20, 2016 at 9:14 AM, Campbell, Lance  wrote:


These are the versions of software I have to use.  I cannot install
other
software:



Apache 2.2.15

mod_jk  1.2.41

Tomcat 8.0.36



Issue:

We are looking at having a domain where all content will get routed to
Tomcat 8 except for three directories that contain static content.
These three directories will be served up by Apache.  Based on the
above versions how can I tell Apache to handle just these three
directories and then send all other content requests to Tomcat?






should be able to use either of:

JkUnMount /URI/* worker

SetEnvIf Request_URI "/URI/*" no-jk


-Tony


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



Re: Small problems compiling tomcat native

2016-04-25 Thread Rainer Jung

Am 25.04.2016 um 14:31 schrieb Stefan Frei:

very sorry just solved it.


overlooked a line in configure

/root/tomcat-native-1.1.34-src/jni/native/build/get-version.sh:
Permission denied


OK, no problem. If extracted from a source tarball, the file should have 
been executable by default though. It might be it is not if you picked a 
zip file source download.


Another comment: OpenSSL 1.0.1k is pretty old. 1.0.1s is current for 
1.0.1 and even better would be 1.0.2g but it might be, that you won't 
find such a packet for your OS version. You could compile 1.0.2g 
yourself though and install in a separate directory. Using 1.0.2 you 
could switch to tcnative 1.2.x (which needs OpenSSL 1.0.2). The current 
tcnative 1.2.x is 1.2.5, but a 1.2.6 will likely be released during the 
next few days.


There are currently no plans for another tcnative 1.1.x release.

Regards,

Rainer


2016-04-25 14:04 GMT+02:00 Rainer Jung <rainer.j...@kippdata.de>:

Can you provide the full configure command you use and the configure and
make output as well as config.log? Do you have environment variables set,
that influence the build (CC, CFLAGS, LDFLAGS or similar)?

The "-Wl,-z,relro" should not directly come from our own tcnative scripts
but using the make output (and configure output) we can double check.

It could be, that those flags come from and APR or OpenSSL pkgconfig or .la
file or similar, which we inspect when building tcnative to learn about the
correct flags to link against OpenSSL and APR.

You might run

find PATH -exec grep relro \{\} \; -ls

with PATH replaced by the tcnative build directory and APR and OpenSSL
install directories respectively. There are indications that debian adds the
relro flag when building the system openssl.

Does you linker understand "-z relro"? You can check "man ld" and "ld
--help".

Regards,

Rainer


Am 25.04.2016 um 13:16 schrieb Stefan Frei:


libapr1:amd64  1.5.1-3
openssl1.0.1k-3+deb8u4

2016-04-25 12:35 GMT+02:00 Mark Thomas <ma...@apache.org>:


On 25/04/2016 10:31, Stefan Frei wrote:


Hello

tomcat 8.0.33
tomcat-native-1.1.34-src
SMP Debian 3.16.7-ckt25-2
1.8.0_77

i am unable to compile the native libs, here is the error messages
from the make command:

libtool: link: CURRENT `-Wl,-z,relro' must be a nonnegative integer
libtool: link: `-Wl,-z,relro' is not valid version information
make[1]: *** [libtcnative-.la] Error 1
make: *** [all-recursive] Error 1

I followed the instructions described here:
https://tomcat.apache.org/native-doc/

how can i debug this?



What versions of APR and OpenSSL are you compiling against?

Mark


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



Re: Small problems compiling tomcat native

2016-04-25 Thread Rainer Jung
Can you provide the full configure command you use and the configure and 
make output as well as config.log? Do you have environment variables 
set, that influence the build (CC, CFLAGS, LDFLAGS or similar)?


The "-Wl,-z,relro" should not directly come from our own tcnative 
scripts but using the make output (and configure output) we can double 
check.


It could be, that those flags come from and APR or OpenSSL pkgconfig or 
.la file or similar, which we inspect when building tcnative to learn 
about the correct flags to link against OpenSSL and APR.


You might run

find PATH -exec grep relro \{\} \; -ls

with PATH replaced by the tcnative build directory and APR and OpenSSL 
install directories respectively. There are indications that debian adds 
the relro flag when building the system openssl.


Does you linker understand "-z relro"? You can check "man ld" and "ld 
--help".


Regards,

Rainer

Am 25.04.2016 um 13:16 schrieb Stefan Frei:

libapr1:amd64  1.5.1-3
openssl1.0.1k-3+deb8u4

2016-04-25 12:35 GMT+02:00 Mark Thomas :

On 25/04/2016 10:31, Stefan Frei wrote:

Hello

tomcat 8.0.33
tomcat-native-1.1.34-src
SMP Debian 3.16.7-ckt25-2
1.8.0_77

i am unable to compile the native libs, here is the error messages
from the make command:

libtool: link: CURRENT `-Wl,-z,relro' must be a nonnegative integer
libtool: link: `-Wl,-z,relro' is not valid version information
make[1]: *** [libtcnative-.la] Error 1
make: *** [all-recursive] Error 1

I followed the instructions described here:
https://tomcat.apache.org/native-doc/

how can i debug this?


What versions of APR and OpenSSL are you compiling against?

Mark


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



Re: SSL_CTX_set_alpn_select_cb undefined

2016-04-15 Thread Rainer Jung

Am 15.04.2016 um 20:24 schrieb Michael Fox:

Per https://access.redhat.com/solutions/445713, the Apache httpd rpm package 
included in RHEL 7 is based on Apache 2.4.6.

OpenSSL version 1.0.1 is the latest version available from RedHat.

As you said, "... the current patch level of 1.0.2, which is 1.0.2g has no known security 
issues" and" ...symbol SSL_CTX_set_alpn_select_cb only exists in 1.0.2 and newer ".  
You are referring to the version of OpenSSL which available as open source, not from Red Hat, 
correct?


Yes. You can get OpenSSL 1.0.2g (or anything newer at the time of 
retrieval from openssl.org). You'd have to build it yourself.



If I am still confused, please explain it to me.  If not, I would like to refer 
to the questions at the end of my original post (below).


You are not confused.

>> Should I investigate the use of older versions of Tomcat, Java, and 
Tomcat connector?


In general "no" and also not because of this problem.

>> Should I not use APR with Tomcat (and then use HTTP/1.1)?

If you have a need for the APR connector you can use it.

>> Should I abandon the RedHat Apache/OpenSSL software and use the 
latest Apache/OpenSSL from apache.org?

>>

Apache as in "Apache web server" doesn't have anything to do with the 
topic here. You can create the tcnative libs based on your own 
compilation of OpenSSL (and if you like also the APR libs) without 
influencing which OpenSSL or APR version your Linux and your Apache web 
server coming from this Linux distro uses. If RedHat doesn't provide you 
OpenSSL 1.0.2 and you'd like to use up-to-date Tomcat (recommended) and 
you have a need for tcnative, then yes, you'd need to do your own 
OpenSSL compilation.


Regards,

Rainer



-Original Message-
From: Rainer Jung [mailto:rainer.j...@kippdata.de]
Sent: Friday, April 15, 2016 1:57 PM
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: SSL_CTX_set_alpn_select_cb undefined

Am 15.04.2016 um 19:37 schrieb Michael Fox:

I am running Red Hat Linux version 7.2, Apache version 2.4.6, Java JDK 
1.8.0_65, Tomcat version 9.0.0.M1, Tomcat connector version 1.2.5, and have 
uncommented the HTTP/2 Connector lines in the Tomcat server.xml file.  When I 
run the configure command for the Tomcat connector, I get the message:

checking OpenSSL library version >= 1.0.2...



Found   OPENSSL_VERSION_NUMBER 0x1000105f (OpenSSL 1.0.1e 11 Feb 2013)

Require OPENSSL_VERSION_NUMBER 0x1000200f or greater (1.0.2)



Per Red Hat (https://access.redhat.com/articles/1384453), they consider OpenSSL 
version 1.0.2 to have security issues, and so are not issuing that version.


You misunderstood that text. Version 1.0.2 had security issues, which where 
fixed by 1.0.2a. So the current patch level of 1.0.2, which is 1.0.2g has no 
known security issues.

tcnative starting with version 1.2.0 no longer supports OpenSSL older than 
1.0.2. So no support for 0.9.8, 1.0.0 and 1.0.1. You need to build tcnative 
1.2.x against OpenSSL 1.0.2 preferably against 1.0.2g.

The symbol SSL_CTX_set_alpn_select_cb only exists in 1.0.2 and newer.

Regards,

Rainer


To be able to configure and make the tcnative library, I run the configure 
command as such:

   ./configure --with-apr=/usr/bin/apr-1-config
--with-java-home=$JAVA_HOME --prefix=$CATALINA_HOME
--disable-openssl-version-check --with-ssl=yes



I am able to make and install the library, but when I run the Tomcat configtest 
I get:

INFO: Initializing ProtocolHandler ["https-apr-8443"]

/usr/java/jdk1.8.0_65/bin/java: symbol lookup error:
/home/tomcat/apache-tomcat-9.0.0.M1-src/output/build/lib/libtcnative-1
.so.0.2.5: undefined symbol: SSL_CTX_set_alpn_select_cb

Configuration error detected!



Is there a way to get around or define this symbol?

Should I investigate the use of older versions of Tomcat, Java, and Tomcat 
connector?

Should I not use APR with Tomcat (and then use HTTP/1.1)?

Should I abandon the RedHat Apache/OpenSSL software and use the latest 
Apache/OpenSSL from apache.org?



Thanks,

Mike


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



Re: SSL_CTX_set_alpn_select_cb undefined

2016-04-15 Thread Rainer Jung

Am 15.04.2016 um 19:37 schrieb Michael Fox:

I am running Red Hat Linux version 7.2, Apache version 2.4.6, Java JDK 
1.8.0_65, Tomcat version 9.0.0.M1, Tomcat connector version 1.2.5, and have 
uncommented the HTTP/2 Connector lines in the Tomcat server.xml file.  When I 
run the configure command for the Tomcat connector, I get the message:

checking OpenSSL library version >= 1.0.2...



Found   OPENSSL_VERSION_NUMBER 0x1000105f (OpenSSL 1.0.1e 11 Feb 2013)

Require OPENSSL_VERSION_NUMBER 0x1000200f or greater (1.0.2)



Per Red Hat (https://access.redhat.com/articles/1384453), they consider OpenSSL 
version 1.0.2 to have security issues, and so are not issuing that version.


You misunderstood that text. Version 1.0.2 had security issues, which 
where fixed by 1.0.2a. So the current patch level of 1.0.2, which is 
1.0.2g has no known security issues.


tcnative starting with version 1.2.0 no longer supports OpenSSL older 
than 1.0.2. So no support for 0.9.8, 1.0.0 and 1.0.1. You need to build 
tcnative 1.2.x against OpenSSL 1.0.2 preferably against 1.0.2g.


The symbol SSL_CTX_set_alpn_select_cb only exists in 1.0.2 and newer.

Regards,

Rainer


To be able to configure and make the tcnative library, I run the configure 
command as such:

  ./configure --with-apr=/usr/bin/apr-1-config --with-java-home=$JAVA_HOME 
--prefix=$CATALINA_HOME --disable-openssl-version-check --with-ssl=yes



I am able to make and install the library, but when I run the Tomcat configtest 
I get:

INFO: Initializing ProtocolHandler ["https-apr-8443"]

/usr/java/jdk1.8.0_65/bin/java: symbol lookup error: 
/home/tomcat/apache-tomcat-9.0.0.M1-src/output/build/lib/libtcnative-1.so.0.2.5:
 undefined symbol: SSL_CTX_set_alpn_select_cb

Configuration error detected!



Is there a way to get around or define this symbol?

Should I investigate the use of older versions of Tomcat, Java, and Tomcat 
connector?

Should I not use APR with Tomcat (and then use HTTP/1.1)?

Should I abandon the RedHat Apache software and use the latest Apache from 
apache.org?



Thanks,

Mike


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



Re: Modjk surfacing errno 115

2016-03-04 Thread Rainer Jung

Am 05.03.2016 um 00:09 schrieb Max Lynch:

Hi Rainer, I will do my best to provide those things.

Here is what looks like the full sequence from the our log:

[46055:3512666992] [info] jk_open_socket::jk_connect.c (627): connect to
_ip_:12409 failed (errno=115)
[46055:3512666992] [info] ajp_connect_to_endpoint::jk_ajp_common.c (992):
Failed opening socket to (_ip_:12409) (errno=115)
[46055:3512666992] [error] ajp_send_request::jk_ajp_common.c (1621):
(_hostname_) connecting to backend failed. Tomcat is probably not started
or is listening on the wrong port (errno=115)
[46055:3512666992] [info] ajp_service::jk_ajp_common.c (2614): (_hostname_)
sending request to tomcat failed (recoverable), because of error during
request sending (attempt=1)
[46055:3512666992] [info] jk_open_socket::jk_connect.c (627): connect to
_ip_:12409 failed (errno=115)
[46055:3512666992] [info] ajp_connect_to_endpoint::jk_ajp_common.c (992):
Failed opening socket to (_ip_:12409) (errno=115)
[46055:3512666992] [error] ajp_send_request::jk_ajp_common.c (1621):
(_hostname_) connecting to backend failed. Tomcat is probably not started
or is listening on the wrong port (errno=115)
[46055:3512666992] [info] ajp_service::jk_ajp_common.c (2614): (_hostname_)
sending request to tomcat failed (recoverable), because of error during
request sending (attempt=2)
[46055:3512666992] [error] ajp_service::jk_ajp_common.c (2634):
(_hostname_) connecting to tomcat failed.
[46055:3512666992] [info] service::jk_lb_worker.c (1469): service failed,
worker _hostname_ is in error state


OK, so errno 115 occurs in jk_connect.c line 627. The code there is 
expected to handle 115 but will not wait longer than socket_connect_timeout.



You can see after this sequence the backend worker is marked as Bad.

Here is the config:

JkWorkerProperty worker.list=jkstatus,ajp_app,ajp_app2,ajp_app3,...
JkWorkerProperty worker.jkstatus.type=status
JkWorkerProperty worker.lb_member_template.type=ajp13
JkWorkerProperty worker.lb_member_template.activation=Active
JkWorkerProperty worker.lb_member_template.ping_mode=A
JkWorkerProperty worker.lb_member_template.connection_pool_timeout=600
JkWorkerProperty worker.lb_member_template.socket_keepalive=True
JkWorkerProperty worker.lb_member_template.socket_timeout=30


I usually recommend *not* to use the general socket_timeout. Remove it.

I do suggest to set ping_timeout to e.g. 10 seconds (it is the default, 
but making it explicit kind of ducoments it in your config).



JkWorkerProperty worker.lb_member_template.socket_connect_timeout=3000


This means 3 seconds connect timeout. So it seems either your network, 
an intermediary between Apache and Tomcat, or Tomcat has a problem of 
allowing to establish a new connection in 3 seconds. Although the 
connect is typically done by the backend OS, once the app/TC/JVM gets 
slow in accepting new connections, the accept queue fills up and then 
new connects will fail.


Did you check whether you observe long GC pauses for your Tomcat JVMs? 
Enable a very verbose GC log and have a look.


I typically avoid very short timeouts, so try setting 
socket_connect_timeout to 1. If the root cause isn't just a short 
term hickup, this will not mitigate the problem but should result in 
slightly better stability in general.



JkWorkerProperty worker.lb_member_template.recover_time=30
JkWorkerProperty worker.lb_member_template.recovery_options=7
JkWorkerProperty worker.lb_worker_template.type=lb
JkWorkerProperty worker.ajp_app.reference=worker.lb_worker_template
JkWorkerProperty worker.ajp_app.balance_workers=_hostname1_ajpport1,
_hostname1_ajpport2, ..., _hostname34_ajpport15
JkWorkerProperty
worker._hostname_ajpportX.reference=worker.lb_member_template
JkWorkerProperty worker._hostname_ajpportX.host=_hostname_
JkWorkerProperty worker._hostname_ajpportX.port=


Looks fine except for the socket_timeout and the very short 
socket_connect_timeout.



will this list accept attachments for the other details such as netstat
output and thread dumps?


Not sure, but you can try. If it doesn't work, you can also send 
privately to me and I will summarize.


If the problem persists for a long enough time, you can also try opening 
a new connection to your Tomcat AJP connector from the mod_jk machine by 
running a telnet from the mod_jk machine to the remote Tomcat port. If 
there is a longer hang, you should notice it with telnet as well. Of 
course you can't speak AJP using telnet, but it can show you whether 
there really is a connect problem.


You might argue, that the problem disappears when you restart Apache. 
But that might be due to the fact, that then all existing connections 
get closed and resources (like threads) are freed on the Tomcat/JVM 
side. I suspect the question is, what keeps those resources busy. So 
let's have a look at netstat and thread dumps and probably try the 
little telnet experiment.


Regards,

Rainer


Re: Modjk surfacing errno 115

2016-03-04 Thread Rainer Jung

Am 04.03.2016 um 20:35 schrieb Max Lynch:

Hi there,

We have a very heavily used implementation of modjk 1.2.35 running in
Apache 2.2.15 i686 on CentOS 6.7 x86_64. After Apache startup, our system
will perform optimally with no errors for about 24 hours, after which we
begin to see this message:

connecting to backend failed. Tomcat is probably not started or is
listening on the wrong port (errno=115)


Errno 115 on RHEL is EINPROGRESS. That means the call didn't finish but 
one could retry it. This indicates we might be able to improve the code, 
but it is also possible that e.g. a configured socket_connect_timeout 
was reached. To check, we would need the full mod_jk log lines (and if 
several different log lines show up for one event all of them) including 
the columns with source file name and line number etc.


It would also be very useful to see your configuration. You can remove 
IP adresses, ports, secrets etc. and rename your workers but we should 
see the timeout setting, cping settings and so on.



Once we start seeing this error for one backend/worker, we begin seeing the
same errors for eventually all workers. This problem doesn't go away until
we restart Apache. Our setup consists of 720 workers per apache, with
multiple apache servers, and each apache server also has several other
sites configured with modjk serving other tomcat backends. It should be
noted that we do not see the same error with other sites, nor do we have so
many workers defined for any other site.



We've searched through past mailings to try and find the same issue. The
couple times we saw it brought up the error code 110 was also mentioned. It
should be noted we do not see the same pattern. errno 110 does show but
outside of the window when the problem begins and is at its worst. We
believe this issue is not configuration related.

We're posting this here to try and gather more data. Our process prohibits
an upgrade of any kind without plenty of evidence supporting our position.
Hoping that some individuals might have seen this particular issue, or if
there is any data on whether this could be a bug. Hopefully we're correct
in thinking this issue is not a configuration problem, but we'll help to
rule out.


It could also be interesting to capture the output of "netstat -an" 
during the time that the problem happens. And finally the same on the 
Tomcat side as well as a thread dump of the Tomcat JVM.


Once you provide the full log line, I can check, whether the 1.2.41 code 
actually has improvements related to errno 115 or not. Knowing the place 
in the code where the error occurs might also give us an idea, what 
might have happened and how to check further (e.g. Tomcat not accepting 
connections, firewall idle connection drop between mod_jk and Tomcat 
etc. etc.).


Regards,

Rainer

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



Re: How do I block 'Unloading class sun.reflect....' messages?

2016-01-07 Thread Rainer Jung

Am 07.01.2016 um 19:21 schrieb Caldarale, Charles R:

From: Lee Bassom [mailto:lbas...@interactions.com]
Subject: Re: How do I block 'Unloading class sun.reflect' messages?



-XX:+PrintGCDetails


I'm going to guess that the above enables the class unloading messages.


I used the above flags in combination with "-XX:+PrintFlagsFinal" and 
couldn't find anything enabled that would print class unloading 
messages. Then went further, looked at looked at 
hotspot/src/share/vm/runtime/arguments.cpp and again didn't find 
anything (apart from the known -verbose:class, that's not in use here).


Then in noticed, that the HotSpot version 20.5-b03 looks quite old, so I 
guess this is Java 6? And yes, in arguments.cpp for Java 6 one finds 
TraceClassUnloading enabled as a side effect of -Xloggc (sic!). And that 
side effect is actually visible with "-XX:+PrintFlagsFinal".


So it seems for Java 6 there's no way around that. As soon as you (the 
OP) use -Xloggc, the JVM activates TraceClassUnloading. This should not 
happen in Java 7 or 8.


Regards,

Rainer


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



Re: How do I block 'Unloading class sun.reflect....' messages?

2016-01-07 Thread Rainer Jung

Am 07.01.2016 um 19:55 schrieb Rainer Jung:

Am 07.01.2016 um 19:21 schrieb Caldarale, Charles R:

From: Lee Bassom [mailto:lbas...@interactions.com]
Subject: Re: How do I block 'Unloading class sun.reflect' messages?



-XX:+PrintGCDetails


I'm going to guess that the above enables the class unloading messages.


I used the above flags in combination with "-XX:+PrintFlagsFinal" and
couldn't find anything enabled that would print class unloading
messages. Then went further, looked at looked at
hotspot/src/share/vm/runtime/arguments.cpp and again didn't find
anything (apart from the known -verbose:class, that's not in use here).

Then in noticed, that the HotSpot version 20.5-b03 looks quite old, so I
guess this is Java 6? And yes, in arguments.cpp for Java 6 one finds
TraceClassUnloading enabled as a side effect of -Xloggc (sic!). And that
side effect is actually visible with "-XX:+PrintFlagsFinal".

So it seems for Java 6 there's no way around that. As soon as you (the
OP) use -Xloggc, the JVM activates TraceClassUnloading. This should not
happen in Java 7 or 8.


Actually it suffices to move the -XX:-TraceClassUnloading flag behind 
the -Xloggc flag.


Regards,

Rainer


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



Re: How to build tc-natvie for solaris sparc 64 bit using 64 bit java JDK

2015-12-12 Thread Rainer Jung

Am 11.12.2015 um 20:27 schrieb Nithesh Kb:

*HI, I'm using Solaris sparc 64 bit machine. i wanted to build tc native
using 64 bit version of java.*

*i installed java in my Solaris box by referring*
http://docs.oracle.com/javase/7/docs/webnotes/install/solaris/solaris-jdk.html

*when i check the*

/usr/jdk/jdk1.7.0_80/bin/java -version
java version "1.7.0_80"Java(TM) SE Runtime Environment (build
1.7.0_80-b15)Java HotSpot(TM) Server VM (build 24.80-b11, mixed mode)

*export JAVA_HOME=/usr/jdk/jdk1.7.0_80*

*./configure --with-apr=/usr/local/apr/bin/apr-1-config
--with-java-home=$JAVA_HOME --with-ssl=/usr/local/ssl
--prefix=$CATALINA_HOME*

*i'm able to build using this java 32 bit but 64 bit java is there in*

/usr/jdk/jdk1.7.0_80/bin/sparcv9/java -version
java version "1.7.0_80"Java(TM) SE Runtime Environment (build
1.7.0_80-b15)Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed
mode)

*So how do i tell my tc-native configure to use 64 bit java instead of* 32
bit java

Issue is here i can build with 32 bit java and tomcat will work. but in
production there is no 32 bit JRE only 64 bit JRE is there is if is use the
same 32 bit tc-native library i'l get

*wrong ELF class: ELFCLASS32 (Possible cause: architecture word width
mismatch)]*

So i must use 64 JDK for tc native build. please help me


From your other mail it seems you are using gcc to do the build. If so, 
make sure to include "-m64" in your CFLAGS for all components (OpenSSL, 
APT, tcnative). To build tcnative for 65 Bits, you need to have 64 Bit 
OpenSSL and 64 Bit APR first.


The 64 Bit part of the JVM will then be chosen automatically, not 
sparcv9 or similar needed.


Regards,

Rainer


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



Re: How to build tc-natvie for solaris sparc 64 bit using 64 bit java JDK

2015-12-12 Thread Rainer Jung

Am 12.12.2015 um 18:29 schrieb Nithesh Kb:

HI Rainer,
Interestingly i tried this as well.

*APR,*
*CC="cc" CFLAGS="-m64" LDFLAGS="-m64" ./configure*

*TC-native,*
*CC="cc" CFLAGS="-m64 -fPIC" LDFLAGS="-m64" ./configure
--with-apr=/usr/local/apr/bin/apr-1-config
--with-java-home=/usr/jdk/jdk1.7.0_80/ --with-ssl=/usr/local/ssl
--prefix=/tomcat*

*But i get this error,*

*ld: fatal: file /usr/local/ssl/lib/libssl.so: wrong ELF class: ELFCLASS32*
*ld: fatal: file /usr/local/ssl/lib/libcrypto.so: wrong ELF class:
ELFCLASS32*
*ld: fatal: file processing errors. No output written to
.libs/libtcnative-1.so.0.1.33*
 Error code 2*
*make: Fatal error: Command failed for target `libtcnative-1.la
'*
*Current working directory /tomcat/bin/tomcat-native-1.1.33-src/jni/native*


Does it mean my openssl is not 64 bit, actually i'm not sure about my
openssl architecture ?


Yes, that's why I suggested you should build OpenSSL as well. It will 
not have any further dependencies.


You can check bitness using

file /usr/local/ssl/lib/libssl.so
file /usr/local/ssl/lib/libcrypto.so

Pick yourself a 1.0.2e OpenSSl download, build it (with -m64) and 
install it into a separate directory. Check the bitness of the result 
with the "file" command. Then point tcnative at it when running its 
configure etc.


You are pretty close.

Note that there's also a more recent tcnative 1.2.2 and the versions 
1.3.34 and 1.2.3 are currently in the voting process, so will likely be 
released very soon. So once your build works, you might want to check 
for the recent version and redo the build. You can use the same APR and 
OpenSSL builds, so no need to redo them for the nex tcnative.


Regards,

Rainer

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



Re: REMOTE_USER mod_jk

2015-11-20 Thread Rainer Jung

Am 19.11.2015 um 14:32 schrieb Teresa Fasano:

With Apache/2.2.15 the REMOTE_USER is passed to the application (Jboss),
while with Apache/2.4.6 is lost.

In the log of the application we see this error: "REMOTE_USER variable
not assigned."


If you have a test system, you can set JkLogLevel to debug. On that log 
level, you should be able to see the REMOTE_USER forwarding in the 
mod_jk logs. First check how the line looks when using HTTPD 2.2. Then 
check, whether that info is present when using 2.4. If "yes", then your 
problem is on the Tomcat (configuration, webapp) side. If it is not 
present, then HTTPD 2.4 for some reason does not set REMOTE_USER and you 
have to check your 2.4 integration.


Regards,

Rainer


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



Re: mod_jk make error with OSX 10.11.1

2015-10-29 Thread Rainer Jung

Am 29.10.2015 um 03:59 schrieb Christopher Schultz:

Youngho,

On 10/28/15 10:35 PM, Youngho Cho wrote:

  Just before I upgrade to OSX 10.11.1

  And try to compile Apache mod_jk 1.2.41.

But the make is fail.

  YounghoiMac:native youngho$ sudo make

Making all in common
usr/share/apr-1/build-1/libtool --silent --mode=compile
/Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.11.xctoolchain/usr/bin/cc
-I. -I/usr/include/apache2 -arch x86_64 -DHAVE_CONFIG_H -DHAVE_APR
-I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.Internal.sdk/usr/include/apr-1
-I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.Internal.sdk/usr/include/apr-1
-arch x86_64 -DHAVE_CONFIG_H -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK
-DDARWIN_10 
-I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.Internal.sdk/usr/include/apr-1
-c jk_ajp12_worker.c -o jk_ajp12_worker.lo
In file included from jk_ajp12_worker.c:26:
In file included from ./jk_ajp12_worker.h:27:
In file included from ./jk_logger.h:27:
./jk_global.h:78:10: fatal error: 'apr_lib.h' file not found
#include "apr_lib.h"
  ^
1 error generated.
make[1]: *** [jk_ajp12_worker.lo] Error 1
make: *** [all-recursive] Error 1

---

  How can I fixed it ?

  Someone also have same trouble

  
https://stackoverflow.com/questions/33402932/tomcat-connectors-mod-jk-make-error#_=_


When you ran "configure", what options did you choose?


In addition to that question: when building mod_jk for the Apache web 
server 2.x, it uses the APR libraries, which are also used for the 
Apache web server. During the build it needs the header files for APR. 
Sometimes they must be installed with some developer package for APR. 
From the above it looks like your APR headers files (like apr_lib.h) 
should be located in 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.Internal.sdk/usr/include/apr-1 
but somehow they are not.


Regards,

Rainer


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



Re: [ANN] New committer: Martin Grigorov

2015-10-26 Thread Rainer Jung

Hi Martin,

Am 26.10.2015 um 15:35 schrieb Mark Thomas:

On behalf of the Tomcat committers I am pleased to announce that
Martin Grigorov (mgrigorov) has been voted in as a new Tomcat committer.

Please join me in welcoming him.


Long time no hear. Nice having you around here!

Regards,

Rainer


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



Re: [ANN] New committer: Ognjen Blagojevic

2015-10-25 Thread Rainer Jung

Am 24.10.2015 um 15:58 schrieb Mark Thomas:

On behalf of the Tomcat committers I am pleased to announce that
Ognjen Blagojevic (ognjen) has been voted in as a new Tomcat committer.

Please join me in welcoming him.


Congratulations and welcome to the team!

Rainer

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



Re: TCP connection vs Tomcat threads vs File Descriptors - please help

2015-10-17 Thread Rainer Jung

Am 17.10.2015 um 08:27 schrieb vicky:

Hi All,
can someone please help in understand  that how TCP connections are interlinked 
with the no. ofFile Descriptors & no of threads configured over a machine .
Setup details :OD - Centos 6Tomcat7Java 7
Recently i have faced an problem in while my application was having +20k TCP 
connections in TIME-WAIT state resulting in choking my application though no 
consumed threads & Files descriptors are pretty less than threshold.
1) I would like to understand that is there any limit that how many TCP 
connections a machine can open , IF YES then how to tune it .
2) Second query   , my understanding was every TCP connection will open one 
file  descriptor but in my currentsituation only 900 FD were used whereas the 
TCP_WAIT connections where +20K .Kindly suggest how do i comprehend this . How 
these are interlinked
3) If i configure 600 threads in server.xml for my HTTP connector & if i'm 
running that machine over 8 core cpu does that mean simultaneously 600 X 8 (cpu 
core) =4800 threads will be served by my tomcat ?


Let me give you an incomplete answer:

A TCP connection in state TIME_WAIT does no longer exist from the point 
of view of the application/Tomcat/Java etc. So it does not need any 
application resources like threads.


To understand TIME_WAIT, you should look for "TCP state diagram" in your 
favorite search engine or grab a copy of Steven's TCP/IP illustrated. 
You will find a picture like this:


http://www.cs.northwestern.edu/~agupta/cs340/project2/TCPIP_State_Transition_Diagram.pdf

(page 2)

There you will see, that an ESTABLISHED connection can only enter 
TIME_WAIT state on the side of the connection, that first started the 
connection shut down by sending a FIN packet. And on that side it will 
always go through TIME_WAIT state.


The default time during which a connection sits in TIME_WAIT on Linux 
seems to be 60, sometimes 120 seconds. So the total number of 
connections in that state is proportional to the number of connections 
per second that the local node starts closing.


Example: Assume you run 100 new connections per second and all of the 
are closed by the local node first. That means in 60 seconds 6000 
connections will pile up in state TIME_WAIT.


In addition, removing TIME_WAIT connections from the OS list is not done 
continuously but in regular intervals, like e.g. every 5 seconds. So the 
real numbers can be slightly higher.


Why are TIME_WAIT states bad? They don't need app resources, so why 
care? Because the increase the list of TCP connection states the OS has 
to manage and a huge number of such TIME_WAIT connections - a few 
10.000s - can make the IP stack slower.


The TIME_WAIT duration is not configurable for Linux only on some other 
Unixes. See the discussion at:


http://comments.gmane.org/gmane.linux.network/244411

For some time you had to live with it and the only things you could do was

- checking whether you could force more connections being closed by the 
remote side first


- reducing the number of connections per second by increasing connection 
reuse, so keeping connections around for a longer time instead of 
constantly creating new ones.


Both options would increase the need for app resources though, because 
the longer lifetime of established connections would often increase the 
number of threads needed.


Now some people recommend using net.ipv4.tcp_tw_reuse, but that tunable 
seems to only apply to outgoing connections. Other suggest using 
net.ipv4.tcp_tw_recycle, but that one seems to make problems if clients 
sit behind a NAT device.


See:

http://vincent.bernat.im/en/blog/2014-tcp-time-wait-state-linux.html

Other people suggest tuning 
net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait:


http://www.lognormal.com/blog/2012/09/27/linux-tcpip-tuning/

It could be, that this tunable will be replaced by 
nf_conntrack_tcp_timeout_time_wait in new kernels.


Regards,

Rainer

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



Re: Problems with tomcat-connectors-1.2.41 on 32bit linux

2015-08-26 Thread Rainer Jung

Am 26.08.2015 um 08:00 schrieb Falco Schwarz:

On Tue, Aug 25, 2015 at 5:13 PM, Rainer Jung rainer.j...@kippdata.de
wrote:


Am 25.08.2015 um 14:58 schrieb Falco Schwarz:


If I try to startup httpd though the following error occurs:

httpd: Syntax error on line 88 of /opt/apache/conf/alles/httpd.conf:
Cannot
load /opt/apache/modules/mod_jk.so into server:
/opt/apache/modules/mod_jk.so: undefined symbol: __sync_add_and_fetch_4



simply change the #elif line 436 e.g. to

#elif defined(JK_USE_GCC_ATOMICS)  defined(__GNUC__)  (__GNUC__  4 ||
(__GNUC__ == 4  __GNUC_MINOR__ = 1))


Since JK_USE_GCC_ATOMICS is not defined, the elif will be skipped and the
next option (APR atomics) will be used, but you can later switch back to
the GCC version by compiling with -DJK_USE_GCC_ATOMICS. We might add
something like this and make the define be chosen according to configure
flags (--disable-gcc-atomics). Or maybe we should even use a configure
check to detect real support for GCC atomics on the target platform.
users-h...@tomcat.apache.org



I switched the logic to better suit my needs, but that works:

#elif !defined(JK_NO_GCC_ATOMICS)  defined(__GNUC__)  (__GNUC__  4 ||
(__GNUC__ == 4  __GNUC_MINOR__ = 1))


So on our 32bit systems jk is built with:
CFLAGS='-DJK_NO_GCC_ATOMICS' ./configure --with-apxs=/opt/apache/bin/apxs

It would be nice if something like that (preferably a configure option)
would be built in. It would of course be even better if configure could
detect if gcc atomics work and decide whether to use them or not. Anyways,
thank you for your quick and very helpful response.


I added a configure check in

  http://svn.apache.org/viewvc?view=revisionrevision=1697985

and documented the problem in

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

You might want to cross check.

Thanks for helping!

Regards,

Rainer

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



Re: [ANN] Apache Tomcat Connectors 1.2.41 released

2015-08-25 Thread Rainer Jung

Am 24.08.2015 um 21:23 schrieb Mark Thomas:

On 24/08/2015 16:40, Alten, Jessica-Aileen wrote:



We'd love to provide Windows binaries for mod_jk, but they are a real
pain in the neck to actually build: they require very specific build
environment, and the library must be built in such a way that it's
compatible with the web server in which it's running (e.g. httpd
1.3/2.2/2.4 or IIS 5/6/7/8/9, proper architecture (32/63) and chipset
(x86/x86-64/itanium/alpha). It's gotten to the point where it's tough
to provide all of those combinations with any regularity.


I understand that it is difficult - perhaps too difficult for the developers of 
this module, but the average Windows admin or Java programmer should do this? ;)
There were binaries of this module at least for the last 10 years!
I'm very disappointed on this attitude. You are closing out the whole 
Windows/IIS world.


Yes, we (the Tomcat community) has a problem here.

We needed a jk release to address a security issue that had been made
public before we were ready. The developers that normally work on jk
have been quiet lately so one of the other Tomcat developers stepped up
to do the release. The source code side of things is relatively simple
but the binaries are not and the document build process is not
sufficient to generate a binary release.




This is the documented build process for ISAPI:
http://svn.apache.org/viewvc/tomcat/jk/trunk/native/iis/README?view=annotate

We don't have the equivalent 'How to build a release' documentation.

It is not at all clear how release builds (which options have been used,
what have they been compiled with / against?) have been built in the
past so it is next to impossible to reproduce a similar build.


Unfortunately, I don't believe they provide builds for the ISAPI
redirector for IIS. If that's what you need... umm...


Umm - yes - this is what I need.


There are a couple of options:

Hope the jk committers provide enough information to document the
release process so anyone can run it.

Figure out how to build something that works for you and share that with
the Tomcat community so anyone can build it. Then one of the active
Tomcat committers will be able to include the binary in the next release
(and provide an official binary for this release).


I just tried the isapi_redirector build using VC 2010 and the 
Makefile.amd64. No additional flags, just setting up the compiler with 
setenv /Release /x64 (as usual for MSVC) before running it. Then 
changing into the iis src directory and running nmake -f 
Makefile.amd64 which results in Release_amd64/isapi_redirect.dll (the 
IIS plugin) and Release_amd64/isapi_redirect.pdb (the symbol file needed 
for debugging). The build was done on Windows 7 64 Bits Professional, 
but I think that is less important then the MSVC version used.


Since I'm using the 2010 compiler, the produced binary has a dependency 
on the MSVCR100.dll runtime library, which must be installed 
independently on the system if not yet available, but at least there are 
redistributables for it provided by Microsoft, see 
https://www.microsoft.com/en-US/download/details.aspx?id=. I have 
checked the dependency using the depends.exe dependency walker 
(similar to Unix/Linux ldd), see http://www.dependencywalker.com/.


I'd hope that the usual runtime library compatibility issues are not the 
problematic for the ISAPI redirector as for mod_jk on Windows. Maybe IIS 
can cope better with plugins using different versions of the runtime 
libs. I definitely don't have a version 6 compiler to prevent using the 
newer runtime libs.


@Jessica: which CPU architecture are you using: x86 (32 Bit), x64 (64 
Bits) or even Itanium 64? Which OS version do you have? If you are 
willing to test, I can provide an example binary from which we might 
learn, how well it works and whether that type of build is suitable for 
others as well.


Regards,

Rainer


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



Re: Problems with tomcat-connectors-1.2.41 on 32bit linux

2015-08-25 Thread Rainer Jung

Am 25.08.2015 um 14:58 schrieb Falco Schwarz:

Hi there,

I tried to update the connectors to the most recent update but I am stuck
with error messages. Just a few background information on the
infrastructure used:

httpd: 2.2.31
OpenSSL: 1.0.2.d
mod_jk: 1.2.41

Kernel: 3.0.101-0.47.52-pae
OS: SLES 11 SP3 (32bit)
gcc: (SUSE Linux) 4.3.4 [gcc-4_3-branch revision 152973]

httpd configure: ./configure --prefix=/opt/apache
--sysconfdir=/opt/apache/build --enable-mods-shared=all ssl ldap cache
proxy authn_alias authnz_ldap dav_lock --with-mpm=prefork
--with-included-apr --with-pcre --with-ldap --with-ssl=/opt/apache/openssl

jk configure: ./configure --with-apxs=/opt/apache/bin/apxs

configure, make and install runs without any errors. If I try to startup
httpd though the following error occurs:

httpd: Syntax error on line 88 of /opt/apache/conf/alles/httpd.conf: Cannot
load /opt/apache/modules/mod_jk.so into server:
/opt/apache/modules/mod_jk.so: undefined symbol: __sync_add_and_fetch_4


When I added the use of atomics, I checked for the minimal GCC version 
to support it. At that time I didn't notice, that GCC originally had 
only support for some architectures, and for all other architectures 
compiles in a call to a function named __sync_add_and_fetch_4(), which 
it does not implement itself.


There's a couple of options:

- use a newer GCC, it might support x86 atomics. But I guess you'd like 
to stick to your SLES provided GCC, so this probably is not an option 
for you.


- As a workaround fall back to what APR provides as atomics. In file 
common/jk_global.h you could comment out the following lines with a 
leading //:


436 #elif defined(__GNUC__)  (__GNUC__  4 || (__GNUC__ == 4  
__GNUC_MINOR__ = 1))

437 #define JK_ATOMIC_INCREMENT(x) __sync_add_and_fetch(x, 1)
438 #define JK_ATOMIC_DECREMENT(x) \
439 do {\
440 if (__sync_sub_and_fetch(x, 1)  0) __sync_add_and_fetch(x, 1);\
441 } while (0)

or simply change the #elif line 436 e.g. to

#elif defined(JK_USE_GCC_ATOMICS)  defined(__GNUC__)  (__GNUC__  4 
|| (__GNUC__ == 4  __GNUC_MINOR__ = 1))



Since JK_USE_GCC_ATOMICS is not defined, the elif will be skipped and 
the next option (APR atomics) will be used, but you can later switch 
back to the GCC version by compiling with -DJK_USE_GCC_ATOMICS. We might 
add something like this and make the define be chosen according to 
configure flags (--disable-gcc-atomics). Or maybe we should even use a 
configure check to detect real support for GCC atomics on the target 
platform.


Let us know how it works.

Thanks for reporting the problem,

Rainer

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



Re: [ANN] Apache Tomcat Connectors 1.2.41 released

2015-08-25 Thread Rainer Jung

Am 25.08.2015 um 20:41 schrieb Christopher Schultz:


On 8/25/15 11:49 AM, Rainer Jung wrote:



I just tried the isapi_redirector build using VC 2010 and the
Makefile.amd64. No additional flags, just setting up the compiler
with setenv /Release /x64 (as usual for MSVC) before running it.
Then changing into the iis src directory and running nmake -f
Makefile.amd64 which results in Release_amd64/isapi_redirect.dll
(the IIS plugin) and Release_amd64/isapi_redirect.pdb (the symbol
file needed for debugging). The build was done on Windows 7 64 Bits
Professional, but I think that is less important then the MSVC
version used.

Since I'm using the 2010 compiler, the produced binary has a
dependency on the MSVCR100.dll runtime library, which must be
installed independently on the system if not yet available, but at
least there are redistributables for it provided by Microsoft, see
https://www.microsoft.com/en-US/download/details.aspx?id=. I
have checked the dependency using the depends.exe dependency
walker (similar to Unix/Linux ldd), see
http://www.dependencywalker.com/.

I'd hope that the usual runtime library compatibility issues are
not the problematic for the ISAPI redirector as for mod_jk on
Windows. Maybe IIS can cope better with plugins using different
versions of the runtime libs. I definitely don't have a version 6
compiler to prevent using the newer runtime libs.


I believe we go through great pains with tcnative to build against
MSVCRT.DLL because, evidently, that is guaranteed to be available on
any modern Windows system (I think that means win2k/NT4.0+... possibly
back to win95). This reduces the installation complexity for the end
user, but requires lots of work on the part of the packager.

I'd like to know what the community thinks about building against
MSVCRT100.DLL, which is essentially the same thing and I would imagine
that everyone has that DLL these days. (The issue, of course, is that
we can't bundle it ourselves due to licensing restrictions.)

Can we statically-link instead of using the DLL? Would that be very
stupid? Seems like it would solve everything.


AFAIR the original problem about the msvc runtime libs is, that 
different versions are not compatible with each other. The one needed by 
MSVC 6 (msvcrt.dll) is compatible with newer ones (the ones with numbers 
in their name), but newer ones for different numbers are not compatible 
with each other. Using different numbered versions in the same process 
can lead to crashes etc.


This is a problem, if your process consists of different pieces compiled 
with different MSVC versions and thus loading different msvc libs. One 
example is the Apache web server provided/compiled by someone and a 
module provided/compiled by someone else. Another might be the jvm 
(java.exe) and a native library loaded into it. For instance the 
java.dll contained in Java 1.8.0_51 and in 1.7.0_80 load msvcr100.dll. 
So when Oracle updates their tool chain, they might switch to a newer 
msvc runtime lib version.


I'd hope that this is less likely to happen for IIS, but I haven't yet 
checked, whether IIS on newer systems itself still only has a dependency 
on MSVCRT.dll or also on newer versions. I hope not. Still there could 
be a problem if people add other extensions introducing such 
incompatibilities.


So I think this is less about end user installation hassle. Adding the 
msvc redistribution once to systems isn't that uncommon as a task on 
windows. It is more about being compatible with msvc runtime libs loaded 
by other components inside the same process. The MS tool chain isn't 
suited to support modular software that's combined from different suppliers.


For reference see e.g.

https://msdn.microsoft.com/en-us/library/abx4dbyh.aspx

or

https://msdn.microsoft.com/en-us/library/abx4dbyh%28v=vs.100%29.aspx

for MSVC 2010

(especially the paragraph starting with If you have more than one DLL) and

https://msdn.microsoft.com/en-us/library/ms235460.aspx

I think from those descriptions the compatibility problem for tcnative 
might be void, because likely we don't pass native objects across the 
boundary, just references which are only natively used inside tcnative, 
not in the JVM anywhere else.


For mod_jk the problem is harder, because there's a lot of data passed 
between httpd and mod_jk.so. As someone wrote: The same holds true in 
case of simple C structures too. Although it is unlikely that, say for 
an example, the order of struct tm or struct FILE, would change from one 
version of Visual Studio to another, one can’t reply on such 
assumptions. For the isapi redirector I'm undecided how likely a 
problem is.


Regards,

Rainer

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



Re: [ANN] Apache Tomcat Connectors 1.2.41 released

2015-08-25 Thread Rainer Jung

Am 25.08.2015 um 23:59 schrieb Christopher Schultz:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Rainer,

On 8/25/15 5:53 PM, Rainer Jung wrote:

Am 25.08.2015 um 20:41 schrieb Christopher Schultz:


On 8/25/15 11:49 AM, Rainer Jung wrote:



I just tried the isapi_redirector build using VC 2010 and the
Makefile.amd64. No additional flags, just setting up the
compiler with setenv /Release /x64 (as usual for MSVC) before
running it. Then changing into the iis src directory and
running nmake -f Makefile.amd64 which results in
Release_amd64/isapi_redirect.dll (the IIS plugin) and
Release_amd64/isapi_redirect.pdb (the symbol file needed for
debugging). The build was done on Windows 7 64 Bits
Professional, but I think that is less important then the MSVC
version used.

Since I'm using the 2010 compiler, the produced binary has a
dependency on the MSVCR100.dll runtime library, which must be
installed independently on the system if not yet available, but
at least there are redistributables for it provided by
Microsoft, see
https://www.microsoft.com/en-US/download/details.aspx?id=.
I have checked the dependency using the depends.exe
dependency walker (similar to Unix/Linux ldd), see
http://www.dependencywalker.com/.

I'd hope that the usual runtime library compatibility issues
are not the problematic for the ISAPI redirector as for mod_jk
on Windows. Maybe IIS can cope better with plugins using
different versions of the runtime libs. I definitely don't have
a version 6 compiler to prevent using the newer runtime libs.


I believe we go through great pains with tcnative to build
against MSVCRT.DLL because, evidently, that is guaranteed to be
available on any modern Windows system (I think that means
win2k/NT4.0+... possibly back to win95). This reduces the
installation complexity for the end user, but requires lots of
work on the part of the packager.

I'd like to know what the community thinks about building
against MSVCRT100.DLL, which is essentially the same thing and I
would imagine that everyone has that DLL these days. (The issue,
of course, is that we can't bundle it ourselves due to licensing
restrictions.)

Can we statically-link instead of using the DLL? Would that be
very stupid? Seems like it would solve everything.


AFAIR the original problem about the msvc runtime libs is, that
different versions are not compatible with each other. The one
needed by MSVC 6 (msvcrt.dll) is compatible with newer ones (the
ones with numbers in their name), but newer ones for different
numbers are not compatible with each other. Using different
numbered versions in the same process can lead to crashes etc.


I'm pretty sure that fprintf is compatible across versions, no? But


Ha! Not far from one of the real problem examples:

http://www.syndicateofideas.com/posts/fighting-the-msvcrt-dll-hell

And MS says in 
http://blogs.msdn.com/b/vcblog/archive/2014/06/10/the-great-crt-refactoring.aspx:


The best example of this maintainability problem could be found in 
the old implementation of the printf family of functions. The CRT 
provides 142 different variations of printf, but most of the behavior is 
the same for all of the functions, so there are a set of common 
implementation functions that do the bulk of the work. These common 
implementation functions were all defined in output.c in the CRT 
sources(1). This 2,696 line file had 223 conditionally compiled regions 
of code (#ifdef, #else, etc.), over half of which were in a single 1,400 
line function. This file was compiled 12 different ways to generate all 
of the common implementation functions. Even with the large number of 
tests that we have for these functions, the code was exceedingly brittle 
and difficult to modify.


But it seems, if this old blog describes what actually happened in the 
meantime, that starting with version 14 they moved from incompatible 
versions to using backwards compatible libs. Maybe some light at the 
horizon.



the version-less DDL is reliably available on all modern systems,
right? That's the real issue: is the library available on the target
system. Using the version-less library gives us the widest
compatibility without requiring the user to install one of the MSVC++
redistributable packages.


This is a problem, if your process consists of different pieces
compiled with different MSVC versions and thus loading different
msvc libs.


Oh, so it might depend upon whatever IIS uses. So.. how can we tell
which MSVC was used by a particular IIS version?


I'd hope that this is less likely to happen for IIS, but I haven't
yet checked, whether IIS on newer systems itself still only has a
dependency on MSVCRT.dll or also on newer versions. I hope not.
Still there could be a problem if people add other extensions
introducing such incompatibilities.

So I think this is less about end user installation hassle. Adding
the msvc redistribution once to systems isn't that uncommon as a
task on windows. It is more about being compatible

Re: tcnative CVE-2015-4000 (Logjam)

2015-06-12 Thread Rainer Jung

Am 12.06.2015 um 04:01 schrieb Christopher Schultz:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Arthur,

On 6/11/15 4:34 PM, Arthur Ramsey wrote:

On 06/11/2015 02:35 PM, Christopher Schultz wrote: Arthur,

On 6/11/15 2:14 PM, Arthur Ramsey wrote:

Is anyone aware of a way to mitigate the Logjam attack with
tomcat 7 and java 7?

Disable DHE_EXPORT on the server?

I believe I have, but Qualys SSL Server Test still fails me on
the Logjam check.



SSLCipherSuite=ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SH

A256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-A
ES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-
SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128
- -SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-
SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-
DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES25
6-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK

You



also have DHE-* ciphers in there, which is probably the problem.
Remove those and I think Qualys will be happier. Really, who is using
DHE in the first place?


I use tcnative and openssl-1.0.2a both compiled from source
in production today, but I would be open to JSSE too.  I
believe I need Java 8 to mitigate CVE-2015-4000 with JSSE.

Why?

See
http://stackoverflow.com/questions/30352105/how-to-set-custom-dh-grou

p-in-java-sslengine-to-prevent-logjam-attack

Understood.



I thought you just wanted to remove the EXPORT and DHE
ciphers in general. Increasing the number of bits in the DH parameters
will in fact require an upgrade.


I don't see anyway to use a unique 2048-bit or greater DH
group with tcnative currently.

I believe you are correct; there is a bug in BZ:
https://bz.apache.org/bugzilla/show_bug.cgi?id=56108

It looks like 1.1.34 will have this feature. You can build the
current trunk of the 1.1 branch and probably be okay.

Thanks, I'll give it a try.  Scary to use in production, but it
may be my best answer.



I'm not sure if there is anything I can do at compile time.
I'd rather not change the cipher suites as I want to maintain
browser support.

You should disable EXPORT certificates no matter what. Or were you
talking about the DH parameters?

I was talking about DH parameters.



My server configuration passed the Qualys SSL Server Test
with flying colors until Logjam, so I would be worried about
regressions on other security fixes if I used JSSE.

-chris


- -chris


There's two parts under Logjam:

- a downgrade attack that makes the real attack very feasible. The 
downgrade only works if client and derver support the export ciphers (it 
is not necessary that they are the preferred ciphers) and the attacker 
is an active man-in-the-middle, ie. she can observe and change the 
communication. In this case the encryption can be forced to use a 512 
Bit key and is relatively easy to break.


To mitigate the downgrade attack, it should be posible to just disable 
export ciphers on the server side, which is doable per configuration.


- in addition for non-export ciphers, key length of 768 bits and 1024 
bits are assumed to be atackable depending on the computing ressources 
tha attacker has at her hand. 768 is expected to be breakable using 
academic computing ressources, 1024 bits using national computing resources.


To mitigate this, one should use longer keys. I think that is not 
possible with current tcnative 1.1.33. Only the head of 1.1 has code to 
allow that. This code would


  - use a longer key automatically, if the key in the server 
certificate is longer. E.g. a 2048 bit RSA key would lead to using also 
a 2048 bit DHE key automatically. This 2048 DH params are standard DH 
params but should nevertheless be safe due to their length.


  - allows to add custom DH params to the certificate file to choose 
completely custom DH params.


With existing 1.1.33 you can choose your cipher suite, so that non-DHE 
ciphers come first and set SSLHonorCipherOrder such that the client 
chooses the first matching cipher and DHE will likely not be used, only 
by client who do not support a cipher to the left of DHE in your cipher 
list.


Note that old Java versions as clients (6, maybe 7 depending on patch 
level?) have a problem with DHE keys longer than 768 or 1024 bits 
(depending on JVM details). So by mitigating Logjam you might run into 
compatibility issues with those.


It would be interesting to know, what details SSLLabs tell you, e.g. if 
they say you are vulnerable to the export downgrade attack (really bad), 
or just to your DH params should be longer. You can use the OpenSSL 
commandline client in version 1.0.2 to check, what param length a 
handshake results in:


openssl s_client -connect www.example.com:443 -cipher EDH | \
   grep Server Temp Key

See: https://www.openssl.org/blog/

Regards,

Rainer


Re: Http 2 support in Tomcat

2015-05-15 Thread Rainer Jung

Am 15.05.2015 um 20:43 schrieb PerfGuru:

Thanks Mark  Chris this is a very informative. I am using a httpd that 
supports http/2 and wow is it impressive. Sorry, I had to stop using Apache/Tomcat 
to use it but the performance and bandwidth gains are so nice it is addicting and 
my users have noticed. I will look into jre/jdk 9 and ask Oracle if servlet 4 is in 
the EA's. I would like to stay with http/2 rather than go to websockets but I am an 
early adaptor and if it is stable and has servlet 4 with http/2 I will give it a 
try and let you know the results. Best Regards,-Tony


Note that web socket and HTTP/2 serve very different purposes. Web 
sockets provide you basically with a socket you can use for setting up 
your own protocol and get rid of request/response semantics. Web socket 
allow to set up asynchoneous communication.


HTTP/2 more or less has the same request/response semantics as HTTP. It 
is onyl a more efficient implementation of that by combining multiple 
request/response streams into one TCP connection, using header 
compression etc. etc. HTTP/2 is still synchroneous. Yes, there is a 
notion of server push, but push in HTTP/2 is very different from what 
one would name a push in the web socket world.


I think it would be better to clearly keep the two terms web socket and 
HTTP/2 separated.


Regards,

Rainer




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



Re: Tomcat Connectors release

2015-05-14 Thread Rainer Jung

Am 14.05.2015 um 15:58 schrieb George Stanchev:

Hello,

What is the schedule for Connectors release? Is a release scheduled when a 
critical mass of issues fixed or a major problem is resolved or a regular 
time-based release?


It is overdue. I'm heading for it during the next 7 days.

Regards,

Rainer


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



Re: AJP config questions

2015-05-14 Thread Rainer Jung

Am 14.05.2015 um 23:58 schrieb Jeffrey Janner:

Guys, it's been a long time since I did any work with AJP, but it looks like 
something I'll be implementing soon.
I have a couple of basic questions, mostly related to ProxyPassReverse, but 
also one related to SSL.

I know to turn on mod_proxy and mod_proxy_ajp and  a simple ProxyPass where the source 
and dest paths match, i.e. both are /foo.  The question is if they differ.  
The httpd docs give this example:

Rewriting Proxied Path
ProxyPass /apps/foo ajp://backend.example.com:8009/foo
ProxyPassReverse /apps/foo http://www.example.com/foo

but don't mention if you need to turn on the RewriteEngine.


No you don't. ProxyPass and ProxyPassReverse and also any other Proxy* 
directive are implemented without using mod_rewrite.



Also, the second line doesn't look correct.  Shouldn't it be 
http://www.example.com/app/foo?


No. ProxyPass is used when mapping and transforming a request. 
ProxyPassReverse is used when mapping the LocatioN header *if* it is 
part of the response. In that case the response is a HTTP redirect and 
location points to the new address. Your backend will likely use its own 
address as it knows it. The backend (servlet enfine) does not know about 
ajp://backend.example.com. When using AJP, the servlet engine uses the 
web server protocol, host name and port to build a self-referential URL, 
but will use the context path that is really used on the backend.



BTW: we don't seem to be able to get that to work.
ProxyPass /myapp ajp://localhost:8009/myapp  works, but
ProxyPass /app ajp://localhost:8009/myapp does not work, and we've tried 
various iterations of ProxyPassReverse with it.


hard to tell, because you haven't said what does not work means, and 
you now also switched from a previous incomplete example using a 
balancer to another incomplete one without a balancer.


You can test ProxyPass first, then ProxyPassReverse. ProxyPassReverse 
does not influence, whether your request is forwarded and how it will 
look like at the backend. It only changes an optional Locatoin header in 
the response. So if you look at your response with a client that doesn't 
follow redirects, you can check, whether your requests hits the backend, 
you get back a response and whether it looks like what you want.


Note that if links embedded in your responses are wrong (e.g. point at 
/myapp instead of /app) then things get messy and you would need to use 
and configure mod_substitute or mod_sed or mod_proxy_html to scan 
through all of your responses and dynamically replace the links in it.


You might also be interested in ProxyPassReverseCookiePath, which fixes 
path attributes of cookies, so again a response header only thing.



What's the best way to handle ROOT.war, assuming there are other webapps to 
deploy as well?


I don't understad this question.


What if I don't want ROOT.war, but want to send / to a specific webapp?


ProxyPass / ajp://localhost/myapp/


SSL Question:
Since our web.xml is configured to redirect all requests to SSL in the 
security-constraints area, how does that effect the options that need to be 
supplied in the connector?  Right now, we just have the basic config as it comes in 
the initial conf.xml.


I can't tell what how does that effect the options that need to be 
supplied in the connector means, because I don't know what result you 
want to get.


In general ajp itself is always non-encrypted. Whether the backend sends 
a redirect to an https URL due to the security-constraint or not depends 
on whether you already talk https to the web server or not. If you 
already use https then ajp transports this information via ajp and the 
backend will not issue a redirect. If you talk http to the web server, 
then the security-constraint will issue a redirect. If the context path 
in the redirect is wrong, ProxyPassReverse can fix it.



Sorry for being a newbie on this, but the last time I messed with Apache proxy 
was 4.0 and then I used JK.


NP. Just keep in mind, that mod_jk and mod_proxy_ajo use the same AJP 
protocol. What differs is how it works to change path segments in 
requests, responses and headers. mod_proxy has specific directives for 
that, mod_jk not.


Although not describing mod_proxy, the page

http://tomcat.apache.org/connectors-doc/generic_howto/proxy.html

might be helpful. Where mod_jk and mod_proxy differ a lot is the URL 
Rewriting part, the AJP as a Solution is the same or at least very 
similar.


Regards,

Rainer

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



Re: AJP config questions

2015-05-14 Thread Rainer Jung

Am 15.05.2015 um 02:11 schrieb Rainer Jung:

Am 14.05.2015 um 23:58 schrieb Jeffrey Janner:

Guys, it's been a long time since I did any work with AJP, but it
looks like something I'll be implementing soon.
I have a couple of basic questions, mostly related to
ProxyPassReverse, but also one related to SSL.

I know to turn on mod_proxy and mod_proxy_ajp and  a simple ProxyPass
where the source and dest paths match, i.e. both are /foo.  The
question is if they differ.  The httpd docs give this example:

Rewriting Proxied Path
ProxyPass /apps/foo ajp://backend.example.com:8009/foo
ProxyPassReverse /apps/foo http://www.example.com/foo

but don't mention if you need to turn on the RewriteEngine.


No you don't. ProxyPass and ProxyPassReverse and also any other Proxy*
directive are implemented without using mod_rewrite.


Also, the second line doesn't look correct.  Shouldn't it be
http://www.example.com/app/foo?


No. ProxyPass is used when mapping and transforming a request.
ProxyPassReverse is used when mapping the LocatioN header *if* it is
part of the response. In that case the response is a HTTP redirect and
location points to the new address. Your backend will likely use its own
address as it knows it. The backend (servlet enfine) does not know about
ajp://backend.example.com. When using AJP, the servlet engine uses the
web server protocol, host name and port to build a self-referential URL,
but will use the context path that is really used on the backend.


I should probably add: ProxyPassReverse maps from right to left. So

ProxyPassReverse /apps/foo http://www.example.com/foo

takes any Location header whose value starts with 
http://www.example.com/foo; and then removes that value, sticks 
/apps/foo in front instead and adds protocol, host and port according 
to the local Apache VHost that forwarded the request.



BTW: we don't seem to be able to get that to work.
ProxyPass /myapp ajp://localhost:8009/myapp  works, but
ProxyPass /app ajp://localhost:8009/myapp does not work, and we've
tried various iterations of ProxyPassReverse with it.


hard to tell, because you haven't said what does not work means, and
you now also switched from a previous incomplete example using a
balancer to another incomplete one without a balancer.

You can test ProxyPass first, then ProxyPassReverse. ProxyPassReverse
does not influence, whether your request is forwarded and how it will
look like at the backend. It only changes an optional Locatoin header in
the response. So if you look at your response with a client that doesn't
follow redirects, you can check, whether your requests hits the backend,
you get back a response and whether it looks like what you want.

Note that if links embedded in your responses are wrong (e.g. point at
/myapp instead of /app) then things get messy and you would need to use
and configure mod_substitute or mod_sed or mod_proxy_html to scan
through all of your responses and dynamically replace the links in it.

You might also be interested in ProxyPassReverseCookiePath, which fixes
path attributes of cookies, so again a response header only thing.


What's the best way to handle ROOT.war, assuming there are other
webapps to deploy as well?


I don't understad this question.


What if I don't want ROOT.war, but want to send / to a specific webapp?


ProxyPass / ajp://localhost/myapp/


SSL Question:
Since our web.xml is configured to redirect all requests to SSL in the
security-constraints area, how does that effect the options that
need to be supplied in the connector?  Right now, we just have the
basic config as it comes in the initial conf.xml.


I can't tell what how does that effect the options that need to be
supplied in the connector means, because I don't know what result you
want to get.

In general ajp itself is always non-encrypted. Whether the backend sends
a redirect to an https URL due to the security-constraint or not depends
on whether you already talk https to the web server or not. If you
already use https then ajp transports this information via ajp and the
backend will not issue a redirect. If you talk http to the web server,
then the security-constraint will issue a redirect. If the context path
in the redirect is wrong, ProxyPassReverse can fix it.


Sorry for being a newbie on this, but the last time I messed with
Apache proxy was 4.0 and then I used JK.


NP. Just keep in mind, that mod_jk and mod_proxy_ajo use the same AJP
protocol. What differs is how it works to change path segments in
requests, responses and headers. mod_proxy has specific directives for
that, mod_jk not.

Although not describing mod_proxy, the page

http://tomcat.apache.org/connectors-doc/generic_howto/proxy.html

might be helpful. Where mod_jk and mod_proxy differ a lot is the URL
Rewriting part, the AJP as a Solution is the same or at least very
similar.

Regards,

Rainer


-
To unsubscribe, e-mail: users-unsubscr

Re: File descriptors peaks with latest stable build of Tomcat 7

2015-04-22 Thread Rainer Jung

Am 22.04.2015 um 00:08 schrieb André Warnier:
...

The OP has a complex setup, where we are not even sure that the various
connections in various states are even related directly to Tomcat or not.
Graphically, we have this :

client -- TCP -- nginx -- TCP -- Tomcat -- webapp -- TCP --
external servers

The output of netstat shows all the connections and their state, at the
OS level.  Even assuming that nginx runs on a separate host, that still
leaves the possibility that most of the connections in CLOSE_WAIT state
for example, would be connections between the webapps and external
servers, having not much to do with Tomcat per se.
But of course they use fd's and resources, just like the others. And for
lsof, they would appear as belonging to the Tomcat process.


See my response from 1.5 days ago which contains the individual 
statistics for each of the above three TCP parts.


Regards,

Rainer

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



Re: File descriptors peaks with latest stable build of Tomcat 7

2015-04-22 Thread Rainer Jung

Am 22.04.2015 um 11:38 schrieb André Warnier:

Rainer Jung wrote:

See my response from 1.5 days ago which contains the individual
statistics for each of the above three TCP parts.



Yes, sorry Rainer, I did not read that as carefully as I should have.


No worries at all. Lots of stuff going back and forth.

Rainer


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



Re: File descriptors peaks with latest stable build of Tomcat 7

2015-04-22 Thread Rainer Jung

Am 22.04.2015 um 11:58 schrieb Thomas Boniface:

What concerns me the most is the CLOSE_WAIT on tomcat side because when an
fd peak appears the web application appears to be stuck. It feels like all
its connections are consumed and none can be established from nginx
anymore. Shouldn't the CLOSE_WAIT connection be recycled to received new
connections from nginx ?


Just to clarify:

Every connection has two ends. In netstat the local end is left, the 
remote end is right. If a connection is between processes both on the 
same system, it will be shown in netstat twice. Once for each endpoint 
being the local side.


CLOSE_WAIT for a connection between a (local) and b (remote) means, that 
b has closed the connection but not a. There is no automatism for a 
closing it because b has closed it. If CLOSE_WAIT pile up, then the idea 
of b and a when a connection should no longer be used are disparate. 
E.g. they might have very different idle timeouts (Keep Alive Timeout on 
HTTP speak), or one observed a problem that the other didn't observe.


When I did the counting for

  Count   IP:Port ConnectionState
   8381127.0.0.1:8080 CLOSE_WAIT

the 127.0.0.1:8080 was left in netstat output, so local. It means 
the other side (whatever is the other side of the connection, likely 
nginx) has closed the connection alardy, but not Tomcat.


And the total number of those connections:

  Count   IP:Port ConnectionState
   8381127.0.0.1:8080 CLOSE_WAIT
   1650127.0.0.1:8080 ESTABLISHED

indeed sums up to the default maxConnections 1 mentioned by Chris.

What I do not understand is, that the same connections looked at from 
nginx being the local end, show a totally different statistics:


  Count   IP:Port ConnectionState
  20119127.0.0.1:8080 SYN_SENT
   4692127.0.0.1:8080 ESTABLISHED
488127.0.0.1:8080 FIN_WAIT2
122127.0.0.1:8080 TIME_WAIT
 13127.0.0.1:8080 FIN_WAIT1

But maybe that's a problem to solve after you fixed the CLOSED_WAIT (or 
the 1000 limit) and redo the whole observation.


Pretty big numbers you habe ...

Regards,

Rainer

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



Re: Getting Apache 2.2.29 to work with tomcat 8.0.21 using mod_jk 1.2.40 on a mac

2015-04-22 Thread Rainer Jung

Am 22.04.2015 um 11:33 schrieb Mayuresh:

Hi Gurus,

i am trying to make this combination and am stumbled at a place. After a
lot of searching and experimenting I finally decided to post this question
here.

I am trying to load a page which loads just fine directly on tomcat.
However if I try to load it through the Apache web server, it fails with a
502 on apache (400 on tomcat)

For an unsuccessful request through apache I see the following in the logs,
where all the headers seem to be garbled:
22-Apr-2015 01:53:46.656 FINE [http-nio-8080-exec-1]
org.apache.tomcat.util.modeler.BaseModelMBean.preRegister preRegister
org.apache.coyote.RequestInfo@616702aa
Catalina:type=RequestProcessor,worker=http-nio-8080,name=HttpRequest1
22-Apr-2015 01:53:46.657 FINE [http-nio-8080-exec-1]
org.apache.coyote.http11.AbstractNioInputBuffer.parseRequestLine Received
[^R4^B^G^B^B^@^HHTTP/1.1^@^@^M/greeting/abc^@^@
  10.0.0.23^@ÿÿ^@^Posxltmkshi.local^@ü^@^@
  ^K^@^Uosxltmkshi.local:9980^@ ^F^@
keep-alive^@ ^L^@^Hno-cache^@^@^MCache-Control^@^@^Hno-cache^@
^A^@Jtext/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8^@
^N^@wMozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/42.0.2311.90
Safari/537.36^@^@^OAccept-Encoding^@^@^Sgzip, deflate,
sdch^@^@^OAccept-Language^@^@^Nen-US,en;q=0.8^@^@^OX-Forwarded-For^@^@^L14.102.224.6^@
^H^@^A0^@
^@^OAJP_REMOTE_PORT^@^@^E55806^@
^@^PJK_LB_ACTIVATION^@^@^CACT^@ÿ]


mod_jk talks the AJP protocol, so you need to connect it to the Tomcat 
AJP connector. You instead connected it to the Tomcat HTTP connector. 
You probably have configured port 8080 in the mod_jk config instead of 
8009 (default AJP port in Tomcat default server.xml).


Regards,

Rainer


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



Re: File descriptors peaks with latest stable build of Tomcat 7

2015-04-20 Thread Rainer Jung

Am 20.04.2015 um 14:11 schrieb Thomas Boniface:

Hi,

I have tried to find help regarding an issue we experience with our
platform leading to random file descriptor peaks. This happens more often
on heavy load but can also happen on low traffic periods.

Our application is using servlet 3.0 async features and an async connector.
We noticed that a lot of issues regarding asynchronous feature were fixed
between our production version and the last stable build. We decided to
give it a try to see if it improves things or at least give clues on what
can cause the issue; Unfortunately it did neither.

The file descriptor peaks and application blocking happens frequently with
this version when it only happens rarely on previous version (tomcat7
7.0.28-4).

Tomcat is behind an nginx server. The tomcat connector used is configured
as follows:

We use an Nio connector:
Connector port=8080 protocol=org.apache.coyote.
http11.Http11NioProtocol
   selectorTimeout=1000
   maxThreads=200
   maxHttpHeaderSize=16384
   address=127.0.0.1
   redirectPort=8443/

In catalina I can see some Broken pipe message that were not happening with
previous version.

I compared thread dumps from server with both the new and old version of
tomcat and both look similar from my stand point.

My explanation may not be very clear, but I hope this gives an idea how
what we are experiencing. Any pointer would be welcomed.


If the peaks happen long enough and your platforms has the tools 
available you can use lsof to look for what those FDs are - or on Linux 
looking at ls -l /proc/PID/fd/* (PID is the process PID file) - or on 
Solaris use the pfiles command.


If the result is what is expected, namely that by far the most FDs are 
coming from network connections for port 8080, then you can check via 
netstat in which connection state those are.


If most are in ESTABLISHED state, then you/we need to further break down 
the strategy.


Regards,

Rainer


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



Re: File descriptors peaks with latest stable build of Tomcat 7

2015-04-20 Thread Rainer Jung

Am 20.04.2015 um 15:41 schrieb Rainer Jung:

Am 20.04.2015 um 14:11 schrieb Thomas Boniface:

Hi,

I have tried to find help regarding an issue we experience with our
platform leading to random file descriptor peaks. This happens more often
on heavy load but can also happen on low traffic periods.

Our application is using servlet 3.0 async features and an async
connector.
We noticed that a lot of issues regarding asynchronous feature were fixed
between our production version and the last stable build. We decided to
give it a try to see if it improves things or at least give clues on what
can cause the issue; Unfortunately it did neither.

The file descriptor peaks and application blocking happens frequently
with
this version when it only happens rarely on previous version (tomcat7
7.0.28-4).

Tomcat is behind an nginx server. The tomcat connector used is configured
as follows:

We use an Nio connector:
Connector port=8080 protocol=org.apache.coyote.
http11.Http11NioProtocol
   selectorTimeout=1000
   maxThreads=200
   maxHttpHeaderSize=16384
   address=127.0.0.1
   redirectPort=8443/

In catalina I can see some Broken pipe message that were not happening
with
previous version.

I compared thread dumps from server with both the new and old
version of
tomcat and both look similar from my stand point.

My explanation may not be very clear, but I hope this gives an idea how
what we are experiencing. Any pointer would be welcomed.


If the peaks happen long enough and your platforms has the tools
available you can use lsof to look for what those FDs are - or on Linux
looking at ls -l /proc/PID/fd/* (PID is the process PID file) - or on
Solaris use the pfiles command.

If the result is what is expected, namely that by far the most FDs are
coming from network connections for port 8080, then you can check via
netstat in which connection state those are.

If most are in ESTABLISHED state, then you/we need to further break down
the strategy.


One more thing: the connection peak might happen, if for some reason 
your application or the JVM (GC) gets slow. The reason doesn't have to 
still be there at the time when you take the thread dump.


You might want to add %D to your Tomcat access log and ty to estimate, 
whether the connection peaks are due to (temporary) application slow down.


The same holds for activating a GC log and check for long or many 
cumulative GC pauses.


Regards,

Rainer

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



Re: File descriptors peaks with latest stable build of Tomcat 7

2015-04-20 Thread Rainer Jung

Am 20.04.2015 um 17:40 schrieb Thomas Boniface:

Hi,

Both nginx and tomcat are hosted on the same server when listing the
connections I see both the connections from nginx to tomcat (the first one
create) and the one from tomcat to nginx used to reply. I may have
presented things the bad way though (I'm not too good regarding system
level).

I do agree the high number of close wait seems strange, I really feel like
nginx closed the connection before tomcat did (what I think leads to the
broken pipe expections observed in the catalina.out). In case someone want
to have a look I uploaded a netstat log here:
http://www.filedropper.com/netsat


The connection statistics between clients and nginx http port is:

  Count   IP:Port ConnectionState
  45467  178.32.101.62:80 TIME_WAIT
  44745178.33.42.6:80 TIME_WAIT
  26093178.33.42.6:80 ESTABLISHED
  25667  178.32.101.62:80 ESTABLISHED
   6898  178.32.101.62:80 FIN_WAIT2
   6723178.33.42.6:80 FIN_WAIT2
800  178.32.101.62:80 FIN_WAIT1
792178.33.42.6:80 FIN_WAIT1
712  178.32.101.62:80 LAST_ACK
656178.33.42.6:80 LAST_ACK
234178.33.42.6:80 SYN_RECV
232  178.32.101.62:80 SYN_RECV
 18178.33.42.6:80 CLOSING
  8  178.32.101.62:80 CLOSING
  1178.33.42.6:80 CLOSE_WAIT
  10.0.0.0:80 LISTEN

So lots of connections in TIME_WAIT state which is kind of expected for 
a web server doing lots of short time client connections, but slows down 
the IP stack. Also quite a lot of established connections (about 
50.000!), which means that you probably want to check, whether you can 
reduce your keep alive timeout for nginx.


The same statistics for the https port:

  Count   IP:Port ConnectionState
   2283 178.32.101.62:443 TIME_WAIT
   2125   178.33.42.6:443 TIME_WAIT
   1585 178.32.101.62:443 ESTABLISHED
   1493   178.33.42.6:443 ESTABLISHED
484 178.32.101.62:443 FIN_WAIT2
420   178.33.42.6:443 FIN_WAIT2
 47 178.32.101.62:443 FIN_WAIT1
 46   178.33.42.6:443 FIN_WAIT1
 25 178.32.101.62:443 LAST_ACK
 17   178.33.42.6:443 SYN_RECV
 16 178.32.101.62:443 SYN_RECV
 16   178.33.42.6:443 LAST_ACK
 10   178.33.42.6:443 CLOSING
  4 178.32.101.62:443 CLOSING
  1   0.0.0.0:443 LISTEN

About the same relative picture but only about 5% of the http connection 
counts.


The incoming connection statistics for Tomcat (port 8080) is:

  Count   IP:Port ConnectionState
   8381127.0.0.1:8080 CLOSE_WAIT
   1650127.0.0.1:8080 ESTABLISHED
127127.0.0.1:8080 SYN_RECV
 65127.0.0.1:8080 TIME_WAIT
  1   172.16.1.3:8080 LISTEN
  1127.0.0.1:8080 LISTEN

The many CLOSE_WAIT mean, that the remote side (nginx) has already 
closed the connection, but not yet Tomcat. Probably the idleconnection 
timeout / keep alive timeout for connectiosn between nginx and Tomcat is 
lower on the nginx side, than on the tomcat side.


Interestingly the same connections but viewed from the opposite side of 
the connection (nginx) have totally different statistics:


  Count   IP:Port ConnectionState
  20119127.0.0.1:8080 SYN_SENT
   4692127.0.0.1:8080 ESTABLISHED
488127.0.0.1:8080 FIN_WAIT2
122127.0.0.1:8080 TIME_WAIT
 13127.0.0.1:8080 FIN_WAIT1

I wonder why we have 4692 established connections here, but on 1650 in 
the table above. In a static situation, the numbers should be the same. 
It indicates, that the is so much dynamics, taht the numbers vary a lot 
even while netstat runs.


We see a lot of SYN_SENT, so nginx wants to open many more connections 
to Tomcat but doesn't get them as quickly as it wants.


Finally there's a bunch of connections to remote web services:

  CountIP:Port ConnectionState
286  95.85.3.86:80 CLOSE_WAIT
255   46.228.164.12:80 ESTABLISHED
209   188.125.82.65:80 CLOSE_WAIT
172  176.74.173.230:80 ESTABLISHED
170   54.171.53.252:80 CLOSE_WAIT
136   188.125.82.65:80 LAST_ACK
129  95.85.3.86:80 LAST_ACK
128  23.212.108.209:80 CLOSE_WAIT
106  46.137.157.249:80 CLOSE_WAIT
10181.19.244.69:80 ESTABLISHED
 86   146.148.30.94:80 CLOSE_WAIT
 8346.137.83.90:80 CLOSE_WAIT
 80   188.125.82.65:80 ESTABLISHED
 78  37.252.163.221:80 CLOSE_WAIT
 7746.137.83.90:80 ESTABLISHED
 73  46.137.157.121:80 CLOSE_WAIT
 6454.246.89.98:80 CLOSE_WAIT
 63  173.194.40.153:80 ESTABLISHED
 6193.176.80.69:80 ESTABLISHED
 55  23.212.108.198:80 CLOSE_WAIT
 5354.72.204.78:80 CLOSE_WAIT
 51  37.252.162.230:80 CLOSE_WAIT
 51  173.194.40.154:80 ESTABLISHED
 50  54.247.113.157:80 CLOSE_WAIT
 50   37.252.170.98:80 CLOSE_WAIT
 49  23.212.108.191:80 CLOSE_WAIT
 47   54.154.23.133:80 CLOSE_WAIT
 43  176.34.179.135:80 CLOSE_WAIT
 39   146.148.21.73:80 CLOSE_WAIT
 36   46.137.87.196:80 CLOSE_WAIT
 34  173.194.40.154:80 CLOSE_WAIT
 30   46.137.87.163:80 

Re: SEVERE: All threads (200) are currently busy

2015-04-12 Thread Rainer Jung

Am 12.04.2015 um 02:20 schrieb HG:

Every once in a while we get the following (Tomcat 6)

Mar 31, 2015 7:24:32 PM org.apache.tomcat.util.threads.ThreadPool logFull
SEVERE: All threads (200) are currently busy, waiting. Increase
maxThreads (200) or check the servlet status

in the Catalina logs and server stops responding. The server is used
very lightly and number of concurrent users not anywhere near 200 (2-3
on a busy day)

The thread dump shows 199 of these:

TP-Processor200 daemon prio=10 tid=0x2b513c31b000 nid=0x1c44
runnable [0x2b514a9a7000]
java.lang.Thread.State: RUNNABLE
 at java.net.SocketInputStream.socketRead0(Native Method)
 at java.net.SocketInputStream.read(SocketInputStream.java:129)
 at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
 at java.io.BufferedInputStream.read1(BufferedInputStream.java:258)
 at java.io.BufferedInputStream.read(BufferedInputStream.java:317)
 - locked 0x0007873208a0 (a java.io.BufferedInputStream)
 at org.apache.jk.common.ChannelSocket.read(ChannelSocket.java:628)
 at org.apache.jk.common.ChannelSocket.receive(ChannelSocket.java:566)
 at
org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:693)

 at
org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:898)

 at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)

 at java.lang.Thread.run(Thread.java:662)

and one of

TP-Processor4 daemon prio=10 tid=0x2b513c21a000 nid=0x7470 in
Object.wait() [0x2b513552]
java.lang.Thread.State: WAITING (on object monitor)
 at java.lang.Object.wait(Native Method)
 - waiting on 0x000784a7a208 (a
org.apache.tomcat.util.threads.ThreadPool)
 at java.lang.Object.wait(Object.java:485)
 at
org.apache.tomcat.util.threads.ThreadPool.findControlRunnable(ThreadPool.java:339)

 - locked 0x000784a7a208 (a
org.apache.tomcat.util.threads.ThreadPool)
 at
org.apache.tomcat.util.threads.ThreadPool.runIt(ThreadPool.java:314)
 at
org.apache.jk.common.ChannelSocket.acceptConnections(ChannelSocket.java:676)

 at
org.apache.jk.common.ChannelSocket$SocketAcceptor.runIt(ChannelSocket.java:879)

 at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)

 at java.lang.Thread.run(Thread.java:662)

Can anybody figure out why it complaints about busy threads when they
are clearly not?


The first 199 are connected to a fronting web server and wait for 
requests on their connections.


You are using a blocking connector implementation. That means each web 
server to Tomcat connection needs on eexclusive thread to handle it. It 
does not matter whether the connection already has an in-flight request 
on it or is completely idle. The thread is exclusively working for this 
single connection. Once your Tomcat has as manyconnections open in 
parallel as your thread pool size (or n-1), it can not accept any more 
connections and will log the observed message.


Your can choose a mix of the following optimizations:

- increase your thread pool size

- configure Tomcat and for web server (Apache/mod_jk, 
Apache/mod_proxy_ajp, ...) to shut down idle connections more 
aggressively to free Tomcat threads
  - lower idle connection timeout (Tomcat keep alive timeout and e.g. 
mod_jk connection_pool_timeout)
  - lower the number of connections, that will be kept alive even if 
they are idle for a long time (mod_jk connectiopn_pool_min_size)


- switch to a non blocking connector implementation like NIO. There the 
threads are not blocked during the time the connections are idle. Idle 
connections are monitored by (few, e.g. 1) poller threads and only 
connections with in-flight requests need a normal thread pool thread.


- Make sure your web servers are not oversized in terms of their own 
capability on how many connections in parallel they will provide


Regards,

Rainer

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



Re: AJP Connector : question on mod_proxy_ajp

2015-04-01 Thread Rainer Jung

Am 01.04.2015 um 09:43 schrieb André Warnier:

Rainer Jung wrote:

Am 31.03.2015 um 22:47 schrieb Christopher Schultz:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

André,

On 3/31/15 3:41 PM, André Warnier wrote:

I have a question of my own.


??!


+1


Tomcat 6.x/7.x/8.x.

Until now, we have been using mostly the Apache httpd mod_jk
connector to Tomcat. And we have been using the Tomcat AJP
Connector's 'tomcatAuthentication=false' setting, to propagate
the authenticated user from httpd to Tomcat.

Now we have a case where we must use the Apache httpd
mod_proxy_ajp connector instead of mod_jk, and I want to make sure
that the working of the AJP Connector's attribute
tomcatAuthentication remains the same in that context. Does it ?


Not automatically IIRC.


Mostly the same.


And do we have to specify anything special in the httpd
configuration for mod_proxy_ajp to make it so, or is the
authenticated user always passed to Tomcat by default, as seems to
be implied here :

http://httpd.apache.org/docs/2.2/mod/mod_proxy_ajp.html Attributes
?remote_user0x03String


mod_jk sends the user's authentication information over in the
REMOTE_USER field, so you'd just make sure that the REMOTE_USER field
is being sent using mod_proxy_ajp. I'm not exactly sure what the
incantation is for telling mod_proxy_ajp to send that field.

You could try to see if you get a REMOTE_USER without any additional
configuration on the httpd side. Note that REMOTE_USER will not show
up if you call request.getAttributeNames -- you have to explicitly
call request.getAttribute(REMOTE_USER) if you want to get it back.


mod_jk and mod_proxy_ajp by default forward the user member of the
request_rec struct as the AJP attribute SC_A_REMOTE_USER to Tomcat. If
tomcatAuthentication is false, Tomcat uses this attribute instead of
doing its own authentication.

With mod_jk you are a bit more flexible, because you can e.g.
configure it to take the user name from an Apache environment variable
you choose instead of where Apache puts it when its builtin
authentication procedures are used. But for the typical setup it
should work for both modules out of the box.

Regards,

Rainer



Many thanks for the confirmation.

@Chris : it looks like you are thinking a bit more complicated than it is..
But your thinking may come in handy for my follow-up question :

Now suppose that the front-end Apache authenticates the user, and in
addition to an authenticated user-id, it is also able to collect a
number of groups to which this user belongs. And suppose that being a
mod_perl guru at the Apache httpd level, I could collect these groups
and could use just about any scheme known to man, to pass them on to
Tomcat in the proxied request.

In what form would I need to do that, so that Tomcat could use these
groups as roles for that user ? And how would Tomcat (or a
Tomcat-based application) get to know about these roles/groups for that
user ?
(for example if the webapp were to call : request.isUserInRole(x) ?)

(and by the way, apart from calling isUserInRole() and getting a
true/false answer, is there a way for the webapp to get a list of all
such roles for the user, without knowing them in advance ?)


I think there's no trivial way to do that. By default the Principal 
retrieved via AJP13 will have no roles.


But Mark just committed for 8.0.21 and the forthcoming 7.0.61 a new 
feature tomcatAuthorization, see 
http://tomcat.apache.org/tomcat-8.0-doc/config/ajp.html.


If it is set to true, then the name of the principal will be used to 
look up the roles in whatever realm is configured in Tomcat. That is not 
the same as setting them on the proxy side though.


We could add a custom attribute to AJP like we did before to transport 
roles. But where would that attribute get its content from?


As far as I can see, there is no official place in Apache httpd 
structures where group or role info is kept around. The same modules 
that retrieve group info (from files, ldap, etc.) are also responsible 
for checking authorization, so they keep that info in module individual 
private data. Some of them use env vars to publish info, especialy the 
ldap module and it seems also the dbd one. Adding a custom AJP attribute 
would therefore be of limited (but non-void) use. You would have to fill 
a custom env var with the list of roles using mod_setenvif, mod_rewrite, 
mod_perl or hopefully ldap or dbd already provide the data you'd want to 
pass along. Do you think that would be useful?


Regards,

Rainer

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



Re: Post Session Id

2015-04-01 Thread Rainer Jung

Am 31.03.2015 um 15:19 schrieb Wesley Acheson:


Currently I'm trying to use tracking-modeSSL/tracking-mode in web.xml
but just running some local tests it appears that there are a number of
problems when using the JK connector and using this mechanism.

First issue:  Even though the requests are going through AJP which supports
the SSL context information propegation, It appears I need to add a second
connector to serve over https.  This is because the logic in
ApplicationConnector.java

 for (Connector connector : connectors) {
 if (Boolean.TRUE.equals(connector.getAttribute(SSLEnabled))) {
 supportedSessionTrackingModes.add(SessionTrackingMode.SSL);
 break;
 }
 }

Looks like the AJP connector doesn't accept that attribute.


Something we could fix, but you found a workaround.


Second issue: This is the actual issue that blocks us.

When going over mod_jk to a tomcat instance  it appears that the request
attribute SSL_SESSION_ID isn't populated on the first few requests to the
server. However it is populated on subsequent requests.

This is causing the following exception.

java.lang.NullPointerException
 at
org.apache.catalina.connector.CoyoteAdapter.parseSessionSslId(CoyoteAdapter.java:985)
 at
org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:765)
 at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:416)
 at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:190)
 at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:611)
 at
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:314)
 at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
 at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
 at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
 at java.lang.Thread.run(Thread.java:745)

Closing and repopening the browser causes the same issue to occur again.
Which means that I'm going to have to go back to posting the id, after
places where we don't control redirects back to our domain, I'm going to
have to issue a one time session lookup token to lookup the session Id.
This means sharing a data source with the Valve and the web applications.
(basically a string-string hashmap) Hopefully I can use JNDI or similar
for a local map if not its going to be needed to be backed by a database.

So remaining questions are two:  How to get the SSL_SESSION_ID populated on
initial requests?   Can I share some object in memory with tomcat as the
container(in a valve)  and the web application?


I currently see no reason, why it shouldn't be populated right from the 
start. Could you please check


- whether Apache always provides SSL_SESSION_ID:

Set SSLOptions +StdEnvVars and add %{SSL_SESSION_ID}X to your access 
log (using CustomLog and a LogFormat).


This will log the ssl session id with every request that is handled by 
Apache in the Apache access log. If the field does not contain an id, 
then mod_jk has no chance of forwarding it and we need to solve that part.


- whether Tomcat sees the right IDs:

You can add %{javax.servlet.request.ssl_session}r to the pattern of the 
AccessLogValve to add the ssl session id to your Tomcat access log.


If you can see the ID for the problematic cases in the httpd access log 
but not in the Tomcat one, I'll do a little test here to reproduce.


Regards,

Rainer

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



Re: AJP Connector : question on mod_proxy_ajp

2015-04-01 Thread Rainer Jung

Am 01.04.2015 um 12:22 schrieb André Warnier:

Rainer Jung wrote:

Am 01.04.2015 um 09:43 schrieb André Warnier:

Rainer Jung wrote:

Am 31.03.2015 um 22:47 schrieb Christopher Schultz:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

André,

On 3/31/15 3:41 PM, André Warnier wrote:

I have a question of my own.


??!


+1


Tomcat 6.x/7.x/8.x.

Until now, we have been using mostly the Apache httpd mod_jk
connector to Tomcat. And we have been using the Tomcat AJP
Connector's 'tomcatAuthentication=false' setting, to propagate
the authenticated user from httpd to Tomcat.

Now we have a case where we must use the Apache httpd
mod_proxy_ajp connector instead of mod_jk, and I want to make sure
that the working of the AJP Connector's attribute
tomcatAuthentication remains the same in that context. Does it ?


Not automatically IIRC.


Mostly the same.


And do we have to specify anything special in the httpd
configuration for mod_proxy_ajp to make it so, or is the
authenticated user always passed to Tomcat by default, as seems to
be implied here :

http://httpd.apache.org/docs/2.2/mod/mod_proxy_ajp.html Attributes
?remote_user0x03String


mod_jk sends the user's authentication information over in the
REMOTE_USER field, so you'd just make sure that the REMOTE_USER field
is being sent using mod_proxy_ajp. I'm not exactly sure what the
incantation is for telling mod_proxy_ajp to send that field.

You could try to see if you get a REMOTE_USER without any additional
configuration on the httpd side. Note that REMOTE_USER will not show
up if you call request.getAttributeNames -- you have to explicitly
call request.getAttribute(REMOTE_USER) if you want to get it back.


mod_jk and mod_proxy_ajp by default forward the user member of the
request_rec struct as the AJP attribute SC_A_REMOTE_USER to Tomcat. If
tomcatAuthentication is false, Tomcat uses this attribute instead of
doing its own authentication.

With mod_jk you are a bit more flexible, because you can e.g.
configure it to take the user name from an Apache environment variable
you choose instead of where Apache puts it when its builtin
authentication procedures are used. But for the typical setup it
should work for both modules out of the box.

Regards,

Rainer



Many thanks for the confirmation.

@Chris : it looks like you are thinking a bit more complicated than
it is..
But your thinking may come in handy for my follow-up question :

Now suppose that the front-end Apache authenticates the user, and in
addition to an authenticated user-id, it is also able to collect a
number of groups to which this user belongs. And suppose that being a
mod_perl guru at the Apache httpd level, I could collect these groups
and could use just about any scheme known to man, to pass them on to
Tomcat in the proxied request.

In what form would I need to do that, so that Tomcat could use these
groups as roles for that user ? And how would Tomcat (or a
Tomcat-based application) get to know about these roles/groups for that
user ?
(for example if the webapp were to call : request.isUserInRole(x) ?)

(and by the way, apart from calling isUserInRole() and getting a
true/false answer, is there a way for the webapp to get a list of all
such roles for the user, without knowing them in advance ?)


I think there's no trivial way to do that. By default the Principal
retrieved via AJP13 will have no roles.

But Mark just committed for 8.0.21 and the forthcoming 7.0.61 a new
feature tomcatAuthorization, see
http://tomcat.apache.org/tomcat-8.0-doc/config/ajp.html.

If it is set to true, then the name of the principal will be used to
look up the roles in whatever realm is configured in Tomcat. That is
not the same as setting them on the proxy side though.

We could add a custom attribute to AJP like we did before to transport
roles. But where would that attribute get its content from?

As far as I can see, there is no official place in Apache httpd
structures where group or role info is kept around. The same modules
that retrieve group info (from files, ldap, etc.) are also responsible
for checking authorization, so they keep that info in module
individual private data. Some of them use env vars to publish info,
especialy the ldap module and it seems also the dbd one. Adding a
custom AJP attribute would therefore be of limited (but non-void) use.
You would have to fill a custom env var with the list of roles using
mod_setenvif, mod_rewrite, mod_perl or hopefully ldap or dbd already
provide the data you'd want to pass along. Do you think that would be
useful?



Let's say that from my point of view, that new tomcatAuthorization
feature is good, because it is an additional step in the right
direction.  In effect, it (optionally) splits the authentication from
the authorization phase, which makes the whole thing more flexible.

The underlying issue here is that the concept of groups used in most
of the non-Tomcat area, is distinct of the concept of role in Tomcat.

In general terms, what

Re: AJP Connector : question on mod_proxy_ajp

2015-03-31 Thread Rainer Jung

Am 31.03.2015 um 22:47 schrieb Christopher Schultz:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

André,

On 3/31/15 3:41 PM, André Warnier wrote:

I have a question of my own.


??!


+1


Tomcat 6.x/7.x/8.x.

Until now, we have been using mostly the Apache httpd mod_jk
connector to Tomcat. And we have been using the Tomcat AJP
Connector's 'tomcatAuthentication=false' setting, to propagate
the authenticated user from httpd to Tomcat.

Now we have a case where we must use the Apache httpd
mod_proxy_ajp connector instead of mod_jk, and I want to make sure
that the working of the AJP Connector's attribute
tomcatAuthentication remains the same in that context. Does it ?


Not automatically IIRC.


Mostly the same.


And do we have to specify anything special in the httpd
configuration for mod_proxy_ajp to make it so, or is the
authenticated user always passed to Tomcat by default, as seems to
be implied here :

http://httpd.apache.org/docs/2.2/mod/mod_proxy_ajp.html Attributes
?remote_user0x03String


mod_jk sends the user's authentication information over in the
REMOTE_USER field, so you'd just make sure that the REMOTE_USER field
is being sent using mod_proxy_ajp. I'm not exactly sure what the
incantation is for telling mod_proxy_ajp to send that field.

You could try to see if you get a REMOTE_USER without any additional
configuration on the httpd side. Note that REMOTE_USER will not show
up if you call request.getAttributeNames -- you have to explicitly
call request.getAttribute(REMOTE_USER) if you want to get it back.


mod_jk and mod_proxy_ajp by default forward the user member of the 
request_rec struct as the AJP attribute SC_A_REMOTE_USER to Tomcat. If 
tomcatAuthentication is false, Tomcat uses this attribute instead of 
doing its own authentication.


With mod_jk you are a bit more flexible, because you can e.g. configure 
it to take the user name from an Apache environment variable you choose 
instead of where Apache puts it when its builtin authentication 
procedures are used. But for the typical setup it should work for both 
modules out of the box.


Regards,

Rainer

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



  1   2   3   4   5   6   7   8   9   10   >