[VOTE] Releasing Tomcat Connectors 1.2.22

2007-04-12 Thread Mladen Turk 

Hi,

Mod_jk 1.2.22 has been available for testing for some days.
No new bugs have been reported so far, so it is time to proceed with the
release vote.

The source distribution can be downloaded from:
http://tomcat.apache.org/dev/dist/tomcat-connectors/jk/source/jk-1.2.22/
or
http://www.apache.org/dist/tomcat/tomcat-connectors/jk/source/jk-1.2.22/

Set of Windows binaries is available and can be downloaded from:
http://www.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/win32/jk-1.2.22/
Set of Windows 64 bit binaries is available and can be downloaded from:
http://www.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/win64/jk-1.2.22/

The updated documentation can be found at
http://tomcat.apache.org/dev/dist/tomcat-connectors/jk/docs/jk-1.2.22/


So here's the vote, which will be open until Tuesday April 17, 12:00 GMT.

Apache Tomcat Connectors 1.2.22 is:
[ ] Stable - no major issues, no regressions
[ ] Beta - at least one significant issue -- tell us what it is
[ ] Alpha - multiple significant issues -- tell us what they are

Regards,
Mladen


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

Re: Candidate binaries for 6.0.11

2007-04-12 Thread Filip Hanik - Dev Lists 

Remy Maucherat wrote:

Filip Hanik - Dev Lists wrote:
much appreciated, I'm still working on the "deregistering" of the JMX 
resources, somehow they are slipping through the cracks


Originally, the purpose of the JMX stuff was to provide thread 
monitoring. Now that the processors are not tied to threads anymore, 
it becomes a bit useless IMO. Normally, Java 5+ provides JMX 
monitoring of threads already, but of course the Tomcat JMX does 
provide a little more data (that may or may not be worth keeping).
I've done the fix for the NIO connector. I believe I have been able to 
take care of all the problems.
In the NIO protocol, I simply got rid of the thread local, and replaced 
it with a queue.

This queue is able to deregister objects, should it be needed.
Only time they are deregistered, is if they number exceed the 
processorCache= in the NIO  element.


The memory leak exists in the APR and JIO connector, when and only when 
they use the shared  and the Executor has a 
minSpareThreadsSince these connectors do not use an executor by default, I'd like to 
get some feedback if these two need to get fixed for the upcoming release.


If we are to proceed with the release without fixing these, I would 
simply note it in the release notes, that to use an executor, use the 
workaround.


I'm open to suggestions...and once again...thanks for your patience 
(especially since it's me that want this new release)


Filip




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]

svn commit: r528347 - /tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java

2007-04-12 Thread fhanik 
Author: fhanik
Date: Thu Apr 12 21:19:09 2007
New Revision: 528347

URL: http://svn.apache.org/viewvc?view=rev&rev=528347
Log:
Since we can keep alive a HTTP connection, even after we have stopped using it 
as a comet, then we need to go back to the original timeout

Modified:
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java?view=diff&rev=528347&r1=528346&r2=528347
==
--- tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java 
Thu Apr 12 21:19:09 2007
@@ -757,8 +757,14 @@
 NioEndpoint.KeyAttachment attach = 
(NioEndpoint.KeyAttachment)socket.getAttachment(false);
 if (attach != null) {
 attach.setComet(comet);
-Integer comettimeout = (Integer) 
request.getAttribute("org.apache.tomcat.comet.timeout");
-if (comettimeout != null) 
attach.setTimeout(comettimeout.longValue());
+if (comet) {
+Integer comettimeout = (Integer) 
request.getAttribute("org.apache.tomcat.comet.timeout");
+if (comettimeout != null) 
attach.setTimeout(comettimeout.longValue());
+} else {
+//reset the timeout
+
attach.setTimeout(endpoint.getSocketProperties().getSoTimeout());
+}
+
 }
 }
 } catch (InterruptedIOException e) {
@@ -903,8 +909,10 @@
 NioEndpoint.KeyAttachment attach = 
(NioEndpoint.KeyAttachment) key.attachment();
 if (attach != null)  {
 attach.setComet(comet);
-Integer comettimeout = (Integer) 
request.getAttribute("org.apache.tomcat.comet.timeout");
-if (comettimeout != null) 
attach.setTimeout(comettimeout.longValue());
+if (comet) {
+Integer comettimeout = (Integer) 
request.getAttribute("org.apache.tomcat.comet.timeout");
+if (comettimeout != null) 
attach.setTimeout(comettimeout.longValue());
+}
 }
 }
 } catch (InterruptedIOException e) {



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

svn commit: r528341 - /tomcat/tc6.0.x/trunk/webapps/docs/aio.xml

2007-04-12 Thread fhanik 
Author: fhanik
Date: Thu Apr 12 20:22:29 2007
New Revision: 528341

URL: http://svn.apache.org/viewvc?view=rev&rev=528341
Log:
Updated with some useful info

Modified:
tomcat/tc6.0.x/trunk/webapps/docs/aio.xml

Modified: tomcat/tc6.0.x/trunk/webapps/docs/aio.xml
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/docs/aio.xml?view=diff&rev=528341&r1=528340&r2=528341
==
--- tomcat/tc6.0.x/trunk/webapps/docs/aio.xml (original)
+++ tomcat/tc6.0.x/trunk/webapps/docs/aio.xml Thu Apr 12 20:22:29 2007
@@ -72,7 +72,13 @@
Alternately, it is also possible to catch any exception, perform clean 
up
on any data structure the servlet may be using, and using the close 
method
of the event. It is not allowed to attempt reading data from the 
request 
-   object outside of the execution of this method.
+   object outside of the execution of this method.
+   On some platforms, like Windows, a client disconnect is indicated by a 
READ event.
+   Reading from the stream may result in -1, an IOException or an 
EOFException.
+   Make sure you properly handle all these three cases.
+   If you don't catch the IOException, Tomcat will instantly invoke your 
event chain with an ERROR as 
+   it catches the error for you, and you will be notified of the error at 
that time.
+  
   EventType.END: End may be called to end the processing of the request. 
Fields that have
  been initialized in the begin method should be reset. After this event has
  been processed, the request and response objects, as well as all their 
dependent
@@ -194,8 +200,8 @@
 InputStream is = request.getInputStream();
 byte[] buf = new byte[512];
 do {
-int n = is.read(buf);
-if (n > 0) {
+int n = is.read(buf); //can throw an IOException
+if (n > 0) {
 log("Read " + n + " bytes: " + new String(buf, 0, n) 
 + " for session: " + 
request.getSession(true).getId());
 } else if (n < 0) {



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

svn commit: r528323 - in /tomcat/tc6.0.x/trunk: java/org/apache/coyote/ java/org/apache/coyote/http11/ java/org/apache/tomcat/util/net/ webapps/docs/config/

2007-04-12 Thread fhanik 
Author: fhanik
Date: Thu Apr 12 19:28:01 2007
New Revision: 528323

URL: http://svn.apache.org/viewvc?view=rev&rev=528323
Log:
Fix the handling of the Http11NioProcessors when the thread pool can be 
shrinking and growing.
So we are not associating the processor with a thread local, instead going 
directly to a pool of them


Modified:
tomcat/tc6.0.x/trunk/java/org/apache/coyote/RequestInfo.java
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProtocol.java
tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
tomcat/tc6.0.x/trunk/webapps/docs/config/http.xml

Modified: tomcat/tc6.0.x/trunk/java/org/apache/coyote/RequestInfo.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/coyote/RequestInfo.java?view=diff&rev=528323&r1=528322&r2=528323
==
--- tomcat/tc6.0.x/trunk/java/org/apache/coyote/RequestInfo.java (original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/coyote/RequestInfo.java Thu Apr 12 
19:28:01 2007
@@ -17,6 +17,8 @@
 
 package org.apache.coyote;
 
+import javax.management.ObjectName;
+
 
 /**
  * Structure holding the Request and Response objects. It also holds 
statistical
@@ -63,6 +65,7 @@
 Response res;
 int stage = Constants.STAGE_NEW;
 String workerThreadName;
+ObjectName rpName;
 
 //  Information about the current request  ---
 // This is usefull for long-running requests only
@@ -217,7 +220,15 @@
 return workerThreadName;
 }
 
+public ObjectName getRpName() {
+return rpName;
+}
+
 public void setWorkerThreadName(String workerThreadName) {
 this.workerThreadName = workerThreadName;
+}
+
+public void setRpName(ObjectName rpName) {
+this.rpName = rpName;
 }
 }

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java?view=diff&rev=528323&r1=528322&r2=528323
==
--- tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java 
Thu Apr 12 19:28:01 2007
@@ -753,16 +753,14 @@
 try {
 rp.setStage(org.apache.coyote.Constants.STAGE_SERVICE);
 error = !adapter.event(request, response, status);
-SelectionKey key = 
socket.getIOChannel().keyFor(socket.getPoller().getSelector());
-if ( key != null ) {
-NioEndpoint.KeyAttachment attach = (NioEndpoint.KeyAttachment) 
key.attachment();
-if ( attach!=null ) {
+if ( !error ) {
+NioEndpoint.KeyAttachment attach = 
(NioEndpoint.KeyAttachment)socket.getAttachment(false);
+if (attach != null) {
 attach.setComet(comet);
-Integer comettimeout = 
(Integer)request.getAttribute("org.apache.tomcat.comet.timeout");
-if ( comettimeout != null ) 
attach.setTimeout(comettimeout.longValue());
+Integer comettimeout = (Integer) 
request.getAttribute("org.apache.tomcat.comet.timeout");
+if (comettimeout != null) 
attach.setTimeout(comettimeout.longValue());
 }
 }
-
 } catch (InterruptedIOException e) {
 error = true;
 } catch (Throwable t) {
@@ -1072,7 +1070,8 @@
 //if this is a comet connection
 //then execute the connection closure at the next selector 
loop
 
request.getAttributes().remove("org.apache.tomcat.comet.timeout");
-attach.setError(true);
+//attach.setTimeout(5000); //force a cleanup in 5 seconds
+//attach.setError(true); //this has caused concurrency 
errors
 }
 }
 

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProtocol.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProtocol.java?view=diff&rev=528323&r1=528322&r2=528323
==
--- tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProtocol.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProtocol.java 
Thu Apr 12 19:28:01 2007
@@ -22,7 +22,9 @@
 import java.util.Hashtable;
 import java.util.Iterator;
 import java.util.concurrent.ConcurrentHashMap;
+import java.util.concurrent.ConcurrentLinkedQueue;
 import java.util.concurrent.Executor;
+import java.util.concurrent.atomic.AtomicInteger;
 import javax.management.MBeanRegistration;
 import javax.

Re: Candidate binaries for 6.0.11

2007-04-12 Thread Remy Maucherat 

Filip Hanik - Dev Lists wrote:
much appreciated, I'm still working on the "deregistering" of the JMX 
resources, somehow they are slipping through the cracks


Originally, the purpose of the JMX stuff was to provide thread 
monitoring. Now that the processors are not tied to threads anymore, it 
becomes a bit useless IMO. Normally, Java 5+ provides JMX monitoring of 
threads already, but of course the Tomcat JMX does provide a little more 
data (that may or may not be worth keeping).


Rémy

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

DO NOT REPLY [Bug 42104] - Tomcat crash unespected

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

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





--- Additional Comments From [EMAIL PROTECTED]  2007-04-12 13:21 ---
This could be a bug in tcnative.dll.

One way you could help would be to build tcnative.dll yourself from sources
*with debug* (-g for gcc or /Zi for VC++), and use that to reproduce this crash
so that we have a useful stack trace from inside tcnative.dll..

-- 
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: Annotation processing - Geronimo injection

2007-04-12 Thread Remy Maucherat 

David Jencks wrote:
Excellent, thanks!  Would this be shortly after 6.0.11 is out or further 
in the future?  If you have any guess about a date it would be much 
appreciated.


No idea. For example, I thought 6.0.11 would be ok, but it's not. I 
don't know if I'll commit as is either, since I did not look at the 
revised patches.


Rémy

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

svn commit: r528085 - /tomcat/connectors/tags/jk1.2.x/JK_1_2_22/

2007-04-12 Thread mturk 
Author: mturk
Date: Thu Apr 12 11:52:18 2007
New Revision: 528085

URL: http://svn.apache.org/viewvc?view=rev&rev=528085
Log:
made a copy

Added:
tomcat/connectors/tags/jk1.2.x/JK_1_2_22/
  - copied from r528084, tomcat/connectors/trunk/


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

svn commit: r528084 - /tomcat/connectors/trunk/jk/native/common/jk_version.h

2007-04-12 Thread mturk 
Author: mturk
Date: Thu Apr 12 11:47:35 2007
New Revision: 528084

URL: http://svn.apache.org/viewvc?view=rev&rev=528084
Log:
Mark version for a release.

Modified:
tomcat/connectors/trunk/jk/native/common/jk_version.h

Modified: tomcat/connectors/trunk/jk/native/common/jk_version.h
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_version.h?view=diff&rev=528084&r1=528083&r2=528084
==
--- tomcat/connectors/trunk/jk/native/common/jk_version.h (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_version.h Thu Apr 12 11:47:35 
2007
@@ -33,7 +33,7 @@
 #define JK_VERBETA  0
 #define JK_BETASTRING   "0"
 /* set JK_VERISRELEASE to 1 when release (do not forget to commit!) */
-#define JK_VERISRELEASE 0
+#define JK_VERISRELEASE 1
 #define JK_VERRC0
 #define JK_RCSTRING "0"
 



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

Re: Annotation processing - Geronimo injection

2007-04-12 Thread David Jencks 


On Apr 12, 2007, at 9:15 AM, Remy Maucherat wrote:


David Jencks wrote:
https://issues.apache.org/jira/secure/attachment/12355273/ 
GERONIMO-3010-4.patch In addition, this one combines the  
InstanceManager interfaces.  I think this is a bad idea because it  
forces jasper to use an interface shared with catalina, which the  
previous patch does not.  This makes catalina marginally more  
complicated when used as a standalone container for jasper but  
makes it possible to use jasper outside catalina without any  
catalina classes.  Note also that the previous (3c) patch allows  
use of tomcat embedded in a container that supplies its own  
InstanceManager implementation without pulling in any jasper  
classes at runtime.

This has 1 interface, 1 implementation.


Thanks for the patch revisions. I will look into adding these  
features after the next stable release.


Excellent, thanks!  Would this be shortly after 6.0.11 is out or  
further in the future?  If you have any guess about a date it would  
be much appreciated.


thanks
david jencks



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 40668] - MailSessionFactory is missing in Tomcat 5.5.23

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

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

  Attachment #19186|text/plain  |application/x-zip-compressed
  mime type||
  Attachment #19186|1   |0
   is patch||




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

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

DO NOT REPLY [Bug 40668] - MailSessionFactory is missing in Tomcat 5.5.23

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

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

  Attachment #19186|Patch for missing libraries |Patch for missing libraries
description|from Tomcat 5.5.20  |from Tomcat 5.5.23
   |distibution |distibution
  Attachment #19186|application/x-zip-compressed|text/plain
  mime type||
  Attachment #19186|Tomcat 5.5.20 patch.zip |Tomcat 5.5.23 patch.zip
   filename||
  Attachment #19186|0   |1
   is patch||




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

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

Re: Candidate binaries for 6.0.11

2007-04-12 Thread Filip Hanik - Dev Lists 

Remy Maucherat wrote:

Yoav Shapira wrote:

After playing with these candidate binaries for just an hour or so,
things look good to me.


Yes, they seem fine. Most likely however, I won't propose a vote on 
them, as I would prefer picking up the NIO fixes with a 6.0.12 tag.
much appreciated, I'm still working on the "deregistering" of the JMX 
resources, somehow they are slipping through the cracks

Filip


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 42104] New: - Tomcat crash unespected

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

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

   Summary: Tomcat crash unespected
   Product: Tomcat 5
   Version: 5.5.16
  Platform: All
OS/Version: Windows Server 2003
Status: NEW
  Severity: critical
  Priority: P2
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Sometimes, unexpectedly, tomcat shut down and logs the error you can find 
below. I use the jre 1.5.0_11 and I think that the tomcat shut down is due to 
a jre error. It seems the error is related to the tcnative-1.dll.

#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x480be12e, pid=1768, tid=6112
#
# Java VM: Java HotSpot(TM) Client VM (1.5.0_11-b03 mixed mode)
# Problematic frame:
# C  [tcnative-1.dll+0xe12e]
#

---  T H R E A D  ---

Current thread (0x4bde2360):  JavaThread "http-80-31" daemon 
[_thread_in_native, id=6112]

siginfo: ExceptionCode=0xc005, reading address 0x0034

Registers:
EAX=0x0001, EBX=0x43436370, ECX=0x, EDX=0x0001
ESP=0x50c5f33c, EBP=0x50c5f344, ESI=0x, EDI=0x4bde2360
EIP=0x480be12e, EFLAGS=0x00010246

Top of Stack: (sp=0x50c5f33c)
0x50c5f33c:   4bde2360 43436368 50c5f35c 480b111f
0x50c5f34c:   50c5f358 0001  
0x50c5f35c:   50c5f394 0079832f 4bde2420 50c5f39c
0x50c5f36c:   0001 4c182060  50c5f378
0x50c5f37c:    50c5f3ac 43436630 
0x50c5f38c:   43436370 50c5f3a4 50c5f3cc 00792a64
0x50c5f39c:   434365d0 00796509 4c182060 
0x50c5f3ac:   0001 50c5f3b0 43b2bdad 50c5f3f8 

Instructions: (pc=0x480be12e)
0x480be11e:   5d c2 0c 00 83 f8 01 0f 85 80 00 00 00 8b 75 10
0x480be12e:   8b 46 34 85 c0 74 3a 8b 56 14 c7 42 14 10 00 00 


Stack: [0x50c2,0x50c6),  sp=0x50c5f33c,  free space=252k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [tcnative-1.dll+0xe12e]
C  [tcnative-1.dll+0x111f]
j  org.apache.tomcat.jni.Address.get(IJ)J+0
j  org.apache.coyote.http11.Http11AprProcessor.action
(Lorg/apache/coyote/ActionCode;Ljava/lang/Object;)V+229
J  org.apache.coyote.Request.action
(Lorg/apache/coyote/ActionCode;Ljava/lang/Object;)V
j  org.apache.coyote.RequestInfo.getRemoteAddr()Ljava/lang/String;+8
j  sun.reflect.GeneratedMethodAccessor734.invoke(Ljava/lang/Object;
[Ljava/lang/Object;)Ljava/lang/Object;+36
J  sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;
[Ljava/lang/Object;)Ljava/lang/Object;
J  java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)
Ljava/lang/Object;
v  ~RuntimeStub::alignment_frame_return Runtime1 stub
j  org.apache.commons.modeler.BaseModelMBean.getAttribute(Ljava/lang/String;)
Ljava/lang/Object;+375
j  com.sun.jmx.mbeanserver.DynamicMetaDataImpl.getAttribute
(Ljava/lang/Object;Ljava/lang/String;)Ljava/lang/Object;+30
J  com.sun.jmx.mbeanserver.MetaDataImpl.getAttribute
(Ljava/lang/Object;Ljava/lang/String;)Ljava/lang/Object;
v  ~RuntimeStub::alignment_frame_return Runtime1 stub
j  com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute
(Ljavax/management/ObjectName;Ljava/lang/String;)Ljava/lang/Object;+143
J  com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute
(Ljavax/management/ObjectName;Ljava/lang/String;)Ljava/lang/Object;
j  org.apache.catalina.manager.StatusTransformer.writeProcessorState
(Ljava/io/PrintWriter;Ljavax/management/ObjectName;Ljavax/management/MBeanServe
r;I)V+713
j  org.apache.catalina.manager.StatusTransformer.writeConnectorState
(Ljava/io/PrintWriter;Ljavax/management/ObjectName;Ljava/lang/String;Ljavax/man
agement/MBeanServer;Ljava/util/Vector;Ljava/util/Vector;I)V+1031
j  org.apache.catalina.manager.StatusManagerServlet.doGet
(Ljavax/servlet/http/HttpServletRequest;Ljavax/servlet/http/HttpServletResponse
;)V+680
j  javax.servlet.http.HttpServlet.service
(Ljavax/servlet/http/HttpServletRequest;Ljavax/servlet/http/HttpServletResponse
;)V+132
j  javax.servlet.http.HttpServlet.service
(Ljavax/servlet/ServletRequest;Ljavax/servlet/ServletResponse;)V+30
j  org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(Ljavax/servlet/ServletRequest;Ljavax/servlet/ServletResponse;)V+354
J  org.apache.catalina.core.ApplicationFilterChain.doFilter
(Ljavax/servlet/ServletRequest;Ljavax/servlet/ServletResponse;)V
j  org.apache.catalina.core.StandardWrapperValve.invoke
(Lorg/apache/catalina/connector/Request;Lorg/apache/catalina/connector/Response
;)V+670
j  org.apache.catalina.core.StandardContextValve.invoke
(Lorg/apache/catalina/connector/Request;Lorg/apache/catalina/connector/Response
;)V+285
j  org.apache.catalina.authenticator.Authenticat

Re: Candidate binaries for 6.0.11

2007-04-12 Thread William L. Thomson Jr. 
On Thu, 2007-04-12 at 18:13 +0200, Remy Maucherat wrote:
> Yoav Shapira wrote:
> > After playing with these candidate binaries for just an hour or so,
> > things look good to me.
> 
> Yes, they seem fine. Most likely however, I won't propose a vote on 
> them, as I would prefer picking up the NIO fixes with a 6.0.12 tag.

I will not request stabilizing of any version of 6.0.x on Gentoo that
has the known NIO leak/issues. ( Despite not having any issues myself )
So would prefer to see a 6.0.12 with those fixes as well.

-- 
William L. Thomson Jr.
Gentoo/Java


signature.asc
Description: This is a digitally signed message part

DO NOT REPLY [Bug 40668] - MailSessionFactory is missing in Tomcat 5.5.23

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

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |




--- Additional Comments From [EMAIL PROTECTED]  2007-04-12 09:32 ---
You can also use the patch (taken from the Tomcat 5.5.17 distribution) from:
http://issues.apache.org/bugzilla/attachment.cgi?id=19186

-- 
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 42103] New: - Parans trustStoreType trustStorePass trustStoreFile

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

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

   Summary: Parans trustStoreType trustStorePass trustStoreFile
   Product: Tomcat 5
   Version: 5.5.23
  Platform: Other
OS/Version: Windows XP
Status: NEW
  Severity: normal
  Priority: P2
 Component: Webapps:Administration
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When admin configure server.xml file its write this parans trustStoreType
trustStorePass trustStoreFile in the conector tag, but te service don't work.

If i change to truststoreType truststorePass truststoreFile its work well. 

See: 








-- 
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: Candidate binaries for 6.0.11

2007-04-12 Thread Peter Rossbach 

+1

Peter


Am 12.04.2007 um 18:13 schrieb Remy Maucherat:


Yoav Shapira wrote:

After playing with these candidate binaries for just an hour or so,
things look good to me.


Yes, they seem fine. Most likely however, I won't propose a vote on  
them, as I would prefer picking up the NIO fixes with a 6.0.12 tag.


Rémy

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

Re: Annotation processing - Geronimo injection

2007-04-12 Thread Remy Maucherat 

David Jencks wrote:
https://issues.apache.org/jira/secure/attachment/12355273/GERONIMO-3010-4.patch 

In addition, this one combines the InstanceManager interfaces.  I think 
this is a bad idea because it forces jasper to use an interface shared 
with catalina, which the previous patch does not.  This makes catalina 
marginally more complicated when used as a standalone container for 
jasper but makes it possible to use jasper outside catalina without any 
catalina classes.  Note also that the previous (3c) patch allows use of 
tomcat embedded in a container that supplies its own InstanceManager 
implementation without pulling in any jasper classes at runtime.


This has 1 interface, 1 implementation.


Thanks for the patch revisions. I will look into adding these features 
after the next stable release.


Rémy

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

Re: Candidate binaries for 6.0.11

2007-04-12 Thread Remy Maucherat 

Yoav Shapira wrote:

After playing with these candidate binaries for just an hour or so,
things look good to me.


Yes, they seem fine. Most likely however, I won't propose a vote on 
them, as I would prefer picking up the NIO fixes with a 6.0.12 tag.


Rémy

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

Re: memory leak with shrinking thread pools

2007-04-12 Thread Filip Hanik - Dev Lists 

Peter Rossbach wrote:

HI Filip,

with your last checkin my trace changed but leak is there. Also I got 
a exception too:

yes, still working on it,
Filip


12.04.2007 17:20:30 org.apache.tomcat.util.net.NioSelectorPool 
getSharedSelector

INFO: Using a shared selector for servlet write/read
Event received connect BEGIN
Getting handler for action connect
New client connected TestClient0
Event received send BEGIN
Getting handler for action send
Sending message from TestClient0 message: 0-1176391230388
Disconnecting client (commit)
Sent 1 messages to connected client TestClient0
Event received connect BEGIN
Getting handler for action connect
Client reconnected: TestClient0
Event received connect END
Getting handler for action connect
Disconnecting client TestClient0
Disconnecting client (commit)
Event received connect END
Getting handler for action connect
Disconnecting client TestClient0
Event received connect BEGIN
Getting handler for action connect
Client reconnected: TestClient0
Event received disconnect BEGIN
Getting handler for action disconnect
Closing empty room 0
Disconnecting client (commit)
Remove client TestClient0. 0 clients remain.
Event received connect BEGIN
Getting handler for action connect
New client connected TestClient0
Event received send BEGIN
Getting handler for action send
Sending message from TestClient0 message: 0-1176391294275
Disconnecting client (commit)
Sent 1 messages to connected client TestClient0
Event received connect END
Getting handler for action connect
Disconnecting client TestClient0
Event received connect BEGIN
Getting handler for action connect
Client reconnected: TestClient0
Event received disconnect BEGIN
Getting handler for action disconnect
Closing empty room 0
Disconnecting client (commit)
Remove client TestClient0. 0 clients remain.
Exception in thread "http-30014-2" java.lang.NullPointerException
at 
org.apache.tomcat.util.net.NioEndpoint$Worker.run(NioEndpoint.java:1863)

at java.lang.Thread.run(Thread.java:613)
Event received connect BEGIN
Getting handler for action connect
New client connected TestClient0
Event received send BEGIN
Getting handler for action send
Sending message from TestClient0 message: 0-1176391394010
Disconnecting client (commit)
Sent 1 messages to connected client TestClient0
Event received connect END
Getting handler for action connect
Disconnecting client TestClient0
Event received connect BEGIN
Getting handler for action connect
Client reconnected: TestClient0
Event received disconnect BEGIN
Getting handler for action disconnect
Closing empty room 0
Disconnecting client (commit)
Remove client TestClient0. 0 clients remain.
Exception in thread "http-30014-1" java.lang.NullPointerException
at 
org.apache.tomcat.util.net.NioEndpoint$Worker.run(NioEndpoint.java:1863)

at java.lang.Thread.run(Thread.java:613)


Regards
Peter



Am 12.04.2007 um 16:29 schrieb Filip Hanik - Dev Lists:


Peter Rossbach wrote:

Hi Filip,


I have test your patch with my comet testclient.  It seems not 
working.  The RequestProcessors JMX Objects aren't deregistered:

So far the patch is only for NIO, I will make it for APR and JIO today.


Access Log:

'127.0.0.1:30014' 2007-04-12 13:05:46 /cometchat/?null - - - 200  0.001
'127.0.0.1:30014' 2007-04-12 13:05:46 /cometchat/chat?null 'connect' 
'TestClient0' - 200 '9A46086F29768BA775FBD2771D8614BC.tomcat6' 0.001
'127.0.0.1:30014' 2007-04-12 13:05:46 /cometchat/chat?null 'send' 
'TestClient0' '0-1176383146864' 200 
'9A46086F29768BA775FBD2771D8614BC.tomcat6' 0.002
'127.0.0.1:30014' 2007-04-12 13:05:46 /cometchat/chat?null 'connect' 
'TestClient0' - 200 '9A46086F29768BA775FBD2771D8614BC.tomcat6' 0.000
'127.0.0.1:30014' 2007-04-12 13:05:51 /cometchat/chat?null 
'disconnect' 'TestClient0' - 200 
'9A46086F29768BA775FBD2771D8614BC.tomcat6' 0.001




Am 12.04.2007 um 05:48 schrieb Filip Hanik - Dev Lists:


Here is a revised patch for the memory leak.
One thing I noticed is that it goes a little farther than I think 
it does.
Since every request processor gets registered with JMX, I just 
couldn't find a spot where it was unregistered.
And since the name was dynamic, ie based on the "count++" variable, 
there would be no way to unregister unless you knew the name.


http://people.apache.org/~fhanik/mem-leak-diff.patch

I suspect, that this memory leak also exists with the old thread 
pool, when you restart the endpoint in a running environment. At 
that time, all the threads get recycled, and most stuff gets 
unregistered, except the RequestInfo objects.


In this patch, I modified the usage of the recycledProcessor cache, 
to have a limit, and also to deregister objects should it be needed.


Personally, I'm still really confused about how everything gets 
registered with the MBean server and then holds hard references 
into the code itself.
On one note, I think the JMX stuff could simply have weak 
references, as in my old patch, but that could have other 
consequences.


Please commen

svn commit: r527981 - /tomcat/tc6.0.x/trunk/java/org/apache/juli/ClassLoaderLogManager.java

2007-04-12 Thread remm 
Author: remm
Date: Thu Apr 12 08:34:51 2007
New Revision: 527981

URL: http://svn.apache.org/viewvc?view=rev&rev=527981
Log:
- 42085: The handlers for the root logger are now added in addLogger when they 
are explicitly specified.

Modified:
tomcat/tc6.0.x/trunk/java/org/apache/juli/ClassLoaderLogManager.java

Modified: tomcat/tc6.0.x/trunk/java/org/apache/juli/ClassLoaderLogManager.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/juli/ClassLoaderLogManager.java?view=diff&rev=527981&r1=527980&r2=527981
==
--- tomcat/tc6.0.x/trunk/java/org/apache/juli/ClassLoaderLogManager.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/juli/ClassLoaderLogManager.java Thu 
Apr 12 08:34:51 2007
@@ -412,18 +412,6 @@
 }
 }
 
-// Add handlers to the root logger, if any are defined using the 
.handlers property.
-if (rootHandlers != null) {
-StringTokenizer tok2 = new StringTokenizer(rootHandlers, ",");
-while (tok2.hasMoreTokens()) {
-String handlerName = (tok2.nextToken().trim());
-Handler handler = (Handler) info.handlers.get(handlerName);
-if (handler != null) {
-localRootLogger.addHandler(handler);
-}
-}
-}
-
 }
 
 }



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

Re: memory leak with shrinking thread pools

2007-04-12 Thread Peter Rossbach 

HI Filip,

with your last checkin my trace changed but leak is there. Also I got  
a exception too:


12.04.2007 17:20:30 org.apache.tomcat.util.net.NioSelectorPool  
getSharedSelector

INFO: Using a shared selector for servlet write/read
Event received connect BEGIN
Getting handler for action connect
New client connected TestClient0
Event received send BEGIN
Getting handler for action send
Sending message from TestClient0 message: 0-1176391230388
Disconnecting client (commit)
Sent 1 messages to connected client TestClient0
Event received connect BEGIN
Getting handler for action connect
Client reconnected: TestClient0
Event received connect END
Getting handler for action connect
Disconnecting client TestClient0
Disconnecting client (commit)
Event received connect END
Getting handler for action connect
Disconnecting client TestClient0
Event received connect BEGIN
Getting handler for action connect
Client reconnected: TestClient0
Event received disconnect BEGIN
Getting handler for action disconnect
Closing empty room 0
Disconnecting client (commit)
Remove client TestClient0. 0 clients remain.
Event received connect BEGIN
Getting handler for action connect
New client connected TestClient0
Event received send BEGIN
Getting handler for action send
Sending message from TestClient0 message: 0-1176391294275
Disconnecting client (commit)
Sent 1 messages to connected client TestClient0
Event received connect END
Getting handler for action connect
Disconnecting client TestClient0
Event received connect BEGIN
Getting handler for action connect
Client reconnected: TestClient0
Event received disconnect BEGIN
Getting handler for action disconnect
Closing empty room 0
Disconnecting client (commit)
Remove client TestClient0. 0 clients remain.
Exception in thread "http-30014-2" java.lang.NullPointerException
at org.apache.tomcat.util.net.NioEndpoint$Worker.run 
(NioEndpoint.java:1863)

at java.lang.Thread.run(Thread.java:613)
Event received connect BEGIN
Getting handler for action connect
New client connected TestClient0
Event received send BEGIN
Getting handler for action send
Sending message from TestClient0 message: 0-1176391394010
Disconnecting client (commit)
Sent 1 messages to connected client TestClient0
Event received connect END
Getting handler for action connect
Disconnecting client TestClient0
Event received connect BEGIN
Getting handler for action connect
Client reconnected: TestClient0
Event received disconnect BEGIN
Getting handler for action disconnect
Closing empty room 0
Disconnecting client (commit)
Remove client TestClient0. 0 clients remain.
Exception in thread "http-30014-1" java.lang.NullPointerException
at org.apache.tomcat.util.net.NioEndpoint$Worker.run 
(NioEndpoint.java:1863)

at java.lang.Thread.run(Thread.java:613)


Regards
Peter



Am 12.04.2007 um 16:29 schrieb Filip Hanik - Dev Lists:


Peter Rossbach wrote:

Hi Filip,


I have test your patch with my comet testclient.  It seems not  
working.  The RequestProcessors JMX Objects aren't deregistered:
So far the patch is only for NIO, I will make it for APR and JIO  
today.


Access Log:

'127.0.0.1:30014' 2007-04-12 13:05:46 /cometchat/?null - - - 200   
0.001
'127.0.0.1:30014' 2007-04-12 13:05:46 /cometchat/chat?null  
'connect' 'TestClient0' - 200  
'9A46086F29768BA775FBD2771D8614BC.tomcat6' 0.001
'127.0.0.1:30014' 2007-04-12 13:05:46 /cometchat/chat?null 'send'  
'TestClient0' '0-1176383146864' 200  
'9A46086F29768BA775FBD2771D8614BC.tomcat6' 0.002
'127.0.0.1:30014' 2007-04-12 13:05:46 /cometchat/chat?null  
'connect' 'TestClient0' - 200  
'9A46086F29768BA775FBD2771D8614BC.tomcat6' 0.000
'127.0.0.1:30014' 2007-04-12 13:05:51 /cometchat/chat?null  
'disconnect' 'TestClient0' - 200  
'9A46086F29768BA775FBD2771D8614BC.tomcat6' 0.001




Am 12.04.2007 um 05:48 schrieb Filip Hanik - Dev Lists:


Here is a revised patch for the memory leak.
One thing I noticed is that it goes a little farther than I think  
it does.
Since every request processor gets registered with JMX, I just  
couldn't find a spot where it was unregistered.
And since the name was dynamic, ie based on the "count++"  
variable, there would be no way to unregister unless you knew the  
name.


http://people.apache.org/~fhanik/mem-leak-diff.patch

I suspect, that this memory leak also exists with the old thread  
pool, when you restart the endpoint in a running environment. At  
that time, all the threads get recycled, and most stuff gets  
unregistered, except the RequestInfo objects.


In this patch, I modified the usage of the recycledProcessor  
cache, to have a limit, and also to deregister objects should it  
be needed.


Personally, I'm still really confused about how everything gets  
registered with the MBean server and then holds hard references  
into the code itself.
On one note, I think the JMX stuff could simply have weak  
references, as in my old patch, but that could have other  
consequences.


Please comment on this patch, I'm pl

DO NOT REPLY [Bug 40668] - MailSessionFactory is missing in Tomcat 5.5.23

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

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





--- Additional Comments From [EMAIL PROTECTED]  2007-04-12 08:08 ---
I found a working link:

http://archive.apache.org/dist/tomcat/tomcat-5/v5.5.17/bin/apache-tomcat-5.5.17.zip

-- 
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: memory leak with shrinking thread pools

2007-04-12 Thread Peter Rossbach 

Hi Filip,

I have testet with NIO and the memory leak is still there.

Peter



Am 12.04.2007 um 16:29 schrieb Filip Hanik - Dev Lists:


Peter Rossbach wrote:

Hi Filip,


I have test your patch with my comet testclient.  It seems not  
working.  The RequestProcessors JMX Objects aren't deregistered:
So far the patch is only for NIO, I will make it for APR and JIO  
today.


Access Log:

'127.0.0.1:30014' 2007-04-12 13:05:46 /cometchat/?null - - - 200   
0.001
'127.0.0.1:30014' 2007-04-12 13:05:46 /cometchat/chat?null  
'connect' 'TestClient0' - 200  
'9A46086F29768BA775FBD2771D8614BC.tomcat6' 0.001
'127.0.0.1:30014' 2007-04-12 13:05:46 /cometchat/chat?null 'send'  
'TestClient0' '0-1176383146864' 200  
'9A46086F29768BA775FBD2771D8614BC.tomcat6' 0.002
'127.0.0.1:30014' 2007-04-12 13:05:46 /cometchat/chat?null  
'connect' 'TestClient0' - 200  
'9A46086F29768BA775FBD2771D8614BC.tomcat6' 0.000
'127.0.0.1:30014' 2007-04-12 13:05:51 /cometchat/chat?null  
'disconnect' 'TestClient0' - 200  
'9A46086F29768BA775FBD2771D8614BC.tomcat6' 0.001


Server.xml config:
...
className="org.apache.catalina.core.AprLifecycleListener"  
SSLEngine="on" />


...


protocol="org.apache.coyote.http11.Http11AprProtocol"/>

   pollerSize="1024" />

protocol="org.apache.coyote.http11.Http11NioProtocol"/>

...



With NIO I see the following event log:

Event received connect BEGIN
Getting handler for action connect
New client connected TestClient0
Event received send BEGIN
Getting handler for action send
Sending message from TestClient0 message: 0-1176383115466
Disconnecting client (commit)
Sent 1 messages to connected client TestClient0
Event received connect BEGIN
Getting handler for action connect
Client reconnected: TestClient0
Event received disconnect BEGIN
Getting handler for action disconnect
Closing empty room 0
Disconnecting client (commit)
Remove client TestClient0. 0 clients remain.

After every test  three more JMX RequestProcessors are registered.
I don't see the Comet END events like the APR Connector send to my  
ChatServlet.

What steps do you take to see an "END" event?
Filip


APR Connector Log

Event received connect BEGIN
Getting handler for action connect
New client connected TestClient0
Event received send BEGIN
Getting handler for action send
Sending message from TestClient0 message: 0-1176383857840
Disconnecting client (commit)
Sent 1 messages to connected client TestClient0
Event received connect END
Getting handler for action connect
Disconnecting client TestClient0
Event received connect BEGIN
Getting handler for action connect
Client reconnected: TestClient0
Event received disconnect BEGIN
Getting handler for action disconnect
Closing empty room 0
Disconnecting client (commit)
Remove client TestClient0. 0 clients remain.
Event received connect END
Getting handler for action connect

Regards
Peter


Am 12.04.2007 um 05:48 schrieb Filip Hanik - Dev Lists:


Here is a revised patch for the memory leak.
One thing I noticed is that it goes a little farther than I think  
it does.
Since every request processor gets registered with JMX, I just  
couldn't find a spot where it was unregistered.
And since the name was dynamic, ie based on the "count++"  
variable, there would be no way to unregister unless you knew the  
name.


http://people.apache.org/~fhanik/mem-leak-diff.patch

I suspect, that this memory leak also exists with the old thread  
pool, when you restart the endpoint in a running environment. At  
that time, all the threads get recycled, and most stuff gets  
unregistered, except the RequestInfo objects.


In this patch, I modified the usage of the recycledProcessor  
cache, to have a limit, and also to deregister objects should it  
be needed.


Personally, I'm still really confused about how everything gets  
registered with the MBean server and then holds hard references  
into the code itself.
On one note, I think the JMX stuff could simply have weak  
references, as in my old patch, but that could have other  
consequences.


Please comment on this patch, I'm planning on committing it  
tomorrow (Thursday) as it seems to work well for me.


Filip



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

DO NOT REPLY [Bug 40668] - MailSessionFactory is missing in Tomcat 5.5.23

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

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





--- Additional Comments From [EMAIL PROTECTED]  2007-04-12 08:02 ---
The link in comment #2 to obtain the missing files does not work. Could somebody
post a working link?

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

svn commit: r527964 - /tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java

2007-04-12 Thread fhanik 
Author: fhanik
Date: Thu Apr 12 07:53:06 2007
New Revision: 527964

URL: http://svn.apache.org/viewvc?view=rev&rev=527964
Log:
Don't unmark the object as a comet, if we do, it will not call the cleanup for 
it

Modified:
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java?view=diff&rev=527964&r1=527963&r2=527964
==
--- tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java 
Thu Apr 12 07:53:06 2007
@@ -1073,7 +1073,6 @@
 //then execute the connection closure at the next selector 
loop
 
request.getAttributes().remove("org.apache.tomcat.comet.timeout");
 attach.setError(true);
-attach.setComet(false);
 }
 }
 



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

Re: Tagging 1.2.22

2007-04-12 Thread Rainer Jung 

diff to our last candidate and simple build on Solaris look good :)

Mladen Turk wrote:

Mladen Turk wrote:

Hi,

The quality check release was out few days ago.


Hi there is new quality check release available from:
http://people.apache.org/~mturk/jk-1.2.22-dev/

It contains few minor fixes mostly for documentation
and release script (owner/group for .tar)

I'll give it 24 hours before making a tag for any
last minute checks.


Regards,
Mladen.


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

Re: memory leak with shrinking thread pools

2007-04-12 Thread Filip Hanik - Dev Lists 

Peter Rossbach wrote:

Hi Filip,


I have test your patch with my comet testclient.  It seems not 
working.  The RequestProcessors JMX Objects aren't deregistered:

So far the patch is only for NIO, I will make it for APR and JIO today.


Access Log:

'127.0.0.1:30014' 2007-04-12 13:05:46 /cometchat/?null - - - 200  0.001
'127.0.0.1:30014' 2007-04-12 13:05:46 /cometchat/chat?null 'connect' 
'TestClient0' - 200 '9A46086F29768BA775FBD2771D8614BC.tomcat6' 0.001
'127.0.0.1:30014' 2007-04-12 13:05:46 /cometchat/chat?null 'send' 
'TestClient0' '0-1176383146864' 200 
'9A46086F29768BA775FBD2771D8614BC.tomcat6' 0.002
'127.0.0.1:30014' 2007-04-12 13:05:46 /cometchat/chat?null 'connect' 
'TestClient0' - 200 '9A46086F29768BA775FBD2771D8614BC.tomcat6' 0.000
'127.0.0.1:30014' 2007-04-12 13:05:51 /cometchat/chat?null 
'disconnect' 'TestClient0' - 200 
'9A46086F29768BA775FBD2771D8614BC.tomcat6' 0.001


Server.xml config:
...
className="org.apache.catalina.core.AprLifecycleListener" 
SSLEngine="on" />


...

   
protocol="org.apache.coyote.http11.Http11AprProtocol"/>

   pollerSize="1024" />
   
protocol="org.apache.coyote.http11.Http11NioProtocol"/>

...



With NIO I see the following event log:

Event received connect BEGIN
Getting handler for action connect
New client connected TestClient0
Event received send BEGIN
Getting handler for action send
Sending message from TestClient0 message: 0-1176383115466
Disconnecting client (commit)
Sent 1 messages to connected client TestClient0
Event received connect BEGIN
Getting handler for action connect
Client reconnected: TestClient0
Event received disconnect BEGIN
Getting handler for action disconnect
Closing empty room 0
Disconnecting client (commit)
Remove client TestClient0. 0 clients remain.

After every test  three more JMX RequestProcessors are registered.
I don't see the Comet END events like the APR Connector send to my 
ChatServlet.

What steps do you take to see an "END" event?
Filip


APR Connector Log

Event received connect BEGIN
Getting handler for action connect
New client connected TestClient0
Event received send BEGIN
Getting handler for action send
Sending message from TestClient0 message: 0-1176383857840
Disconnecting client (commit)
Sent 1 messages to connected client TestClient0
Event received connect END
Getting handler for action connect
Disconnecting client TestClient0
Event received connect BEGIN
Getting handler for action connect
Client reconnected: TestClient0
Event received disconnect BEGIN
Getting handler for action disconnect
Closing empty room 0
Disconnecting client (commit)
Remove client TestClient0. 0 clients remain.
Event received connect END
Getting handler for action connect

Regards
Peter


Am 12.04.2007 um 05:48 schrieb Filip Hanik - Dev Lists:


Here is a revised patch for the memory leak.
One thing I noticed is that it goes a little farther than I think it 
does.
Since every request processor gets registered with JMX, I just 
couldn't find a spot where it was unregistered.
And since the name was dynamic, ie based on the "count++" variable, 
there would be no way to unregister unless you knew the name.


http://people.apache.org/~fhanik/mem-leak-diff.patch

I suspect, that this memory leak also exists with the old thread 
pool, when you restart the endpoint in a running environment. At that 
time, all the threads get recycled, and most stuff gets unregistered, 
except the RequestInfo objects.


In this patch, I modified the usage of the recycledProcessor cache, 
to have a limit, and also to deregister objects should it be needed.


Personally, I'm still really confused about how everything gets 
registered with the MBean server and then holds hard references into 
the code itself.
On one note, I think the JMX stuff could simply have weak references, 
as in my old patch, but that could have other consequences.


Please comment on this patch, I'm planning on committing it tomorrow 
(Thursday) as it seems to work well for me.


Filip



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

Re: Candidate binaries for 6.0.11

2007-04-12 Thread Yoav Shapira 

After playing with these candidate binaries for just an hour or so,
things look good to me.

Yoav

On 4/11/07, Remy Maucherat <[EMAIL PROTECTED]> wrote:

Candidate binaries are available here:
http://people.apache.org/~remm/tomcat-6/v6.0.11/

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: memory leak with shrinking thread pools

2007-04-12 Thread Peter Rossbach 

Hi Filip,


I have test your patch with my comet testclient.  It seems not  
working.  The RequestProcessors JMX Objects aren't deregistered:


Access Log:

'127.0.0.1:30014' 2007-04-12 13:05:46 /cometchat/?null - - - 200  0.001
'127.0.0.1:30014' 2007-04-12 13:05:46 /cometchat/chat?null 'connect'  
'TestClient0' - 200 '9A46086F29768BA775FBD2771D8614BC.tomcat6' 0.001
'127.0.0.1:30014' 2007-04-12 13:05:46 /cometchat/chat?null 'send'  
'TestClient0' '0-1176383146864' 200  
'9A46086F29768BA775FBD2771D8614BC.tomcat6' 0.002
'127.0.0.1:30014' 2007-04-12 13:05:46 /cometchat/chat?null 'connect'  
'TestClient0' - 200 '9A46086F29768BA775FBD2771D8614BC.tomcat6' 0.000
'127.0.0.1:30014' 2007-04-12 13:05:51 /cometchat/chat?null  
'disconnect' 'TestClient0' - 200  
'9A46086F29768BA775FBD2771D8614BC.tomcat6' 0.001


Server.xml config:
...
className="org.apache.catalina.core.AprLifecycleListener"  
SSLEngine="on" />


...


protocol="org.apache.coyote.http11.Http11AprProtocol"/>

   pollerSize="1024" />

protocol="org.apache.coyote.http11.Http11NioProtocol"/>

...



With NIO I see the following event log:

Event received connect BEGIN
Getting handler for action connect
New client connected TestClient0
Event received send BEGIN
Getting handler for action send
Sending message from TestClient0 message: 0-1176383115466
Disconnecting client (commit)
Sent 1 messages to connected client TestClient0
Event received connect BEGIN
Getting handler for action connect
Client reconnected: TestClient0
Event received disconnect BEGIN
Getting handler for action disconnect
Closing empty room 0
Disconnecting client (commit)
Remove client TestClient0. 0 clients remain.

After every test  three more JMX RequestProcessors are registered.
I don't see the Comet END events like the APR Connector send to my  
ChatServlet.


APR Connector Log

Event received connect BEGIN
Getting handler for action connect
New client connected TestClient0
Event received send BEGIN
Getting handler for action send
Sending message from TestClient0 message: 0-1176383857840
Disconnecting client (commit)
Sent 1 messages to connected client TestClient0
Event received connect END
Getting handler for action connect
Disconnecting client TestClient0
Event received connect BEGIN
Getting handler for action connect
Client reconnected: TestClient0
Event received disconnect BEGIN
Getting handler for action disconnect
Closing empty room 0
Disconnecting client (commit)
Remove client TestClient0. 0 clients remain.
Event received connect END
Getting handler for action connect

Regards
Peter


Am 12.04.2007 um 05:48 schrieb Filip Hanik - Dev Lists:


Here is a revised patch for the memory leak.
One thing I noticed is that it goes a little farther than I think  
it does.
Since every request processor gets registered with JMX, I just  
couldn't find a spot where it was unregistered.
And since the name was dynamic, ie based on the "count++" variable,  
there would be no way to unregister unless you knew the name.


http://people.apache.org/~fhanik/mem-leak-diff.patch

I suspect, that this memory leak also exists with the old thread  
pool, when you restart the endpoint in a running environment. At  
that time, all the threads get recycled, and most stuff gets  
unregistered, except the RequestInfo objects.


In this patch, I modified the usage of the recycledProcessor cache,  
to have a limit, and also to deregister objects should it be needed.


Personally, I'm still really confused about how everything gets  
registered with the MBean server and then holds hard references  
into the code itself.
On one note, I think the JMX stuff could simply have weak  
references, as in my old patch, but that could have other  
consequences.


Please comment on this patch, I'm planning on committing it  
tomorrow (Thursday) as it seems to work well for me.


Filip


Filip Hanik - Dev Lists wrote:
Index: java/org/apache/coyote/http11/Http11NioProtocol.java
===
--- java/org/apache/coyote/http11/Http11NioProtocol.java	(revision  
527526)
+++ java/org/apache/coyote/http11/Http11NioProtocol.java	(working  
copy)

@@ -22,7 +22,9 @@
 import java.util.Hashtable;
 import java.util.Iterator;
 import java.util.concurrent.ConcurrentHashMap;
+import java.util.concurrent.ConcurrentLinkedQueue;
 import java.util.concurrent.Executor;
+import java.util.concurrent.atomic.AtomicInteger;
 import javax.management.MBeanRegistration;
 import javax.management.MBeanServer;
 import javax.management.ObjectName;
@@ -212,6 +214,7 @@
 private int timeout = 30;   // 5 minutes as in Apache  
HTTPD server

 private int maxSavePostSize = 4 * 1024;
 private int maxHttpHeaderSize = 8 * 1024;
+protected int processorCache = 200; //max number of  
Http11NioProcessor objects cached

 private int socketCloseDelay=-1;
 private boolean disableUploadTimeout =

DO NOT REPLY [Bug 41956] - New HTTP connector - The ip address not saved within server.xml

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

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





--- Additional Comments From [EMAIL PROTECTED]  2007-04-12 05:41 ---
Does anybody have an idea ?

-- 
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 41956] - New HTTP connector - The ip address not saved within server.xml

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

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





--- Additional Comments From [EMAIL PROTECTED]  2007-04-12 05:41 ---
Does anybody have an idea ?

-- 
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: memory leak with shrinking thread pools

2007-04-12 Thread Remy Maucherat 

Filip Hanik - Dev Lists wrote:

Here is a revised patch for the memory leak.
One thing I noticed is that it goes a little farther than I think it does.
Since every request processor gets registered with JMX, I just couldn't 
find a spot where it was unregistered.
And since the name was dynamic, ie based on the "count++" variable, 
there would be no way to unregister unless you knew the name.


It needs to be unregistered when (= if) it is discarded. However, the 
monitoring needs were there when the processor was associated with a 
thread. Now with comet and executors, this is not the case. So it may be 
a good idea to think and see if a similar monitoring capability with a 
different implementation could be provided in the future (otherwise, it 
should probably go away).



http://people.apache.org/~fhanik/mem-leak-diff.patch


In the immediate future, I think it's the best solution.

I suspect, that this memory leak also exists with the old thread pool, 
when you restart the endpoint in a running environment. At that time, 
all the threads get recycled, and most stuff gets unregistered, except 
the RequestInfo objects.


In this patch, I modified the usage of the recycledProcessor cache, to 
have a limit, and also to deregister objects should it be needed.


It should have a mechanical limit already: it's the maximum amount of 
concurrent connections + the maximum amount of comet connections. Giving 
it a lower limit would mean creating processors, which is expensive. I 
suggest adding a parameter.


Personally, I'm still really confused about how everything gets 
registered with the MBean server and then holds hard references into the 
code itself.
On one note, I think the JMX stuff could simply have weak references, as 
in my old patch, but that could have other consequences.


IMO, weak references are too weird, plus it would not solve any 
registration issue.


Please comment on this patch, I'm planning on committing it tomorrow 
(Thursday) as it seems to work well for me.


Rémy

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

Re: Tagging 1.2.22

2007-04-12 Thread Guenter Knauf 
Hi,
> Hi there is new quality check release available from:
> http://people.apache.org/~mturk/jk-1.2.22-dev/

> It contains few minor fixes mostly for documentation
> and release script (owner/group for .tar)

> I'll give it 24 hours before making a tag for any
> last minute checks.
+1 for NetWare, tested with TC 3.3.1, 4.1.31, 4.1.34, 5.0.30.

Guenter.



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