svn commit: r527486 - /tomcat/connectors/trunk/jk/tools/jkrelease.sh

[mturk]

Author: mturk
Date: Wed Apr 11 06:28:06 2007
New Revision: 527486

URL: http://svn.apache.org/viewvc?view=rev&rev=527486
Log:
Add more options for links/elinks so it doesn't dump links in generated text 
files.

Modified:
tomcat/connectors/trunk/jk/tools/jkrelease.sh

Modified: tomcat/connectors/trunk/jk/tools/jkrelease.sh
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/tools/jkrelease.sh?view=diff&rev=527486&r1=527485&r2=527486
==
--- tomcat/connectors/trunk/jk/tools/jkrelease.sh (original)
+++ tomcat/connectors/trunk/jk/tools/jkrelease.sh Wed Apr 11 06:28:06 2007
@@ -127,8 +127,8 @@
 
 # Check for links, elinks or w3m
 W3MOPTS="-dump -cols 80 -t 4 -S -O iso-8859-1 -T text/html"
-LNKOPTS="-dump"
-ELNKOPTS="--dump --no-numbering --no-home"
+LNKOPTS="-dump -dump-width 80 -dump-charset iso-8859-1 -no-numbering 
-no-references -no-home"
+ELNKOPTS=$LNKOPTS
 failed=true
 for tool in `echo "w3m elinks links"`
 do



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

svn commit: r527492 - in /tomcat/connectors/trunk/jk/native: apache-1.3/Makefile.vc apache-2.0/Makefile.vc

[mturk]

Author: mturk
Date: Wed Apr 11 06:50:33 2007
New Revision: 527492

URL: http://svn.apache.org/viewvc?view=rev&rev=527492
Log:
Update command line Makefiles so they can produce multiple targets without 
writing to the same output directory.

Modified:
tomcat/connectors/trunk/jk/native/apache-1.3/Makefile.vc
tomcat/connectors/trunk/jk/native/apache-2.0/Makefile.vc

Modified: tomcat/connectors/trunk/jk/native/apache-1.3/Makefile.vc
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/apache-1.3/Makefile.vc?view=diff&rev=527492&r1=527491&r2=527492
==
--- tomcat/connectors/trunk/jk/native/apache-1.3/Makefile.vc (original)
+++ tomcat/connectors/trunk/jk/native/apache-1.3/Makefile.vc Wed Apr 11 
06:50:33 2007
@@ -1,37 +1,23 @@
-# Microsoft Developer Studio Generated NMAKE File, Based on mod_jk.dsp
-!IF "$(CFG)" == ""
-CFG=mod_jk - Win32 Release
-!MESSAGE No configuration specified. Defaulting to mod_jk - Win32 Release.
-!ENDIF 
-
-!IF "$(CFG)" != "mod_jk - Win32 Release"
-!MESSAGE Invalid configuration "$(CFG)" specified.
-!MESSAGE You can specify a configuration when running NMAKE
-!MESSAGE by defining the macro CFG on the command line. For example:
-!MESSAGE 
-!MESSAGE NMAKE /f "Makefile.vc" CFG="mod_jk - Win32 Release"
-!MESSAGE 
-!MESSAGE Possible choices for configuration are:
-!MESSAGE 
-!MESSAGE "mod_jk - Win32 Release" (based on "Win32 (x86) Dynamic-Link Library")
-!MESSAGE 
-!ERROR An invalid configuration is specified.
-!ENDIF 
-
 !IF "$(OS)" == "Windows_NT"
 NULL=
 !ELSE 
 NULL=nul
 !ENDIF 
 
+!IFDEF EAPI
+OUTDIR=.\ReleaseSSL
+INTDIR=.\ReleaseSSL
+DEF_EAPI=/D "EAPI"
+!ELSE
+OUTDIR=.\Release
+INTDIR=.\Release
+DEF_EAPI=
+!ENDIF
+
+
 CPP=cl.exe
 MTL=midl.exe
 RSC=rc.exe
-OUTDIR=.\Release
-INTDIR=.\Release
-# Begin Custom Macros
-OutDir=.\Release
-# End Custom Macros
 
 ALL : "$(OUTDIR)\mod_jk.so"
 
@@ -102,7 +88,7 @@
   $(LINK32_FLAGS) $(LINK32_OBJS)
 <<
 
-CPP_PROJ=/nologo /MD /W3 /Zi /O2 /I "..\common" /I "$(APACHE1_HOME)\include" 
/I "$(JAVA_HOME)\include" /I "$(JAVA_HOME)\include\win32" /D "WIN32" /D 
"NDEBUG" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /D "MOD_JK_EXPORTS" 
/Fo"$(INTDIR)\\" /Fd"$(INTDIR)\mod_jk_src" /FD /c 
+CPP_PROJ=/nologo /MD /W3 /Zi /O2 /I "..\common" /I "$(APACHE1_HOME)\include" 
/I "$(JAVA_HOME)\include" /I "$(JAVA_HOME)\include\win32" /D "WIN32" /D 
"NDEBUG" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" $(DEF_EAPI) /D "MOD_JK_EXPORTS" 
/Fo"$(INTDIR)\\" /Fd"$(INTDIR)\mod_jk_src" /FD /c 
 
 .c{$(INTDIR)}.obj::
$(CPP) @<<
@@ -136,16 +122,7 @@
 
 MTL_PROJ=/nologo /D "NDEBUG" /mktyplib203 /win32 
 
-!IF "$(NO_EXTERNAL_DEPS)" != "1"
-!IF EXISTS("mod_jk.dep")
-!INCLUDE "mod_jk.dep"
-!ELSE 
-!MESSAGE Warning: cannot find "mod_jk.dep"
-!ENDIF 
-!ENDIF 
 
-
-!IF "$(CFG)" == "mod_jk - Win32 Release"
 SOURCE=..\common\jk_ajp12_worker.c
 
 "$(INTDIR)\jk_ajp12_worker.obj" : $(SOURCE) "$(INTDIR)"
@@ -269,8 +246,3 @@
 SOURCE=.\mod_jk.c
 
 "$(INTDIR)\mod_jk.obj" : $(SOURCE) "$(INTDIR)"
-
-
-
-!ENDIF 
-

Modified: tomcat/connectors/trunk/jk/native/apache-2.0/Makefile.vc
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/apache-2.0/Makefile.vc?view=diff&rev=527492&r1=527491&r2=527492
==
--- tomcat/connectors/trunk/jk/native/apache-2.0/Makefile.vc (original)
+++ tomcat/connectors/trunk/jk/native/apache-2.0/Makefile.vc Wed Apr 11 
06:50:33 2007
@@ -2,9 +2,13 @@
 APACHE2_HOME=$(APACHE22_HOME)
 APR_LIB=libapr-1.lib
 APU_LIB=libaprutil-1.lib
+OUTDIR=.\Release22
+INTDIR=.\Release22
 !ELSE
 APR_LIB=libapr.lib
 APU_LIB=libaprutil.lib
+OUTDIR=.\Release20
+INTDIR=.\Release20
 !IFDEF APACHE20_HOME
 APACHE2_HOME=$(APACHE20_HOME)
 !ENDIF
@@ -17,11 +21,6 @@
 CPP=cl.exe
 MTL=midl.exe
 RSC=rc.exe
-OUTDIR=.\Release
-INTDIR=.\Release
-# Begin Custom Macros
-OutDir=.\Release
-# End Custom Macros
 
 ALL : "$(OUTDIR)\mod_jk.so"
 



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

Re: Tagging 1.2.22

[Mladen Turk]

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]

DO NOT REPLY [Bug 25060] - Reloading context orphans currently open jndi datasource connections

[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=25060





--- Additional Comments From [EMAIL PROTECTED]  2007-04-11 07:57 ---
Hey Mark!
I respectfully disagree with you about this being a enhancement.
If the datasources are left to be garbage collected, their connections with the
database remain opened (as i just experienced on Tomcat 5.0.28). Since most
database installations rely on a maximum number of connections, the new
datasource resulting of the context's reload might not be able to connect to the
database, right? If these affirmations are right, IMHO this issue is a bug.
What do you think?
Thank you for your time! :)

-- 
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: r527512 - /tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java

[fhanik]

Author: fhanik
Date: Wed Apr 11 08:03:10 2007
New Revision: 527512

URL: http://svn.apache.org/viewvc?view=rev&rev=527512
Log:
big oopsie, I know, right after the tag got created

Modified:
tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java

Modified: tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java?view=diff&rev=527512&r1=527511&r2=527512
==
--- tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java Wed 
Apr 11 08:03:10 2007
@@ -790,7 +790,7 @@
 executor = new ThreadPoolExecutor(getMinSpareThreads(), 
getMaxThreads(), 60, TimeUnit.SECONDS,taskqueue, tf);
 taskqueue.setParent( (ThreadPoolExecutor) executor);
 }
-} else if ( executor != null ) {//avoid two thread pools being 
created
+} else if ( executor == null ) {//avoid two thread pools being 
created
 workers = new WorkerStack(maxThreads);
 }
 



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

DO NOT REPLY [Bug 42090] New: - tcnative badly handles some OpenSSL disconnections.

[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=42090

   Summary: tcnative badly handles some OpenSSL disconnections.
   Product: Tomcat 5
   Version: 5.5.20
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: critical
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


Upon a network failure, this happens in ssl_socket_recv()
(jni/native/src/sslnetwork.c) :

SSL_read() return ZERO.
con->ssl->shutdown does not get the SSL_RECEIVED_SHUTDOWN flag.
SSL_get_error() returns SSL_ERROR_SYSCALL.
apr_get_netos_error() returns ZERO.

As a consequence, ssl_socket_recv() just returns ZERO, which is also
APR_SUCCESS. Thus, the network failure is undetected and the caller (APR) enters
a 100% CPU loop !

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

Candidate binaries for 6.0.11

[Remy Maucherat]

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]

memory leak with shrinking thread pools

[Filip Hanik - Dev Lists]

Thanks to Peter Rossbach for alerting me to this.

If we are using the Executor, and are using shrinking thread pools, the 
RequestGroupInfo collects these objects and never releases them.
The only reason we don't see the problem with the default thread pool, 
is cause it never shrinks, hence it never loses it's thread local 
reference to the object.


Current workarounds are:
1. maxThreads==minSpareThreads
2. Disable JMX

Example of reference tree
http://people.apache.org/~fhanik/shrinking-pool-leak.html

Filip

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

DO NOT REPLY [Bug 42090] - tcnative badly handles some OpenSSL disconnections.

[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=42090





--- Additional Comments From [EMAIL PROTECTED]  2007-04-11 08:57 ---
Created an attachment (id=19931)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=19931&action=view)
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: memory leak with shrinking thread pools

[Filip Hanik - Dev Lists]

attached is an example patch using weak references that would solve this 
problem,

I'd like to get thoughts on this patch, please comment

if the attachment doesn't make it
http://people.apache.org/~fhanik/mem-leak-diff.patch

Filip

Filip Hanik - Dev Lists wrote:

Thanks to Peter Rossbach for alerting me to this.

If we are using the Executor, and are using shrinking thread pools, 
the RequestGroupInfo collects these objects and never releases them.
The only reason we don't see the problem with the default thread pool, 
is cause it never shrinks, hence it never loses it's thread local 
reference to the object.


Current workarounds are:
1. maxThreads==minSpareThreads
2. Disable JMX

Example of reference tree
http://people.apache.org/~fhanik/shrinking-pool-leak.html

Filip

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





Index: java/org/apache/coyote/RequestGroupInfo.java
===
--- java/org/apache/coyote/RequestGroupInfo.java(revision 527526)
+++ java/org/apache/coyote/RequestGroupInfo.java(working copy)
@@ -18,13 +18,14 @@
 package org.apache.coyote;
 
 import java.util.ArrayList;
+import java.lang.ref.WeakReference;
 
 /** This can be moved to top level ( eventually with a better name ).
  *  It is currently used only as a JMX artifact, to agregate the data
  *  collected from each RequestProcessor thread.
  */
 public class RequestGroupInfo {
-ArrayList processors=new ArrayList();
+ArrayList> processors=new 
ArrayList>();
 private long deadMaxTime = 0;
 private long deadProcessingTime = 0;
 private int deadRequestCount = 0;
@@ -33,7 +34,8 @@
 private long deadBytesSent = 0;
 
 public synchronized void addRequestProcessor( RequestInfo rp ) {
-processors.add( rp );
+WeakReference reference = new 
WeakReference(rp);
+processors.add( reference );
 }
 
 public synchronized void removeRequestProcessor( RequestInfo rp ) {
@@ -45,16 +47,18 @@
 deadErrorCount += rp.getErrorCount();
 deadBytesReceived += rp.getBytesReceived();
 deadBytesSent += rp.getBytesSent();
-
-processors.remove( rp );
+for (int i=processors.size()-1; i>=0; i-- ) {
+if ( processors.get(i).get()== null || 
processors.get(i).get().equals(rp) )
+processors.remove(rp);
+}
 }
 }
 
 public synchronized long getMaxTime() {
 long maxTime=deadMaxTime;
 for( int i=0; i hook;
 
 private int bytesRead=0;
 // Time of the request - usefull to avoid repeated calls to 
System.currentTime
@@ -341,14 +342,14 @@
 }
 
 public void action(ActionCode actionCode, Object param) {
-if( hook==null && response!=null )
-hook=response.getHook();
+if( (hook==null || hook.get()==null ) && response!=null )
+hook= new WeakReference(response.getHook());
 
 if (hook != null) {
 if( param==null ) 
-hook.action(actionCode, this);
+hook.get().action(actionCode, this);
 else
-hook.action(actionCode, param);
+hook.get().action(actionCode, param);
 }
 }
 
Index: java/org/apache/coyote/Response.java
===
--- java/org/apache/coyote/Response.java(revision 527526)
+++ java/org/apache/coyote/Response.java(working copy)
@@ -22,6 +22,7 @@
 
 import org.apache.tomcat.util.buf.ByteChunk;
 import org.apache.tomcat.util.http.MimeHeaders;
+import java.lang.ref.WeakReference;
 
 /**
  * Response object.
@@ -92,7 +93,7 @@
 /**
  * Action hook.
  */
-public ActionHook hook;
+public WeakReference hook;
 
 
 /**
@@ -150,12 +151,12 @@
 
 
 public ActionHook getHook() {
-return hook;
+return hook.get();
 }
 
 
 public void setHook(ActionHook hook) {
-this.hook = hook;
+this.hook = new WeakReference(hook);
 }
 
 
@@ -176,11 +177,12 @@
 
 
 public void action(ActionCode actionCode, Object param) {
-if (hook != null) {
+if (hook != null && hook.get()!=null) {
 if( param==null ) 
-hook.action(actionCode, this);
-else
-hook.action(actionCode, param);
+hook.get().action(actionCode, this);
+else {
+hook.get().action(actionCode, param);
+}
 }
 }
 

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

DO NOT REPLY [Bug 42038] - JK uriworkermap ROOT mapping causes non-virtual exclusions to be ignored

[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=42038





--- Additional Comments From [EMAIL PROTECTED]  2007-04-11 10:42 ---
Created an attachment (id=19932)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=19932&action=view)
Corrected version of files from 1.2.21

Attached is a patch which corrects the behavior to match the documentation.
This allows a site without multiple virtual hosts to use a
uriworkermap.properties such as:

/*=v7CDALiveWorker
/umich|/*=v7CDALiveWorker
#Exclude static files
!/UMICH/*=v7CDALiveWorker
!/StaticFiles/*=v7CDALiveWorker
!/System/*=v7CDALiveWorker
!/Humin-migration/*=v7CDALiveWorker

It also allows a site with multiple virtual hosts to use a
uriworkermap.properties like:
/lsa-cmsdev1.lsa.adsroot.itcs.umich.edu/*=v7CDALiveWorker
/lsa-cmsdev1.lsa.adsroot.itcs.umich.edu/umich|/*=v7CDALiveWorker
#Exclude static files
!/lsa-cmsdev1.lsa.adsroot.itcs.umich.edu/UMICH/*=v7CDALiveWorker
!/lsa-cmsdev1.lsa.adsroot.itcs.umich.edu/StaticFiles/*=v7CDALiveWorker
!/lsa-cmsdev1.lsa.adsroot.itcs.umich.edu/System/*=v7CDALiveWorker
!/lsa-cmsdev1.lsa.adsroot.itcs.umich.edu/Humin-migration/*=v7CDALiveWorker

I have submitted the complete altered files rather than a patch because I do
not know the patch format preferred, and I am concerned I did not correctly
follow the tab/spacing standards. Also, I believe the files have changed since
the last release, and a patch may not cleanly apply. Let me know if you would
like me to correct these.


-- 
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 42038] - JK uriworkermap ROOT mapping causes non-virtual exclusions to be ignored

[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=42038


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WONTFIX |




--- Additional Comments From [EMAIL PROTECTED]  2007-04-11 10:47 ---
I believe that the current behavior is contrary to the documentation, and that
altering the configuration file format is not necessary to solve it. My attached
solution may break working configurations that mixed and matched virtual with
non-virtual mounts, but it may not. I would like someone who is more familiar
with the code and C to examine my solution, as I may have overlooked something.

-- 
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 42085] - java.util.Logging duplicated since 5.5.23. 5.5.20 is OK

[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=42085


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||asf-
   ||[EMAIL PROTECTED]




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

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

DO NOT REPLY [Bug 42085] - java.util.Logging duplicated since 5.5.23. 5.5.20 is OK

[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=42085


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |NEEDINFO




--- Additional Comments From [EMAIL PROTECTED]  2007-04-11 12:13 ---
java.util.logging.FileHandler extends java.util.logging.StreamHandler. The
no-args constructors for these two classes both make a call to the configure()
method, which is why you see two TivoliFormatters created when the tivoli
handler is set up. This shouldn't cause duplication, though; the first formatter
to be created is simply discarded, and only the second is used.

Could you give more information about your setup? I can't duplicate this
problem. Is that your entire logging.properties file? How does your code use the
logger?

If I put these lines into a test servlet:

Logger logger = Logger.getLogger("");
logger.severe("Handlers: " + Arrays.asList(logger.getHandlers()));

and make a request to it (using your logging.properties file), the console shows
that the root logger has two handlers (both FileHandlers).


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

[Remy Maucherat]

Filip Hanik - Dev Lists wrote:
attached is an example patch using weak references that would solve this 
problem,

I'd like to get thoughts on this patch, please comment

if the attachment doesn't make it
http://people.apache.org/~fhanik/mem-leak-diff.patch


For sure it's not the right way to do it (the right way being 
unregistering the appropriate management artifacts when the associated 
resources are released - if it's not possible, then it means the design 
of the said resources is broken).


Rémy

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

DO NOT REPLY [Bug 42038] - JK uriworkermap ROOT mapping causes non-virtual exclusions to be ignored

[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=42038


[EMAIL PROTECTED] changed:

   What|Removed |Added

  Attachment #19932|0   |1
is obsolete||




--- Additional Comments From [EMAIL PROTECTED]  2007-04-11 14:13 ---
Created an attachment (id=19934)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=19934&action=view)
Altered Files against 1.2.22

This updates the files to be against the
tomcat-connectors-1.2.22-dev-527493-src.zip that Mladen made available. You can
uncompress them as an overlay.

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

[Filip Hanik - Dev Lists]

Remy Maucherat wrote:

Filip Hanik - Dev Lists wrote:
attached is an example patch using weak references that would solve 
this problem,

I'd like to get thoughts on this patch, please comment

if the attachment doesn't make it
http://people.apache.org/~fhanik/mem-leak-diff.patch


For sure it's not the right way to do it (the right way being 
unregistering the appropriate management artifacts when the associated 
resources are released - if it's not possible, then it means the 
design of the said resources is broken).
you're of course right, I think I simply need to get rid of the thread 
local cache, and use the processor cache instead.
do you have any idea of the performance penalty? I'd probably use a 
ConcurrentLinkedQueue or something instead of synchronized{processorCache}


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]

Re: memory leak with shrinking thread pools

[Remy Maucherat]

Filip Hanik - Dev Lists wrote:
you're of course right, I think I simply need to get rid of the thread 
local cache, and use the processor cache instead.
do you have any idea of the performance penalty? I'd probably use a 
ConcurrentLinkedQueue or something instead of synchronized{processorCache}


There's a penalty already for using an executor (unfortunately). So 
there could be a check: if using an executor, then use a processor pool 
of some sort (a dumb synced stack could do it, but I don't know if it 
would be better or worse speed wise - maybe about the same since there's 
no read at all, only modifications of the "collection"), otherwise use 
the thread local. Maybe there could be a better solution, but it's 
probably the easy one.


I didn't think about this leak issue when I thought about supporting 
executors.


Rémy

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

Re: memory leak with shrinking thread pools

[Filip Hanik - Dev Lists]

Remy Maucherat wrote:

Filip Hanik - Dev Lists wrote:
you're of course right, I think I simply need to get rid of the 
thread local cache, and use the processor cache instead.
do you have any idea of the performance penalty? I'd probably use a 
ConcurrentLinkedQueue or something instead of 
synchronized{processorCache}


There's a penalty already for using an executor (unfortunately). So 
there could be a check: if using an executor, then use a processor 
pool of some sort (a dumb synced stack could do it, but I don't know 
if it would be better or worse speed wise - maybe about the same since 
there's no read at all, only modifications of the "collection"), 
otherwise use the thread local. Maybe there could be a better 
solution, but it's probably the easy one.


I didn't think about this leak issue when I thought about supporting 
executors.
me neither, but then again, the thread local is not the real problem. 
its the requestinfo and requestgroupinfo objects, has the funky circular 
dependency, and ties it back all the way to the "handler". Had it not 
been for those, then there would have been no leak, since the objects 
would have been collected when the thread died, and the thread local 
reference disappeared.


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: r527748 - in /tomcat/site/trunk: docs/security-4.html xdocs/security-4.xml

[markt]

Author: markt
Date: Wed Apr 11 18:54:27 2007
New Revision: 527748

URL: http://svn.apache.org/viewvc?view=rev&rev=527748
Log:
A couple of issues from the security list archives.

Modified:
tomcat/site/trunk/docs/security-4.html
tomcat/site/trunk/xdocs/security-4.xml

Modified: tomcat/site/trunk/docs/security-4.html
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/docs/security-4.html?view=diff&rev=527748&r1=527747&r2=527748
==
--- tomcat/site/trunk/docs/security-4.html (original)
+++ tomcat/site/trunk/docs/security-4.html Wed Apr 11 18:54:27 2007
@@ -211,6 +211,45 @@
 
 
 
+
+Not fixed in Apache Tomcat 4.1.x
+
+
+
+
+
+
+
+
+
+moderate: Information disclosure
+   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4836";>
+   CVE-2005-4836
+
+
+The deprecated HTTP/1.1 connector does not reject request URIs 
containing
+   null bytes when used with contexts that are configured with
+   allowLinking="true". Failure to reject the null byte enables an attacker
+   to obtain the source for any JSP page in these contexts. Users of Tomcat
+   4.1.x are advised to use the default, supported Coyote HTTP/1.1 
connector
+   which does not exhibit this issue. There are no plans to issue an update
+   to Tomcat 4.1.x for this issue.
+
+Affects: 4.1.15-4.1.HEAD
+  
+
+
+
+
+
+
+
+
+
+
+
+
+
 
 Fixed in Apache Tomcat 4.1.36
 
@@ -270,6 +309,23 @@
they are in proxy servers, Tomcat should always be secured as if no 
proxy 
restricting context access was used.
 
+
+Affects: 4.0.0-4.0.6, 4.1.0-4.1.34
+
+
+low: Cross-site scripting
+   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1358";>
+   CVE-2007-1358
+
+
+Web pages that display the Accept-Language header value sent by the
+   client are susceptible to a cross-site scripting attack if they assume
+   the Accept-Language header value conforms to RFC 2616. Under normal
+   circumstances this would not be possible to exploit, however older
+   versions of Flash player were known to allow carefully crafted malicious
+   Flash files to make requests with such custom headers. Tomcat now 
ignores
+   invalid values for Accept-Language headers that do not conform to RFC
+   2616.
 
 Affects: 4.0.0-4.0.6, 4.1.0-4.1.34
   

Modified: tomcat/site/trunk/xdocs/security-4.xml
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/xdocs/security-4.xml?view=diff&rev=527748&r1=527747&r2=527748
==
--- tomcat/site/trunk/xdocs/security-4.xml (original)
+++ tomcat/site/trunk/xdocs/security-4.xml Wed Apr 11 18:54:27 2007
@@ -24,6 +24,22 @@
 
   
 
+  
+moderate: Information disclosure
+   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4836";>
+   CVE-2005-4836
+
+The deprecated HTTP/1.1 connector does not reject request URIs 
containing
+   null bytes when used with contexts that are configured with
+   allowLinking="true". Failure to reject the null byte enables an attacker
+   to obtain the source for any JSP page in these contexts. Users of Tomcat
+   4.1.x are advised to use the default, supported Coyote HTTP/1.1 
connector
+   which does not exhibit this issue. There are no plans to issue an update
+   to Tomcat 4.1.x for this issue.
+
+Affects: 4.1.15-4.1.HEAD
+  
+
   
 important: Information disclosure
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2090";>
@@ -70,6 +86,21 @@
they are in proxy servers, Tomcat should always be secured as if no 
proxy 
restricting context access was used.
 
+
+Affects: 4.0.0-4.0.6, 4.1.0-4.1.34
+
+low: Cross-site scripting
+   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1358";>
+   CVE-2007-1358
+
+Web pages that display the Accept-Language header value sent by the
+   client are susceptible to a cross-site scripting attack if they assume
+   the Accept-Language header value conforms to RFC 2616. Under normal
+   circumstances this would not be possible to exploit, however older
+   versions of Flash player were known to allow carefully crafted malicious
+   Flash files to make requests with such custom headers. Tomcat now 
ignores
+   invalid values for Accept-Language headers that do not conform to RFC
+   2616.
 
 Affects: 4.0.0-4.0.6, 4.1.0-4.1.34
   



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

Re: memory leak with shrinking thread pools

[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 = true;
 private int socketBuffer = 9000;
@@ -534,6 +537,10 @@
 setAttribute("timeout", "" + timeouts);
 }
 
+public void setProcessorCache(int processorCache) {
+this.processorCache = processorCache;
+}
+
 public void setOomParachute(int oomParachute) {
 ep.setOomParachute(oomParachute);
 setAttribute("oomParachute",oomParachute);
@@ -584,8 +591,40 @@
 new ThreadLocal();
 protected ConcurrentHashMap 
connections =
 new ConcurrentHashMap();
-protected java.util.Stack recycledProcessors = 
-new java.util.Stack();
+protected ConcurrentLinkedQueue recycledProcessors 
= new ConcurrentLinkedQueue() {
+protected AtomicInteger size = new AtomicInteger(0);
+public boolean offer(Http11NioProcessor processor) {
+boolean offer = proto.processorCache==-1?true:size.get() < 
proto.processorCache;
+//avoid over growing our cache or add after we have stopped
+boolean result = false;
+if ( offer ) {
+result = super.offer(processor);
+if ( result ) {
+size.incrementAndGet();
+}
+}
+if (!result) deregister(processor);
+return result;
+}
+
+public Http11NioProcessor poll() {
+Http11NioProcessor result = super.poll();
+if ( result != null ) {
+size.decrementAndGet();
+}
+return result;
+}
+
+public void clear() {
+Http11NioProcessor next = poll();
+while ( next != null ) {
+deregister(next);
+next = poll();
+}
+super.clear();
+size.set(0);
+}
+};
 
 Http11ConnectionHandler(Http11NioProtocol proto) {
 this.proto = proto;
@@ -626,7 +665,7 @@
 } finally {
 if (state != SocketState.LONG) {
 connections.remove(socket);
-recycledProcessors.push(result);
+if (proto.ep.getUseExecutor()) 
recycledProcessors.offer(result);
 }
 }
 }
@@ -636,14 +675,10 @@
 public SocketState process(NioChannel socket) {
 Http11NioProcessor processor = null;
 try {
-processor = (Http11NioProcessor) localProcessor.get();
+if ( !proto.ep.getUseExecutor() ) processor = 
(Http1

Tomcat 6.0.10 web.xml correction

[Rashmi Rubdi]

Hello dev-list,

I'm a newbie to this list. I'm not sure if this would be the right
place to suggest a correction to Tomcat (please correct me if I'm
wrong).

I have a fresh install of Tomcat 6.0.10 and the web.xml under
apache-tomcat-6.0.10\conf\ , still refers to Servlet 2.4


http://java.sun.com/xml/ns/j2ee";
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
   xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd";
   version="2.4">



But, according to this chart:
http://tomcat.apache.org/whichversion.html , Tomcat 6.0.10 supports
Servlet 2.5 so shouldn't the web.xml under the conf folder change
accordingly?

The 2.4 version in Tomcat 6.0.10 doesn't break anything so far.

I think web.xml should change to:


http://java.sun.com/xml/ns/javaee";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee web-app_2_5.xsd"
version="2.5">

http://marc.info/?l=tomcat-dev&w=2&r=1&s=web.xml&q=b to see if someone
made this suggestion already, but there doesn't seem to be.

-Thank you
Rashmi

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

DO NOT REPLY [Bug 42085] - java.util.Logging duplicated since 5.5.23. 5.5.20 is OK

[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=42085


[EMAIL PROTECTED] changed:

   What|Removed |Added

 AssignedTo|tomcat- |asf-
   |[EMAIL PROTECTED]  |[EMAIL PROTECTED]
 Status|NEEDINFO|NEW




--- Additional Comments From [EMAIL PROTECTED]  2007-04-11 23:19 ---
More Infos:
* The bug does not appear when all our classes are in the bootclasspath
  (as we do for testing via eclipse)
  but only when deployed as war/jar

* We use a root context and deploy it as ROOT.war
  (although this is not really documented as beeing supported this way)

* The TivoliFormatter has only a default Constructor

The first usage that was duplicated works as follows:

public class ProductContextListener implements ServletContextListener {

  private static Logger log = Logger.getLogger(ProductContextListener
.class.getName());

  ...
  public void contextInitialized(ServletContextEvent anEvent) {
...
log.info("Starting Product Version " + version);
...
  }
}

Our global logging.properties is as follows:

--%<---%<-
handlers = 1catalina.java.util.logging.FileHandler

# Handlers for the root logger
.handlers = 1catalina.java.util.logging.FileHandler

1catalina.java.util.logging.FileHandler.level = INFO
1catalina.java.util.logging.FileHandler.pattern = /var/log/ucs/catalina%g.log
# limit Output to 1MB
1catalina.java.util.logging.FileHandler.limit=1048576
# Limit rotation to 10 Logs ...
1catalina.java.util.logging.FileHandler.count=10
# 1catalina.java.util.logging.FileHandler.append=true
1catalina.java.util.logging.FileHandler.formatter=java.util.logging.SimpleFormatter
--%<---%<-

Our server XML is as follows:

--%<---%<-

  
  


  

 
 
  

  


--%<---%<-

Hmm, perhaps the Problem happens when using a 
ROOT  only ?

web.xml was copied from tomcat 5.5.20

We use the following properties (in eclipse)
to start tomcat. 

---%<-%<---
-Dcatalina.home="${TOMCAT5}"
-Dcatalina.base="${workspace_loc:de.customer.product}/ext/tomcat5" 
-Djava.endorsed.dirs="${TOMCAT5}}/common/endorsed"
-Djava.io.tmpdir="${TOMCAT5}/temp"
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-Djava.util.logging.config.file="${workspace_loc:de.customer.product}/ext/tomcat5/conf/logging.properties"
---%<-%<---

On linux we use a similar init.d script:

---%<-%<---

On linux we use a similar init.d script:

#!/bin/sh
#
# Startup script for product UserConfigurationSystem
# $Id: product,v 1.7 2007/04/10 08:53:50 kha Exp $
#  
# /etc/init.d/product
#
### BEGIN INIT INFO
# Provides:  product
# Required-Start:mysql
# Default-Start: 3 5
# Default-Stop:  0 1 2 6
# Short-Description: product - Our super duper product
# Description:   A Small tomcat based web-app as XML-RPCProvider
#   against a fat MySQL Database
### END INIT INFO
# 
# Check for missing binaries (stale symlinks should not happen)
# Note: Special treatment of stop for LSB conformance
CATALINA_HOME=/opt/app/product/apache-tomcat
CATALINA_BASE=/opt/app/product/service
CATALINA_BIN=$CATALINA_HOME/bin/catalina.sh
test -x $FOO_BIN || { echo "$CATALINA_BIN not installed"; 
if [ "$1" = "stop" ]; then exit 0;
else exit 5; fi; }

JAVA_HOME=/usr/java/jdk1.5.0_11
JRE_HOME=$JAVA_HOME/jre
CATALINA_OPTS=
USER=product
CATALINA_OPTS=-Dde.customer.product.confDir=/etc/product
CATALINA_OPTS="$CATALINA_OPTS
-Xbootclasspath/a:/opt/app/product/service/lib/product-tivoli.jar"
# CATALINA_OPTS="$CATALINA_OPTS -ea -esa -Xdebug
-Xrunjdwp:transport=dt_socket,address=9099,server=y,suspend=n"
CATALINA_TMPDIR=/var/opt/app/product/tmp

su - $USER -c "export JAVA_HOME=$JAVA_HOME;\
   export JRE_HOME=$JRE_HOME;\
   export CATALINA_OPTS='$CATALINA_OPTS';\
   export JAVA_OPTS='$JAVA_OPTS';\
   export CATALINA_HOME=$CATALINA_HOME;\
   export CATALINA_BASE=$CATALINA_BASE;\
   export CATALINA_TMPDIR=$CATALINA_TMPDIR;\
   $CATALINA_HOME/bin/catalina.sh $1"
---%<-%<---

Thats all I can give you so far, as we must 
deliver the product next week ;-)







-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=emai