Tomcat returning error 404 for any file but index.html

[Jair Santos]

Hello everyone,

 

Environment: Windows server 2012, Tomcat 8.0, Geoserver 2.8.0.

 

I deployed Geoserver into Tomcat.

 

Tomcat can serve the index.html file located in C:\Program Files\Apache
Software Foundation\Tomcat 8.0\webapps\geoserver, but it cannot serve any
other file (see log below). I know there are a list of welcome files in
web.xml such as

 

welcome-file-list>

index.html

.

 

Even including for example the index_backup.html in the welcome-file-list it
returns 404 - The requested resource is not available.

 

I've checked the permissions of the geoserver folder and the files inside
it. They seems to be okay.

 

Any help will be very much appreciated.

 

Thank you.

 

JJ.

 

 

192.168.1.1 - - [20/Oct/2015:16:57:31 -0700] "GET
/geoserver/wms?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetMap&FORMAT=image%2Fpng&T
RANSPARENT=true&LAYERS=bmid-pipes&WIDTH=256&HEIGHT=256&CRS=EPSG%3A3857&STYLE
S=&BBOX=-13315941.823503986%2C6437832.270290684%2C-13306157.883883484%2C6447
616.209911186 HTTP/1.1" 200 1796

192.168.1.1 - - [20/Oct/2015:17:12:04 -0700] "GET /geoserver/index_backup
HTTP/1.1" 404 992

 

Re: Tomcat answers on port 80, not on 443

[Christopher Schultz]

Gregory,

On 10/15/15 1:48 PM, 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:\keystore\scilexcon
> #org.apache.felix.https.keystore=./keystore/scilexcon
> org.apache.felix.https.keystore.password=redacted
> org.apache.felix.https.keystore.key.password= redacted
> org.apache.felix.https.truststore=E:\keystore\scilexcon
> #org.apache.felix.https.truststore=C:\Program 
> Files\Java\jre1.8.0_60\lib\security\cacerts
> #org.apache.felix.https.truststore=./keystore/scilexcon
> org.apache.felix.https.truststore.password= redacted

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.

-chris

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

Re: SSL and Virtual Hosting

[Christopher Schultz]

Björn,

On 10/21/15 2:47 PM, Björn Raupach wrote:
>> On 21 Oct 2015, at 20:42, Mark Thomas  wrote:
>>
>> On 21/10/2015 16:27, Björn Raupach wrote:
>>> Dear group,
>>>
>>> it would be nice if anyone knows, if my planned setup is going to work.
>>>
>>> At the moment we are having two services (web apps) at two different 
>>> machines and hostnames. Lets say bob.example.com and alice.example.com 
>>>
>>> bob.example.com runs without SSL and deploys the web app at the root 
>>> context. We just throw a ROOT.war in /webapps.
>>>
>>> alice.example.com needs SSL at all times. It currently does not run with 
>>> the root context but we would like to. So another ROOT.war. We have an SSL 
>>> cert for alice.example.com
>>>
>>> I want both applications to run on a single Tomcat instance with Virtual 
>>> Hosting. Virtual Hosting with Tomcat that is. I am comfortable with setting 
>>> up Virtual Hosting, but I am just not sure about the SSL part. Does the 
>>> choice between IP-based or Hostname matter? bob.example.com might need SSL 
>>> support in the future.
>>>
>>> We are using Amazon AWS if that is important. So I could get another 
>>> Elastic IP. We are working with the latest Apache Tomcat 8 and the latest 
>>> JDK on the server machines.
>>>
>>> Sorry if this is not 100% Tomcat related.
>>
>> Currently it will work if both hosts can share the same certificate
>> because they share a connector and (currently) a connector can only have
>> a single certificate.
> 
> How can both hosts share the same certificate?

I think he meant that if both sites "can" share a certificate, the whole
thing becomes easier. For example, a certificate with a
subject-alternative-name, or a wildcard certificate.

Recent versions of Java support SNI which should allow multiple
certificates to be used, but I'm not sure if Tomcat supports that
directly right now (see Mark's comments about multi-certificate support
in the very near future).

> Do I need a SAN certificate or can I just run with the cert for
> alice.example.com  and have to live with any
> cert errors on bob.example.com ?

Well, those are both options, but the first one costs a heap of money
and the second is unpalatable for users (errors = bad).

>> As of 9.0.x (and hopefully eventually back-ported to 8.x) you'll be able
>> to have per host certs. There should be a 9.0.0-RC1 in the next week or so.

This is the "holy grail" of TLS certificate support -- one that I hope
will be able to be back-ported without too much pain for (probably) Mark.

IIRC, this will also allow *either* PEM-file-based setup *or*
keystore-based setup regardless of the crypto implementation (OpenSSL
vs. JSSE) being used. I personally detest keystores because they are so
fault-intolerant, but they do have the advantage of being able to say
"use any matching certificate in this blob" to get work done.

So... if you are willing to wait a bit (9.0-RC1 in the next week? woah!)
for a back-port from trunk into the 8.0.x branch, then that's probably
your best bet. If you absolutely need to get this out right away, I see
only a few options:

1. Wildcard cert
2. Cert with a SAN
3. Front each service with AWS ELB
4. Front both services with httpd, which supports SNI
5. Use two s, each on a different port
6. Use two s, each on a different interface

That last one (6) might not be possible on AWS, since the host is itself
mostly unaware of the public IP address external clients use to access
it. (I have an EC2 instance with both internal and external IPs, and I
only have "lo" and "eth0" interfaces, so I couldn't bind a 
to the public IP's interface).

Option #3 might be the best for you in the short-term (and possibly the
long-term), because it allows you to easily configure TLS *and*
port-redirection without the complexity of a whole server+httpd instance
to maintain. It will also allow you to grow your service trivially in
the future should you choose to do so. The downside is that you pay for
the ELB by the bit-transferred. It's up to you to decide how much you're
willing to pay for that kind of thing.

Hope that helps,
-chris

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

Re: SSL and Virtual Hosting

[George Sexton]

On 10/21/2015 12:42 PM, Mark Thomas wrote:

Currently it will work if both hosts can share the same certificate
because they share a connector and (currently) a connector can only have
a single certificate.

As of 9.0.x (and hopefully eventually back-ported to 8.x) you'll be able
to have per host certs. There should be a 9.0.0-RC1 in the next week or so.


I'm excited to see this feature. I'm using a wild-card cert within my 
domain, but I want to offer my customers with virtual hosts the option 
of supplying their own cert in their domain.




Mark


--
George Sexton
*MH Software, Inc.*
Voice: 303 438 9585
http://www.mhsoftware.com

Re: Monitoring Connections

[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 really described the actual problem, yet.

-chris

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

Re: Question for posgresq, and jdbc.jar placement.

[Christopher Schultz]

Jose,

On 10/21/15 7:33 AM, Jose María Zaragoza wrote:
> IMHO
> 
> $CATALINA_HOME/lib  would be the right place

+1

-chris

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

Re: SSL and Virtual Hosting

[Björn Raupach]

Hello Mark,

thanks for responding

> On 21 Oct 2015, at 20:42, Mark Thomas  wrote:
> 
> On 21/10/2015 16:27, Björn Raupach wrote:
>> Dear group,
>> 
>> it would be nice if anyone knows, if my planned setup is going to work.
>> 
>> At the moment we are having two services (web apps) at two different 
>> machines and hostnames. Lets say bob.example.com and alice.example.com 
>> 
>> bob.example.com runs without SSL and deploys the web app at the root 
>> context. We just throw a ROOT.war in /webapps.
>> 
>> alice.example.com needs SSL at all times. It currently does not run with the 
>> root context but we would like to. So another ROOT.war. We have an SSL cert 
>> for alice.example.com
>> 
>> I want both applications to run on a single Tomcat instance with Virtual 
>> Hosting. Virtual Hosting with Tomcat that is. I am comfortable with setting 
>> up Virtual Hosting, but I am just not sure about the SSL part. Does the 
>> choice between IP-based or Hostname matter? bob.example.com might need SSL 
>> support in the future.
>> 
>> We are using Amazon AWS if that is important. So I could get another Elastic 
>> IP. We are working with the latest Apache Tomcat 8 and the latest JDK on the 
>> server machines.
>> 
>> Sorry if this is not 100% Tomcat related.
> 
> Currently it will work if both hosts can share the same certificate
> because they share a connector and (currently) a connector can only have
> a single certificate.

How can both hosts share the same certificate? Do I need a SAN certificate or 
can I just run with the cert for alice.example.com  
and have to live with any cert errors on bob.example.com 
? 

> 
> As of 9.0.x (and hopefully eventually back-ported to 8.x) you'll be able
> to have per host certs. There should be a 9.0.0-RC1 in the next week or so.
> 
> Mark
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org 
> 
> For additional commands, e-mail: users-h...@tomcat.apache.org 
> 

Re: SSL and Virtual Hosting

[Björn Raupach]

Dear Jason,

> On 21 Oct 2015, at 19:18, Jason Britton  wrote:
> 
> Hi Björn -
> Look in tomcat/conf at the server.xml, you'd just define multiple host
> entries, one host entry would have a name of "alice.example.com" the other
> with "bob.example.com".  Each host entry would also have its own appBase
> (alice-webapps & bob-webapps), meaning both sites could be deployed using
> ROOT.war.  Update the DNS for alice and bob to point at the server your
> consolidated tomcat is on.  Inside tomcat/conf/Catalina/ I'm pretty sure
> you're going to need a directory for each host with that hosts config
> ROOT.xml etc).

thanks. Yes, I know how to do this part.

>  We use Apache HTTPD to proxy to our Tomcats and we
> terminate SSL at HTTPD so I'm not exactly sure on your SSL questions.  Our
> SSL is configured through Apache HTTPD Virtual Hosts.  Maybe you want to
> look into the cost for a wildcard SSL cert that would cover *.example.com
> rather than specific hosts?

Unfortunately that is the scenario I am trying to prevent.
I don’t want to add another layer of complexity.
Apache Tomcat works like a charm and if it supports Virtual Hosting I don’t need
another service running.

> 
> Jason
> 
> On Wed, Oct 21, 2015 at 8:27 AM, Björn Raupach  wrote:
> 
>> Dear group,
>> 
>> it would be nice if anyone knows, if my planned setup is going to work.
>> 
>> At the moment we are having two services (web apps) at two different
>> machines and hostnames. Lets say bob.example.com and alice.example.com
>> 
>> bob.example.com runs without SSL and deploys the web app at the root
>> context. We just throw a ROOT.war in /webapps.
>> 
>> alice.example.com needs SSL at all times. It currently does not run with
>> the root context but we would like to. So another ROOT.war. We have an SSL
>> cert for alice.example.com
>> 
>> I want both applications to run on a single Tomcat instance with Virtual
>> Hosting. Virtual Hosting with Tomcat that is. I am comfortable with setting
>> up Virtual Hosting, but I am just not sure about the SSL part. Does the
>> choice between IP-based or Hostname matter? bob.example.com might need
>> SSL support in the future.
>> 
>> We are using Amazon AWS if that is important. So I could get another
>> Elastic IP. We are working with the latest Apache Tomcat 8 and the latest
>> JDK on the server machines.
>> 
>> Sorry if this is not 100% Tomcat related.
>> 
>> Thanks for taking the time!
>> 
>> 
>> with kind regards,
>> Björn
>> 
>> -
>> 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: SSL and Virtual Hosting

[Mark Thomas]

On 21/10/2015 16:27, Björn Raupach wrote:
> Dear group,
> 
> it would be nice if anyone knows, if my planned setup is going to work.
> 
> At the moment we are having two services (web apps) at two different machines 
> and hostnames. Lets say bob.example.com and alice.example.com 
> 
> bob.example.com runs without SSL and deploys the web app at the root context. 
> We just throw a ROOT.war in /webapps.
> 
> alice.example.com needs SSL at all times. It currently does not run with the 
> root context but we would like to. So another ROOT.war. We have an SSL cert 
> for alice.example.com
> 
> I want both applications to run on a single Tomcat instance with Virtual 
> Hosting. Virtual Hosting with Tomcat that is. I am comfortable with setting 
> up Virtual Hosting, but I am just not sure about the SSL part. Does the 
> choice between IP-based or Hostname matter? bob.example.com might need SSL 
> support in the future.
> 
> We are using Amazon AWS if that is important. So I could get another Elastic 
> IP. We are working with the latest Apache Tomcat 8 and the latest JDK on the 
> server machines.
> 
> Sorry if this is not 100% Tomcat related.

Currently it will work if both hosts can share the same certificate
because they share a connector and (currently) a connector can only have
a single certificate.

As of 9.0.x (and hopefully eventually back-ported to 8.x) you'll be able
to have per host certs. There should be a 9.0.0-RC1 in the next week or so.

Mark


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

Re: Monitoring Connections

[Jamie Jackson]

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.

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 doubt that this is the *sole* culprit, but it *is* something for me to
tweak.

Thanks,
Jamie


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

Re: httpd 2.2 +mod-jk1.2.37+ tomcat 7.0.28 (debian package)

[tomcat]

On 20.10.2015 00:13, J Lopez wrote:

Hi all,

   is it possible to filter 404 application errors taking into account
content-type beside http return code in jk configuration.
   I need to difference between application is not deployed/executing (http
404 content-type html) and application running and returning a 404 json
response (content-type json)

   I have put mod-jk in debug mode and content-type is showed in logs. I
have not seen in documentation if a fail_on_status can be combined with
content-type returned.


[...]

I have not seen this in the documentation either, and it does not look like this feature 
is available.


But if I understand correctly, you have 2 cases of 404 :

1) if the application is for Tomcat "not there" (meaning for example it is not deployed at 
that particular moment), then Tomcat itself returns a 404.

2) if the application is there and working, in some cases it returns a 404 
itself.

And for some reason, you want to distinguish these 2 cases.

(It would help to know why, and at what level you want to distinguish this)

But let's suppose that the application is normally installed at (tomcat)/webapps/app1, and 
responds to URLs like "/app1/*".


If the "/webapps/app1" application is not there, then Tomcat will try to map this to the 
default application, "/webapps/ROOT/app1/*".  Then it will probably not find it there 
either, and return a 404 response.


If the application is there, then Tomcat will (succesfully) map the call to 
/webapps/app1/*", and the application will respond. And, maybe, it will sometimes respond 
with a 404.


So two possible solutions :
1) change the application, so that in such a case, it responds with something 
else than 404.
2) install something in /ROOT, which will catch everything that gets there, and respond 
with something else than 404.
That supposes of course that you do not previously have a default application under 
/webapps/ROOT.





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

Re: Tracking down memory leak

[David kerber]

On 10/21/2015 1:08 PM, Christopher Schultz wrote:

Rallavagu,

On 10/20/15 9:46 AM, Rallavagu wrote:

Please take a look at Memory Analyzer tool
(http://www.eclipse.org/mat/). Run the app and take the heap dump while
app is running and use the tool to analyze it. You could use VisualVM
with plugins to get instrumentation or you could use hprof
(http://docs.oracle.com/javase/7/docs/technotes/samples/hprof.html)


+1

If you have a huge number of a certain type of object, that can help you
understand what is going on. I use YourKit (I get a free license as an
ASF committer) and it can do things like find memory-consuming object
trees, like maybe a cache that is taking up 3GiB when you thought it
would maybe stop at 100MiB.


Thanks for the suggestion, guys!  I used visualvm and was able to get it 
straightened out.



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

Re: SSL and Virtual Hosting

[Jason Britton]

Hi Björn -
Look in tomcat/conf at the server.xml, you'd just define multiple host
entries, one host entry would have a name of "alice.example.com" the other
with "bob.example.com".  Each host entry would also have its own appBase
(alice-webapps & bob-webapps), meaning both sites could be deployed using
ROOT.war.  Update the DNS for alice and bob to point at the server your
consolidated tomcat is on.  Inside tomcat/conf/Catalina/ I'm pretty sure
you're going to need a directory for each host with that hosts config
ROOT.xml etc).  We use Apache HTTPD to proxy to our Tomcats and we
terminate SSL at HTTPD so I'm not exactly sure on your SSL questions.  Our
SSL is configured through Apache HTTPD Virtual Hosts.  Maybe you want to
look into the cost for a wildcard SSL cert that would cover *.example.com
rather than specific hosts?

Jason

On Wed, Oct 21, 2015 at 8:27 AM, Björn Raupach  wrote:

> Dear group,
>
> it would be nice if anyone knows, if my planned setup is going to work.
>
> At the moment we are having two services (web apps) at two different
> machines and hostnames. Lets say bob.example.com and alice.example.com
>
> bob.example.com runs without SSL and deploys the web app at the root
> context. We just throw a ROOT.war in /webapps.
>
> alice.example.com needs SSL at all times. It currently does not run with
> the root context but we would like to. So another ROOT.war. We have an SSL
> cert for alice.example.com
>
> I want both applications to run on a single Tomcat instance with Virtual
> Hosting. Virtual Hosting with Tomcat that is. I am comfortable with setting
> up Virtual Hosting, but I am just not sure about the SSL part. Does the
> choice between IP-based or Hostname matter? bob.example.com might need
> SSL support in the future.
>
> We are using Amazon AWS if that is important. So I could get another
> Elastic IP. We are working with the latest Apache Tomcat 8 and the latest
> JDK on the server machines.
>
> Sorry if this is not 100% Tomcat related.
>
> Thanks for taking the time!
>
>
> with kind regards,
> Björn
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Tracking down memory leak

[Christopher Schultz]

Rallavagu,

On 10/20/15 9:46 AM, Rallavagu wrote:
> Please take a look at Memory Analyzer tool
> (http://www.eclipse.org/mat/). Run the app and take the heap dump while
> app is running and use the tool to analyze it. You could use VisualVM
> with plugins to get instrumentation or you could use hprof
> (http://docs.oracle.com/javase/7/docs/technotes/samples/hprof.html)

+1

If you have a huge number of a certain type of object, that can help you
understand what is going on. I use YourKit (I get a free license as an
ASF committer) and it can do things like find memory-consuming object
trees, like maybe a cache that is taking up 3GiB when you thought it
would maybe stop at 100MiB.

-chris

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

Re: httpd 2.2 +mod-jk1.2.37+ tomcat 7.0.28 (debian package)

[Christopher Schultz]

J,

On 10/19/15 6:13 PM, J Lopez wrote:
>   is it possible to filter 404 application errors taking into account
> content-type beside http return code in jk configuration.
>   I need to difference between application is not deployed/executing (http
> 404 content-type html) and application running and returning a 404 json
> response (content-type json)

You want to handle this on the httpd-side or the Tomcat side?

> I have put mod-jk in debug mode and content-type is showed in logs. I
> have not seen in documentation if a fail_on_status can be combined with
> content-type returned.

One way to do this is to have a do-nothing ROOT application that has a
custom 404 error page that sets a different status: even something
that's very unusual. So the order of events would go like this:

GET /myapp/some/page - not found -> application returns 404 to httpd

GET /unknown/page - not found -> ROOT catches 404, returns 505 to httpd

Does that help?

-chris

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

Re: Monitoring Connections

[Christopher Schultz]

Jamie,

On 10/16/15 3:12 PM, Jamie Jackson wrote:
> On Tue, Oct 13, 2015 at 9:34 AM, Christopher Schultz <
> ch...@christopherschultz.net> wrote:
> 
> Jamie,
> 
> On 10/9/15 10:03 AM, Jamie Jackson wrote:
 Here's the stack trace dump:
 https://gist.github.com/jamiejackson/ca2a49d2c8afac496067

 FWIW, I've been trying to come up with a reliable test case to
 trigger the problem, but I haven't nailed it yet. I've suspected
 that it's related to file (large or slow) HTTP file uploads, and
 that's what I was running at the time, which helps to explain the
 java.net.SocketInputStream.socketRead0 traces.
> 
> Your server looks mostly idle. It also looks like it's running both
> Tomcat and Jetty in the same instance. What's going on?
> 
> 
>> I'm not sure yet. I'm asking around, and I'll let you know.
>
> About the appearance of Jetty in the stack trace dump: It's part of
> FusionReactor (the JVM monitor)--it uses Jetty to serve its interface.

Okay.

 "http-bio--exec-19" Id=27307 RUNNABLE (in native)
 java.lang.Thread.State: RUNNABLE at
 java.net.SocketInputStream.socketRead0(Native Method) at
 java.net.SocketInputStream.read(SocketInputStream.java:152) at
 java.net.SocketInputStream.read(SocketInputStream.java:122) at
 [...]
> org.apache.commons.fileupload.MultipartStream$ItemInputStream.read(MultipartStream.java:887)
 at java.io.BufferedInputStream.read1(BufferedInputStream.java:273)
 at java.io.BufferedInputStream.read(BufferedInputStream.java:334) -
 locked java.io.BufferedInputStream@6e81abfc at
 java.io.FilterInputStream.read(FilterInputStream.java:107)
> 
> Obviously, this thread is reading a file upload. Also these:
> 
> "http-bio--exec-21" Id=27309 RUNNABLE (in native)
>java.lang.Thread.State: RUNNABLE
> "http-bio--exec-26" Id=27314 RUNNABLE (in native)
>java.lang.Thread.State: RUNNABLE
> 
> This thread is making an outgoing HTTP request, which could be hanging:
> 
 "Thread-27550" Id=27623 RUNNABLE (in native)
 java.lang.Thread.State: RUNNABLE at
 java.net.SocketInputStream.socketRead0(Native Method) at
 java.net.SocketInputStream.read(SocketInputStream.java:152) at
 java.net.SocketInputStream.read(SocketInputStream.java:122) at
 sun.security.ssl.InputRecord.readFully(InputRecord.java:442) at
 sun.security.ssl.InputRecord.read(InputRecord.java:480) at
 sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:934) -
 locked java.lang.Object@659eed19 at
 sun.security.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:891)
> 
> Same with this one:
> 
> "Thread-27551" Id=27624 RUNNABLE (in native)
>java.lang.Thread.State: RUNNABLE
> 
> But neither of the above threads making HTTP requests are
> request-processing threads: they are independent and shouldn't block
> incoming requests.
> 
> You have 12 total request-processing threads: the ones named
> "http-bio--exec-[#]". Most of them aren't doing anything -- just
> waiting on a new request to come in.
> 
> You have an AJP connector defined, but it looks like it's not being used.
> 
> Initially, you said that you used mod_proxy from httpd. Are you
> expecting to use mod_proxy_http or mod_proxy_ajp?
> 
> 
>> mod_proxy_http, as far as I know, but see below...

Yes, you are using mod_proxy_http.

> When you try to make a connection during these incidents, do you get
> any errors on the httpd side?
> 
> 
>> Unfortunately, at the time, I thought this would be easy to reproduce, so I
>> didn't take enough notes (including the time of the problem on my load test
>> box). Here are some errors that I think were just created by the app timing
>> out requests. I don't think these were associated with the failed requests,
>> so take these entries (from httpd's error_log) with a grain of salt:
>> https://gist.github.com/jamiejackson/2f16ca83bdfc9c8f8795#file-errors-txt

There's not a whole lot in there, other than the fact that something
"bad" happened.

> Can you post your  configuration from conf/server.xml?
> Remember to remove any sensitive information that you might have in there.
> 
> 
>> I think this is what you're after:
> 
>> >connectionTimeout="93000"
>>redirectPort="8443" />

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 betwe

SSL and Virtual Hosting

[Björn Raupach]

Dear group,

it would be nice if anyone knows, if my planned setup is going to work.

At the moment we are having two services (web apps) at two different machines 
and hostnames. Lets say bob.example.com and alice.example.com 

bob.example.com runs without SSL and deploys the web app at the root context. 
We just throw a ROOT.war in /webapps.

alice.example.com needs SSL at all times. It currently does not run with the 
root context but we would like to. So another ROOT.war. We have an SSL cert for 
alice.example.com

I want both applications to run on a single Tomcat instance with Virtual 
Hosting. Virtual Hosting with Tomcat that is. I am comfortable with setting up 
Virtual Hosting, but I am just not sure about the SSL part. Does the choice 
between IP-based or Hostname matter? bob.example.com might need SSL support in 
the future.

We are using Amazon AWS if that is important. So I could get another Elastic 
IP. We are working with the latest Apache Tomcat 8 and the latest JDK on the 
server machines.

Sorry if this is not 100% Tomcat related.

Thanks for taking the time!


with kind regards,
Björn
 
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Question for posgresq, and jdbc.jar placement.

[Jose María Zaragoza]

2015-10-21 13:19 GMT+02:00 Andrew Davis :

> Ok, I'm embarrassed.
>
> I've got a UBUNTU (GUI included) install of Tomcat7 installed from command
> line.
>
> Inside my machine I have what looks like two locations that play a key
> role.
>
> OPTION 1 for the jdbc.jar file?
>   I think that this is the "$CATALINA" base
>   Path:  usr/share/tomcat7
>  Folders Inside: (bin, common, conf, lib, log, server, shared)
>  Files Inside: (defaults.md5sum, defaults.template,
> logrotate.md5sum, logrotate.template)
>
> OPTION 2 for the jdbc.jar file?
>  I'm not sure if this would be the "$CATALINA" home
>  Path: var/lib/tomcat7
>  Folders Inside: (common, conf, logs, server, shared, webapps,
> work)
>  **When I upload a .war file from the
> http://localhost/manager/html interface it is placed in the "webapps"**
>
>
>
Probably you have symbolic links in /usr/share/tomcat7
Have a look

ls -lrt tomcat7




>
> OPTION 3 for the jdbc.jar file?***  *This is working, but I am going
> to write multiple apps which would use this .jar file.
> do I just include multiple copies of the .jar, or is there a central place
> to put it (please no jokes here).
> [image: Inline image 2]
>


IMHO

$CATALINA_HOME/lib  would be the right place





>
>
> Andy...
>

Question for posgresq, and jdbc.jar placement.

[Andrew Davis]

Ok, I'm embarrassed.

I've got a UBUNTU (GUI included) install of Tomcat7 installed from command
line.

Inside my machine I have what looks like two locations that play a key role.

OPTION 1 for the jdbc.jar file?
  I think that this is the "$CATALINA" base
  Path:  usr/share/tomcat7
 Folders Inside: (bin, common, conf, lib, log, server, shared)
 Files Inside: (defaults.md5sum, defaults.template,
logrotate.md5sum, logrotate.template)

OPTION 2 for the jdbc.jar file?
 I'm not sure if this would be the "$CATALINA" home
 Path: var/lib/tomcat7
 Folders Inside: (common, conf, logs, server, shared, webapps, work)
 **When I upload a .war file from the
http://localhost/manager/html interface
it is placed in the "webapps"**



OPTION 3 for the jdbc.jar file?***  *This is working, but I am going to
write multiple apps which would use this .jar file.
do I just include multiple copies of the .jar, or is there a central place
to put it (please no jokes here).
[image: Inline image 2]


Andy...

[ANN] Apache Tomcat 7.0.65 released

[Violeta Georgieva]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 7.0.65.

Apache Tomcat is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Expression Language and Java
WebSocket technologies.

This release contains a number of bug fixes and improvements compared to
version 7.0.64. The notable changes since 7.0.64 include:


- Add a web application class loader implementation that supports the
parallel
  loading of web application classes. Use of this feature requires a Java 7
or
  later JRE


Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-7.0-doc/changelog.html

Note: This version has 4 zip binaries: a generic one and
  three bundled with Tomcat native binaries for Windows operating
  systems running on different CPU architectures.

Note: Use of the Java WebSocket 1.1 implementation requires Java 7.

Note: If you use the APR/native AJP or HTTP connector you *must* upgrade
  to version 1.1.33 or later of the APR/native library.

Downloads:
http://tomcat.apache.org/download-70.cgi

Migration guides from Apache Tomcat 5.5.x and 6.0.x:
http://tomcat.apache.org/migration.html

Enjoy

The Apache Tomcat team