Re: svn commit: r348665 - /tomcat/sandbox/java/org/apache/coyote/standalone/MainInetd.java

[Bill Barker]

<[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Author: costin
> Date: Wed Nov 23 21:34:19 2005
> New Revision: 348665
>
> URL: http://svn.apache.org/viewcvs?rev=348665&view=rev
> Log:
> Another experiment - this class uses NIO to get the socket from Xinetd ( 
> I'll also try
> with launchd ). This allows starting tomcat on-demand, from xinetd/lauchd.
> Work in progress, I also want to shutdown when idle for too long.
>
> This is also targeted to embeded/desktop use.
>

About the most useless waste of svn space I could imagine.  I mean, it's 
like a total reason to close off the sandbox right here.




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

Re: svn commit: r348665 - /tomcat/sandbox/java/org/apache/coyote/standalone/MainInetd.java

[Cédrik LIME]

At 00:35 24/11/2005 -0800, you wrote:


<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Author: costin
> Date: Wed Nov 23 21:34:19 2005
> New Revision: 348665
>
> URL: http://svn.apache.org/viewcvs?rev=348665&view=rev
> Log:
> Another experiment - this class uses NIO to get the socket from Xinetd (
> I'll also try
> with launchd ). This allows starting tomcat on-demand, from xinetd/lauchd.
> Work in progress, I also want to shutdown when idle for too long.
>
> This is also targeted to embeded/desktop use.
>

About the most useless waste of svn space I could imagine.  I mean, it's
like a total reason to close off the sandbox right here.


Disk space is cheap. Why should we prevent new ideas from being expressed?

Even if this particular test won't make it in 
HEAD, even if *most* of the experiments in the 
sandbox will die, it is always useful to express 
ideas: you never you, it may spark a light in 
someone's head for the next killer feature.


+1 to keeping sandbox!

Besides... I find integrating TC with launchd is 
worth its share of geekpoints! O:-)


Cédrik 



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

DO NOT REPLY [Bug 37627] New: - Slow and incomplete dynamic content generation after enabling native connector support

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

   Summary: Slow and incomplete dynamic content generation after
enabling native connector support
   Product: Tomcat 5
   Version: 5.5.12
  Platform: Other
OS/Version: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Unknown
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


After adding the APR library to the java.library.path [as described in
http://tomcat.apache.org/tomcat-5.5-doc/apr.html], certain JSPs that produce a
lot of output (but used to be served in under a second) are now very slow and
produce incomplete output (after reloading a few times). Sometimes the header
appears only after a few kilobytes of output, at which point the output is cut
off...


http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
http://www.w3.org/1999/xhtml";>
...
Server: Apache-Coyote/1.1
X-Total-Results: 389
Content-Type: text/html;charset=UTF-8
Content-Language: en-US
Content-Length: 22858
Date: Thu, 24 Nov 2005 08:41:56 GMT

Any ideas what is going on here?

-- 
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 37627] - Slow and incomplete dynamic content generation after enabling native connector support

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





--- Additional Comments From [EMAIL PROTECTED]  2005-11-24 14:04 ---
Created an attachment (id=17031)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=17031&action=view)
Test application


-- 
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 37627] - Slow and incomplete dynamic content generation after enabling native connector support

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





--- Additional Comments From [EMAIL PROTECTED]  2005-11-24 14:19 ---
Nope, this JSP works fine for me. Another attempt ?

-- 
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 37629] New: - No worker files

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

   Summary: No worker files
   Product: Tomcat 5
   Version: 5.5.12
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: normal
  Priority: P2
 Component: Unknown
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


In the 5.5.12 distribution I did not found any worker.properties files under the
conf directory. Is it normal or is it a new change in Tomcat, there is no
explanation in the doc?
Sorry if it is not the good place to log this kind of problem, but I did not
found any other place.
Regards.
Jean-Yves

-- 
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: r348735 - in /tomcat: connectors/trunk/http11/src/java/org/apache/coyote/http11/InternalAprOutputBuffer.java container/tc5.5.x/webapps/docs/changelog.xml

[remm]

Author: remm
Date: Thu Nov 24 06:04:48 2005
New Revision: 348735

URL: http://svn.apache.org/viewcvs?rev=348735&view=rev
Log:
- 37627:Fix buffering issue in the HTTP APR connector when a large buffer
  size was used for servlets.
- Unfortunately the FIXME had never been addressed and the algorithm never
  implemented properly, unlike for the AJP connector.

Modified:

tomcat/connectors/trunk/http11/src/java/org/apache/coyote/http11/InternalAprOutputBuffer.java
tomcat/container/tc5.5.x/webapps/docs/changelog.xml

Modified: 
tomcat/connectors/trunk/http11/src/java/org/apache/coyote/http11/InternalAprOutputBuffer.java
URL: 
http://svn.apache.org/viewcvs/tomcat/connectors/trunk/http11/src/java/org/apache/coyote/http11/InternalAprOutputBuffer.java?rev=348735&r1=348734&r2=348735&view=diff
==
--- 
tomcat/connectors/trunk/http11/src/java/org/apache/coyote/http11/InternalAprOutputBuffer.java
 (original)
+++ 
tomcat/connectors/trunk/http11/src/java/org/apache/coyote/http11/InternalAprOutputBuffer.java
 Thu Nov 24 06:04:48 2005
@@ -720,19 +720,20 @@
 public int doWrite(ByteChunk chunk, Response res) 
 throws IOException {
 
-// FIXME: It would likely be more efficient to do a number of 
writes
-// through the direct BB; however, the case should happen very 
rarely.
-// An algorithm similar to ByteChunk.append may also be better.
-if (chunk.getLength() > bbuf.capacity()) {
-if (Socket.send(socket, chunk.getBuffer(), chunk.getStart(), 
-chunk.getLength()) < 0) {
-throw new IOException(sm.getString("iib.failedwrite"));
-}
-} else {
-if (bbuf.position() + chunk.getLength() > bbuf.capacity()) {
+int len = chunk.getLength();
+int start = chunk.getStart();
+byte[] b = chunk.getBuffer();
+while (len > 0) {
+int thisTime = len;
+if (bbuf.position() == bbuf.capacity()) {
 flushBuffer();
 }
-bbuf.put(chunk.getBuffer(), chunk.getStart(), 
chunk.getLength());
+if (thisTime > bbuf.capacity() - bbuf.position()) {
+thisTime = bbuf.capacity() - bbuf.position();
+}
+bbuf.put(b, start, thisTime);
+len = len - thisTime;
+start = start + thisTime;
 }
 return chunk.getLength();
 

Modified: tomcat/container/tc5.5.x/webapps/docs/changelog.xml
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/webapps/docs/changelog.xml?rev=348735&r1=348734&r2=348735&view=diff
==
--- tomcat/container/tc5.5.x/webapps/docs/changelog.xml (original)
+++ tomcat/container/tc5.5.x/webapps/docs/changelog.xml Thu Nov 24 06:04:48 2005
@@ -136,6 +136,10 @@
 Fix crash which could occur with the HTTP APR connector when accessing 
request JMX objects
 outside of the processing of the said request (remm)
   
+  
+37627: Fix buffering issue in the HTTP APR connector when a 
large buffer size was
+used for servlets (remm)
+  
 
   
   



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

DO NOT REPLY [Bug 37627] - Slow and incomplete dynamic content generation after enabling native connector support

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-11-24 15:07 ---
A bad bug report ... The header returned gave away you were using a large
bufferSize (which BTW I consider an inefficient waste of memory), however.

-- 
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 37627] - Slow and incomplete dynamic content generation after enabling native connector support

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





--- Additional Comments From [EMAIL PROTECTED]  2005-11-24 15:25 ---
I am using a Tomcat 5.5.12 default installation, and never set any "bufferSize"
anywhere!? Do I need to change the default value?


-- 
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 37627] - Slow and incomplete dynamic content generation after enabling native connector support

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





--- Additional Comments From [EMAIL PROTECTED]  2005-11-24 15:27 ---
It seems that the problem can't be reproduced on Windows. Perhaps I did
something wrong during setup? I have apr-1.2.2 installed.


-- 
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 37627] - Slow and incomplete dynamic content generation after enabling native connector support

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





--- Additional Comments From [EMAIL PROTECTED]  2005-11-24 15:41 ---
(In reply to comment #4)
> I am using a Tomcat 5.5.12 default installation, and never set any 
> "bufferSize"
> anywhere!? Do I need to change the default value?

Content-Length: 22858 proves you are using response.setBufferSize.

-- 
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 37627] - Slow and incomplete dynamic content generation after enabling native connector support

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





--- Additional Comments From [EMAIL PROTECTED]  2005-11-24 16:00 ---
(In reply to comment #6)
> Content-Length: 22858 proves you are using response.setBufferSize.

Please have a look at the attached test application; it's a simple jsp page, no
response.setBufferSize in sight!

-- 
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 32719] - IntrospectionUtils feature causes $ charters to be stripped out of web.xml files

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




--- Additional Comments From [EMAIL PROTECTED]  2005-11-24 17:26 ---
*** Bug 34843 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]

Re: svn commit: r348665 - /tomcat/sandbox/java/org/apache/coyote/standalone/MainInetd.java

[Costin Manolache]

On 11/24/05, Bill Barker <[EMAIL PROTECTED]> wrote:

> > URL: http://svn.apache.org/viewcvs?rev=348665&view=rev
> > Log:
> > Another experiment - this class uses NIO to get the socket from Xinetd (
> > I'll also try
> > with launchd ). This allows starting tomcat on-demand, from xinetd/lauchd.
> > Work in progress, I also want to shutdown when idle for too long.


> About the most useless waste of svn space I could imagine.  I mean, it's
> like a total reason to close off the sandbox right here.

I can move this to sf, but it is far more usefull than a lot of code in tomcat.

Costin

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

DO NOT REPLY [Bug 10903] - Unbalanced tags do not generate compile time error

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |




--- Additional Comments From [EMAIL PROTECTED]  2005-11-24 17:40 ---
I think there could be a side effect.
A page like this one used to work on Tomcat 4.1, and gives a " The end tag
"

Re: svn commit: r348665 - /tomcat/sandbox/java/org/apache/coyote/standalone/MainInetd.java

[Costin Manolache]

I'm a bit puzzled - can you explain a bit why you think it's a bad idea ???

I hope you realize this is not 'prefork' mode ( i.e. forking a tomcat
on each request ), just wait
for the first connection and pass the server socket descriptor. It's
by far the cleanest method to run tomcat on port 80 - either via
xinetd/launchd, or via another native wrapper ( compare it with
commons-daemon ). And the only clean method I know of loading tomcat
on demand - instead of keeping it running and taking memory all the
time. Tomcat is not used only for big servers, but also for
development and smaller servers - I don't like my memory used by code
that I run only once in a while.

Costin

On 11/24/05, Bill Barker <[EMAIL PROTECTED]> wrote:
>
> <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > Author: costin
> > Date: Wed Nov 23 21:34:19 2005
> > New Revision: 348665
> >
> > URL: http://svn.apache.org/viewcvs?rev=348665&view=rev
> > Log:
> > Another experiment - this class uses NIO to get the socket from Xinetd (
> > I'll also try
> > with launchd ). This allows starting tomcat on-demand, from xinetd/lauchd.
> > Work in progress, I also want to shutdown when idle for too long.
> >
> > This is also targeted to embeded/desktop use.
> >
>
> About the most useless waste of svn space I could imagine.  I mean, it's
> like a total reason to close off the sandbox right here.
>
>
>
>
> -
> 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]

getContext() - spec interpretation

[Mark Thomas]

All,

I have been looking at bug 13040 and reviewing the current 
getContext() implementation. I saw Remy's comment from some time ago 
when fixing some related bugs 
(http://marc.theaimsgroup.com/?l=tomcat-dev&m=106008981803343&w=2) 
that this would be better if the spec mandated that the parameter 
passed to getContext() must be an exact match for a context path.


Having read the 2.4 spec several times I am pretty sure that is does 
say this, albeit not as directly as it might. I assume (perhaps 
wrongly) that any changes in this area will generate a lot of debate 
so I wanted to do the debate and then change the code.


The key parts of the spec are:
SRV.14.2.8 ServletContext

public ServletContext getContext(java.lang.String uripath)

uripath - a String specifying the context path of another web 
application in the container.



My interpretation is:
SRV.14.2.8 says the parameter is a context path
SRV.4.4 is very clear about what is context path is

Therefore, getContext() must look for an exact match of uripath 
against the context paths for the currently deployed web-apps.


My proposal, therefore is to change the getContext() implementation to 
look for an exact match. This is stricter than the current 
implementation (and may cause problems for some users) but will fix a 
number of odd behaviours including the one described in bug 13040.


In the unlikely event that no-one disagrees with my interpretation, 
I'll commit a fix over the weekend to TC4 and TC5. (The 2.3 spec has 
the exact same wording.)


Mark


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

Re: getContext() - spec interpretation

[Yoav Shapira]

Oddly enough, I was thinking about the same thing a couple of weeks
ago and tend to agree with your interpretation...

Yoav

On 11/24/05, Mark Thomas <[EMAIL PROTECTED]> wrote:
> All,
>
> I have been looking at bug 13040 and reviewing the current
> getContext() implementation. I saw Remy's comment from some time ago
> when fixing some related bugs
> (http://marc.theaimsgroup.com/?l=tomcat-dev&m=106008981803343&w=2)
> that this would be better if the spec mandated that the parameter
> passed to getContext() must be an exact match for a context path.
>
> Having read the 2.4 spec several times I am pretty sure that is does
> say this, albeit not as directly as it might. I assume (perhaps
> wrongly) that any changes in this area will generate a lot of debate
> so I wanted to do the debate and then change the code.
>
> The key parts of the spec are:
> SRV.14.2.8 ServletContext
> 
> public ServletContext getContext(java.lang.String uripath)
> 
> uripath - a String specifying the context path of another web
> application in the container.
> 
>
> My interpretation is:
> SRV.14.2.8 says the parameter is a context path
> SRV.4.4 is very clear about what is context path is
>
> Therefore, getContext() must look for an exact match of uripath
> against the context paths for the currently deployed web-apps.
>
> My proposal, therefore is to change the getContext() implementation to
> look for an exact match. This is stricter than the current
> implementation (and may cause problems for some users) but will fix a
> number of odd behaviours including the one described in bug 13040.
>
> In the unlikely event that no-one disagrees with my interpretation,
> I'll commit a fix over the weekend to TC4 and TC5. (The 2.3 spec has
> the exact same wording.)
>
> Mark
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
Yoav Shapira
System Design and Management Fellow
MIT Sloan School of Management
Cambridge, MA, USA
[EMAIL PROTECTED] / www.yoavshapira.com

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