Re: /manager/text/list

[Chris Gamache]

Hi Theo,

Yea, when versioning warfiles themselves you can count on the version being a 
part of the deploy root. 

I'm using a versioned context.xml files in confBase/[engine]/[host]

Html manger reports them correctly. The version number simply isn't there  in 
the text list.

> On Oct 23, 2015, at 2:59 AM, Theo Sweeny  wrote:
> 
> Hi Chris,
> 
> -Original Message-
> From: Chris Gamache [mailto:cgama...@gmail.com]
> Sent: 22 October 2015 19:58
> To: Tomcat Users List 
> Subject: /manager/text/list
> 
> Hi all,
> 
> Using Tomcat 8 ...
> 
> Has anyone noticed that /manager/text/list doesn't show version numbers when 
> there are multiple versions of a webapp running (via parallel deployment)?
> 
> Is there a different listing facility I should be using to find out the 
> version tags of the currently running applications?
> 
> CG
> 
> When running a similar search on Tomcat v8.0.21, Red Hat x64 with JDK 
> 1.7.0.8, the parallel versions are displayed as -
> 
> tomcat@localhost:/opt/tomcat
> $ curl -s -X GET http://username:password@localhost:8080/manager/text/list 
> |sort
> /account-information-bs-1.0:running:0:account-information-bs-1.0##v1.0.3
> /account-information-bs-1.1:running:0:account-information-bs-1.1##v1.1.0
> 
> How are you implementing the version numbers?
> 
> Regards,
> 
> Theo
> Avios Group (AGL) Ltd is a limited company registered in England (registered 
> number 2260073 and VAT number 512566754) whose registered address is Astral 
> Towers, Betts Way, London Road, Crawley, West Sussex RH10 9XY . Avios Group 
> (AGL) Limited is part of the IAG group of companies This email and any files 
> transmitted with it are confidential and intended solely for the use of the 
> individual or entity to whom they are addressed. If you have received this 
> email in error please notify the system manager.
> 
> -
> 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 returning context path with extra leading slash

[Christopher Schultz]

Konstantin,

On 10/23/15 6:32 AM, Konstantin Kolinko wrote:
> 2015-10-22 20:55 GMT+03:00 Christopher Schultz :
>> All,
>>
>> On 10/14/15 11:03 PM, Christopher Schultz wrote:
>>> All,
>>>
>>> On 7/3/15 1:40 PM, Christopher Schultz wrote:
 Running Tomcat 8.0.x trunk as of 167 (slightly old) on
 jdk1.8.0_45 on Mac OS X, I'm having intermittent problems with
 Tomcat appearing not to change a relative URL into a
 fully-qualified URL for redirection purposes.
>>>
 Since it's intermittent, it's hard to catch. But I just found a
 case.
>>>
 I have an HttpServletResponseWrapper that logs calls to
 sendRedirect() by dumping-out the URL that was passed-into the
 sendRedirect method.
>>>
 [snip]
>>>
 [HttpServletResponse.sendRedirect or similar is ruining my redirect
  URL, so the hostname is being obliterated and I get
 http://context/path/to/page instead of
 http://localhost/context/path/to/page]
>>>
>>> I'm having this problem, again. This time with an updated 8.0.x trunk
>>> (pretty much 8.0.27).
>>>
>>> It might be a problem with securityfilter, which is trying to do this:
>>>
>>> // redirect to login page
>>> response.sendRedirect(response.encodeRedirectURL(request.getContextPath(
>>> )
>>> + loginPage));
>>>
> <...>
>>
>> Any idea what might be causing Tomcat to return "/" + context path when
>> ServletContext.getContextPath() is called?
> 
> It seems that you are confusing two different methods,
> 
> (1) HttpServletRequest.getContextPath()
> (2) ServletContext.getContextPath(), @since Servlet 2.5
> 
> (1) returns the actual value from client's request, as is
> (2) returns "canonical" value
> 
> (2) is always the same, (1) varies

Aah, I didn't realize that they were different.

I'll look into why HttpServletRequest.getContextPath is returning the
"extra" slash -- probably because of something that has happened
previously in the workflow.

Thanks,
-chris

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

Re: Tomcat returning context path with extra leading slash (was: Re: Tomcat not properly fully-qualifying redirect URLs)

[Konstantin Kolinko]

2015-10-22 20:55 GMT+03:00 Christopher Schultz :
> All,
>
> On 10/14/15 11:03 PM, Christopher Schultz wrote:
>> All,
>>
>> On 7/3/15 1:40 PM, Christopher Schultz wrote:
>>> Running Tomcat 8.0.x trunk as of 167 (slightly old) on
>>> jdk1.8.0_45 on Mac OS X, I'm having intermittent problems with
>>> Tomcat appearing not to change a relative URL into a
>>> fully-qualified URL for redirection purposes.
>>
>>> Since it's intermittent, it's hard to catch. But I just found a
>>> case.
>>
>>> I have an HttpServletResponseWrapper that logs calls to
>>> sendRedirect() by dumping-out the URL that was passed-into the
>>> sendRedirect method.
>>
>>> [snip]
>>
>>> [HttpServletResponse.sendRedirect or similar is ruining my redirect
>>>  URL, so the hostname is being obliterated and I get
>>> http://context/path/to/page instead of
>>> http://localhost/context/path/to/page]
>>
>> I'm having this problem, again. This time with an updated 8.0.x trunk
>> (pretty much 8.0.27).
>>
>> It might be a problem with securityfilter, which is trying to do this:
>>
>> // redirect to login page
>> response.sendRedirect(response.encodeRedirectURL(request.getContextPath(
>> )
>> + loginPage));
>>
<...>
>
> Any idea what might be causing Tomcat to return "/" + context path when
> ServletContext.getContextPath() is called?

It seems that you are confusing two different methods,

(1) HttpServletRequest.getContextPath()
(2) ServletContext.getContextPath(), @since Servlet 2.5

(1) returns the actual value from client's request, as is
(2) returns "canonical" value

(2) is always the same, (1) varies

Best regards,
Konstantin Kolinko

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

Error during WebSocket handshake: Unexpected response code: 404

[Madhav Ayyagari]

Hi all,
I’m trying make Websockets work with embedded Tomcat (8.0.28) started by Main 
class (shown below). When I try to open websocket connection from browser using 
the URLs below, I always get “Error during WebSocket handshake: Unexpected 
response code: 404”.
Is there anything wrong with the way Tomcat is started/setup or classpath used 
in running the application?

Any help is greatly appreciated.
-Madhav

WS URLs getting the error:

http://localhost:8080/entities
http://localhost:8080/ws2/entities

Http URLs that show html page (but are not successful in connecting to 
websocket):
http://localhost:8080/ws2/hello

Main class that starts Tomcat:

package com.mypackage;

public class TomcatWebServer {

  public static void main(String[] args) {
Tomcat tomcat = new Tomcat();
tomcat.setPort(8080);

Context ctx = tomcat.addContext("/ws2", new File(".").getAbsolutePath());

Set classes = new HashSet<>();
classes.add(MyWebSocketEndpoint.class);
ctx.addServletContainerInitializer(new WsSci(), classes);

Tomcat.addServlet(ctx, "hello", new HttpServlet() {
  protected void service(HttpServletRequest req, HttpServletResponse resp)
  throws ServletException, IOException {
Writer w = resp.getWriter();
w.write(""
+ "var wsUri=\"ws://localhost:8080/ws2/entities\";"
+ "var ws=new WebSocket(wsUri);"
+ "ws.onopen=function(evt){console.log(\"opened: 
\"+JSON.stringify(evt));};"
+ "ws.onclose=function(evt){console.log(\"closed: 
\"+JSON.stringify(evt));};"
+ "Hello, World!");
w.flush();
  }
});
ctx.addServletMapping("/hello", "hello");

try {
  tomcat.start();
  tomcat.getServer().await();
} catch (LifecycleException e) {
  e.printStackTrace();
}
  }

}


WebSocket implementing Class:

@ServerEndpoint("/entities")
public class MyWebSocketEndpoint {

  private Map clientSessions = new HashMap<>();

  @OnOpen
  public void onOpen(Session session) {
System.out.println("session opened = " + session.getId());
clientSessions.put(session.getId(), session);
  }

  @OnMessage
  public void onMessage(String message) {
System.out.println("message = " + message);
  }

  @OnClose
  public void onClose(Session session) {
System.out.println("session close = " + session.getId());
clientSessions.remove(session.getId());
  }

  void broadcast(String message) {
for (Session session : clientSessions.values()) {
  session.getAsyncRemote().sendText(message);
}
  }
}


Gradle build file:

apply plugin: 'java'
apply plugin: 'idea'

repositories {
   mavenCentral()
}

configurations {
provided
}

sourceSets {
main {
compileClasspath += configurations.provided
}

}

idea {
module {
scopes.PROVIDED.plus += [configurations.provided]
}
}

task run() {
dependsOn build
doLast {
javaexec {
main = 'com.mypackage.TomcatWebServer'
classpath = sourceSets.main.output + 
sourceSets.main.runtimeClasspath
println 'classpath for running ' + main + ' is ' + 
classpath.getAsPath()
}
}
}

dependencies {
compile 'log4j:log4j:1.2.17'
compile 'org.apache.tomcat.embed:tomcat-embed-core:8.0.28'
compile 'org.apache.tomcat.embed:tomcat-embed-logging-log4j:8.0.28'
compile 'org.apache.tomcat.embed:tomcat-embed-websocket:8.0.28'
compile 'org.apache.tomcat:tomcat-websocket-api:8.0.28'
//provided 'javax.websocket:javax.websocket-api:1.1'
}


© Copyright 2015 REDI Global Technologies LLC (“REDI”), member FINRA, SIPC. All 
rights reserved. The information contained in and accompanying this 
communication may be confidential, subject to legal privilege, or otherwise 
protected from disclosure, and is intended solely for the use of the intended 
recipient(s). If you are not the intended recipient of this communication, 
please delete and destroy all copies in your possession, notify the sender that 
you have received this communication in error, and note that any review or 
dissemination of, or the taking of any action in reliance on, this 
communication is expressly prohibited. E-mail messages may contain computer 
viruses or other defects, may not be accurately replicated on other systems, or 
may be intercepted, deleted or interfered with without the knowledge of the 
sender or the intended recipient. REDI makes no warranties in relation to these 
matters. Please note that REDI reserves the right to intercept, monitor, and 
retain e-mail messages to and from its systems as permitted by applicable law. 
If you are not comfortable with the risks associated with e-mail messages, you 
may decide not to use e-mail to communicate with REDI.

RE: servlet filter not working over virtual directories in tomcat

[Pradyut Bhattacharya]

Thank you Mark for replying. 


 


> The URL
pattern therefore needs to be "/*"


 


Could not do anything with the above statement. May be an example could suffice.


 


Somehow could see an example for PreResources in the internet and this is
how I did it without an TestApp#web.xml file in the Catalina/localhost folder.


 





   






   






This works fine with filters.


 


Regards,


Pradyut

> Subject: Re: servlet filter not working over virtual directories in tomcat
> To: users@tomcat.apache.org
> From: ma...@apache.org
> Date: Fri, 23 Oct 2015 08:15:09 +0100
> 
> On 23/10/2015 03:39, Pradyut Bhattacharya wrote:
> > Hi,
> > I  had configured virtual directories in glassfish3.x over which I could 
> > write filters.
> > For an example I could access files at c:/web from 
> > http://localhost/TestApp/web over which I could also place a filter at my 
> > web app's web/xml file with
> > 
> > dir_filter
> > /web/*
> > Unfortunately Tomcat 8.0 is not allowing me to write a 
> > filter above that. It simply ignores the filters and shows the content in 
> > the web directory.
> > The problem is anybody can access all of the files in the "web" folder.
> > Any how can we place filter over the virtual directories.
> > FYI - i have made the web app named "TestApp" and the virtual config is 
> > located at "$tomcat_dir/conf/Catalina/localhost" directory with the file 
> > name "TestApp#web.xml" file and having the content > encoding='utf-8'?> 
> > 
> > The question is also at stackoverflow - 
> > http://stackoverflow.com/questions/33290483/servlet-filter-not-working-over-virtual-directories-in-tomcat
> > Tomcat bugzilla - https://bz.apache.org/bugzilla/show_bug.cgi?id=58523
> 
> Tomcat is doing exactly what you have configured it to do. There is no
> Tomcat bug here, just user error.
> 
> With a context.xml file named TestApp#web.xml you have a defined a new
> web application with a context path of "/TestApp/web" and a docBase of
> "C:\web"
> 
> The URL pattern therefore needs to be "/*"
> 
> If you want to mount "C:\web" inside an existing web application using
> the path "/web" then you need to define a PreResources or PostResources
> element using the org.apache.catalina.webresources.DirResourceSet
> implementation. See
> http://tomcat.apache.org/tomcat-8.0-doc/config/resources.html for more
> details.
> 
> Mark
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
  

Re: Tomcat answers on port 80, not on 443

[tomcat]

On 23.10.2015 16:53, Beyer, Gregory L wrote:
...
##
# Inbound SSL Settings
##

org.apache.felix.https.enable=true
org.osgi.service.http.port.secure=443
org.apache.felix.https.keystore=E:\\Program Files\\Connector\\.keystore
org.apache.felix.https.keystore.password=REDACTED
org.apache.felix.https.keystore.key.password= REDACTED
 	org.apache.felix.https.truststore=C:\\Program 
Files\\Java\\jre1.8.0_60\\lib\\security\\cacerts

org.apache.felix.https.truststore.password= REDACTED


Question  -- Does anyone think " Program Files"  (space) above is contributing 
to the problem?



Maybe, maybe not.  It would depend on how "Felix" parses its configuration 
files.


But in any case, admitting spaces in file names is certainly one of the stupidest and most 
costly ideas in the history of computing.
A close second would be making this a standard program installation directory in some 
widely-distributed operating systems.
A close third would be using the same thing in the standard installation path of some 
popular open-source software.

oh well..


Getting back on-topic however : I do not know anything about Felix, and I have not really 
followed this thread.  But assuming that this Felix is a web application running under 
Tomcat, the fact that it has the above in its own configuration file, rather than in some 
Tomcat configuration file, would tend to make one suspect that Felix is opening its own 
listening socket, of which Tomcat knows nothing. No ?


And in such a case, there would be some conflict if one simultaneously to deploying this 
web application, would try to open a Tomcat Connector on the same port.

One of them is bound to fail.

[...]


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

RE: Tomcat answers on port 80, not on 443

[Beyer, Gregory L]

Thank you Konstantin and Chris Schultz.  Been trying all you suggested 
Konstantin, and a heck of a lot more without much success.  But I finally did 
get /something/ in a log that might be helpful if anyone can interpret it.

Chris, on your observation:

I'm not sure how Apache Felix fits into this (I don't know a thing 
about Felix), but:

> maxThreads="150" SSLEnabled="true" scheme="https" 
secure="true"
>clientAuth="false" sslProtocol="TLS" />

This connector has no reference to any keystore configuration. Unless 
Felix is somehow wiring that all up, then you haven't configured a viable TLS 
connector.

I also don't know what role Felix plays.  Apparently you spotted something 
missing in the snippet above that tells you there's no connector configured.  
The above is right out of the server.xml.  I simply un-remmed it. 

Now, my java app's configuration file DOES have an entry that references a 
keystore: 

##
# Inbound SSL Settings
##

org.apache.felix.https.enable=true
org.osgi.service.http.port.secure=443
org.apache.felix.https.keystore=E:\\Program Files\\Connector\\.keystore
org.apache.felix.https.keystore.password=REDACTED
org.apache.felix.https.keystore.key.password= REDACTED
org.apache.felix.https.truststore=C:\\Program 
Files\\Java\\jre1.8.0_60\\lib\\security\\cacerts
org.apache.felix.https.truststore.password= REDACTED

Question  -- Does anyone think " Program Files"  (space) above is contributing 
to the problem?

BTW the \\Connector\\ in the paths above is the install directory of my java 
app, which is, I think, a different connector than that in the server.xml.

So here is the snippet from my log:



2015-10-23 09:34:10 [o.e.j.u.c.AbstractLifeCycle] WARN   - FAILED 
SslContextFactory@2cc0a31e(E:\Program Files\Connector\.keystore,C:\Program 
Files\Java\jre1.8.0_60\lib\security\cacerts): 
java.security.UnrecoverableKeyException: Cannot recover key
java.security.UnrecoverableKeyException: Cannot recover key
at sun.security.provider.KeyProtector.recover(Unknown Source) 
~[na:1.8.0_60]
at sun.security.provider.JavaKeyStore.engineGetKey(Unknown Source) 
~[na:1.8.0_60]
at sun.security.provider.JavaKeyStore$JKS.engineGetKey(Unknown Source) 
~[na:1.8.0_60]
at sun.security.provider.KeyStoreDelegator.engineGetKey(Unknown Source) 
~[na:1.8.0_60]
at 
sun.security.provider.JavaKeyStore$DualFormatJKS.engineGetKey(Unknown Source) 
~[na:1.8.0_60]
at java.security.KeyStore.getKey(Unknown Source) ~[na:1.8.0_60]
at sun.security.ssl.SunX509KeyManagerImpl.(Unknown Source) 
~[na:1.8.0_60]
at sun.security.ssl.KeyManagerFactoryImpl$SunX509.engineInit(Unknown 
Source) ~[na:1.8.0_60]
at javax.net.ssl.KeyManagerFactory.init(Unknown Source) ~[na:1.8.0_60]
at 
org.eclipse.jetty.util.ssl.SslContextFactory.getKeyManagers(SslContextFactory.java:1080)
 ~[na:na]
at 
org.eclipse.jetty.util.ssl.SslContextFactory.doStart(SslContextFactory.java:291)
 ~[na:na]
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
 ~[na:na]
at 
org.eclipse.jetty.server.ssl.SslSelectChannelConnector.doStart(SslSelectChannelConnector.java:612)
 ~[na:na]
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
 ~[na:na]
at 
org.apache.felix.http.jetty.internal.JettyService.startConnector(JettyService.java:421)
 ~[na:na]
at 
org.apache.felix.http.jetty.internal.JettyService.initializeHttps(JettyService.java:327)
 ~[na:na]
at 
org.apache.felix.http.jetty.internal.JettyService.initializeJetty(JettyService.java:273)
 ~[na:na]
at 
org.apache.felix.http.jetty.internal.JettyService.startJetty(JettyService.java:197)
 ~[na:na]
at 
org.apache.felix.http.jetty.internal.JettyService.start(JettyService.java:130) 
~[na:na]
at 
org.apache.felix.http.jetty.internal.JettyActivator.doStart(JettyActivator.java:29)
 ~[na:na]
at 
org.apache.felix.http.base.internal.AbstractActivator.start(AbstractActivator.java:41)
 ~[na:na]
at 
org.apache.felix.http.bundle.internal.CombinedActivator.start(CombinedActivator.java:56)
 ~[na:na]
at 
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:645)
 ~[org.apache.felix.main-4.2.1.jar:na]
at org.apache.felix.framework.Felix.activateBundle(Felix.java:2146) 
~[org.apache.felix.main-4.2.1.jar:na]
at org.apache.felix.framework.Felix.startBundle(Felix.java:2064) 
~[org.apache.felix.main-4.2.1.jar:na]
at 
org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1291) 
~[org.apache.felix.main-4.2.1.jar:na]
at 
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:304)
 ~[org.apache.felix.main-4.2.1.jar:na]

RE: /manager/text/list

[Theo Sweeny]

Hi Chris,

-Original Message-
From: Chris Gamache [mailto:cgama...@gmail.com]
Sent: 22 October 2015 19:58
To: Tomcat Users List 
Subject: /manager/text/list

Hi all,

Using Tomcat 8 ...

Has anyone noticed that /manager/text/list doesn't show version numbers when 
there are multiple versions of a webapp running (via parallel deployment)?

Is there a different listing facility I should be using to find out the version 
tags of the currently running applications?

CG

When running a similar search on Tomcat v8.0.21, Red Hat x64 with JDK 1.7.0.8, 
the parallel versions are displayed as -

tomcat@localhost:/opt/tomcat
$ curl -s -X GET http://username:password@localhost:8080/manager/text/list |sort
/account-information-bs-1.0:running:0:account-information-bs-1.0##v1.0.3
/account-information-bs-1.1:running:0:account-information-bs-1.1##v1.1.0

How are you implementing the version numbers?

Regards,

Theo
Avios Group (AGL) Ltd is a limited company registered in England (registered 
number 2260073 and VAT number 512566754) whose registered address is Astral 
Towers, Betts Way, London Road, Crawley, West Sussex RH10 9XY . Avios Group 
(AGL) Limited is part of the IAG group of companies This email and any files 
transmitted with it are confidential and intended solely for the use of the 
individual or entity to whom they are addressed. If you have received this 
email in error please notify the system manager.

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

Re: servlet filter not working over virtual directories in tomcat

[Mark Thomas]

On 23/10/2015 03:39, Pradyut Bhattacharya wrote:
> Hi,
> I  had configured virtual directories in glassfish3.x over which I could 
> write filters.
> For an example I could access files at c:/web from 
> http://localhost/TestApp/web over which I could also place a filter at my web 
> app's web/xml file with
> 
> dir_filter
> /web/*
> Unfortunately Tomcat 8.0 is not allowing me to write a 
> filter above that. It simply ignores the filters and shows the content in the 
> web directory.
> The problem is anybody can access all of the files in the "web" folder.
> Any how can we place filter over the virtual directories.
> FYI - i have made the web app named "TestApp" and the virtual config is 
> located at "$tomcat_dir/conf/Catalina/localhost" directory with the file name 
> "TestApp#web.xml" file and having the content encoding='utf-8'?> 
> 
> The question is also at stackoverflow - 
> http://stackoverflow.com/questions/33290483/servlet-filter-not-working-over-virtual-directories-in-tomcat
> Tomcat bugzilla - https://bz.apache.org/bugzilla/show_bug.cgi?id=58523

Tomcat is doing exactly what you have configured it to do. There is no
Tomcat bug here, just user error.

With a context.xml file named TestApp#web.xml you have a defined a new
web application with a context path of "/TestApp/web" and a docBase of
"C:\web"

The URL pattern therefore needs to be "/*"

If you want to mount "C:\web" inside an existing web application using
the path "/web" then you need to define a PreResources or PostResources
element using the org.apache.catalina.webresources.DirResourceSet
implementation. See
http://tomcat.apache.org/tomcat-8.0-doc/config/resources.html for more
details.

Mark

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

Re: Monitoring Connections

[Aurélien Terrestris]

> I know mod_jk will complain if it can't
> make a connection or if there is a timeout... I suspect mod_proxy_http
> will do the same.

They both are supposed to log 502, while Tomcat will raise a "connection
reset by peer" when answering to an already closed connection.
Timeouts for both are buggy until, if I remember well, Apache 2.2.17 (see :
http://www.spinics.net/lists/apache-users/msg93765.html ), behaving with a
timeout 4 times too short. I suppose this was hard-coded for test reasons,
and just forgotten. They never replied on this anyway, and please check if
you're not running this old bugged Apache.

As said by Chris, your server seems quiet, and this means the problem might
be out there.

Uploading files ? Please check if there is any virus scanner software on
the server, this might be an explanation. Have a look on the server if you
can find the temporary file which is being uploaded, and what is its size
(more than 100 megs ??)

When the problem happens again, don't forget to do a 'netstat -an'. There,
it will be important to check if there is any SYN_SENT connections, showing
a network problem.
Another thing more difficult if the problem is related to DNS solving which
could be stalled for any reason. You can try some nslookup commands when
the problem happens and compare with normal nslookup (what DNS server
answered ?) ; you also can install a BIND on your server and make it log
everything, this would give you logs for after crash analysis. Or let run a
'tcpdump port 53' and save its capture for later analysis.


regards
A.T.









2015-10-21 20:58 GMT+02:00 Christopher Schultz :

> Jamie,
>
> On 10/21/15 2:37 PM, Jamie Jackson wrote:
> > On Wed, Oct 21, 2015 at 1:03 PM, Christopher Schultz  wrote:
> >
> >> Jamie,
> >>
> >>
> >>
> >> Your mostly-default  will default to a maximum of 200
> >> incoming connections with 200 threads to handle them. You are only using
> >> 12, so something else must be going on. You have no obvious limits on
> >> httpd, so you are probably using the default there as well
> >> (coincidentally, also in the 200-connection range).
> >>
> >> That's a high connection timeout: 93 seconds (why 93?). Note that the
> >> connectionTimeout sets the amount of time Tomcat will wait for a client
> >> to send the request line (the "GET /foo HTTP/1.1"), not the amount of
> >> time the request is allowed to run -- like for an upload, etc. I usually
> >> lower this setting from the default of 60 seconds to more like 5 or 10
> >> seconds. Clients shouldn't be waiting a long time between making a
> >> connection and sending a request.
> >>
> >> This timeout also applies to subsequent requests on a keep-alive
> >> connection. So if the browser opens a connection and sends 1, 2, 3
> >> requests, Tomcat will hold that thread+connection open for 93 seconds
> >> after the last request (assuming the client doesn't terminate the
> >> connection, which it might NOT) before allowing other clients to be
> >> serviced by that thread. This is a BIO-Connector-only behavior. The
> >> NIO/NIO2 and APR connectors don't hold-up the request thread waiting for
> >> a follow-up keep-alive request from a client.
> >>
> >
> > Thanks for the info. It seems as if connectionTimeout is almost
> universally
> > misunderstood to mean something like "request timeout," (which is why it
> > had been high--to accommodate things like long responses and file
> uploads).
> > It seems possible that we could be using up too many threads for too long
> > because of the effect of this long timeout on keep-alives.
>
> While that's true, you should something like 185 threads "in reserve"
> and so the server shouldn't grind to a halt and not let anyone else in.
> If there are other components in the mix, those could prevent more
> connections (e.g. load-balancer, QOS component, etc.) or even if you are
> trying to connect from a single web browser with a 4-connection limit,
> you'll obviously only be able to upload 4 files at a time.
>
> But you didn't say anything about that kind of thing, so I assume it's
> not the issue.
>
> > The only time I can think of that a client would be taking any kind of
> time
> > between connection and sending the request URI line is if someone is
> > manually interacting (say, via telnet). I'm going to follow your lead and
> > reduce this.
>
> I wouldn't reduce it past the default of 60 seconds (6ms) unless you
> are observing client-starvation.
>
> > I doubt that this is the *sole* culprit, but it *is* something for me to
> > tweak.
>
> I would read the whole HTTP-Connector configuration reference --
> especially the "timeout" related items -- and make sure you understand
> them all before setting any of them. The defaults are reasonable, but
> every environment has its own special set of requirements.
>
> I don't think the timeouts are the issue. What else can you tell us
> about the behavior of the server when it "crashes"? I don't think you
> have 

Wireshark support for Tomcat clusters

[Aurélien Terrestris]

For those interested, the Wireshark 2.0 which is now running the RC
process, has a built-in dissector for Tomcat clusters (named ATH for Apache
Tribes Heartbeat)



regards

Re: Monitoring Connections

[Aurélien Terrestris]

Chris,

"Live monitoring is the only way to go, unless you want your customers
to surprise you with performance problems on your own site. :)"

Monitoring, ok, but alerting is critical for large scale production
environments. You mention JMX callbacks for alerting, but it would be worth
that you mention SNMP since it's very easy to set up and efficient. We also
can raise alerts on deltas with this method, and see a problem before the
CPU says something bad is going to happen. Just my feedback ;)

regards




2015-10-08 19:27 GMT+02:00 Christopher Schultz :

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Aurélien,
>
> On 10/7/15 5:59 PM, Aurélien Terrestris wrote:
> > when this happens you can do a thread-dump (kill -3 pid on Linux
> > platforms) and you would see if there is a lock on JDBC objects, or
> > anything else synchronized (from the Collections like Hashtable).
> > Not easy for beginners to understand a dump, but worth learning.
>
> +1
>
> This is the only way to find out what's going on. All other monitoring
> solutions will just tell you that *something* is wrong, but this will
> give you details.
>
> > Very often an application will slow down because Garbage
> > Collection, and the GC thread will be the only one working at that
> > time. Please use the verbose settings to have all your Tomcats log
> > GC activity. This is useful for both live and after time analysis.
>
> This is pretty unlikely for the reported observations, since Tomcat
> slows down and stops responding (presumably until restarted). That is
> more likely to be something like database connection pool being
> exhausted due to poor resource management rather than out-of-control
> GC activity.
>
> > You won't monitor mod_proxy, this has no sense.
>
> I disagree. The connection can go down for various reasons. But I
> suspect that's not the problem in this case.
>
> > If you suspect a network flood, do a 'netstat -an' to see how many
> > connections are used by your Apache (both ESTABLISHED and
> > TIME_WAIT). However, you might need to set timeout and flushpacket
> > on your proxypass directive when your application has such
> > requirements (see HTTPD doc for this settings). To know if you're
> > flooded, you can do a 'ps -eaf | grep [h]ttp' and you would see
> > many httpd process, it is similar to the netstat result more or
> > less.
>
> +1
>
> > If you enjoy live monitoring, you need to have a look on
> > Christopher's presentation (
> > http://events.linuxfoundation.org/sites/events/files/slides/Monitoring
> %20Apache%20Tomcat%20with%20JMX.pdf
> >
> >
> ) who posts many answers to this mailing list.
>
> Live monitoring is the only way to go, unless you want your customers
> to surprise you with performance problems on your own site. :)
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJWFqd5AAoJEBzwKT+lPKRYi9AQAIpHkOgXoz2Ntfdf8aH1mjTB
> gdKDu1B5fEgpTYRhV+mQ5rEegkszJ0jUEQdCVjwp2ZjldgsLPP6wXaBw6LdUG3UB
> l63K4tCkDwIiVI8rB0syAeQQ/4uUS7SmiJaLZAwLHl08mDZHs9e/LiKJ47rJjh3+
> 4pkejtbHhobF2fcH61ZM7M5qxPKlzP49dDzXyppbvEG/kk7T9FkIl2TVOT349zkP
> c1jrtC19fKDhbz72c/03/Z1V/clZ+Q3BScYHddlRw0ZXuOEu8LQJRD0VPmEY4pM5
> DTPH+z5spnYUO0hH0FHx/WGHgQ5iCrQHYG8pdkfhDEqSaDnqm4qIFxC4fChIFSuh
> c9eqor7axyOcacHvTCwPudXGuWBxK0LCnigikd83OM/EaKdRwR0ahMqXKEQkRdTn
> QW3vfsOQXXuy0vAFz6fphOkWXCr4SJWVOsAG3f1vlStMs2to4q66hpNQpLFJpcdN
> ectoRaCRvQMLdw9UhdG3z5wTCvPPj9RP8IA/Lxi48QisYOMZwABgh7mMh2+mE7pH
> tTHun4fE2HhdVPqORonHhTWldvu4xYqWav9FNBgg2ywyekAWVcrcFZRLgYhG+T37
> 0neZbSdwd/iLdsZ+sKhGY04CSwAsUZdTh87pZ+8NWH7tvi71JIt7nlI0JgRI5ipw
> Jdty982ew2WiaY0rhspW
> =Ra47
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>