date:20110103


Harsimranjit singh Kler wrote:

Hi

Here is details:

*Tomcat version*: 5.5.27
*OS*:Window XP
*JDK*:1.6
*Environment Trying to Create* :Load balancing and Clustering on single
Machine using tomcat instances only(balancer Feature) .

*What i have Achieved*:i am running 4 instances of tomcat on ports
8080,9080,10080,11080.So port 8080 tomcat work as balancer and other works
as cluster.(Using Multicasting IP and Port {check server.xml} it works
fine).
attached find server.xml,web.xml,rule.xml of balancer tomcat(8080).

So using  balancer feature in tomcat and rule.xml and some customized
classes requests are successfully redirected to one of cluster ie 9080,10080
or 11080 instance.

*Issue*:when request redirected from tomcat balancer(on 8080 port) to any
cluster (tomcat instance on 9080,10080 or 11080 port) URL in address bar
also changed. i dont want to display cluster URL.So how i can achive this?.

i think org.apache.webapp.balancer.BalancerFilter  class internally use
SendRedirect() method .

I tried with requestDispatcher..Forward() but it accept only realtive
address.




I believe that David already gave you the basic answer.





From what I read in the message, it appears the balancer is sending the
browser a redirect (one of the 30x responses) which in turn changes the
url in the browser's address bar.  The OP (if I understand correctly)
would like the url in the browser's address bar not to change at all (no
30x redirect response).  The only way I can imagine that working is if
the balancer acts as a reverse proxy, sending each request back to a
different back-end worker.


I don't think that what you want to achieve can be done (yet) with Tomcat alone.

As a bit of an outsider's answer, I'll add this : from browsing the Tomcat cluster on-line 
documentation, it looks to me as a very impresive piece of work, but also as quite a 
complex setup.


If your main purpose is to balance the load between a number of back-end Tomcat engines, I 
believe that using an Apache httpd front-end with either of the mod_proxy_ajp or the 
mod_jk connector, would be much easier to set up, and would provide exactly what you want 
: a single hostname:port for the clients, and load-balancing, and fail-over capabilities.


It does that, because it would act like David indicates above, as a reverse proxy.  In 
this kind of configuration, the clients (browsers e.g.) always talk to the same front-end 
server, and receive the responses from that front-end server.  The front-end server in 
turn passes the requests to one of several back-end servers, and gets the response from 
them, which they then send back to the client.
The clients always talk to the front-end server, and see only that one; they never even 
know that there are back-end servers, and never see the hostname:port of these back-end 
servers.


Maybe the Tomcat cluster configuration does additional things which the front-end balancer 
setup cannot do.  But that is an area that I really don't know, and maybe someone else can 
comment on that.



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

What is the healthy interval length for young gc?

Hi,

First of all Happy and Successful New Year to all subscribers.

I understand that this is a very application specific issue, but I'm
wondering which interval is perceived as 'healthy' for young
collections?
I have one customer's system which, at peak time, performs a young gc
every 15 seconds. Parallel the response time goes incredibly high (30
seconds).
Here a log sniplet:

2010-12-30T21:34:07.500+0100: 818132.148: [Full GC [PSYoungGen:
289802K-0K(3838208K)] [PSOldGen: 8366132K-7958635K(8388608K)]
8655935K-7958635K(12226816K) [PSPermGen: 152897K-152281K(262144K)],
79.1738980 secs] [Times: user=79.04 sys=0.02, real=79.18 secs]
2010-12-30T21:35:36.748+0100: 818221.397: [GC [PSYoungGen:
3487936K-106067K(3794752K)] 11446571K-8064702K(12183360K), 0.3410450
secs] [Times: user=1.83 sys=0.01, real=0.34 secs]
2010-12-30T21:35:43.792+0100: 818228.441: [GC [PSYoungGen:
3555155K-129828K(3578944K)] 11513790K-8088464K(11967552K), 0.2955760
secs] [Times: user=1.39 sys=0.02, real=0.30 secs]
2010-12-30T21:35:58.512+0100: 818243.160: [GC [PSYoungGen:
3578617K-154016K(3795456K)] 11537253K-8112652K(12184064K), 0.3276970
secs] [Times: user=1.57 sys=0.07, real=0.33 secs]
2010-12-30T21:36:28.126+0100: 818272.774: [GC [PSYoungGen:
3561760K-143668K(3551424K)] 11520396K-8102304K(11940032K), 0.3682730
secs] [Times: user=1.56 sys=0.12, real=0.37 secs]

So my questions are:

Could it be that the long liveness of the objects in the young space,
combined with often young collections lead to heap pollution on the
old gen, cause request bound objects live to long?

Do I understand it correctly that the size of the young space doesn't
influence the collection time (as long as the amount of living objects
remains the same) and does it make sense to increase the young space
in our case?

tomcat: 6.0.20
java 1.6.0.16

regards
Leon

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

Re: What is the healthy interval length for young gc?

Leon Rosenberg wrote:

Hi,

First of all Happy and Successful New Year to all subscribers.

And the same to you.

I understand that this is a very application specific issue, but I'm
wondering which interval is perceived as 'healthy' for young
collections?
I have one customer's system which, at peak time, performs a young gc
every 15 seconds. Parallel the response time goes incredibly high (30
seconds).

So my questions are:

Could it be that the long liveness of the objects in the young space,
combined with often young collections lead to heap pollution on the
old gen, cause request bound objects live to long?

Do I understand it correctly that the size of the young space doesn't
influence the collection time (as long as the amount of living objects
remains the same) and does it make sense to increase the young space
in our case?

Here is what I believe to be a nice article :
http://chaoticjava.com/posts/how-does-garbage-collection-work/

Of course, we really need Chuck to comment on this.
But let me tell you what I think, at the risk of stepping on my own fingers
again.

I refer to the nice pictures in the above article.

The symptom that the response time becomes very long, makes me think that it is a Major GC
that is taking place often, not only a Minor GC. I don't think that a Minor GC (involving
only the new Heap area) suspends the applications, while a Major GC does.

If Major GC's are taking place often, then it must mean that despite the regular copying
from the From to the To parts of the new generation (by the Minor GCs), the JVM is
running out of space on the new gen part, and therefore has to do a Major GC to move
things to the old gen.

By increasing the space on the new gen alone, you may make Minor GC's less
frequent.

But if objects are being copied in the new gen between the From and the To, and the new
gen is getting filled up rapidly anyway (since the Major GC's happen), it means that these
objects are still referenced somewhere and are not discarded during the copying. So by
increasing the new gen alone, you risk that when the Major GC does happen, it will fill up
the old gen too. And if that one ever gets full, you will get an OOM.

So I would increase the Heap as a whole, and let Java determine the proper split between
the parts. And of course you can monitor what really happens, using a number of tools
(like jconsole).

I do not think that the fact of copying the objects from the new gen to the old gen
causes the objects to live too long. They live long because they are still being
referenced somewhere and thus cannot be forgotten.
So the real issue may be in the application, which is keeping references to objects, when
it shouldn't.
That may be a more difficult fix than some magic formula for Heap size. But there have
been a lot of discussions lately on the list about memory leaks, and maybe you can find
inspiration there.

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

Re: What is the healthy interval length for young gc?

Hello André,

On Mon, Jan 3, 2011 at 1:35 PM, André Warnier a...@ice-sa.com wrote:
 Leon Rosenberg wrote:
 I understand that this is a very application specific issue, but I'm
 wondering which interval is perceived as 'healthy' for young
 collections?
 I have one customer's system which, at peak time, performs a young gc
 every 15 seconds. Parallel the response time goes incredibly high (30
 seconds).

 So my questions are:

 Could it be that the long liveness of the objects in the young space,
 combined with often young collections lead to heap pollution on the
 old gen, cause request bound objects live to long?

 Do I understand it correctly that the size of the young space doesn't
 influence the collection time (as long as the amount of living objects
 remains the same) and does it make sense to increase the young space
 in our case?

 Here is what I believe to be a nice article :
 http://chaoticjava.com/posts/how-does-garbage-collection-work/

 Of course, we really need Chuck to comment on this.
 But let me tell you what I think, at the risk of stepping on my own fingers
 again.

 I refer to the nice pictures in the above article.

 The symptom that the response time becomes very long, makes me think that it
 is a Major GC that is taking place often, not only a Minor GC.  I don't
 think that a Minor GC (involving only the new Heap area) suspends the
 applications, while a Major GC does.

Nope. I mean we know that we have pauses (70 seconds) when the major
gc occurs, and we know, where it comes from, and we are fighting it,
but this is not the symptom ;-)



 If Major GC's are taking place often, then it must mean that despite the
 regular copying from the From to the To parts of the new generation (by
 the Minor GCs), the JVM is running out of space on the new gen part, and
 therefore has to do a Major GC to move things to the old gen.

Actually no, in my understanding both are independent. I mean the gc
doesn't start to copy over if young is full, it simply cleans young.
However,
to quote your article: Old generation objects are objects that
survived a few collections in the young generation area, and if
objects managed to survive longer as they should in the young space,
they might have been copied to old gen, despite the fact, that they
are young generation objects by nature (meaning short lifetime). This
theory is what I'm trying to check.


 So I would increase the Heap as a whole, and let Java determine the proper
 split between the parts.  And of course you can monitor what really happens,
 using a number of tools (like jconsole).

No we can't, because it would also increase the time for full gc,
which will stop the application for even longer (causing enough
headache already :-()

but anyway thanks for the suggestions ;-)

regards
Leon

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

Re: isapi_redirector.dll Problems - Bad Gateway?


What I mean by internally is the application works on the intranet within our
corporate domain.  I'm trying to get the application to work externally
outside the corporate firewall.


awarnier wrote:
 
 amythyst wrote:
 I'm fairly certain the tomcat server is up and running because the
 application works internally.  If tomcat wasn't working then I assume I
 wouldn't be able to access the app internally as it requires tomcat to
 function.
 
 Define what you mean by internally, as opposed to the other way.
 What exactly do you use for the internal URL which works, as opposed to
 what 
 non-internal which does not work ?
 
 (replace the hostname by myhost.com or something; but if the hostnames
 are different in 
 each case, then convey that somehow).
 
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 
 
 

-- 
View this message in context: 
http://old.nabble.com/isapi_redirector.dll-Problems---Bad-Gateway--tp30500400p30577794.html
Sent from the Tomcat - User mailing list archive at Nabble.com.


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

Tomcat uses more and more PermGen space

2011-01-03 Thread Mikolaj Rydzewski



Hi all,

While investigating OOM issue I discovered, that Tomcat instantly uses 
more and more PermGen space.

At this moment I have access to one environemnt only, this is:

Windows XP
Java 1.6.0_22
Vanilla Tomcat 6.0.21

I use jconsole to monitor PermGen space and I can observe that it 
slowly increases. There are no other webapps deployed, nor any requests 
to tomcat. Is it normal?


I started to look at this, because customer reported, that with his 
setup, PermGen doubled its size within 3 hours! He runs lambda probe 
webapp and another webapp which makes heavy use of XStream library. I 
googled and found that there are reports related to XStream and PermGen 
issues.


I wonder if anyone encountered anything similiar?

--
Mikolaj Rydzewski m...@ceti.pl

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

Re: Tomcat uses more and more PermGen space

On 1/3/11 1:48 PM, Mikolaj Rydzewski wrote:
 
 Hi all,
 
 While investigating OOM issue I discovered, that Tomcat instantly uses
 more and more PermGen space.
 At this moment I have access to one environemnt only, this is:
 
 Windows XP
 Java 1.6.0_22
 Vanilla Tomcat 6.0.21

Are you sure it's 6.0.21?  This version was not released.

If you're using it in production you know what I'm going to suggest you
do, right?


 I use jconsole to monitor PermGen space and I can observe that it slowly
 increases. There are no other webapps deployed, nor any requests to
 tomcat. Is it normal?

So Tomcat, with no webapps, uses more PermGen over time?


 I started to look at this, because customer reported, that with his
 setup, PermGen doubled its size within 3 hours! He runs lambda probe
 webapp and another webapp which makes heavy use of XStream library. I
 googled and found that there are reports related to XStream and PermGen
 issues.

This would be a different issue than if your 6.0.21 has no apps installed.


p

 I wonder if anyone encountered anything similiar?



0x62590808.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: What is the healthy interval length for young gc?

On 1/3/11 1:10 PM, Leon Rosenberg wrote:
 Hello André,
 
 On Mon, Jan 3, 2011 at 1:35 PM, André Warnier a...@ice-sa.com wrote:
 Leon Rosenberg wrote:
 I understand that this is a very application specific issue, but I'm
 wondering which interval is perceived as 'healthy' for young
 collections?
 I have one customer's system which, at peak time, performs a young gc
 every 15 seconds. Parallel the response time goes incredibly high (30
 seconds).

 So my questions are:

 Could it be that the long liveness of the objects in the young space,
 combined with often young collections lead to heap pollution on the
 old gen, cause request bound objects live to long?

 Do I understand it correctly that the size of the young space doesn't
 influence the collection time (as long as the amount of living objects
 remains the same) and does it make sense to increase the young space
 in our case?

 Here is what I believe to be a nice article :
 http://chaoticjava.com/posts/how-does-garbage-collection-work/

 Of course, we really need Chuck to comment on this.
 But let me tell you what I think, at the risk of stepping on my own fingers
 again.

 I refer to the nice pictures in the above article.

 The symptom that the response time becomes very long, makes me think that it
 is a Major GC that is taking place often, not only a Minor GC.  I don't
 think that a Minor GC (involving only the new Heap area) suspends the
 applications, while a Major GC does.
 
 Nope. I mean we know that we have pauses (70 seconds) when the major
 gc occurs, and we know, where it comes from, and we are fighting it,
 but this is not the symptom ;-)
 
 

 If Major GC's are taking place often, then it must mean that despite the
 regular copying from the From to the To parts of the new generation (by
 the Minor GCs), the JVM is running out of space on the new gen part, and
 therefore has to do a Major GC to move things to the old gen.
 
 Actually no, in my understanding both are independent. I mean the gc
 doesn't start to copy over if young is full, it simply cleans young.
 However,
 to quote your article: Old generation objects are objects that
 survived a few collections in the young generation area, and if
 objects managed to survive longer as they should in the young space,
 they might have been copied to old gen, despite the fact, that they
 are young generation objects by nature (meaning short lifetime). This
 theory is what I'm trying to check.

Objects which survive collections in young generations will make their
way into the old generation, and then sit around for a long time waiting
to be collected.

What are your memory settings currently and how are the generations divided?

How many processors do you have available and are you using CMS 
incremental mode?


p

 So I would increase the Heap as a whole, and let Java determine the proper
 split between the parts.  And of course you can monitor what really happens,
 using a number of tools (like jconsole).
 
 No we can't, because it would also increase the time for full gc,
 which will stop the application for even longer (causing enough
 headache already :-()
 
 but anyway thanks for the suggestions ;-)
 
 regards
 Leon
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 



0x62590808.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: Tomcat(5.5) Clustering and Load Balancing.

On 1/3/11 9:40 AM, Harsimranjit singh Kler wrote:
 using tomcat instances only(balancer Feature) 

Why?

http://tomcat.apache.org/tomcat-5.5-doc/balancer-howto.html#Using_the_balancer_webapp

This is a simple implementation of a rules-based load balancer. It was
not designed as a replacement for other load-balancing mechanisms used
for high traffic environments.

IMHO I'd suggest that it's not suitable for most environments.

Just use HTTPD and mod_jk.


p


0x62590808.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: Tomcat uses more and more PermGen space

2011-01-03 Thread Mikolaj Rydzewski



On Mon, 03 Jan 2011 14:02:20 +, Pid p...@pidster.com wrote:


Windows XP
Java 1.6.0_22
Vanilla Tomcat 6.0.21


Are you sure it's 6.0.21?  This version was not released.

If you're using it in production you know what I'm going to suggest 
you

do, right?


I misread console logs. Tomcat version is 6.0.29. It runs on JDK 
6.0_21. I used apache-tomcat-6.0.29.exe installer bundled by apache 
team.


I use jconsole to monitor PermGen space and I can observe that it 
slowly

increases. There are no other webapps deployed, nor any requests to
tomcat. Is it normal?


So Tomcat, with no webapps, uses more PermGen over time?


Yes.

This would be a different issue than if your 6.0.21 has no apps 
installed.


I have no access to production environment now. I wanted to check 
whether lambda webapp causes problem or no. PermGen was increasing faste 
with lambda deployed, but it does still increase with no webapps!


--
Mikolaj Rydzewski m...@ceti.pl

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

RE: Tomcat uses more and more PermGen space

 From: Mikolaj Rydzewski [mailto:m...@ceti.pl] 
 Subject: Tomcat uses more and more PermGen space

 While investigating OOM issue I discovered, that Tomcat instantly 
 uses more and more PermGen space.

I suspect you're not using the word instantly appropriately here...

PermGen can steadily increase if there's something in your environment that 
creates new, typically anonymous, classes as part of its operation.  PermGen 
will not decrease until a full GC occurs, which won't happen unless either the 
old gen or PermGen fills up (or a full GC is forced).

Simple increased usage of PermGen is *not* necessarily indicative of a memory 
leak, but not returning to a stable value *after* a full GC would be.

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

Re: multipart/form-data support

On 1/3/11 3:06 AM, Pankaj Tiwari wrote:
 I have been trying to send multipart/form-data to the server. I have found
 that the request never reaches the server.

Doesn't sound like a Tomcat problem to me then...

 This is my client code, if I am missing something core in here.
 
 public static void main(String args[])
 {
 try
 {
 URL url = new URL(SERVERURL);
 HttpURLConnection con = (HttpURLConnection)
 url.openConnection();
 
 con.setDoInput(true);
 con.setDoOutput(true);
 con.setUseCaches(false);
 
 con.setRequestProperty(Content-Type,
 multipart/form-data;boundary= + BOUNDARY);
 con.setRequestMethod(POST);

Why are you using keep alive?

 con.setRequestProperty(Connection, Keep-Alive);
 
 OutputStream out = con.getOutputStream();

Why are you using a DataOutputStream?

 DataOutputStream oos = new DataOutputStream(out);
 oos.writeBytes(TWOHYPHENS + BOUNDARY + LINEEND);
 oos.writeBytes(Content-Disposition: form-data; name=\name\ +
 LINEEND);
 oos.writeBytes(LINEEND);
 oos.write(HI.getBytes(UTF-8));
 oos.writeBytes(LINEEND);
 oos.writeBytes(TWOHYPHENS + BOUNDARY + TWOHYPHENS + LINEEND);
 oos.flush();
 con.connect();

Why are you connecting after you've attempted to write data?


p

 oos.close();
 }
 catch (MalformedURLException e)
 {
 e.printStackTrace();
 }
 catch (IOException e)
 {
 e.printStackTrace();
 }
 }
 
 Thanks,
 Pankaj
 



0x62590808.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

RE: Tomcat uses more and more PermGen space

2011-01-03 Thread Mikolaj Rydzewski



On Mon, 3 Jan 2011 08:13:20 -0600, Caldarale, Charles R 
chuck.caldar...@unisys.com wrote:



I suspect you're not using the word instantly appropriately here...


You're right, should be constantly rather.


PermGen can steadily increase if there's something in your
environment that creates new, typically anonymous, classes as part of
its operation.  PermGen will not decrease until a full GC occurs,
which won't happen unless either the old gen or PermGen fills up (or 
a

full GC is forced).

Simple increased usage of PermGen is *not* necessarily indicative of
a memory leak, but not returning to a stable value *after* a full GC
would be.


I thought, that PermGen data cannot be garbage collected...

--
Mikolaj Rydzewski m...@ceti.pl

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

RE: What is the healthy interval length for young gc?

 From: André Warnier [mailto:a...@ice-sa.com] 
 Subject: Re: What is the healthy interval length for young gc?

 I don't think that a Minor GC (involving only the new Heap 
 area) suspends the applications, while a Major GC does.

Not true; a minor GC does suspend the mutator threads, just not for very long.  
Even when using concurrent mark-sweep, the app's threads are stopped, but just 
for very, very brief periods.

 the JVM is running out of space on the new gen part, and therefore 
 has to do a Major GC to move things to the old gen.

The sample traces do not show that occurring.

 By increasing the space on the new gen alone, you may make Minor 
 GC's less frequent.

And by specifying fixed sizes for generations, you can upset the balance 
between old and new, and prevent the GC logic from adjusting the ratios for the 
current workload characteristics.

 I do not think that the fact of copying the objects from the new 
 gen to the old gen causes the objects to live too long.  They 
 live long because they are still being referenced somewhere and
 thus cannot be forgotten.

This part is true.

Given the relatively short duration of the minor GC operations relative to the 
observed response time, I suspect that something else is going on during the 
period that may be causing a spike in heap usage and the slowdown - but that 
can't be proven without more data about exactly what's going on.  Looking at 
the heap usage visually will help: are you seeing a regular sawtooth pattern, 
or does heap usage remain fairly flat and then suddenly spike?

 - 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: GeoServer on Tomcat

On 1/3/11 4:05 AM, Deepak Pal wrote:
 Hye Guys,
 
 I have  a web based application which is getting it's Geo-spatial data
 from Geo-Server and the Geo-
 Server is deployed on Tomcat I want to scale this web application by
 using Scalr scalability framework .
 
 My configuration in scalr framework .
 
 1. Front-end NginX Load-Balancer
 2. Application Server (Tomcat + Geo-Server)
 
 Will this combination provide a good scalability for my web application.
 
 What is your suggestion about this and if you have any Idea about scalr
 then plz. tell me . I will be very helpful to you for this .

Perhaps you'd be looking for the Scalr mailing list, rather than the
Tomcat one?


p


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



0x62590808.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: Encoding Issue on POST

On 1/3/11 7:17 AM, André Warnier wrote:
 Try the following : in your form tag, add the attribute
 
 enctype=multipart/form-data
 
 and try again.

Is it possible to include charset attribute?

 enctype=multipart/form-data;charset=UTF-8


p


0x62590808.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

RE: Tomcat uses more and more PermGen space

 From: Mikolaj Rydzewski [mailto:m...@ceti.pl] 
 Subject: RE: Tomcat uses more and more PermGen space

 I thought, that PermGen data cannot be garbage collected...

I don't know what idiot started that rumor, but it has never been true - unless 
you change the GC settings to utilize one of the optional collectors and fail 
to enable class collection at the same time.

You didn't mention any GC-related settings you have for the JVM; posting those 
would be of interest.

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

Re: What is the healthy interval length for young gc?

Leon Rosenberg wrote:

If Major GC's are taking place often, then it must mean that despite the
regular copying from the From to the To parts of the new generation (by
the Minor GCs), the JVM is running out of space on the new gen part, and
therefore has to do a Major GC to move things to the old gen.

Actually no, in my understanding both are independent. I mean the gc
doesn't start to copy over if young is full, it simply cleans young.
However,
to quote your article: Old generation objects are objects that
survived a few collections in the young generation area, and if
objects managed to survive longer as they should in the young space,
they might have been copied to old gen, despite the fact, that they
are young generation objects by nature (meaning short lifetime). This
theory is what I'm trying to check.

I admit my earlier poor phrasing.
Another re :
http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html#1.1.Introduction|outline
and particularly sections 4.2 and 5.

According to that, the old gen (better named as tenured I guess) gets
collected by a
Major GC when it needs to be (because it has run out of space).
So it is indeed independent of the minor GCs, in the sense that it is not triggered by it
directly.

But, it is reasonable to assume that it runs out of space because objects are
moved there
from the new gen, when ditto objects have survived a certain time in the
new gen.
(I believe that this certain time is measured in terms of Minor GCs, rather than really
a number of seconds).

It also says : If survivor spaces are too small, copying collection overflows directly
into the tenured generation.

So basically, I would say that it boils down (almost) to the same thing.

Scenario :
- the applications create new objects at a furious rate
- the new gen fills up rapidly
- a minor GC is triggered when new is sufficiently full
The minor GC copies live objects from Eden+From, to To, and conveniently forgets dead
ones.
- at the same time (?), the minor GC also copies objects which have survided more than n
minor GCs, to the old gen. OR, if survivor spaces are too small, then the copying also
moves objects directly to the old gen (I take that as meaning independently of whether
they have survived n minor GCs or not).

- the old gen fills up. When it reaches a certain level, this triggers a
major GC.

So yes, it would seem that if you increase the new gen alone, this may increase the time
before a minor GC happens, thus making it so that objects in the new gen will stay
longer there, thus increase the chance that they will die there, before they ever have
to be moved to old gen.

At least if most of these objects are finally of the short-lived type.

I really suggest that you read the article sections above. They also contain some data
about different Garbage Collectors and when to use them. One of these cases may apply to you.
One would need to find the corresponding Java 1.6 version, but I am particularly intrigued
by what it says about the Troughput collector and multiple processors (which they all
tend to be these days).

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

Re: What is the healthy interval length for young gc?

On Mon, Jan 3, 2011 at 3:10 PM, Pid p...@pidster.com wrote:
 On 1/3/11 1:10 PM, Leon Rosenberg wrote:
 Actually no, in my understanding both are independent. I mean the gc
 doesn't start to copy over if young is full, it simply cleans young.
 However,
 to quote your article: Old generation objects are objects that
 survived a few collections in the young generation area, and if
 objects managed to survive longer as they should in the young space,
 they might have been copied to old gen, despite the fact, that they
 are young generation objects by nature (meaning short lifetime). This
 theory is what I'm trying to check.

 Objects which survive collections in young generations will make their
 way into the old generation, and then sit around for a long time waiting
 to be collected.

Hello pid-ster,



 What are your memory settings currently and how are the generations divided?

-Xmx12G
-Xms12G
-XX:PermSize=128M
-XX:MaxPermSize=256M
-XX:+DisableExplicitGC
-verbose:GC
-XX:+PrintGCDetails
-XX:+PrintGCDateStamps
-Xloggc:/.../tomcat/logs/gc_tomcat.log

jmap says:

Attaching to process ID 16969, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 14.2-b01

using thread-local object allocation.
Parallel GC with 6 thread(s)

Heap Configuration:
   MinHeapFreeRatio = 40
   MaxHeapFreeRatio = 70
   MaxHeapSize  = 12884901888 (12288.0MB)
   NewSize  = 2686976 (2.5625MB)
   MaxNewSize   = 17592186044415 MB
   OldSize  = 5439488 (5.1875MB)
   NewRatio = 2
   SurvivorRatio= 8
   PermSize = 134217728 (128.0MB)
   MaxPermSize  = 268435456 (256.0MB)

Heap Usage:
PS Young Generation
Eden Space:
   capacity = 4074897408 (3886.125MB)
   used = 1509410704 (1439.4862213134766MB)
   free = 2565486704 (2446.6387786865234MB)
   37.04168603206219% used
From Space:
   capacity = 110755840 (105.625MB)
   used = 47330080 (45.137481689453125MB)
   free = 63425760 (60.487518310546875MB)
   42.73371047522189% used
To Space:
   capacity = 109314048 (104.25MB)
   used = 0 (0.0MB)
   free = 109314048 (104.25MB)
   0.0% used
PS Old Generation
   capacity = 8589934592 (8192.0MB)
   used = 6636110912 (6328.688537597656MB)
   free = 1953823680 (1863.3114624023438MB)
   77.25449874997139% used
PS Perm Generation
   capacity = 268435456 (256.0MB)
   used = 228667664 (218.07447814941406MB)
   free = 39767792 (37.92552185058594MB)
   85.18534302711487% used




 How many processors do you have available and are you using CMS 
 incremental mode?

vm with 6 assigned cores and no to both.


I also might add, that the amount of free space right now is much
higher as during the peak times, when its usually below 1GB (more
sessions, more caches).

regards
Leon

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

Comet and multipart

2011-01-03 Thread sol myr

Hi,

We're implementing a CometServlet on top of Tomcat NIO connector, using long 
polling.
Currently we're using the approach recommended by most tutorials: the client 
opens a connection and waits for a message (for a configured timeout); if such 
a message arrives, the client consumes it (e.g. presents it on screen), then 
*closes* the http connection, and opens a new connection (to wait for the next 
message).

Unfortunately, we have a network performance problem with opening and closing 
connections (our 3rd party proxy is good at keeping connections alive, but is 
slow in negotiating new connections).

So we'd like to keep the HTTP connection alive, and pass multiple messages on 
the same connection. We were hoping to tell the messages apart based on 
multipart format, or some other separator, or content length.

Could anyone please tell whether that's supported on the TomcatServlet side? 
If so, could you please refer me to the appropriate documentation?
In particular, is there some flag (on Tomcat or CometServlet) telling it to 
support multipart?

Thanks :)

RE: What is the healthy interval length for young gc?

 From: André Warnier [mailto:a...@ice-sa.com] 
 Subject: Re: What is the healthy interval length for young gc?

 But, it is reasonable to assume that it runs out of space 
 because objects are moved there from the new gen, when 
 ditto objects have survived a certain time in the new gen.
 (I believe that this certain time is measured in terms of
 Minor GCs, rather than really a number of seconds).

This is correct.  Also, objects may be directly allocated in the old gen 
portion of the heap if they are too large for the young gen; this is a wrinkle 
that can cause havoc if the app allocates excessively large arrays (among other 
things).

 - 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: What is the healthy interval length for young gc?

Hello Chuck,

On Mon, Jan 3, 2011 at 3:23 PM, Caldarale, Charles R
chuck.caldar...@unisys.com wrote:
 By increasing the space on the new gen alone, you may make Minor
 GC's less frequent.

 And by specifying fixed sizes for generations, you can upset the balance 
 between old and new, and prevent the GC logic from adjusting the ratios for 
 the current workload characteristics.

Generally, yes. But I cannot increase the old gen anymore, because it
will slow down the gc by another 10 seconds (we got 10 seconds from
last increase by 2GB) and this will let all the tomcats to drop out of
the lb pool. So I only have the option to increase the 'new' space,
which I'm investigating.


 I do not think that the fact of copying the objects from the new
 gen to the old gen causes the objects to live too long.  They
 live long because they are still being referenced somewhere and
 thus cannot be forgotten.

 This part is true.

Well that depends on the definition of 'long' isn't it? Usually I
would expect (and hope) that all request-bound objects (beans,
modelmap parts, tag instances, byte arrays) gets collected with the
next minor gc run after the request is finished. I have the feeling
that this is not the case.


 Given the relatively short duration of the minor GC operations relative to 
 the observed response time, I suspect that something else is going on during 
 the period that may be causing a spike in heap usage and the slowdown - but 
 that can't be proven without more data about exactly what's going on.  
 Looking at the heap usage visually will help: are you seeing a regular 
 sawtooth pattern, or does heap usage remain fairly flat and then suddenly 
 spike?

A regular sawtooth which gets more intense in peak times.
Unfortunately we see a lot of other indicators increase (used threads
near limit, number of apache processes increases, eth traffic
increases and so on). It's hard to say which one is symptom and which
one is the root.
The most irritating thing of all is that the commited memory of the
linux vm is making a huge (12GB) leap to the top. This one I can't
explain at all ;-)

regards
Leon

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

Re: multipart/form-data support

2011-01-03 Thread Pankaj Tiwari

1. Keep-Alive - I am not sure if that should cause any issues here.
2. The request never reaches the server. I have tried without the last
connect as well but nothing seems to work here.

When I run this piece of code, I do not get any exceptions or error on the
client side but the request does not seems to be reaching the server.
(doGet/doPost methods are never called).

Q1. How can i debug if the request is being sent from the java client at
all? If it had been a browser, I could have used a header monitoring plugin
but not sure about java application
Q2. Is there any chance that tomcat does not support or ignores such request
(multipart file-data)?

On Mon, Jan 3, 2011 at 7:53 PM, Pid p...@pidster.com wrote:

 On 1/3/11 3:06 AM, Pankaj Tiwari wrote:
  I have been trying to send multipart/form-data to the server. I have
 found
  that the request never reaches the server.

 Doesn't sound like a Tomcat problem to me then...

  This is my client code, if I am missing something core in here.
 
  public static void main(String args[])
  {
  try
  {
  URL url = new URL(SERVERURL);
  HttpURLConnection con = (HttpURLConnection)
  url.openConnection();
 
  con.setDoInput(true);
  con.setDoOutput(true);
  con.setUseCaches(false);
 
  con.setRequestProperty(Content-Type,
  multipart/form-data;boundary= + BOUNDARY);
  con.setRequestMethod(POST);

 Why are you using keep alive?

  con.setRequestProperty(Connection, Keep-Alive);
 
  OutputStream out = con.getOutputStream();

 Why are you using a DataOutputStream?

  DataOutputStream oos = new DataOutputStream(out);
  oos.writeBytes(TWOHYPHENS + BOUNDARY + LINEEND);
  oos.writeBytes(Content-Disposition: form-data;
 name=\name\ +
  LINEEND);
  oos.writeBytes(LINEEND);
  oos.write(HI.getBytes(UTF-8));
  oos.writeBytes(LINEEND);
  oos.writeBytes(TWOHYPHENS + BOUNDARY + TWOHYPHENS + LINEEND);
  oos.flush();
  con.connect();

 Why are you connecting after you've attempted to write data?


 p

  oos.close();
  }
  catch (MalformedURLException e)
  {
  e.printStackTrace();
  }
  catch (IOException e)
  {
  e.printStackTrace();
  }
  }
 
  Thanks,
  Pankaj
 




-- 
Pankaj Tiwari

Re: Encoding Issue on POST


Pid wrote:

On 1/3/11 7:17 AM, André Warnier wrote:

Try the following : in your form tag, add the attribute

enctype=multipart/form-data

and try again.


Is it possible to include charset attribute?

 enctype=multipart/form-data;charset=UTF-8



I don't think so.
You can specify

acceptCharset=xxx

but that only determines what kind of input the form should accept.
Unfortunately, nothing forces the browser to send a charset indication for 
what it sends.
It should always do that when there is a body, but most browsers don't.
It's a real pita.
Even for multipart/form-data, they don't provide it in the parts, usually.
This whole area is full of holes, which is why you may need things like URIencoding and 
the charset filter.




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

RE: multipart/form-data support

 From: Pankaj Tiwari [mailto:panky.tiw...@gmail.com] 
 Subject: Re: multipart/form-data support

 2. The request never reaches the server.

Then it can't be a Tomcat issue, can it?

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

Re: isapi_redirector.dll Problems - Bad Gateway?


Yes, I'm still getting those error messages in the isapi_connector log.

I don't think the application installs a standard tomcat installation. 
Basically, I have a directory in the program files folder called Atlassian
then under that I have JIRA 4.2.  In that directory I have lots of folders
and one of them is conf and that is where my server.xml file is and some
other files.  So, I'm not sure how I would test what you were suggesting.


awarnier wrote:
 
 amythyst wrote:
 Sorry for all the posts... I have a specific question... I'm reading the
 isapi_redirector.log which shows the errors... it says things like this:
 
  shutting down the read side of socket 576 [127.0.0.1:1145 -
 127.0.0.1:8009]
 
 To me, it seems like its trying to connect to tomcat on 127.0.0.1:8009
 but
 tomcat is listening on 0.0.0.0:8009 ... does that make a difference?
 
 No.  The 0.0.0.0:8009 essentially means that the Tomcat AJP connector is
 listening on port 
 8009, for /all/ this hosts's IP addresses.
 127.0.0.1 happens to be one of these addresses, the one corresponding to
 the loopback 
 connection, fom this host to this host (and only valid for local
 in-same-host connections).
 
 To pick up on the previous exchange:
 - we have thus established that Tomcat is listening, with an AJP
 connector, on port 8009.
 
 In isolation, the message above does not tell us much, except that it
 seems that some 
 process at least was having a connection with that Tomcat AJP port.  And
 if you found that 
 line in the isapi_redirector log, then it must be that it was the
 isapi_redirector which 
 had that connection, then.
 
 Mmm, the plot thickens.
 
 I have to scroll back a little, to your first post(s), to find out what
 isn't working.
 ...
 Are you still getting messages such as these ?
 
 [Thu Dec 16 11:20:10.559 2010] [1508:1800] [error]
 ajp_get_reply::jk_ajp_common.c (2058): (worker1) Tomcat is down or refused
 connection. No response has been sent to the client (yet)
 
 [Thu Dec 16 11:20:10.559 2010] [1508:1800] [info]
 ajp_service::jk_ajp_common.c (2543): (worker1) sending request to tomcat
 failed (recoverable), because of protocol error (attempt=1)
 
 [Thu Dec 16 11:20:10.559 2010] [1508:1800] [debug]
 ajp_service::jk_ajp_common.c (2400): retry 1, sleeping for 100 ms before
 retrying
 
 [Thu Dec 16 11:20:10.668 2010] [1508:1800] [debug]
 ajp_send_request::jk_ajp_common.c (1572): (worker1) all endpoints are
 disconnected.
 
 [Thu Dec 16 11:20:10.668 2010] [1508:1800] [debug]
 jk_open_socket::jk_connect.c (484): socket TCP_NODELAY set to On
 
 
 
 Ok, let's do something :
 
 a) under the Tomcat top directory, there is a directory called webapps
 (under which 
 presumably you already have a subdirectory called jira).
 At the same level as jira, create another directory called test, and
 copy some html 
 file into it, which you will rename as test.html
 So you will have :
 tomcat_top_dir/webapps/
jira/
(many files)
test/
 test.html
 
 b) in your uriworkermap.properties file, add the line
 
 /test/*=worker1
 
 c) then restart Tomcat and IIS
 
 d) then from a browser, try to access :
 
 d1) http://yourhostname:8081/test/test.html
 (where 8081 is the port on which Tomcat listens with its HTTP protocol
 connector)
 
 d2) http://yourhostname:80/test/test.html
 (where 80) is the port on which IIS is listening)
 
 Do both work and show the page test.html ?
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 
 
 

-- 
View this message in context: 
http://old.nabble.com/isapi_redirector.dll-Problems---Bad-Gateway--tp30500400p30578705.html
Sent from the Tomcat - User mailing list archive at Nabble.com.


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

Re: isapi_redirector.dll Problems - Bad Gateway?


amythyst wrote:

Yes, I'm still getting those error messages in the isapi_connector log.

I don't think the application installs a standard tomcat installation. 
Basically, I have a directory in the program files folder called Atlassian

then under that I have JIRA 4.2.  In that directory I have lots of folders
and one of them is conf and that is where my server.xml file is and some
other files.  So, I'm not sure how I would test what you were suggesting.


That also makes it quite difficult for someone here to help you, because we have no idea 
what is where and what changes have been made as compared to a standard configuration.

But Atlassian is a commercial product, no ?
Do they not offer any kind of support ?


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

Re: isapi_redirector.dll Problems - Bad Gateway?

They do not offer any support with getting their application to work
externally. They provide an online walkthrough document which is here:
http://confluence.atlassian.com/display/JIRA/Integrating+JIRA+with+IIS

And that is how I and the network guy set it up however, as you know, it
isn't working. I have tried every avenue to fix this and you guys are kinda
my last hope. :) I have been trying to fix this for over a month and I
can't figure it out.

awarnier wrote:

amythyst wrote:
Yes, I'm still getting those error messages in the isapi_connector log.

I don't think the application installs a standard tomcat installation.
Basically, I have a directory in the program files folder called
Atlassian
then under that I have JIRA 4.2. In that directory I have lots of
folders
and one of them is conf and that is where my server.xml file is and some
other files. So, I'm not sure how I would test what you were suggesting.

That also makes it quite difficult for someone here to help you, because
we have no idea
what is where and what changes have been made as compared to a standard
configuration.
But Atlassian is a commercial product, no ?
Do they not offer any kind of support ?

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

--
View this message in context:
http://old.nabble.com/isapi_redirector.dll-Problems---Bad-Gateway--tp30500400p30578822.html
Sent from the Tomcat - User mailing list archive at Nabble.com.

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

Re: isapi_redirector.dll Problems - Bad Gateway?


Woo  I fixed it!  I changed the listener port from 8009 to 8010!  And
now it works!  Thank you guys so much for the assistance and the guidance.
:)

awarnier wrote:
 
 amythyst wrote:
 Yes, I'm still getting those error messages in the isapi_connector log.
 
 I don't think the application installs a standard tomcat installation. 
 Basically, I have a directory in the program files folder called
 Atlassian
 then under that I have JIRA 4.2.  In that directory I have lots of
 folders
 and one of them is conf and that is where my server.xml file is and some
 other files.  So, I'm not sure how I would test what you were suggesting.
 
 
 That also makes it quite difficult for someone here to help you, because
 we have no idea 
 what is where and what changes have been made as compared to a standard
 configuration.
 But Atlassian is a commercial product, no ?
 Do they not offer any kind of support ?
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 
 
 

-- 
View this message in context: 
http://old.nabble.com/isapi_redirector.dll-Problems---Bad-Gateway--tp30500400p30578925.html
Sent from the Tomcat - User mailing list archive at Nabble.com.


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

Re: isapi_redirector.dll Problems - Bad Gateway?


amythyst wrote:

They do not offer any support with getting their application to work
externally.  They provide an online walkthrough document which is here: 
http://confluence.atlassian.com/display/JIRA/Integrating+JIRA+with+IIS


And that is how I and the network guy set it up however, as you know, it
isn't working.  I have tried every avenue to fix this and you guys are kinda
my last hope. :)  I have been trying to fix this for over a month and I
can't figure it out.  


Ah well, some of us like the desperate cases.
Let's back up a bit.

You mentioned that you found a conf directory somewhere.
There should be a server.xml file in there.
Have you posted here already ?
If not, can you *paste* the content into a message to the list, after removing all the 
comment parts, and all private info such as hostnames or passwords.


Also, a layout of the directories that you find at the same level as that conf directory 
would help.  Something like :


Atlassian
Jira
  conf
  xyz ?

etc..

Thanks

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

Re: Tomcat uses more and more PermGen space

On 1/3/11 2:13 PM, Mikolaj Rydzewski wrote:
 So Tomcat, with no webapps, uses more PermGen over time?
 
 Yes.

My 6.0.29 doesn't.  It just sits there using ~18Mb of PermGen.

No webapps, or just the example webapps?  Is there any traffic to the
Tomcat instance?


p


0x62590808.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: Comet and multipart

2011-01-03 Thread Mark Thomas

On 03/01/2011 14:48, sol myr wrote:
 Hi,
 
 We're implementing a CometServlet on top of Tomcat NIO connector, using long 
 polling.
 Currently we're using the approach recommended by most tutorials: the client 
 opens a connection and waits for a message (for a configured timeout); if 
 such a message arrives, the client consumes it (e.g. presents it on screen), 
 then *closes* the http connection, and opens a new connection (to wait for 
 the next message).
 
 Unfortunately, we have a network performance problem with opening and closing 
 connections (our 3rd party proxy is good at keeping connections alive, but is 
 slow in negotiating new connections).
 
 So we'd like to keep the HTTP connection alive, and pass multiple messages on 
 the same connection. We were hoping to tell the messages apart based on 
 multipart format, or some other separator, or content length.
 
 Could anyone please tell whether that's supported on the TomcatServlet side? 
 If so, could you please refer me to the appropriate documentation?
 In particular, is there some flag (on Tomcat or CometServlet) telling it to 
 support multipart?

That is going to require some custom coding on your part.

Mark

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

Re: Comet and multipart

2011-01-03 Thread Filip Hanik - Dev Lists


On 1/3/2011 7:48 AM, sol myr wrote:

Hi,

We're implementing a CometServlet on top of Tomcat NIO connector, using long 
polling.
Currently we're using the approach recommended by most tutorials: the client 
opens a connection and waits for a message (for a configured timeout); if such 
a message arrives, the client consumes it (e.g. presents it on screen), then 
*closes* the http connection, and opens a new connection (to wait for the next 
message).

Unfortunately, we have a network performance problem with opening and closing 
connections (our 3rd party proxy is good at keeping connections alive, but is 
slow in negotiating new connections).

So we'd like to keep the HTTP connection alive, and pass multiple messages on 
the same connection. We were hoping to tell the messages apart based on 
multipart format, or some other separator, or content length.

Could anyone please tell whether that's supported on the TomcatServlet side?

yes, it is supported, as long as your client knows how to do it. On the 
server/servlet side, all you do is read the input stream byte by byte
you can create any type of protocol rules inside the HTTP message that it sends 
up
best
Filip


If so, could you please refer me to the appropriate documentation?
In particular, is there some flag (on Tomcat or CometServlet) telling it to support 
multipart?

Thanks :)






-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1191 / Virus Database: 1435/3355 - Release Date: 01/02/11



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

[OT] Re: multipart/form-data support

On 1/3/11 2:55 PM, Pankaj Tiwari wrote:
 1. Keep-Alive - I am not sure if that should cause any issues here.

Why set it if you're not reusing the connection?

 2. The request never reaches the server. I have tried without the last
 connect as well but nothing seems to work here.

Check the response status code: con.getResponseCode()

 When I run this piece of code, I do not get any exceptions or error on the
 client side but the request does not seems to be reaching the server.
 (doGet/doPost methods are never called).
 
 Q1. How can i debug if the request is being sent from the java client at
 all? If it had been a browser, I could have used a header monitoring plugin
 but not sure about java application

GIYF: Wireshark.

 Q2. Is there any chance that tomcat does not support or ignores such request
 (multipart file-data)?

Tomcat doesn't care what the body of the request looks like.


p

 On Mon, Jan 3, 2011 at 7:53 PM, Pid p...@pidster.com wrote:
 
 On 1/3/11 3:06 AM, Pankaj Tiwari wrote:
 I have been trying to send multipart/form-data to the server. I have
 found
 that the request never reaches the server.

 Doesn't sound like a Tomcat problem to me then...

 This is my client code, if I am missing something core in here.

 public static void main(String args[])
 {
 try
 {
 URL url = new URL(SERVERURL);
 HttpURLConnection con = (HttpURLConnection)
 url.openConnection();

 con.setDoInput(true);
 con.setDoOutput(true);
 con.setUseCaches(false);

 con.setRequestProperty(Content-Type,
 multipart/form-data;boundary= + BOUNDARY);
 con.setRequestMethod(POST);

 Why are you using keep alive?

 con.setRequestProperty(Connection, Keep-Alive);

 OutputStream out = con.getOutputStream();

 Why are you using a DataOutputStream?

 DataOutputStream oos = new DataOutputStream(out);
 oos.writeBytes(TWOHYPHENS + BOUNDARY + LINEEND);
 oos.writeBytes(Content-Disposition: form-data;
 name=\name\ +
 LINEEND);
 oos.writeBytes(LINEEND);
 oos.write(HI.getBytes(UTF-8));
 oos.writeBytes(LINEEND);
 oos.writeBytes(TWOHYPHENS + BOUNDARY + TWOHYPHENS + LINEEND);
 oos.flush();
 con.connect();

 Why are you connecting after you've attempted to write data?


 p

 oos.close();
 }
 catch (MalformedURLException e)
 {
 e.printStackTrace();
 }
 catch (IOException e)
 {
 e.printStackTrace();
 }
 }

 Thanks,
 Pankaj



 
 



0x62590808.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: isapi_redirector.dll Problems - Bad Gateway?

2011-01-03 Thread Michael Ludwig

amythyst schrieb am 03.01.2011 um 07:36 (-0800):
 
 Woo  I fixed it!  I changed the listener port from 8009 to
 8010!  And now it works!

Congrats.

The worker.properties you posted last year, however, read as follows:

| worker.worker1.type=ajp13
| worker.worker1.host=localhost
| worker.worker1.port=8009

But then, that was last year. ;-)

-- 
Michael Ludwig

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

Re: isapi_redirector.dll Problems - Bad Gateway?


Yup you are correct.  It was 8009.  And changing the port to 8010 seems to
have resolved it.  But I'm not sure why this has fixed it.

I changed the port in the worker.properties and the server.xml


Michael Ludwig-6 wrote:
 
 amythyst schrieb am 03.01.2011 um 07:36 (-0800):
 
 Woo  I fixed it!  I changed the listener port from 8009 to
 8010!  And now it works!
 
 Congrats.
 
 The worker.properties you posted last year, however, read as follows:
 
 | worker.worker1.type=ajp13
 | worker.worker1.host=localhost
 | worker.worker1.port=8009
 
 But then, that was last year. ;-)
 
 -- 
 Michael Ludwig
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 
 
 

-- 
View this message in context: 
http://old.nabble.com/isapi_redirector.dll-Problems---Bad-Gateway--tp30500400p30579733.html
Sent from the Tomcat - User mailing list archive at Nabble.com.


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

Re: isapi_redirector.dll Problems - Bad Gateway?

2011-01-03 Thread Michael Ludwig

amythyst schrieb am 03.01.2011 um 09:15 (-0800):
 
 Yup you are correct.  It was 8009.  And changing the port to 8010
 seems to have resolved it.  But I'm not sure why this has fixed it.

Unfavourable firewall configuration?

-- 
Michael Ludwig

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

Re: Encoding Issue on POST

2011-01-03 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

André,

On 1/2/2011 7:38 AM, André Warnier wrote:
 Well, I would say that by removing the filter nothing changes, then that
 proves at least that the filter is useless, doesn't it ?

Or that it wasn't actually being used. The filter does have some utility
given:

1. Many web browsers submit POST requests without a Content-Type
character encoding :(
2. The default request body encoding is ISO-8859-1 per spec

If the web app can guarantee that the POST data will be UTF-8 (using
UTF-8 encoding in prior-response and in FORM accept-charset), use of the
aforementioned filter is recommended technique.

 Actually, maybe not.  From what I understand of the filter code, it only
 sets the request's character encoding if it is not already set. (It does
 not do any character translation itself).

Yes and no: no actual translation is being done... it's just telling the
container how to do the translation. But, the OP has force set to
true, which means that if the client /does/ send a charset, it will be
overridden (which is pretty much a terrible idea).

 And, if your form and your browser do their job, the request encoding
 should already be set, to UTF-8.

Yes, but many do not do this, even the well-behaved ones like ff and chrome.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0iCVoACgkQ9CaO5/Lv0PDrjACfUAsd3hiGbyO85dpzXDg/NkNK
grQAn2A/iiyKMxk4uLgeiAN72cg0yG2z
=hYE2
-END PGP SIGNATURE-

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

Re: multipart/form-data support

2011-01-03 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Pankaj,

On 1/2/2011 10:06 PM, Pankaj Tiwari wrote:
 I have been trying to send multipart/form-data to the server. I have found
 that the request never reaches the server.

How are you checking to see if it reaches the server?

 This is my client code, if I am missing something core in here.
 
 public static void main(String args[])
 {
 try
 {
 URL url = new URL(SERVERURL);

What is SERVERURL?

 con.setDoInput(true);
 con.setDoOutput(true);

...

 OutputStream out = con.getOutputStream();
 DataOutputStream oos = new DataOutputStream(out);

I agree with Pid: why are you using DataOutputStream?

 oos.writeBytes(TWOHYPHENS + BOUNDARY + LINEEND);

Hmm... write before connect?

 oos.flush();
 con.connect();

Try connecting before writing. Also, try reading the response (you did
setDoInput(true)...).

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0iDnEACgkQ9CaO5/Lv0PD6AQCfctFc2yULc7QkATMx1fAqwe5F
km4AniigJu80/uJ6gl1Kg/6WD1i+rv/I
=KmrY
-END PGP SIGNATURE-

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

Re: isapi_redirector.dll Problems - Bad Gateway?


Yea I don't know... I'm not the network person so I don't have access to see
what is in the firewall.  He told me everything was set up properly in the
firewall and when I changed the port to 8010, we made no changes in the
firewall whatsoever.


Michael Ludwig-6 wrote:
 
 amythyst schrieb am 03.01.2011 um 09:15 (-0800):
 
 Yup you are correct.  It was 8009.  And changing the port to 8010
 seems to have resolved it.  But I'm not sure why this has fixed it.
 
 Unfavourable firewall configuration?
 
 -- 
 Michael Ludwig
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 
 
 

-- 
View this message in context: 
http://old.nabble.com/isapi_redirector.dll-Problems---Bad-Gateway--tp30500400p30580198.html
Sent from the Tomcat - User mailing list archive at Nabble.com.


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

RE: isapi_redirector.dll Problems - Bad Gateway?

 From: amythyst [mailto:roxanne.ga...@deltasolutions.com] 
 Subject: Re: isapi_redirector.dll Problems - Bad Gateway?

 And changing the port to 8010 seems to
 have resolved it.

 I changed the port in the worker.properties and the server.xml

You earlier stated that you changed the listener port to 8010; did you really 
mean Connector?  A listener is something quite different in the world of 
Tomcat.

 - Chuck

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

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

RE: isapi_redirector.dll Problems - Bad Gateway?

Hmm... maybe. :)  I was calling it that because that is the port tomcat is
listening on to forward the requests right?

n828cl wrote:

 From: amythyst [mailto:roxanne.ga...@deltasolutions.com] 
 Subject: Re: isapi_redirector.dll Problems - Bad Gateway?

 And changing the port to 8010 seems to
 have resolved it.

 I changed the port in the worker.properties and the server.xml

 You earlier stated that you changed the listener port to 8010; did you
 really mean Connector?  A listener is something quite different in the
 world of Tomcat.

  - Chuck

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

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

-- 
View this message in context: 
http://old.nabble.com/isapi_redirector.dll-Problems---Bad-Gateway--tp30500400p30580707.html
Sent from the Tomcat - User mailing list archive at Nabble.com.

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

Re: isapi_redirector.dll Problems - Bad Gateway?

amythyst wrote:

Yea I don't know... I'm not the network person so I don't have access to see
what is in the firewall. He told me everything was set up properly in the
firewall and when I changed the port to 8010, we made no changes in the
firewall whatsoever.

Michael Ludwig-6 wrote:

amythyst schrieb am 03.01.2011 um 09:15 (-0800):

Yup you are correct. It was 8009. And changing the port to 8010
seems to have resolved it. But I'm not sure why this has fixed it.

Unfavourable firewall configuration?

Congratulations, and we share your happiness at having resolved the problem.
However, it is always good to know why exactly the problem happened, if only to avoid it
re-appearing at some unexpected future time.

So allow us to continue digging a bit.

I believe that the key must be here, in an answer which you sent previously :

I have the following connector string in my server.xml file:

Connector port=8009 redirectPort=8443 enableLookups=false
protocol=AJP/1.3 URIEncoding=UTF-8/

I will attach the file itself to make sure you guys think it looks ok.

I ran the netstat command you gave me... lots of stuff there! But I do see
this:

TCP 0.0.0.0:80090.0.0.0:0 LISTENING 4

This 8009 port must not have been Tomcat, but something else.
If it is still there now, then try to find out what process number 4 actually is. You
should be able to see that in the Task Manager, if you select the PID column for display.

It should also normally show the name of the executable program, if you really entered the
command as :

netstat -aobn

e.g.

TCP127.0.0.1:1430 127.0.0.1:1429 HERGESTELLT 1092
[komodo.exe]

(maybe you just forgot to copy and paste that second line ?)

On my WinXP laptop for example, I see that process # 4 as [System] :

TCP192.168.245.129:1390.0.0.0:0 ABHÖREN 4
[System]

In retrospect, it looks strange to have a process with PID # 4 on that server, listening
on port 8009. What could it be ?

Also, in the Tomcat logs of when you were still having the Connector listening on port
8009, there must have been error messages when Tomcat started.

(It should not have been able to start that Connector, if the port was not
free).

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

Re: What is the healthy interval length for young gc?

On 1/3/11 2:41 PM, Leon Rosenberg wrote:
 On Mon, Jan 3, 2011 at 3:10 PM, Pid p...@pidster.com wrote:
 On 1/3/11 1:10 PM, Leon Rosenberg wrote:
 Actually no, in my understanding both are independent. I mean the gc
 doesn't start to copy over if young is full, it simply cleans young.
 However,
 to quote your article: Old generation objects are objects that
 survived a few collections in the young generation area, and if
 objects managed to survive longer as they should in the young space,
 they might have been copied to old gen, despite the fact, that they
 are young generation objects by nature (meaning short lifetime). This
 theory is what I'm trying to check.

 Objects which survive collections in young generations will make their
 way into the old generation, and then sit around for a long time waiting
 to be collected.
 
 Hello pid-ster,
 
 

 What are your memory settings currently and how are the generations divided?
 
 -Xmx12G
 -Xms12G
 -XX:PermSize=128M
 -XX:MaxPermSize=256M
 -XX:+DisableExplicitGC
 -verbose:GC
 -XX:+PrintGCDetails
 -XX:+PrintGCDateStamps
 -Xloggc:/.../tomcat/logs/gc_tomcat.log
 
 jmap says:
 
 Attaching to process ID 16969, please wait...
 Debugger attached successfully.
 Server compiler detected.
 JVM version is 14.2-b01
 
 using thread-local object allocation.
 Parallel GC with 6 thread(s)
 
 Heap Configuration:
MinHeapFreeRatio = 40
MaxHeapFreeRatio = 70
MaxHeapSize  = 12884901888 (12288.0MB)
NewSize  = 2686976 (2.5625MB)
MaxNewSize   = 17592186044415 MB
OldSize  = 5439488 (5.1875MB)
NewRatio = 2
SurvivorRatio= 8
PermSize = 134217728 (128.0MB)
MaxPermSize  = 268435456 (256.0MB)
 
 Heap Usage:
 PS Young Generation
 Eden Space:
capacity = 4074897408 (3886.125MB)

used = 1509410704 (1439.4862213134766MB)
free = 2565486704 (2446.6387786865234MB)
37.04168603206219% used
 From Space:
capacity = 110755840 (105.625MB)
used = 47330080 (45.137481689453125MB)
free = 63425760 (60.487518310546875MB)
42.73371047522189% used
 To Space:
capacity = 109314048 (104.25MB)
used = 0 (0.0MB)
free = 109314048 (104.25MB)
0.0% used
 PS Old Generation
capacity = 8589934592 (8192.0MB)
used = 6636110912 (6328.688537597656MB)
free = 1953823680 (1863.3114624023438MB)
77.25449874997139% used
 PS Perm Generation
capacity = 268435456 (256.0MB)
used = 228667664 (218.07447814941406MB)
free = 39767792 (37.92552185058594MB)
85.18534302711487% used

Have you attempted to profile the heap to see what's making it into the
old gen?  (I say attempted because 16G is a lot of heap to profile...)

 How many processors do you have available and are you using CMS 
 incremental mode?
 
 vm with 6 assigned cores and no to both.

Deliberate choice, or just not tried it yet?  If you've got multiple
cores parallel gc is a good idea.

Try something like this:

-XX:+UseParNewGC \
-XX:+UseConcMarkSweepGC \
-XX:+CMSClassUnloadingEnabled \

Incremental mode will take some of the sting out of large collections.

 http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html

-XX:+CMSIncrementalMode \
-XX:+CMSIncrementalPacing \

If you hadn't disabled manual GC...

-XX:+ExplicitGCInvokesConcurrent \

These will output a lot more info.  verbosegc is superceded by
PrintGCDetails, I think.

-XX:+PrintGCDetails \
-XX:+PrintGCTimeStamps \
-XX:+PrintTenuringDistribution \
-XX:-TraceClassUnloading \


p



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



0x62590808.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Handling Comet Timeouts with CometProcessor

2011-01-03 Thread Joe Biron

Hello,

I've been making great progress with CometProcessor on Tomcat 6.0.29.
I have a question about handling timeouts (and I did review this
thread: http://www.mail-archive.com/users@tomcat.apache.org/msg55616.html).

I want my clients to connect and stay connected for a very long time,
but I do need to have my server time the connections out periodically.

When I request.setAttribute(org.apache.tomcat.comet.timeout,
timeout), I do indeed receive a CometEvent.EventType.ERROR, but I can
find no way to gracefully tell the client that everything is OK and I
just want them to back off for a while then reconnect.

When I do this:

...
response.sendError(HttpServletResponse.SC_REQUEST_TIMEOUT, Timed out.
Please reconnect);
response.flushBuffer();
event.close();
...

the client does not receive the response. They only sense an
unceremonious connection close - which, if through routers, may take
quite some time to be detected.

How can I hook into the timeout to send the client a short response
before connection close?

Is there a better way to do this? Should my application handle these
timeouts, and use the comet.timeout as a longer safety net?

Much appreciated.

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

Re: multipart/form-data support

2011-01-03 Thread Pankaj Tiwari

Hi Chris,

Thank you so much for pointing me to the right direction. The problem was
with my SERVERURL. The server was sending back the response as 200.

I should have checked that before :(

Thanks Again,
Pankaj

On Mon, Jan 3, 2011 at 11:29 PM, Christopher Schultz 
ch...@christopherschultz.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Pankaj,

 On 1/2/2011 10:06 PM, Pankaj Tiwari wrote:
  I have been trying to send multipart/form-data to the server. I have
 found
  that the request never reaches the server.

 How are you checking to see if it reaches the server?

  This is my client code, if I am missing something core in here.
 
  public static void main(String args[])
  {
  try
  {
  URL url = new URL(SERVERURL);

 What is SERVERURL?

  con.setDoInput(true);
  con.setDoOutput(true);

 ...

  OutputStream out = con.getOutputStream();
  DataOutputStream oos = new DataOutputStream(out);

 I agree with Pid: why are you using DataOutputStream?

  oos.writeBytes(TWOHYPHENS + BOUNDARY + LINEEND);

 Hmm... write before connect?

  oos.flush();
  con.connect();

 Try connecting before writing. Also, try reading the response (you did
 setDoInput(true)...).

 - -chris
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (MingW32)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

 iEYEARECAAYFAk0iDnEACgkQ9CaO5/Lv0PD6AQCfctFc2yULc7QkATMx1fAqwe5F
 km4AniigJu80/uJ6gl1Kg/6WD1i+rv/I
 =KmrY
 -END PGP SIGNATURE-

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




-- 
Pankaj Tiwari

Tomcat 7

2011-01-03 Thread Peter Sparkes


Can anyone please point me to a tutorial on how to
Install Tomcat 7 with virtual hosts on Debian Lenny

Thanks

Peter

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

Re: Tomcat(5.5) Clustering and Load Balancing.

2011-01-03 Thread Harsimranjit singh Kler

So this means tomcat alone have not sufficent support for Load Balancing and
clustering?.
but i am able to check successfully: 1)Session maintaince2)Auto Deployment

Only thing i am not able to achive to hide Cluster URL on redirection.

You main only way to achive is to use apache server HTTPD and connector,
mod_jk things ?.



On Mon, Jan 3, 2011 at 7:44 PM, Pid p...@pidster.com wrote:

 On 1/3/11 9:40 AM, Harsimranjit singh Kler wrote:
  using tomcat instances only(balancer Feature)

 Why?


 http://tomcat.apache.org/tomcat-5.5-doc/balancer-howto.html#Using_the_balancer_webapp

 This is a simple implementation of a rules-based load balancer. It was
 not designed as a replacement for other load-balancing mechanisms used
 for high traffic environments.

 IMHO I'd suggest that it's not suitable for most environments.

 Just use HTTPD and mod_jk.


 p




-- 

Regards

Harsimranjit Singh Kler

RE: Tomcat 7