DO NOT REPLY [Bug 36823] - Ant task Description file catalina.tasks shouldn't have JspC

2005-09-27 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36823.
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=36823


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2005-09-27 10:08 ---
This will not be addressed.

-- 
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: JK 1.2.15 Release plan?

2005-09-27 Thread Rainer Jung
I encourage you for voting 1.2.15 as stable.

Mladen Turk wrote:

 Anyhow, I would like that we vote this (1.2.15) version as stable,
 because it's a bug-fix release over the 1.2.14 stable.


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



DO NOT REPLY [Bug 36814] - Parameter for POST encoding

2005-09-27 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36814.
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=36814





--- Additional Comments From [EMAIL PROTECTED]  2005-09-27 13:32 ---
it always comes down to what the servlet specification says a container 
implementation should do, what developers expect container implementations to 
do and how they should behave, and what developers often get confused about.

character encoding seems to be one of those things that many developers are 
getting confused about, and this issue in particular seems to come about quite 
often. i suppose as far as a developer is concerned whatever data they send to 
the server should be maintained in that way. so if arabic is sent via a post 
running on tomcat, is it acceptable for the developer to have to understand 
that tomcat runs in a charset that is not universal and to have to seek a 
filter or write their own filter to change this?

personally, i believe encoding falls into the same kind of category as other 
configuration elements like databases, jndi environment vars.

imo the container should help out the developer with this type of 
functionality, if not by configuration, then by providing default configurable 
filters across web applications. 

just my opinion.

-- 
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 36814] - Parameter for POST encoding

2005-09-27 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36814.
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=36814





--- Additional Comments From [EMAIL PROTECTED]  2005-09-27 15:21 ---
Maybe I am too silly to do it, but for my test case it does not work setting the
encoding with a filter. I did this:

in the web.xml as the first filter in the list:

 filter
filter-nameSet Character Encoding/filter-name
filter-classpackage.SetCharacterEncodingFilter/filter-class
init-param
  param-nameencoding/param-name
  param-valueUTF-8/param-value
/init-param
  /filter

This is the filter which is packaged as example with Tomcat.

If I do now a post with UTF-8 characters all submitted UTF-8 characters are
corrupted. 

What am I doing wrong?


There is also a problem with valves. If you read a parameter from the request
inside a valve then the character encoding is automatically set to the default
(spec) value which is ISO-8859-1. Later you can not change this in a filter 
anymore.

(If I use my patch instead, everything is fine, no matter where I try to read
parameters from the request.)

With regards,
Udo

-- 
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 36814] - Parameter for POST encoding

2005-09-27 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36814.
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=36814





--- Additional Comments From [EMAIL PROTECTED]  2005-09-27 15:25 ---
don't forget to add a filter mapping, this is ours, you may need a URL pattern 
match.

filter-mapping
filter-namerequestCharacterEncodingFilter/filter-name
servlet-namespringFrontController/servlet-name
/filter-mapping



-- 
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 36814] - Parameter for POST encoding

2005-09-27 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36814.
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=36814





--- Additional Comments From [EMAIL PROTECTED]  2005-09-27 15:45 ---
I also have the filter mapping like this:

 filter-mapping
filter-nameSet Character Encoding/filter-name
servlet-nameaction/servlet-name
  /filter-mapping

but it does not work.

In the config file in the Context I have this valve included:

Valve className=org.apache.catalina.valves.AccessLogValve
   directory=logs  prefix=localhost_access_ewi_log. suffix=.txt
   resolveHost=false pattern=common/

In the comment it says, that all request accesses are logged. Maybe this one
sets the character encoding already to the wrong value? I mean not directly the
valve but Tomcat when the request is accessed.




-- 
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 36827] New: - Need an option to severe socket connections between mod_jk and ajp connector after request/response cycle.

2005-09-27 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36827.
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=36827

   Summary: Need an option to severe socket connections between
mod_jk and ajp connector after request/response cycle.
   Product: Tomcat 5
   Version: 5.0.28
  Platform: All
OS/Version: Linux
Status: NEW
  Severity: major
  Priority: P2
 Component: Native:JK
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


Here’s the situation as it stands today and what can be done to solve it. I’ll 
try to keep this short.

Running configuration:

•   Running on Linux Red-Hat Ent 3
•   1 X F5 load balancer and hardware SSL box.
•   5 X Apache 1.3.33/mod_jk 1.2.14
•   6 X JBoss 4.0.0/Tomcat 5.0.28 using the AJP13 connector. 
•   Oracle 9i

Our production environment hosts a number of applications, each with different 
load and usage patterns. Our problem comes from the fact that it is difficult 
to find a web farm configuration that will satisfy every application. For 
reasons I will not explain here, we cannot have a dedicated web farm for each 
application.

This is what we think is happening in our production environment based on 
tests ran in UAT (User Acceptance Tests) and literature from the Apache and 
Tomcat products. This is all pretty new to us so if someone can provide hard 
facts, you are more than welcome.

1.  The 1.3 generation of Apache web servers will spawn a child process to 
handle an HTTP request. Only one HTTP request at a time can be processed by 
that child. 
2.  As the load increases on the web server, additional child processes 
will be spawned to concurrently serve the requests. There is a default limit 
to how many child processes can be forked. That limit defaults to 256 but has 
been changed in production to 16384. This is the MaxClients directive. It 
seems that production really needs the 16384 value instead of the 256 default. 
With 256, our web servers were rejecting connections and could not support the 
load generated by all of our clients.
3.  To prevent latency, Apache will maintain a maximum of 100 spare child 
processes alive. Spare means that they are not serving requests. Once reached, 
that number of spare servers does not seem to decrease. This is the number we 
see in our tests in UAT where 201 threads remain active in Tomcat. This is the 
100 spare children connections * 2 web server plus accept() thread. 
4.  If a request needs to be forwarded to Tomcat/JBoss (dynamic pages), 
the child process mod_jk module will instantiate a socket connection to the 
ajp13 connector in Tomcat. 
5.  Tomcat will accept the connection and create a thread to serve it. 
Connections will be accepted up to a concurrent maximum of 1200. This upper 
value has been set by us. 
6.  Tomcat will reject connections when the maximum is reached. JBoss 
4.0.0 has a known issue where the server will die when the maximum is reached. 
This has been fixed in 4.0.2. 
7.  A connection could potentially be recycled in mod_jk (recycle_timeout) 
if no activity occurs thru the connection. However, any requests to Tomcat 
from any user session-bound to that Tomcat instance could go thru the 
connection, thus keeping it active. Recycling does not seem to occur. We use a 
recycle_timeout value of 300.
8.  The fact that the production web servers can potentially serve up to 
16384 concurrent requests make it possible for a web server to instantiate an 
almost infinite number of connections to Tomcat and nuke it. 
9.  Tomcat can then become overloaded with connections. If a valid HTTP 
request comes thru Apache and is routed to a child process that has not yet 
made a connection to Tomcat, the connection could be impossible if Tomcat has 
already accepted its 1200 limit. 
10. In that case, mod_jk could potentially fail over to another Tomcat. 
The user would however loose his session.
11. The recycle_timeout and  cache_size options are of no use to us 
because too many web server children are created to serve the company load. 
Thus, many different routes can be taken by requests targeted to our 
application, keeping all the connection alive.
12. We tried really small recycle_timeout values (e.g. 20) with no effect. 
A netstat reveals that connections remain ESTABLISHED. 
13. The maxRequestsPerChild setting is set to 0 in PROD. It means that 
Apache child processes will never die, unless you reach the maxSpareServers 
value. Thus, at least 100 connections per web server will always remain 
actively connected to Tomcat. A  0 value would at least guarantee that a 
child process would eventually die, freeing 

Need an option to severe socket connections between mod_jk and ajp connector after request/response cycle.

2005-09-27 Thread Remy Gendron
Hi all,

Here's the situation as it stands today and what can be done to solve
it. I'll try to keep this short.

Running configuration:

*   Running on Linux Red-Hat Ent 3
*   1 X F5 load balancer and hardware SSL box.
*   5 X Apache 1.3.33/mod_jk 1.2.14
*   6 X JBoss 4.0.0/Tomcat 5.0.28 using the AJP13 connector. 
*   Oracle 9i


Our production environment hosts a number of applications, each with
different load and usage patterns. Our problem comes from the fact that
it is difficult to find a web farm configuration that will satisfy every
application. For reasons I will not explain here, we cannot have a
dedicated web farm for each application.

This is what we think is happening in our production environment based
on tests ran in UAT (User Acceptance Tests) and literature from the
Apache and Tomcat products. This is all pretty new to us so if someone
can provide hard facts, you are more than welcome.

1.  The 1.3 generation of Apache web servers will spawn a child
process to handle an HTTP request. Only one HTTP request at a time can
be processed by that child. 
2.  As the load increases on the web server, additional child
processes will be spawned to concurrently serve the requests. There is a
default limit to how many child processes can be forked. That limit
defaults to 256 but has been changed in production to 16384. This is the
MaxClients directive. It seems that production really needs the 16384
value instead of the 256 default. With 256, our web servers were
rejecting connections and could not support the load generated by all of
our clients.
3.  To prevent latency, Apache will maintain a maximum of 100 spare
child processes alive. Spare means that they are not serving requests.
Once reached, that number of spare servers does not seem to decrease.
This is the number we see in our tests in UAT where 201 threads remain
active in Tomcat. This is the 100 spare children connections * 2 web
server plus accept() thread. 
4.  If a request needs to be forwarded to Tomcat/JBoss (dynamic
pages), the child process mod_jk module will instantiate a socket
connection to the ajp13 connector in Tomcat. 
5.  Tomcat will accept the connection and create a thread to serve
it. Connections will be accepted up to a concurrent maximum of 1200.
This upper value has been set by us. 
6.  Tomcat will reject connections when the maximum is reached.
JBoss 4.0.0 has a known issue where the server will die when the maximum
is reached. This has been fixed in 4.0.2. 
7.  A connection could potentially be recycled in mod_jk
(recycle_timeout) if no activity occurs thru the connection. However,
any requests to Tomcat from any user session-bound to that Tomcat
instance could go thru the connection, thus keeping it active. Recycling
does not seem to occur. We use a recycle_timeout value of 300.
8.  The fact that the production web servers can potentially serve
up to 16384 concurrent requests make it possible for a web server to
instantiate an almost infinite number of connections to Tomcat and nuke
it. 
9.  Tomcat can then become overloaded with connections. If a valid
HTTP request comes thru Apache and is routed to a child process that has
not yet made a connection to Tomcat, the connection could be impossible
if Tomcat has already accepted its 1200 limit. 
10. In that case, mod_jk could potentially fail over to another
Tomcat. The user would however loose his session.
11. The recycle_timeout and  cache_size options are of no use to us
because too many web server children are created to serve the company
load. Thus, many different routes can be taken by requests targeted to
our application, keeping all the connection alive.
12. We tried really small recycle_timeout values (e.g. 20) with no
effect. A netstat reveals that connections remain ESTABLISHED. 
13. The maxRequestsPerChild setting is set to 0 in PROD. It means
that Apache child processes will never die, unless you reach the
maxSpareServers value. Thus, at least 100 connections per web server
will always remain actively connected to Tomcat. A  0 value would at
least guarantee that a child process would eventually die, freeing
Tomcat connections and releasing back leaked memory to the OS. 

It's hard to see a path out of this one. One solution would be to reduce
the MaxClients Apache config back to 256. This would mean that a single
instance of Tomcat would not be hit by more than 256 * 5 = 1280 (5 is
the web farm size) connections. Our current jvm settings (heap + thread
stack sizes) would allow us to do it. We would also need to bump our
current 1200 limit a bit higher. However, this solution if not
compatible with other applications which have really high loads.

Second option would be to patch mod_jk so that connections are dropped
as soon as the response has been received from Tomcat. Drawbacks include
preventing us from upgrading to new releases (unless we re-apply the
modifications), introduce the 

Problems Parsing Request Paramers

2005-09-27 Thread Jeremy Nix
First off, I apologize for the cross-post.  I posted this same message
in the User's mailing list with no replies.   So, my hope is that one of
you developers may have some insight into the problem that I'm having.

Certain users of my website are having issues with respect to submitting
a form on a page.  Not all users are experiencing this problem, and I've
yet to replicate it myself so it makes the situation even more complex.
I have an icking suspicion that its related to the user's browser, but
I've tested on the same browser version/subversion without a glitch.
Here's the scenario:
1) User goes to page.
2) User fills out form.
3) User clicks submit.
4) JSP page then performs sanity checks against submitted data.  In the
event of a failure on the sanity checks, page is redirected back to
previous page.

Simple enough.  Well, users are filling out the form and clicking submit
with valid infromation, yet when I parse the parameters out of the
request, I'm finding none of the form values from the previous page.  I
then decided to investigate further and log out all request information
in the event that these sanity checks fail.  The following is what I
logged out:

-
Attributes:
  javax.servlet.request.cipher_suite = [SSL_RSA_WITH_RC4_128_MD5]
  javax.servlet.request.key_size = [128]
  javax.servlet.request.ssl_session =
[433162398579970fee9289baa9ac832b8558dcc409382f62cb67a3499b80]
Parameters:
Cookies:
 JSESSIONID = [FCB31837FFBD2C0D9F986C42B698BADE]
 contact_value = [ABC]
 duplicate_type = [None]
 duplicate_time = []
 mortgage = []
 lender_id_label = []
 title_alternative = []
 can_place_orders = [Y]
 flood_default = [126]
 can_cancel_lol = [N]
 contact_label = []
 lender_id_value = [ABC]
 census = []
 loan_no_label = []
 delivery_method = [Online]
 apprasail = []
 delivery_address = []
 title = []
Headers:
  accept = [image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/vnd.ms-excel, application/msword,
application/vnd.ms-powerpoint, application/x-shockwave-flash, */*]
  referer =
[https://WEBSITE_URL/CreateOrder.jsp?applicant2HomePhone=streetName=Ma
in+Stapplicant2WorkPhone=applicantOtherPhone=ownerEstimate=applicant
2WorkPhone2=revisionOf=applicantWorkPhoneExtension=unitType=preFixDi
r=Eapplicant2OtherPhoneAreaCode=applicantOtherPhone2=applicantMname=L
skipstep=nonezip4=applicant2HomePhoneAreaCode=applicant2OtherPhone=
applicantLname=DoestreetNum=applicantHomePhoneAreaCode=zip=40845pass
code=HomeorderHeaderGeneralNotes=applicantHomePhone2=propertyLoanNumb
er=productTitle=applicantFname=Johnapplicant2WorkPhoneExtension=appl
icant2WorkPhoneAreaCode=applicant2Mname=JunitNumber=applicantWorkPhon
eAreaCode=postFixDir=productAppraisal=propertyParcelNumber=applicant
WorkPhone2=applicantOtherPhoneAreaCode=city=HulenapplicantHomePhone=
applicantWorkPhone=applicant2Lname=Janeapplicant2OtherPhone2=applican
t2HomePhone2=streetType=state=KYcontactId=10productMortgagePrep=pro
ductFlood=Yesapplicant2Fname=Doe]
  accept-language = [en-us]
  content-type = [application/x-www-form-urlencoded]
  accept-encoding = [gzip, deflate]
  user-agent = [Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;
.NET CLR 1.1.4322)]
  host = [WEBSITE_DOMAIN]
  connection = [Keep-Alive]
  cache-control = [no-cache]
  cookie = [JSESSIONID=FCB31837FFBD2C0D9F986C42B698BADE;
contact_value=ABC; duplicate_type=None; duplicate_time=; mortgage=;
lender_id_label=; title_alternative=; can_place_orders=Y;
flood_default=126; can_cancel_lol=N; contact_label=;
lender_id_value=ABC; census=; can_view_insurance_tracking=N;
loan_no_label=; delivery_method=Online; apprasail=; delivery_address=;
title=]
  content-length = [0]

-
There are many interesting things about this request.  First, the
content-length is 0.  Not sure how this could happen...error in
browser??  Second, and the most intriguing...Notice the referer entry.
The referer entry actually contains all relevant information that I
needed in order to process this request, yet if you look at what
parameters I was actually able to parse off this request you will
see...NONE.

I'm stumped.  Anybody else seen this before?

Environment:
JDK 1.4.2_08
Tomcat 5.5.9

___
Jeremy Nix
Senior Application Developer
Southwest Financial Services, LTD.
(513) 621-6699 x1158
www.sfsltd.com





Re: Problems Parsing Request Paramers

2005-09-27 Thread Yoav Shapira
Hi,
Could it be the referer URL is too long, causing the query string to be ignored
or dropped?  There's a limit (2048 characters, I think?) on GET requests in
some browsers.  But actually, you're seeing this on the server, so I'm not
sure.  Can you try testing with less parameters or an otherwise shorter query
string?

Yoav

--- Jeremy Nix [EMAIL PROTECTED] wrote:

 First off, I apologize for the cross-post.  I posted this same message
 in the User's mailing list with no replies.   So, my hope is that one of
 you developers may have some insight into the problem that I'm having.
 
 Certain users of my website are having issues with respect to submitting
 a form on a page.  Not all users are experiencing this problem, and I've
 yet to replicate it myself so it makes the situation even more complex.
 I have an icking suspicion that its related to the user's browser, but
 I've tested on the same browser version/subversion without a glitch.
 Here's the scenario:
 1) User goes to page.
 2) User fills out form.
 3) User clicks submit.
 4) JSP page then performs sanity checks against submitted data.  In the
 event of a failure on the sanity checks, page is redirected back to
 previous page.
 
 Simple enough.  Well, users are filling out the form and clicking submit
 with valid infromation, yet when I parse the parameters out of the
 request, I'm finding none of the form values from the previous page.  I
 then decided to investigate further and log out all request information
 in the event that these sanity checks fail.  The following is what I
 logged out:
 
 -
 Attributes:
   javax.servlet.request.cipher_suite = [SSL_RSA_WITH_RC4_128_MD5]
   javax.servlet.request.key_size = [128]
   javax.servlet.request.ssl_session =
 [433162398579970fee9289baa9ac832b8558dcc409382f62cb67a3499b80]
 Parameters:
 Cookies:
  JSESSIONID = [FCB31837FFBD2C0D9F986C42B698BADE]
  contact_value = [ABC]
  duplicate_type = [None]
  duplicate_time = []
  mortgage = []
  lender_id_label = []
  title_alternative = []
  can_place_orders = [Y]
  flood_default = [126]
  can_cancel_lol = [N]
  contact_label = []
  lender_id_value = [ABC]
  census = []
  loan_no_label = []
  delivery_method = [Online]
  apprasail = []
  delivery_address = []
  title = []
 Headers:
   accept = [image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
 application/vnd.ms-excel, application/msword,
 application/vnd.ms-powerpoint, application/x-shockwave-flash, */*]
   referer =
 [https://WEBSITE_URL/CreateOrder.jsp?applicant2HomePhone=streetName=Ma
 in+Stapplicant2WorkPhone=applicantOtherPhone=ownerEstimate=applicant
 2WorkPhone2=revisionOf=applicantWorkPhoneExtension=unitType=preFixDi
 r=Eapplicant2OtherPhoneAreaCode=applicantOtherPhone2=applicantMname=L
 skipstep=nonezip4=applicant2HomePhoneAreaCode=applicant2OtherPhone=
 applicantLname=DoestreetNum=applicantHomePhoneAreaCode=zip=40845pass
 code=HomeorderHeaderGeneralNotes=applicantHomePhone2=propertyLoanNumb
 er=productTitle=applicantFname=Johnapplicant2WorkPhoneExtension=appl
 icant2WorkPhoneAreaCode=applicant2Mname=JunitNumber=applicantWorkPhon
 eAreaCode=postFixDir=productAppraisal=propertyParcelNumber=applicant
 WorkPhone2=applicantOtherPhoneAreaCode=city=HulenapplicantHomePhone=
 applicantWorkPhone=applicant2Lname=Janeapplicant2OtherPhone2=applican
 t2HomePhone2=streetType=state=KYcontactId=10productMortgagePrep=pro
 ductFlood=Yesapplicant2Fname=Doe]
   accept-language = [en-us]
   content-type = [application/x-www-form-urlencoded]
   accept-encoding = [gzip, deflate]
   user-agent = [Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;
 .NET CLR 1.1.4322)]
   host = [WEBSITE_DOMAIN]
   connection = [Keep-Alive]
   cache-control = [no-cache]
   cookie = [JSESSIONID=FCB31837FFBD2C0D9F986C42B698BADE;
 contact_value=ABC; duplicate_type=None; duplicate_time=; mortgage=;
 lender_id_label=; title_alternative=; can_place_orders=Y;
 flood_default=126; can_cancel_lol=N; contact_label=;
 lender_id_value=ABC; census=; can_view_insurance_tracking=N;
 loan_no_label=; delivery_method=Online; apprasail=; delivery_address=;
 title=]
   content-length = [0]
 
 -
 There are many interesting things about this request.  First, the
 content-length is 0.  Not sure how this could happen...error in
 browser??  Second, and the most intriguing...Notice the referer entry.
 The referer entry actually contains all relevant information that I
 needed in order to process this request, yet if you look at what
 parameters I was actually able to parse off this request you will
 see...NONE.
 
 I'm stumped.  Anybody else seen this before?
 
 Environment:
 JDK 1.4.2_08
 Tomcat 5.5.9
 
 ___
 Jeremy Nix
 Senior Application Developer
 Southwest Financial Services, LTD.
 (513) 621-6699 x1158
 www.sfsltd.com
 
 
 
 



RE: Problems Parsing Request Paramers

2005-09-27 Thread Jeremy Nix
The original referer variable was a little over 1K chars, so I don't
believe that I'm pushing that limit quite yet.  As for recreating...I
cannot.  I wish I could.  In order for me to cut down the # of
parameters, I'd have to modify the workflow process which could
potentially aggitate our users.  I will try this locally, but I'm almost
certain that my testing will be futile since I've yet to recreate the
scenario.  Any other ideas?  

I did speak with someone over the phone today who contacted me regarding
this post.  It seems as though they have experienced the same problem
with Tomcat 4 and 5.  He seemed to believe it was related to load.  I
know that our website typically operates at roughly 80 users at a time.
At our peak, 200 users.  So, I'm not so sure it is related to load, but
I'm going to do some further investigating in our test environment with
a load tester to see if I can recreate the problem.

___
Jeremy Nix
Senior Application Developer
Southwest Financial Services, LTD.
(513) 621-6699 x1158
www.sfsltd.com



-Original Message-
From: Yoav Shapira [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, September 27, 2005 2:06 PM
To: Tomcat Developers List
Subject: Re: Problems Parsing Request Paramers


Hi,
Could it be the referer URL is too long, causing the query string to be
ignored or dropped?  There's a limit (2048 characters, I think?) on GET
requests in some browsers.  But actually, you're seeing this on the
server, so I'm not sure.  Can you try testing with less parameters or an
otherwise shorter query string?

Yoav

--- Jeremy Nix [EMAIL PROTECTED] wrote:

 First off, I apologize for the cross-post.  I posted this same message
 in the User's mailing list with no replies.   So, my hope is that one
of
 you developers may have some insight into the problem that I'm having.
 
 Certain users of my website are having issues with respect to 
 submitting a form on a page.  Not all users are experiencing this 
 problem, and I've yet to replicate it myself so it makes the situation

 even more complex. I have an icking suspicion that its related to the 
 user's browser, but I've tested on the same browser version/subversion

 without a glitch. Here's the scenario:
 1) User goes to page.
 2) User fills out form.
 3) User clicks submit.
 4) JSP page then performs sanity checks against submitted data.  In 
 the event of a failure on the sanity checks, page is redirected back 
 to previous page.
 
 Simple enough.  Well, users are filling out the form and clicking 
 submit with valid infromation, yet when I parse the parameters out of 
 the request, I'm finding none of the form values from the previous 
 page.  I then decided to investigate further and log out all request 
 information in the event that these sanity checks fail.  The following

 is what I logged out:
 --
 --
 -
 Attributes:
   javax.servlet.request.cipher_suite = [SSL_RSA_WITH_RC4_128_MD5]
   javax.servlet.request.key_size = [128]
   javax.servlet.request.ssl_session =
 [433162398579970fee9289baa9ac832b8558dcc409382f62cb67a3499b80]
 Parameters:
 Cookies:
  JSESSIONID = [FCB31837FFBD2C0D9F986C42B698BADE]
  contact_value = [ABC]
  duplicate_type = [None]
  duplicate_time = []
  mortgage = []
  lender_id_label = []
  title_alternative = []
  can_place_orders = [Y]
  flood_default = [126]
  can_cancel_lol = [N]
  contact_label = []
  lender_id_value = [ABC]
  census = []
  loan_no_label = []
  delivery_method = [Online]
  apprasail = []
  delivery_address = []
  title = []
 Headers:
   accept = [image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
 application/vnd.ms-excel, application/msword,
 application/vnd.ms-powerpoint, application/x-shockwave-flash, */*]
   referer =

[https://WEBSITE_URL/CreateOrder.jsp?applicant2HomePhone=streetName=Ma
 in+Stapplicant2WorkPhone=applicantOtherPhone=ownerEstimate=applica
 in+nt
 2WorkPhone2=revisionOf=applicantWorkPhoneExtension=unitType=preFix
 Di

r=Eapplicant2OtherPhoneAreaCode=applicantOtherPhone2=applicantMname=L

skipstep=nonezip4=applicant2HomePhoneAreaCode=applicant2OtherPhone=

applicantLname=DoestreetNum=applicantHomePhoneAreaCode=zip=40845pass

code=HomeorderHeaderGeneralNotes=applicantHomePhone2=propertyLoanNumb

er=productTitle=applicantFname=Johnapplicant2WorkPhoneExtension=appl

icant2WorkPhoneAreaCode=applicant2Mname=JunitNumber=applicantWorkPhon

eAreaCode=postFixDir=productAppraisal=propertyParcelNumber=applicant

WorkPhone2=applicantOtherPhoneAreaCode=city=HulenapplicantHomePhone=

applicantWorkPhone=applicant2Lname=Janeapplicant2OtherPhone2=applican

t2HomePhone2=streetType=state=KYcontactId=10productMortgagePrep=pro
 ductFlood=Yesapplicant2Fname=Doe]
   accept-language = [en-us]
   content-type = [application/x-www-form-urlencoded]
   accept-encoding = [gzip, deflate]
   user-agent = [Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;
 .NET CLR 1.1.4322)]
   

Re: Problems Parsing Request Paramers

2005-09-27 Thread Rick Knowles

Yoav Shapira wrote:


Hi,
Could it be the referer URL is too long, causing the query string to be ignored
or dropped?  There's a limit (2048 characters, I think?) on GET requests in
some browsers.  But actually, you're seeing this on the server, so I'm not
sure.  Can you try testing with less parameters or an otherwise shorter query
string?



I've seen this sort of thing too, but I thought it was 255 chars. From
RFC2616 section 3.2.1:

Note: Servers ought to be cautious about depending on URI lengths above
255 bytes, because some older client or proxy implementations might not
properly support these lengths. 

Not quite set in stone, but a good general hint to avoid long URLs.

Rick

--
Servlet v2.4 container in a single 155KB jar file ? Try Winstone 
(http://winstone.sourceforge.net/)



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



isapi_redirect expert?

2005-09-27 Thread David Thielen
Hi;

 

I understand it is a big no-no to ask user questions on this list. But I
have three questions about isapi_redirect that no one on the user list seems
to know the answer to.

 

If I can post them here and I get an answer, I would be happy to write up
the solution for posting on the tomcat site as I know others are hitting
these same questions.

 

??? - Thanks - dave

 

David Thielen

303-499-2544

www.windwardreports.com

 



Re: isapi_redirect expert?

2005-09-27 Thread Tim Whittington
If it's undocumented behaviour or it's a clear gap in the documentation 
(i.e a doc bug) then it might be appropriate here.

Otherwise, send them through to me and I'll see if I can help.

tim

David Thielen wrote:


Hi;



I understand it is a big no-no to ask user questions on this list. But I
have three questions about isapi_redirect that no one on the user list seems
to know the answer to.



If I can post them here and I get an answer, I would be happy to write up
the solution for posting on the tomcat site as I know others are hitting
these same questions.



??? - Thanks - dave



David Thielen

303-499-2544

www.windwardreports.com




 



Please verify this is correct: Need multiple virtual directories for isapi_redirector

2005-09-27 Thread David Thielen
Note: I looked and looked and couldn't find this documented.

Hi;

I want to make sure this is correct:

If you want to run Tomcat against multiple websites, not just the default
website, this is what I have had to do.

This is on Windows 2003/IIS 6.0.

I removed isapi_redirector.dll from the default web site ISAPI Filters and
put it in the parent Web Sites ISAPI Filter properties.

I added a jakarta virtual directory for each website (and I have a lot.).

Now it appears to work.

??? - thanks - dave



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



What is correct for workers.properties.minimal

2005-09-27 Thread David Thielen
Hi;

 

I'm running Tomcat 5.5 on Windows 2003/IIS 6.0 using isapi_redirect

 

The isapi_redirect.exe installer creates a worker.properties.minimal of:

  worker.list=wlb,jkstatus

  worker.ajp13w.type=ajp13

  worker.ajp13w.host=localhost

  worker.ajp13w.port=8009

  worker.wlb.type=lb

  worker.wlb.balance_workers=ajp13w

  worker.jkstatus.type=status

 

While the docs show one of:

  worker.list=ajp13w

  worker.ajp13w.type=ajp13

  worker.ajp13w.host=localhost

  worker.ajp13w.port=8009

 

First, what use is the load balancing if I have just one server running one
instance of Tomcat? Does it load balance within that one instance?

 

Second, what is jkstatus for?

 

Thanks - dave

 

 

David Thielen

303-499-2544

www.windwardreports.com

 



Re: Please verify this is correct: Need multiple virtual directories for isapi_redirector

2005-09-27 Thread Yoav Shapira
Hi,
Please use tomcat-user@jakarta.apache.org for user support issues.  The
tomcat-dev list is for discussion regarding Tomcat's own internal development. 
Thank you,

Yoav

--- David Thielen [EMAIL PROTECTED] wrote:

 Note: I looked and looked and couldn't find this documented.
 
 Hi;
 
 I want to make sure this is correct:
 
 If you want to run Tomcat against multiple websites, not just the default
 website, this is what I have had to do.
 
 This is on Windows 2003/IIS 6.0.
 
 I removed isapi_redirector.dll from the default web site ISAPI Filters and
 put it in the parent Web Sites ISAPI Filter properties.
 
 I added a jakarta virtual directory for each website (and I have a lot.).
 
 Now it appears to work.
 
 ??? - thanks - dave
 
 
 
 -
 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 36834] New: - Wrong message length in body chunks ?

2005-09-27 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36834.
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=36834

   Summary: Wrong message length in body chunks ?
   Product: Tomcat 5
   Version: Unknown
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Native:JK
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


jk_ajp13.h uses (line 43): AJP13_MAX_SEND_BODY_SZ = DEF_BUFFER_SZ - 6

but the start of the message is

2 header bytes
2 bytes for the message length
1 byte for the message type
2 bytes for the chunk length.

= a total of 7 bytes.  

The buffer usable space should be DEF_BUFFER_SZ - 7, if I'm not wrong

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



cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader WebappClassLoader.java

2005-09-27 Thread jfarcand
jfarcand2005/09/27 16:42:53

  Modified:catalina/src/share/org/apache/catalina/loader
WebappClassLoader.java
  Log:
  Port fix from SJSAS.
  
  Patch submitted by: Jan Luehe
  
  Revision  ChangesPath
  1.51  +16 -3 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java
  
  Index: WebappClassLoader.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java,v
  retrieving revision 1.50
  retrieving revision 1.51
  diff -u -r1.50 -r1.51
  --- WebappClassLoader.java8 Sep 2005 15:00:54 -   1.50
  +++ WebappClassLoader.java27 Sep 2005 23:42:53 -  1.51
  @@ -1470,6 +1470,21 @@
*/
   public void stop() throws LifecycleException {
   
  +/*
  + * Clear the IntrospectionUtils cache.
  + *
  + * Implementation note:
  + * Any reference to IntrospectionUtils which may cause the static
  + * initalizer of that class to be invoked must occur prior to setting
  + * the started flag to FALSE, because the static initializer of
  + * IntrospectionUtils makes a call to
  + * org.apache.commons.logging.LogFactory.getLog(), which ultimately
  + * calls the loadClass() method of the thread context classloader,
  + * which is the same as this classloader, whose impl throws a
  + * ThreadDeath if the started flag has been set to FALSE.
  + */
  +IntrospectionUtils.clear();
  +
   started = false;
   
   int length = files.length;
  @@ -1515,8 +1530,6 @@
   org.apache.commons.logging.LogFactory.release(this);
   // Clear the classloader reference in the VM's bean introspector
   java.beans.Introspector.flushCaches();
  -// Clear the IntrospectionUtils cache
  -IntrospectionUtils.clear();
   
   }
   
  
  
  

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



TC v5.5.12 Breaks v5.5.9 Configuration

2005-09-27 Thread Bob Bronson

Hi all,

Pardon my post to the dev group. I already posted to the User list 
but received no useful response.


I've just tried to upgrade from TC v5.5.9 to v5.5.12 and it seems my 
(very simple) configuration is now broken.


The following configuration works beautifully under 5.5.9 -- no 
exceptions, no warnings, just utter perfection.


Here's a description of my configuration (BTW, CATALINA_HOME and 
JAvA_HOME are fine, I'm sure they're not causing the problem).


I have CATALINA_BASE set like this:
  C:\Projects\Configs\

Within this Configs directory I have two sub-directories: conf and 
Engine_01 like this:


  C:\Projects\Configs\
  |
  +-conf\
  |  |
  |  +-server.xml
  |  +-web.xml
  |
  +-Engine01\
  |  |
  |  +-localhost\
  |  |  |
  |  |  +-ROOT.xml


Within the conf directory I have my server.xml and the default 
web.xml files. Here is the server.xml contents:


Server port=10035 shutdown=SHUTDOWN debug=0
 Service name=Catalina
   Connector port=80 /
   Engine name=ENGINE_01 defaultHost=localhost
 Host name=localhost appBase=..\Sites\Test 1/
   /Engine
 /Service
/Server


Notice I have named the engine, Engine_01.

As you can see, in the Engine_01 directory I have a subdirectory, 
localhost, which contains a context fragment file named, ROOT.xml. 
Here is the contents of ROOT.xml:


  Context path= docBase=/


In my server.xml you'll notice I have my appBase property set to 
..\Sites\Test 1. Here is the Sites directory structure:


  C:\Projects\Sites\
  |
  +-Test 1\
  |
  +-index.html
  +-WEB-INF\
  |
  +-web.xml
  +-classes\
  +-root\


It's all quite simple, I think. When I run under v5.5.9, this 
configuration works perfectly, as I said.


Using the EXACT SAME configuration, running under v5.5.12, I see this 
WARNING and EXCEPTION when I start TC:


WARNING: A docBase C:\Projects\Sites\Test 1\. inside the host appBase 
has been specified, and will be ignored
Sep 26, 2005 8:37:22 PM org.apache.catalina.core.StandardContext 
resourcesStart

SEVERE: Error starting static Resources
java.lang.IllegalArgumentException: Document base 
C:\Projects\Configs\..\Sites\Test 1\ROOT does not exist or is not a 
readable directory
   at 
org.apache.naming.resources.FileDirContext.setDocBase(FileDirContext.java:140)
   at 
org.apache.catalina.core.StandardContext.resourcesStart(StandardContext.java:3777)
   at 
org.apache.catalina.core.StandardContext.start(StandardContext.java:3948)
   at 
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759)
   at 
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739)
   at 
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524)
   at 
org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:603)
   at 
org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:535)
   at 
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:470)
   at 
org.apache.catalina.startup.HostConfig.start(HostConfig.java:1118)
   at 
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:310)
   at 
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
   at 
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1020)
   at 
org.apache.catalina.core.StandardHost.start(StandardHost.java:718)
   at 
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1012)
   at 
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442)
   at 
org.apache.catalina.core.StandardService.start(StandardService.java:450)
   at 
org.apache.catalina.core.StandardServer.start(StandardServer.java:680)
   at 
org.apache.catalina.startup.Catalina.start(Catalina.java:536)

   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown 
Source)

   at java.lang.reflect.Method.invoke(Unknown Source)
   at 
org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:275)
   at 
org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)

Sep 26, 2005 8:37:22 PM org.apache.catalina.core.StandardContext start
SEVERE: Error in resourceStart()
Sep 26, 2005 8:37:22 PM org.apache.catalina.core.StandardContext start
SEVERE: Error getConfigured
Sep 26, 2005 8:37:22 PM org.apache.catalina.core.StandardContext start
SEVERE: Context [] startup failed due to previous errors
Sep 26, 2005 8:37:22 PM org.apache.catalina.core.StandardContext stop
INFO: Container 
org.apache.catalina.core.ContainerBase.[ENGINE_01].[localhost].[/] has 
not been started
Sep 26, 2005 8:37:23 PM org.apache.coyote.http11.Http11BaseProtocol 
start

INFO: Starting Coyote HTTP/1.1 on http-80
Sep 26, 2005 8:37:23 PM 

DO NOT REPLY [Bug 36834] - Wrong message length in body chunks ?

2005-09-27 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36834.
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=36834


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]
   ||com




-- 
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 36834] - Wrong message length in body chunks ?

2005-09-27 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36834.
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=36834


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2005-09-28 06:35 ---
Request Body messages don't have a 'type' field in the AJP/1.3 protocol.

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