date:20100727

> From: Ivan [mailto:xhh...@gmail.com]
> Subject: Re: FileDirContext returns the path directly without checking
> whether the target file really exists
> 
> I copied some words from the spec, the the second paragraph, 
> it says something about resources in the META-INF/resources 
> directory, if we do not need to care about whether the real
> file exists, I think we could never go into this situation,
> we might always have a path in the default context.
> right ?

No.  The resource may or may not exist completely independently of whether or 
not the webapp has some location in the file system; you're confusing the 
situations.  One can use getRealPath() to determine the path for a resource the 
webapp wants to /create/, not just one the webapp wants to read.  If you want 
to see if the path returned points to an existing file, there are ample APIs in 
the JRE to let you do so.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


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

Re: FileDirContext returns the path directly without checking whether the target file really exists

2010-07-27 Thread Ivan

I copied some words from the spec, the the second paragraph, it says
something about resources in the META-INF/resources directory, if we do not
need to care about whether the real file exists, I think we could never go
into this situation, we might always have a path in the default context.
right ?
--->
The getRealPath method takes a String argument and returns a String
representation of a file on the local file system to which a path
corresponds. The
getPathTranslated method computes the real path of the pathInfo of the
request.
In situations where the servlet container cannot determine a valid file path
for these
methods, such as when the Web application is executed from an archive, on a
remote
file system not accessible locally, or in a database, these methods must
return null.
Resources inside the META-INF/resources directory of JAR file must be
considered only if the container has unpacked them from their containing JAR
file
when a call to getRealPath() is made, and in this case MUST return the
unpacked
location.
<---

2010/7/28 Mark Thomas 

> On 26/07/2010 03:20, Ivan wrote:
> > Hi,
> > Seems that the doGetRealPath method in the FileDirContext returns the
> > path directly without checking the target file or folder exists, so is it
> > expected or file checking is required ?
>
> I don't see anything in the Servlet specification that says that the
> real path has to exist. Do you?
>
> Mark
>
> > --->
> > @Override
> > protected String doGetRealPath(String path) {
> > File file = new File(getDocBase(), path);
> > return file.getAbsolutePath();
> > }
> ><---
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


-- 
Ivan

RE: Tomcat Shutting Down by Itself?

> From: André Warnier [mailto:a...@ice-sa.com]
> Subject: Re: Tomcat Shutting Down by Itself?
> 
> > 1) Enable a SecurityManager (usually a major pain).
> 
> Because you would need to authorise everything else that this
> application /might/ be doing, except system.exit(), right ?

Correct.  Getting the settings right might involve much experimentation and a 
few application errors along the way - it all depends on what the webapp needs 
to do.

> > 2) Use System.getRuntime().addShutdownHook() to trigger 
> > your own thread when the JVM does decide to exit.
>
> would that mean adding another application which is launched 
> at Tomcat start, and runs the above ?

Yes, that would probably be the easiest way.

> Or do you need to do this in the application itself ?

No, since the shutdown hook applies to the JVM, not individual webapps.

> No other way from "outside", apart from the SecurityManager ?

Not that I can think of right off the bat.  Others might know easier tricks 
specific to Tomcat.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


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

RE: Tomcat Shutting Down by Itself?

>> 2) Use System.getRuntime().addShutdownHook() to trigger your 
>> own thread when the JVM does decide to exit.
> 
> Assuming the OP does not have easy access to the running 
> application, would that mean adding another application 
> which is launched at Tomcat start, and runs the above ?
> Or do you need to do this in the application itself ?

That was my next question, too.

--
Eric Robinson


Disclaimer - July 27, 2010 
This email and any files transmitted with it are confidential and intended 
solely for Tomcat Users List. If you are not the named addressee you should not 
disseminate, distribute, copy or alter this email. Any views or opinions 
presented in this email are solely those of the author and might not represent 
those of . Warning: Although  has taken reasonable precautions to ensure no 
viruses are present in this email, the company cannot accept responsibility for 
any loss or damage arising from the use of this email or attachments. 
This disclaimer was added by Policy Patrol: http://www.policypatrol.com/

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

Re: Tomcat Shutting Down by Itself?

Caldarale, Charles R wrote:

From: André Warnier [mailto:a...@ice-sa.com]
Subject: Re: Tomcat Shutting Down by Itself?

Would there be any specific way to catch a call to system.exit() ?

1) Enable a SecurityManager (usually a major pain).

Because you would need to authorise everything else that this application /might/ be 
doing, except system.exit(), right ?

2) Use System.getRuntime().addShutdownHook() to trigger your own thread when 
the JVM does decide to exit.

Assuming the OP does not have easy access to the running application, would that mean 
adding another application which is launched at Tomcat start, and runs the above ?

Or do you need to do this in the application itself ?

No other way from "outside", apart from the SecurityManager ?

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

RE: Tomcat Shutting Down by Itself?

> From: André Warnier [mailto:a...@ice-sa.com]
> Subject: Re: Tomcat Shutting Down by Itself?
> 
> Would there be any specific way to catch a call to system.exit() ?

1) Enable a SecurityManager (usually a major pain).

2) Use System.getRuntime().addShutdownHook() to trigger your own thread when 
the JVM does decide to exit.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


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

Re: Tomcat Shutting Down by Itself?


Mark Thomas wrote:

On 27/07/2010 21:20, Robinson, Eric wrote:
this particular set of users of this complex application, uses 
a particular functionality of the application, used by no other 
set of users, and that particular functionality contains 
(or triggers) a bug that blows away the server. 

That seems like the reasonable conclusion. The next question is whether
there is a way to trap it and see what is happening.


Access logs and look for a common pattern?

That would be a possibility too, simple if it works.  But access logs have a habit of 
being written at the end of a transaction, so in a case like this one, where the server 
just disapears without any evident trace, you may miss exactly the one that you are 
looking for.  I don't know about Tomcat though.


Would there be any specific way to catch a call to system.exit() ?

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

Re: Tomcat Shutting Down by Itself?

On 27/07/2010 21:20, Robinson, Eric wrote:
>> this particular set of users of this complex application, uses 
>> a particular functionality of the application, used by no other 
>> set of users, and that particular functionality contains 
>> (or triggers) a bug that blows away the server. 
> 
> That seems like the reasonable conclusion. The next question is whether
> there is a way to trap it and see what is happening.

Access logs and look for a common pattern?

Mark



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

RE: Tomcat Shutting Down by Itself?

> this particular set of users of this complex application, uses 
> a particular functionality of the application, used by no other 
> set of users, and that particular functionality contains 
> (or triggers) a bug that blows away the server. 

That seems like the reasonable conclusion. The next question is whether
there is a way to trap it and see what is happening.

--
Eric Robinson



Disclaimer - July 27, 2010 
This email and any files transmitted with it are confidential and intended 
solely for Tomcat Users List. If you are not the named addressee you should not 
disseminate, distribute, copy or alter this email. Any views or opinions 
presented in this email are solely those of the author and might not represent 
those of . Warning: Although  has taken reasonable precautions to ensure no 
viruses are present in this email, the company cannot accept responsibility for 
any loss or damage arising from the use of this email or attachments. 
This disclaimer was added by Policy Patrol: http://www.policypatrol.com/

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

Re: Tomcat Shutting Down by Itself?


André Warnier wrote:

Robinson, Eric wrote:
Yes. Each instance serves a different set of users in a local office 
somewhere.


By that I mean each pair of load-balanced instances serves a set of
users in a local office somewhere.


Then my suspicions would be as follows :
this particular set of users of this complex application, uses a 
particular functionality of the application, used by no other set of 
users, and that particular functionality contains (or triggers) a bug 
that blows away the server.



And we have a set of options here :
- tell the customer to close down that office and move the people somewhere else, to a 
Tomcat instance that works. I they also then crash that one, then we know
- more efficiently : switch the ports between those instances, and some other set of 
instances which at the moment do not crash.  If the other one then starts crashing, then 
we also know. (Of course that may not work if each instance has its particular set of 
back-end data. That would be messy.)

- or else, start capturing the packets destined to these crashing instances of 
Tomcat.
Since they have their own port, it should be easy to do that with wireshark, filtering on 
the destination port.  The next time it crashes, examine the end of the packet capture to 
see if you can determine the sequence which crashes the server.
- or maybe simpler : when one of these instances crashes, do the users notice anything ? 
or does it just smoothly switch to the other balanced instance ?

If they notice, they may be able to tell what they were doing just before ?



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

Re: Tomcat Shutting Down by Itself?


Robinson, Eric wrote:
Yes. Each instance serves a different set of users 
in a local office somewhere.


By that I mean each pair of load-balanced instances serves a set of
users in a local office somewhere.


Then my suspicions would be as follows :
this particular set of users of this complex application, uses a particular functionality 
of the application, used by no other set of users, and that particular functionality 
contains (or triggers) a bug that blows away the server.


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

RE: Tomcat Shutting Down by Itself?

> Yes. Each instance serves a different set of users 
> in a local office somewhere.

By that I mean each pair of load-balanced instances serves a set of
users in a local office somewhere.

--


Disclaimer - July 27, 2010 
This email and any files transmitted with it are confidential and intended 
solely for Tomcat Users List. If you are not the named addressee you should not 
disseminate, distribute, copy or alter this email. Any views or opinions 
presented in this email are solely those of the author and might not represent 
those of . Warning: Although  has taken reasonable precautions to ensure no 
viruses are present in this email, the company cannot accept responsibility for 
any loss or damage arising from the use of this email or attachments. 
This disclaimer was added by Policy Patrol: http://www.policypatrol.com/

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

RE: Tomcat Shutting Down by Itself?

>> 364600 491072 java5101  <--Here's the occasional bad boy
>> 604780 746120 java   31131  <--Here's the occasional bad boy.

> Those sizes appear to be in Kbyte, so we are talking in one 
> case of a process with a resident size of 360 MB, in the other of 
> 600 MB.I guess thus, that these are not instances of JVM started 
> with -Xms64M and -Xmx64M ? 

That's correct. This instance is started with '-ms256M -mx256M' on app03
and '-ms512M -mx512M' on app04.

> Mmm. So these instances are running the same application and version 
> of ditto, on different hosts, and they both crash sometimes.
> But the same application/version is running in other instances, 
> which do not crash.

Exactly.

> Are the ones that crash used by the same users on both instances?

Yes. The instances are behind a load balancer that uses a weighted least
connection algorithm with 6 minutes of session persistence based on
source IP. So the initial connection from any workstation goes to the
server that is currently serving the fewest connections, but then
subsequent connections from the same workstation go to the same server
(unless it goes down or 6 idle minutes elapse).

> and are these users different ones than the ones using the other
instances of the app that never crash ?

Yes. Each instance serves a different set of users in a local office
somewhere.

--
Eric Robinson



Disclaimer - July 27, 2010 
This email and any files transmitted with it are confidential and intended 
solely for Tomcat Users List. If you are not the named addressee you should not 
disseminate, distribute, copy or alter this email. Any views or opinions 
presented in this email are solely those of the author and might not represent 
those of . Warning: Although  has taken reasonable precautions to ensure no 
viruses are present in this email, the company cannot accept responsibility for 
any loss or damage arising from the use of this email or attachments. 
This disclaimer was added by Policy Patrol: http://www.policypatrol.com/

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

Re: Tomcat Shutting Down by Itself?


Robinson, Eric wrote:
Intuitively, I would have never thought that it was 
/possible/ to run 160 or so instances of Tomcat on 
anything but some type of very expensive hardware.


I assure you that it works admirably! And each of the instances runs a
sophisticated medical application with hundreds of JSPs and class files.

The data above, and your comments, seem to make unlikely 
the OOM hypothesis, unless you have one application suddenly

acting up.


Also, we run a script that checks the logs for OOM errors and those are
not showing up.

On which of those servers is the one Tomcat instance dying ? 
on both ?  


Both occasionally. But now that we're digging into it, it has not
happened for several days on either one. :-/

Is that Tomcat instance running an application 
which the other ones don't ?


They all run copies of the same application, albeit slightly different
versions. But the one that is shutting down is running the same version
as other instances that are not shutting down.

What kind of memory usage do the Tomcat instances have 
(in total, including the Heap) ? 


Depends on which server and when you check. Right now on app03:

[r...@app03 ~]# ps axo rss,vsz,comm,pid|grep java|sort -g
44984 251104 java 9151
47972 251876 java10753
50816 253200 java19077
59540 253160 java17079
61780 254840 java12740
73196 244908 java26675
76580 252984 java29065
78224 262196 java  981
89080 255308 java17223
93968 255196 java13046
98272 256228 java17481
99440 256012 java25020
101744 264704 java9529
106160 258664 java   19425
108476 257452 java   26549
109712 266980 java8853
113688 261296 java   14086
117596 270040 java   26159
118356 269264 java8912
121316 270460 java   10800
123248 263196 java5202
125764 257728 java   28540
126544 258128 java7774
128084 267096 java   25420
128448 267420 java   13290
128508 259092 java   29286
129588 258800 java   21942
130068 265700 java   12465
130924 260472 java   29974
131484 268980 java8812
132208 261088 java7585
132560 268264 java   17343
133632 264320 java   16501
134232 261116 java   29183
135548 269132 java   10609
136932 273096 java   28742
140224 273052 java   12246
140624 274484 java   15351
141780 263020 java   12765
144948 264512 java9292
148512 276672 java9300
148900 267820 java9547
150448 724588 java   12883
152224 270336 java   13083
153040 271260 java9236
153300 293472 java9634
153648 276708 java   31556
154324 272836 java9041
154520 265512 java9894
155176 272788 java   11453
155940 271532 java   10843
155940 274996 java   15897
156920 273980 java8772
157240 271088 java   28906
157596 273128 java   16910
158852 275100 java   16096
160516 267404 java8813
161060 279840 java   11403
161840 277244 java   11150
162176 274532 java   11876
162508 271484 java9341
162672 274292 java   13402
162960 274220 java   10226
163460 279256 java   25700
163840 282796 java9988
164248 277304 java   18237
164800 277576 java   26965
164928 278300 java   32556
164992 274972 java   11334
165284 282936 java9587
165608 275548 java6217
165992 277956 java   24426
166180 271832 java   18542
166548 274660 java   10662
167004 277668 java   10179
167064 284676 java9386
167656 278904 java   12672
167712 278332 java6112
167716 278484 java 715
168052 278188 java3376
168224 274312 java2910
168720 277072 java   32519
170104 274900 java7194
170864 278304 java   16399
171036 275596 java   10375
171392 279968 java   12195
171884 281372 java   11207
172716 276524 java   23927
173192 279232 java2755
173636 279772 java   11569
173688 278308 java   18800
174560 277796 java   10721
174660 279300 java   31576
175448 278176 java   12907
175784 287360 java9198
176632 281812 java   15212
177588 293016 java   11750
178272 282860 java   19846
178704 280868 java   12023
179476 283092 java   28283
182580 283768 java   18964
183496 284244 java   15746
184928 282928 java9942
185100 287952 java   30676
186124 28 java   16051
186312 294096 java9100
187360 305840 java   29874
190032 303316 java   1126

RE: Tomcat Shutting Down by Itself?

> Intuitively, I would have never thought that it was 
> /possible/ to run 160 or so instances of Tomcat on 
> anything but some type of very expensive hardware.

I assure you that it works admirably! And each of the instances runs a
sophisticated medical application with hundreds of JSPs and class files.

> The data above, and your comments, seem to make unlikely 
> the OOM hypothesis, unless you have one application suddenly
> acting up.

Also, we run a script that checks the logs for OOM errors and those are
not showing up.

> On which of those servers is the one Tomcat instance dying ? 
> on both ?  

Both occasionally. But now that we're digging into it, it has not
happened for several days on either one. :-/

> Is that Tomcat instance running an application 
> which the other ones don't ?

They all run copies of the same application, albeit slightly different
versions. But the one that is shutting down is running the same version
as other instances that are not shutting down.

> What kind of memory usage do the Tomcat instances have 
> (in total, including the Heap) ? 

Depends on which server and when you check. Right now on app03:

[r...@app03 ~]# ps axo rss,vsz,comm,pid|grep java|sort -g
44984 251104 java 9151
47972 251876 java10753
50816 253200 java19077
59540 253160 java17079
61780 254840 java12740
73196 244908 java26675
76580 252984 java29065
78224 262196 java  981
89080 255308 java17223
93968 255196 java13046
98272 256228 java17481
99440 256012 java25020
101744 264704 java9529
106160 258664 java   19425
108476 257452 java   26549
109712 266980 java8853
113688 261296 java   14086
117596 270040 java   26159
118356 269264 java8912
121316 270460 java   10800
123248 263196 java5202
125764 257728 java   28540
126544 258128 java7774
128084 267096 java   25420
128448 267420 java   13290
128508 259092 java   29286
129588 258800 java   21942
130068 265700 java   12465
130924 260472 java   29974
131484 268980 java8812
132208 261088 java7585
132560 268264 java   17343
133632 264320 java   16501
134232 261116 java   29183
135548 269132 java   10609
136932 273096 java   28742
140224 273052 java   12246
140624 274484 java   15351
141780 263020 java   12765
144948 264512 java9292
148512 276672 java9300
148900 267820 java9547
150448 724588 java   12883
152224 270336 java   13083
153040 271260 java9236
153300 293472 java9634
153648 276708 java   31556
154324 272836 java9041
154520 265512 java9894
155176 272788 java   11453
155940 271532 java   10843
155940 274996 java   15897
156920 273980 java8772
157240 271088 java   28906
157596 273128 java   16910
158852 275100 java   16096
160516 267404 java8813
161060 279840 java   11403
161840 277244 java   11150
162176 274532 java   11876
162508 271484 java9341
162672 274292 java   13402
162960 274220 java   10226
163460 279256 java   25700
163840 282796 java9988
164248 277304 java   18237
164800 277576 java   26965
164928 278300 java   32556
164992 274972 java   11334
165284 282936 java9587
165608 275548 java6217
165992 277956 java   24426
166180 271832 java   18542
166548 274660 java   10662
167004 277668 java   10179
167064 284676 java9386
167656 278904 java   12672
167712 278332 java6112
167716 278484 java 715
168052 278188 java3376
168224 274312 java2910
168720 277072 java   32519
170104 274900 java7194
170864 278304 java   16399
171036 275596 java   10375
171392 279968 java   12195
171884 281372 java   11207
172716 276524 java   23927
173192 279232 java2755
173636 279772 java   11569
173688 278308 java   18800
174560 277796 java   10721
174660 279300 java   31576
175448 278176 java   12907
175784 287360 java9198
176632 281812 java   15212
177588 293016 java   11750
178272 282860 java   19846
178704 280868 java   12023
179476 283092 java   28283
182580 283768 java   18964
183496 284244 java   15746
184928 282928 java9942
185100 287952 java   30676
186124 28 java   16051
186312 294096 java9100
187360 305840 java   29874
190032 303316 java   11266
190

Re: JMX access with SSL

On 26/07/2010 14:37, Rainer Frey wrote:
> Hi,
> 
> per Java SE Monitoring and Management Guide, JMX access with SSL needs a 
> keystore with certificate which is configured with the Java System property 
> javax.net.ssl.keyStore. Is it safe to set this property for Tomcat (current 
> 6.0) to use SSL for JMX, or might this interfere with the SSL configuration 
> of 
> a HTTP connector?

Should be. I don't see that property in the docs:
http://tomcat.apache.org/tomcat-6.0-doc/config/http.html#SSL_Support

Mark



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

Re: tomcat 6.0.18 stops on Suse Linux Enterprise 10

On 27/07/2010 11:52, VERES ZOLTAN wrote:
> Hi All,
> 
> I have a serious problem with tomcat on linux.
> Tomcat often stops with the error "Connection refused".

Does the process actually terminate? Or when you write "stops" do you
mean "stops accepting connections".

> Clients can not connect to the server and even the tomcat default page can 
> not be displayed.
> When this error occurs, one of the following two JAVA processes has 200% CPU 
> load.
> But I'm not sure this causes the problem.
> 
> /usr/java/jre1.6.0_10/bin/java 
> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager.
> 
> /usr/java/jre1.6.0_10/bin/java 
> -Djava.util.logging.config.file=/opt/tomcat/conf/logging.properties.

Are those really two separate processes? That would suggest multiple
Tomcat instances.

> If I terminate the JAVA process listed above with kill -9, and restart Tomcat 
> with catalina.sh start, it works again for a while. After 10 minutes, it 
> stops again, but this working period can be hours.

Don't do that.

When the problem occurs, take 3 thread dumps, each 10 seconds apart and
compare them. That will tell you what the Tomcat instance is doing.

> I have found the following log items in catalina.log:
> But there is no other program listening on TC port 8181...
> 
> 2010.07.23. 12:35:26 org.apache.coyote.http11.Http11Protocol init
> SEVERE: Error initializing endpoint
> java.net.BindException: Address already in use:8181

That suggests a Tomcat process that has not been fully shutdown is still
running.

> Is it possible, that I have to increase the "maxThreads" or "acceptCount" 
> tomcat parameters, which control the concurrent access to the tomcat server?

Anything is possible, but neither of those is likely.

> Or can an update to 6.0.20-26-28 solve this problem?

Unlikely. Although you should upgrade to 6.0.29 for the recent security fix.

> Software versions:
> OS: Suse Linux Enterprise 10
> Tomcat: 6.0.18
> JAVA JRE: 1.6.0_10-b33

And I'd upgrade the JVm too.

> I would be grateful for any idea.

Looks like an application issue to me. Take the thread dumps and check
the logs.

Mark



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

Re: FileDirContext returns the path directly without checking whether the target file really exists

On 26/07/2010 03:20, Ivan wrote:
> Hi,
> Seems that the doGetRealPath method in the FileDirContext returns the
> path directly without checking the target file or folder exists, so is it
> expected or file checking is required ?

I don't see anything in the Servlet specification that says that the
real path has to exist. Do you?

Mark

> --->
> @Override
> protected String doGetRealPath(String path) {
> File file = new File(getDocBase(), path);
> return file.getAbsolutePath();
> }
><---




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

Re: mod_jk and tomcat virtual hosts not connecting

2010-07-27 Thread Moritz Winter


 Hi Felix,

youre absolutely right and it works like a charm, thank you so much!! 
Vielen Dank ;-)


Btw. the www prefix is just working fine if I add the alias to the 
tomcat server.xml!


Greetings!

Am 27.07.2010 17:55, schrieb Felix Schumacher:

Hi Moritz,

Am Dienstag, den 27.07.2010, 15:40 +0200 schrieb Moritz Winter:


My issue is with the mod_jk plugin. I want to redirect my subdomain
requests jira.example.com to a tomcat 6 virtual host called jiraapp. If
I call the subdomain jira.example.com Im always getting the default
tomcat 6 host called localhost.

I think your problem is, that mod_jk doesn't change the hostname of the
original request. So name your virtual host in tomcat jira.example.com
instead of jiraapp.


I tested every part:
1.) mod_jk: if i change the workers name in either workers.properties or
und er my enabled-site  or if i change the mapping to my
virtual host (/etc/hosts: 127.0.0.1 localhost jiraapp) apache doesnt
start. So I think this should work and is configured right.
2.) if I do a lynx jiraapp:8080 on the machine it works and shows the
right webapp.

But if I access jira.example.com I always getting the default
root-webapp of tomcat 6. So theres no difference in calling
jira.example.com or example.com:8080. In general my setup looks like this:
1.) browse to jira.example.com
2.) apache  hands over to mod_jk
3.) mod_jk redirects to worker.jiraworker.host:worker.jiraworker.port
(jiraa pp:8009) via ajp
4.) jiraapp resolves to 127.0.0.1 trough /etc/hosts
5.) tomcat relays to the jiraapp name based virtual host

Do I miss something here? My guess would be that iam doing something
wrong in step 4 because i can call lynx jiraapp on the local bash (5)
and i can access the default virtual host from remote (1-3).

Help would be appreciated.

Versions:
Apache Tomcat/6.0.29
Sun-Java 1.6.0_20-b02
Apache/2.2.9 (Debian) mod_jk/1.2.26 proxy_html/3.0.0 Server
libapache2-mod-jk 1:1.2.26-2+lenny1

== jk.load ==

LoadModule jk_module /usr/lib/apache2/modules/mod_jk.so
JkWorkersFile /etc/apache2/workers.properties
JkLogFile /var/log/apache2/mod_jk.log
JkLogLevel info
# JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories
-ForwardLocalAddress
JkRequestLogFormat "%w %V %T"


== workers.properties ==

workers.tomcat_home=/opt/tomcat
workers.java_home=/usr/lib/jvm/java-6-sun

I don't think that you need tomcat_home or java_home in your setup.


worker.list=jiraworker
worker.jiraworker.port=8009
worker.jiraworker.host=jiraapp
worker.jiraworker.type=ajp13


== /etc/hosts ==

::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
127.0.0.1 localhost.localdomain localhost jiraapp


== server.xml ===


[...]

[...]



== apache example.com virtual hosts configuration file ==

ServerName www.jira.example.com
ServerAlias jira.example.com

I don't know what happens if you access your server through
www.jira.example.com. I think you will find, that your default tomcat
virtual host will be called instead of jira.example.com.

You will probably want to redirect users to jira.example.com in that
case.

Bye Felix


JkMount /* jiraworker


-
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: mod_jk and tomcat virtual hosts not connecting

2010-07-27 Thread Felix Schumacher

Hi Moritz,

Am Dienstag, den 27.07.2010, 15:40 +0200 schrieb Moritz Winter:

> My issue is with the mod_jk plugin. I want to redirect my subdomain 
> requests jira.example.com to a tomcat 6 virtual host called jiraapp. If 
> I call the subdomain jira.example.com Im always getting the default 
> tomcat 6 host called localhost.
I think your problem is, that mod_jk doesn't change the hostname of the
original request. So name your virtual host in tomcat jira.example.com
instead of jiraapp.

> 
> I tested every part:
> 1.) mod_jk: if i change the workers name in either workers.properties or 
> und er my enabled-site  or if i change the mapping to my 
> virtual host (/etc/hosts: 127.0.0.1 localhost jiraapp) apache doesnt 
> start. So I think this should work and is configured right.
> 2.) if I do a lynx jiraapp:8080 on the machine it works and shows the 
> right webapp.
> 
> But if I access jira.example.com I always getting the default 
> root-webapp of tomcat 6. So theres no difference in calling 
> jira.example.com or example.com:8080. In general my setup looks like this:
> 1.) browse to jira.example.com
> 2.) apache  hands over to mod_jk
> 3.) mod_jk redirects to worker.jiraworker.host:worker.jiraworker.port 
> (jiraa pp:8009) via ajp
> 4.) jiraapp resolves to 127.0.0.1 trough /etc/hosts
> 5.) tomcat relays to the jiraapp name based virtual host
> 
> Do I miss something here? My guess would be that iam doing something 
> wrong in step 4 because i can call lynx jiraapp on the local bash (5) 
> and i can access the default virtual host from remote (1-3).
> 
> Help would be appreciated.
> 
> Versions:
> Apache Tomcat/6.0.29
> Sun-Java 1.6.0_20-b02
> Apache/2.2.9 (Debian) mod_jk/1.2.26 proxy_html/3.0.0 Server
> libapache2-mod-jk 1:1.2.26-2+lenny1
> 
> == jk.load ==
> 
> LoadModule jk_module /usr/lib/apache2/modules/mod_jk.so
> JkWorkersFile /etc/apache2/workers.properties
> JkLogFile /var/log/apache2/mod_jk.log
> JkLogLevel info
> # JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories 
> -ForwardLocalAddress
> JkRequestLogFormat "%w %V %T"
> 
> 
> == workers.properties ==
> 
> workers.tomcat_home=/opt/tomcat
> workers.java_home=/usr/lib/jvm/java-6-sun
I don't think that you need tomcat_home or java_home in your setup.

> worker.list=jiraworker
> worker.jiraworker.port=8009
> worker.jiraworker.host=jiraapp
> worker.jiraworker.type=ajp13
> 
> 
> == /etc/hosts ==
> 
> ::1 localhost ip6-localhost ip6-loopback
> fe00::0 ip6-localnet
> ff00::0 ip6-mcastprefix
> ff02::1 ip6-allnodes
> ff02::2 ip6-allrouters
> ff02::3 ip6-allhosts
> 127.0.0.1 localhost.localdomain localhost jiraapp
> 
> 
> == server.xml ===
> 
> 
> [...]
>  unpackWARs="true" autoDeploy="true"
> xmlValidation="false" xmlNamespaceAware="false">
> [...]
> 
>  unpackWARs="true" autoDeploy="true"
> xmlValidation="false" xmlNamespaceAware="false" >
> 
> == apache example.com virtual hosts configuration file ==
> 
> ServerName www.jira.example.com
> ServerAlias jira.example.com
I don't know what happens if you access your server through
www.jira.example.com. I think you will find, that your default tomcat
virtual host will be called instead of jira.example.com.

You will probably want to redirect users to jira.example.com in that
case.

Bye Felix

> JkMount /* jiraworker
> 
> 
> -
> 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 Shutting Down by Itself?

Robinson, Eric wrote:
What kind of machine are you running these 163/164
instances of Tomcat on, and when you are running them,
what /does/ "free" say ?

I have two different servers with 164 instances of tomcat. Both servers
have 2x quad-core 2.8Ghz Xeon processors with 32GB RAM. On the first
server (app03), most instances of tomcat are configured with 64MB of
Java heap. About 20% of them have 96-256MB. I almost never reboot this
server (current uptime 61 days). Here's 'free' from app03.

[r...@app03 ~]# free
total used free sharedbuffers
cached
Mem: 33265832 305702602695572 0 296976
4562784
-/+ buffers/cache: 257105007555332
Swap: 2031608 02031608

On the other server (app04), all instances of tomcat are configured with
512MB Java heap (-ms512M -mx512M). After 4 or 5 days of uptime, the
server starts to swap a little. Then I reboot it and it is fine for
several more days. As you can see from the following, it is about time
for a reboot. If I do not reboot it tonight, by tomorrow or the next day
it may be up to 1-2GB of swap. (It actually doesn't slow the server down
much though. sar shows that it runs about 90% idle anyway, including
iowait.

[r...@app03 ~]# ssh app04 free
total used free sharedbuffers
cached
Mem: 33265832 32965812 300020 0 191248
3842092
-/+ buffers/cache: 28932472460
Swap: 2031608 42882027320

That is very interesting information, thank you.
Intuitively, I would have never thought that it was /possible/ to run 160 or so instances
of Tomcat on anything but some type of very expensive hardware.

Granted, dual-Xeon CPU mainboards with 32 GB are not the low-end, but still.
One tends to forget how many megabytes fit in one gigabyte, and 160 X 64 MB is actually
"only" 10 GB.

The data above, and your comments, seem to make unlikely the OOM hypothesis, unless you
have one application suddenly acting up.
On which of those servers is the one Tomcat instance dying ? on both ? Is that Tomcat
instance running an application which the other ones don't ?
What kind of memory usage do the Tomcat instances have (in total, including the Heap) ? Do
you start them with any kind of other memory-related parameter for the JVM apart from -Xms
and -Xmx ?

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

mod_jk and tomcat virtual hosts not connecting

2010-07-27 Thread Moritz Winter

 Hi, First of all I would like to mention that this is my first post on 
this list, I hope that this question is sent in the right place.
I have tried finding a solution for my problem, but it either doesn't 
exist, or my limited brain can't manage to figure out how to do it (I 
strongly hope it is the latter).


My issue is with the mod_jk plugin. I want to redirect my subdomain 
requests jira.example.com to a tomcat 6 virtual host called jiraapp. If 
I call the subdomain jira.example.com Im always getting the default 
tomcat 6 host called localhost.


I tested every part:
1.) mod_jk: if i change the workers name in either workers.properties or 
und er my enabled-site  or if i change the mapping to my 
virtual host (/etc/hosts: 127.0.0.1 localhost jiraapp) apache doesnt 
start. So I think this should work and is configured right.
2.) if I do a lynx jiraapp:8080 on the machine it works and shows the 
right webapp.


But if I access jira.example.com I always getting the default 
root-webapp of tomcat 6. So theres no difference in calling 
jira.example.com or example.com:8080. In general my setup looks like this:

1.) browse to jira.example.com
2.) apache  hands over to mod_jk
3.) mod_jk redirects to worker.jiraworker.host:worker.jiraworker.port 
(jiraa pp:8009) via ajp

4.) jiraapp resolves to 127.0.0.1 trough /etc/hosts
5.) tomcat relays to the jiraapp name based virtual host

Do I miss something here? My guess would be that iam doing something 
wrong in step 4 because i can call lynx jiraapp on the local bash (5) 
and i can access the default virtual host from remote (1-3).


Help would be appreciated.

Versions:
Apache Tomcat/6.0.29
Sun-Java 1.6.0_20-b02
Apache/2.2.9 (Debian) mod_jk/1.2.26 proxy_html/3.0.0 Server
libapache2-mod-jk 1:1.2.26-2+lenny1

== jk.load ==

LoadModule jk_module /usr/lib/apache2/modules/mod_jk.so
JkWorkersFile /etc/apache2/workers.properties
JkLogFile /var/log/apache2/mod_jk.log
JkLogLevel info
# JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories 
-ForwardLocalAddress

JkRequestLogFormat "%w %V %T"


== workers.properties ==

workers.tomcat_home=/opt/tomcat
workers.java_home=/usr/lib/jvm/java-6-sun
worker.list=jiraworker
worker.jiraworker.port=8009
worker.jiraworker.host=jiraapp
worker.jiraworker.type=ajp13


== /etc/hosts ==

::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
127.0.0.1 localhost.localdomain localhost jiraapp


== server.xml ===


[...]

[...]



== apache example.com virtual hosts configuration file ==

ServerName www.jira.example.com
ServerAlias jira.example.com
JkMount /* jiraworker


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

Re: Struts App dispatcher error on Tomcat 5.5.23

2010-07-27 Thread Venkat Tanga


Thanks for your suggestion Kolinko.

But it didn't help to solve my problem, on top of that, it was causing 
another issue in page re-directing when ever I click on home page 
link(my application is cache controlled).


Best Regards,
Venkat.

Konstantin Kolinko wrote:

2010/7/27 Venkat Tanga :
  

I guess it is because of the servlet version changes from 2.3 to 2.4., from
Tomcat 5.0.18 to 5.5.23, isn't it ?



No. Tomcat 5.0 and 5.5 both implement the same version of
specifications (Servlet 2.4 / JSP 2.0).

  

Any suggestions on this is highly appreciable.




1. Try with 5.5.30.
2. Try running with
org.apache.catalina.STRICT_SERVLET_COMPLIANCE=true
(can be added to conf/catalina.properties)
http://tomcat.apache.org/tomcat-5.5-doc/config/systemprops.html

Best regards,
Konstantin Kolinko

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

RE: Setting property 'minSpareThreads' to '300' did not find a matching property