date:20130206


On 2/6/2013 12:28 PM, Mark Eggers wrote:

On 2/6/2013 12:06 PM, Konstantin Kolinko wrote:

2013/2/6 Karolis Monkus :

Ok guys, i did what you all said: Removed that crappy 3rd party
tomcat and downloaded tomcat tarball and port changing works fine.
Now i need to run tomcat as service and since it's a Fedora it uses
systemd instead init. So i created file called tomcat.service and
placed it in /etc/systemd/system/ directory.

tomcat.service:

[Service]

ExecStart=/usr/share/apache-tomcat-7.0.35/bin/startup.sh

Restart=restart-always

[Install]

WantedBy=multi-user.target

Then i enable service using command "systemctl enable
tomcat.service" But nothing happens when i start tomcat with
"service tomcat start" Am i missing some more information in that
tomcat.service file?



1. I would guess that the above command would try to start Tomcat by
the root user.  DO NOT do that.

Do not forget to delete files in Tomcat's log and work folders that
are now owned by root. Otherwise starting it with other user will
fail.

2. Have you read RUNNING.txt ?

3. Do not top-post.
http://en.wikipedia.org/wiki/Posting_style#Choosing_the_proper_posting_style




But nothing happens when i start tomcat with "service tomcat
start"


What exactly do you mean by "nothing" ?


A quick glance through yum on Fedora 18 with the following:

yum search tomcat | grep systemd

doesn't reveal anything.

However, there is

tomcat-systemv.noarch : Systemv scripts for Apache Tomcat

I suspect that getting Tomcat to start up using systemd is more complex
than just the simple file you've put together.

There is also:

tomcat-jsvc.noarch : Apache jsvc wrapper for Apache Tomcat as separate
  service
apache-commons-daemon-jsvc.x86_64 : Java daemon launcher

I think using jsvc is a much better route to take if you're running
Tomcat on port 80.

. . . . just my two cents.
/mde/


Following up on my own post:

I'd download the tomcat-jsvc.noarch and unpack it to see what they did.

Then I'd get the Apache Commons Daemon from the source and compile it:

http://commons.apache.org/daemon/

Finally, I'd use the information from the RPM as a guide, along with:

http://tomcat.apache.org/tomcat-6.0-doc/setup.html

And comments in this article:

http://stackoverflow.com/questions/12887028/running-tomcat6-with-jsvc

to get you going.

/mde/




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

Re: can't start tomcat on port 80


On 2/6/2013 12:06 PM, Konstantin Kolinko wrote:

2013/2/6 Karolis Monkus :

Ok guys, i did what you all said: Removed that crappy 3rd party
tomcat and downloaded tomcat tarball and port changing works fine.
Now i need to run tomcat as service and since it's a Fedora it uses
systemd instead init. So i created file called tomcat.service and
placed it in /etc/systemd/system/ directory.

tomcat.service:

[Service]

ExecStart=/usr/share/apache-tomcat-7.0.35/bin/startup.sh

Restart=restart-always

[Install]

WantedBy=multi-user.target

Then i enable service using command "systemctl enable
tomcat.service" But nothing happens when i start tomcat with
"service tomcat start" Am i missing some more information in that
tomcat.service file?



1. I would guess that the above command would try to start Tomcat by
the root user.  DO NOT do that.

Do not forget to delete files in Tomcat's log and work folders that
are now owned by root. Otherwise starting it with other user will
fail.

2. Have you read RUNNING.txt ?

3. Do not top-post.
http://en.wikipedia.org/wiki/Posting_style#Choosing_the_proper_posting_style



But nothing happens when i start tomcat with "service tomcat
start"


What exactly do you mean by "nothing" ?


A quick glance through yum on Fedora 18 with the following:

yum search tomcat | grep systemd

doesn't reveal anything.

However, there is

tomcat-systemv.noarch : Systemv scripts for Apache Tomcat

I suspect that getting Tomcat to start up using systemd is more complex 
than just the simple file you've put together.


There is also:

tomcat-jsvc.noarch : Apache jsvc wrapper for Apache Tomcat as separate
 service
apache-commons-daemon-jsvc.x86_64 : Java daemon launcher

I think using jsvc is a much better route to take if you're running 
Tomcat on port 80.


. . . . just my two cents.
/mde/

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

Re: Issue with Connections

TVFoodMaps wrote:

Thanks for the information. I'm still a bit perplexed how to
increase/change the settings so these issues dont cause the "hang" I saw
this morning. My guess was that I hit some type of limit on sockets/file
descriptors. I'm not sure if the fix is in my application, network
settings or the OS file descriptor limits.

On a related note, I also notice lots of TIME_WAIT connections to port
8080. What controls how long the connection is in TIME_WAIT?

Here is a very good article about it, with pictures and all.
http://www.serverframework.com/asynchronousevents/2011/01/time-wait-and-its-design-implications-for-protocols-and-scalable-servers.html

On Wed, Feb 6, 2013 at 12:32 PM, André Warnier wrote:

André Warnier wrote:

TVFoodMaps wrote:

Hi,

My website is setup using apache 2, mod jk 1.37 and tomcat 6. Most of
the
connector settings are set to defaults and things normally run pretty
well.
However during certain spikes in traffic my server seems to hang by what
appears to be caused by "leaking connections". What I see is about 250
rows like this from a netstat:

tcp1 0 :::127.0.0.1:8009 :::127.0.0.1:48387
CLOSE_WAIT
tcp1 0 :::127.0.0.1:8009 :::127.0.0.1:48309
CLOSE_WAIT
tcp 689 0 :::127.0.0.1:8009 :::127.0.0.1:48423
CLOSE_WAIT
tcp 686 0 :::127.0.0.1:8009 :::127.0.0.1:48413
CLOSE_WAIT

I also am see a lot of these:

tcp1 0 :::127.0.0.1:49261 :::127.0.0.1:8080
CLOSE_WAIT
tcp1 0 :::127.0.0.1:52836 :::127.0.0.1:8080
CLOSE_WAIT
tcp0 0 :::127.0.0.1:58262 :::127.0.0.1:8080
TIME_WAIT

(Note the application makes direct calls to port 8080 for a specific API
I'm using (SOLR)).

I'm really not sure which is actually causing the problem, but I was
hoping
for some guidane on which settings I should look into tweaking.

Hi.

1) here is one (among many) explanation of the CLOSE_WAIT state.
http://blogs.technet.com/b/**janelewis/archive/2010/03/09/**
explaining-close-wait.aspx
(and many more if you search google for "tcp close_wait")
Basically, it is a normal state through which any TCP connection passes
at some point.
It is only pathological when you many of them persisting for a long time.

2) assuming yours are pathological and persist a long time :
2.a) the ones like this :
> tcp1 0 :::127.0.0.1:8009 :::127.0.0.1:48387
> CLOSE_WAIT

involve port 8009, which is the AJP port of Tomcat, in this case the
"server" side. The other side is mod_jk within Apache httpd, in this case
the client side (because it is mod_jk which first establishes the
connection to Tomcat, so mod_jk is the client here).
If one of these persists for a long time, it means that the client
(mod_jk) does not entirely close its connection to Tomcat.
Why that could be, another person here would have to explain.

2.b) the other ones like
> tcp1 0 :::127.0.0.1:49261 :::127.0.0.1:8080
> CLOSE_WAIT

relate to your application (as a client), which does not entirely close()
its connections to port 8080.
In my own experience - and assuming that you application is a java
application - this can happen for example as follows :
- the explicit connection to port 8080 is made from within some object,
as part of the creation of that object
- then when the application doesn't need the "connection object" anymore,
it discards it.
- the object is left on the heap, waiting to be garbage-collected
- when it is (eventually) garbage-collected, it will really de destroyed,
and any lingering "socket" within it will be closed (and the line above
will disappear from your netstat output)
but..
while it sits on the heap waiting to be garbage-collected (which could be
for a long time if your system has a lot of spare heap memory), that inner
socket is still there, not totally closed (the server closed its side, but
the client didn't).

Eventually, you may have so many sockets in the CLOSE_WAIT state, that
your system's TCP stack becomes unresponsive. (That's what I have seen
happening under Linux).

I do not really know the real underlying reason for this behaviour, but
my guess is that below the level of Java and the JVM, a Java socket at some
level relies on a OS-level socket object. And as long as that OS-level
socket object is not explicitly told to close() the connection, it doesn't.
So make sure that before you discard your high-level objects containing a
connection, you explicitly close that connection.

Addendum : this may be interesting too :

http://www.michaelprivat.com/?**p=63

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

Re: can't start tomcat on port 80

2013-02-06 Thread Konstantin Kolinko

2013/2/6 Karolis Monkus :
> Ok guys, i did what you all said:
> Removed that crappy 3rd party tomcat and downloaded tomcat tarball and port
> changing works fine. Now i need to run tomcat as service and since it's a
> Fedora it uses systemd instead init. So i created file called tomcat.service
> and placed it in /etc/systemd/system/ directory.
>
> tomcat.service:
>
> [Service]
>
> ExecStart=/usr/share/apache-tomcat-7.0.35/bin/startup.sh
>
> Restart=restart-always
>
> [Install]
>
> WantedBy=multi-user.target
>
> Then i enable service using command "systemctl enable tomcat.service"
> But nothing happens when i start tomcat with "service tomcat start"
> Am i missing some more information in that tomcat.service file?
>

1. I would guess that the above command would try to start Tomcat by
the root user.  DO NOT do that.

Do not forget to delete files in Tomcat's log and work folders that
are now owned by root. Otherwise starting it with other user will
fail.

2. Have you read RUNNING.txt ?

3. Do not top-post.
http://en.wikipedia.org/wiki/Posting_style#Choosing_the_proper_posting_style

> But nothing happens when i start tomcat with "service tomcat start"

What exactly do you mean by "nothing" ?

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

Re: [Seriously OT] Help in diagnosing server unresponsiveness

Jeffrey Janner wrote:

-Original Message-
From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com]
Sent: Wednesday, February 06, 2013 12:06 PM
To: 'Tomcat Users List'
Subject: RE: [Seriously OT] Help in diagnosing server unresponsiveness

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Wednesday, February 06, 2013 11:02 AM
To: Tomcat Users List
Subject: Re: [Seriously OT] Help in diagnosing server

unresponsiveness

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jeffrey,

On 2/6/13 10:26 AM, Jeffrey Janner wrote:

-Original Message- From: Christopher Schultz
[mailto:ch...@christopherschultz.net] Sent: Tuesday, February 05,
2013 4:59 PM To: Tomcat Users List Subject: Re: [Seriously OT]

Help

in diagnosing server unresponsiveness

-BEGIN PGP SIGNED MESSAGE-

IMO, developer performance trumps runtime performance most of the
time. So, if you can create a more maintainable system in less

time

by using EJB (or whatever), then you go ahead and do it:
servers are cheap, while developer time is expensive.

- -chris

Chris, I'd like to differ with you on this last point. As someone
who's been a developer, support person, and admin, I've got a

pretty

good perspective on this subject. While servers may be cheap, they
will never be cheap enough to overcome poor programming practices.
I've worked with systems so poorly designed that we couldn't
purchase a system big enough to run the software adequately, once
you got

above

a handful of users. Yes, it's gotten to the point where systems are
much cheaper than they used to be, while developer salaries are

only

increasing (supposedly), so wasting time on some minor performance
improvement may not be cost-effective. However, when you aggregate

the

time that hundreds of users spend waiting on a response from a
poorly designed, unresponsive system, I think you'll find that it
trumps the cost of having the developer spending a few extra

minutes

to "get it right the first time".

How about "servers are a lot cheaper than competent software
developers"? ;)

- -chris

+1
Can't tell how tired I am of hearing some version of the following:
 "I don't care to learn how a library/API is supposed to work, I just
want to use it."

(replying to own post == bad form)
Actually, that line usually begins: "I don't have time to"

As maybe one more rant to add to this series, and as a reply to the "just throw more 
hardware at it, it's cheap" line.
For a small service company offering ASP kind of services to customers, buying hardware to 
run apps is for us a relatively frequent occurrence.
And while it is true that basic hardware is relatively cheap nowadays, one quickly notices 
that "a bit more hardware" can involve a significant step up the cost ladder. For example, 
let's say that a good-quality basic rack-mounted server costs 2000€, and has 4 slots for 
RAM. And let's say that 1 RAM unit nowadays can hold 8 GB and costs 50€. So in total you 
can fit 4x8=32 GB of RAM in that basic server, at a cost of 2200€ for the total. If you 
need 33 GB (thus say only 1x8 GB more, at a theoretical additional cost of 50€), you have 
to switch to the next server category, which may have 8 slots for RAM, but costs 3000€. So 
the additional 1 GB of Tomcat heap (just as an example) ends up costing 850€, not 50€. 
Additionally, this bigger server could be 2U in height instead of 1U, and cost 75% more 
per month to host in a rack. And so it goes for other server resources (disk, network 
bandwidth, etc.).  I am not even counting the time that will be needed to move the 
applications from server 1 to server 2.
(And "the cloud" turns out not to be much cheaper, once you seriously factor in the 
various cost elements).

So there is still something to say about *how* one is writing applications.
Of course in many cases such low-level materialistic considerations do not affect the 
programmer directly and immediately in his pay packet.  But ultimately, someone pays for 
it, and at the end of the day it does reflect on the bottom-line and on the menu at the 
cantina.
That is also why I sometimes look in wonder as someone on this forum will tell someone 
else something like "4 GB of heap is really not very much to run your webapp; you should 
at least double that for any serious work".  What about instead "Dude, 4 GB is four 
thousand million bytes (plus spares). Would you not have a quick look at your webapp, to 
see if it really needs that much workspace to send back a single html page ?".

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

Re: Issue with Connections

2013-02-06 Thread TVFoodMaps

Thanks for the information.  I'm still a bit perplexed how to
increase/change the settings so these issues dont cause the "hang" I saw
this morning.  My guess was that I hit some type of limit on sockets/file
descriptors.  I'm not sure if the fix is in my application, network
settings or the OS file descriptor limits.

On a related note, I also notice lots of TIME_WAIT connections to port
8080.  What controls how long the connection is in TIME_WAIT?


On Wed, Feb 6, 2013 at 12:32 PM, André Warnier  wrote:

> André Warnier wrote:
>
>> TVFoodMaps wrote:
>>
>>> Hi,
>>>
>>> My website is setup using apache 2, mod jk 1.37 and tomcat 6.  Most of
>>> the
>>> connector settings are set to defaults and things normally run pretty
>>> well.
>>>  However during certain spikes in traffic my server seems to hang by what
>>> appears to be caused by "leaking connections".  What I see is about 250
>>> rows like this from a netstat:
>>>
>>> tcp1  0 :::127.0.0.1:8009   :::127.0.0.1:48387
>>>  CLOSE_WAIT
>>> tcp1  0 :::127.0.0.1:8009   :::127.0.0.1:48309
>>>  CLOSE_WAIT
>>> tcp  689  0 :::127.0.0.1:8009   :::127.0.0.1:48423
>>>  CLOSE_WAIT
>>> tcp  686  0 :::127.0.0.1:8009   :::127.0.0.1:48413
>>>  CLOSE_WAIT
>>>
>>> I also am see a lot of these:
>>>
>>> tcp1  0 :::127.0.0.1:49261  :::127.0.0.1:8080
>>> CLOSE_WAIT
>>> tcp1  0 :::127.0.0.1:52836  :::127.0.0.1:8080
>>> CLOSE_WAIT
>>> tcp0  0 :::127.0.0.1:58262  :::127.0.0.1:8080
>>> TIME_WAIT
>>>
>>> (Note the application makes direct calls to port 8080 for a specific API
>>> I'm using (SOLR)).
>>>
>>> I'm really not sure which is actually causing the problem, but I was
>>> hoping
>>> for some guidane on which settings I should look into tweaking.
>>>
>>>
>>>  Hi.
>> 1) here is one (among many) explanation of the CLOSE_WAIT state.
>> http://blogs.technet.com/b/**janelewis/archive/2010/03/09/**
>> explaining-close-wait.aspx
>> (and many more if you search google for "tcp close_wait")
>> Basically, it is a normal state through which any TCP connection passes
>> at some point.
>> It is only pathological when you many of them persisting for a long time.
>>
>> 2) assuming yours are pathological and persist a long time :
>> 2.a) the ones like this :
>>  > tcp1  0 :::127.0.0.1:8009   :::127.0.0.1:48387
>>  >  CLOSE_WAIT
>>
>> involve port 8009, which is the AJP port of Tomcat, in this case the
>> "server" side. The other side is mod_jk within Apache httpd, in this case
>> the client side (because it is mod_jk which first establishes the
>> connection to Tomcat, so mod_jk is the client here).
>> If one of these persists for a long time, it means that the client
>> (mod_jk) does not entirely close its connection to Tomcat.
>> Why that could be, another person here would have to explain.
>>
>> 2.b) the other ones like
>>  > tcp1  0 :::127.0.0.1:49261  :::127.0.0.1:8080
>>  > CLOSE_WAIT
>>
>> relate to your application (as a client), which does not entirely close()
>> its connections to port 8080.
>> In my own experience - and assuming that you application is a java
>> application - this can happen for example as follows :
>> - the explicit connection to port 8080 is made from within some object,
>> as part of the creation of that object
>> - then when the application doesn't need the "connection object" anymore,
>> it discards it.
>> - the object is left on the heap, waiting to be garbage-collected
>> - when it is (eventually) garbage-collected, it will really de destroyed,
>> and any lingering "socket" within it will be closed (and the line above
>> will disappear from your netstat output)
>> but..
>> while it sits on the heap waiting to be garbage-collected (which could be
>> for a long time if your system has a lot of spare heap memory), that inner
>> socket is still there, not totally closed (the server closed its side, but
>> the client didn't).
>>
>> Eventually, you may have so many sockets in the CLOSE_WAIT state, that
>> your system's TCP stack becomes unresponsive. (That's what I have seen
>> happening under Linux).
>>
>> I do not really know the real underlying reason for this behaviour, but
>> my guess is that below the level of Java and the JVM, a Java socket at some
>> level relies on a OS-level socket object.  And as long as that OS-level
>> socket object is not explicitly told to close() the connection, it doesn't.
>> So make sure that before you discard your high-level objects containing a
>> connection, you explicitly close that connection.
>>
>>
>>  Addendum : this may be interesting too :
> http://www.michaelprivat.com/?**p=63 
>
>
>
> --**--**-
> To unsubscribe, e-mail: 
> users-unsu

RE: [Seriously OT] Help in diagnosing server unresponsiveness

2013-02-06 Thread Jeffrey Janner

> -Original Message-
> From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com]
> Sent: Wednesday, February 06, 2013 12:06 PM
> To: 'Tomcat Users List'
> Subject: RE: [Seriously OT] Help in diagnosing server unresponsiveness
> 
> > -Original Message-
> > From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> > Sent: Wednesday, February 06, 2013 11:02 AM
> > To: Tomcat Users List
> > Subject: Re: [Seriously OT] Help in diagnosing server
> unresponsiveness
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > Jeffrey,
> >
> > On 2/6/13 10:26 AM, Jeffrey Janner wrote:
> > >> -Original Message- From: Christopher Schultz
> > >> [mailto:ch...@christopherschultz.net] Sent: Tuesday, February 05,
> > >> 2013 4:59 PM To: Tomcat Users List Subject: Re: [Seriously OT]
> Help
> > >> in diagnosing server unresponsiveness
> > >>
> > >> -BEGIN PGP SIGNED MESSAGE-
> > >>
> > >> IMO, developer performance trumps runtime performance most of the
> > >> time. So, if you can create a more maintainable system in less
> time
> > >> by using EJB (or whatever), then you go ahead and do it:
> > >> servers are cheap, while developer time is expensive.
> > >>
> > >> - -chris
> > >
> > > Chris, I'd like to differ with you on this last point. As someone
> > > who's been a developer, support person, and admin, I've got a
> pretty
> > > good perspective on this subject. While servers may be cheap, they
> > > will never be cheap enough to overcome poor programming practices.
> > > I've worked with systems so poorly designed that we couldn't
> > > purchase a system big enough to run the software adequately, once
> > > you got
> > above
> > > a handful of users. Yes, it's gotten to the point where systems are
> > > much cheaper than they used to be, while developer salaries are
> only
> > > increasing (supposedly), so wasting time on some minor performance
> > > improvement may not be cost-effective. However, when you aggregate
> > the
> > > time that hundreds of users spend waiting on a response from a
> > > poorly designed, unresponsive system, I think you'll find that it
> > > trumps the cost of having the developer spending a few extra
> minutes
> > > to "get it right the first time".
> >
> > How about "servers are a lot cheaper than competent software
> > developers"? ;)
> >
> > - -chris
> +1
> Can't tell how tired I am of hearing some version of the following:
>  "I don't care to learn how a library/API is supposed to work, I just
> want to use it."

(replying to own post == bad form)
Actually, that line usually begins: "I don't have time to"

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

RE: [Seriously OT] Help in diagnosing server unresponsiveness

2013-02-06 Thread Jeffrey Janner

> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Wednesday, February 06, 2013 11:02 AM
> To: Tomcat Users List
> Subject: Re: [Seriously OT] Help in diagnosing server unresponsiveness
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Jeffrey,
> 
> On 2/6/13 10:26 AM, Jeffrey Janner wrote:
> >> -Original Message- From: Christopher Schultz
> >> [mailto:ch...@christopherschultz.net] Sent: Tuesday, February 05,
> >> 2013 4:59 PM To: Tomcat Users List Subject: Re: [Seriously OT] Help
> >> in diagnosing server unresponsiveness
> >>
> >> -BEGIN PGP SIGNED MESSAGE-
> >>
> >> IMO, developer performance trumps runtime performance most of the
> >> time. So, if you can create a more maintainable system in less time
> >> by using EJB (or whatever), then you go ahead and do it:
> >> servers are cheap, while developer time is expensive.
> >>
> >> - -chris
> >
> > Chris, I'd like to differ with you on this last point. As someone
> > who's been a developer, support person, and admin, I've got a pretty
> > good perspective on this subject. While servers may be cheap, they
> > will never be cheap enough to overcome poor programming practices.
> > I've worked with systems so poorly designed that we couldn't purchase
> > a system big enough to run the software adequately, once you got
> above
> > a handful of users. Yes, it's gotten to the point where systems are
> > much cheaper than they used to be, while developer salaries are only
> > increasing (supposedly), so wasting time on some minor performance
> > improvement may not be cost-effective. However, when you aggregate
> the
> > time that hundreds of users spend waiting on a response from a poorly
> > designed, unresponsive system, I think you'll find that it trumps the
> > cost of having the developer spending a few extra minutes to "get it
> > right the first time".
> 
> How about "servers are a lot cheaper than competent software
> developers"? ;)
> 
> - -chris
+1
Can't tell how tired I am of hearing some version of the following:
 "I don't care to learn how a library/API is supposed to work, I just want to 
use it."

Re: Issue with Connections

André Warnier wrote:

TVFoodMaps wrote:

Hi,

My website is setup using apache 2, mod jk 1.37 and tomcat 6.  Most of 
the
connector settings are set to defaults and things normally run pretty 
well.

 However during certain spikes in traffic my server seems to hang by what
appears to be caused by "leaking connections".  What I see is about 250
rows like this from a netstat:

tcp1  0 :::127.0.0.1:8009   :::127.0.0.1:48387
 CLOSE_WAIT
tcp1  0 :::127.0.0.1:8009   :::127.0.0.1:48309
 CLOSE_WAIT
tcp  689  0 :::127.0.0.1:8009   :::127.0.0.1:48423
 CLOSE_WAIT
tcp  686  0 :::127.0.0.1:8009   :::127.0.0.1:48413
 CLOSE_WAIT

I also am see a lot of these:

tcp1  0 :::127.0.0.1:49261  :::127.0.0.1:8080
CLOSE_WAIT
tcp1  0 :::127.0.0.1:52836  :::127.0.0.1:8080
CLOSE_WAIT
tcp0  0 :::127.0.0.1:58262  :::127.0.0.1:8080
TIME_WAIT

(Note the application makes direct calls to port 8080 for a specific API
I'm using (SOLR)).

I'm really not sure which is actually causing the problem, but I was 
hoping

for some guidane on which settings I should look into tweaking.

Hi.
1) here is one (among many) explanation of the CLOSE_WAIT state.
http://blogs.technet.com/b/janelewis/archive/2010/03/09/explaining-close-wait.aspx 

(and many more if you search google for "tcp close_wait")
Basically, it is a normal state through which any TCP connection passes 
at some point.

It is only pathological when you many of them persisting for a long time.

2) assuming yours are pathological and persist a long time :
2.a) the ones like this :
 > tcp1  0 :::127.0.0.1:8009   :::127.0.0.1:48387
 >  CLOSE_WAIT

involve port 8009, which is the AJP port of Tomcat, in this case the 
"server" side. The other side is mod_jk within Apache httpd, in this 
case the client side (because it is mod_jk which first establishes the 
connection to Tomcat, so mod_jk is the client here).
If one of these persists for a long time, it means that the client 
(mod_jk) does not entirely close its connection to Tomcat.

Why that could be, another person here would have to explain.

2.b) the other ones like
 > tcp1  0 :::127.0.0.1:49261  :::127.0.0.1:8080
 > CLOSE_WAIT

relate to your application (as a client), which does not entirely 
close() its connections to port 8080.
In my own experience - and assuming that you application is a java 
application - this can happen for example as follows :
- the explicit connection to port 8080 is made from within some object, 
as part of the creation of that object
- then when the application doesn't need the "connection object" 
anymore, it discards it.

- the object is left on the heap, waiting to be garbage-collected
- when it is (eventually) garbage-collected, it will really de 
destroyed, and any lingering "socket" within it will be closed (and the 
line above will disappear from your netstat output)

but..
while it sits on the heap waiting to be garbage-collected (which could 
be for a long time if your system has a lot of spare heap memory), that 
inner socket is still there, not totally closed (the server closed its 
side, but the client didn't).

Eventually, you may have so many sockets in the CLOSE_WAIT state, that 
your system's TCP stack becomes unresponsive. (That's what I have seen 
happening under Linux).

I do not really know the real underlying reason for this behaviour, but 
my guess is that below the level of Java and the JVM, a Java socket at 
some level relies on a OS-level socket object.  And as long as that 
OS-level socket object is not explicitly told to close() the connection, 
it doesn't.
So make sure that before you discard your high-level objects containing 
a connection, you explicitly close that connection.

Addendum : this may be interesting too :
http://www.michaelprivat.com/?p=63

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

Re: Issue with Connections

TVFoodMaps wrote:

Hi,

My website is setup using apache 2, mod jk 1.37 and tomcat 6.  Most of the
connector settings are set to defaults and things normally run pretty well.
 However during certain spikes in traffic my server seems to hang by what
appears to be caused by "leaking connections".  What I see is about 250
rows like this from a netstat:

tcp1  0 :::127.0.0.1:8009   :::127.0.0.1:48387
 CLOSE_WAIT
tcp1  0 :::127.0.0.1:8009   :::127.0.0.1:48309
 CLOSE_WAIT
tcp  689  0 :::127.0.0.1:8009   :::127.0.0.1:48423
 CLOSE_WAIT
tcp  686  0 :::127.0.0.1:8009   :::127.0.0.1:48413
 CLOSE_WAIT

I also am see a lot of these:

tcp1  0 :::127.0.0.1:49261  :::127.0.0.1:8080
CLOSE_WAIT
tcp1  0 :::127.0.0.1:52836  :::127.0.0.1:8080
CLOSE_WAIT
tcp0  0 :::127.0.0.1:58262  :::127.0.0.1:8080
TIME_WAIT

(Note the application makes direct calls to port 8080 for a specific API
I'm using (SOLR)).

I'm really not sure which is actually causing the problem, but I was hoping
for some guidane on which settings I should look into tweaking.

Hi.
1) here is one (among many) explanation of the CLOSE_WAIT state.
http://blogs.technet.com/b/janelewis/archive/2010/03/09/explaining-close-wait.aspx
(and many more if you search google for "tcp close_wait")
Basically, it is a normal state through which any TCP connection passes at some 
point.
It is only pathological when you many of them persisting for a long time.

2) assuming yours are pathological and persist a long time :
2.a) the ones like this :
> tcp1  0 :::127.0.0.1:8009   :::127.0.0.1:48387
>  CLOSE_WAIT

involve port 8009, which is the AJP port of Tomcat, in this case the "server" side. The 
other side is mod_jk within Apache httpd, in this case the client side (because it is 
mod_jk which first establishes the connection to Tomcat, so mod_jk is the client here).
If one of these persists for a long time, it means that the client (mod_jk) does not 
entirely close its connection to Tomcat.

Why that could be, another person here would have to explain.

2.b) the other ones like
> tcp1  0 :::127.0.0.1:49261  :::127.0.0.1:8080
> CLOSE_WAIT

relate to your application (as a client), which does not entirely close() its connections 
to port 8080.
In my own experience - and assuming that you application is a java application - this can 
happen for example as follows :
- the explicit connection to port 8080 is made from within some object, as part of the 
creation of that object

- then when the application doesn't need the "connection object" anymore, it 
discards it.
- the object is left on the heap, waiting to be garbage-collected
- when it is (eventually) garbage-collected, it will really de destroyed, and any 
lingering "socket" within it will be closed (and the line above will disappear from your 
netstat output)

but..
while it sits on the heap waiting to be garbage-collected (which could be for a long time 
if your system has a lot of spare heap memory), that inner socket is still there, not 
totally closed (the server closed its side, but the client didn't).

Eventually, you may have so many sockets in the CLOSE_WAIT state, that your system's TCP 
stack becomes unresponsive. (That's what I have seen happening under Linux).

I do not really know the real underlying reason for this behaviour, but my guess is that 
below the level of Java and the JVM, a Java socket at some level relies on a OS-level 
socket object.  And as long as that OS-level socket object is not explicitly told to 
close() the connection, it doesn't.
So make sure that before you discard your high-level objects containing a connection, you 
explicitly close that connection.

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

Re: Help in diagnosing server unresponsiveness

2013-02-06 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Howard,

If you are interested in clustering, you should try to attend
ApacheCon this month in Portland, OR in the US: Mark Thomas will be
giving a talk on Tomcat clustering that I'm sure will be enlightening.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEAREIAAYFAlESjwcACgkQ9CaO5/Lv0PC+0gCfaXt66fDFLzClnfzLAsZcLzXH
044Anj1e6NSZaUFk5MbhC92SLzVXwkWi
=P9K0
-END PGP SIGNATURE-

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

Re: Help in diagnosing server unresponsiveness

2013-02-06 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Howard,

On 2/5/13 8:29 PM, Howard W. Smith, Jr. wrote:
> Chris, On Sun, Feb 3, 2013 at 12:39 PM, Christopher Schultz 
>  wrote:
> 
>> If your requirements allow for users to have to re-authenticate
>> when you have a failover-event, then I highly recommend that you
>> use sticky-sessions /without/ session replication: performance
>> will be much better that way (and it's easier to configure).
> 
> this is very interesting but somewhat of a concern as well. does 
> failover occur when one tomcat-and-web-app instance is taking a
> long time serving one request? there are a few places/pages in my
> web app that does some heavy lifting (reports that execute SQL
> SELECT, and yes, I am using indexes along with statement caching,
> etc...), and i've seen my app failover with a 404 error (i
> currently only have one instance).

It depends on how you configure things. It's usually the lb that makes
that decision, so you configure it there. I would imagine that a good
lb would be able to do things like "guess" the health of the
backend-server and take it out of rotation if it's not healthy. mod_jk
has a variety of health-checks that you can perform to decide when a
Tomcat needs to be abandoned (perhaps temporarily).

Your app fails-over to a 404? Something must be misconfigured. Or were
you saying that your webapp returns a 404 if a query runs too long or
something... that doesn't sound optimal.

>> Well, if you can tolerate re-auth on failover, then there's
>> nothing to do at all: simply enable sticky-sessions and let it
>> happen. Failovers should be rare, anyway, right?
> 
> sticky sessions sound nice and I would love to give it a try, but 
> honestly, i don't think the endusers want to have to re-auth on 
> failover. just today, I read on the atmosphere list that sticky 
> sessions are required for using atmosphere with/in clusters. i'm 
> definitely using atmosphere, but not using sticky sessions (or 
> clusters) yet.  :(

I think if you use async replication, you must use sticky sessions
anyway, because otherwise you run the risk of having a user hit a
different server before it has been updated from a previous request
(on a different server).

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEAREIAAYFAlESjtAACgkQ9CaO5/Lv0PAQtwCgvzniTJG11eoJeOJcV3Gpnz6Y
+UoAnRph0Qh6c8D5f9Mk0vHis3E1iMSy
=GDk7
-END PGP SIGNATURE-

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

RE: Tomcat Upgrade & Migration Questions

2013-02-06 Thread Williams, Nick

> On Feb 6, 2013, at 1:24 AM, Kirk Hoganson wrote:
>> I am currently in the middle of an upgrade from Apache (2.2)/Tomcat
>> (5.5.16) to Apache (2.2)/Tomcat (6.0.24).  The JVM is being upgraded
>> from
>> 1.5.0_09-b01 to 1.6.0_22-b22.  The new host servers will be RedHat 6.2.
>
>Why are you upgrading to 6.0.24 & Java 1.6.0_22?  These are already multiple 
>versions out of date.  Do yourself a favor and upgrade to the latest release 
>of each, which at this time is 6.0.36 and Java 1.6.0_39.

Just want to chime in here. Please note that Java 6 is 8 years old, as of 
February 2011 Oracle ended public update notifications, and (most importantly) 
as of February 2013 (this month) Java 6 will be END OF LIFE 
(http://www.oracle.com/technetwork/java/eol-135779.html). This means that if 
some security issue is identified in Java 6 that could compromise your servers, 
the only way you will be able to get a fix for it is to upgrade to Java 7. 
(Java 7 is approaching its second birthday and Java 8 comes out later this 
year. The plan is for Java 7 to go end of life in July 2014, but July 2012 was 
the plan for Java 6 and that got extended 7 months. I think Java 7 has a little 
time left in it yet.)

Dan is right to encourage you to go to Java 1.6.0_39 instead of 1.6.0_22 and to 
go to Tomcat 6.0.36 instead of 6.0.24. The versions you are proposing to update 
to are out of date, potentially insecure, and should not be used on production 
systems. However, I would take it a step further. If you are already in the 
process of upgrading your systems, get a little more current and save yourself 
some headache down the road. Get Java 1.7.0_13 and Tomcat 7.0.35. That should 
last you for a couple more years before you'll need to update.

Just my $0.02.

Nick

This e-mail may contain privileged or confidential information. If you are not 
the intended recipient: (1) you may not disclose, use, distribute, copy or rely 
upon this message or attachment(s); and (2) please notify the sender by reply 
e-mail, and then delete this message and its attachment(s). Underwriters 
Laboratories Inc. and its affiliates disclaim all liability for any errors, 
omissions, corruption or virus in this message or any attachments.

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

Re: [Seriously OT] Help in diagnosing server unresponsiveness

2013-02-06 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jeffrey,

On 2/6/13 10:26 AM, Jeffrey Janner wrote:
>> -Original Message- From: Christopher Schultz
>> [mailto:ch...@christopherschultz.net] Sent: Tuesday, February 05,
>> 2013 4:59 PM To: Tomcat Users List Subject: Re: [Seriously OT]
>> Help in diagnosing server unresponsiveness
>> 
>> -BEGIN PGP SIGNED MESSAGE-
>> 
>> IMO, developer performance trumps runtime performance most of the
>> time. So, if you can create a more maintainable system in less
>> time by using EJB (or whatever), then you go ahead and do it:
>> servers are cheap, while developer time is expensive.
>> 
>> - -chris
> 
> Chris, I'd like to differ with you on this last point. As someone 
> who's been a developer, support person, and admin, I've got a
> pretty good perspective on this subject. While servers may be
> cheap, they will never be cheap enough to overcome poor programming
> practices. I've worked with systems so poorly designed that we
> couldn't purchase a system big enough to run the software
> adequately, once you got above a handful of users. Yes, it's gotten
> to the point where systems are much cheaper than they used to be,
> while developer salaries are only increasing (supposedly), so
> wasting time on some minor performance improvement may not be
> cost-effective. However, when you aggregate the time that hundreds
> of users spend waiting on a response from a poorly designed,
> unresponsive system, I think you'll find that it trumps the cost of
> having the developer spending a few extra minutes to "get it right
> the first time".

How about "servers are a lot cheaper than competent software
developers"? ;)

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEAREIAAYFAlESjGwACgkQ9CaO5/Lv0PDqUACgrpSMfS+87G/aofbuyZT/4C9n
N9QAmwdTFk7t+JRQEu/75VCVB4SjBgV/
=s59y
-END PGP SIGNATURE-

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

Re: Tomcat


Mark Eggers wrote:

On 2/6/2013 3:20 AM, mohit.g...@rbs.com wrote:


Hi Thanks for all the help and I know it may sound lame but I am
trying to learn these things. Although I have one more doubt. If we
have multiple tomcat for multiple environment on the single Unix
box(machine) Now Single Apache daemon is running for multiple
environment. So can we run multiple instance of Apache daemon in the
same machine or not for each different environment. If this is
possible how can we accomplish this.

Thanks in advance for the help and sorry for bugging the group with
such silly questions.

MOHIT GARG Analyst International Banking RBS Block No 1, Tower A,
Unitech Infospace Complex Sector 21, Gurgaon, Haryana, 122002, India
Office: +91 8860190177

-Original Message- From: André Warnier
[mailto:a...@ice-sa.com] Sent: 06 February 2013 16:21 To: Tomcat Users
List Subject: Re: Tomcat

mohit.g...@rbs.com wrote:

Hi

Regrets for the wrong framing of question. Actually I am new to
tomcat and what I really want to do is run on the same server two
different tomcats so that one doesn't interfere with the working of
the other. As I have different environments so I want that the
tomcat running in my development environment do not access the
files of my SIT environment and vice-versa. That's why I want to
have a separate tomcat process for each host. If I just change the
port in the config file the request will be mapped but the various
environments will have access to all the files as it will be
present in the common directory.



Ah, that's better. So we forget about Apache httpd, right ? So,
assuming that you are talking about tomcat only :

There are (many) different levels of separation, depending on what
you really want to separate.

First, a note : considering that you are on a Linux machine, it is
highly possible that you have installed Tomcat using a pre-packaged
version from your Linux distribution. These packages work fine and
are easy to install for a normal single-instance case, but they make
it more difficult for doing the kind of thing that you want to do,
and more difficult for people on this list to help you.  That is
because each of these packages distributes the files of Tomcat in
different places on the disk, sets different environment variables,
sets differents links from one directory to the other in the
filesystem, etc.. So it would be better to install a "standard"
tomcat downloaded from the website "tomcat.apache.org", to some
directory like /opt/tomcat, and follow the instructions that are
given in the "RUNNING.txt" file at the top of this distribution. This
way, everyone here knows what you are talking about and has a good
idea of where things are. (You can also leave your current Tomcat
where it is, and consider it as your "production" tomcat, and
download and install another copy to another directory as your
"development" tomcat. Then we can maybe help you set up this
development tomcat in a way that does not conflict with the other
one).

Then, the next question is : you want to run 2 "separate" tomcats, so
as not to mix the production and the development environments. That's
established. But do you want also to be able to run 2 different
/versions/ of Tomcat ?

If yes, you will have to download and install tomcat twice, to 2
separate directories in /opt (such as /opt/tomcat-prod and
/opt/tomcat-dev for instance). If not, then one single copy of tomcat
will be enough, and you can configure things to still run 2 different
"instances" of tomcat, from one single copy of the code.


Then, some advance information : There are 2 environment variables
which point to disk directories and which are very important for what
you want to do :

CATALINA_HOME : this tells Tomcat where its runnable *code* is
located.  under CATALINA_HOME, Tomcat expects to find for example
it's "bin" subdirectory, where the main executable parts of Tomcat
are located.

CATALINA_BASE : this tells Tomcat where its instance-specific
"things" are located. For example, Tomcat will look into
$CATALINA_BASE/conf to find its main configuration files.

By default, these 2 values are the same, and Tomcat will use the same
/bin, /conf etc..

But you can set up 2 tomcat instances to use the same $CATALINA_HOME
directory (so they will run the same Tomcat code from
$CATALINA_HOME/bin), but have different $CATALINA_BASE directories
(so they will use a different configuration from $CATALINA_BASE/conf,
different webapps from $CATALINA_BASE/webapps etc).

That's the basics for separating two tomcat instances.

Note that there is still a much easier way, using a single Tomcat
instance and just 2 separate "virtual hosts" inside the same running
Tomcat (see :
http://tomcat.apache.org/tomcat-7.0-doc/virtual-hosting-howto.html).
The hostnames will be different, and the webapps will be completely
separate.  But there will still be one single instance of tomcat
running, and there /could/ be interference between them (not at the
access level, but

Re: Tomcat


On 2/6/2013 3:20 AM, mohit.g...@rbs.com wrote:


Hi Thanks for all the help and I know it may sound lame but I am
trying to learn these things. Although I have one more doubt. If we
have multiple tomcat for multiple environment on the single Unix
box(machine) Now Single Apache daemon is running for multiple
environment. So can we run multiple instance of Apache daemon in the
same machine or not for each different environment. If this is
possible how can we accomplish this.

Thanks in advance for the help and sorry for bugging the group with
such silly questions.

MOHIT GARG Analyst International Banking RBS Block No 1, Tower A,
Unitech Infospace Complex Sector 21, Gurgaon, Haryana, 122002, India
Office: +91 8860190177

-Original Message- From: André Warnier
[mailto:a...@ice-sa.com] Sent: 06 February 2013 16:21 To: Tomcat Users
List Subject: Re: Tomcat

mohit.g...@rbs.com wrote:

Hi

Regrets for the wrong framing of question. Actually I am new to
tomcat and what I really want to do is run on the same server two
different tomcats so that one doesn't interfere with the working of
the other. As I have different environments so I want that the
tomcat running in my development environment do not access the
files of my SIT environment and vice-versa. That's why I want to
have a separate tomcat process for each host. If I just change the
port in the config file the request will be mapped but the various
environments will have access to all the files as it will be
present in the common directory.



Ah, that's better. So we forget about Apache httpd, right ? So,
assuming that you are talking about tomcat only :

There are (many) different levels of separation, depending on what
you really want to separate.

First, a note : considering that you are on a Linux machine, it is
highly possible that you have installed Tomcat using a pre-packaged
version from your Linux distribution. These packages work fine and
are easy to install for a normal single-instance case, but they make
it more difficult for doing the kind of thing that you want to do,
and more difficult for people on this list to help you.  That is
because each of these packages distributes the files of Tomcat in
different places on the disk, sets different environment variables,
sets differents links from one directory to the other in the
filesystem, etc.. So it would be better to install a "standard"
tomcat downloaded from the website "tomcat.apache.org", to some
directory like /opt/tomcat, and follow the instructions that are
given in the "RUNNING.txt" file at the top of this distribution. This
way, everyone here knows what you are talking about and has a good
idea of where things are. (You can also leave your current Tomcat
where it is, and consider it as your "production" tomcat, and
download and install another copy to another directory as your
"development" tomcat. Then we can maybe help you set up this
development tomcat in a way that does not conflict with the other
one).

Then, the next question is : you want to run 2 "separate" tomcats, so
as not to mix the production and the development environments. That's
established. But do you want also to be able to run 2 different
/versions/ of Tomcat ?

If yes, you will have to download and install tomcat twice, to 2
separate directories in /opt (such as /opt/tomcat-prod and
/opt/tomcat-dev for instance). If not, then one single copy of tomcat
will be enough, and you can configure things to still run 2 different
"instances" of tomcat, from one single copy of the code.


Then, some advance information : There are 2 environment variables
which point to disk directories and which are very important for what
you want to do :

CATALINA_HOME : this tells Tomcat where its runnable *code* is
located.  under CATALINA_HOME, Tomcat expects to find for example
it's "bin" subdirectory, where the main executable parts of Tomcat
are located.

CATALINA_BASE : this tells Tomcat where its instance-specific
"things" are located. For example, Tomcat will look into
$CATALINA_BASE/conf to find its main configuration files.

By default, these 2 values are the same, and Tomcat will use the same
/bin, /conf etc..

But you can set up 2 tomcat instances to use the same $CATALINA_HOME
directory (so they will run the same Tomcat code from
$CATALINA_HOME/bin), but have different $CATALINA_BASE directories
(so they will use a different configuration from $CATALINA_BASE/conf,
different webapps from $CATALINA_BASE/webapps etc).

That's the basics for separating two tomcat instances.

Note that there is still a much easier way, using a single Tomcat
instance and just 2 separate "virtual hosts" inside the same running
Tomcat (see :
http://tomcat.apache.org/tomcat-7.0-doc/virtual-hosting-howto.html).
The hostnames will be different, and the webapps will be completely
separate.  But there will still be one single instance of tomcat
running, and there /could/ be interference between them (not at the
access level, but in the sense that on

Re: multiple instances of tomcat daemon


On 2/6/2013 1:28 AM, mohit.g...@rbs.com wrote:

Hi

I am using a tomcat server on a Linux machine. Is there any way I can
run multiple instances of apache daemon process so that if daemon for
environment A do not have access to files for environment B. In short
I want to run multiple daemon processes.

Thanks & Regards


Read RUNNING.txt in the root directory of the downloaded Tomcat bundle.

. . . . just my two cents.
/mde/

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

Re: Consider support for the Servlet profile of JSR 196 (JASPIC) in Tomcat 7.0.x

2013-02-06 Thread Ron Monzillo


On 2/3/13 5:02 AM, Mark Thomas wrote:

On 30/01/2013 23:57, Ron Monzillo wrote:

Tomcat Experts and Users,

The Servlet Profile of JSR 196 defines the use of the JASPIC SPI in
support of the portable integration
of new and/or custom authentication mechanisms in compatible Servlet
containers.

The Profile is a required component of all Full Platform EE Web
Containers, and we are receiving requests
for the profile to become a required component of the EE web profile. To
that end, we are contacting
standalone and EE web profile Servlet containers to determine if there
is interest in adopting the profile.

For those unfamiliar with JASPIC, the SPI is a general purpose facility
that applies the concepts of pluggable
authentication as defined by PAM and JAAS to the realm of message
authentication. The Servlet profile applies
the SPI to the realm of HttpServletRequest message authentication in the
context of servlet security constraint
processing. The SPI was defined to support complex challenge response
authentication protocols, and has
been shown to be an effective means to integrate portable
implementations of new internet authentication
mechanisms (e.g. Facebook Connect, and SAML WEB SSO) in compatible
Servlet containers.

Does the Tomcat community support the inclusion of the Servlet profile
of JSR 196 in the EE web Profile?

Apache Tomcat does not currently support the Java EE web profile. Tomcat
currently supports only the Servlet, JSP and EL specifications and will
be adding WebSocket to that list for Tomcat 8.

The has been very little demand from the Apache Tomcat user community to
support the Java EE web profile. There have been just two threads on the
users list that mention the web profile. There have been slightly more
on the dev list.

JASPIC was on the TODO list for Tomcat 7 for a while but it dropped off
because a) it wasn't a mandatory requirement for Servlet containers and
b) there was very little (no references at all on the users list) for it.

I think it would be safe to say that the Apache Tomcat community has no
opinion on the Java EE web profile requiring JSR 196 support. You'd
obviously get a very different reaction if the Servlet spec was going to
require JSR 196 support.

Apache TomEE does support the Java EE web profile. If you haven't
already approached that community for their views, I recommend that you
do so.

Mark,

I have posted the question to the TomEE and Caucho/Resin user's lists.

It would also help to know what the level of interest is from Tomcat 
users and developers.


I anticipate that there are Tomcat users and developers who are committed
to other approaches, but I'd like to make sure the use of JASPIC has been
presented for consideration by the Tomcat community.

I would also like to know if anyone has already done or is interested in 
doing

the work to integrate the JASPIC  profile in the Tomcat code base.

kind regards,

Ron



Kind regards,

Mark


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




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

Re: [Seriously OT] Help in diagnosing server unresponsiveness

2013-02-06 Thread Edson Richter

Em 06/02/2013 13:26, Jeffrey Janner escreveu:

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Tuesday, February 05, 2013 4:59 PM
To: Tomcat Users List
Subject: Re: [Seriously OT] Help in diagnosing server unresponsiveness

-BEGIN PGP SIGNED MESSAGE-

IMO, developer performance trumps runtime performance most of the time.
So, if you can create a more maintainable system in less time by using
EJB (or whatever), then you go ahead and do it: servers are cheap,
while developer time is expensive.

- -chris

Chris, I'd like to differ with you on this last point.
As someone who's been a developer, support person, and admin, I've got a pretty 
good perspective on this subject.
While servers may be cheap, they will never be cheap enough to overcome poor programming 
practices. I've worked with systems so poorly designed that we couldn't purchase a system 
big enough to run the software adequately, once you got above a handful of users. Yes, 
it's gotten to the point where systems are much cheaper than they used to be, while 
developer salaries are only increasing (supposedly), so wasting time on some minor 
performance improvement may not be cost-effective. However, when you aggregate the time 
that hundreds of users spend waiting on a response from a poorly designed, unresponsive 
system, I think you'll find that it trumps the cost of having the developer spending a 
few extra minutes to "get it right the first time".

I've partially agree. The systems architect should be able to create a 
balance between maintainable code and performance. We can't crucify 
JPA/EJB, indeed bad use of JPA/EJB (as any other development library) 
would induce to problems. Developers, in general, create tests for their 
own, to check if the logic if fulfilled. But then, it is mandatory to 
have another phase with load test - and then, in this situation, you 
will find the problems of memory, CPU, disk, network overload.

In our case, any window that takes more than 0,250s (250ms) to popup is 
considered an issue, and must be reworked. That doesn't mean we need to 
write SQL on our own, means that the communication flow is wrong, or 
there is more information in the window than the user need at that point.

No matter what some could argue, nobody reads more than 50 lines of 
anything (customers, sales, products) per page. So why execute a query 
that returns 35000 objects? So, the architect must have in my these 
constraints and requirements and then give the vision to the 
programmers, so they could write efficient code.

As said, I partially agree. I do prefer to spend few bucks more than 
have an application that will take hundreds of thousands of 
(what-ever-your-money-is) to recover user confidence.

Regards,

Edson

-
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: Strange thread behavior in tomcat/jboss 7


Leon Rosenberg wrote:

Hello Andre, et al,

On Wed, Feb 6, 2013 at 2:40 PM, André Warnier  wrote:


Leon Rosenberg wrote:
...




We have 105 threads in this state over multiple hours.

Question: Could it be that we have connection leakage through keep-alive
connections? Is there are possibility to reduce them?
I understand that jboss have the same apache 11 connector, however all
extended configuration options are removed from the doc:
http://docs.jboss.org/**jbossweb/7.0.x/config/http.**html



I don't know Jboss at all, but assuming that it is Tomcat behind, and
assuming that they have not replaced the HTTP Connector by their own, then
their documentation is wrong, and you could try the following attributes :

keepAliveTimeout

The number of milliseconds this Connector will wait for another HTTP
request before closing the connection. The default value is to use the
value that has been set for the connectionTimeout attribute. Use a value of
-1 to indicate no (i.e. infinite) timeout.

connectionTimeout

The number of milliseconds this Connector will wait, after accepting a
connection, for the request URI line to be presented. Use a value of -1 to
indicate no (i.e. infinite) timeout. The default value is 6 (i.e. 60
seconds) but note that the standard server.xml that ships with Tomcat sets
this to 2 (i.e. 20 seconds).

connectionTimeout can play a role if there are (nefarious) clients which
establish a connection to your server, but then just hang there and never
send any request on that connection. That's one known form of DOS attack.

A keepAliveTimeout of 60 seconds seems quite high to me.  It means that
- the browser created a connection and asked for it to be "persistent"
- the browser sent a request on this connection
- the server allocated one thread to process that request
- the thread sent the response to that request
- now the thread, instead of being immediately released to the pool of
idle threads (to process some other request) hangs on to the connection,
waiting to see if the browser has another request to send on it. And it
hangs so for keepAliveTimeout time (60 seconds here in the default case).
- if another request comes within a short period of time, the benefit is
that the connection has not been closed, so the browser and server do not
have the overhead of establishing a new one (a few packets exchanged, a few
thousand lines of code ran).
But if the browser has no more requests to send right now, you are wasting
an open TCP connection and a thread sitting there just waiting.
I can see this as useful nowadays if your application serves a lot of
pages containing many embedded  tags or the like, since the browser
will not have to open a new connection for each image that it wants to
retrieve.
But even then, a few seconds of keepAlive would suffice.



My analysis is pretty near yours. Still I don't think we are DOSed somehow,
but some 3K concurrent sessions could indeed block few hundred of threads
by simply keeping their browsers open and doing nothing.
I will try to reduce keep alive settings just to be sure :-) I hope Jboss
submits the parameter one on one ;-)



I am far from an expert in the matter, but JMX should allow you to view whatever 
parameters are in effect in the end. That's at the JVM level, so it should be independent 
of JBoss.


Also, don't know if it is your case, but if you are using Windows Integrated 
Authentication, setting keepAlive very low may have detrimental effects, forcing WIA to 
re-authenticate the user sessions more frequently.


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

RE: [Seriously OT] Help in diagnosing server unresponsiveness

2013-02-06 Thread Jeffrey Janner

> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Tuesday, February 05, 2013 4:59 PM
> To: Tomcat Users List
> Subject: Re: [Seriously OT] Help in diagnosing server unresponsiveness
> 
> -BEGIN PGP SIGNED MESSAGE-
> 
> IMO, developer performance trumps runtime performance most of the time.
> So, if you can create a more maintainable system in less time by using
> EJB (or whatever), then you go ahead and do it: servers are cheap,
> while developer time is expensive.
> 
> - -chris

Chris, I'd like to differ with you on this last point.
As someone who's been a developer, support person, and admin, I've got a pretty 
good perspective on this subject.
While servers may be cheap, they will never be cheap enough to overcome poor 
programming practices. I've worked with systems so poorly designed that we 
couldn't purchase a system big enough to run the software adequately, once you 
got above a handful of users. Yes, it's gotten to the point where systems are 
much cheaper than they used to be, while developer salaries are only increasing 
(supposedly), so wasting time on some minor performance improvement may not be 
cost-effective. However, when you aggregate the time that hundreds of users 
spend waiting on a response from a poorly designed, unresponsive system, I 
think you'll find that it trumps the cost of having the developer spending a 
few extra minutes to "get it right the first time".

Re: Strange thread behavior in tomcat/jboss 7

2013-02-06 Thread Leon Rosenberg

Hello Andre, et al,

On Wed, Feb 6, 2013 at 2:40 PM, André Warnier  wrote:

> Leon Rosenberg wrote:
> ...
>
>
>
>> We have 105 threads in this state over multiple hours.
>>
>> Question: Could it be that we have connection leakage through keep-alive
>> connections? Is there are possibility to reduce them?
>> I understand that jboss have the same apache 11 connector, however all
>> extended configuration options are removed from the doc:
>> http://docs.jboss.org/**jbossweb/7.0.x/config/http.**html
>>
>>
> I don't know Jboss at all, but assuming that it is Tomcat behind, and
> assuming that they have not replaced the HTTP Connector by their own, then
> their documentation is wrong, and you could try the following attributes :
>
> keepAliveTimeout
>
> The number of milliseconds this Connector will wait for another HTTP
> request before closing the connection. The default value is to use the
> value that has been set for the connectionTimeout attribute. Use a value of
> -1 to indicate no (i.e. infinite) timeout.
>
> connectionTimeout
>
> The number of milliseconds this Connector will wait, after accepting a
> connection, for the request URI line to be presented. Use a value of -1 to
> indicate no (i.e. infinite) timeout. The default value is 6 (i.e. 60
> seconds) but note that the standard server.xml that ships with Tomcat sets
> this to 2 (i.e. 20 seconds).
>
> connectionTimeout can play a role if there are (nefarious) clients which
> establish a connection to your server, but then just hang there and never
> send any request on that connection. That's one known form of DOS attack.
>
> A keepAliveTimeout of 60 seconds seems quite high to me.  It means that
> - the browser created a connection and asked for it to be "persistent"
> - the browser sent a request on this connection
> - the server allocated one thread to process that request
> - the thread sent the response to that request
> - now the thread, instead of being immediately released to the pool of
> idle threads (to process some other request) hangs on to the connection,
> waiting to see if the browser has another request to send on it. And it
> hangs so for keepAliveTimeout time (60 seconds here in the default case).
> - if another request comes within a short period of time, the benefit is
> that the connection has not been closed, so the browser and server do not
> have the overhead of establishing a new one (a few packets exchanged, a few
> thousand lines of code ran).
> But if the browser has no more requests to send right now, you are wasting
> an open TCP connection and a thread sitting there just waiting.
> I can see this as useful nowadays if your application serves a lot of
> pages containing many embedded  tags or the like, since the browser
> will not have to open a new connection for each image that it wants to
> retrieve.
> But even then, a few seconds of keepAlive would suffice.
>
>
My analysis is pretty near yours. Still I don't think we are DOSed somehow,
but some 3K concurrent sessions could indeed block few hundred of threads
by simply keeping their browsers open and doing nothing.
I will try to reduce keep alive settings just to be sure :-) I hope Jboss
submits the parameter one on one ;-)

regards
Leon

Re: Tomcat Upgrade & Migration Questions

2013-02-06 Thread Daniel Mikusa

On Feb 6, 2013, at 1:24 AM, Kirk Hoganson wrote:

> I am currently in the middle of an upgrade from Apache (2.2)/Tomcat
> (5.5.16) to Apache (2.2)/Tomcat (6.0.24).  The JVM is being upgraded from
> 1.5.0_09-b01 to 1.6.0_22-b22.  The new host servers will be RedHat 6.2.

Why are you upgrading to 6.0.24 & Java 1.6.0_22?  These are already multiple 
versions out of date.  Do yourself a favor and upgrade to the latest release of 
each, which at this time is 6.0.36 and Java 1.6.0_39.

> I would like to use the default application installation paths used by the
> RPMs.  

I can understand the temptation to do this, but you should really install 
Tomcat direct from http://tomcat.apache.org.  You'll get the latest version and 
it's packaged in a way that is familiar to everyone on this list, which means 
we can help you with problems. 

> However, I would like the user code base(s) to exist in a separate
> partition.  These servers will be hosting multiple separate java
> applications.  

Not sure what you mean by "code base".  Are you referring to the WAR files for 
your applications?  

If so, those are normally placed into your "webapps" directory.  You can change 
that directory by changing the "appBase" attribute of the  tag.

  https://tomcat.apache.org/tomcat-6.0-doc/config/host.html#Common%20Attributes

Or you can place a context file in "conf///.xml" and 
use "docBase" to specify the location of your WAR file.  Note, you would only 
do this if the path to the WAR file is not inside your "webapps" (i.e. appBase) 
directory already.

  https://tomcat.apache.org/tomcat-6.0-doc/config/context.html

> Currently Apache and Tomcat use mod_jk as the connector.
> 
> I am hoping for some advice that will help me with the server/Tomcat/Apache
> configuration.  I am specifically interested in Tomcat configuration
> advice, or direction.  I would like to get some clarification on the
> following questions:
> 
> How can I configure Tomcat to allow each individual application (JVM) to be
> restarted independently?
> 
>   - We currently do this with separate CATALINA_BASE directories, and
>   separate startup/shutdown scripts.  I’m not sure if that is the cleanest
>   way.

If you need to isolate your applications, i.e. one application per JVM, then 
this is the way to go.  It will also allow you to restart your Tomcat servers 
independently.  It may seem like a waste of memory, but the overhead of Tomcat 
is very small so it's not as bad as you might initially think.

An alternative approach would be to run all of your web apps in one Tomcat 
instance.  You could then reload individual applications using the Manager 
interface or you could undeploy / redeploy them.  This will restart your 
applications, but it's not quite the same as restarting the Tomcat server.  

What you do depends on your needs.

> 
> What method would best allow Apache to serve static content, and Tomcat to
> server java based dynamic content?
> 
>   - I’m assuming this will depend on the connector used.

The exact configuration to use will depend on how you proxy to your Tomcat 
server.  That being said, the general idea is that you keep requests to your 
static resources from being proxied to your Tomcat servers.  This then allows 
Apache HTTPD to service those requests.

This can either be done inclusively, i.e. by mapping only the paths which 
should be proxied, or exclusively by proxying everything and specify certain 
paths that should not be proxied.

With mod_proxy, you use ProxyPass and ProxyPass with an "!" (excludes) at the 
end of the path.

Ex:

  ProxyPass /myapp
  ProxyPass /myapp/static !

With mod_jk, you use JkMount and JkUnMount.

> 
> Which connector (mod_jk, mod_proxy_ajp, mod_cluster) should be used?

http://markmail.org/message/dftgdokeyebqd4ep?q=deciding-between-modjk-modproxyhttp-and-modproxyajp

> 
>   - I have heard conflicting reports about mod_jk being deprecated or not.

This is not true.  There are similarly named projects that you shouldn't use 
though, like mod_jk2, mod_jserv and mod_webapp.

>   - I have seen benchmarks with mod_proxy_ajp outperforming mod_jk
>   significantly.

I have not heard this, where did you see these?

Dan

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

RE: Tomcat in port 80 and Debian

2013-02-06 Thread Caldarale, Charles R

> From: Brett Delle Grazie [mailto:brett.dellegra...@gmail.com] 
> Subject: Re: Tomcat in port 80 and Debian

> > This topic is mentioned in the FAQ,
> > http://wiki.apache.org/tomcat/HowTo#How_to_run_Tomcat_without_root_privileges.3F

> Another alternative to those in the FAQ is to use the jsvc binary

Actually, jsvc is the _first_ thing mentioned in the above FAQ, with a link to 
the complete documentation on the package.

 - 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: can't start tomcat on port 80

2013-02-06 Thread Karolis Monkus


Ok guys, i did what you all said:
Removed that crappy 3rd party tomcat and downloaded tomcat tarball and port 
changing works fine. Now i need to run tomcat as service and since it's a 
Fedora it uses systemd instead init. So i created file called tomcat.service 
and placed it in /etc/systemd/system/ directory.


tomcat.service:

[Service]

ExecStart=/usr/share/apache-tomcat-7.0.35/bin/startup.sh

Restart=restart-always

[Install]

WantedBy=multi-user.target

Then i enable service using command "systemctl enable tomcat.service"
But nothing happens when i start tomcat with "service tomcat start"
Am i missing some more information in that tomcat.service file?

Thanks,
Karolis M.

- Original Message - 
From: "Caldarale, Charles R" 

To: "Tomcat Users List" 
Sent: Tuesday, February 05, 2013 5:15 PM
Subject: RE: can't start tomcat on port 80



From: Karolis Monkus [mailto:karolis.mon...@dts-solutions.lt]
Subject: Re: can't start tomcat on port 80



Nothing running on 80 port, selinux and firewall disabled, so no
need for writing iptables rules.


Good to kno.w


What do you mean by saying i need support from Fedora?


The third-party repackaged versions of Tomcat are not just copies of the 
real ones from tomcat.apache.org - they have been modified to change 
location and content of configuration files, log files, startup scripts, 
etc.  Consequently, when something doesn't work, it's often necessary to 
contact the repackager, since experience shows they broke it.



Would everything be easier if i just download newest tomcat tar
archive and manually install/run it?


It certainly would for those of us providing this voluntary support on the 
mailing list; we would then know exactly what we're dealing with.


- 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





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

Re: Strange thread behavior in tomcat/jboss 7

Leon Rosenberg wrote:
...

We have 105 threads in this state over multiple hours.

Question: Could it be that we have connection leakage through keep-alive
connections? Is there are possibility to reduce them?
I understand that jboss have the same apache 11 connector, however all
extended configuration options are removed from the doc:
http://docs.jboss.org/jbossweb/7.0.x/config/http.html

I don't know Jboss at all, but assuming that it is Tomcat behind, and assuming that they
have not replaced the HTTP Connector by their own, then their documentation is wrong, and
you could try the following attributes :

keepAliveTimeout

The number of milliseconds this Connector will wait for another HTTP request before
closing the connection. The default value is to use the value that has been set for the
connectionTimeout attribute. Use a value of -1 to indicate no (i.e. infinite) timeout.

connectionTimeout

The number of milliseconds this Connector will wait, after accepting a connection, for the
request URI line to be presented. Use a value of -1 to indicate no (i.e. infinite)
timeout. The default value is 6 (i.e. 60 seconds) but note that the standard
server.xml that ships with Tomcat sets this to 2 (i.e. 20 seconds).

connectionTimeout can play a role if there are (nefarious) clients which establish a
connection to your server, but then just hang there and never send any request on that
connection. That's one known form of DOS attack.

A keepAliveTimeout of 60 seconds seems quite high to me. It means that
- the browser created a connection and asked for it to be "persistent"
- the browser sent a request on this connection
- the server allocated one thread to process that request
- the thread sent the response to that request
- now the thread, instead of being immediately released to the pool of idle threads (to
process some other request) hangs on to the connection, waiting to see if the browser has
another request to send on it. And it hangs so for keepAliveTimeout time (60 seconds here
in the default case).
- if another request comes within a short period of time, the benefit is that the
connection has not been closed, so the browser and server do not have the overhead of
establishing a new one (a few packets exchanged, a few thousand lines of code ran).
But if the browser has no more requests to send right now, you are wasting an open TCP
connection and a thread sitting there just waiting.
I can see this as useful nowadays if your application serves a lot of pages containing
many embedded tags or the like, since the browser will not have to open a new
connection for each image that it wants to retrieve.

But even then, a few seconds of keepAlive would suffice.

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

Re: Tomcat


mohit.g...@rbs.com wrote:
 
Hi

Thanks for all the help and I know it may sound lame but I am trying to learn 
these things.
Although I have one more doubt.
If we have multiple tomcat for multiple environment on the single Unix 
box(machine)
Now Single Apache daemon is running for multiple environment. So can we run 
multiple instance of Apache daemon in the same machine or not for each 
different environment.
If this is possible how can we accomplish this.



Yes you can, but this is a Tomcat list, not an Apache httpd list.
So for that question you should better go to the Apache httpd help list.

The real question is : what does that Apache httpd really do, in your setup ?


(Unrelated note : send your responses only to the list, do not send me an extra copy. I 
already get each message posted to the list, so I get them in double now).


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

RE: Tomcat

Hi
Thanks for all the help and I know it may sound lame but I am trying to learn 
these things.
Although I have one more doubt.
If we have multiple tomcat for multiple environment on the single Unix 
box(machine)
Now Single Apache daemon is running for multiple environment. So can we run 
multiple instance of Apache daemon in the same machine or not for each 
different environment.
If this is possible how can we accomplish this.

Thanks in advance for the help and sorry for bugging the group with such silly 
questions.

MOHIT GARG
Analyst 
International Banking
RBS
Block No 1, Tower A, Unitech Infospace Complex Sector 21, Gurgaon, Haryana, 
122002, India
Office: +91 8860190177   

-Original Message-
From: André Warnier [mailto:a...@ice-sa.com] 
Sent: 06 February 2013 16:21
To: Tomcat Users List
Subject: Re: Tomcat

mohit.g...@rbs.com wrote:
> Hi
>  
> Regrets for the wrong framing of question.
> Actually I am new to tomcat and what I really want to do is run on the same 
> server two different tomcats so that one doesn't interfere with the working 
> of the other.
> As I have different environments so I want that the tomcat running in my 
> development environment do not access the files of my SIT environment and 
> vice-versa. That's why I want to have a separate tomcat process for each host.
> If I just change the port in the config file the request will be mapped but 
> the various environments will have access to all the files as it will be 
> present in the common directory.
> 

Ah, that's better.
So we forget about Apache httpd, right ?
So, assuming that you are talking about tomcat only :

There are (many) different levels of separation, depending on what you really 
want to separate.

First, a note : considering that you are on a Linux machine, it is highly 
possible that you have installed Tomcat using a pre-packaged version from your 
Linux distribution.
These packages work fine and are easy to install for a normal single-instance 
case, but they make it more difficult for doing the kind of thing that you want 
to do, and more difficult for people on this list to help you.  That is because 
each of these packages distributes the files of Tomcat in different places on 
the disk, sets different environment variables, sets differents links from one 
directory to the other in the filesystem, etc..
So it would be better to install a "standard" tomcat downloaded from the 
website "tomcat.apache.org", to some directory like /opt/tomcat, and follow the 
instructions that are given in the "RUNNING.txt" file at the top of this 
distribution.
This way, everyone here knows what you are talking about and has a good idea of 
where things are.
(You can also leave your current Tomcat where it is, and consider it as your 
"production" 
tomcat, and download and install another copy to another directory as your 
"development" 
tomcat. Then we can maybe help you set up this development tomcat in a way that 
does not conflict with the other one).

Then, the next question is : you want to run 2 "separate" tomcats, so as not to 
mix the production and the development environments. That's established.
But do you want also to be able to run 2 different /versions/ of Tomcat ?

If yes, you will have to download and install tomcat twice, to 2 separate 
directories in /opt (such as /opt/tomcat-prod and /opt/tomcat-dev for instance).
If not, then one single copy of tomcat will be enough, and you can configure 
things to still run 2 different "instances" of tomcat, from one single copy of 
the code.

Then, some advance information :
There are 2 environment variables which point to disk directories and which are 
very important for what you want to do :

CATALINA_HOME : this tells Tomcat where its runnable *code* is located.  under 
CATALINA_HOME, Tomcat expects to find for example it's "bin" subdirectory, 
where the main executable parts of Tomcat are located.

CATALINA_BASE : this tells Tomcat where its instance-specific "things" are 
located. For example, Tomcat will look into $CATALINA_BASE/conf to find its 
main configuration files.

By default, these 2 values are the same, and Tomcat will use the same /bin, 
/conf etc..

But you can set up 2 tomcat instances to use the same $CATALINA_HOME directory 
(so they will run the same Tomcat code from $CATALINA_HOME/bin), but have 
different $CATALINA_BASE directories (so they will use a different 
configuration from $CATALINA_BASE/conf, different webapps from 
$CATALINA_BASE/webapps etc).

That's the basics for separating two tomcat instances.

Note that there is still a much easier way, using a single Tomcat instance and 
just 2 separate "virtual hosts" inside the same running Tomcat (see : 
http://tomcat.apache.org/tomcat-7.0-doc/virtual-hosting-howto.html).
The hostnames will be different, and the webapps will be completely separate.  
But there will still be one single instance of tomcat running, and there 
/could/ be interference between them (not at the access le

Re: Help in diagnosing server unresponsiveness

2013-02-06 Thread Edson Richter

Em 06/02/2013 01:18, Zoran Avtarovski escreveu:

Thanks Igor,

I just stumbled upon that same document. I think you may be on to
something here.

I have a feeling that the GC may not be configured well.

Also read the following:
http://docs.oracle.com/cd/E13150_01/jrockit_jvm/jrockit/geninfo/diagnos/bestpractices.html

And check this (if you are using RHEL 6 or CentOS 6, worth to take a look):
https://rhn.redhat.com/errata/RHSA-2013-0223.html

Edson

On 6/02/13 2:15 PM, "Igor Cicimov" wrote:

On Wed, Feb 6, 2013 at 1:15 PM, Zoran Avtarovski
wrote:

Here's some updated observations after a not quite incident (CPU and
memory spiked but the app is still running):

1. Yesterday we had a 90% CPU spike at a time where there was absolutely
no server traffic. Verified through both the HTTP logs and the mod_jk
logs. The CPU spiked and recovered back to average levels.
2. Used memory spiked at 10GB from a pre incident average of 500MB
throughout 2 busy days without incident
3. Used memory has only gone back down to 4GB and is holding at this
level
4. The Used physical memory went up from 2GB to 14GB and has stayed
there
5. Garbage collector time spikes to 24.0. I think with JavaMelody it
means
that GC took 24% of of the CPU??

So I think our issues are related to GC. Is there a way to trigger more
frequent GC which will hopefully be less resource intensive?

And why have the memory usage levels not recovered?

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

Zoran,

First I would like to recommend the following document for reading:
http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html#cms

It explains the GC in JVM 1.6 including the Concurrent Collector settings
which is the one you are using. The values for the GC in the log file are
the time the particular collector spent for the operation so the 24.0
would
probably mean 24 seconds, which might mean that for 24 seconds your
applications might be unresponsive during the CMS GC.

As explained in the document from the above link the GC has minor and
major
collecting phases. During the minor collection the objects are GC'ed from
the so called young generation or promoted in the old (tenured)
generation.
More of this objects pile up in the old generation more frequent the major
GC needs to run. The major ones take usually much longer (they have to
clean much bigger space) time than the minor ones but the minor ones have
to run more frequently. Now, what you need to find is what is causing your
problem really? If your application creates lot of new objects then you'll
have lots of minor GC running. More of this objects survive, they get
moved
to the old generation space and then you'll have lots of major GC running
as well. The danger here is that you might end up with constantly running
GC which will render your application unusable due to pauses. So basically
badly written application can cause lots of problems, not closing
connections and freeing objects etc etc, and in that case even the best GC
tunning in the world will not help you, your application(s) will
eventually
get to halt.

So read the document carefully and decide which user case is best for you.
If you are creating lots of new objects then maybe increasing the minor
space (default new/old ratio is 1:3) can help.

Also paste here the results of the GC logs. The link I provided has some
more useful settings and recommendations for the CMS collector. This
collector stops the application threads twice during the operation so you
need to check those times too.

Cheers & Pozdrav,
Igor

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

Re: Tomcat


mohit.g...@rbs.com wrote:

Hi
 
Regrets for the wrong framing of question.

Actually I am new to tomcat and what I really want to do is run on the same 
server two different tomcats so that one doesn't interfere with the working of 
the other.
As I have different environments so I want that the tomcat running in my 
development environment do not access the files of my SIT environment and 
vice-versa. That's why I want to have a separate tomcat process for each host.
If I just change the port in the config file the request will be mapped but the 
various environments will have access to all the files as it will be present in 
the common directory.



Ah, that's better.
So we forget about Apache httpd, right ?
So, assuming that you are talking about tomcat only :

There are (many) different levels of separation, depending on what you really want to 
separate.


First, a note : considering that you are on a Linux machine, it is highly possible that 
you have installed Tomcat using a pre-packaged version from your Linux distribution.
These packages work fine and are easy to install for a normal single-instance case, but 
they make it more difficult for doing the kind of thing that you want to do, and more 
difficult for people on this list to help you.  That is because each of these packages 
distributes the files of Tomcat in different places on the disk, sets different 
environment variables, sets differents links from one directory to the other in the 
filesystem, etc..
So it would be better to install a "standard" tomcat downloaded from the website 
"tomcat.apache.org", to some directory like /opt/tomcat, and follow the instructions that 
are given in the "RUNNING.txt" file at the top of this distribution.
This way, everyone here knows what you are talking about and has a good idea of where 
things are.
(You can also leave your current Tomcat where it is, and consider it as your "production" 
tomcat, and download and install another copy to another directory as your "development" 
tomcat. Then we can maybe help you set up this development tomcat in a way that does not 
conflict with the other one).


Then, the next question is : you want to run 2 "separate" tomcats, so as not to mix the 
production and the development environments. That's established.

But do you want also to be able to run 2 different /versions/ of Tomcat ?

If yes, you will have to download and install tomcat twice, to 2 separate directories in 
/opt (such as /opt/tomcat-prod and /opt/tomcat-dev for instance).
If not, then one single copy of tomcat will be enough, and you can configure things to 
still run 2 different "instances" of tomcat, from one single copy of the code.



Then, some advance information :
There are 2 environment variables which point to disk directories and which are very 
important for what you want to do :


CATALINA_HOME : this tells Tomcat where its runnable *code* is located.  under 
CATALINA_HOME, Tomcat expects to find for example it's "bin" subdirectory, where the main 
executable parts of Tomcat are located.


CATALINA_BASE : this tells Tomcat where its instance-specific "things" are located. For 
example, Tomcat will look into $CATALINA_BASE/conf to find its main configuration files.


By default, these 2 values are the same, and Tomcat will use the same /bin, 
/conf etc..

But you can set up 2 tomcat instances to use the same $CATALINA_HOME directory (so they 
will run the same Tomcat code from $CATALINA_HOME/bin), but have different $CATALINA_BASE 
directories (so they will use a different configuration from $CATALINA_BASE/conf, 
different webapps from $CATALINA_BASE/webapps etc).


That's the basics for separating two tomcat instances.

Note that there is still a much easier way, using a single Tomcat instance and just 2 
separate "virtual hosts" inside the same running Tomcat

(see : http://tomcat.apache.org/tomcat-7.0-doc/virtual-hosting-howto.html).
The hostnames will be different, and the webapps will be completely separate.  But there 
will still be one single instance of tomcat running, and there /could/ be interference 
between them (not at the access level, but in the sense that one webapp could use up all 
the memory and so interfere with the other e.g.).



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

Re: multiple instances of tomcat daemon


mohit.g...@rbs.com wrote:

Hi
 
I am using a tomcat server on a Linux machine.

Is there any way I can run multiple instances of apache daemon process so that 
if daemon for environment A do not have access to files for environment B.
In short I want to run multiple daemon processes.
 

That's not really what I meant by "rephrasing your question".  Try again ?

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

RE: Tomcat

Hi

Regrets for the wrong framing of question.
Actually I am new to tomcat and what I really want to do is run on the same 
server two different tomcats so that one doesn't interfere with the working of 
the other.
As I have different environments so I want that the tomcat running in my 
development environment do not access the files of my SIT environment and 
vice-versa. That's why I want to have a separate tomcat process for each host.
If I just change the port in the config file the request will be mapped but the 
various environments will have access to all the files as it will be present in 
the common directory.

-Original Message-
From: André Warnier [mailto:a...@ice-sa.com] 
Sent: 06 February 2013 15:30
To: Tomcat Users List
Subject: Re: Tomcat

mohit.g...@rbs.com wrote:

> Hi
> 
> I am using a tomcat server on a Linux machine.
> Is there any way I can run multiple instances of apached daemon process so 
> that if daemon for environment A do not have access to files for environment 
> B.
> In short I want to run multiple daemon processes.
> 

Hi. No offense but the way you are asking your question tends to suggest that 
you have a limited understanding of how this stuff works. Here are some 
pointers :

You seem to be talking about 2 different products :
1) Apache httpd : is a general purpose webserver, made by people who belong to 
the Apache httpd project (see : httpd.apache.org)
2) Apache Tomcat : is also a webserver, but mainly a "java servlet container", 
designed primarily to run web applications written in java.  It is made by 
other people who belong to the Apache Tomcat project (see : tomcat.apache.org)

(And see "www.apache.org" for what "Apache" really is).

Either one of Apache httpd or Apache tomcat can act as a webserver, serve 
static content and run web applications.
They can also work in combination, with Apache httpd acting as a front-end to 
one or more Tomcat servers.  If the client browsers always access the front-end 
Apache httpd server, and the front-end Apache httpd server then distributes the 
work to several back-end tomcat servers, this is called "proxying" and/or "load 
balancing".  There are also other programs (or hardware boxes) that can act as 
"proxy" and/or "load-balancer".

In both cases (Apache httpd or tomcat), you /can/ run several instances on a 
same host. 
It is only a matter of configuration.
Generally-speaking however, if the problem is that one instance is not enough 
to support the load that is put on it, multiplying the instances on the same 
host will not help.
You will need either to improve your applications (so that they respond 
better), or use a bigger machine, or multiply the hosts and divide the load 
between them (using a load-balancing configuration).

If the question is about separating the documents or applications into several 
independent "domains", so that one "website" does not have access to the data 
of another website, then in both cases the solution may be to run one single 
instance, but use what is know as "virtual hosts" (where one instance responds 
to several hostnames, each having its own documents and applications).

So now, would you like to rephrase your question more precisely ?

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

***

The Royal Bank of Scotland plc. Registered in Scotland No 90312. 
Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. 
Authorised and regulated by the Financial Services Authority. The 
Royal Bank of Scotland N.V. is authorised and regulated by the 
De Nederlandsche Bank and has its seat at Amsterdam, the 
Netherlands, and is registered in the Commercial Register under 
number 33002587. Registered Office: Gustav Mahlerlaan 350, 
Amsterdam, The Netherlands. The Royal Bank of Scotland N.V. and 
The Royal Bank of Scotland plc are authorised to act as agent for each 
other in certain jurisdictions. 

This e-mail message is confidential and for use by the addressee only. 
If the message is received by anyone other than the addressee, please 
return the message to the sender by replying to it and then delete the 
message from your computer. Internet e-mails are not necessarily 
secure. The Royal Bank of Scotland plc and The Royal Bank of Scotland 
N.V. including its affiliates ("RBS group") does not accept responsibility 
for changes made to this message after it was sent. For the protection
of RBS group and its clients and customers, and in compliance with
regulatory requirements, the contents of both incoming and outgoing
e-mail communications, which could include proprietary information and
Non-Public Personal Information, may be read by authorised persons
within RBS group other than the intended recipient(s). 

Whilst all reasonable care has been taken to

Re: Tomcat


mohit.g...@rbs.com wrote:


Hi

I am using a tomcat server on a Linux machine.
Is there any way I can run multiple instances of apached daemon process so that 
if daemon for environment A do not have access to files for environment B.
In short I want to run multiple daemon processes.



Hi. No offense but the way you are asking your question tends to suggest that you have a 
limited understanding of how this stuff works. Here are some pointers :


You seem to be talking about 2 different products :
1) Apache httpd : is a general purpose webserver, made by people who belong to the Apache 
httpd project (see : httpd.apache.org)
2) Apache Tomcat : is also a webserver, but mainly a "java servlet container", designed 
primarily to run web applications written in java.  It is made by other people who belong 
to the Apache Tomcat project (see : tomcat.apache.org)


(And see "www.apache.org" for what "Apache" really is).

Either one of Apache httpd or Apache tomcat can act as a webserver, serve static content 
and run web applications.
They can also work in combination, with Apache httpd acting as a front-end to one or more 
Tomcat servers.  If the client browsers always access the front-end Apache httpd server, 
and the front-end Apache httpd server then distributes the work to several back-end tomcat 
servers, this is called "proxying" and/or "load balancing".  There are also other programs 
(or hardware boxes) that can act as "proxy" and/or "load-balancer".


In both cases (Apache httpd or tomcat), you /can/ run several instances on a same host. 
It is only a matter of configuration.
Generally-speaking however, if the problem is that one instance is not enough to support 
the load that is put on it, multiplying the instances on the same host will not help.
You will need either to improve your applications (so that they respond better), or use a 
bigger machine, or multiply the hosts and divide the load between them (using a 
load-balancing configuration).


If the question is about separating the documents or applications into several independent 
"domains", so that one "website" does not have access to the data of another website, then 
in both cases the solution may be to run one single instance, but use what is know as 
"virtual hosts" (where one instance responds to several hostnames, each having its own 
documents and applications).


So now, would you like to rephrase your question more precisely ?

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

multiple instances of tomcat daemon

Hi
 
I am using a tomcat server on a Linux machine.
Is there any way I can run multiple instances of apache daemon process so that 
if daemon for environment A do not have access to files for environment B.
In short I want to run multiple daemon processes.
 
Thanks & Regards

MOHIT GARG 
Analyst 
International Banking
RBS
Block No 1, Tower A, Unitech Infospace Complex Sector 21, Gurgaon, Haryana, 
122002, India
Office: +91 8860190177 


***
 
The Royal Bank of Scotland plc. Registered in Scotland No 90312. 
Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. 
Authorised and regulated by the Financial Services Authority. The 
Royal Bank of Scotland N.V. is authorised and regulated by the 
De Nederlandsche Bank and has its seat at Amsterdam, the 
Netherlands, and is registered in the Commercial Register under 
number 33002587. Registered Office: Gustav Mahlerlaan 350, 
Amsterdam, The Netherlands. The Royal Bank of Scotland N.V. and 
The Royal Bank of Scotland plc are authorised to act as agent for each 
other in certain jurisdictions. 
  
This e-mail message is confidential and for use by the addressee only. 
If the message is received by anyone other than the addressee, please 
return the message to the sender by replying to it and then delete the 
message from your computer. Internet e-mails are not necessarily 
secure. The Royal Bank of Scotland plc and The Royal Bank of Scotland 
N.V. including its affiliates ("RBS group") does not accept responsibility 
for changes made to this message after it was sent. For the protection
of RBS group and its clients and customers, and in compliance with
regulatory requirements, the contents of both incoming and outgoing
e-mail communications, which could include proprietary information and
Non-Public Personal Information, may be read by authorised persons
within RBS group other than the intended recipient(s). 

Whilst all reasonable care has been taken to avoid the transmission of 
viruses, it is the responsibility of the recipient to ensure that the onward 
transmission, opening or use of this message and any attachments will 
not adversely affect its systems or data. No responsibility is accepted 
by the RBS group in this regard and the recipient should carry out such 
virus and other checks as it considers appropriate. 

Visit our website at www.rbs.com 

***
  


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

Tomcat