DO NOT REPLY [Bug 34805] - warn about invalid security contraint url patterns

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |




--- Additional Comments From [EMAIL PROTECTED]  2006-08-01 08:41 ---
I think there might be a bug in this implementation which is reporting
legitimate url-mappings as questionable.

If I understand the original intent of this patch, should not the line that
currently appears as:

if (pattern.charAt(pattern.length()-1) != '/') {

should be:

if (pattern.charAt(pattern.length()-2) != '/') {


What do you think?

-- 
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 40150] New: - Incorrect User/Role classnames are silently 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=40150

   Summary: Incorrect User/Role classnames are silently ignored.
   Product: Tomcat 5
   Version: 5.5.17
  Platform: All
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


org.apache.catalina.realm.JAASRealm does not verify any of the class names that
are set through setRoleClassNames() and setUserClassNames().

If an incorrect class name (e.g. a typo) is configured in context.xml, this is
unnoticed by JAASRealm. The result is that during authentication, when the
subject's principals are checked against the configured class names, the
principals are not recognised, and therefore not added to the subject.

The fact an incorrect configured class name is currently not detected and logged
makes it very hard to find the source of the problem. It can be easily fixed by
checking the class names in the two methods mentioned above. The class must
exist, and it must implement java.security.Principal, which is currently not
enforced/checked by the code.

-- 
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 40150] - Incorrect User/Role classnames are silently 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=40150





--- Additional Comments From [EMAIL PROTECTED]  2006-08-01 09:00 ---
Created an attachment (id=18668)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=18668&action=view)
Proposed fixed version of JAASRealm.

This version of JAASRealm validates the class names for setUserClassNames and
setRoleClassNames. It verifies if the class exists, and if it implements
java.security.Principal. If not, it logs a message (severe), that allows users
to detect the incorrect class name.

It might even be better if it threw an exception.

I've also restructured the code to parse the comma-delimited class name string,
as it was rather inefficient. It uses a StringTokenizer now.

-- 
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 40151] New: - mod_jk with Apache doesn't handle jsessionid encoded directory URLs

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

   Summary: mod_jk with Apache doesn't handle jsessionid encoded
directory URLs
   Product: Tomcat 5
   Version: Unknown
  Platform: All
OS/Version: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Native:JK
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


URLs of the form http://www.example.com/dir/;jsessionid=328s1t1289qrt (where
you'd expect the welcome file to be served up) don't work with mod_jk and Apache
2.2.3. Apache returns a 404 and adds the following to the error log: 
File does not exist: /wwwroot/dir/;jsessionid=328s1t1289qrt

Without the jsessionid part (http://www.example.com/dir/) works fine.

I've tried this against mod_jk from Tomcat connectors 1.2.18.

-- 
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 40150] - Incorrect User/Role classnames are silently 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=40150





--- Additional Comments From [EMAIL PROTECTED]  2006-08-01 11:28 ---
Created an attachment (id=18669)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=18669&action=view)
Improved version of the patch

No longer using StringTokenizer, but String.split, as StringTokenizer is
considered legacy. Thanks to Sameer Acharya.

-- 
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: r427546 - /tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/StandardContext.java

[remm]

Author: remm
Date: Tue Aug  1 04:57:41 2006
New Revision: 427546

URL: http://svn.apache.org/viewvc?rev=427546&view=rev
Log:
- Stop wrappers a bit earlier.

Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/StandardContext.java

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/StandardContext.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/StandardContext.java?rev=427546&r1=427545&r2=427546&view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/StandardContext.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/StandardContext.java Tue 
Aug  1 04:57:41 2006
@@ -4445,6 +4445,13 @@
 // Stop our filters
 filterStop();
 
+// Stop our child containers, if any
+Container[] children = findChildren();
+for (int i = 0; i < children.length; i++) {
+if (children[i] instanceof Lifecycle)
+((Lifecycle) children[i]).stop();
+}
+
 // Stop our application listeners
 listenerStop();
 
@@ -4468,13 +4475,6 @@
 // Stop the Valves in our pipeline (including the basic), if any
 if (pipeline instanceof Lifecycle) {
 ((Lifecycle) pipeline).stop();
-}
-
-// Stop our child containers, if any
-Container[] children = findChildren();
-for (int i = 0; i < children.length; i++) {
-if (children[i] instanceof Lifecycle)
-((Lifecycle) children[i]).stop();
 }
 
 // Clear all application-originated servlet context attributes



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

DO NOT REPLY [Bug 40153] New: - pooop

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

   Summary: pooop
   Product: Tomcat 3
   Version: Unknown
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Connectors
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [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 40153] - pooop

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2006-08-01 14:12 ---
Please do not take advantage of our openess.
Unless you explain what you meant with this, you will be
expelled from all the ASF mailing list.

-- 
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 40155] New: - Context setup for JSPs in 5.5.17

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

   Summary: Context setup for JSPs in 5.5.17
   Product: Tomcat 5
   Version: 5.5.17
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Servlet & JSP API
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


This is a duplicate of Bug 39817 and 40130.  I am resubmitting because I did 
not get an answer to my question.

What is the proper Tomcat configuration for my application in 5.5.17?  I have 
reviewed the online docs and I cannot hit my login page, nor does my 
application run my listeners on startup.  What am I doing wrong, in comparison 
to 5.5.12?

My setup is as follows:

server.xml


context.xml (under D:\webapps\Concept\ROOT folder)


Code structure

d:\webapps\Concept\catalog (contains jsps)
d:\webapps\Concept\core (contains jsps)
d:\webapps\Concept\WEB-INF (contains compiled classes/libs)

/core/*.jsp are included properly
/catalog/*.jsp are NOT included properly

What is the difference between those 2 folders?

Tomcat Manager shows a "context" for each JSP folder (catalog, core, etc), in 
addition to /, and other contexts I have created in Catalina/concept folder.  
Why is this different from previous versions?

-- 
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 40155] - Context setup for JSPs in 5.5.17

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE




--- Additional Comments From [EMAIL PROTECTED]  2006-08-01 19:27 ---


*** This bug has been marked as a duplicate of 39817 ***

-- 
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 39817] - Include File Failure for Parent|Top Relative References

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





--- Additional Comments From [EMAIL PROTECTED]  2006-08-01 19:27 ---
*** Bug 40155 has been marked as a duplicate of this bug. ***

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

ArrayIndexOutOfBoundsException in ResourceCache.java

[James Courtney]

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.java
: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.processC
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(ThreadPool
.java:683)
at java.lang.Thread.run(Thread.java:534)

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

Re: ArrayIndexOutOfBoundsException in ResourceCache.java

[Filip Hanik - Dev Lists]

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.java
: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.processC
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(ThreadPool
.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]

DO NOT REPLY [Bug 40155] - Context setup for JSPs in 5.5.17

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





--- Additional Comments From [EMAIL PROTECTED]  2006-08-01 23:20 ---
With , it should be painfully obvious that Tomcat will attempt to
deploy whatever folders are in your "D:\webapps\Concept" folder as webapps.

-- 
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: ArrayIndexOutOfBoundsException in ResourceCache.java

[James Courtney]

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-1 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.Http11Proces

Re: ArrayIndexOutOfBoundsException in ResourceCache.java

[Filip Hanik - Dev Lists]

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-1 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.apa

Re: ArrayIndexOutOfBoundsException in ResourceCache.java

[Remy Maucherat]

James Courtney wrote:

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


I think I should have coded it that way.

Rémy

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

RE: ArrayIndexOutOfBoundsException in ResourceCache.java

[James Courtney]

Yep, 5.0.28, sorry:)

Jamey
 

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

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-1 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:28
> 8)
>   
>> at
>>
>> 
>
org.apache.naming.resources

RE: ArrayIndexOutOfBoundsException in ResourceCache.java

[James Courtney]

You coded the modification methods that way but the read method (lookup) is not.

I'll take a few minutes to try and create a test case but my other work will 
prevent me spending too much time on it.  I'll certainly submit a patch with 
the bug.

Thanks to all!

Jamey

 

-Original Message-
From: Remy Maucherat [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, August 01, 2006 5:16 PM
To: Tomcat Developers List
Subject: Re: ArrayIndexOutOfBoundsException in ResourceCache.java

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

I think I should have coded it that way.

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: r427821 - /tomcat/tc6.0.x/trunk/java/org/apache/naming/resources/ResourceCache.java

[remm]

Author: remm
Date: Tue Aug  1 17:39:28 2006
New Revision: 427821

URL: http://svn.apache.org/viewvc?rev=427821&view=rev
Log:
- Use a single reference to the cache during lookup (the cache array could be 
concurrently replaced).

Modified:
tomcat/tc6.0.x/trunk/java/org/apache/naming/resources/ResourceCache.java

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/naming/resources/ResourceCache.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/naming/resources/ResourceCache.java?rev=427821&r1=427820&r2=427821&view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/naming/resources/ResourceCache.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/naming/resources/ResourceCache.java 
Tue Aug  1 17:39:28 2006
@@ -289,10 +289,11 @@
 public CacheEntry lookup(String name) {
 
 CacheEntry cacheEntry = null;
+CacheEntry[] currentCache = cache;
 accessCount++;
-int pos = find(cache, name);
-if ((pos != -1) && (name.equals(cache[pos].name))) {
-cacheEntry = cache[pos];
+int pos = find(currentCache, name);
+if ((pos != -1) && (name.equals(currentCache[pos].name))) {
+cacheEntry = currentCache[pos];
 }
 if (cacheEntry == null) {
 try {



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

svn commit: r427861 - in /tomcat/container/branches/tc4.1.x: catalina/src/conf/server.xml resources/confinstall/server_1.xml resources/confinstall/server_2.xml

[markt]

Author: markt
Date: Tue Aug  1 19:45:23 2006
New Revision: 427861

URL: http://svn.apache.org/viewvc?rev=427861&view=rev
Log:
Align standard server.xml with one created by the Windows installer

Modified:
tomcat/container/branches/tc4.1.x/catalina/src/conf/server.xml
tomcat/container/branches/tc4.1.x/resources/confinstall/server_1.xml
tomcat/container/branches/tc4.1.x/resources/confinstall/server_2.xml

Modified: tomcat/container/branches/tc4.1.x/catalina/src/conf/server.xml
URL: 
http://svn.apache.org/viewvc/tomcat/container/branches/tc4.1.x/catalina/src/conf/server.xml?rev=427861&r1=427860&r2=427861&view=diff
==
--- tomcat/container/branches/tc4.1.x/catalina/src/conf/server.xml (original)
+++ tomcat/container/branches/tc4.1.x/catalina/src/conf/server.xml Tue Aug  1 
19:45:23 2006
@@ -109,7 +109,7 @@
 
 
 
+  
+  
   
   http://svn.apache.org/viewvc/tomcat/container/branches/tc4.1.x/resources/confinstall/server_2.xml?rev=427861&r1=427860&r2=427861&view=diff
==
--- tomcat/container/branches/tc4.1.x/resources/confinstall/server_2.xml 
(original)
+++ tomcat/container/branches/tc4.1.x/resources/confinstall/server_2.xml Tue 
Aug  1 19:45:23 2006
@@ -1,7 +1,6 @@
 
-   minProcessors="5" maxProcessors="75"
enableLookups="true" redirectPort="8443"
-   acceptCount="100" debug="0" connectionTimeout="2"
+   acceptCount="100" connectionTimeout="2"
useURIValidationHack="false" disableUploadTimeout="true" />
 
@@ -9,61 +8,28 @@
 
 
 
-
+
 
 
-
-
-
-
-
-
-
-
-
-
-
-
-
 
 
+
+
 
 
 
@@ -286,46 +252,5 @@
 
 
   
-
-  
-
-  
-
 
 



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

DO NOT REPLY [Bug 40160] New: - Webdav Context path must be /*

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

   Summary: Webdav Context path must be /*
   Product: Tomcat 5
   Version: Unknown
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Servlets:WebDAV
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


The context path at which the webdav servlet is run must be
/*. That is, a web.xml entry like the following does
not work:


webdavsf
/dav/*


This is tested on 5.5.17

This is unfortunate if you want to have one WAR file
containing some other servlets and a dav area with
content autogenerated by the servlets.

I have made patches to "webdav servlet" on SourceForge, which is derived from
the apache code and has the same problem. My patches seem to fix it, and I
suspect that very similar patches would fix the original version. I am not a dav
expert though, and I haven't tested it on the original version, nor any locking
etc. So the patches described bel

There seem to be two reasons for this requirement for /* instead of, say /dav/*

(1) The internal path generated for a null entry is
wrong. This can be fixed by removing the following
lines from getRelativePath() [in DefaultServlet]:
if (result == null)
result = (String) request.getAttribute(
Globals.INCLUDE_SERVLET_PATH_ATTR);

and
if (result == null) {
result = request.getServletPath();
}
I don't see how these lines could ever help in the WebDav context, though I am
not an expert in dav, and they may be important in some other use of 
DefaultServlet.

The second required modification that I posted for "webdav servlet" on
sourceforge has already been fixed (or something equivalent) in 5.5.17., so you
should be able to ignore that.

-- 
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: svn commit: r427821 - /tomcat/tc6.0.x/trunk/java/org/apache/naming/resources/ResourceCache.java

[James Courtney]

Fantastic, thanks Remy!

Do you guys still want a bug filed for that?

Jamey
 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, August 01, 2006 5:39 PM
To: tomcat-dev@jakarta.apache.org
Subject: svn commit: r427821 -
/tomcat/tc6.0.x/trunk/java/org/apache/naming/resources/ResourceCache.jav
a

Author: remm
Date: Tue Aug  1 17:39:28 2006
New Revision: 427821

URL: http://svn.apache.org/viewvc?rev=427821&view=rev
Log:
- Use a single reference to the cache during lookup (the cache array
could be concurrently replaced).

Modified:
 
tomcat/tc6.0.x/trunk/java/org/apache/naming/resources/ResourceCache.java

Modified:
tomcat/tc6.0.x/trunk/java/org/apache/naming/resources/ResourceCache.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/naming
/resources/ResourceCache.java?rev=427821&r1=427820&r2=427821&view=diff

==
---
tomcat/tc6.0.x/trunk/java/org/apache/naming/resources/ResourceCache.java
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/naming/resources/ResourceCache.
+++ java Tue Aug  1 17:39:28 2006
@@ -289,10 +289,11 @@
 public CacheEntry lookup(String name) {
 
 CacheEntry cacheEntry = null;
+CacheEntry[] currentCache = cache;
 accessCount++;
-int pos = find(cache, name);
-if ((pos != -1) && (name.equals(cache[pos].name))) {
-cacheEntry = cache[pos];
+int pos = find(currentCache, name);
+if ((pos != -1) && (name.equals(currentCache[pos].name))) {
+cacheEntry = currentCache[pos];
 }
 if (cacheEntry == null) {
 try {



-
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: svn commit: r427821 - /tomcat/tc6.0.x/trunk/java/org/apache/naming/resources/ResourceCache.java

[James Courtney]

BTW, is my increasing cacheMaxSize on the Context a sensible workaround
until this code is released?

Thanks!

Jamey


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, August 01, 2006 5:39 PM
To: tomcat-dev@jakarta.apache.org
Subject: svn commit: r427821 -
/tomcat/tc6.0.x/trunk/java/org/apache/naming/resources/ResourceCache.jav
a

Author: remm
Date: Tue Aug  1 17:39:28 2006
New Revision: 427821

URL: http://svn.apache.org/viewvc?rev=427821&view=rev
Log:
- Use a single reference to the cache during lookup (the cache array
could be concurrently replaced).

Modified:
 
tomcat/tc6.0.x/trunk/java/org/apache/naming/resources/ResourceCache.java

Modified:
tomcat/tc6.0.x/trunk/java/org/apache/naming/resources/ResourceCache.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/naming
/resources/ResourceCache.java?rev=427821&r1=427820&r2=427821&view=diff

==
---
tomcat/tc6.0.x/trunk/java/org/apache/naming/resources/ResourceCache.java
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/naming/resources/ResourceCache.
+++ java Tue Aug  1 17:39:28 2006
@@ -289,10 +289,11 @@
 public CacheEntry lookup(String name) {
 
 CacheEntry cacheEntry = null;
+CacheEntry[] currentCache = cache;
 accessCount++;
-int pos = find(cache, name);
-if ((pos != -1) && (name.equals(cache[pos].name))) {
-cacheEntry = cache[pos];
+int pos = find(currentCache, name);
+if ((pos != -1) && (name.equals(currentCache[pos].name))) {
+cacheEntry = currentCache[pos];
 }
 if (cacheEntry == null) {
 try {



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