RE: No binary distribution for mod_jk?

[Jäkel , Guido]

>-Original Message-
>From: Christopher Schultz [mailto:ch...@christopherschultz.net]
>Sent: Thursday, July 21, 2016 5:51 PM
>To: Tomcat Users List
>Subject: Re: No binary distribution for mod_jk?
>
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA256
>
>Paul,
>
>On 7/20/16 12:12 PM, Paul Roubekas wrote:
>> I am trying to install the mod_jk on httpd for my tomcat 7.0.68
>> (TomEE) server.
>>
>> I am reading this
>> https://tomcat.apache.org/connectors-doc/webserver_howto/apache.html
>>
>>
>documentation which points to this
>> http://tomcat.apache.org/download-connectors.cgi download page.
>> But there is no binary download for *unix, just source?
>
>That's right: the ASF provides source, not binaries (in general). You
>will have to build mod_jk yourself on *NIX. The good news is that it's
>fairly easy to build yourself.
>
>- -chris

... but I expect that every serious Linux binary distribution will alson with 
other additional Apache modules provide it in it's software repository, or is 
this wrong? As an user of Gentoo I have no experience with this.

Guido

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

RE: OutOfMemoryError: PermGen space

[Jäkel , Guido]

>-Original Message-
>From: Berneburg, Cris J. - US [mailto:cberneb...@caci.com]
>Sent: Thursday, July 21, 2016 6:18 PM
>To: Tomcat Users List
>Subject: RE: OutOfMemoryError: PermGen space
>
>Mark
>
>Thanks again for taking the time to assist with the OutOfMemoryError.  BLUF, 
>it looks like Log4J2 is the culprit.  Will you
>please check my work below to see if I have interpreted correctly?

Dear Chris,

Is the Log4J-JAR located at the "right place" with respect to the classloader 
path, i.e. inside the webapps lib directory? Is Log4J2 is just used for your 
application or for Tomcat logging, too? 

Guido

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

RE: A complex issue concerning the application lifecycle, MBeans and Spring

[Jäkel , Guido]

Hi Mark,

OK - as a newbie I read this from the stack trace: ...

>20160713-161427.340 ERROR [catalina-exec-64] [] [[/]] StandardWrapper.Throwable
>[...]
>at 
> org.springframework.web.servlet.HttpServletBean.init(HttpServletBean.java:136)
>at javax.servlet.GenericServlet.init(Unknown Source)
>at org.apache.catalina.core.StandardWrapper.initServlet(Unknown Source)
>at org.apache.catalina.core.StandardWrapper.loadServlet(Unknown Source)
>at org.apache.catalina.core.StandardWrapper.allocate(Unknown Source)
> 2)at org.apache.catalina.core.StandardWrapper.isSingleThreadModel(Unknown 
> Source)
>at sun.reflect.GeneratedMethodAccessor178.invoke(Unknown Source)
>at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>at java.lang.reflect.Method.invoke(Method.java:497)
> 1)at org.apache.tomcat.util.modeler.BaseModelMBean.getAttribute(Unknown 
> Source)
>at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:647)
>at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678)
>at org.apache.catalina.mbeans.MBeanDumper.dumpBeans(Unknown Source)
 [...]

It seems to me that "all reading is passiv" don't hold because the call to 
getAttibute() at 1) will invoke the MBean and this leads to the call of 
isSingleThreadModel at 2) -- I don't see why at the moment.

But about 2) I take a look at the sources at github:


public boolean isSingleThreadModel() {

// Short-cuts
// If singleThreadModel is true, must have already checked this
// If instance != null, must have already loaded
if (singleThreadModel || instance != null) {
return singleThreadModel;
}

// The logic to determine this safely is more complex than one might
// expect. allocate() already has the necessary logic so re-use it.
// Make sure the Servlet is loaded with the right class loader
ClassLoader oldCL = null;
try {
oldCL = ((Context) getParent()).bind(false, null);
--->Servlet s = allocate();
deallocate(s);
} catch (Throwable t) {
ExceptionUtils.handleThrowable(t);
} finally {
((Context) getParent()).unbind(false, oldCL);
}
return singleThreadModel;
}


And this will load (and initialize) the servlet because some conditions are 
fulfilled: It is sure that  singleThradModel == false  and  instance == null  
because we are called from isSingleThreadModel

So maybe there should be a special code path in case of an ongoing 
initialization on the top like the 'if(unloading)' clause. The note states, 
that one can't decide if a Servlet implements SingleThreadModel until loading. 
So maybe on startup this must be answered in a "conservative way" (if possible) 
or thrown back with an exception. If this will lead to an overall exception for 
the MBean request, this might be "the right thing", because at leaset one of 
the returned information can't be answered yet at this moment (during 
initialization of the servlet).


@Override
public Servlet allocate() throws ServletException {

// If we are currently unloading this servlet, throw an exception
if (unloading) {
throw new 
ServletException(sm.getString("standardWrapper.unloading", getName()));
}

boolean newInstance = false;

// If not SingleThreadedModel, return the same instance every time
if (!singleThreadModel) {
// Load and initialize our instance if necessary
--->if (instance == null || !instanceInitialized) {
synchronized (this) {
if (instance == null) {
try {
if (log.isDebugEnabled()) {
log.debug("Allocating non-STM instance");
}

// Note: We don't know if the Servlet implements
// SingleThreadModel until we have loaded it.
instance = loadServlet();
[...]


By the way: The only occurrence where  instaceInitialized is set to true is 
*after* a call to the core servlet.init at initServelt. Therefore it semantic 
is not "initialization is started and in progress" but "initialization is 
completed" and IMHO therefore one can't take it as an indicator for the fact 
that's it should be done. But I can't overview if the  synchronized(this)  will 
close this gap. 



Greetings

Guido

RE: OutOfMemoryError: PermGen space

[Jäkel , Guido]

>In Visual VM, under File, Compare Memory Snapshots, it does not see the 
>snapshots I generated.  The snapshots appear to
>be extension *.apps, but the compare function looks for files with extension 
>*.nps.  I don't know how to get the compare
>function to work.
>
>Not sure where to go from here.  Got any suggestions?

You may pull heap dumps and use the Eclipse Memory Analyzer Toolkit (aka MAT)  
(http://www.eclipse.org/mat/) to discover stale objects danging on the webapps 
classloader. The tool may be used stand-alone (via an included  Eclipse RCP) or 
as an Eclipse Plugin.


Greetings

Guido

RE: A complex issue concerning the application lifecycle, MBeans and Spring

[Jäkel , Guido]

>So it would appear that if the Connectors are disabled, the monitoring system 
>is not able
>to reach Tomcat, and the problem does not occur then.
>
>So would it not be possible to create some little piece of software, which 
>would
>temporarily "suspend" or "disable" the Connectors, while the application 
>update is taking
>place, and then re-enable them when it's done ?
>
>Of course, if the application update is also going though the Connectors, this 
>may be a
>problem..

Dear André,

thank you for quickly announcing your idea for an workaround. But you right see 
the limits, and the more important impact of disabling the connectors is that 
it will also disable the traffic to all the other running applications (and we 
have a bunch of it on each of our Tomcats)

In the first instance I want to have a fix for the issue. But nevertheless, 
maybe this lead me to a suitable workaround if I think about it in the 
background.

Greetings

Guido

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

A complex issue concerning the application lifecycle, MBeans and Spring

[Jäkel , Guido]

Dear Developers,

I have an elaborate issue migrating from Tomcat 6.0.41 to 8.0.36 (currently 
using java 8.0.66 on Gentoo Linux, but this is not of importance I think): It 
is related to the build-in manager application used as a jmxproxy. And to 
initialization of the Spring framework during an application lifecycle. But in 
core, I think it's not related to the manager app and it's proxy feature 
itself. But to some MBean or lifecycle implementation details.

First of all: In principle, all works well. If i start the tomcat from the 
scratch, all applications will proper initialize and work as expected. If I 
restart any application by different triggers (manager, touching the WAR or a 
sensitive file inside the docroot and so on), it will be undeployed and 
deployied again - all as usual.

But if there is a certain request to some MBean while the App is starting, 
there will be a request to the application (via catalina-exec). And then, as a 
race condition, the initialization of the Spring framework, esp. the bean 
wiring will fail with lots of exceptions because this is not thread-safe.

If this additional (failing) request is processed fast enough, the application 
will be usable due to initialization via the normal servlet lifecycle request. 
But if it's as a race condition in the other way round, the application will be 
not usable afterwards.

The point now is: This requests to the MBeans are done requently (ever 10s) by 
our monitoring system. And about 90% of the automatic deployments done by the 
CI system now will fail by this race condition in spite of the deployed apps 
are well-done. Without any modification, the same application is able to start 
by chance of no concurrent request to the MBean or (of course) by disabling the 
Monitoring or factical preventing it's request also by a restart of the whole 
tomcat, because the connectors are disabled until all apps are up as you'll 
know.

This never happens with tomcat 6 used for many years. Therefore, there must be 
some regression with an MBean that will allow to route a request to a 
not-fully-started application. I happens with all our well-established 
applications which use the Spring framework -- regardess if deployed via the CI 
because of normal, slightly modification or even with unchanged versions 
running in production on Tomcat6. I can't give information about the behavior 
on Tomcat7.

I think I was able to narrow it down to a specific MBean readout: If I send the 
request ".../manager/jmxproxy?qry=Catalina:j2eeType=Servlet,WebModule=*,*" 
before the Deployer logs "[StandardContext] Reloading Context with name [foo] 
is completed", then it will trigger an unwanted, additional thread.

It sounds like it points into the right direction because the MBean related to 
the Servlet is offering e.g. information about the containers lifecycle state.

May you fix it or did you see any workaround? If you need any more details, 
please ask about. Thank you in advance for your support.


with greetings

Guido

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

RE: A complex issue concerning the application lifecycle, MBeans and Spring

[Jäkel , Guido]

>> Dear André,
>>
>> thank you for quickly announcing your idea for an workaround. But you right 
>> see the limits, and the more important
>impact of disabling the connectors is that it will also disable the traffic to 
>all the other running applications (and we have a
>bunch of it on each of our Tomcats)
>>
>> In the first instance I want to have a fix for the issue. But nevertheless, 
>> maybe this lead me to a suitable workaround if I
>think about it in the background.
>>
>
>Well, here is a little variation of the idea then :
>The purpose of the monitoring is normally to verify that the applications are 
>responding,
>right ? (*)
>And the fact that the applications are responding, does not depend on the 
>Connector
>through which such requests come in, right ?
>So why not define an additional Connector, on a different port, for usage 
>*only* by the
>monitoring system, and disable only /that/ Connector while you are doing your 
>application
>update ?
>
>(*) I mean, if you want to verify that the connection is working, then you can 
>just do a
>"ping" kind of test.

Dear André,

So why? It's because want to modify a complex, multi-staged and well-working 
platform as a last resort only. The monitoring does a lot more than to verify 
that the applications are running, it's uses a bunch of the data available via 
the MBeans for a control dashboard.

It's was my mistake to use the term workaround ...

Guido

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

RE: A complex issue concerning the application lifecycle, MBeans and Spring

[Jäkel , Guido]

Hi Mark,

I just applied the patchset to the released source tarball of  8.0.36  and with 
performing some cycling and deployments of applications I confirm the issue has 
gone as expected.

with thanks again

Guido

>-Original Message-
>From: Guido Jäkel [mailto:g.jae...@dnb.de]
>Sent: Thursday, July 14, 2016 11:51 PM
>To: Tomcat Users List
>Cc: Rainer Jung
>Subject: Re: A complex issue concerning the application lifecycle, MBeans and 
>Spring
>
>Dear Mark,
>
>thank you a lot for giving your time and knowledge to follow and confirm my 
>thoughts on this complex and inscrutable
>issue and fixing it at the core within a day!
>
>I take a look at  http://svn.apache.org/viewvc?view=revision=1752739  
>and I found that you picked up my
>suggestion of "a conservative way to answer the question about 
>isSingleThreadModel()". I was close about to use the term
>"three-state" but I just forgot that with Java one may code this in this 
>elegant way.
>
>I'm already on a short holiday until Monday, but I can start to verify it 
>right then. Because I'm using Gentoo Linux, I might
>bump the ebuild to this version within minutes, if an official source tarball 
>is already available then. Or I may apply it as a
>patch to the 8.0.32 because it's just a few lines.
>
>I'll give feedback ASAP. Our home-brewed "Multi-Tomcat Monitoring Scoreboard" 
>is an excellent stress test ;)
>
>greetings
>
>Guido

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

RE: [SOLVED] mod_jk/1.2.37 Apache/2.4.7 (Ubuntu): AJP established connections pile up, connection_pool_timeout has no effect?

[Jäkel , Guido]

>From: Hildegard Meier [mailto:daku8...@gmx.de]
>Sent: Thursday, September 01, 2016 10:14 AM
>To: users@tomcat.apache.org
>Subject: [SOLVED] mod_jk/1.2.37 Apache/2.4.7 (Ubuntu): AJP established 
>connections pile up, connection_pool_timeout has
>no effect?
>
>Dear Guido,
>
>many thanks for Your answer.

many thanks for your feedback, too.

>
>It looks, like the parameter reply_timeout=180 was the solution. I added 
>that parameter yesterday and was not sure if
>that would help and since I go to vacation in short time, I asked in this list 
>in parallel to maybe solve the problem before
>vacation in another way.
>[...]
>Why the backend applications so often do not give any response, I think is 
>another issue for the developers.
>
>But maybe the importance of changing the reply_timeout parameter from default 
>value "infinit" to a even very high value of
>30 min should be stated even more prominent in the worker documentation.

I set this even lower (to 120s) because it's said it's the timeout for reading 
of each packet and no application on the Tomcat should take so much time to 
send any part of an answers.

I might be of worth if you pass the URIs of the dangling requests to 
developers. Because not finished, they are not logged. But you may take a look 
on the scoreboards of the Apache or the Tomcat. On Tomcat, it available via an 
MBean, you may read out it via JMX or via the http-proxy of the Tomcat Manager 
application. I may send you a script as a pointer, if you like.

Guido

RE: mod_jk/1.2.37 Apache/2.4.7 (Ubuntu): AJP established connections pile up, connection_pool_timeout has no effect?

[Jäkel , Guido]

Dear Hildegard,

you wrote, you're using the worker MPM. What are the pool sizes for child 
workers and it's threads, i.e. the values for  ServerLimit, ThreadsPerChild? 
And what's the minimum thread pool size, i.e.   MinSpareThreads? 

Note that the AJP connection pool is used per child (and per tomcat backend 
definition if you're using more than one). You use connection_pool_minsize=1.  
Please also note, that the spare threads will no gather to the lowest possible 
number of childs. May this facts explain the "remaining idle" AJP connections?


But even if the number of connections is unexpected high -- this will not 
consome more memory time by time after establishing. 


If you see a real leak, this will have another reason. One from my lessons 
learned: If you're write access and error logs by a piped process like 
rotatelogs, this will "slowly and continuous eat up memory", if it will not 
consume. This will e.g. happen, if rotatelogs can't create files because of a 
broken path or lack of rights.

Greetings

Guido

>-Original Message-
>From: Hildegard Meier [mailto:daku8...@gmx.de]
>Sent: Wednesday, August 31, 2016 2:11 PM
>To: users@tomcat.apache.org
>Subject: mod_jk/1.2.37 Apache/2.4.7 (Ubuntu): AJP established connections pile 
>up, connection_pool_timeout has no effect?
>
>Running:
>Ubuntu Trusty 14.0.4 LTS 64 Bit
>mod_jk/1.2.37
>Apache/2.4.7 (Ubuntu)
>
>Hello,
>
>I have much investigated into this, but have no idea, why the AJP connections 
>from the Apache (MPM worker) to the AJP
>backends pile up.
>They do not get closed, they stay in state ESTABLISHED.
>
>Over night, the idle connections should be closed from the pool, but the do 
>not get closed, they get more and more every
>day, and the RAM of the Apache server gets eaten up.
>
>We have the following /etc/libapache2-mod-jk/workers.properties:
>
>---
>
># not used
>workers.tomcat_home=/usr/share/tomcat6
># not used
>workers.java_home=/usr/lib/jvm/default-java
>ps=/
>
># General worker template
>worker.template_01.type=ajp13
>worker.template_01.socket_connect_timeout=3000
>worker.template_01.ping_mode=A
>worker.template_01.connection_pool_timeout=600
>worker.template_01.connection_pool_minsize=1
>worker.template_01.socket_keepalive=true
>worker.template_01.reply_timeout=180
>
>---
>
>and on the AJP backends (Jboss / EAP), we have also set the connectionTimeout 
>to 60 ms , as written in
>https://tomcat.apache.org/connectors-doc/common_howto/timeouts.html
>
>But even a Backend with low traffic, (maybe one request per minute) gets 300 
>established AJP connections after some days.
>
>Here the content of /etc/apache2/mods-enabled/jk.conf:
>
>
>
>JkWorkersFile /etc/libapache2-mod-jk/workers.properties
>JkLogFile /var/log/apache2/mod_jk.log
>JkLogLevel info
>JkShmFile /var/log/apache2/jk-runtime-status
>JkWatchdogInterval 60
>
>
>It looks like the JkWatchdog is not running? Or do the connections do not idle 
>because of some non-Apache requests like
>cping/cpong?
>
>Your support is much appreciated.
>
>Thanks
>
>-
>To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>For additional commands, e-mail: users-h...@tomcat.apache.org


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

RE: mod_jk/1.2.37 Apache/2.4.7 (Ubuntu): AJP established connections pile up, connection_pool_timeout has no effect?

[Jäkel , Guido]

Dear Hildegard, 

I wrote:

>Note that the AJP connection pool is used per child (and per tomcat backend 
>definition if you're using more than one). You
>use connection_pool_minsize=1.  Please also note, that the spare threads will 
>no gather to the lowest possible number of
>childs. May this facts explain the "remaining idle" AJP connections?

You can get a good picture of what's up if you watch the scoreboard of the 
Apache server status page (mod_status) with the option refresh=1

As an example on one of my Apache frontends I'm using 16 children with 64 
threads. And a minimum pool of 128  (= 2*64), i.e. there may be 6 connections 
keep to each Tomcat after first usage of any thread in a newborn child as long 
as the child is alive.

The actual scoreboard of an more or less busy of my Apache looks like


_KC_R___WK___K_K_KK_RRR__K_C_K__KK_K__K_K__KRKK_KR__
K_WKRR_KRK_KCK_KCR_K__RK_KK_W_KKW__K__KK___KRRK_RKW_WKR_KK_RKR_K
__KK_RWRRK_CC__KW_KKRRKKK___KKW_KKR_RK_R__KW__KCKCK___R_
K_K_KKRKR_CR__KR_K_K__K__KR_K___KK__KK__WK__KK_K_KRK_KKR__KRK__K
_RK__R_K_CR__K__K__K__KKK__K_KKKRKW_K_RK_RKK_KK___RKRK_KRKKK
R_R__R_KKK_KW_R_RRW__RKK_K_CKK__KC___KRKKKC__R__KR_K
RCKRW_KR_K_K___KK_R_K_K___K_R__RK_KRK__K_K_KRRK___RK

___KK_R__K___RWK_R_K_KK_K_K_KKKRKK_K__KRRKKR___KKK_R

KK__RRKKRRKK_K_KKK_K__KRKKKRK___RK_KKK_R_KWRK_K_KC_K
K_KC_RK__KRKK___RKKR___KK_KR_KK__KK_KKK_WKKK__KRK__K__K_RKKK




and the same for a much more lazy one

KK__KK_K_KKK__K__K__K___K__K__W_KK__
___KW_K___K__K__KK___KK__K__K_KK_KK__KKW_W__K_K_

K_K__KKKK__K___K_K__K__K__K__K_K_W_KK___
___KKK_K_K_K___K__KK__K__K__
K_WKKK_K__K__K___K___K__KK__











where '_' represents an idle thread but a line of '.' a closed child.

Guido

RE: CLOSE_WAIT between Application (Tomcat) and Apache HTTPD

[Jäkel , Guido]

Dear Adhavan,

I think this is quiet normal, because the browser clients "in front" will reuse 
connections (using keep-alive at TCP level) but an in-between load balancer may 
be not work or configured in this way and will use a new connection for each 
request to the backend.

Then, you'll see a lot of sockets in the TCP/IP closedown workflow between the 
load balancer and the backend server. Pleases refer to TCP/IP that the port 
even for a "well closed connection" will be hold some time to handle late 
(duplicate) packets. Think about a duplicated, delayed RST packet - this should 
not close the next connection to this port.

Because this situation is very unlikely or even impossible on a local area 
network, you may adjust the TCP stack setting of your server to use much lower 
protection times (in the magnitude of seconds) and also adjust others. And at 
Linux, you may also expand the range of ports used for connections.

BTW: If you have a dedicated stateful packet inspecting firewall between your 
LB and the server, you also have to take a look on this.


Said that, one more cent about the protocol between the LB and the Tomcat: I 
don’t know about HTTP, but if you use AJP (with mod_jk) you may configure it to 
keep and reuse connections to the Tomcat backend(s).

Guido

>-Original Message-
>From: Adhavan Mathiyalagan [mailto:adhav@gmail.com]
>Sent: Wednesday, May 10, 2017 6:32 PM
>To: Tomcat Users List
>Subject: CLOSE_WAIT between Application (Tomcat) and Apache HTTPD
>
>Team,
>
>Tomcat version : 8.0.18
>
>Apache HTTPD version : 2.2
>
>
>There are lot of CLOSE_WAIT connections being created at the
>Application(tomcat)  ,when the traffic is routed through the Apache HTTPD
>load balancer to the Application running over tomcat container. This leads
>to slowness of the port where the Application is running and eventually the
>application is not accessible through that particular PORT.
>
>In case of the traffic directly reaching the Application PORT without HTTPD
>(Load balancer) there is no CLOSE_WAIT connections created and  application
>can handle the load seamlessly.
>
>Thanks in advance for the support.
>
>Regards,
>Adhavan.M

RE: Help with Tomcat Automatic Application Deployment

[Jäkel , Guido]

Dear Srinath,

take a look at the Configuration Elements for

/Context/WatchedResource

Probably included at the main context.xml  file or the one of your application 
(, see https://tomcat.apache.org/tomcat-8.5-doc/config/context.html).

Greetings

Guido

>-Original Message-
>From: sri devops [mailto:sri.devop...@gmail.com]
>Sent: Tuesday, May 08, 2018 8:08 PM
>To: users@tomcat.apache.org
>Subject: Help with Tomcat Automatic Application Deployment
>
> Hello Team,
>
>Currently I have apache-tomcat-8.5.23 installed and running on
>RHEL7.x86_64. I have a war deployed and application is running under
>tomcat. While application is running, if i make any manual changes to some
>config files [ context.xml or server.xml or web.xml] and noticed Tomcat is
>restarting application even though I haven't called tomcat service start
>script.
>
>My intention is,
>1) At first when there's initial war deployed and tomcat service start
>script is called, tomcat should extract war and app should work
>2) Second, While tomcat is in running state and application is running and
>if i make any manual changes to any tomcat config file, I do not want
>application to auto magically restart.
>
>*my server.xml looks as below*
>
>   unpackWARs="true" autoDeploy="true">
>
>
>I also looked at your docs and researched online, but unclear on these
>parameters what to use when. [ setting autoDeploy=false (or) having
>deployIgnore attribute somewhere ?]
>
>Thanks in Advance,
>
>Srinath

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

RE: Amazon EC2 Tomcat 7.0.85 not starting up due to some memory issue .Please mask if

[Jäkel , Guido]

Dear Kiran,

there might be many other ways to compromise your server. But I wonder about 
the application you run on you Tomcat and if you know about the wide-used 
exploit in the Java JSF library "Primefaces" (see 
https://www.exploit-db.com/exploits/43733/).

With greetings

Guido

>-Original Message-
>From: Kiran Badi [mailto:ki...@poonam.org]
>Sent: Wednesday, May 16, 2018 7:13 PM
>To: Tomcat Users List 
>Subject: Re: Amazon EC2 Tomcat 7.0.85 not starting up due to some memory issue 
>.Please mask if
>
>Yes tomcat is not starting up. I am also suspecting that EC2 instance was
>probably compromised. Not sure as how but I see some rogue programs were
>running under tomcat user. I use putty with private keys to login and those
>keys are not in public view for sure.
>

RE: Contexts: can there be a hierarchy?

[Jäkel , Guido]

Dear Chuck,

>It's a hierarchy for the URLs, but not from a webapp location, construction,
>or execution perspective - /foo/bar is completely independent of /foo, not
>inside or a subset of it.

Reading that I understand what you have pointed out and of course fully agree 
to it :)

Greetings

Guido

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

RE: [OT] What can prevent sessions from timeouting apart from real requests

[Jäkel , Guido]

Dear Leon,

I suggest to use the Tomcat Manager Application to investigate the session data:

* Use the Session Display (/manager/html/sessions?path=/foo) to take a look on 
the different Timers (Creation Time, Last Accessed Time, Used Time, Inactive 
Timemm,TTL) or even the session data

* Use the Connector Scoreborads on the Server Status Display (/manager/status) 
to detect stuck requests. I'm not sure if a stuck request may prevent a session 
cleanup (especially of "other" sessions)

Another approach may be to snapshot a memory dump and investigate the session 
objects, e.g. with the Eclipse Memory Analyze Tool (aka MAT).

Greetings

Guido

>-Original Message-
>From: Leon Rosenberg [mailto:rosenberg.l...@gmail.com]
>Sent: Friday, August 24, 2018 11:25 AM
>To: Tomcat Users List 
>Subject: [OT] What can prevent sessions from timeouting apart from real 
>requests
>
>Hi,
>
>one of the systems we are consulting has encountered a strange problem. The
>sessions will build up indefinitely but never expire. Then, at one point
>(at 02am in the night, 19K sessions would drop at once).
>Of course the simplest explanation would be that someone is actively
>requests something every 15 minutes (session timeout) keeping track of the
>JSESSIONID. We are trying to track this through the access_log and such.
>However, my question, is it possible to prevent session from timeouting by
>doing something stupid code-wise? Like storing a session in a hashmap
>somewhere, and accessing some attributes from time to time? My
>understanding was that the session timeout is solely dependent on incoming
>requests and handled by the container, but I was not 100% sure ;-)
>
>Thanks in advance
>Leon

RE: Tomcat Valve

[Jäkel , Guido]

Dear Lance

I don't know the motivation for your usecase. But note that the access log is 
written after handling the complete request (therefore its able to log the 
number of bytes send) and, because it's typical buffered, with a delay, too.

This means, that a request is listed there only in the case of a proper 
shutdown. If the Tomcat come down because of a JVM OOM or something like this, 
this might be inaccurate.

In addition, if you tell the Tomcat to shut down, one of the first steps is to 
block the "Connectors", i.e. the receivers for HTTP (and/or AJP). Request will 
be rejected then, but not logged anymore.  Then, further shutdown will happen, 
e.g. the shutdown of the Servlet Containere(s). This may take some notable time 
and during this, the JVM -- Maybe from another point of view called "the Tomcat 
Process" -- is still running.

Greetings

Guido

>-Original Message-
>From: Mark Thomas [mailto:ma...@apache.org]
>Sent: Friday, August 24, 2018 6:44 PM
>To: users@tomcat.apache.org
>Subject: Re: Tomcat Valve
>
>On 24/08/18 17:36, Campbell, Lance wrote:
>> I don't understand.  How does that help a valve running know that it is 
>> shutting down?  At that point it would be too late.
>
>The point is you don't need a valve to answer your question. Just look
>at the last 9 entries in the access log.
>
>Mark
>
>>
>> On 8/24/18, 11:06 AM, "Mark Thomas"  wrote:
>>
>> On 24/08/18 16:52, Campbell, Lance wrote:
>> > Tomcat 9
>> > Use Case 1:  I want to store the last N number of URLs sent to Tomcat 
>> 9 application.  Then if Tomcat shuts down I want
>to write out these last N number of URLs to the log file.
>> >
>> > Strategy:
>> > I figured I would use a valve to keep track of the last N number of 
>> URLs.  However I don’t know how to tell when the
>valve is shutting down.
>> >
>> > Does anyone have any suggestions?
>>
>> tail -n 9 ${CATALINA_BASE}/logs/localhost_access_log.-mm-dd.txt
>>
>> Mark
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>
>
>-
>To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Contexts: can there be a hierarchy?

[Jäkel , Guido]

Dear Chales (and James)

why do you call it not really a hierachy? If you name the deployments e.g.

ROOT.war
foo.war
foo#bar.war

then the "expected" will happen: The longest context path will match to the 
corresponding container:

* all /foo/bar{,/.*} will be served by foo#bar.war,
* all other /foo{,/.*} will be servered by foo.war
* all other {,.*} will be served by ROOT.war


@James: This will even work with Tomcat 6 ;)


Greetings

Guido

>-Original Message-
>From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com]
>Sent: Thursday, August 23, 2018 4:19 AM
>To: Tomcat Users List 
>Subject: RE: Contexts: can there be a hierarchy?
>
>Not really a hierarchy, but just name your .war files (or directories) 
>appropriately:

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

RE: Cluster more than 2 tomcat servers

[Jäkel , Guido]

Dear Tim,

maybe you can do an "independent" check using the JGroups lib stand-alone, 
which offers two sets of a cluster demo. This may help to narrow down the issue 
to the Tomcat setup or the "other" (OS or network configuration) areas.

Please refer to  http://www.jgroups.org/tutorial-3.x/html_single/ , section 
"1.4. Running a Demo Program"

You just need the lib and a JVM, i.e. you can use it out of the box at your 
Tomcat machines. The "Draw Demo" requires Graphics, but you also may use 
another Testcase offering a textmode receiver and sender. You may start this 
receivers on every machine and then one or more senders on demand.

On both demo's, cluster status messages are displayed on stdout.


Here my somewhat older starter scripts:


root@genless /opt/jgroups # cat _receiver 
( cd `dirname $0` || exit 1
java -cp jgroups.jar org.jgroups.tests.McastReceiverTest -mcast_addr 
224.10.10.10 -port  $@
)

root@genless /opt/jgroups # cat _sender 
( cd `dirname $0` || exit 1
java -cp jgroups.jar org.jgroups.tests.McastSenderTest -mcast_addr 224.10.10.10 
-port  $@
)

root@genless /opt/jgroups # cat _draw-demo 
( cd `dirname $0` || exit 1
java  -Djava.net.preferIPv4Stack=true -cp jgroups.jar  org.jgroups.demos.Draw $@
)

root@genless /opt/jgroups # tree
.
|-- _draw-demo
|-- _receiver
|-- _sender
|-- _src
|   |-- jgroups-2.9.0.GA.jar
|   `-- jgroups-3.0.10.Final.jar
`-- jgroups.jar -> _src/jgroups-3.0.10.Final.jar


Yours

Guido

RE: mod_proxy_http and "Expect: 100-continue" don't play well

[Jäkel , Guido]

Dear Michael,

i don't know if this issue also take happen with it, but may be using  mod_jk  
an option for you, also?

Greetings

Guido

>-Original Message-
>From: Michael Osipov [mailto:micha...@apache.org]
>Sent: Wednesday, July 04, 2018 9:26 PM
>To: users@tomcat.apache.org
>Subject: mod_proxy_http and "Expect: 100-continue" don't play well
>
>Hi folks,
>
>[...]
>
>Is there any remedy to this? I will try mod_proxy_ajp tomorrow. If no
>solution is available, this will basically mean that I have to drop
>HTTPd proxying the requests and lose potential balancing features in the
>future for this service.
>
>Michael

RE: RE: mod_proxy_http and "Expect: 100-continue" don't play well

[Jäkel , Guido]

Dear Michael,

I wasn't faced by this yes, but what's about adding something like


RequestHeader unset Expect early


at the Apache httpd?

Greetings

Guido

>-Original Message-
>From: Michael Osipov [mailto:1983-01...@gmx.net]
>Sent: Thursday, July 05, 2018 2:03 PM
>To: users@tomcat.apache.org
>Subject: Re: RE: mod_proxy_http and "Expect: 100-continue" don't play well
>
>
>> Dear Michael,
>>
>> i don't know if this issue also take happen with it, but may be using  
>> mod_jk  an option for you, also?
>
>Hi Guido,
>
>just installed mod_jk through ports and configured it. No avail, I have the 
>very same issue.
>I will raise this on the HTTPd mailing list.
>
>Michael
>
>
>> >-Original Message-
>> >From: Michael Osipov [mailto:micha...@apache.org]
>> >Sent: Wednesday, July 04, 2018 9:26 PM
>> >To: users@tomcat.apache.org
>> >Subject: mod_proxy_http and "Expect: 100-continue" don't play well
>> >
>> >Hi folks,
>> >
>> >[...]
>> >
>> >Is there any remedy to this? I will try mod_proxy_ajp tomorrow. If no
>> >solution is available, this will basically mean that I have to drop
>> >HTTPd proxying the requests and lose potential balancing features in the
>> >future for this service.
>> >
>> >Michael
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>
>-
>To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Protocol handler initialization failed, Address already in use

[Jäkel , Guido]

Dear Sergey,

does this actually happen on a restart situation (with less than about 5min 
pausing time)? Then maybe you have a dangling connection (close/time waiting) 
on the TCP stack from the shutdown  of a client connection (or the reverse 
proxy). Please check if any is still open after closing down Tomcat ...

... or after stopping the Container. If it is bridged, did it use a veth 
device? This also don't closed down before the last connection have closed and 
may prevent to creade a new on (with the same name or the same IP).

Greetings

Guido

>-Original Message-
>From: Sergey Esin [mailto:sergey.e...@jetbrains.com]
>Sent: Monday, July 09, 2018 5:12 PM
>To: users@tomcat.apache.org
>Subject: Protocol handler initialization failed, Address already in use
>
>Hi,
>
>I  have not-100% reproducable issue with the latest Tomcat 8.5.32 (Java
>8u172). It happens only time to time.
>
>It's running in docker container under AWS ECS on a separate machine in ECS
>cluster.
>Brigde networking - so the Tomcat container gets it's own IP address.
>
>I have a number of Nio HTTP/1.1 connectors configured in Tomcat and upon
>container startup I can get such issue for _any_ of configured ports:
>
>09 Jul 2018 16:46:03,570 INFO  [Http11NioProtocol ]
>Initializing ProtocolHandler ["http-nio-8080"]
>09 Jul 2018 16:46:03,598 INFO  [NioSelectorPool   ] Using a
>shared selector for servlet write/read
>09 Jul 2018 16:46:03,609 INFO  [Http11NioProtocol ]
>Initializing ProtocolHandler ["http-nio-49080"]
>09 Jul 2018 16:46:03,610 INFO  [NioSelectorPool   ] Using a
>shared selector for servlet write/read
>09 Jul 2018 16:46:03,611 INFO  [Http11NioProtocol ]
>Initializing ProtocolHandler ["http-nio-50080"]
>09 Jul 2018 16:46:03,612 ERROR [StandardService   ] Failed to
>initialize connector [Connector[HTTP/1.1-50080]]
>org.apache.catalina.LifecycleException: Failed to initialize component
>[Connector[HTTP/1.1-50080]]
>at
>org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:112)
>~[catalina.jar:8.5.32]
>at
>org.apache.catalina.core.StandardService.initInternal(StandardService.java:549)
>[catalina.jar:8.5.32]
>at
>org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
>[catalina.jar:8.5.32]
>at
>org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:875)
>[catalina.jar:8.5.32]
>at
>org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
>[catalina.jar:8.5.32]
>at org.apache.catalina.startup.Catalina.load(Catalina.java:632)
>[catalina.jar:8.5.32]
>at org.apache.catalina.startup.Catalina.load(Catalina.java:655)
>[catalina.jar:8.5.32]
>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>~[?:1.8.0_172]
>at
>sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>~[?:1.8.0_172]
>at
>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>~[?:1.8.0_172]
>at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_172]
>at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:309)
>[bootstrap.jar:8.5.32]
>at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:492)
>[bootstrap.jar:8.5.32]
>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>~[?:1.8.0_172]
>at
>sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>~[?:1.8.0_172]
>at
>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>~[?:1.8.0_172]
>at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_172]
>at
>org.tanukisoftware.wrapper.WrapperStartStopApp.run(WrapperStartStopApp.java:400)
>[wrapper.jar:3.5.32]
>at java.lang.Thread.run(Thread.java:748) [?:1.8.0_172]
>Caused by: org.apache.catalina.LifecycleException: Protocol handler
>initialization failed
>at
>org.apache.catalina.connector.Connector.initInternal(Connector.java:995)
>~[catalina.jar:8.5.32]
>at
>org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
>~[catalina.jar:8.5.32]
>... 18 more
>Caused by: java.net.BindException: Address already in use
>at sun.nio.ch.Net.bind0(Native Method) ~[?:1.8.0_172]
>at sun.nio.ch.Net.bind(Net.java:433) ~[?:1.8.0_172]
>at sun.nio.ch.Net.bind(Net.java:425) ~[?:1.8.0_172]
>at
>sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
>~[?:1.8.0_172]
>at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
>~[?:1.8.0_172]
>at
>org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:210)
>~[tomcat-coyote.jar:8.5.32]
>at
>org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1086)
>~[tomcat-coyote.jar:8.5.32]
>at
>org.apache.tomcat.util.net.AbstractJsseEndpoint.init(AbstractJsseEndpoint.java:268)

RE: Certificate based database authentication

[Jäkel , Guido]

Dear Will,

I agree to Your approach. Said that, I also don't have any experience with the 
concrete question, but from my Tomcat and Java experience, I would say that -- 
from a quick look -- the docs 


https://blogs.oracle.com/dev2dev/ssl-connection-to-oracle-db-using-jdbc,-tlsv12,-jks-or-oracle-wallets


https://www.oracle.com/technetwork/topics/wp-oracle-jdbc-thin-ssl-130128.pdf

should provide the information you need.

Good luck to find somebody who have already solved this challenge

Guido

>-Original Message-
>From: Will Nordmeyer [mailto:quark...@gmail.com]
>Sent: Tuesday, July 10, 2018 7:19 PM
>To: Tomcat Users List 
>Subject: Re: Certificate based database authentication
>
>Thanks Andre - I agree it is an oracle driver based question, but
>sometimes here is faster for answers based on people's own life
>experience.

RE: mod_proxy_http and "Expect: 100-continue" don't play well

[Jäkel , Guido]

Dear Michael,

did you give it a try, also? To my knowledge the keyword "early" may hide this 
header from the Apache machinery to act on it. As you said this header is need 
to set for the backend, maybe it's possible to add it again with a normal 
("late") "RequestHeader set". Maybe it's possible to early edit it 
"disfunctional" and to restore it later matched on this.

greetings

Guido

https://httpd.apache.org/docs/2.4/mod/mod_headers.html 
["Early mode is designed as a test/debugging aid for developers. Directives 
defined using the early keyword are set right at the beginning of processing 
the request. This means they can be used to simulate different requests and set 
up test cases, but it also means that headers may be changed at any time by 
other modules before generating a Response.
Because early directives are processed before the request path's configuration 
is traversed, early headers can only be set in a main server or virtual host 
context. Early directives cannot depend on a request path, so they will fail in 
contexts such as  or .

[...]

Except in early mode, the RequestHeader directive is processed just before the 
request is run by its handler in the fixup phase. This should allow headers 
generated by the browser, or by Apache input filters to be overridden or 
modified.

"]

>-Original Message-
>From: Michael Osipov [mailto:micha...@apache.org]
>Sent: Thursday, July 05, 2018 8:07 PM
>To: Tomcat Users List 
>Subject: Re: mod_proxy_http and "Expect: 100-continue" don't play well
>
>Am 2018-07-05 um 14:44 schrieb Jäkel, Guido:
>> Dear Michael,
>>
>> I wasn't faced by this yes, but what's about adding something like
>>
>>  
>>  RequestHeader unset Expect early
>>  
>>
>> at the Apache httpd?
>
>I know that tip, but it makes no sense at all. The client expected
>100-continue, but you are dropping this request header. You effective
>disabling this feature.
>
>>> -Original Message-
>>> From: Michael Osipov [mailto:1983-01...@gmx.net]
>>> Sent: Thursday, July 05, 2018 2:03 PM
>>> To: users@tomcat.apache.org
>>> Subject: Re: RE: mod_proxy_http and "Expect: 100-continue" don't play well
>>>
>>>
>>>> Dear Michael,
>>>>
>>>> i don't know if this issue also take happen with it, but may be using  
>>>> mod_jk  an option for you, also?
>>>
>>> Hi Guido,
>>>
>>> just installed mod_jk through ports and configured it. No avail, I have the 
>>> very same issue.
>>> I will raise this on the HTTPd mailing list.
>>>
>>> Michael
>>>
>>>
>>>>> -Original Message-
>>>>> From: Michael Osipov [mailto:micha...@apache.org]
>>>>> Sent: Wednesday, July 04, 2018 9:26 PM
>>>>> To: users@tomcat.apache.org
>>>>> Subject: mod_proxy_http and "Expect: 100-continue" don't play well
>>>>>
>>>>> Hi folks,
>>>>>
>>>>> [...]
>>>>>
>>>>> Is there any remedy to this? I will try mod_proxy_ajp tomorrow. If no
>>>>> solution is available, this will basically mean that I have to drop
>>>>> HTTPd proxying the requests and lose potential balancing features in the
>>>>> future for this service.
>>>>>
>>>>> Michael
>>>>
>>>> -
>>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>
>
>
>-
>To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>For additional commands, e-mail: users-h...@tomcat.apache.org


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

RE: Tomcat stop and start using bash script

[Jäkel , Guido]

Hi also,

  to archive a full graceful shutdown, it's also save to just send a SIGTERM to 
the JVM running the Tomcat. This will result in invoking exactly the same 
mechanisms as the official top-level methods described by André without the 
need to start an extra VM. The PID should be available by the operating systems 
standard mechanisms as the Application Controll Framework (initd, system), by 
Java tools like jps or by system tools like ps, pidof, ... . To invoke a forced 
shutdown, one may send SIGKILL to the JVM process. 

  The advantage of both is to have a very small footprint and follow the KISS 
pragma, which may especially important in a "out-of-resources" scenario when 
the Tomcat high level interfaces (HTTP/AJP/JMX connector) become disfunctional 
as a side effect.

BTW: If the Application/Tomcat/JVM is "in trouble", one may invoke the JVM 
thread dump facility by sending a SIGQUIT to the JVM, also. Again, this may be 
a "last resort" if you can't command the Tomcat/JVM in a other way.


Greetings

Guido

>-Original Message-
>From: André Warnier (tomcat) [mailto:a...@ice-sa.com]
>Sent: Thursday, June 28, 2018 10:58 PM
>To: users@tomcat.apache.org
>Subject: Re: Tomcat stop and start using bash script
>
>Hi.
>
>I have not followe3d this thread since the beginning, but
>
>The standard tomcat distribution comes with a series of shell scripts in the 
>"bin"
>directory, which do just that : start or stop tomcat. They are conveniently 
>called
>"startup.sh" and "shutdown.sh". You could get inspiration from those.
>
>Since you are talking about bash, it is to be presumed that you are on a Linux 
>system.
>If this Linux system has a package management system, it is very likely that 
>there is a
>tomcat package available. Such tomcat packages come with startup and stop 
>scripts for
>tomcat, which make it easy to start/stop tomcat via a shell command.
>
>Furthermore, look at the on-line documentation. In
>http://tomcat.apache.org/tomcat-9.0-doc/config/server.html#Common_Attributes, 
>you will
>find the "shutdown" attribute and its explanation. It basically means that if 
>you open a
>TCP/IP socket to the given port (which you can do with bash), and send the 
>indicated
>string on that connection, tomcat will initiate a shutdown.
>
>And that's in fact what the standard shutdown.sh does, though using a 
>roundabout way : it
>starts another java jvm instance which runs another temporary instance of 
>tomcat, which
>just does one thing : send this shutdown string to the appropriate (main 
>instance of
>tomcat's) shutdown port (and then it shuts itself down).
>
>So it looks like there are a lot of ways to achieve what you want, and you 
>only need to
>pick the right one for you.

mod_jk: Forwarding URLs containing escaped slashes (e.g. for REST services) fail with syntactical-wrong double-escaping

[Jäkel , Guido]

Hi all,

I have problems to pass (REST-) URLs containing escaped slashes ('%2F') in path 
elements using the  Apache httpd  and  mod_jk  to the application server (in 
fact not Tomcat, but Wildfy. But this is of no matter, here).

This kind of URL may be accepted by the httpd using the option 
'AllowEncodedSlashes=NoDecode'. But then, while using the mode 
'ForwardURIProxy' for mod_jk , they are re-encoded in a bad way: As '%252F', 
because the percent sign itself is escaped by accident. The result is a 
syntactically bad URL which is rejected by the application server.

I already filed this last week as  
https://bz.apache.org/bugzilla/show_bug.cgi?id=62459 . Please, may take some 
maintainer a look at this?

with greetings

Guido

RE: mod_jk: Forwarding URLs containing escaped slashes (e.g. for REST services) fail with syntactical-wrong double-escaping

[Jäkel , Guido]

Dear Markus,

I'm not using Tomcat as backend here. And in addition, this will not help in 
case of syntactically wrong URL patterns like '%252F' produced by mod_jk.

thank you, anyway -- maybe emphasizing this option is useful for others here 
using Tomcat.

Guido

>-Original Message-
>From: i...@flyingfischer.ch [mailto:i...@flyingfischer.ch]
>Sent: Wednesday, June 20, 2018 12:52 PM
>To: users@tomcat.apache.org
>Subject: Re: mod_jk: Forwarding URLs containing escaped slashes (e.g. for REST 
>services) fail with syntactical-wrong double-
>escaping
>
>> Hi all,
>>
>> I have problems to pass (REST-) URLs containing escaped slashes ('%2F') in 
>> path elements using the  Apache httpd  and  mod_jk
>to the application server (in fact not Tomcat, but Wildfy. But this is of no 
>matter, here).
>>
>> This kind of URL may be accepted by the httpd using the option 
>> 'AllowEncodedSlashes=NoDecode'. But then, while using the mode
>'ForwardURIProxy' for mod_jk , they are re-encoded in a bad way: As '%252F', 
>because the percent sign itself is escaped by
>accident. The result is a syntactically bad URL which is rejected by the 
>application server.
>>
>> I already filed this last week as  
>> https://bz.apache.org/bugzilla/show_bug.cgi?id=62459 . Please, may take some 
>> maintainer a
>look at this?
>>
>> with greetings
>>
>> Guido
>>
>
>You may want to create setenv.sh in CATALINA_HOME/bin with the following
>option:
>
>export
>JAVA_OPTS="-Dorg.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true"
>
>
>Markus
>
>-
>To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>For additional commands, e-mail: users-h...@tomcat.apache.org


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

RE: problem in starting tomcat

[Jäkel , Guido]

>> When I am trying to start my server I got following error as:
>> A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  SIGSEGV (0xb) at pc=0x7fd4f206e28a, pid=2412, tid=2412
>> #
>> # JRE version:  (11.0+18) (build )
>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (11-ea+18, mixed mode, aot, 
>> sharing, tiered, compressed oops, g1 gc, linux-amd64)
>> # Problematic frame:
>> # C  [libc.so.6+0x8128a]  strlen+0x2a
>
>This is saying that the segfault occurred in libc code, specifically the
>strlen function.  This suggests that either the JVM is using the libc
>library incorrectly, or that the libc library on your system is bad.


From your hs_er_pid.txt I read:

---  S Y S T E M  ---

OS:Red Hat Enterprise Linux Server release 7.5 (Maipo)
uname:Linux 3.10.0-693.el7.x86_64 #1 SMP Thu Jul 6 19:56:57 EDT 2017 
x86_64
libc:glibc 2.19 NPTL 2.19

[...]

vm_info: Java HotSpot(TM) 64-Bit Server VM (11-ea+18) for linux-amd64 
JRE (11-ea+18), built on Jun 13 2018 20:25:53 by "mach5one" with gcc 7.3.0


So you're providing a somewhat older  glibc 2.19  (released 20140208) but the 
JVM you're using was built recently (20180513). Did you compile this JVM? Was 
it compiled against a fittig version of glibc? I would strongly suggest to use 
a JRE/JDK package provided by your Linux Distribution.


Greetings

Guido

RE: Tomcat embedded with Apache Solr

[Jäkel , Guido]

Dear Christopher,

my 5ct on that: We're using Solr for years like (and together with) all other 
Webapps on Tomcat (and since some month on Wildfly) in a "classic" (non-cloud) 
setup without any the need for special tweaks.

There is no official support for an webapp artifact since some Versions, but 
one just have to extract the web application tree from the release.

I have no experience with embedded tomcat, but it should be also straight 
forward. Said that, I can't imagine the advantage of such an approach against 
the currently used, which just start the Web Application Server (Jetty, Tomcat 
or whatever) with the preinstalled Solr application.

We even have used it in the other way round: We used an embedded Solr Server as 
a SolrMaster instead of a SolrClient within an Ingest application to avoid the 
"serialization/network overhead" of big Solr documents. This Application was 
also hosted together with others on our Tomcat plattform


With greetings

Guido

>-Original Message-
>From: Christopher Schultz [mailto:ch...@christopherschultz.net]
>Sent: Sunday, October 14, 2018 3:41 AM
>To: Tomcat Users List 
>Subject: Tomcat embedded with Apache Solr
>
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA256
>
>All,
>
>I've posted a question to the Solr mailing list[1] about why Jetty is
>being used instead of Tomcat, and it seems that it's just "always the
>way it's been" for the most part.
>
>These seems to be some interest in moving from their existing model
>(Jetty launches, then hosts Solr as a web application) to an embedded
>model where a Solr-agent launches and then launches the app server
>(e.g. tc) hosting itself.
>
>Is anyone familiar enough with Solr to whip-up a quick-and-dirty POC
>for Tomcat-embedded-hosting-Solr?

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

RE: JVM keystores and CA

[Jäkel , Guido]

Dear Igor,

>> 3. In case JAVA_HOME/lib/security/cacerts is my trust store (the default) I 
>> would
>> expect Java to use the system store(s) too in case a certificate can not be 
>> validated
>> simply because a CA is missing in the Java store. Example, DigiCert Global
>> Root G2 CA is missing in the Java versions older than 8u91 causing 
>> inexplicable
>> PKIX exceptions but can be found in the system store, both under 
>> /etc/ssl/certs and
>> /usr/share/ca-certificates which are (much) more frequently updated with new 
>> certs than Java versions.
>> This actually applies to the case of custom trust store even more so
>>
>> Thoughts?

Because Java is platform-independent, it have an own store and don't use any of 
the underlying OS. But one told me that on some Linux distributions, there's a 
script tool to update the Java cert store from the CA-Certificates-Package. 
Using such a tool you get the update more frequently. 

But actually you probably don't need. You wrote about using Java8u91, which is 
simply complete out of date because the latest is Java8u192. I you complain 
about security things like an outdated certificate store, you simply should 
install a Java version as recent as the CA-Certificates package of the hosting 
OS. Any you will catch other JAVA bugs and security issues by the way, too.

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

RE: JVM keystores and CA

[Jäkel , Guido]

Dear Igor and others,

in this context maybe the attached Java program together with this script is 
useful for you ...


#!/bin/bash

if [ -z "$1" ]; then
  cat >&2 <<-EOT
syntax : $0 [-d] [-a] 
purpose: check ssl certificate path. Use [#] to add to keystore"
options:
  -ddebug ssl handshake
  -aadd certificate (if not already trusted)
EOT
  exit -1
fi

[ "$1" == "-d" ] && shift && DEBUG="-Djavax.net.debug=ssl:handshake" && 
echo "DEBUG MODE" >&2
ACTION="q"; [ "$1" == "-a" ] && shift && ACTION="1"

echo $ACTION | java $DEBUG InstallCert $*


greetings

Guido

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

RE: JVM keystores and CA

[Jäkel , Guido]

>Just to make it clear, when I mentioned Java8u91 as an example I meant for
>the time when lets say Java8u81 was latest at that moment. In that case
>when using the built in JVM store you would encounter failed connections to
>servers with G2 signed certificates. Then as you said you would need to
>import it into the JVM store by yourself or wait for the next Java release
>that would include it by default i.e. Java8u91

I understand your meanings, but I wonder if the release interval of the 
"CA-Certs Distro package" is shorter than that from Java and first of all if 
it's likely that one will use a certificate chained with a "brand-new" CA 
that's not in the common trust stores :)

RE: Number of Web Applications in one Tomcat

[Jäkel , Guido]

>-Original Message-
>From: Torsten Krah [mailto:krah...@gmail.com]
>Sent: Tuesday, October 30, 2018 2:55 PM
>To: users@tomcat.apache.org
>Subject: Re: Number of Web Applications in one Tomcat
>
>Am Dienstag, den 30.10.2018, 14:39 +0100 schrieb Ahmed, Tarek:
>> "With Tomcat 7.0.23+ you can configure it to start several web
>> applications in parallel. This is disabled by default but can be
>> enabled
>> by setting the startStopThreads attribute of a *Host* to a value
>> greater
>> than one."
>
>But be aware that you may run into problem with this one - look e.g.
>here:
>
>https://www.mail-archive.com/users@tomcat.apache.org/msg127141.html
>
>Cheers
>
>Torsten

I'm pretty sure that this problem is just caused by malformed applications that 
include some XML stuff inside the application that MUST NOT include, but have 
to be provided instead by the platform -- e.g. as JVM endorsed libs. A common 
case is that application A provide and register some implementation of an API 
at JVM level and application B provide this also, but with another version. 
Then, one of the application will use at runtime another lib as at compile time.

Without parallel start, this might seem to work (or not) in a stable way. But 
with parallel start, you get race conditions.

RE: Number of Web Applications in one Tomcat: THANKS!

[Jäkel , Guido]

>Has anyone ever attacked one of your web applications? There are some
>fun ways to make an application use a huge amount of memory. Just
>because the applications themselves are behaving doesn't mean that all
>the users are behaving.
>
>For example, do you have a max POST size set for your application? If
>not, I can send your login form a username that is so long it might
>exhaust your heap. 2147483647 characters is a LOT of characters.
>
>If you have a max POST size, maybe you don't filter-out PUT requests,
>and have Tomcat parsing those for you. Same problem, there.

Dear Chris,

But that's no argument for or against running more than one application per 
Tomcat: If you're not aware of such things, one may attack your other Tomcats 
in the same way because of identical configuration. Of course, if you plan to 
run a couple of applications per Tomcat, you may also plan to spread it to more 
than instance to have a fail-over or load balancing . But even if you use a 
HA-cluster with one App per cluster member: If one is able to crash the 
Application by a Request on one cluster member, this might be repeated on the 
other members without noteworthy costs.

RE: Default context.xml with parallel deployment

[Jäkel , Guido]

Dear Giles,

what aspects do you use in you  myapplication#foo.xml ? You may symlink this 
files from an application-specific master template, e.g. myapplication.xml

greeatings

Guido

>-Original Message-
>From: Gilles SCHLIENGER [mailto:gilles.schlien...@cncc.fr]
>Sent: Thursday, November 08, 2018 9:46 PM
>To: users@tomcat.apache.org
>Subject: Default context.xml with parallel deployment
>
>Hi everyone,
>
>We are using Tomcat 9.0.8.
>
>We are using xml context files in  
>$CATALINA_BASE/conf/[enginename]/[hostname]/ to store the database connexion 
>information.
>
>When using parallel deployment, I understand that you should use for specific 
>context xml files :
>- for myapplication##1.war : myapplication##1.xml
>- for myapplication##2.war : myapplication##2.xml
>
>We would like to have a default context xml file ONLY available for the « 
>myapplication » application but for all versions
>
>It seems we could use a file called « context.xml.default » but the properties 
>would be also available to other applications,
>which we don't want.
>
>Is there a way to have a context.xml file available to all versions of the 
>same application or any other way to do it ?
>
>Thanks a lot in advance !
>Regards
>Gilles

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

RE: log4j: Logging to same file from multiple contexts?

[Jäkel , Guido]

Dear Dave,

I walk through that years before, too.

Yes - you can't let write different Log4J Appenders to the same file or you get 
this garbage.

Yes - you have property resolving here, but there are no properties you need.


We did a solution using an additional servlet called at application init that 
temporary define a property from the application parameters like virtual host 
and context path, write out the first logging entry to let initialize Log4J 
here, i.e. read the configuration file with the current parameter and finally 
undefine the parameter (for savety). This sequence has to by synchronized by an 
JVM-wide singleton to prevent parallel execution in case you have more than one 
application using this. Write me an email if I should search for the source 
code.


Another solution is to use a SocketAppender and an "central" receiver anywhere 
(running with a standalone JVM)


  <-- 
this name is NOT related to log4j, you may choose any you want.













[...]



  <-- local file logging



The AsyncAppender is chained on top to have a fuse not to block logging (and 
the application) in case of trouble with the receiver.


Greetings

Guido

>-Original Message-
>From: David Filip [mailto:dfi...@colornet.com]
>Sent: Monday, October 08, 2018 8:28 PM
>To: users@tomcat.apache.org
>Subject: log4j: Logging to same file from multiple contexts?
>
>Dear Tomcat Users,
>
>Apologies if this is more of a log4j question, but I thought that I'd start 
>here, in case Tomcat has any easy remedies.
>
>I have a common webapp that I deploy to multiple, different contexts.
>
>In log4j.properties, I have a few different log files defined, e.g., for 
>logins:
>
>log4j.appender.logins=org.apache.log4j.DailyRollingFileAppender
>log4j.appender.logins.file=${catalina.home}/logs/logins.log
>log4j.appender.logins.datePattern='.'-MM-dd
>log4j.appender.logins.append=true
>log4j.appender.logins.layout=org.apache.log4j.PatternLayout
>log4j.appender.logins.layout.ConversionPattern=[%d{MM/dd/ HH:mm:ss}] [%p] 
>[%C{1}]: %m%n
>
>log4j.logger.com.colornet.CAP.Actions.LoginAction=info, logins
>log4j.logger.com.colornet.CAP.Util.LoginTokenTag=info, logins
>
>However, as you may have guessed, if I have the same log4j configuration file 
>for each context, the contexts tend to over-write
>each other.
>
>Is there any way to have the SAME log4j.properties deployed too multiple 
>contexts play nicely and not overwrite each other, but
>merely append each other?
>
>Extra credit question (although sounds even more like a log4j question, so 
>apologies): If not, is there any way to define the
>file path, e.g.:
>
>log4j.appender.logins.file=${catalina.home}/logs/logins.log
>
>to include the specific context?  I have found a few references on the 'Net, 
>e.g., ${contextPath}, ${servletName}, etc., which
>don't seem to work.
>
>My goal (desire?) is to have the same webapp and configuration and web.xml and 
>log4j.properties, etc., deployed to every web
>context, but not have one context overwrite another content's entries.
>
>Of course, as the Mick once said, "You can't always have what you want".
>
>Please let me know if this is possible.
>
>Thanks,
>
>Dave.
>
>
>


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

RE: SSL on Tomcat

[Jäkel , Guido]

Dear Loai,

Your client can't very (don't trust) the certificate (chain) of the target. 
Either target's certificate is not an "official" one (e.g. self signed) or your 
clients JVM certificate trust chain is not up to date.

I you like I may send you a small java commandline tool to check the 
verification chain and/or add exceptions to the local trust store in case of 
self-signed certificates.

Guido


>-Original Message-
>From: Loai Abdallatif [mailto:loai.abdalla...@gmail.com]
>Sent: Thursday, September 27, 2018 4:52 PM
>To: Tomcat Users List 
>Subject: Re: SSL on Tomcat
>
>hello, shall I add the certificate to server.xml on tomcat server or just on 
>Webserver
>
>
>On Thu, Sep 27, 2018 at 5:50 PM, Loai Abdallatif  > wrote:
>
>
>   Hello,
>
>   I have Set Apache Load Balancer ( ModJK) with Server IP 192.168.1.120 
> (Webserver01.epsilon.test)  which forward the
>traffic to tomcat server .(192.168.1.111 (appserver01.epsilon.test)
>
>
>   each tomcat server has three workers ( 0,1,2)
>
>   I deployed Central Authentication Service (CAS)  on Worker0  and its  
> is working with warning related to ssl
>Certificate, I have another Application on this worker0 called ServiceCatalog 
>unfortunatly it didnt work and gave error as below
>
>
>
>
>
>
>
>
>   ERROR org.jasig.cas.client.util.CommonUtils - 
> sun.security.validator.ValidatorException: PKIX path building failed
>: sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
>valid certification path to requested
>target
>   javax.net.ssl.SSLHandshakeException: 
> sun.security.validator.ValidatorException: PKIX path building failed: sun.sec
>urity.provider.certpath.SunCertPathBuilderException: unable to find valid 
>certification path to requested target
>   at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
>   at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1964)
>   at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:328)
>   at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:322)
>   at 
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1614)
>   at 
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
>   at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052)
>   at 
> sun.security.ssl.Handshaker.process_record(Handshaker.java:987)
>   at 
> sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1072)
>   at 
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1385)
>   at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1413)
>   at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1397)
>   at 
> sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
>   at 
> sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnectio
>n.java:185)
>   at 
> sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1564)
>   at 
> sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492)
>   at 
> sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:263)
>   at 
> org.jasig.cas.client.util.CommonUtils.getResponseFromServer(CommonUtils.java:429)
>   at 
> org.jasig.cas.client.validation.AbstractCasProtocolUrlBasedTicketValidator.retrieveResponseFromServer(A
>bstractCasProtocolUrlBasedTicketValidator.java:41)
>   at 
> org.jasig.cas.client.validation.AbstractUrlBasedTicketValidator.validate(AbstractUrlBasedTicketValidato
>r.java:193)
>   at 
> org.springframework.security.cas.authentication.CasAuthenticationProvider.authenticateNow(CasAuthentica
>tionProvider.java:157)
>   at 
> org.springframework.security.cas.authentication.CasAuthenticationProvider.authenticate(CasAuthenticatio
>nProvider.java:142)
>
>
>

RE: Application hanging on Tomcat 7.0.54

[Jäkel , Guido]

Dear Louis,

I would recommend to use a tool like JVisualVM (with Plugins*) to take a look 
on this things while it's still running or have blocked. You may live watch 
things like running threads or the Java heap occupation or investigate JVM, 
Java and Tomcat parameters (and even run some actions) via JMX with 
"MBean-Explorer". You may trigger to generate a heap dump or force FullGC and 
even do CPU or Memory profiling.

The Tomcat JDBC Connection Pool for instance provide a MBean view for every 
connection with it's parameters. You may live watch the number of active, idle, 
... connections (with a "well hidden" chart feature: Double-Click to expand 
some value representations; this here to a chart)

Tomcat (i.e. Catalina) have something like a running request scoreboard, also. 
You may take and identify from that all long running or blocked requests. On 
the MBean, it's at 
"Catalina|RequestProcessor|||currentURI" and 
corresponding parameters.


(*) You would have to install some plugins inside the JVisualVM Tool, e.g. 
"Visual GC", "VisualVM Buffer Monitor", "Thread Inspector", "VisualVM BMeans"

Greetings

Guido

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

RE: Request for a technical review

[Jäkel , Guido]

Dear Mallory and Mark,

  then I'm the one of the rare who use an "unusual" setups for more than 10 
years :) . On a staged farm of about 3*10 Tomcat's we run a whole bunch of 
"webapps"; most of them in at least two instances for failover.

  But I never configured more than one Service and one Engine: There is only 
one Service , with an AJP Connector for the reverse proxy (Apache httpd + 
Jakarta) and a http Connector for service purposes. Inside, there is one Engine 
and inside this, there are a bundle of Hosts for each domain needed for the 
applications and inside each hosts (using an individual appBase for each 
domain), the deployments spawn contexts for each application running. Among 
this hosts, there's also a "localhost" taking the admin applications. This one 
is addressed via the http Connector.

Guido

>-Original Message-
>From: Mark Thomas [mailto:ma...@apache.org]
>Sent: Wednesday, December 12, 2018 3:26 PM
>To: users@tomcat.apache.org
>Subject: Re: Request for a technical review
>The first architecture diagram:
> - doesn't show any hosts
> - incorrectly classes a "Service" as a "webapp" (a context is a webapp)
> - shows the unusual setup of multiple services

RE: Using tomcat manager to deploy to several services

[Jäkel , Guido]

Dear Frank,

I don't agree that this is "better". It will trigger the same things in the 
backend in the end. And obviously don't need the Tomcat Connector to be 
available.

This might be important in situation with some malfunctions caused by near-OOM 
or out-of-request-workers (caused by long running or blocked requests). 

In my Tomcat farm control scripts, I also never use the "shutdown port" 
mechanism to (graceful) stop the Tomcat but send a SIGTERM to the JVM. Again, 
this will do the same thing but need much less to be fuctional. And if a 
graceful shutdown will fail, one even need to SIGKILL the JVM.

>-Original Message-
>From: Frank Schullerer [mailto:schulle...@googlemail.com.INVALID]
>Sent: Tuesday, December 04, 2018 4:06 PM
>To: users@tomcat.apache.org
>Subject: Re: Using tomcat manager to deploy to several services
>
>Hello,
>
>thanks for the answer. That is exactly the way how we do this today (all
>via a shell script and via Jenkins). But I thought the
>"official" way to start/stop/deploy/reload applications via   e.g.  "curl
>http://localhost:8080/manager/text/reload?... " is better
>
>Greetings

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

RE: Using tomcat manager to deploy to several services

[Jäkel , Guido]

Dear Frank,

I guess you have configured autodeployment of the WARs. And it seems to me that 
you want to use a tree in a filesystem to place your deployments. Given that, 
you may use an arbitrary way to place the WARs to that location, because it's 
not the Tomcat Manager application that actually perform the deployment.

You may trigger a restart of the application container by touching the WAR or 
(in case of an expanded deployment) touching a watched file (common 
WEB-INF/web.xml) and trigger undeploy by removing (or hiding by rename the 
extention) the WAR.

>If there is a better way and have a tomcat manager to deploy all applications, 
>please let me know!


with greetings

Guido

RE: Using tomcat manager to deploy to several services

[Jäkel , Guido]

>Does it really ? If some tomcat code is at that time processing a client POST 
>request,
>which potentially modifies data on the server (or a back-end database), is 
>ditto tomcat
>code "informed" of the JVM shutdown, and does it have time to interrupt the 
>processing in
>some predictable/recoverable way ?

In no other way than a Tomcat worker get informed about a Tomcat shutdown if 
you trigger this event e.g. by the shutdown port mechanism or JXM. OT a feature 
of Tomcat is that it will first stop accepting new requests by the connectors 
and let the servlet containers stop the applications afterwards. Therefore, a 
started request will be finished. And after all request workers are idle, the 
worker pool will terminate.

If you send a signal to a process, nothing is "interrupted" but just a consumer 
in the process get signaled - that's why it's called this way. And that's the 
reason why a process might not stop if you send a SIGTERM to it. It's just a 
request to please the process to terminate by itself. Some signals are handled 
outside the process, for simplification let's say by the process scheduler. If 
one send a SIGKILL, the scheduler will "hard kill" the process (and it's 
threads) at any point of execution path and just recover the reserved resources.

RE: tomcat manager gui hangs on web-app reload for one web-app not others

[Jäkel , Guido]

Dear Bill,

usually the Tomcat is configured in such a way that it watches the file  
.../WEB-INF/web.xml  of your application an reload the application then. If you 
use autodeploy of a WAR, it's the same with the archive file.

Said that, may you please try to reload your application by just touching a 
watched file? If you use this second way to command a reload, the issue should 
be narrowed in that way that the Tomcat itself works well and enter the 
shutdown lifecycle of the servlet container. And then it's caused by the 
application don't to react on this.

Guido

>-Original Message-
>From: Bill Harrelson [mailto:bill.harrel...@accordare.com]
>Sent: Thursday, September 13, 2018 10:14 PM
>To: users@tomcat.apache.org
>Subject: tomcat manager gui hangs on web-app reload for one web-app not others
>
>Tomcat 8.0.14, Java 1.8.0_91. I've looked through StackOverflow and
>searched the archives and can't figure this out. We've been running
>tomcat, various versions for about 15 years, always using the
>manager-gui to control hosts. We have one tomcat instance running 8
>hosts, where the manager-gui works fine for all but one of them. I've
>compared /conf/Catalina/WEBAPPname/manager.xml with others that are
>working and they are identical. I've compared the directory name with
>the name in server.xml and it's identical. Behavior - when I start the
>manager-gui for that web-app, it logs in and starts fine. I can see
>sessions, I can see Server Status, etc.  all seems to work, except: -
>if I click on Reload or Stop, it just sits and spins and eventually
>times out. Every other host manager gui gets an immediate tab name
>update, then completes, changing the url. This one web-app does none of
>that. When this happens there are no entries in the catalina log, the
>tomcat stderror log, or the web-app access log I can't figure out where
>to look next. Any help would be appreciated. Thanks. It's a test server
>and having to restart all of tomcat to change the test configuration is
>slowing work way down. Bill

RE: Monitoring resources comsumption at context level

[Jäkel , Guido]

Hi,

that's a question that is not specific to Zabbix or Tomcat but to all kind of 
cases that use *one* JVM to run more than one "Application". And that's also an 
open point to me since nearly decades. 

Some years ago I googled something that is called "Classmexer" (as a 
subproject(?) of something that is called "Javamex"

https://www.javamex.com/classmexer/

This seems to provide a Package that may calculate the memory consumption of an 
java object (tree?). Maybe, by help of this, on may be able to calculate what's 
the memory attatched to a certain classloader or servlet container. Maybe some 
Java guru here can take a look at this, it even seem to provide a JMX 
instrumentation interface, yet.

If it is possible to use this an if it's not a real expensive operation, then 
somebody may develop a kind of adapter to be used for Tomcat or other 
Application Servers.


@Fellipe: There are some tools to examine a JVM heap dump, but -- as me -- 
that's not you're looking for. Dumping the heap on a running JVM is a 
stop-world-event that will take significant time in case of the usecase here, 
where the heap of the Tomcat JVM will be sized to many GBs to serve a couple of 
applications. From this, in a production environment one may pull a heap dump 
for offline debugging purposes in case of already ongoing trouble. But it's not 
appropriate for continuous monitoring.

Guido



>-Original Message-
>From: Christopher Schultz [mailto:ch...@christopherschultz.net]
>Sent: Friday, April 05, 2019 12:35 AM
>To: users@tomcat.apache.org
>Subject: Re: Monitoring resources comsumption at context level
>
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA256
>
>Fellipe,
>
>On 4/4/19 16:51, Fellipe Theophilo wrote:
>> Hi Cris, thank you for reply. So, I've talked to the developer team
>> about this and they told me that they want to be able to know at
>> OBJECT level or at CLASS level what is consuming more resources, to
>> make easier to debug the code. For example, suppose that some JVM
>> is having high resource comsumption, they want to know what CLASS,
>> or what METHOD is the responsible for the issue. Is there any way
>> to do it?
>
>Your developer team should already know that the only way to do that
>would be to take a heap dump or attach a debugger to a running JVM.
>What they want is simply not possible via JMX.
>
>Taking a heap dump can cause your JVM to stall for an indeterminate
>amount of time.

RE: Monitoring resources comsumption at context level

[Jäkel , Guido]

>Some years ago I googled something that is called "Classmexer" (as a 
>subproject(?) of something that is called "Javamex"
>
>   https://www.javamex.com/classmexer/
>

I just noticed, that I also have bookmarked an post called "Instrumentation 
Memory Counter"

https://www.javaspecialists.eu/archive/Issue142.html

to deal with related things ...

RE: Crash in http connector random once a day

[Jäkel , Guido]

>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.

RE: Crash in http connector random once a day

[Jäkel , Guido]

Dear Daniel,

a request is logged in the access log after it has finished. (In addition, on 
Tomcat the log is flushed with some delay, but that's not the problem here).

But if the request is stall while processing, there's no hint in the access 
log. Therefore: Is there an application log that may confirm that the request 
have reached the application on Tomcat and have start to process?

On Tomcat, there's also a request scoreboard feature where you may "live watch" 
outstanding requests. You may access to it via the Tomcat Host Manager 
Application. As a hint, I may also provide you a short (Unix) script to readout 
this from the MBean by HTTP via the jmxproxy-Feature of the Manager.

Greetings

Guido

>-Original Message-
>From: Daniel Castilla | thin(k)design [mailto:d...@thin-k-design.com]
>Sent: Thursday, March 14, 2019 11:10 AM
>To: users@tomcat.apache.org
>Subject: Crash in http connector random once a day
>
>The strange thing is, those failed requests with no response are
>logged in the tomcat access logs with a 500 http connection error all
>at the same time (although they begun with 1-2 min difference) and
>after 8 to 24 hours (the URL is alway unique, so I know for sure).

RE: How to add an header field to all requests unconditionally

[Jäkel , Guido]

Dear Thomas,

you may include a filter servlet into the application to modify the response 
header. A quick search offers e.g.  https://gist.github.com/danlangford/3669475 
, which states to implement a generic, configurable Response Header Filter.

You may compile this servlet independent from an existing application, 
therefore you may tweak even existing WARs with this.

Guido

>-Original Message-
>From: Thomas Meyer [mailto:tho...@m3y3r.de]
>Sent: Wednesday, March 13, 2019 10:43 AM
>To: users@tomcat.apache.org
>Subject: How to add an header field to all requests unconditionally
>
>Hi,
>
>what would be the easiest way to uncoditionally add an header field to
>all requests coming from a given connector?
>I searched the provided Valves but there seems to be no support for my
>requirment.
>
>with kind regards
>thomas
>
>
>
>
>-
>To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>For additional commands, e-mail: users-h...@tomcat.apache.org

RE: How to add an header field to all requests unconditionally

[Jäkel , Guido]

>-Original Message-
>From: André Warnier (tomcat) [mailto:a...@ice-sa.com]
>Sent: Wednesday, March 13, 2019 12:11 PM
>To: users@tomcat.apache.org
>Subject: Re: How to add an header field to all requests unconditionally
>
>The OP wants to insert a *Request* header, not a Response header.
>As I recall, that is a bit more complicated, because under Tomcat the Request 
>is
>immutable, so you have to subclass it, and add the header dynamically when the 
>application
>issues a request.getHeaders call or so.

Oh sorry, I misinterpreted that. 

@Thomas: By other words, you want to know something about the destination of 
your request. To be curious I want to know what the different Connectors are 
used for? Maybe there's another thing associated with the Connector that is 
more easy to detect for the application.

-
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

[Jäkel , Guido]

>-Original Message-
>From: Johanes Soetanto [mailto:otnat...@gmail.com]
>Sent: Tuesday, March 12, 2019 9:03 PM
>To: Tomcat Users List 
>Subject: Re: Followup2: Changed behaviour of Tomcat 
>Deployment/Context/Lifecycle Manager concerning symbolic links
>
>Hi all,
>
>On Tue, 12 Mar. 2019, 9:45 pm Jäkel, Guido,  wrote:
>
>Correct me if I'm wrong. The original reason of this discussion if the file
>extension does not end with war right? I don't see from test above that the
>links do not ends with war. Or is it because of trailing dot at the end?

Dear Johanes,

Yes, that sufficient because internal it's checked by endWith('.war'). In my 
case, the filename ends with a version and a deployment node descriptor 
appended. But you may append whatever you want and/or even left out the string 
"war".

Guido

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

[Jäkel , Guido]

Dear Mark Thomas, other developers and list members, 

caused by the requirement of an external software product, I currently have to 
upgrade a Tomcat-8.5 installation from Tomcat-8.5.23 to >=8.5.32 and therefore 
I concretely choose 8.5.38. As I expect from a minor update, in the first 
moment this is a smooth thing. But surprisingly I run in a very strange issue: 
There is -- at least for me -- a remarkable change in the behavior of the 
handling of WAR deployments: If the deployment unit is a symbolic link, the new 
version will not use anymore the "extension" of the name of the symbolic link 
to determine the "kind of application" but will "resolve" the link(s) and use 
the tail of the name of the final destination instead:

* If I a deployment is a file named 'foo.war', all works well as before and 
expected. 
* If it an symbolic link named 'foo.war' pointing to '[/]bar.war', 
also all works as before and expected (i.e. the root context name is 'foo')
* But now and in contrast to before: if the link destination don't have the 
extension '.war', the deployment process will fail. 

From this, after establishing the link

foo.war -> /some/fill/path/to/destination/bar.an_extension

for deployment, with the newer Tomcat version I get the error

20190308-092433.557 ERROR [catalina-exec-38] [] [[/manager]] FAIL - 
Application at context path [/foo] could not be started
org.apache.catalina.LifecycleException: Failed to start component 
[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/foo]]
at org.apache.catalina.util.LifecycleBase.start(Unknown Source)
at org.apache.catalina.manager.ManagerServlet.start(Unknown 
Source)
at org.apache.catalina.manager.HTMLManagerServlet.start(Unknown 
Source)
at 
org.apache.catalina.manager.HTMLManagerServlet.doPost(Unknown Source)
at javax.servlet.http.HttpServlet.service(Unknown Source)
at javax.servlet.http.HttpServlet.service(Unknown Source)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Unknown Source)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(Unknown Source)
at 
org.apache.catalina.filters.CsrfPreventionFilter.doFilter(Unknown Source)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Unknown Source)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(Unknown Source)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(Unknown 
Source)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Unknown Source)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(Unknown Source)
at 
org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(Unknown Source)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Unknown Source)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(Unknown Source)
at org.apache.catalina.core.StandardWrapperValve.invoke(Unknown 
Source)
at org.apache.catalina.core.StandardContextValve.invoke(Unknown 
Source)
at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(Unknown Source)
at org.apache.catalina.core.StandardHostValve.invoke(Unknown 
Source)
at org.apache.catalina.valves.ErrorReportValve.invoke(Unknown 
Source)
at 
org.apache.catalina.valves.RequestFilterValve.process(Unknown Source)
at org.apache.catalina.valves.RemoteAddrValve.invoke(Unknown 
Source)
at 
org.apache.catalina.valves.AbstractAccessLogValve.invoke(Unknown Source)
at org.apache.catalina.core.StandardEngineValve.invoke(Unknown 
Source)
at org.apache.catalina.connector.CoyoteAdapter.service(Unknown 
Source)
at org.apache.coyote.http11.Http11Processor.service(Unknown 
Source)
at org.apache.coyote.AbstractProcessorLight.process(Unknown 
Source)
at 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(Unknown Source)
at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(Unknown Source)
at org.apache.tomcat.util.net.SocketProcessorBase.run(Unknown 
Source)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(Unknown Source)
at java.lang.Thread.run(Thread.java:748)
Caused by: org.apache.catalina.LifecycleException: Failed to start 
component [org.apache.catalina.webresources.StandardRoot@23279aae]
at 

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

[Jäkel , Guido]

>-Original Message-
>From: Rainer Jung [mailto:rainer.j...@kippdata.de]
>Sent: Monday, March 11, 2019 9:03 AM
>To: Tomcat Users List ; Michael Osipov 
>
>Subject: Re: Followup2: Changed behaviour of Tomcat 
>Deployment/Context/Lifecycle Manager concerning symbolic links
>
>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

Dear Rainer,

Thank you for scanning the mail archive!

This states that getCanonicalPath() was used because -- instead of getPath() -- 
is case insensitive (on Windows!). And the change was made to fix typo problems 
in a testcase (http://svn.apache.org/viewvc?rev=1842657=rev
)

Well - using getCanonicalPath() might solve a typo case issue, but 
unfortunately this introduce another semantic.

Guido

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

[Jäkel , Guido]

>-Original Message-
>From: Mark Thomas [mailto:ma...@apache.org]
>Sent: Tuesday, March 12, 2019 12:51 AM
>To: users@tomcat.apache.org
>Subject: Re: Followup2: Changed behaviour of Tomcat 
>Deployment/Context/Lifecycle Manager concerning symbolic links

>Looking at the code in ContextConfig.fixDocBase() it looks like it
>should be possible to switch lines 585 and 587 to use getAbsolutePath()
>without having too much impact on any performance improvements we may
>want to consider. That should address the regression. @Guido can you
>confirm that please?


Using  getAbsolutePath()  instead of  getPath()  ...

File file = new File(docBase);
if (!file.isAbsolute()) {
-docBase = (new File(appBase, docBase)).getCanonicalPath();
+docBase = (new File(appBase, docBase)).getAbsolutePath();
} else {
-docBase = file.getCanonicalPath();
+docBase = file.getAbsolutePath();
}

also still solve the issue for me.


Here my minimal test set:

* At some auto-deploying location, create the empty WAR 'dst.war.' 

(You may use the following, if you like)

# cat /opt/bin/mkemptyzip 
#!/bin/bash
#
# 20180516/gj

if [ -z "$1" ]; then
  cat >&2 <<-EOT
syntax : $0 ...
purpose: generate empty zip file
EOT
  exit -1
fi
for FILE; do
  [ -f "$FILE" ] && echo "file \"$FILE\" exists, skipping" && continue
  echo -en  
'\x50\x4b\x05\x06\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
 >$FILE
done

* Set up some different styled symlinks to it:

root@testbcs0 /home/tomcatT-8/webapps/localhost # ll ???.*  

 
lrwxrwxrwx 1 root root 41 Mar 12 12:32 abs.war -> 
/data/srv/test/webapps/localhost/dst.war.
lrwxrwxrwx 1 root root  8 Mar 12 12:33 chn.war. -> dst.war.
-rw-r--r-- 1 root root 22 Mar 12 12:32 dst.war.
lrwxrwxrwx 1 root root  8 Mar 12 12:35 dsy.war -> chn.war.
lrwxrwxrwx 1 root root  8 Mar 12 12:40 p#s.war -> chn.war.
lrwxrwxrwx 1 root root  8 Mar 12 11:51 lnk.war -> dst.war.
lrwxrwxrwx 1 root root 21 Mar 12 11:51 rel.war -> ../localhost/dst.war.


This will proper deploy the Contexts named '/abs'  '/dsy'  '/p/s'  '/lnk'  and  
'/rel' . All this breaks while using getCanonical, but works with getPath() or 
getAbsolutePath(). Notice also, that the "final destination" is still proper 
watched, i.e. touching the 'dst.war.' will redeploy all contexts.




>I can run the unit tests and if they pass and the correction of the
>regression is confirmed it should be possible to get the fix into the
>next set of releases.
>
>The next release is almost certainly too soon for completing the
>performance review. That is probably going to need to wait until the
>following set of releases.

To remove the regression, IMHO you fist should revert the change for the next 
release and do your wider code cleaning and performance after that.


with greetings

Guido

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

[Jäkel , Guido]

My investigations so far: This is thrown by

   java/org/apache/catalina/webresources/StandardRoot.java

protected WebResourceSet createMainResourceSet() {
String docBase = context.getDocBase();

WebResourceSet mainResourceSet;
if (docBase == null) {
mainResourceSet = new EmptyResourceSet(this);
} else {
File f = new File(docBase);
if (!f.isAbsolute()) {
f = new File(((Host)context.getParent()).getAppBaseFile(), 
f.getPath());
}
if (f.isDirectory()) {
mainResourceSet = new DirResourceSet(this, "/", 
f.getAbsolutePath(), "/");
} else if(f.isFile() && docBase.endsWith(".war")) { 
<<== HERE
mainResourceSet = new WarResourceSet(this, "/", 
f.getAbsolutePath());
} else {
throw new IllegalArgumentException(
sm.getString("standardRoot.startInvalidMain",
f.getAbsolutePath()));
}
}

return mainResourceSet;



And just from the names of the used methods, I wonder that the root cause is 
the following change


diff -r -u 
/var/tmp/portage/www-servers/tomcat-8.5.23/work/apache-tomcat-8.5.23-src/java/org/apache/catalina/startup/ContextConfig.java
 
/var/tmp/portage/www-servers/tomcat-8.5.37/work/apache-tomcat-8.5.37-src/java/org/apache/catalina/startup/ContextConfig.java

[...]
@@ -589,7 +583,7 @@
 
 File file = new File(docBase);
 if (!file.isAbsolute()) {
-docBase = (new File(appBase, docBase)).getPath();
+docBase = (new File(appBase, docBase)).getCanonicalPath();
 } else {
 docBase = file.getCanonicalPath();
 }
[...]

(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


greetings

Guido





>[...]
>for deployment, with the newer Tomcat version I get the error
>
>   20190308-092433.557 ERROR [catalina-exec-38] [] [[/manager]] FAIL - 
> Application at context path [/foo] could not be
>started
>   org.apache.catalina.LifecycleException: Failed to start component
>[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/foo]]
> [...]
>   Caused by: java.lang.IllegalArgumentException: The main resource set 
> specified
>[/some/fill/path/to/destination/bar.an_extension] is not valid
>   at 
> org.apache.catalina.webresources.StandardRoot.createMainResourceSet(Unknown 
> Source)
>   at 
> org.apache.catalina.webresources.StandardRoot.startInternal(Unknown Source)
>   ... 39 more

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

RE: request.getContextPath() behind a proxy (apache/nginx)

[Jäkel , Guido]

>On 05/02/2019 08:23, Johan Compagner wrote:
>> problem is that our customers are doing this.
>> also they can have 1 tomcat with a few webapps that they want to map under
>> different domains
>>
>> so that would mean for them starting 3 different tomcats under 3 different
>> ports and configure all that
>> thats not always something they want to do.
>> So i guess the only way for me is to have some kind of setting (per context)
>
>They would be better configuring Tomcat with virtual hosts and having
>three ROOT webapps.
>
>Mark

Dear Johan,

as Christopher and Mark wrote: If possible in any way, please avoid to handle 
it via rewriting on a reverse proxy and prefer to set up the Tomcat to serve 
the application on the same domain and context path as used "outside" in front 
of the proxy.

If you real can't avoid, you have to do a forward rewriting of the used header 
(e.g. hostname) and/or URL pattern in the one hand, but also a complex backward 
rewriting of the answer! You have to back-rewrite parts of the answer header 
(Cookies, Locations, Links, ...) and the embedded URLs in the content of 
different MIME types (HTML, CSS, javascript, JSON, ...). As a consequence, you 
have either to forbid compression of the returned body or (even more complex) 
decompress/modify/recompress it on the fly.

Sometimes, I simply can't avoid because we need to have an application 
available on two "addresses" while migration or something similar. And if the 
application itself can't be run in two instances I know no other way. But's it 
a real burden every time.

with greetings

Guido

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

[Jäkel , Guido]

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?

greetings

Guido

>-Original Message-
>From: Jäkel, Guido [mailto:g.jae...@dnb.de]
>Sent: Friday, March 08, 2019 11:39 AM
>To: 'Tomcat Users List' 
>Subject: Followup: Changed behaviour of Tomcat Deployment/Context/Lifecycle 
>Manager concerning symbolic links
>
> [...]
>
>And just from the names of the used methods, I wonder that the root cause is 
>the following change
>
>
>   diff -r -u 
> /var/tmp/portage/www-servers/tomcat-8.5.23/work/apache-tomcat-8.5.23-
>src/java/org/apache/catalina/startup/ContextConfig.java 
>/var/tmp/portage/www-servers/tomcat-8.5.37/work/apache-tomcat-8.5.37-
>src/java/org/apache/catalina/startup/ContextConfig.java
>
>   [...]
>   @@ -589,7 +583,7 @@
>
> File file = new File(docBase);
> if (!file.isAbsolute()) {
>-docBase = (new File(appBase, docBase)).getPath();
>+docBase = (new File(appBase, docBase)).getCanonicalPath();
> } else {
> docBase = file.getCanonicalPath();
> }
>   [...]
>
>(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
>
>
>greetings
>
>Guido

RE: Configuring log format for console output (catalina.out)

[Jäkel , Guido]

Dear Joan,

by use of the common scripts, the file  catalina.out  will contain the console 
output (stdout/tderr) of the *JVM* process and -- if not configured in another 
way -- of the applications. Therefore, you have to deal with the features of 
output formatting of current JVMs. Or -- as me -- you might pipe this file 
descriptors through a tiny script that will prepend a timestamp in a format of 
your choice. This will have the advantage that it also handle "console" output 
of Java application; despite of the fact that using stdout/stderr instead of a 
java logging mechanism is a very bad style.

If you don't need to process thousands of lines per second, a simple shell 
script may do the job:

while read line; do echo "`date -Ins` $line"; done

To avoid "double-stamping", you may add an heuristic check of the incoming 
line; please adjust the RegExpr to your neeeds

while read line; do [[ ! "$line" =~ ^\d\d\d\d ]] && echo -n "[`date 
-Ins`] "; echo $line; done


Guido

RE: Tomcat Bandwidth Utilization Tool

[Jäkel , Guido]

Dear Michael,

you may read the statistic values provided by the Connector (and others like 
busy works, load, heap usage or even the request scoreboard) via JXM or even 
(by help of the JMX Proxy Servlet) via HTTP. You may contact me if you need 
more advice.

greetings

Guido

>-Original Message-
>From: Michael Duffy [mailto:mduffy...@gmail.com]
>Sent: Friday, August 30, 2019 2:36 AM
>To: users@tomcat.apache.org
>Subject: Re: Tomcat Bandwidth Utilization Tool
>
>There is a " Bytes received: 0.00 MB Bytes sent: 12.03 MB" in the Tomcat
>Manager; however, the received count does not change and the sent count
>seems low.
>
>On Thu, Aug 29, 2019 at 7:09 PM Michael Duffy  wrote:
>
>> Is there a simple tool that will show bandwidth utilization to and from
>> the Tomcat server?
>>
>> I am looking for something that will provide an exact byte count of the
>> TCP/IP packets.
>>
>> I would have thought this would be an easy find; however, after hours of
>> Googling around I have not yet been successful.
>>
>> There are some options here:
>> https://www.comparitech.com/net-admin/free-bandwidth-monitoring-tools/ ,but
>> none of them specifically mention integration with Tomcat.
>>
>> At the application level, if I just measure the byte flow into and out of
>> my application, I will miss the bytes in the TCP/IP headers.
>>
>> Any suggestions would be greatly appreciated.
>>
>> Thx.
>>
>> Mike
>>
>>
>>

AW: remote jmx monitoring through ssh tunnel

[Jäkel , Guido]

Dear all,

some time ago, I also need to pass JXM through a tunneled connection (using 
STunnel). The Problem with JMX via RMI is that here is more than one connection 
and involved in the handshake is an IP address that is different on both ends 
of the tunnel. A solution was to use an alternative transport layer named JMXMP 
because this need only one connection.

You may use my notes on https://github.com/gjaekel/jmxmp-lifecycle-listener as 
a starting point.

One have to provide additionals JARS, on Tomcat to $CATALINA_HOME/lib. Then one 
have to compile and install an additional listener



The client also must be "undergrid" with an additional library, e.g.

visualvm --cp:a jmxremote_optional.jar

and the connection URL must use the alternative protocol

service:jmx:jmxmp://:


with greetings

Guido

-Ursprüngliche Nachricht-
Von: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Gesendet: Donnerstag, 12. Dezember 2019 16:05
An: users@tomcat.apache.org
Betreff: Re: remote jmx monitoring through ssh tunnel

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Chris,

On 12/11/19 15:52, Chris Cheshire wrote:
> On Wed, Dec 11, 2019 at 12:24 PM Christopher Schultz 
>  wrote:
>> 
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>> 
>> 
>> 
>> On 12/10/19 12:59, Chris Cheshire wrote:
>>> On Tue, Dec 10, 2019 at 11:58 AM Chris Cheshire 
>>>  wrote:
 
 On Tue, Dec 10, 2019 at 9:42 AM Christopher Schultz 
  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
> 
> Chris,
> 
> On 12/9/19 17:10, Chris Cheshire wrote:
>> In CATALINA_BASE/bin/setenv.sh I have the following :
>> 
>> CATALINA_OPTS="-Dcom.sun.management.jmxremote
>> -Dcom.sun.management.jmxremote.ssl=false
>> -Dcom.sun.management.jmxremote.authenticate=false"
> 
> Okay.
> 
>> In CATALINA_BASE/conf/server.xml I have a listener configured :
>> 
>> > className="org.apache.catalina.mbeans.JmxRemoteLifecycleListener"
>>
>>
>>
>> 
rmiRegistryPortPlatform="10001" rmiServerPortPlatform="10002"
>> useLocalPorts="true" />
>> 
>> 
>> Upon startup I see in logs : INFO [main] 
>> org.apache.catalina.mbeans.JmxRemoteLifecycleListener.createServe
r
>>
>>
>>
>> 
The JMX Remote Listener has configured the registry on port
>> [10001] and the server on port [10002] for the [Platform] server
>> 
>> 
>> $ netstat -an | grep 10001 tcp4   0  0 
>> 127.0.0.1.10001 *.*LISTEN tcp6
>> 0 0  ::1.10001 *.*LISTEN
>> 
>> On my local machine I have a tunnel set up as follows :
>> ssh -N -L10001:localhost:10001 -L10002:localhost:10002 
>> user@remotehost
>> 
>> (where user is the user tomcat is running under)
>> 
>> When I try to add a remote JMX connection in VisualVM on my 
>> client machine to localhost:10001 I get an error dialog after a 
>> brief delay with the message "Cannot connect to localhost:10001 
>> using service:jmx:rmi:///jndi/rmi://localhost:10001/jmxrmi". If I 
>> change it to port 10002 I get the same error. On the server at 
>> this time : $ netstat -an | grep 10001 tcp4
>> 0  0 127.0.0.1.10001 *.*LISTEN
>> tcp6   0 0  ::1.10001 *.*LISTEN
>> tcp4   0 0  127.0.0.1.62637 127.0.0.1.10001
>> TIME_WAIT
>> 
>> 
>> If I try to use jconsole connecting to port 10001 I get the error 
>> "Connection failed: non-JRMP server at remote endpoint". 
>> Connecting to port 10002 I get the error "Connection failed: no 
>> such object in table"
> 
> You should be using the port defined by rmiRegistryPortPlatform, 
> so 10001 is the correct port to use.
> 
>> I've been through the tomcat configuration documentation a couple 
>> times but I can't see what else I need to configure.
> 
> What you have looks good to me without reproducing it myself. Can 
> you do :
> 
> $ netstat -an | grep 1000[0-9]
> 
> ?
> 
> Just to be sure about both ports?
> 
 
 $ netstat -an | grep 1000[0-9] tcp6   0  0 :::10001 
 :::*LISTEN tcp6   0  0 :::10002 
 :::*LISTEN
 
 
 H. Tomcat is only listening on ipv6 ports, but my tunnel is 
 using ipv4. After digging around [1], I added this to CATALINA_OPTS 
 in setenv.sh
 
 -Djava.net.preferIPv4Stack=true
 -Djava.net.preferIPv4Addresses=true
 
 $ netstat -an | grep 1000[0-9] tcp0  0
 0.0.0.0:10001 0.0.0.0:*   LISTEN tcp0
 0 0.0.0.0:10002 0.0.0.0:*   LISTEN
 
 When I try to connect with jconsole I get the same error (non-JRMP 
 server at remote endpoint), with the server showing
 
 tcp0  0 0.0.0.0:10001   0.0.0.0:* 

AW: JVM job for Tomcat taking lots and lots of CPU

[Jäkel , Guido]

Dear James, Dear others,

I just get notice of this long thread. Sorry, if already give this suggestion. 
But James: If it's possible, you may use (J)VisualVM with the "VisualGC" Plugin 
to get some live impressions of "what's going on" with the heaps. To my 
experience this visual perceptions is much easy to comprehend as a long list of 
numbers.

If JMX is enabled to use remotely, you may even run the VisualVM-Tool on a 
different machine.

Maybe some JVM-Options like

-XX:+PrintGCDetails
-XX:+PrintGCApplicationStoppedTime
-XX:+PrintAdaptiveSizePolicy
-XX:+PrintTenuringDistribution
-XX:+PrintStringDeduplicationStatistics

may help you to let write down a log of GC activities.


with greetings

Guido 


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