DO NOT REPLY [Bug 34833] New: - JK connector fails to failover
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=34833. 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=34833 Summary: JK connector fails to failover Product: Tomcat 5 Version: Unknown Platform: PC OS/Version: Linux Status: NEW Severity: major Priority: P2 Component: Native:JK AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] JK 1.2.12 doesn't fail over properly if a server cannot be reached. This appears to be a regression--the same scenario works perfectly under 1.2.6. I have 2 tomcat instances on machines called clemens and feynman. Apache is running on Feynman and has a load-balancing workers.properties file. If I shut off the tomcat server on Feynman, and leave the server running on clemens, I get the following errors: [Tue May 10 00:58:33 2005] [info] jk_open_socket::jk_connect.c (433): connect \ to 127.0.0.1:8009 failed with errno=111 [Tue May 10 00:58:33 2005] [info] ajp_connect_to_endpoint::jk_ajp_common.c (89\ 2): Failed opening socket to (127.0.0.1:8009) with (errno=111) [Tue May 10 00:58:33 2005] [info] ajp_send_request::jk_ajp_common.c (1248): Er\ ror connecting to the Tomcat process. [Tue May 10 00:58:33 2005] [info] ajp_service::jk_ajp_common.c (1746): Sending\ request to tomcat failed, recoverable operation attempt=1 [Tue May 10 00:58:33 2005] [info] jk_open_socket::jk_connect.c (433): connect \ to 127.0.0.1:8009 failed with errno=111 [Tue May 10 00:58:33 2005] [info] ajp_connect_to_endpoint::jk_ajp_common.c (89\ 2): Failed opening socket to (127.0.0.1:8009) with (errno=111) [Tue May 10 00:58:33 2005] [info] ajp_send_request::jk_ajp_common.c (1248): Er\ ror connecting to the Tomcat process. [Tue May 10 00:58:33 2005] [info] ajp_service::jk_ajp_common.c (1746): Sending\ request to tomcat failed, recoverable operation attempt=2 [Tue May 10 00:58:33 2005] [info] jk_open_socket::jk_connect.c (433): connect \ to 127.0.0.1:8009 failed with errno=111 [Tue May 10 00:58:33 2005] [info] ajp_connect_to_endpoint::jk_ajp_common.c (89\ 2): Failed opening socket to (127.0.0.1:8009) with (errno=111) [Tue May 10 00:58:33 2005] [info] ajp_send_request::jk_ajp_common.c (1248): Er\ ror connecting to the Tomcat process. [Tue May 10 00:58:33 2005] [info] ajp_service::jk_ajp_common.c (1746): Sending\ request to tomcat failed, recoverable operation attempt=3 [Tue May 10 00:58:33 2005] [error] ajp_service::jk_ajp_common.c (1755): Error c\ onnecting to tomcat. Tomcat is probably not started or is listening on the wron\ g port. worker=feynman failed [Tue May 10 00:58:33 2005] [error] service::jk_lb_worker.c (632): unrecoverable\ error 503, request failed. Tomcat failed in the middle of request, we can't re\ cover to another instance. The diagnostics are incorrect. Tomcat could not have failed in the middle of request, because that server was never reachable in the first place. There's something wrong in the logic here. The log file never shows JK attempting to fail over to the other (perfectly working) tomcat instance in this case. The other server handles requests fine during this time--it's just never contacted. Load balancing file attached below: # Define the load-balancing router worker.list=router # Configure the router worker.router.type=lb worker.router.balanced_workers=clemens,feynman #worker.router.balance_workers=clemens,feynman worker.router.local_worker_only=0 # Set properties for clemens (ajp13) worker.clemens.type=ajp13 worker.clemens.host=clemens worker.clemens.port=8009 worker.clemens.lbfactor=80 #worker.clemens.cachesize=10 worker.clemens.cache_timeout=300 worker.clemens.socket_keepalive=0 worker.clemens.socket_timeout=100 worker.clemens.local_worker=0 # Set properties for feynman (ajp13) worker.feynman.type=ajp13 worker.feynman.host=feynman worker.feynman.port=8009 worker.feynman.lbfactor=300 #worker.feynman.cachesize=10 worker.feynman.cache_timeout=300 worker.feynman.socket_keepalive=0 worker.feynman.socket_timeout=100 worker.feynman.local_worker=1 Again, reverting to 1.2.6 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]
[ANN] Memory Profiling with Reference Scanner
Hi all, some news about Reference Scanner, frequently used to find memory leaks in tomcat and webapplications: -1- Profiling of tomcat and webapplications has been simplified yet: In earlier versions of Reference Scanner it was required to patch thesource code (Bootstrap.java), this is not required anymore. Simply call the Reference Scanner Launcher within the start script catalina.sh, that's all. http://jb2works.com/refscan/start.html#tomcat -2- Furthermore, we have now plugins for Eclipse and IntelliJ-IDEA. http://jb2works.com/refscan/plugins.html - Reference Scanner Summary - Use your web browser and inspect your running Java application. Create memory snapshots and compare against each other. Analyze reference graphs. Find memory leaks. Test elimination ofmemory leaks without to change in code. Your application runs at normal speed. Does not require JVMPI debug mode. Simply add this memory profiler .jar, 835kbyte. usage/ current screenshots http://jb2works.com/refscan/usage.html download http://jb2works.com/refscan/status.html faq http://jb2works.com/refscan/faq.html Best Regards, Joerg Baumgaertel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_lb_worker.c
mturk 2005/05/10 02:23:33
Modified:jk/native/common jk_lb_worker.c
Log:
Fix bug 34833 making failover to work.
Revision ChangesPath
1.83 +2 -2 jakarta-tomcat-connectors/jk/native/common/jk_lb_worker.c
Index: jk_lb_worker.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_lb_worker.c,v
retrieving revision 1.82
retrieving revision 1.83
diff -u -r1.82 -r1.83
--- jk_lb_worker.c5 May 2005 19:48:03 - 1.82
+++ jk_lb_worker.c10 May 2005 09:23:33 - 1.83
@@ -625,7 +625,7 @@
rec-s-in_recovering = JK_FALSE;
rec-s-error_time = time(NULL);
-if (is_service_error JK_HTTP_OK) {
+if (is_service_error != JK_HTTP_SERVER_BUSY) {
/*
* Error is not recoverable - break with an error.
*/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34833] - JK connector fails to failover
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=34833. 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=34833 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-05-10 11:24 --- Fixed in the CVS. -- 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]
JK 1.2.12 is broken and can not be released as stable
There was a nasty bug in load balancer, that basically broke the failover. Interesting is that it was spotted only when the release was made, so this gives one reason more for making some sort of releases and binaries to attract more users to actually do the testing. My question is what to do? I would really hate to wait for a month or so for the next release, and obviously we can not declare the 1.2.12 as stable due to this bug. We can retag and release 1.2.13, or just wait if something else will arise and have some vacation in the mean time :). Bill will love this, for sure ;) Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project jakarta-tomcat-jk-native (in module jakarta-tomcat-connectors) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project jakarta-tomcat-jk-native has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 143 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - jakarta-tomcat-jk-native : Connectors to various web servers Full details are available at: http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed The following work was performed: http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/gump_work/build_jakarta-tomcat-connectors_jakarta-tomcat-jk-native.html Work Name: build_jakarta-tomcat-connectors_jakarta-tomcat-jk-native (Type: Build) Work ended in a state of : Failed Elapsed: Command Line: make [Working Directory: /usr/local/gump/public/workspace/jakarta-tomcat-connectors/jk/native] - Making all in common make[1]: Entering directory `/home/gump/workspaces2/public/workspace/jakarta-tomcat-connectors/jk/native/common' /bin/sh /usr/local/gump/public/workspace/apache-httpd/dest-10052005/build/libtool --silent --mode=compile gcc -I/usr/local/gump/public/workspace/apache-httpd/dest-10052005/include -g -O2 -g -O2 -pthread -DHAVE_APR -I/usr/local/gump/public/workspace/apr/dest-10052005/include/apr-1 -g -O2 -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I/home/gump/workspaces2/public/workspace/apache-httpd/srclib/pcre -I /opt/jdk1.4/include -I /opt/jdk1.4/include/ -c jk_ajp12_worker.c /usr/local/gump/public/workspace/apache-httpd/dest-10052005/build/libtool: /usr/local/gump/public/workspace/apache-httpd/dest-10052005/build/libtool: No such file or directory make[1]: *** [jk_ajp12_worker.lo] Error 127 make[1]: Leaving directory `/home/gump/workspaces2/public/workspace/jakarta-tomcat-connectors/jk/native/common' make: *** [all-recursive] Error 1 - To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/rss.xml - Atom: http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2310052005, brutus:brutus-public:2310052005 Gump E-mail Identifier (unique within run) #18. -- Apache Gump http://gump.apache.org/ [Instance: brutus] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: Project jakarta-tomcat-jk-native (in module jakarta-tomcat-connectors) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project jakarta-tomcat-jk-native has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 143 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - jakarta-tomcat-jk-native : Connectors to various web servers Full details are available at: http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed The following work was performed: http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/gump_work/build_jakarta-tomcat-connectors_jakarta-tomcat-jk-native.html Work Name: build_jakarta-tomcat-connectors_jakarta-tomcat-jk-native (Type: Build) Work ended in a state of : Failed Elapsed: Command Line: make [Working Directory: /usr/local/gump/public/workspace/jakarta-tomcat-connectors/jk/native] - Making all in common make[1]: Entering directory `/home/gump/workspaces2/public/workspace/jakarta-tomcat-connectors/jk/native/common' /bin/sh /usr/local/gump/public/workspace/apache-httpd/dest-10052005/build/libtool --silent --mode=compile gcc -I/usr/local/gump/public/workspace/apache-httpd/dest-10052005/include -g -O2 -g -O2 -pthread -DHAVE_APR -I/usr/local/gump/public/workspace/apr/dest-10052005/include/apr-1 -g -O2 -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I/home/gump/workspaces2/public/workspace/apache-httpd/srclib/pcre -I /opt/jdk1.4/include -I /opt/jdk1.4/include/ -c jk_ajp12_worker.c /usr/local/gump/public/workspace/apache-httpd/dest-10052005/build/libtool: /usr/local/gump/public/workspace/apache-httpd/dest-10052005/build/libtool: No such file or directory make[1]: *** [jk_ajp12_worker.lo] Error 127 make[1]: Leaving directory `/home/gump/workspaces2/public/workspace/jakarta-tomcat-connectors/jk/native/common' make: *** [all-recursive] Error 1 - To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/rss.xml - Atom: http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2310052005, brutus:brutus-public:2310052005 Gump E-mail Identifier (unique within run) #18. -- Apache Gump http://gump.apache.org/ [Instance: brutus] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK 1.2.12 is broken and can not be released as stable
On Tue, May 10, 2005 at 11:33:56AM +0200, Mladen Turk wrote: There was a nasty bug in load balancer, that basically broke the failover. Interesting is that it was spotted only when the release was made, so this gives one reason more for making some sort of releases and binaries to attract more users to actually do the testing. My question is what to do? I am observing these mod_jk issues quite some time lurking on tomcat-dev and from a user POV I'd really appreciate a fork of mod_jk into 1.2 stable and 1.3 (or whatsoever) unstable. During 1.2 development after 1.2.5 serious changes have been added that a) broke compabilty and b) added new features that introduced a lot of new issues and bugs. Don't take me wrong, mod_jk is a great peace of software and the new features are really good in concept, but IMHO I would not consider any mod_jk release after 1.2.6 stable. Mladen has done a great Job in improving mod_jk, but I think that this sort of changes require a new branch. And finally another issue about mod_jk ... lack of dokumentation. I think I have seen the local_worker issue several times on the dev list, and I am not watching the user list. Wouldn't it be easier to document the newer redirect features than answering tons of mails from users that ask for it. I am neither a contirbutor, nor a developer nor a member of asf, so my opinion may not weight much... regards Klaus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34835] New: - strange problem--In two different time , it is showing different figure from static database
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=34835. 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=34835 Summary: strange problem--In two different time , it is showing different figure from static database Product: Tomcat 5 Version: 5.0.9 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Servlet JSP API AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] We are running JSP based program from it. In 1 minutes difference it is showing different figure whereas this figure is shown from the past stored data -- 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.12 is broken and can not be released as stable
Well the JK 1.2 branch should be fixed and when we'll have something stable, we could start a new branch. BTW, there was many bugs related to LB in jk for ages :-) 2005/5/10, Klaus Wagner [EMAIL PROTECTED]: On Tue, May 10, 2005 at 11:33:56AM +0200, Mladen Turk wrote: There was a nasty bug in load balancer, that basically broke the failover. Interesting is that it was spotted only when the release was made, so this gives one reason more for making some sort of releases and binaries to attract more users to actually do the testing. My question is what to do? I am observing these mod_jk issues quite some time lurking on tomcat-dev and from a user POV I'd really appreciate a fork of mod_jk into 1.2 stable and 1.3 (or whatsoever) unstable. During 1.2 development after 1.2.5 serious changes have been added that a) broke compabilty and b) added new features that introduced a lot of new issues and bugs. Don't take me wrong, mod_jk is a great peace of software and the new features are really good in concept, but IMHO I would not consider any mod_jk release after 1.2.6 stable. Mladen has done a great Job in improving mod_jk, but I think that this sort of changes require a new branch. And finally another issue about mod_jk ... lack of dokumentation. I think I have seen the local_worker issue several times on the dev list, and I am not watching the user list. Wouldn't it be easier to document the newer redirect features than answering tons of mails from users that ask for it. I am neither a contirbutor, nor a developer nor a member of asf, so my opinion may not weight much... regards Klaus - 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 34840] New: - updating war - tomcat removes mycontext.xml
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=34840. 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=34840 Summary: updating war - tomcat removes mycontext.xml Product: Tomcat 5 Version: 5.5.9 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] I've a new installed tomcat and placed mycontext.xml (conf/Catalina/localhost): Context docBase=/somewhere/somewhat.war / After updating somewhat.war tomcat removes mycontext.xml! So the application will not be deployed correctly. The tomcat docs (tomcat-docs/config/host.html#Automatic%20Application%20Deployment) says: An update to a WAR which has been expanded will trigger an undeploy (with a removal of the expanded webapp), followed by a deployment -- 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 24897] - Getting IOException when line length exceeds 4096
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=24897. 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=24897 --- Additional Comments From [EMAIL PROTECTED] 2005-05-10 15:40 --- (In reply to comment #2) (In reply to comment #1) This is a (reasonable) limit that I did put in on purpose. See the CoyoteReader source for the constant (and recompile to change it for special purpose applications). I don't understand how this is reasonable. If someone sending a request to a webservice, and the request is well formed (doesn't have to have line breaks to be well formed), and it is a request with a lot of data, then this breaks it. Maybe I'm missing something, I don't want to have to force my clients to to insert line breaks in their XML requests when there is nothing in the W3C standard that says XML requests have to contain line breaks. Am I missing something? This seems to have been fixed in version 5.5.4. -- 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 34842] New: - jk-1.2.8-12 buffer overrun failure with .net enabled IIS 5 on xp pro sp 2
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=34842.
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=34842
Summary: jk-1.2.8-12 buffer overrun failure with .net enabled IIS
5 on xp pro sp 2
Product: Tomcat 5
Version: 5.5.9
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: critical
Priority: P4
Component: Native:JK
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
Hi,
We have had issues with getting JK1.2.8 and JK1.2.12 talking to Tomcat on 2 XP
Pro boxes with SP2 but no such problems with W2K.
When requesting a mapped URL, we are prompted to open/save a 180KB file (the
isapi_redirect I reckon) which is mostly garbage except for the following
segment which reveals a .NET related problem...
Is this a known issue, does a later JK solve this issue? We consider this a
critical problem since IT are rolling out XP Pro to our development machines.
Kindest regards, Allistair.
©¦ªtx*
îçe+000 ð? À~PA
ÿÿGAIsProcessorFeaturePresent KERNEL32CorExitProcess mscoree.dll
¿¡ï¢ ¦SunMonTueWedThuFriSat
JanFebMarAprMayJunJulAugSepOctNovDecTZ ±
U±º
ºJºNºruntime error
TLOSS error
SING error
DOMAIN error
R6029
- This application cannot run using the active version of the Microsoft .NET
Runtime
Please contact the application's support team for more information.
R6028
- unable to initialize heap
R6027
- not enough space for lowio initialization
R6026
- not enough space for stdio initialization
R6025
- pure virtual function call
R6024
- not enough space for _onexit/atexit table
R6019
- unable to open console device
R6018
- unexpected heap error
R6017
- unexpected multithread lock error
R6016
- not enough space for thread data
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
R6009
- not enough space for environment
R6008
- not enough space for arguments
R6002
- floating point not loaded
Microsoft Visual C++ Runtime Library
Runtime Error!
Program:... program name unknown
InitializeCriticalSectionAndSpinCount ý½
¾
#¿
( ( ( (
( H
h ( ( (
( H
H
®Á²ÁProgram:A buffer overrun has been
detected which has corrupted the program's
internal state. The program cannot safely continue execution and must
now be terminated.
Buffer overrun detected!A security error of unknown cause has been
detected which has
corrupted the program's internal state. The program cannot safely
continue execution and must now be terminated.
Unknown security failure detected! ÞÇâÇÊÊ
MÍîÎNÎÏ6Ü:ÜÐÜÔÜ
oáæã9çGetProcessWindowStation
GetUserObjectInformationA GetLastActivePopup GetActiveWindow MessageBoxA
user32.dll 1#QNAN 1#INF 1#IND 1#SNAN ³ñ
åò.com.bat.cmd.exe./\ ?* ú`þdþ
,0µ¹H
DO NOT REPLY [Bug 34842] - jk-1.2.8-12 buffer overrun failure with .net enabled IIS 5 on xp pro sp 2
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=34842. 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=34842 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-05-10 16:48 --- my stupid mistake .. this is caused by not creating a virtual directory called jakarta with execute rights *sigh* ignore me. -- 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 34835] - strange problem--In two different time , it is showing different figure from static database
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=34835. 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=34835 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-05-10 19:51 --- Try the tomcat-user list. If you want a useful response you are going to have to provide a lot more informatino than this. -- 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 34840] - updating war - tomcat removes mycontext.xml
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=34840. 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=34840 --- Additional Comments From [EMAIL PROTECTED] 2005-05-10 20:23 --- I don't think this use case will be handled, sorry. I'll likely mark this as wontfix. -- 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 24897] - Getting IOException when line length exceeds 4096
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=24897. 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=24897 --- Additional Comments From [EMAIL PROTECTED] 2005-05-10 20:26 --- This cannot be unlimited, so 4KB is a very reasonable constant. Using this method will make your application *extremely* inefficient, BTW. -- 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 34829] - IOException in InputBuffer when reading xml from post
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=34829. 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=34829 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2005-05-10 20:27 --- Without further comments or test case - duplicate. *** This bug has been marked as a duplicate of 24897 *** -- 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 24897] - Getting IOException when line length exceeds 4096
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=24897. 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=24897 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2005-05-10 20:27 --- *** Bug 34829 has been marked as a duplicate of this bug. *** -- 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 34840] - updating war - tomcat removes mycontext.xml
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=34840. 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=34840 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2005-05-10 20:42 --- Updating the war means you want to fully redeploy. Your war doesn't contain the context.xml, so no redeployment occurs. You should drop the .xml again after the war update in this case. Sorry, there's no other solution (doing otherwise would break other cases), this is not a bug. -- 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 34840] - updating war - tomcat removes mycontext.xml
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=34840. 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=34840 --- Additional Comments From [EMAIL PROTECTED] 2005-05-10 20:42 --- Updating the war means you want to fully redeploy. You should drop the .xml again after the war update in this case. Sorry, there's no other solution (doing otherwise would break other cases), this is not a bug. -- 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/connector Request.java
markt 2005/05/10 13:51:43
Modified:catalina/src/share/org/apache/catalina/connector
Request.java
Log:
Fix NPE when POST size exceeds limit set by maxPostSize. Also remove log
attribute
since it is never used.
Revision ChangesPath
1.24 +4 -9
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/Request.java
Index: Request.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/Request.java,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- Request.java 28 Apr 2005 12:30:38 - 1.23
+++ Request.java 10 May 2005 20:51:43 - 1.24
@@ -68,7 +68,7 @@
import org.apache.catalina.util.RequestUtil;
import org.apache.catalina.util.StringManager;
import org.apache.catalina.util.StringParser;
-import org.apache.commons.logging.Log;
+
/**
* Wrapper object for the Coyote request.
@@ -350,11 +350,6 @@
*/
protected String localName = null;
-/** After the request is mapped to a ServletContext, we can also
- * map it to a logger.
- */
-protected Log log=null;
-
// - Public
Methods
/**
@@ -399,7 +394,6 @@
requestedSessionCookie = false;
requestedSessionId = null;
requestedSessionURL = false;
-log = null;
parameterMap.setLocked(false);
parameterMap.clear();
@@ -2347,7 +2341,8 @@
if (len 0) {
int maxPostSize = connector.getMaxPostSize();
if ((maxPostSize 0) (len maxPostSize)) {
-log.info(sm.getString(coyoteRequest.postTooLarge));
+context.getLogger().info
+(sm.getString(coyoteRequest.postTooLarge));
throw new IllegalStateException(Post too large);
}
try {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK 1.2.12 is broken and can not be released as stable
At 04:33 AM 5/10/2005, Mladen Turk wrote: Interesting is that it was spotted only when the release was made, so this gives one reason more for making some sort of releases and binaries to attract more users to actually do the testing. Agreed that development releases (early and often) are a very good thing. They need the same 3 +1 votes (more + than -) but have a much lower barrier of entry. (Is it tar'red complete? Does it build? Do some basic regressions work?) We can retag and release 1.2.13, or just wait if something else will arise and have some vacation in the mean time :). I'd suggest 1) tag 1.2.13 with any bug fixes in the past week or two. Give me this evening to commit a small tweak to the Win32 .dsp project compile flags, which emit much more legible user.dmp crash analysis output. (I found this out over the weekend.) 2) let it ride - skip adding any new features till it shakes out, at least to 1.2. If someone wants to add some new stuff, make a CVS branch to develop it on, or fork 1.3 already depending on the desired patches. 3) wait for something else to arise, put together the docs on the newest features, and in, say, 3 weeks after 1.2.13 is announced, bless 1.2.14 as the next stable release. And 4) pull down 1.2.11 which was never released (according to your judgement) and 1.2.12 (which is broke, and obviously confuses users who were used to the odds-evens system of dev and stable tarballs.) If they are needed by the occasional user, archive.apache.org/dist/ is the place to look. What is the thought, is 1.2.10 stable? 1.2.8? Or 1.2.6? I'm partial to 1.2.8 myself. Bill will love this, for sure ;) Nope - I hoped 1.2.12 would pan out, I just wasn't planning to endorse it for another three weeks or so. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
