svn commit: r1103633 - /tomcat/trunk/java/org/apache/tomcat/util/net/NioBlockingSelector.java

2011-05-16 Thread markt 
Author: markt
Date: Mon May 16 07:31:23 2011
New Revision: 1103633

URL: http://svn.apache.org/viewvc?rev=1103633&view=rev
Log:
Prevent infinite loop when readTimeout = 0

Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/NioBlockingSelector.java

Modified: tomcat/trunk/java/org/apache/tomcat/util/net/NioBlockingSelector.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/NioBlockingSelector.java?rev=1103633&r1=1103632&r2=1103633&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/NioBlockingSelector.java 
(original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/NioBlockingSelector.java Mon 
May 16 07:31:23 2011
@@ -178,7 +178,7 @@ public class NioBlockingSelector {
 keycount = 1;
 att.resetReadLatch();
 }
-if (readTimeout > 0 && (keycount == 0))
+if (readTimeout >= 0 && (keycount == 0))
 timedout = (System.currentTimeMillis() - time) >= 
readTimeout;
 } //while
 if (timedout)



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

svn commit: r1103634 - /tomcat/trunk/java/org/apache/coyote/ajp/AjpNioProcessor.java

2011-05-16 Thread markt 
Author: markt
Date: Mon May 16 07:33:35 2011
New Revision: 1103634

URL: http://svn.apache.org/viewvc?rev=1103634&view=rev
Log:
Remove unused code

Modified:
tomcat/trunk/java/org/apache/coyote/ajp/AjpNioProcessor.java

Modified: tomcat/trunk/java/org/apache/coyote/ajp/AjpNioProcessor.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/ajp/AjpNioProcessor.java?rev=1103634&r1=1103633&r2=1103634&view=diff
==
--- tomcat/trunk/java/org/apache/coyote/ajp/AjpNioProcessor.java (original)
+++ tomcat/trunk/java/org/apache/coyote/ajp/AjpNioProcessor.java Mon May 16 
07:33:35 2011
@@ -116,13 +116,6 @@ public class AjpNioProcessor extends Abs
 
 
 /**
- * NIO socket read may return more than just the current message. Need to
- * buffer the response to ensure data isn't lost.
- */
-protected byte[] inputBuffer;
-protected int inputBufferEnd;
-
-/**
  * Direct buffer used for sending right away a get body message.
  */
 protected final byte[] getBodyMessageArray;



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

DO NOT REPLY [Bug 50839] Closing connection on the client side (browser) during unfinished transmission result in 100% CPU slike for 30 sec during socket shutdownd in jk_connect.c

2011-05-16 Thread bugzilla 
https://issues.apache.org/bugzilla/show_bug.cgi?id=50839

--- Comment #6 from Tim Whittington  2011-05-16 08:25:44 UTC 
---
The trace log from Konstantin shows that the ISAPI Redirector is spending all
it's time in jk_shutdown_socket, calling jk_is_input_event - basically draining
all the AJP response packets (which will all be SEND_BODY_CHUNK packets).

The Java side of the AJP connector also blindly continues writing out an entire
chunk (across multiple SEND_BODY_CHUNK packets), and possibly across multiple
writes (I can't quite get my head around how an AJP response stream would be
terminated on a client abort on the HTTP side).

I think this behaviour was introduced when the socket shutdown was tidied up to
politely drain lingering bytes on the AJP connection before closing the socket
- in extreme cases this seems to allow the Java side to continue writing data.

I'm thinking at this point the simplest fix is to cap the amount of lingering
bytes the AJP reset will handle on the Tomcat Connector end, and simply close
the AJP connection if that is exceeded.

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

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

DO NOT REPLY [Bug 50839] Closing connection on the client side (browser) during unfinished transmission result in 100% CPU slike for 30 sec during socket shutdownd in jk_connect.c

2011-05-16 Thread bugzilla 
https://issues.apache.org/bugzilla/show_bug.cgi?id=50839

--- Comment #7 from Rainer Jung  2011-05-16 08:48:21 
UTC ---
+1 to such a solution. Limit by number of bytes plus the time we do the
lingering. Break after say 32KB read or 2 seconds linger. Waiting longer or
reading more is just wasting precious resources.

Rainer

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

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

DO NOT REPLY [Bug 51088] ArrayIndexOutOfBoundsException from org.apache.el.parser.JJTELParserState

2011-05-16 Thread bugzilla 
https://issues.apache.org/bugzilla/show_bug.cgi?id=51088

--- Comment #4 from Michael Heinen  2011-05-16 09:32:16 
UTC ---
a) can be excluded (no rarely executed if-branch)
c) could be possible indeed (although an OOM did not occur, but maybe another
RuntimeException)

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

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1103633 - /tomcat/trunk/java/org/apache/tomcat/util/net/NioBlockingSelector.java

2011-05-16 Thread Filip Hanik - Dev Lists 

-1 for this change. 0 means infinite (no timeout)

http://download.oracle.com/javase/6/docs/api/java/net/Socket.html#setSoTimeout%28int%29

Filip

On 5/16/2011 1:31 AM, ma...@apache.org wrote:

Author: markt
Date: Mon May 16 07:31:23 2011
New Revision: 1103633

URL: http://svn.apache.org/viewvc?rev=1103633&view=rev
Log:
Prevent infinite loop when readTimeout = 0

Modified:
 tomcat/trunk/java/org/apache/tomcat/util/net/NioBlockingSelector.java

Modified: tomcat/trunk/java/org/apache/tomcat/util/net/NioBlockingSelector.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/NioBlockingSelector.java?rev=1103633&r1=1103632&r2=1103633&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/NioBlockingSelector.java 
(original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/NioBlockingSelector.java Mon 
May 16 07:31:23 2011
@@ -178,7 +178,7 @@ public class NioBlockingSelector {
  keycount = 1;
  att.resetReadLatch();
  }
-if (readTimeout>  0&&  (keycount == 0))
+if (readTimeout>= 0&&  (keycount == 0))
  timedout = (System.currentTimeMillis() - time)>= 
readTimeout;
  } //while
  if (timedout)



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1321 / Virus Database: 1500/3640 - Release Date: 05/15/11





-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

svn commit: r1103788 - /tomcat/trunk/java/org/apache/tomcat/util/net/NioSelectorPool.java

2011-05-16 Thread markt 
Author: markt
Date: Mon May 16 16:39:42 2011
New Revision: 1103788

URL: http://svn.apache.org/viewvc?rev=1103788&view=rev
Log:
SHARED_SELECTOR is used with double checked locking so it needs to be volatile

Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/NioSelectorPool.java

Modified: tomcat/trunk/java/org/apache/tomcat/util/net/NioSelectorPool.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/NioSelectorPool.java?rev=1103788&r1=1103787&r2=1103788&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/NioSelectorPool.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/NioSelectorPool.java Mon May 
16 16:39:42 2011
@@ -50,7 +50,7 @@ public class NioSelectorPool {
 
 protected NioBlockingSelector blockingSelector;
 
-protected Selector SHARED_SELECTOR;
+protected volatile Selector SHARED_SELECTOR;
 
 protected int maxSelectors = 200;
 protected long sharedSelectorTimeout = 3;



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

DO NOT REPLY [Bug 51206] New: CATALINA_BASE is not visible to setenv.sh

2011-05-16 Thread bugzilla 
https://issues.apache.org/bugzilla/show_bug.cgi?id=51206

 Bug #: 51206
   Summary: CATALINA_BASE is not visible to setenv.sh
   Product: Tomcat 6
   Version: 6.0.32
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: dev@tomcat.apache.org
ReportedBy: fha...@apache.org
Classification: Unclassified


If this variable is not visible, it makes the setenv.sh script sort of useless

Index: bin/catalina.sh
===
--- bin/catalina.sh(revision 1103812)
+++ bin/catalina.sh(working copy)
@@ -116,6 +116,9 @@
 # Ensure that any user defined CLASSPATH variables are not used on startup,
 # but allow them to be specified in setenv.sh, in rare case when it is needed.
 CLASSPATH=
+if [ -z "$CATALINA_BASE" ] ; then
+  CATALINA_BASE="$CATALINA_HOME"
+fi

 if [ -r "$CATALINA_BASE"/bin/setenv.sh ]; then
   . "$CATALINA_BASE"/bin/setenv.sh
@@ -163,10 +166,8 @@
   fi
 fi

-if [ -z "$CATALINA_BASE" ] ; then
-  CATALINA_BASE="$CATALINA_HOME"
-fi

+
 # Add tomcat-juli.jar and bootstrap.jar to classpath
 # tomcat-juli.jar can be over-ridden per instance
 if [ ! -z "$CLASSPATH" ] ; then

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

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

DO NOT REPLY [Bug 51206] CATALINA_BASE is not visible to setenv.sh

2011-05-16 Thread bugzilla 
https://issues.apache.org/bugzilla/show_bug.cgi?id=51206

--- Comment #1 from Filip Hanik  2011-05-16 18:13:27 UTC ---
The fix will have to be modified a little bit to avoid calling
CATALINA_HOME/bin/setenv.sh twice

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

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

svn commit: r1103860 - in /tomcat/trunk/java/org/apache/coyote/ajp: AjpNioProcessor.java AjpNioProtocol.java

2011-05-16 Thread markt 
Author: markt
Date: Mon May 16 19:56:21 2011
New Revision: 1103860

URL: http://svn.apache.org/viewvc?rev=1103860&view=rev
Log:
Tweak processor blocking so that it is non-blocking while no message is being 
processed and blocking during the processing of a message
Align ajp nio protocol implementation with http nio
Still some TCK failures to resolve

Modified:
tomcat/trunk/java/org/apache/coyote/ajp/AjpNioProcessor.java
tomcat/trunk/java/org/apache/coyote/ajp/AjpNioProtocol.java

Modified: tomcat/trunk/java/org/apache/coyote/ajp/AjpNioProcessor.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/ajp/AjpNioProcessor.java?rev=1103860&r1=1103859&r2=1103860&view=diff
==
--- tomcat/trunk/java/org/apache/coyote/ajp/AjpNioProcessor.java (original)
+++ tomcat/trunk/java/org/apache/coyote/ajp/AjpNioProcessor.java Mon May 16 
19:56:21 2011
@@ -196,29 +196,20 @@ public class AjpNioProcessor extends Abs
 // Setting up the socket
 this.socket = socket;
 
-int soTimeout = -1;
-final KeyAttachment ka = (KeyAttachment)socket.getAttachment(false);
-if (keepAliveTimeout > 0) {
-ka.setTimeout(soTimeout);
-}
+long soTimeout = endpoint.getSoTimeout();
+int keepAliveTimeout = endpoint.getKeepAliveTimeout();
 
 // Error flag
 error = false;
 
-boolean keptAlive = false;
-
+final KeyAttachment ka = (KeyAttachment)socket.getAttachment(false);
+
 while (!error && !endpoint.isPaused()) {
-
 // Parsing the request header
 try {
-// Set keep alive timeout if enabled
-if (keepAliveTimeout > 0) {
-ka.setTimeout(keepAliveTimeout);
-}
 // Get first message of the request
-int bytesRead = readMessage(requestHeaderMessage, !keptAlive);
-if (!keptAlive && bytesRead == 0) {
-// No bytes on a blocking read - connection timeout
+int bytesRead = readMessage(requestHeaderMessage, false);
+if (bytesRead == 0) {
 rp.setStage(org.apache.coyote.Constants.STAGE_ENDED);
 break;
 }
@@ -235,8 +226,6 @@ public class AjpNioProcessor extends Abs
 } catch (IOException e) {
 error = true;
 }
-// Should be unnecessary but just in case...
-keptAlive = true;
 recycle();
 continue;
 } else if(type != Constants.JK_AJP13_FORWARD_REQUEST) {
@@ -244,12 +233,9 @@ public class AjpNioProcessor extends Abs
 if(log.isDebugEnabled()) {
 log.debug("Unexpected message: "+type);
 }
-// Should be unnecessary but just in case...
-keptAlive = true;
 recycle();
 continue;
 }
-
 request.setStartTime(System.currentTimeMillis());
 } catch (IOException e) {
 error = true;
@@ -324,7 +310,11 @@ public class AjpNioProcessor extends Abs
 request.updateCounters();
 
 rp.setStage(org.apache.coyote.Constants.STAGE_KEEPALIVE);
-keptAlive = true;
+// Set keep alive timeout if enabled
+if (keepAliveTimeout > 0) {
+ka.setTimeout(keepAliveTimeout);
+}
+
 recycle();
 }
 
@@ -479,18 +469,23 @@ public class AjpNioProcessor extends Abs
 /**
  * Read the specified amount of bytes, and place them in the input buffer.
  */
-protected int read(byte[] buf, int pos, int n, boolean block)
+protected int read(byte[] buf, int pos, int n, boolean blockFirstRead)
 throws IOException {
 
 int read = 0;
 int res = 0;
+boolean block = blockFirstRead;
+
 while (read < n) {
 res = readSocket(buf, read + pos, n, block);
 if (res > 0) {
 read += res;
+} else if (res == 0 && !block) {
+break;
 } else {
 throw new IOException(sm.getString("ajpprotocol.failedread"));
 }
+block = true;
 }
 return read;
 }
@@ -596,14 +591,18 @@ public class AjpNioProcessor extends Abs
  * @return The number of bytes read
  * @throws IOException any other failure, including incomplete reads
  */
-protected int readMessage(AjpMessage message, boolean block)
+protected int readMessage(AjpMessage message, boolean blockFirstRead)
 throws IOException {
 
 byte[] buf = message.getBuffer();
 int headerLength = message.getHeaderLength();
 
-in

svn commit: r1103908 - /tomcat/trunk/java/org/apache/catalina/security/SecurityClassLoad.java

2011-05-16 Thread markt 
Author: markt
Date: Mon May 16 21:30:52 2011
New Revision: 1103908

URL: http://svn.apache.org/viewvc?rev=1103908&view=rev
Log:
Fix Security Exceptions when running Servlet TCK with experimental nio-apr 
connector

Modified:
tomcat/trunk/java/org/apache/catalina/security/SecurityClassLoad.java

Modified: tomcat/trunk/java/org/apache/catalina/security/SecurityClassLoad.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/security/SecurityClassLoad.java?rev=1103908&r1=1103907&r2=1103908&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/security/SecurityClassLoad.java 
(original)
+++ tomcat/trunk/java/org/apache/catalina/security/SecurityClassLoad.java Mon 
May 16 21:30:52 2011
@@ -248,6 +248,12 @@ public final class SecurityClassLoad {
 clazz.newInstance();
 loader.loadClass(basePackage + "util.http.HttpMessages");
 loader.loadClass(basePackage + "util.net.Constants");
+loader.loadClass(basePackage +
+"util.net.NioBlockingSelector$BlockPoller$1");
+loader.loadClass(basePackage +
+"util.net.NioBlockingSelector$BlockPoller$2");
+loader.loadClass(basePackage +
+"util.net.NioBlockingSelector$BlockPoller$3");
 loader.loadClass(basePackage + "util.net.SSLSupport$CipherData");
 loader.loadClass
 (basePackage + "util.net.JIoEndpoint$PrivilegedSetTccl");



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1103633 - /tomcat/trunk/java/org/apache/tomcat/util/net/NioBlockingSelector.java

2011-05-16 Thread Mark Thomas 
On 16/05/2011 16:24, Filip Hanik - Dev Lists wrote:
> -1 for this change. 0 means infinite (no timeout)
> 
> http://download.oracle.com/javase/6/docs/api/java/net/Socket.html#setSoTimeout%28int%29

The problem is that readTimeout is also used in line 169:
att.awaitReadLatch(readTimeout,TimeUnit.MILLISECONDS);

and in that case the timeout is not infinite, it is immediate (Rainer
checked the JRE source) which triggers a tight CPU burning loop.

Any suggestions for a better solution? How about changing a value of 0
to -1 at the start of the method?

Mark

> 
> Filip
> 
> On 5/16/2011 1:31 AM, ma...@apache.org wrote:
>> Author: markt
>> Date: Mon May 16 07:31:23 2011
>> New Revision: 1103633
>>
>> URL: http://svn.apache.org/viewvc?rev=1103633&view=rev
>> Log:
>> Prevent infinite loop when readTimeout = 0
>>
>> Modified:
>> 
>> tomcat/trunk/java/org/apache/tomcat/util/net/NioBlockingSelector.java
>>
>> Modified:
>> tomcat/trunk/java/org/apache/tomcat/util/net/NioBlockingSelector.java
>> URL:
>> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/NioBlockingSelector.java?rev=1103633&r1=1103632&r2=1103633&view=diff
>>
>> ==
>>
>> ---
>> tomcat/trunk/java/org/apache/tomcat/util/net/NioBlockingSelector.java
>> (original)
>> +++
>> tomcat/trunk/java/org/apache/tomcat/util/net/NioBlockingSelector.java
>> Mon May 16 07:31:23 2011
>> @@ -178,7 +178,7 @@ public class NioBlockingSelector {
>>   keycount = 1;
>>   att.resetReadLatch();
>>   }
>> -if (readTimeout>  0&&  (keycount == 0))
>> +if (readTimeout>= 0&&  (keycount == 0))
>>   timedout = (System.currentTimeMillis() - time)>=
>> readTimeout;
>>   } //while
>>   if (timedout)
>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>>
>>
>> -
>> No virus found in this message.
>> Checked by AVG - www.avg.com
>> Version: 10.0.1321 / Virus Database: 1500/3640 - Release Date: 05/15/11
>>
>>
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
> 




-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1103633 - /tomcat/trunk/java/org/apache/tomcat/util/net/NioBlockingSelector.java

2011-05-16 Thread Filip Hanik - Dev Lists 

I take back my -1
looking at the javadoc, it defines -1 as infinite.

So your commit is correct, but requires an addition

-att.awaitReadLatch(readTimeout,TimeUnit.MILLISECONDS);

+if (readTimeout<0) {
+  att.awaitReadLatch(Long.MAX_VALUE,TimeUnit.MILLISECONDS);
+} else {
+  att.awaitReadLatch(readTimeout,TimeUnit.MILLISECONDS);
+}


Filip



On 5/16/2011 3:38 PM, Mark Thomas wrote:

On 16/05/2011 16:24, Filip Hanik - Dev Lists wrote:

-1 for this change. 0 means infinite (no timeout)

http://download.oracle.com/javase/6/docs/api/java/net/Socket.html#setSoTimeout%28int%29

The problem is that readTimeout is also used in line 169:
att.awaitReadLatch(readTimeout,TimeUnit.MILLISECONDS);

and in that case the timeout is not infinite, it is immediate (Rainer
checked the JRE source) which triggers a tight CPU burning loop.

Any suggestions for a better solution? How about changing a value of 0
to -1 at the start of the method?

Mark


Filip

On 5/16/2011 1:31 AM, ma...@apache.org wrote:

Author: markt
Date: Mon May 16 07:31:23 2011
New Revision: 1103633

URL: http://svn.apache.org/viewvc?rev=1103633&view=rev
Log:
Prevent infinite loop when readTimeout = 0

Modified:

tomcat/trunk/java/org/apache/tomcat/util/net/NioBlockingSelector.java

Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/NioBlockingSelector.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/NioBlockingSelector.java?rev=1103633&r1=1103632&r2=1103633&view=diff

==

---
tomcat/trunk/java/org/apache/tomcat/util/net/NioBlockingSelector.java
(original)
+++
tomcat/trunk/java/org/apache/tomcat/util/net/NioBlockingSelector.java
Mon May 16 07:31:23 2011
@@ -178,7 +178,7 @@ public class NioBlockingSelector {
   keycount = 1;
   att.resetReadLatch();
   }
-if (readTimeout>   0&&   (keycount == 0))
+if (readTimeout>= 0&&   (keycount == 0))
   timedout = (System.currentTimeMillis() - time)>=
readTimeout;
   } //while
   if (timedout)



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1321 / Virus Database: 1500/3640 - Release Date: 05/15/11




-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1321 / Virus Database: 1500/3641 - Release Date: 05/16/11





-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

DO NOT REPLY [Bug 51195] "Find leaks" reports a false positive memory/classloader leak

2011-05-16 Thread bugzilla 
https://issues.apache.org/bugzilla/show_bug.cgi?id=51195

--- Comment #1 from Christopher Schultz  
2011-05-16 21:54:00 UTC ---
The patch as written seems a bit over-reaching, possibly non-threadsafe and
might even be JVM-specific.

It's over-reaching in that it purges the ObjectStreamClass's cache
unconditionally which may result in a slight performance degradation for other
threads as they re-populate the cache. I suspect performance is somewhat less
of a concern for the thread taking the webapp out of service, so I think
there's a reasonable amount of room to only clear those classes from the cache
that came from the doomed webapp's ClassLoader.

>From a thread-safety point of view, I'm not sure it's safe at all to clear this
cache without doing a lot of checking of the type and/or method signatures,
etc. This is also tied to the fact that this is a private class that may or may
not exist outside of Sun/Oracle's implementation, or even in different versions
of the JVM... if it's implementation-specific, we need a reliable way to test
for the safety of this technique.

Obviously reflection can be used to see if the class and it's fields actually
exist, but I'm skeptical about ensuring the thread-safety of the
implementation.

Is it not enough to call System.gc(), here?

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

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1103633 - /tomcat/trunk/java/org/apache/tomcat/util/net/NioBlockingSelector.java

2011-05-16 Thread Mark Thomas 
On 16/05/2011 22:47, Filip Hanik - Dev Lists wrote:
> I take back my -1
> looking at the javadoc, it defines -1 as infinite.
> 
> So your commit is correct, but requires an addition
> 
> -att.awaitReadLatch(readTimeout,TimeUnit.MILLISECONDS);
> 
> +if (readTimeout<0) {
> +  att.awaitReadLatch(Long.MAX_VALUE,TimeUnit.MILLISECONDS);
> +} else {
> +  att.awaitReadLatch(readTimeout,TimeUnit.MILLISECONDS);
> +}

Thanks - I'll get that committed shortly.

Mark



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

svn commit: r1103923 - /tomcat/trunk/java/org/apache/tomcat/util/net/NioBlockingSelector.java

2011-05-16 Thread markt 
Author: markt
Date: Mon May 16 22:02:04 2011
New Revision: 1103923

URL: http://svn.apache.org/viewvc?rev=1103923&view=rev
Log:
Add Filip's additional patch to correctly handle infinite read timeouts

Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/NioBlockingSelector.java

Modified: tomcat/trunk/java/org/apache/tomcat/util/net/NioBlockingSelector.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/NioBlockingSelector.java?rev=1103923&r1=1103922&r2=1103923&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/NioBlockingSelector.java 
(original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/NioBlockingSelector.java Mon 
May 16 22:02:04 2011
@@ -166,7 +166,11 @@ public class NioBlockingSelector {
 try {
 if ( att.getReadLatch()==null || 
att.getReadLatch().getCount()==0) att.startReadLatch(1);
 poller.add(att,SelectionKey.OP_READ, reference);
-att.awaitReadLatch(readTimeout,TimeUnit.MILLISECONDS);
+if (readTimeout < 0) {
+att.awaitReadLatch(Long.MAX_VALUE, 
TimeUnit.MILLISECONDS);
+} else {
+att.awaitReadLatch(readTimeout, TimeUnit.MILLISECONDS);
+}
 }catch (InterruptedException ignore) {
 Thread.interrupted();
 }



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1103633 - /tomcat/trunk/java/org/apache/tomcat/util/net/NioBlockingSelector.java

2011-05-16 Thread Mark Thomas 
On 16/05/2011 22:54, Mark Thomas wrote:
> On 16/05/2011 22:47, Filip Hanik - Dev Lists wrote:
>> I take back my -1
>> looking at the javadoc, it defines -1 as infinite.
>>
>> So your commit is correct, but requires an addition
>>
>> -att.awaitReadLatch(readTimeout,TimeUnit.MILLISECONDS);
>>
>> +if (readTimeout<0) {
>> +  att.awaitReadLatch(Long.MAX_VALUE,TimeUnit.MILLISECONDS);
>> +} else {
>> +  att.awaitReadLatch(readTimeout,TimeUnit.MILLISECONDS);
>> +}
> 
> Thanks - I'll get that committed shortly.

Woot. That seems to have fixed a bunch of additional issues I was
seeing. Thanks again.

I'll test this more thoroughly tomorrow.

Mark



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

DO NOT REPLY [Bug 51195] "Find leaks" reports a false positive memory/classloader leak

2011-05-16 Thread bugzilla 
https://issues.apache.org/bugzilla/show_bug.cgi?id=51195

--- Comment #2 from Joern Huxhorn  2011-05-17 00:17:23 
UTC ---
Calling System.gc() is not enough at all since the caches in question contain
SoftReferences that are not collected until the VM is running out of memory.
This is the root of this whole issue. The references are not released, thus
causing the leak-warning.

System.gc() is already executed during/before "Find leaks" if I'm not entirely
mistaken.

The performance degradation is absolutely irrelevant since I'd like to see this
code executed on click of the "Find leaks" button and not in case of every
undeploy.
This isn't something you'd do in a production environment.
Clicking that button will result in a certain amount of performance degradation
caused by the System.gc(), anyway.

The patch itself would only be non-threadsafe if
a) the private class java.io.ObjectStreamClass$Caches exists and
b) the implementation contains both fields and
c) the fields in question are not instances of ConcurrentMap but only Map

c) is not taken care of at the moment but this could easily be circumvented by
changing the if condition to if(value instanceof ConcurrentMap) or even
if(value instanceof ConcurrentHashMap).

Calling clear() on a ConcurrentHashMap is safe according to the documentation.
It won't interfere with any retrieval or update operations.
It's just not guaranteed, that the map is really empty with 100% certainty.

The code does nothing at all if a) or b) are not fulfilled.

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

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org