if you can create a test case, great, if not, a patch would be nice with your bug submission.
I believe you meant version 5.0.28, not 4.xx.x.

Filip

James Courtney wrote:
Thanks Filip,
  I believe the threads causing the condition are the connector threads
as we have 200 or so of them configured for handling requests of which
most are for static content which apparently comes from the
ResourceCache via ProxyDirContext and Mapper.  We do not "own" these
threads as they are created and managed by the connector for handling
requests.  The exception is occuring when looking up a static piece of
content.  ProxyDirContext manages the ResourceCache and synchonizes on
it whenever it modifies it using allocate and load and also unload.  It
does not synchronize on it when it uses the lookup method which has the
problem I mentioned below.  An alternative solution would be for
ProxyDirContext to synchronized on the cache when performing the lookup
but that might introduce more overhead than the read-copy method I
suggested initially.

I will attempt to file a bug on this and suggest a test case.  We're
seeing this in our environment because we have a static content base of
30+ MB consisting of 8000-10000 static files all being accessed at
regular intervals by 8000+ clients.  This causes a lot of "churn" in the
ResourceCache I suspect and aggrivates the exception we see.  One might
be able to reproduce this by explicitly reducing the max size of the
cache on the Context and using a smaller number of files whose total
size still far exceeds the cache maximum size set.  A sufficient number
of clients would still be required to trigger the race condition.  In
short it's probably a PITA to reproduce but I'll suggest what I can.

How explicit a configuration do you guys need from me for a test case?
I'll try and reproduce it on vanilla Tomcat 4.0.28 (non-embedded) as I'd
think that'd be just as possible to do and more generally relevant.  If
I can then I'll try and do it using as simple/minimal a config as
possible but we'll see:)

Thanks again.

Jamey



-----Original Message-----
From: Filip Hanik - Dev Lists [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 01, 2006 3:21 PM
To: Tomcat Developers List
Subject: Re: ArrayIndexOutOfBoundsException in ResourceCache.java

if you are running it embedded, what threads are causing the race
condition, if it is one of your threads, you can avoid it.
otherwise, if you have a test case for us, submit it to bugzilla, and we
will be happy to consider it for the next 5.0.x release

Filip

James Courtney wrote:
I'm pretty regularly seeing the following error in my embedded Tomcat
(5.0.28) connector. It appears to occur as a result of one thread entering the ResourceCache.lookup(String name) method and getting the index of an element in the cache using the find method. Before this thread can access the element at that index the cache array is modified by a second thread and the index is now outside the bounds of
the array.
A basic race condition.  I've noticed that I can configure my Context
(StandardContext) to increase the max cache size which seems to help quite a bit with this problem. Is this the recommended solution or should a code change also be considered to alleviate this problem? I would suggest that the ResourceCache.lookup method should create a reference to the current cache which it should use rather than working

on the global cache reference which may change.  Something like this:

/* current code, ResourceCache.java line 286 */ CacheEntry cacheEntry = null; ...
int pos = find(cache, name);
/* ArrayIndexOutOfBoundsException occurs when backing array modified between these lines */ if ((pos != -1) && (name.equals(cache[pos].name))) {
    cacheEntry = cache[pos];
}

/* new code */
CacheEntry cacheEntry = null;
CacheEntry[] currentCache = cache;
...
int pos = find(currentCache, name);
if ((pos != -1) && (name.equals(currentCache[pos].name))) {
    cacheEntry = currentCache[pos];
}

Thanks in advance for your help!

James Courtney



******************************
** The original stack trace **
******************************

2005-11-28 15:09:01: ERROR An exception or error occurred in the container during the request processing
java.lang.ArrayIndexOutOfBoundsException: 4868
        at

org.apache.naming.resources.ResourceCache.lookup(ResourceCache.java:288)
        at

org.apache.naming.resources.ProxyDirContext.cacheLookup(ProxyDirContext.
java:1393)
        at

org.apache.naming.resources.ProxyDirContext.lookup(ProxyDirContext.java:
279)
        at
org.apache.tomcat.util.http.mapper.Mapper.internalMapWrapper(Mapper.ja
va
:775)
        at
org.apache.tomcat.util.http.mapper.Mapper.internalMap(Mapper.java:621)
        at
org.apache.tomcat.util.http.mapper.Mapper.map(Mapper.java:511)
        at
org.apache.coyote.tomcat5.CoyoteAdapter.postParseRequest(CoyoteAdapter
.j
ava:279)
        at

org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:158)
        at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:
79
9)
        at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.proces
sC
onnection(Http11Protocol.java:705)
        at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:
57
7)
        at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPo
ol
.java:683)
        at java.lang.Thread.run(Thread.java:534)

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


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

Reply via email to