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/tom
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:
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 respo
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 pr
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:
-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?re
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:
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: norm
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
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 implementat
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
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.MIL
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(rea
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
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.
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: tom
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
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 th
18 matches
Mail list logo