DO NOT REPLY [Bug 35896] - Tomcat stoped service apache request
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=35896. 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=35896 --- Additional Comments From [EMAIL PROTECTED] 2005-07-28 08:56 --- Created an attachment (id=15807) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15807action=view) tomcat.log Pleas, find in the attachment tomcat logs from time the problem occured -- 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 35896] - Tomcat stoped service apache request
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=35896. 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=35896 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-07-28 09:55 --- It seems that you are using the (deprecated) AJP12Interceptor with the AJP/1.3 version of mod_jk. Try again with the Coyote AJP/1.3 Connector (or even the AJP13Interceptor. -- 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 35908] - Java JVM crashes
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=35908. 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=35908 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE Summary|Java JVM crashes|Java JVM crashes --- Additional Comments From [EMAIL PROTECTED] 2005-07-28 12:37 --- *** This bug has been marked as a duplicate of 35907 *** -- 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 35907] - Java JVM crashes
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=35907. 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=35907 --- Additional Comments From [EMAIL PROTECTED] 2005-07-28 12:37 --- *** Bug 35908 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 35907] - Java JVM crashes
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=35907. 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=35907 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID Summary|Java JVM crashes|Java JVM crashes --- Additional Comments From [EMAIL PROTECTED] 2005-07-28 12:39 --- From the trace - it looks like javac is barfing which is a Sun bug. Please be sure that all patches are applied and if needed - use the fork option for compiling jsps. Otherwise - this is not a tomcat 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]
Re: APR AJP Connector loosing data
El jue, 28-07-2005 a las 01:09 +0200, Remy Maucherat escribió: Mauricio Nuñez wrote: Apparently , my report was useful! :-) The issue turned out to be really basic. Any other problems besides that ? Rémy Thanks. I'm begining to recompile the CVS connector to try. Now I'm fighting with the jakarta jar hell :-) . Now I'm testing the NIO connector. After the compilation, I'will send you my results. Well, for the log, the test case about the APR AJP loosing data is to configure apache2 + mod_jk + Tomcat woth Apr AJP13 socket, and try any page with size 8192. Tested with Linux Centos 4, Sun JDK 1.5.0_03. wget http://tomcat3.chile.com/tomcat-docs/changelog.html Petición HTTP enviada, esperando respuesta... 200 OK Longitud: 128,310 [text/html] 68% [] 87,390--.--K/s 06:35:10 (1.95 MB/s) - Connection closed at byte 87,390. Reintentando. --06:35:11-- http://tomcat3.chile.com/tomcat-docs/changelog.html (intento: 2) = `changelog.html' Conectando con tomcat3.chile.com[10.0.0.43]:80... conectado. Petición HTTP enviada, esperando respuesta... 206 Partial Content Longitud: 128,310 (40,920 para acabar) [text/html] 87% [+== ] 111,942 --.--K/s 06:35:26 (549.77 KB/s) - Connection closed at byte 111,942. Reintentando. --06:35:28-- http://tomcat3.chile.com/tomcat-docs/changelog.html (intento: 3) = `changelog.html' Conectando con tomcat3.chile.com[10.0.0.43]:80... conectado. Petición HTTP enviada, esperando respuesta... 206 Partial Content Longitud: 128,310 (16,368 para acabar) [text/html] 93% [= ] 120,126 --.--K/s 06:35:43 (415.22 KB/s) - Connection closed at byte 120,126. Reintentando. --06:35:46-- http://tomcat3.chile.com/tomcat-docs/changelog.html (intento: 4) = `changelog.html' Conectando con tomcat3.chile.com[10.0.0.43]:80... conectado. Petición HTTP enviada, esperando respuesta... 206 Partial Content Longitud: 128,310 (8,184 para acabar) [text/html] 100%[++==] 128,310 --.--K/s 06:35:46 (510.23 KB/s) - `changelog.html' saved [128,310/128,310] - 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]
Info Schott-Pula/HRPUY/Schott is out of the office.
I will be out of the office starting 25.07.2005 and will not return until 08.08.2005. We are on hollidays from 26 th july 2004 till 06 th august 2004. We will respond to your message when we return. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat 5.5.9 and Unix Domain Sockets
Hi, I am trying to configure Tomcat 5.5.9 with mod_jk2 on HPUX . The configuration for using UNIX Sockets is not working with the same configuration which was working Tomcat 4.1.x. Do any one have any idea of any configuration changes in 5.5.9 for configuring unix domain sockets? Basically are there any changes in server.xml and jk2.properties that has to be enabled.? Thanks in advance, Regards, Bob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/coyote/ajp AjpAprProcessor.java
remm2005/07/28 05:17:02 Modified:jk/java/org/apache/coyote/ajp AjpAprProcessor.java Log: - Remove bad import. Revision ChangesPath 1.12 +1 -2 jakarta-tomcat-connectors/jk/java/org/apache/coyote/ajp/AjpAprProcessor.java Index: AjpAprProcessor.java === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/coyote/ajp/AjpAprProcessor.java,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- AjpAprProcessor.java 27 Jul 2005 19:29:16 - 1.11 +++ AjpAprProcessor.java 28 Jul 2005 12:17:02 - 1.12 @@ -32,7 +32,6 @@ import org.apache.coyote.Request; import org.apache.coyote.RequestInfo; import org.apache.coyote.Response; -import org.apache.jk.common.AjpConstants; import org.apache.tomcat.jni.Address; import org.apache.tomcat.jni.Sockaddr; import org.apache.tomcat.jni.Socket; @@ -1398,7 +1397,7 @@ outputBuffer.put((byte) 0x41); outputBuffer.put((byte) 0x42); outputBuffer.putShort((short) (thisTime + 4)); -outputBuffer.put(AjpConstants.JK_AJP13_SEND_BODY_CHUNK); +outputBuffer.put(Constants.JK_AJP13_SEND_BODY_CHUNK); outputBuffer.putShort((short) chunk.getLength()); outputBuffer.put(chunk.getBytes(), chunk.getOffset() + off, thisTime); outputBuffer.put((byte) 0x00); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: APR AJP Connector loosing data
Mauricio Nuñez wrote: El jue, 28-07-2005 a las 01:09 +0200, Remy Maucherat escribió: Mauricio Nuñez wrote: Apparently , my report was useful! :-) The issue turned out to be really basic. Any other problems besides that ? Rémy Thanks. I'm begining to recompile the CVS connector to try. Now I'm fighting with the jakarta jar hell :-) . There's no hell involved ... There's one source file involved (actually, only one line). What you need to do is javac that one class (which only depends only on JARs which are in the Tomcat bundle in server/lib: tomcat-apr, tomcat-util, tomcat-coyote, tomcat-ajp). Even getting the full thing is easy as long as you know Ant (ant download; ant). Now I'm testing the NIO connector. After the compilation, I'will send you my results. Well, for the log, the test case about the APR AJP loosing data is to configure apache2 + mod_jk + Tomcat woth Apr AJP13 socket, and try any page with size 8192. Tested with Linux Centos 4, Sun JDK 1.5.0_03. I noticed that after trying random stuff. While it's good to send details, it's less useful to send them after the bug has been fixed. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35914] New: - Problem to create and delete Access Log Valve many times
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=35914. 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=35914 Summary: Problem to create and delete Access Log Valve many times Product: Tomcat 5 Version: 5.5.9 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: Webapps:Administration AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] I'm adding test cases to JOnAS administration console and I have a problem to remove Access Log Valve. I have reproduced the problem with Tomcat administration. 1-I create a new Access Log Valve in directory logs/ 2-I delete the valve 3-I create a new Access Log Valve in directory logs/ again 4-I try to delete the valve and I have an error : org.apache.commons.modeler.BaseModelMBean invoke GRAVE: Exception invoking method removeValve java.lang.NullPointerException at org.apache.catalina.mbeans.MBeanFactory.removeValve(MBeanFactory.java:1069) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.commons.modeler.BaseModelMBean.invoke(BaseModelMBean.java:501) at mx4j.server.interceptor.InvokerMBeanServerInterceptor.invoke(InvokerMBeanServerInterceptor.java:221) at mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:120) at mx4j.server.interceptor.SecurityMBeanServerInterceptor.invoke(SecurityMBeanServerInterceptor.java:84) at mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:120) at mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:120) at mx4j.server.interceptor.ContextClassLoaderMBeanServerInterceptor.invoke(ContextClassLoaderMBeanServerInterceptor.java:203) at mx4j.server.MX4JMBeanServer.invoke(MX4JMBeanServer.java:1043) at org.apache.webapp.admin.valve.DeleteValvesAction.execute(DeleteValvesAction.java:124) at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:419) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:224) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1192) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:430) at javax.servlet.http.HttpServlet.service(HttpServlet.java:709) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.webapp.admin.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:123) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:526) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:526) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:534) I think that the error is when the valve is removed in the
DO NOT REPLY [Bug 31576] - Remove code now in ManagerBase from DeltaManager
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=31576. 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=31576 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-07-28 15:41 --- No answer, and it's been a while, so I'm closing this issue. If you look, 5.5.10 had significant work done in the area. I hope that addressed your requirements. -- 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 32754] - Can't modify thread configuration attributes of AJP connector MBean
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=32754. 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=32754 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |NEEDINFO --- Additional Comments From [EMAIL PROTECTED] 2005-07-28 15:45 --- Adriana, is this also true for 5.5.9/5.5.10? -- 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 32888] - Each cluster slave creates duplicated session on top of the replicated one
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=32888. 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=32888 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |NEEDINFO --- Additional Comments From [EMAIL PROTECTED] 2005-07-28 15:45 --- Joseph, does this still happen in 5.5.10? We did a lot of clustering fixes in that release. -- 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-connectors/jk/java/org/apache/coyote/ajp AjpAprProcessor.java
remm2005/07/28 06:48:47
Modified:jk/java/org/apache/coyote/ajp AjpAprProcessor.java
Log:
- Cleanup attribute parsing code (shouild be equivalent).
Revision ChangesPath
1.13 +22 -27
jakarta-tomcat-connectors/jk/java/org/apache/coyote/ajp/AjpAprProcessor.java
Index: AjpAprProcessor.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/coyote/ajp/AjpAprProcessor.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- AjpAprProcessor.java 28 Jul 2005 12:17:02 - 1.12
+++ AjpAprProcessor.java 28 Jul 2005 13:48:47 - 1.13
@@ -826,21 +826,13 @@
}
// Decode extra attributes
-boolean moreAttr = true;
+byte attributeCode;
+while ((attributeCode = requestHeaderMessage.getByte())
+!= Constants.SC_A_ARE_DONE) {
-while (moreAttr) {
-byte attributeCode = requestHeaderMessage.getByte();
-if (attributeCode == Constants.SC_A_ARE_DONE)
-break;
-
-if (attributeCode == Constants.SC_A_SSL_KEY_SIZE) {
-// Bug 1326: it's an Integer.
-request.setAttribute(SSLSupport.KEY_SIZE_KEY,
- new Integer(requestHeaderMessage.getInt()));
-}
-
-if (attributeCode == Constants.SC_A_REQ_ATTRIBUTE ) {
-// 2 strings ???...
+switch (attributeCode) {
+
+case Constants.SC_A_REQ_ATTRIBUTE :
requestHeaderMessage.getBytes(tmpMB);
String n = tmpMB.toString();
requestHeaderMessage.getBytes(tmpMB);
@@ -848,10 +840,8 @@
request.setAttribute(n, v);
if (log.isTraceEnabled())
log.trace(jk Attribute set + n + = + v);
-}
-
-// 1 string attributes
-switch (attributeCode) {
+break;
+
case Constants.SC_A_CONTEXT :
requestHeaderMessage.getBytes(tmpMB);
// nothing
@@ -890,7 +880,7 @@
case Constants.SC_A_SSL_CERT :
request.scheme().setString(https);
-// SSL certificate extraction is costy, moved to
JkCoyoteHandler
+// SSL certificate extraction is lazy, moved to
JkCoyoteHandler
requestHeaderMessage.getBytes(certificates);
break;
@@ -908,21 +898,26 @@
tmpMB.toString());
break;
+case Constants.SC_A_SSL_KEY_SIZE :
+request.setAttribute(SSLSupport.KEY_SIZE_KEY,
+new Integer(requestHeaderMessage.getInt()));
+break;
+
+// FIXME: no usage for secret attribute here
+/*
case Constants.SC_A_SECRET :
requestHeaderMessage.getBytes(tmpMB);
-String secret = tmpMB.toString();
-if(log.isInfoEnabled())
-log.info(Secret: + secret);
-// FIXME: endpoint note - what's that ?
-// endpoint.setNote(secretNote, secret);
break;
+*/
case Constants.SC_A_STORED_METHOD:
requestHeaderMessage.getBytes(request.method());
break;
default:
-break; // ignore, we don't know about it - backward compat
+// Ignore unknown attribute for backward compatibility
+break;
+
}
}
@@ -1390,8 +1385,8 @@
thisTime = chunkSize;
}
len -= thisTime;
-if (outputBuffer.position() + thisTime
-+ bodyMessage.getHeaderLength() + 4
outputBuffer.capacity()) {
+if (outputBuffer.position() + thisTime + 4 + 4
+outputBuffer.capacity()) {
flush();
}
outputBuffer.put((byte) 0x41);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
yoavs 2005/07/28 07:01:50 Modified:.tomcat.nsi webapps/docs changelog.xml Log: Bugzilla 33267: http://issues.apache.org/bugzilla/show_bug.cgi?id=33267 Revision ChangesPath 1.75 +2 -2 jakarta-tomcat-5/tomcat.nsi Index: tomcat.nsi === RCS file: /home/cvs/jakarta-tomcat-5/tomcat.nsi,v retrieving revision 1.74 retrieving revision 1.75 diff -u -r1.74 -r1.75 --- tomcat.nsi28 Apr 2005 12:32:05 - 1.74 +++ tomcat.nsi28 Jul 2005 14:01:49 - 1.75 @@ -162,7 +162,7 @@ InstallRetry: ClearErrors - nsExec::ExecToLog '$INSTDIR\bin\tomcat5.exe //IS//Tomcat5 --DisplayName Apache Tomcat --Description Apache Tomcat @VERSION@ Server - http://jakarta.apache.org/tomcat/; --LogPath $INSTDIR\logs --Install $INSTDIR\bin\tomcat5.exe --Jvm $2' + nsExec::ExecToLog '$INSTDIR\bin\tomcat5.exe //IS//Tomcat5 --DisplayName Apache Tomcat --Description Apache Tomcat @VERSION@ Server - http://jakarta.apache.org/tomcat/; --LogPath $INSTDIR\logs --Install $INSTDIR\bin\tomcat5.exe --Jvm $2--StartPath $INSTDIR --StopPath $INSTDIR' Pop $0 StrCmp $0 0 InstallOk MessageBox MB_ABORTRETRYIGNORE|MB_ICONSTOP \ 1.346 +4 -0 jakarta-tomcat-catalina/webapps/docs/changelog.xml Index: changelog.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v retrieving revision 1.345 retrieving revision 1.346 diff -u -r1.345 -r1.346 --- changelog.xml 27 Jul 2005 19:39:17 - 1.345 +++ changelog.xml 28 Jul 2005 14:01:49 - 1.346 @@ -49,6 +49,10 @@ fix bug35865/bug: setclasspath.sh cannot be excutive under cygwin (funkman) /fix + fix +bug33267/bug: Set working path in service installer, as suggested by Dominik + Drzewiecki. (yoavs) + /fix /changelog /subsection - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33267] - Startup and shutdown working path not set
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=33267. 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=33267 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-07-28 16:02 --- Patch applied. Thank you for the contribution. -- 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 33262] - Service Manager autostart should check for administrative rights
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=33262. 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=33262 [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|NEEDINFO --- Additional Comments From [EMAIL PROTECTED] 2005-07-28 16:10 --- I agree with this patch and would like to do this, but I'm not sure how to check for admin privileges on startup for this service. If someone provides a patch, I'll be glad to apply and test it. -- 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 34278] - error compiling file with jikes compiler
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=34278. 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=34278 --- Additional Comments From [EMAIL PROTECTED] 2005-07-28 16:12 --- I don't have an alpha box with which to reproduce this, and jikes works OK for me with 5.5.10. I'll leave this open for now, but no one else has voted for it or verified it, and maybe it's gone away for you? -- 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 30697] - Conformance of clustering to the spec
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=30697. 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=30697 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |NEEDINFO --- Additional Comments From [EMAIL PROTECTED] 2005-07-28 16:14 --- If you can provide a test case that shows a mismatch between the documentation and the implementation, we'll be glad to carry it out, and hopefully fix the problem. But we need more detail than it seems. -- 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-5 tomcat.nsi
remm2005/07/28 07:17:51 Modified:.tomcat.nsi Log: - Add missing space. Revision ChangesPath 1.76 +2 -2 jakarta-tomcat-5/tomcat.nsi Index: tomcat.nsi === RCS file: /home/cvs/jakarta-tomcat-5/tomcat.nsi,v retrieving revision 1.75 retrieving revision 1.76 diff -u -r1.75 -r1.76 --- tomcat.nsi28 Jul 2005 14:01:49 - 1.75 +++ tomcat.nsi28 Jul 2005 14:17:51 - 1.76 @@ -162,7 +162,7 @@ InstallRetry: ClearErrors - nsExec::ExecToLog '$INSTDIR\bin\tomcat5.exe //IS//Tomcat5 --DisplayName Apache Tomcat --Description Apache Tomcat @VERSION@ Server - http://jakarta.apache.org/tomcat/; --LogPath $INSTDIR\logs --Install $INSTDIR\bin\tomcat5.exe --Jvm $2--StartPath $INSTDIR --StopPath $INSTDIR' + nsExec::ExecToLog '$INSTDIR\bin\tomcat5.exe //IS//Tomcat5 --DisplayName Apache Tomcat --Description Apache Tomcat @VERSION@ Server - http://jakarta.apache.org/tomcat/; --LogPath $INSTDIR\logs --Install $INSTDIR\bin\tomcat5.exe --Jvm $2 --StartPath $INSTDIR --StopPath $INSTDIR' Pop $0 StrCmp $0 0 InstallOk MessageBox MB_ABORTRETRYIGNORE|MB_ICONSTOP \ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35916] New: - Session listeners not called on cluster server restart
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=35916. 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=35916 Summary: Session listeners not called on cluster server restart Product: Tomcat 5 Version: 5.5.9 Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: Catalina:Cluster AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Hi, I think there is a bug at DeltaManager class. I have set up 2 local tomcat servers. My application implements HttpSessionListener, HttpSessionAttributeListener and HttpSessionActivationListener. All the methods of those interfaces are called when needed, so no problems yet. When I shutdown one of the servers, sessionDestroyed is called (only on the server being shutdown) for each session. However, when I start that server again and it receives the active sessions from the other server, neither sessionCreated nor sessionDidActivate methods are called for each active session received from the other server. I think one of them should be called on the server being started up. Here is my cluster configuration, just in case it helps: --- Cluster className=org.apache.catalina.cluster.tcp.SimpleTcpCluster managerClassName=org.apache.catalina.cluster.session.DeltaManager expireSessionsOnShutdown=false useDirtyFlag=true notifyListenersOnReplication=true notifySessionListenersOnReplication=true Membership className=org.apache.catalina.cluster.mcast.McastService mcastAddr=228.0.0.4 mcastBindAddr=127.0.0.1 mcastPort=14000 mcastFrequency=500 mcastDropTime=3000/ Receiver className=org.apache.catalina.cluster.tcp.ReplicationListener tcpListenAddress=127.0.0.1 tcpListenPort=15001 tcpSelectorTimeout=100 tcpThreadCount=6/ Sender className=org.apache.catalina.cluster.tcp.ReplicationTransmitter replicationMode=pooled ackTimeout=15000/ Valve className=org.apache.catalina.cluster.tcp.ReplicationValve filter=.*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;/ /Cluster --- Thank you very much! -- 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: 5.5.10 cluster exception
Dennis wrote: I'm working with the cvs tagged 5.5.10 version of tomcat to check out some clustering fixes. When I bring a 2nd server into the pool, I get this exception repeated every time an mcast packet is received: ==CUT== java.lang.ArrayIndexOutOfBoundsException at java.lang.System.arraycopy(Ljava.lang.Object;ILjava.lang.Object;II)V(Unknown Source) at org.apache.catalina.cluster.mcast.McastMember.getMember(McastMember.java:181) at org.apache.catalina.cluster.mcast.McastServiceImpl.receive(McastServiceImpl.java:209) at org.apache.catalina.cluster.mcast.McastServiceImpl$ReceiverThread.run(McastServiceImpl.java:253) ==END CUT== Here are the relevant lines of code from McastMember.java: ==CUT== byte[] domaind = new byte[dlen]; System.arraycopy(data, nlen + 24, domaind, 0, domaind.length); ==END CUT== I added some debugging to figure out the length of the data. The exception occurs because data.length is 23. Obviously 23+24 is going to throw an ArrayIndexOBE. My question is.. is there a configuration thing that is causing data to be sent to be less than the desired length? It appears the data is not coming in in the format expected. Thoughts? Your post is OT on this mailing list, but I thought I would play a little with the clustering. This works for me, with this config: Cluster className=org.apache.catalina.cluster.tcp.SimpleTcpCluster managerClassName=org.apache.catalina.cluster.session.DeltaManager expireSessionsOnShutdown=false useDirtyFlag=true notifyListenersOnReplication=true Membership className=org.apache.catalina.cluster.mcast.McastService mcastAddr=228.0.0.4 mcastPort=45564 mcastFrequency=500 mcastClusterDomain=dev mcastDropTime=3000/ Receiver className=org.apache.catalina.cluster.tcp.ReplicationListener tcpListenAddress=auto tcpListenPort=4002 tcpSelectorTimeout=100 tcpThreadCount=6/ Sender className=org.apache.catalina.cluster.tcp.ReplicationTransmitter replicationMode=pooled ackTimeout=15000/ Valve className=org.apache.catalina.cluster.tcp.ReplicationValve filter=.*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;/ ClusterListener className=org.apache.catalina.cluster.session.ClusterSessionListener/ /Cluster The domain feature for membership is new in this release (which caused the data packets sent to change). I recommend trying tomcat-user, or filing a bug if you can give working instructions on how to reproduce the problem. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: APR AJP Connector loosing data
El jue, 28-07-2005 a las 14:25 +0200, Remy Maucherat escribió: Mauricio Nuñez wrote: Thanks. I'm begining to recompile the CVS connector to try. Now I'm fighting with the jakarta jar hell :-) . There's no hell involved ... There's one source file involved (actually, only one line). What you need to do is javac that one class (which only depends only on JARs which are in the Tomcat bundle in server/lib: tomcat-apr, tomcat-util, tomcat-coyote, tomcat-ajp). Even getting the full thing is easy as long as you know Ant (ant download; ant). OK. But may be more easy, It's not very out of the box . My steps : downloadind jakarta-tomcat-5.5.10-src.tar.gz, untarring it , creating build.properties from samples, ant download , s/telia.dl.sourceforge.net/easynews.dl.sourceforge.net ant download , changing build.properties ant -projecthelp for( various dirs ) ant compile etc ... I noticed that after trying random stuff. While it's good to send details, it's less useful to send them after the bug has been fixed. OK. The test case is for the list archive, not only for you. The smart people search the archives before send a bug. I'm testing your change, all is working again. 65 ajp workers on machine 1, 95 ajp workers on machine 2. The heap usage grow smoothly. My sample is about 20 min. What kind of data may be relevant for you ? Thanks Mauricio Rémy - 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: APR AJP Connector loosing data
Mauricio Nuñez wrote: El jue, 28-07-2005 a las 14:25 +0200, Remy Maucherat escribió: OK. But may be more easy, It's not very out of the box . Since the out of the box version has a bug, the out of the box experience is going to suck, there's nothing I can do about it. I noticed that after trying random stuff. While it's good to send details, it's less useful to send them after the bug has been fixed. OK. The test case is for the list archive, not only for you. The smart people search the archives before send a bug. Ok. I'm testing your change, all is working again. 65 ajp workers on machine 1, 95 ajp workers on machine 2. The heap usage grow smoothly. My sample is about 20 min. What kind of data may be relevant for you ? That it's working is pretty good already, but you should mention your OS. I built the AJP APR implementation using lots of cut paste of the existing AJP code, and for the most part, just to have it, as I don't expect major benefits (except in one special case where the amount of request processors on the front end is huge compared to the amount of request processors that can realistically be used on the back end - often it's the other way around, so there's no problem). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: APR AJP Connector loosing data
What kind of data may be relevant for you ? That it's working is pretty good already, but you should mention your OS. I built the AJP APR implementation using lots of cut paste of the existing AJP code, and for the most part, just to have it, as I don't expect major benefits (except in one special case where the amount of request processors on the front end is huge compared to the amount of request processors that can realistically be used on the back end - often it's the other way around, so there's no problem). CentOS release 4.1 (Final) Linux 2.6.9-11.ELsmp httpd-2.0.52-12.1.ent.centos4 java version 1.5.0_03 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_03-b07) Java HotSpot(TM) Client VM (build 1.5.0_03-b07, mixed mode, sharing) mod_jk/1.2.10 Jakarta-Tomcat 5.5.10 + APR Fixes. Thanks Mauricio Rémy - 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 35920] New: - AOBE when IPAddress of nodes differ in length
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=35920. 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=35920 Summary: AOBE when IPAddress of nodes differ in length Product: Tomcat 5 Version: 5.5.10 Platform: All OS/Version: All Status: NEW Severity: minor Priority: P3 Component: Catalina:Cluster AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] McastServiceImpl.java re-uses the same DatagramPacket. The byte buffer for this packet gets set to the size of the first packet received and then not reset. I have two machines in a cluster. One with IP Address 192.168.1.5, the other with 192.168.1.27. The DatagramPacket for one machine is size 49, the other 50 because of the one character difference in the name length in the packet. The problem is that when the 2nd packet is received, the DatagramPacket still has size 49. The following exception gets thrown each time a packet from that machine is received: java.lang.ArrayIndexOutOfBoundsException at java.lang.System.arraycopy(Ljava.lang.Object;ILjava.lang.Object;II)V(Unknown Source) at org.apache.catalina.cluster.mcast.McastMember.getMember(McastMember.java:180) at org.apache.catalina.cluster.mcast.McastServiceImpl.receive(McastServiceImpl.java:209) at org.apache.catalina.cluster.mcast.McastServiceImpl$ReceiverThread.run(McastServiceImpl.java:253) The byte buffer for the DatagramPacket needs to check the length and possibly resize if needed. This probably doesn't affect many people. -- 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 35907] - Java JVM crashes
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=35907. 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=35907 --- Additional Comments From [EMAIL PROTECTED] 2005-07-28 19:24 --- (In reply to comment #2) From the trace - it looks like javac is barfing which is a Sun bug. Please be sure that all patches are applied and if needed - use the fork option for compiling jsps. Otherwise - this is not a tomcat bug. In our case the JSPs are compiled at runttime by tomcat. Can you please tell me how to use fork option for compiling JSPs ? Do you mean we should pre-compile all modified or new JSPs before accessing 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 35907] - Java JVM crashes
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=35907. 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=35907 --- Additional Comments From [EMAIL PROTECTED] 2005-07-28 19:39 --- (In reply to comment #2) From the trace - it looks like javac is barfing which is a Sun bug. Please be sure that all patches are applied and if needed - use the fork option for compiling jsps. Otherwise - this is not a tomcat bug. In our case the tomcat compiles the new and modified JSP pages. Can you please let us know how to make tomcat use the fork option for compiling jsps ? I am not aware of using fork option in general. Should we be do pre-compiling of JSP pages before accessing 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 35920] - AOBE when IPAddress of nodes differ in length
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=35920. 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=35920 --- Additional Comments From [EMAIL PROTECTED] 2005-07-28 22:12 --- It looks like the Datagram always has buffer for 1000 Bytes. The IP itself has constant length (4 Bytes), the name (containing the IP as a string) has variable length, but the length is passed as part of the datagram. So no bug to be seen here. I tried with two different length IPs - no problem. If the third line of this: int dlen = XByteBuffer.toInt(dlend, 0); byte[] domaind = new byte[dlen]; System.arraycopy(data, nlen + 24, domaind, 0, domaind.length); is where it happens, can you debug by a print statement giving: data.getLength() XByteBuffer.toLong(alived, 0)) XByteBuffer.toInt(portd, 0), addressToString(addr), nlen, new String(named), dlen, and for i=0...dlen-1 data[nlen + 24 + i] That way you can see, if you received the data which is expected, or where there might be something 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]
DO NOT REPLY [Bug 35920] - AOBE when IPAddress of nodes differ in length
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=35920. 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=35920 --- Additional Comments From [EMAIL PROTECTED] 2005-07-28 22:21 --- Well, I forgot to mention something important. I'm using the BEA JRockit jvm and I'm betting they've done some kind of internal optimization at the java.net class level. I'll try again with the sun jvm and see if that solves the issue. I had done some print statements to see what the byte[] contained. It always said it was 49 bytes long but there were 50 bytes worth of data sent (and received). -- 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 35924] New: - ISAPI redirector accesses freed memory
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=35924. 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=35924 Summary: ISAPI redirector accesses freed memory Product: Tomcat 5 Version: 5.5.9 Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: Native:JK AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] In init_jk of iis/jk_isapi_plugin.c, the worker_env is constructed from a map allocated in that function, which is subsequently freed before init_jk exits. The worker names (and some other strings) are copied from the map into the worker_env, and subsequently into the worker structs themselves. Later, when the worker name is accessed, freed memory is accessed and bogus data is used. e.g. p-worker-name in ajp_done in jk_ajp_common.c Mercifully, the fields concerned seem only to be used in debug logging statements, so this hasn't caused any crashes - even in debug mode all you see is a stream of characters. mod_jk may avoid this issue, as the config map is passed from Apache to the module, and is presumably kept around, although I haven't tested that theory. -- 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]
