Re: DO NOT REPLY [Bug 40317] - mod_jk, mixed up response if request contains http status 304 - resources with Content-Length > 0

[Rainer Jung]

Hi Bill,

why do we close this as duplicate?

The other bug has been closed as "not a mod_jk bug", but in this case 
the user gave evidence, that the might be something broken in the TC AJP 
connector. So shouldn't we keep this one open and only change the component.


Or do you think, there's no related bug in the AJP connector? Then you 
might like toadd a comment.


Regards,

Rainer

[EMAIL PROTECTED] wrote:

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=40317


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




--- Additional Comments From [EMAIL PROTECTED]  2008-02-18 17:29 ---
*** Bug 8 has been marked as a duplicate of this bug. ***


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 38713] - java.io.IOException: tmpFile.renameTo(classFile) failed when compiling new JSP (upon redeploy)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38713


[EMAIL PROTECTED] changed:

   What|Removed |Added

 OS/Version|Windows XP  |SunOS
   Platform|Other   |Sun




--- Additional Comments From [EMAIL PROTECTED]  2008-02-19 02:56 ---
Hi,
We are getting the same error in our Web app which runs on sun one 7.0 web 
server.

In our case, we have a jsp file that has a <[EMAIL PROTECTED] file= .. > to 
another 
jsp file.

We can see the .classtmp file for this jsp in the web server. 
None of the solutions given in this post have worked for us so far.

Has anyone faced a similar situation with sun one before? Please suggest a way 
forward.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Cookie handling issue (bug?) in Tomcat 5.5.26

[Marcinek, Blazej]

Hi,
 
I've just tried running Tomcat 5.5.26 and I've noticed a problem with
Cookie handling (though I'm not sure on which side it should be
corrected).
 
In our application we use cookies containing '=' (equals) characters in
values - this used to work until now, but fails on 5.5.26.
I've ran a little investigation and it appears that setting cookie with
= chars in value works fine (cookie is set properly with full value),
but when obtaining the cookie value later (via request.getCookies()...
getValue() sequence), the returned cookie value is truncated at the
first = character inside.
 
I.e. if I set the cookie "tmp" with value "a=b", I can see on HTTP
monitor that cookie was properly sent to browser, and again to server in
following request (with full "a=b" value) - but the getValue() method
returns "a" instead. 
 
Since the addCookie() works (and sets the value without complaining),
the latter truncation in get Value() looks like a bug in cookie parser. 
Can anyone confirm this? 
 
Kind regards,
 
Blazej Marcinek

Re: Cookie handling issue (bug?) in Tomcat 5.5.26

[Filip Hanik - Dev Lists]

they're not broken, read the servlet spec
http://marc.info/?t=12025394451&r=1&w=2

Filip

Marcinek, Blazej wrote:

Hi,
 
I've just tried running Tomcat 5.5.26 and I've noticed a problem with

Cookie handling (though I'm not sure on which side it should be
corrected).
 
In our application we use cookies containing '=' (equals) characters in

values - this used to work until now, but fails on 5.5.26.
I've ran a little investigation and it appears that setting cookie with
= chars in value works fine (cookie is set properly with full value),
but when obtaining the cookie value later (via request.getCookies()...
getValue() sequence), the returned cookie value is truncated at the
first = character inside.
 
I.e. if I set the cookie "tmp" with value "a=b", I can see on HTTP

monitor that cookie was properly sent to browser, and again to server in
following request (with full "a=b" value) - but the getValue() method
returns "a" instead. 
 
Since the addCookie() works (and sets the value without complaining),
the latter truncation in get Value() looks like a bug in cookie parser. 
Can anyone confirm this? 
 
Kind regards,
 
Blazej Marcinek


  



No virus found in this incoming message.
Checked by AVG Free Edition. 
Version: 7.5.516 / Virus Database: 269.20.7/1286 - Release Date: 2/18/2008 6:49 PM
  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 44435] - Inaccuracies in the ISO-8859-1 character encoder

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=44435





--- Additional Comments From [EMAIL PROTECTED]  2008-02-19 07:20 ---
(In reply to comment #2)
> What happens if you set the startup option:
> -Dorg.apache.catalina.STRICT_SERVLET_COMPLIANCE=true
> 

How would I set this flag in the native windows version?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Cookie handling issue (bug?) in Tomcat 5.5.26

[Marcinek, Blazej]

Ok, now I see why it fails with '=' char - but is there any way to make
Tomcat backward-compatible (e.g. with some System property, which I've
noticed proposed in some posts)?

The problem is that in our company we've got a common login web app,
which authenticates users and sets a domain-wide cookie for single sign
on - this cookie contains = chars, and unfortuntaly I don't control the
way how it's set (it doesn't have version 1 indicator). Then, my web app
(running on Tomcat) needs to fetch value of this cookie properly to
verify user's authentication - which worked fine till now, but on 5.5.26
the returned cookie value is truncated. Can this be worked around
somehow?

Kind regards,

Blazej Marcinek


-Original Message-
From: Filip Hanik - Dev Lists [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, February 19, 2008 3:22 PM
To: Tomcat Developers List
Subject: Re: Cookie handling issue (bug?) in Tomcat 5.5.26

they're not broken, read the servlet spec
http://marc.info/?t=12025394451&r=1&w=2

Filip

Marcinek, Blazej wrote:
> Hi,
>  
> I've just tried running Tomcat 5.5.26 and I've noticed a problem with
> Cookie handling (though I'm not sure on which side it should be
> corrected).
>  
> In our application we use cookies containing '=' (equals) characters
in
> values - this used to work until now, but fails on 5.5.26.
> I've ran a little investigation and it appears that setting cookie
with
> = chars in value works fine (cookie is set properly with full value),
> but when obtaining the cookie value later (via request.getCookies()...
> getValue() sequence), the returned cookie value is truncated at the
> first = character inside.
>  
> I.e. if I set the cookie "tmp" with value "a=b", I can see on HTTP
> monitor that cookie was properly sent to browser, and again to server
in
> following request (with full "a=b" value) - but the getValue() method
> returns "a" instead. 
>  
> Since the addCookie() works (and sets the value without complaining),
> the latter truncation in get Value() looks like a bug in cookie
parser. 
> Can anyone confirm this? 
>  
> Kind regards,
>  
> Blazej Marcinek
>
>   
>

>
> No virus found in this incoming message.
> Checked by AVG Free Edition. 
> Version: 7.5.516 / Virus Database: 269.20.7/1286 - Release Date:
2/18/2008 6:49 PM
>   


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 38713] - java.io.IOException: tmpFile.renameTo(classFile) failed when compiling new JSP (upon redeploy)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38713





--- Additional Comments From [EMAIL PROTECTED]  2008-02-19 08:48 ---
We are running on Windows but had the same scenario: a jsp file that has a
<[EMAIL PROTECTED] file= .. > to another jsp file.

It seemed that one possibility was the JSPs being compiled in the wrong order.
So we created an ANT task that we run when we deploy the web app to the server.
The ANT task compiles all the .jsp files, except those included ones.

For the included files, we renamed them to a different extension .jspinc and
these are not precompiled individually, but they do get compiled inline with the
files that include them.



-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Cookie handling issue (bug?) in Tomcat 5.5.26

[Filip Hanik - Dev Lists]

http://svn.apache.org/viewvc?view=rev&revision=627743 (ServerCookie.java)

Filip

Marcinek, Blazej wrote:

Ok, now I see why it fails with '=' char - but is there any way to make
Tomcat backward-compatible (e.g. with some System property, which I've
noticed proposed in some posts)?

The problem is that in our company we've got a common login web app,
which authenticates users and sets a domain-wide cookie for single sign
on - this cookie contains = chars, and unfortuntaly I don't control the
way how it's set (it doesn't have version 1 indicator). Then, my web app
(running on Tomcat) needs to fetch value of this cookie properly to
verify user's authentication - which worked fine till now, but on 5.5.26
the returned cookie value is truncated. Can this be worked around
somehow?

Kind regards,

Blazej Marcinek


-Original Message-
From: Filip Hanik - Dev Lists [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, February 19, 2008 3:22 PM

To: Tomcat Developers List
Subject: Re: Cookie handling issue (bug?) in Tomcat 5.5.26

they're not broken, read the servlet spec
http://marc.info/?t=12025394451&r=1&w=2

Filip

Marcinek, Blazej wrote:
  

Hi,
 
I've just tried running Tomcat 5.5.26 and I've noticed a problem with

Cookie handling (though I'm not sure on which side it should be
corrected).
 
In our application we use cookies containing '=' (equals) characters


in
  

values - this used to work until now, but fails on 5.5.26.
I've ran a little investigation and it appears that setting cookie


with
  

= chars in value works fine (cookie is set properly with full value),
but when obtaining the cookie value later (via request.getCookies()...
getValue() sequence), the returned cookie value is truncated at the
first = character inside.
 
I.e. if I set the cookie "tmp" with value "a=b", I can see on HTTP

monitor that cookie was properly sent to browser, and again to server


in
  

following request (with full "a=b" value) - but the getValue() method
returns "a" instead. 
 
Since the addCookie() works (and sets the value without complaining),

the latter truncation in get Value() looks like a bug in cookie

parser. 
  
Can anyone confirm this? 
 
Kind regards,
 
Blazej Marcinek


  




  

No virus found in this incoming message.
Checked by AVG Free Edition. 
Version: 7.5.516 / Virus Database: 269.20.7/1286 - Release Date:


2/18/2008 6:49 PM
  
  




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: DO NOT REPLY [Bug 40317] - mod_jk, mixed up response if request contains http status 304 - resources with Content-Length > 0

[Bill Barker]

 

> -Original Message-
> From: Rainer Jung [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, February 19, 2008 1:32 AM
> To: Tomcat Developers List
> Subject: Re: DO NOT REPLY [Bug 40317] - mod_jk, mixed up 
> response if request contains http status 304 - resources with 
> Content-Length > 0
> 
> Hi Bill,
> 
> why do we close this as duplicate?
> 
> The other bug has been closed as "not a mod_jk bug", but in this case 
> the user gave evidence, that the might be something broken in 
> the TC AJP 
> connector. So shouldn't we keep this one open and only change 
> the component.
> 

If it isn't mod_jk's job to sanitize the HTTP output, then it certainly
isn't the job of the AJP connector ;).  The AJP connector has no reason to
even know that httpd received the request via HTTP.

It's possible that there is a bug with DefaultServlet that creates 304
responses with a Content-Length, but I doubt it.  

> Or do you think, there's no related bug in the AJP connector? 
> Then you 
> might like toadd a comment.
> 
> Regards,
> 
> Rainer
> 
> [EMAIL PROTECTED] wrote:
> > DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG.
> > RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
> > .
> > ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND.
> > INSERTED IN THE BUG DATABASE.
> > 
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=40317
> > 
> > 
> > [EMAIL PROTECTED] changed:
> > 
> >What|Removed |Added
> > 
> --
> --
> >  CC|
> |[EMAIL PROTECTED]
> > 
> > 
> > 
> > 
> > --- Additional Comments From 
> [EMAIL PROTECTED]  2008-02-18 17:29 ---
> > *** Bug 8 has been marked as a duplicate of this bug. ***
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 



This message is intended only for the use of the person(s) listed above as the 
intended recipient(s), and may contain information that is PRIVILEGED and 
CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or 
distribute this message or any attachment. If you received this communication 
in error, please notify us immediately by e-mail and then delete all copies of 
this message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through 
the Internet is not secure. Do not send confidential or sensitive information, 
such as social security numbers, account numbers, personal identification 
numbers and passwords, to us via ordinary (unencrypted) e-mail.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r629223 - in /tomcat/trunk: java/org/apache/catalina/tribes/ java/org/apache/catalina/tribes/membership/ java/org/apache/catalina/tribes/transport/ java/org/apache/catalina/tribes/transpor

[fhanik]

Author: fhanik
Date: Tue Feb 19 12:45:54 2008
New Revision: 629223

URL: http://svn.apache.org/viewvc?rev=629223&view=rev
Log:
more UDP impl

Added:

tomcat/trunk/test/org/apache/catalina/tribes/test/channel/TestUdpPackages.java
Modified:
tomcat/trunk/java/org/apache/catalina/tribes/ChannelReceiver.java

tomcat/trunk/java/org/apache/catalina/tribes/membership/McastServiceImpl.java
tomcat/trunk/java/org/apache/catalina/tribes/transport/ReceiverBase.java
tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioReceiver.java

tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioReplicationTask.java
tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioSender.java

tomcat/trunk/test/org/apache/catalina/tribes/test/channel/TestDataIntegrity.java

Modified: tomcat/trunk/java/org/apache/catalina/tribes/ChannelReceiver.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/ChannelReceiver.java?rev=629223&r1=629222&r2=629223&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/tribes/ChannelReceiver.java (original)
+++ tomcat/trunk/java/org/apache/catalina/tribes/ChannelReceiver.java Tue Feb 
19 12:45:54 2008
@@ -27,6 +27,8 @@
  * @version $Revision$, $Date$
  */
 public interface ChannelReceiver extends Heartbeat {
+public static final int MAX_UDP_SIZE = 65535;
+
 /**
  * Start listening for incoming messages on the host/port
  * @throws java.io.IOException

Modified: 
tomcat/trunk/java/org/apache/catalina/tribes/membership/McastServiceImpl.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/membership/McastServiceImpl.java?rev=629223&r1=629222&r2=629223&view=diff
==
--- 
tomcat/trunk/java/org/apache/catalina/tribes/membership/McastServiceImpl.java 
(original)
+++ 
tomcat/trunk/java/org/apache/catalina/tribes/membership/McastServiceImpl.java 
Tue Feb 19 12:45:54 2008
@@ -335,7 +335,10 @@
 }
 };
 } //end if
-if ( t != null ) t.start();
+if ( t != null ) {
+t.setDaemon(true);
+t.start();
+}
 }
 } catch (SocketTimeoutException x ) { 
 //do nothing, this is normal, we don't want to block forever

Modified: 
tomcat/trunk/java/org/apache/catalina/tribes/transport/ReceiverBase.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/transport/ReceiverBase.java?rev=629223&r1=629222&r2=629223&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/tribes/transport/ReceiverBase.java 
(original)
+++ tomcat/trunk/java/org/apache/catalina/tribes/transport/ReceiverBase.java 
Tue Feb 19 12:45:54 2008
@@ -46,7 +46,6 @@
 
 public static final int OPTION_DIRECT_BUFFER = 0x0004;
 
-
 protected static org.apache.juli.logging.Log log = 
org.apache.juli.logging.LogFactory.getLog(ReceiverBase.class);
 
 private MessageListener listener;

Modified: 
tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioReceiver.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioReceiver.java?rev=629223&r1=629222&r2=629223&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioReceiver.java 
(original)
+++ tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioReceiver.java 
Tue Feb 19 12:45:54 2008
@@ -249,7 +249,7 @@
 
 setListen(true);
 if (selector!=null && datagramChannel!=null) {
-ObjectReader oreader = new ObjectReader(65535); //max size for a 
datagram packet
+ObjectReader oreader = new ObjectReader(MAX_UDP_SIZE); //max size 
for a datagram packet
 
registerChannel(selector,datagramChannel,SelectionKey.OP_READ,oreader);
 }
 

Modified: 
tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioReplicationTask.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioReplicationTask.java?rev=629223&r1=629222&r2=629223&view=diff
==
--- 
tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioReplicationTask.java
 (original)
+++ 
tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioReplicationTask.java
 Tue Feb 19 12:45:54 2008
@@ -33,6 +33,8 @@
 import org.apache.catalina.tribes.io.ChannelData;
 import org.apache.catalina.tribes.io.BufferPool;
 import java.nio.channels.CancelledKeyException;
+
+import org.apache.catalina.tribes.ChannelReceiver;
 import org.apache.catalina.tribes.UniqueId;
 import org.apache.catalina.

DO NOT REPLY [Bug 44454] New: - busy count reported in mod_jk inflated, causes incorrect balancing

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=44454

   Summary: busy count reported in mod_jk inflated, causes incorrect
balancing
   Product: Tomcat 5
   Version: 5.5.20
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Native:JK
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


We have some servers running Apache 2.2.3-11 on Centos 5 with mod_jk 1.2.25
connecting to tomcats running 5.5.20.  Over the course of a couple of days, the
busy count on the various servers (as reported by the jkstatus page) creeps
upward, causing the balancing to get out of whack.  A graceful restart of apache
gets things back to normal, as does a restart of the tomcat, but the process
starts again.  I'm not entirely sure what information would be helpful in
troubleshooting this, please advise.  Earlier load testing did not show
anything, so I'm guessing that specific circumstances may cause the count to
become wrong.

Thanks,
Andrew

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 44454] - busy count reported in mod_jk inflated, causes incorrect balancing

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=44454





--- Additional Comments From [EMAIL PROTECTED]  2008-02-19 13:31 ---
Are we sure, that the growing busy numbers are wrong?

Asked differently: can you do Thread Dumps of your backends to confirm, that
they are *not* having that many requests busy? In theory some requests might got
stuck in the backend. If you don't have a reaply_timeout, mod_jk will wait
indefinitely for a response.

By using "kill -QUIT PID" (PID is the process id of your backend=romcat process)
you will get a stack for each thread in Tomcat in your catalina.out. This
procedure does not influence your running Tomcat negatively. It will pause for a
few milliseconds and then resume the usual work.

In the dump, the threads responsible for requests coming in via AJP13 (from
mod_jk) can be identified as TP-ProcessorXXX. Some of the will only have a very
short stack, which indicates, that they are idle in the thread pool. Some have a
slightly longer stack (about 10 lines) with a top level method being a socket
read, which tells us, that mod_jk is connected to them, but they are not actualy
processing a request, and few will have a very long stack, usually containing
webapp methods, a service method etc. Those ar the ones that process a request
and should be equivalnt to "busy" (at least of Tomcat only gets requests from
one httpd. Otherwise you need to add up all the busy for this Tomcat in the
various httpd).

Altough in principal there's a chance, that busy could go wrong, I never
detected it in practice and the feature is out in the wild for quite some time
now, without problem reports. That's why I first want you to check, taht the
numbers are really wrong.

Furthermore: are there errors in the JK error log?

Last: if you want to track how and when busy increases, you can add
"%{JK_LB_LAST_BUSY}n" to your LogFormat in httpd. Then your access log will
contain the busy number after each request in the request log line.

Regards,

Rainer


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 44454] - busy count reported in mod_jk inflated, causes incorrect balancing

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=44454





--- Additional Comments From [EMAIL PROTECTED]  2008-02-19 14:08 ---
I took one of our systems out of rotation and let it sit for a while.  Its busy
was hanging around 16-20 while in rotation.  Once out, it almost immediately
went to 12 and remained at 12 the entire time.  I did the thread dump and
attached the TP-ProcessorXXX entries.  It looks like the vast majority of
connections show in socket read, with a few idle in the pool.  There were no
active threads (which is good, since it was out of rotation).  The mod_jk.log
shows no errors, though there are many warnings for things like: 

[Tue Feb 19 15:56:18.849 2008] [13119:2611919760] [warn]
map_uri_to_worker::jk_uri_worker_map.c (550): Uri echo|20YYY;echo| is invalid.
Uri must start with /

Good ole' internet.  Thanks for the variable, I can see that being handy, though
I can't add anything in right now.

Let me know if there's anything more.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 44454] - busy count reported in mod_jk inflated, causes incorrect balancing

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=44454





--- Additional Comments From [EMAIL PROTECTED]  2008-02-19 14:00 ---
Created an attachment (id=21564)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=21564&action=view)
Results from Thread Dump - Idle Server

The JK Threads from an idle tomcat instance during a thread dump

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 44454] - busy count reported in mod_jk inflated, causes incorrect balancing

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=44454





--- Additional Comments From [EMAIL PROTECTED]  2008-02-19 14:38 ---
Thanks for the check, so we know for sure, that the busy count doesn't
correspond to the backend status.

Although there is still a theoretical possibility, that mod_jk *thinks* the
backend is that busy, I checked, if we miss some error conditions when
decreasing the busy count. There is not condition in the code, how the busy
increment could not be followed by a decrement. The counter is hold inside a
shared memory segment and it is marked as volatile. In case you hae a *very*
busy web site, it's possible, that we run into a non-atomic increment/decrement
problem. Although that's possible, I'm still thinking about other possibilities.

The status worker shows a busy counter for the lb and for each member of an lb.
Do both types of busy counters suffer from the problem?

To get an idea: how fast does the problem happen (how much busy increase per day
or so, and also how many requests approximately are handled by the corresponding
worker during that time)?

You mentioned, that this influences negatively the balancing behaviour. I deduct
from that, that you are using the Busyness method. Do you have a reason not to
use the Requests method? It would not suffer from the "wrong busy" problem.

Finally: although we know no change in the code that would suggest that the
problem will go sway in 1.2.26, is it possible to switch to that version? Be
careful: in 1.2.26 your JkMounts are not automatically inhertited between httpd
VirtualHosts. You either need to include them in each VirtualHost or use
JkMountCopy (see docs). Apart from that, the version update should be reliable.

I'm still wondering, if mod_jk threads might hang between start of request and
end of response. You could use gstack, to do thread dumps on the httpd side.
Since the busy number is summed up over all httpd child processes and we don't
know if the problem is located in only one of those or visible in all of them,
you would need to do gstack on all httpd child processes.

The ones busy in mod_jk will be easily detectable, since mod_jk uses "jk" as
part of most function names.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 43285] - Missing EL Coercion causes argument type mismatch

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43285


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |




--- Additional Comments From [EMAIL PROTECTED]  2008-02-19 15:38 ---
This introduced a new bug now. In 6.0.14, when you have a selecItem whose empty
value is selected (value=""), and the binding datatype was Long, EL evaluation
would set it to NULL. Now, its setting it to 0. 

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 43285] - Missing EL Coercion causes argument type mismatch

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43285





--- Additional Comments From [EMAIL PROTECTED]  2008-02-19 15:48 ---
To add to my comment above: 

Here is my bean:
MyBean { 
   private Long number; 
   ...//getter 
   .. //setter 
   .. // other methods
}

Here is my JSP (JSF Page rather):




myBean.allNumbers is implemented as follows:

public List getAllNumbers() {
   List list = new ArrayList(0);
   list.add(new SelectItem("", "--SELECT--"));   // NOTE: this causes the issue
   list.add(new SelectItem("1", "ONE"));
   list.add(new SelectItem("2", "TWO"));
   list.add(new SelectItem("1", "THREE"));
   return list;
}

Now, when i don't select a value (ie., leave the drop down on --SELECT--) for
the Number and submit the form, Tomcat 6.0.16 would set the myBean.number to 0.
Until Tomcat 6.0.14, the value is NULL.

Why is this important? It ends up putting 0's in the database instead of NULL's.

Thanks

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 44454] - busy count reported in mod_jk inflated, causes incorrect balancing

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=44454





--- Additional Comments From [EMAIL PROTECTED]  2008-02-19 15:54 ---
Created an attachment (id=21566)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=21566&action=view)
Thread Dump from Apache Children


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 44454] - busy count reported in mod_jk inflated, causes incorrect balancing

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=44454





--- Additional Comments From [EMAIL PROTECTED]  2008-02-19 15:50 ---
 Well, we're a busy site, but not stunningly so... everyone's idea on what
makes a busy site may differ.  The httpd systems are never that terribly loaded
CPU/Load wise (less then 40%).  The global counter and the individual counters
add up to each over, so I believe that indicates that they both are having the
issue.  It's hard to tell at what level the inflation occurs, as without calming
servers at around the same time each day it's hard to tell what are real
requests and which are inflation.  We have a few servers in rotation that are
bulkier and run a 2x higher LBFactor, and they seem currently to have about 2x
the false busys.  I'm guessing about 5 a day for the lighter servers, and 10 a
day for the bigger servers.  Because the load balancing is unequal, it varies,
but since our graceful restart 2.5 days ago, the ACC on the servers is anywhere
from 2-4 million, depending on the server.
 As for the balancing method, the busyness method is definitely more even
when it works since our requests can be very different weights.  As for running
1.2.26, I think we could compile/use it no problem (we're running 2.2.3, the
precompile indicates 2.2.6 as a prereq), but I know management would be a little
grumbly to make a change without a better idea as to what's going on.  I don't
think the config changes are a problem for us as we use preference files and
JKMounts only at VHost level... no globals.
 I'm gathering the gstack data now and will post in a few minutes.

In case it comes up, as typical worker is configured like:
worker..port=8009
worker..host=
worker..type=ajp13
worker..socket_timeout=30
worker..connection_pool_timeout=60
worker..lbfactor=20

The LB involved is:
worker..lock=P
worker..method=B

and we have a global setting of:
worker.maintain=15

Thanks,
Andrew

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 44455] New: - Error when using sendRedirect with a mailto as a redirect url

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=44455

   Summary: Error when using sendRedirect with a mailto as a
redirect url
   Product: Tomcat 5
   Version: 5.0.28
  Platform: Other
OS/Version: Windows XP
Status: NEW
  Severity: critical
  Priority: P2
 Component: Connector:Coyote
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When you try to use the sendRedirect of HTTPServletResponse, for example,
response.sendRedirect("mailto:[EMAIL PROTECTED]");, this is redirecting to:

http://theservername/mailto:[EMAIL PROTECTED]

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 44455] - Error when using sendRedirect with a mailto as a redirect url

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=44455





--- Additional Comments From [EMAIL PROTECTED]  2008-02-19 16:49 ---
Another i did not mention, and i tested it in tomcat 6.0.14 and works perfectly.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Tomcat 3.2.x problem with MS-DOS device names

[Mamatha Rao (mamtarao)]

Hi,
 
Our application used Tomcat 3.2 and Nessus scan reported the following
CVE against it
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2003-0045
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2003-0045> 
 
Tomcat release notes suggest fixing defect in 3.3.1a and later. We moved
to Tomcat 5.5 and still saw Nessus reporting the same vulnerability. The
Nessus scan may not be accurate since we ensured that Tomcat did not
actually freeze after the attack.  
 
However, we are now stuck in verifying the vulnerability existed in
Tomcat 3.2. Have tried testing with a sample servlet - it returns a 404
Not Found error on requests like http://[ip http://[ip/>
addr]:8080/test/aux.jsp. Traces show something like
java.io.IOException: Bad pathname
at java.io.WinNTFileSystem.canonicalize0(Native Method)
at
java.io.Win32FileSystem.canonicalize(Win32FileSystem.java:354)
at java.io.File.getCanonicalPath(File.java:513)
at org.apache.tomcat.util.FileUtil.safePath(FileUtil.java:184)
at org.apache.tomcat.core.Context.getRealPath(Context.java:797)
at
org.apache.tomcat.facade.ServletContextFacade.getRealPath(ServletCont
extFacade.java:136)
at
org.apache.jasper.JspEngineContext.getRealPath(JspEngineContext.java:
359)

2008-02-19 10:18:05 - Ctx( /test ): 404 R( /test + /aux.jsp + null) JSP
file not
 found
2008-02-19 10:18:05 - Ctx( /test ): Handler
tomcat.notFoundHandler(null/null) to
mcat.notFoundHandler
 
on such requests. And even with limiting the number of threads, Tomcat
does not freeze. And thread dumps dont indicate anything wrong.
 
Have tried it both on Windows 2000 server and Windows XP. Is there any
dependency on Windows versions?
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2003-0045
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2003-0045>  seems to
suggest it occurs in certain Windows systems while
http://xforce.iss.net/xforce/xfdb/12102
http://xforce.iss.net/xforce/xfdb/12102>  says it occurs in
all versions of Windows.
 
http://marc.info/?l=tomcat-dev&m=101055029706766&w=2
  - This mail
thread is refering to some similar/same(?) bug and suggests even Windows
NT, 2000 have a problem but may be Tomcat 3.2.4 doesnt show the problem.
 
Does anyone remember if this vulnerability can be triggered in Tomcat
3.2 and how? Any pointers to the bug fix in subversion would also help.
 
Regards
Mamatha

DO NOT REPLY [Bug 38713] - java.io.IOException: tmpFile.renameTo(classFile) failed when compiling new JSP (upon redeploy)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38713





--- Additional Comments From [EMAIL PROTECTED]  2008-02-19 21:32 ---
Hi Brian,
Thanks for replying.
As far as I can understand, you are precompiling the jsps before deploying. 
But we depend on the server to compile them at run time. 
Also, while looking into this issue, we found that when ever this error 
occurs, a file with an extension .classtmp exists in the work folder. 

And we have also found that when ever the size of the compiled servlet is 
below a particualr limit which is around 32KBs it is fine. But when the size 
exceeds this limit, we get the error.

Is there any such limit to the sizes of the class files? if so, how can we 
remove this constraint? or is there any other way out? Will <%jsp:include> tag 
help?

(In reply to comment #19)
> We are running on Windows but had the same scenario: a jsp file that has a
> <[EMAIL PROTECTED] file= .. > to another jsp file.
> It seemed that one possibility was the JSPs being compiled in the wrong 
order.
> So we created an ANT task that we run when we deploy the web app to the 
server.
> The ANT task compiles all the .jsp files, except those included ones.
> For the included files, we renamed them to a different extension .jspinc and
> these are not precompiled individually, but they do get compiled inline with 
the
> files that include them.



-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 44294] - Support for EL functions with varargs

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=44294


[EMAIL PROTECTED] changed:

   What|Removed |Added

  Attachment #21426|0   |1
is obsolete||




--- Additional Comments From [EMAIL PROTECTED]  2008-02-19 23:50 ---
Created an attachment (id=21567)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=21567&action=view)
AstFunction.patch


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]