Re: svn commit: r423119 - /tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Connector.java

[Remy Maucherat]

[EMAIL PROTECTED] wrote:

Author: mturk
Date: Tue Jul 18 08:38:14 2006
New Revision: 423119

URL: http://svn.apache.org/viewvc?rev=423119&view=rev
Log:
Add svn:eol-style:native.
We'll probably need to do that for the entire repository.


-1. This will screw up diffs, which will create much bigger problems.

Rémy

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

svn commit: r423388 - /tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11Protocol.java

[remm]

Author: remm
Date: Wed Jul 19 00:05:45 2006
New Revision: 423388

URL: http://svn.apache.org/viewvc?rev=423388&view=rev
Log:
- get/setProperty are used by IntrospectionUtils. Oops.

Modified:
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11Protocol.java

Modified: tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11Protocol.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11Protocol.java?rev=423388&r1=423387&r2=423388&view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11Protocol.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11Protocol.java Wed 
Jul 19 00:05:45 2006
@@ -100,6 +100,20 @@
 
 
 /**
+ * Set a property.
+ */
+public void setProperty(String name, String value) {
+setAttribute(name, value);
+}
+
+/**
+ * Get a property
+ */
+public String getProperty(String name) {
+return (String)getAttribute(name);
+}
+
+/**
  * Pass config info
  */
 public void setAttribute(String name, Object value) {



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

Re: svn commit: r423119 - /tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Connector.java

[Mladen Turk]

Remy Maucherat wrote:

[EMAIL PROTECTED] wrote:

Author: mturk
Date: Tue Jul 18 08:38:14 2006
New Revision: 423119

URL: http://svn.apache.org/viewvc?rev=423119&view=rev
Log:
Add svn:eol-style:native.
We'll probably need to do that for the entire repository.


-1. This will screw up diffs, which will create much bigger problems.



???
Are you sure?
I think that the current situation is screwing the diffs.
All .txt files should have svn:eol-style:native
All .sh files should have svn:eol-style:native;svn:executable
etc...

Anyhow see:
http://svnbook.red-bean.com/en/1.0/ch07s02.html#svn-ch-7-sect-2.3.5

--
Mladen.

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

Re: svn commit: r423119 - /tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Connector.java

[Rainer Jung]

In

http://www.apache.org/dev/version-control.html

the ASF suggests:

Committers will need to properly configure their svn client. One 
particular issue is OS-specific line-endings for text files. When you 
add a new text file, especially when applying patches from Bugzilla, 
first ensure that the line-endings are appropriate for your system, then 
do ...


svn add test.txt
svn propset svn:eol-style native test.txt

Your svn client can be configured to do that automatically for some 
common file types. Add the list to your ~/.subversion/config file.


The last line links to:

http://www.apache.org/dev/svn-eol-style.txt

I used this and up to now had no problems with new files in connectors.

But: when I check out the TC6 files, I get a funny mix of line ending 
types. So I think at the moment htey are not very consistent in the 
repository. I remember Filip also having some trouble.


Maybe we need to set everything to native, checkout, convert those that 
have the wrong endings and commit?


Rainer

Mladen Turk wrote:

Remy Maucherat wrote:


[EMAIL PROTECTED] wrote:


Author: mturk
Date: Tue Jul 18 08:38:14 2006
New Revision: 423119

URL: http://svn.apache.org/viewvc?rev=423119&view=rev
Log:
Add svn:eol-style:native.
We'll probably need to do that for the entire repository.



-1. This will screw up diffs, which will create much bigger problems.



???
Are you sure?
I think that the current situation is screwing the diffs.
All .txt files should have svn:eol-style:native
All .sh files should have svn:eol-style:native;svn:executable
etc...

Anyhow see:
http://svnbook.red-bean.com/en/1.0/ch07s02.html#svn-ch-7-sect-2.3.5

--
Mladen.

-
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 40072] New: - New Session Created Randomly in Tomcat 5.0.28

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

   Summary: New Session Created Randomly  in Tomcat 5.0.28
   Product: Tomcat 5
   Version: 5.0.28
  Platform: Other
OS/Version: Windows 2000
Status: NEW
  Severity: critical
  Priority: P2
 Component: Servlet & JSP API
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


1.  I have a  typical  JSP-Servlet web application running on tomcat 5.0.28. 
 2.  After successful login a new session is created. (in login.jsp) and user
specific data is kept in session
 3.  User moves on through the application .   Accesses  a JSP ( e.g. 
PageWithHeavyJavascript.jsp),  JavaScript code.
 4.  After  doing some selections etc. PageWithHeavyJavascript.jsp,  user
browses another JSP ( e.g.  plain.jsp)  which *does not* have any session
related code. At this point *sometimes* a  NEW session is created. (By
implementing HttpSessionListener I observed that the sessionCreated() methos is
getting called everytime and sessionDestoryed() method is never getting called)
5. After lot of debugging I have observed that this happens when  lot of
Javascript code is called through clicks etc. new session is created. I am
unable to link lot of Javascript calls with New session getting created.
  I would appreciate if you can shed some light on this issue... any 
hint/solution?

-- 
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 40070] - APR causes JVM to crashon SEGV

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 AssignedTo|[EMAIL PROTECTED] |tomcat-
   ||[EMAIL PROTECTED]
  Component|APR |Unknown
Product|APR |Tomcat 5
Version|HEAD|5.0.0




--- Additional Comments From [EMAIL PROTECTED]  2006-07-19 08:57 ---
"Crash in Tomcat" does not necessarily imply "Bug in APR"; this needs to be
diagnosed from the Tomcat perspective first.

-- 
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: mod_jk 1.2.17+ Recover time

[Henri Gomez]

Well a new show stopper for 1.2.18 ;(

2006/7/18, David Rees <[EMAIL PROTECTED]>:

On 7/18/06, Jess Holle <[EMAIL PROTECTED]> wrote:
> Is the 60 seconds hard-coded?
>
> I'd hope not...
>
> Once you have some interesting web apps in Tomcat it often takes a bit
> longer than 10 seconds -- and on my laptop just took a full 60 seconds,
> but that is rather unusual (a restart thereafter only took 18).

Yes, it's hard-coded. See my references in my first post.

-Dave

-
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: r423119 - /tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Connector.java

[Mladen Turk]

Rainer Jung wrote:


Maybe we need to set everything to native, checkout, convert those that 
have the wrong endings and commit?




No need for co/commit.
svn propset will convert current line endings to the virtual
one I suppose, and then each client depending on the platform
will have correct EOL.

tc5.5.x branch has that resolved, and the svn:eol-style is
set correctly for all source/resource non-binary files.
Even all image types have svn:mime-type:application/octet-stream
although they should have svn:mime-type:image/gif, etc...

Regards,
Mladen.

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

Re: mod_jk 1.2.17+ Recover time

[Mladen Turk]

Henri Gomez wrote:

Well a new show stopper for 1.2.18 ;(



Why it would be?
JK 1.2.18 is still not tagged.

--
Mladen.

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

Re: mod_jk 1.2.17+ Recover time

[Rainer Jung]

No, I think it's not:

1) This is not a regression, it was always implemented like that.

2) The recover feature is used in the load balancer and the first way of 
avoiding errors is meant to be retries, the second way is failover. Only 
then comes recovery.


3) A worker that goes into error state is something 
serious/heavy-weight. Timeouts leading to error state should not be 
chosen to small, so that workers go into errors just because of regular 
long running requests.


4) Recovering a worker is not something lightweight, because a stuck 
tomcat might mean, that every recovery times out at full length. 
Remember: we are doing recovery with real requests. I think it's not a 
good idea to try recovering with real requests very often. That's the 
reason for only trying to recover rarely.


5) Once we might have seperate management threads in mod_proxy_ it would 
make sense to probe failed workers more often.


6) We could make the interval configurable, but there is a real danger 
of users thinking, that a low recovery interval, like 10 seconds would 
make things better, whereas it is very likely, that it would make there 
whole system kind of oscillate.


Reagrds

Rainer

 to the full timeouts in the worker

Henri Gomez wrote:

Well a new show stopper for 1.2.18 ;(

2006/7/18, David Rees <[EMAIL PROTECTED]>:


On 7/18/06, Jess Holle <[EMAIL PROTECTED]> wrote:
> Is the 60 seconds hard-coded?
>
> I'd hope not...
>
> Once you have some interesting web apps in Tomcat it often takes a bit
> longer than 10 seconds -- and on my laptop just took a full 60 seconds,
> but that is rather unusual (a restart thereafter only took 18).

Yes, it's hard-coded. See my references in my first post.

-Dave

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

svn commit: r423418 - /tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c

[mturk]

Author: mturk
Date: Wed Jul 19 02:49:02 2006
New Revision: 423418

URL: http://svn.apache.org/viewvc?rev=423418&view=rev
Log:
Allow to have the recover timeout less then default
60 second. If someone needs the lower latency, then
he can set worker.name.recover_time=xxx where the
xxx is value in seconds larger then zero.

Modified:
tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c

Modified: tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c?rev=423418&r1=423417&r2=423418&view=diff
==
--- tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c Wed Jul 19 02:49:02 
2006
@@ -1005,8 +1005,8 @@
 p->s->retries = pThis->retries;
 p->s->recover_wait_time = jk_get_worker_recover_timeout(props, p->s->name,
 
WAIT_BEFORE_RECOVER);
-if (p->s->recover_wait_time < WAIT_BEFORE_RECOVER)
-p->s->recover_wait_time = WAIT_BEFORE_RECOVER;
+if (p->s->recover_wait_time < 1)
+p->s->recover_wait_time = 1;
 p->maintain_time = jk_get_worker_maintain_time(props);
 p->s->last_maintain_time = time(NULL);
 



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

Re: mod_jk 1.2.17+ Recover time

[Mladen Turk]

Henri Gomez wrote:

Well a new show stopper for 1.2.18 ;(



Committed a fix that allows to have a
worker.name.recover_time lower then 60 seconds.
Previously the minimum value was 60 seconds, and
now is 1 second.
The default is still the same (60 seconds)

Regards,
Mladen.

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

Re: mod_jk 1.2.17+ Recover time

[Mladen Turk]

Rainer Jung wrote:


6) We could make the interval configurable, but there is a real danger 
of users thinking, that a low recovery interval, like 10 seconds would 
make things better, whereas it is very likely, that it would make there 
whole system kind of oscillate.




Well, I don't wish to limit the users.
If someone thinks that it should retry on the lower intervals,
let him do that.
Anyhow, why would 60 second be optimal value?
It could as well be 90, 100, 180, etc...

Regards,
Mladen.

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

Re: mod_jk 1.2.17+ Recover time

[Rainer Jung]

Mladen Turk wrote:

Rainer Jung wrote:



6) We could make the interval configurable, but there is a real danger 
of users thinking, that a low recovery interval, like 10 seconds would 
make things better, whereas it is very likely, that it would make 
there whole system kind of oscillate.




Well, I don't wish to limit the users.
If someone thinks that it should retry on the lower intervals,
let him do that.


Yes, but we are doing recovery centralized, that is not every process 
does it on it's own. We moved it to global maintenance, so to really 
profit in a reliable way from a decreased recovery_time a user would 
also need to lower worker.maintain. I'm hoing to addd a few doc lines 
about that later today (at least if you are not faster :) ).



Anyhow, why would 60 second be optimal value?
It could as well be 90, 100, 180, etc...

Increasing is something totally different. I just want to avoid people 
ending with a system that changes error/ok states with a high frequency, 
so that the whole system gets instable.


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

Re: mod_jk 1.2.17+ Recover time

[Mladen Turk]

Rainer Jung wrote:

No, I think it's not:

1) This is not a regression, it was always implemented like that.



Right, and the reason it was never changed was because
no one gave any reason to change it.
Like said, 60 seconds recover timeout was probably used
since someone thought it should be 'fine'.
OTOH the proper value would be 240, cause that's the
common value of TCP_CLOSE_WAIT timeout.

Anyhow, leaving the current 60 second default value,
but allowing lower intervals will change nothing to
the 99.99% of the users.

Regards,
Mladen.

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

Re: mod_jk 1.2.17+ Recover time

[Mladen Turk]

Rainer Jung wrote:

Mladen Turk wrote:


Anyhow, why would 60 second be optimal value?
It could as well be 90, 100, 180, etc...

Increasing is something totally different. I just want to avoid people 
ending with a system that changes error/ok states with a high frequency, 
so that the whole system gets instable.




Right, but why would 60 seconds be an optimal value?
It can be 10 seconds as well. I don't know, cause I
never (and I doubt anyone has) did some profiling
that would tell how that impact the overall performance.
We can only presume and guess, but until someone
gives some real figures, why limiting something we
only presume it might cause problems?

Regards,
Mladen.

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

Re: mod_jk 1.2.17+ Recover time

[Rainer Jung]

I'm OK with your change.

I think we should try to educate the users via doc, that they need to be 
careful when lowering these values to very small numbers. I don't know, 
if that's the right term, but the system needs some damping to keep it 
from switching very frequently between states. At least in most cases.


Mladen Turk wrote:

Rainer Jung wrote:


Mladen Turk wrote:


Anyhow, why would 60 second be optimal value?
It could as well be 90, 100, 180, etc...

Increasing is something totally different. I just want to avoid people 
ending with a system that changes error/ok states with a high 
frequency, so that the whole system gets instable.




Right, but why would 60 seconds be an optimal value?
It can be 10 seconds as well. I don't know, cause I
never (and I doubt anyone has) did some profiling
that would tell how that impact the overall performance.
We can only presume and guess, but until someone
gives some real figures, why limiting something we
only presume it might cause problems?


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

Re: mod_jk 1.2.17+ Recover time

[Remy Maucherat]

Henri Gomez wrote:

Well a new show stopper for 1.2.18 ;(


Why ? With the current implementation, low values will have extremely 
bad behavior in some cases. You should actually configure long 
intervals, without retries.


Rémy

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

Re: mod_jk 1.2.17+ Recover time

[Remy Maucherat]

Rainer Jung wrote:

No, I think it's not:

1) This is not a regression, it was always implemented like that.

2) The recover feature is used in the load balancer and the first way of 
avoiding errors is meant to be retries, the second way is failover. Only 
then comes recovery.


3) A worker that goes into error state is something 
serious/heavy-weight. Timeouts leading to error state should not be 
chosen to small, so that workers go into errors just because of regular 
long running requests.


4) Recovering a worker is not something lightweight, because a stuck 
tomcat might mean, that every recovery times out at full length. 
Remember: we are doing recovery with real requests. I think it's not a 
good idea to try recovering with real requests very often. That's the 
reason for only trying to recover rarely.


5) Once we might have seperate management threads in mod_proxy_ it would 
make sense to probe failed workers more often.


6) We could make the interval configurable, but there is a real danger 
of users thinking, that a low recovery interval, like 10 seconds would 
make things better, whereas it is very likely, that it would make there 
whole system kind of oscillate.


I completely agree with everything here.

Rémy

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

DO NOT REPLY [Bug 40072] - New Session Created Randomly in Tomcat 5.0.28

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2006-07-19 10:30 ---
by default jsp's create a session. Its part of the spec.

See <%@ page session='false'%> in the JSP spec for disabling 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: mod_jk 1.2.17+ Recover time

[Mladen Turk]

Rainer Jung wrote:

I'm OK with your change.

I think we should try to educate the users via doc, that they need to be 
careful when lowering these values to very small numbers. I don't know, 
if that's the right term, but the system needs some damping to keep it 
from switching very frequently between states. At least in most cases.




Correctly. 'Be careful' is a proper term.
If there is a direct link between mod_jk and Tomcat
the most OS-es will detect the broken link immediately.
However if you have a faulty firewall that does not
pass the FIN packets, then even the default 60 second
is less lower then a 240 second system default.

Regards,
Mladen.

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

Re: mod_jk 1.2.17+ Recover time

[Jean-frederic Clere]

Rainer Jung wrote:


No, I think it's not:

1) This is not a regression, it was always implemented like that.

2) The recover feature is used in the load balancer and the first way 
of avoiding errors is meant to be retries, the second way is failover. 
Only then comes recovery.


3) A worker that goes into error state is something 
serious/heavy-weight. Timeouts leading to error state should not be 
chosen to small, so that workers go into errors just because of 
regular long running requests.


4) Recovering a worker is not something lightweight, because a stuck 
tomcat might mean, that every recovery times out at full length. 
Remember: we are doing recovery with real requests. I think it's not a 
good idea to try recovering with real requests very often. That's the 
reason for only trying to recover rarely.


5) Once we might have seperate management threads in mod_proxy_ it 
would make sense to probe failed workers more often.


I am preparing a health checker separed process from httpd to health 
check the workers. If not healthy no retries failover directly, the 
recovering will only occurs when the worker is marked healty again by 
the health checker process.




6) We could make the interval configurable, but there is a real danger 
of users thinking, that a low recovery interval, like 10 seconds would 
make things better, whereas it is very likely, that it would make 
there whole system kind of oscillate.


The next problem is to find a way to tell TC that its connexions have 
been closed (by a stupid firewall that eats the closes for example).
That is nice to recover but how to make sure the TC part knows that 
something has went wrong.


Cheers

Jean-Frederic



Reagrds

Rainer

 to the full timeouts in the worker

Henri Gomez wrote:


Well a new show stopper for 1.2.18 ;(

2006/7/18, David Rees <[EMAIL PROTECTED]>:


On 7/18/06, Jess Holle <[EMAIL PROTECTED]> wrote:
> Is the 60 seconds hard-coded?
>
> I'd hope not...
>
> Once you have some interesting web apps in Tomcat it often takes a 
bit
> longer than 10 seconds -- and on my laptop just took a full 60 
seconds,

> but that is rather unusual (a restart thereafter only took 18).

Yes, it's hard-coded. See my references in my first post.

-Dave

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

Re: mod_jk 1.2.17+ Recover time

[Henri Gomez]

The next problem is to find a way to tell TC that its connexions have
been closed (by a stupid firewall that eats the closes for example).
That is nice to recover but how to make sure the TC part knows that
something has went wrong.


FW who eat the FIN-CLOSE ?

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

Re: mod_jk 1.2.17+ Recover time

[Jean-frederic Clere]

Henri Gomez wrote:



The next problem is to find a way to tell TC that its connexions have
been closed (by a stupid firewall that eats the closes for example).
That is nice to recover but how to make sure the TC part knows that
something has went wrong.



FW who eat the FIN-CLOSE ?


Yes, if not something like that.



-
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 40070] - APR causes JVM to crashon SEGV

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2006-07-19 12:13 ---
You're using Java2D, which as usual is doing invalid accesses to the
output steam. Without APR, you would get issues like getting requests
which are already committed at the beginning of the request, and other
random behavior like that. The solution is to not give direct access
to the Servlet API to the Java2D components (using an intermediate
buffer, etc), or enable the security manager.

-- 
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: r423453 - in /tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11: Constants.java filters/ChunkedInputFilter.java

[fhanik]

Author: fhanik
Date: Wed Jul 19 06:00:42 2006
New Revision: 423453

URL: http://svn.apache.org/viewvc?rev=423453&view=rev
Log:
Fixed chunked input filter to parse the header correctly. Performs strict 
parsing according to the RFC2616, so if the header is invalid it bails out.

Modified:
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Constants.java

tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/filters/ChunkedInputFilter.java

Modified: tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Constants.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Constants.java?rev=423453&r1=423452&r2=423453&view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Constants.java (original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Constants.java Wed Jul 
19 06:00:42 2006
@@ -83,6 +83,12 @@
  * COLON.
  */
 public static final byte COLON = (byte) ':';
+
+/**
+ * SEMI_COLON.
+ */
+public static final byte SEMI_COLON = (byte) ';';
+
 
 
 /**

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/filters/ChunkedInputFilter.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/filters/ChunkedInputFilter.java?rev=423453&r1=423452&r2=423453&view=diff
==
--- 
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/filters/ChunkedInputFilter.java
 (original)
+++ 
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/filters/ChunkedInputFilter.java
 Wed Jul 19 06:00:42 2006
@@ -27,9 +27,11 @@
 import org.apache.coyote.http11.InputFilter;
 
 /**
- * Chunked input filter.
+ * Chunked input filter. Parses chunked data according to
+ * http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6.1";>http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6.1
  * 
  * @author Remy Maucherat
+ * @author Filip Hanik
  */
 public class ChunkedInputFilter implements InputFilter {
 
@@ -127,7 +129,7 @@
 
 if (remaining <= 0) {
 if (!parseChunkHeader()) {
-throw new IOException("Invalid chunk");
+throw new IOException("Invalid chunk header");
 }
 if (endChunk) {
 parseEndChunk();
@@ -234,6 +236,12 @@
 
 /**
  * Parse the header of a chunk.
+ * A chunk header can look like 
+ * A10CRLF
+ * F23;chunk-extension to be ignoredCRLF
+ * The letters before CRLF but after the trailer mark, must be valid hex 
digits, 
+ * we should not parse F23IAMGONNAMESSTHISUP34CRLF as a valid header
+ * according to spec
  */
 protected boolean parseChunkHeader()
 throws IOException {
@@ -241,6 +249,7 @@
 int result = 0;
 boolean eol = false;
 boolean readDigit = false;
+boolean trailer = false;
 
 while (!eol) {
 
@@ -252,11 +261,18 @@
 if (buf[pos] == Constants.CR) {
 } else if (buf[pos] == Constants.LF) {
 eol = true;
-} else {
+} else if (buf[pos] == Constants.SEMI_COLON) {
+trailer = true;
+} else if (!trailer) { 
+//don't read data after the trailer
 if (HexUtils.DEC[buf[pos]] != -1) {
 readDigit = true;
 result *= 16;
 result += HexUtils.DEC[buf[pos]];
+} else {
+//we shouldn't allow invalid, non hex characters
+//in the chunked header
+return false;
 }
 }
 



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

svn commit: r423497 - /tomcat/tc6.0.x/branches/

[mturk]

Author: mturk
Date: Wed Jul 19 08:34:18 2006
New Revision: 423497

URL: http://svn.apache.org/viewvc?rev=423497&view=rev
Log:
Added branches top level directory

Added:
tomcat/tc6.0.x/branches/


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

svn commit: r423498 - /tomcat/tc6.0.x/branches/svn_props/

[mturk]

Author: mturk
Date: Wed Jul 19 08:35:12 2006
New Revision: 423498

URL: http://svn.apache.org/viewvc?rev=423498&view=rev
Log:
made a copy

Added:
tomcat/tc6.0.x/branches/svn_props/
  - copied from r423497, tomcat/tc6.0.x/trunk/


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

Re: Next try: mod_jk 1.2.17 release candidate ready to test

[Jim Jagielski]

Testing complete: +1

On Jul 18, 2006, at 12:48 PM, Jim Jagielski wrote:


I haven't done exhaustive testing yet, but it's looking
good :)

On Jul 18, 2006, at 10:44 AM, Henri Gomez wrote:


Good, so we're ready for a 1.2.18 release ?

2006/7/18, Jim Jagielski <[EMAIL PROTECTED]>:


On Jul 18, 2006, at 8:46 AM, Mladen Turk wrote:

> Rainer Jung wrote:
>> Then let Peter try it on Mac OS X, if he only gets a warning or a
>> real error.
>>
>
> Sure, but since
> http://www.hmug.org/man/2/getsockopt.php
> says that the OS/X uses socklen_t as well, we should be fine.
>

I get no build error...

% gcc --version
powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc.
build 5247)



 
-

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]

Re: mod_jk 1.2.17+ Recover time

[Jim Jagielski]

I'd say that it's a feature enhancement, not a show stopper.
And not a regression nor a bug :)

On Jul 19, 2006, at 5:16 AM, Henri Gomez wrote:


Well a new show stopper for 1.2.18 ;(

2006/7/18, David Rees <[EMAIL PROTECTED]>:

On 7/18/06, Jess Holle <[EMAIL PROTECTED]> wrote:
> Is the 60 seconds hard-coded?
>
> I'd hope not...
>
> Once you have some interesting web apps in Tomcat it often takes  
a bit
> longer than 10 seconds -- and on my laptop just took a full 60  
seconds,

> but that is rather unusual (a restart thereafter only took 18).

Yes, it's hard-coded. See my references in my first post.

-Dave

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

Re: mod_jk 1.2.17+ Recover time

[Henri Gomez]

ok :)

2006/7/19, Jim Jagielski <[EMAIL PROTECTED]>:

I'd say that it's a feature enhancement, not a show stopper.
And not a regression nor a bug :)

On Jul 19, 2006, at 5:16 AM, Henri Gomez wrote:

> Well a new show stopper for 1.2.18 ;(
>
> 2006/7/18, David Rees <[EMAIL PROTECTED]>:
>> On 7/18/06, Jess Holle <[EMAIL PROTECTED]> wrote:
>> > Is the 60 seconds hard-coded?
>> >
>> > I'd hope not...
>> >
>> > Once you have some interesting web apps in Tomcat it often takes
>> a bit
>> > longer than 10 seconds -- and on my laptop just took a full 60
>> seconds,
>> > but that is rather unusual (a restart thereafter only took 18).
>>
>> Yes, it's hard-coded. See my references in my first post.
>>
>> -Dave
>>
>> -
>> 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]

svn commit: r423503 - /tomcat/tc6.0.x/branches/svn_props/

[mturk]

Author: mturk
Date: Wed Jul 19 08:51:29 2006
New Revision: 423503

URL: http://svn.apache.org/viewvc?rev=423503&view=rev
Log:
Remove branch

Removed:
tomcat/tc6.0.x/branches/svn_props/


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

svn commit: r423504 - /tomcat/tc6.0.x/branches/svn_propset/

[mturk]

Author: mturk
Date: Wed Jul 19 08:53:17 2006
New Revision: 423504

URL: http://svn.apache.org/viewvc?rev=423504&view=rev
Log:
made a copy

Added:
tomcat/tc6.0.x/branches/svn_propset/
  - copied from r423503, tomcat/tc6.0.x/trunk/


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

svn commit: r423512 - in /tomcat/tc6.0.x/branches/svn_propset: ./ bin/ java/javax/annotation/ java/javax/annotation/security/ java/javax/el/ java/javax/mail/ java/javax/mail/internet/ java/javax/persi

[mturk]

Author: mturk
Date: Wed Jul 19 09:17:12 2006
New Revision: 423512

URL: http://svn.apache.org/viewvc?rev=423512&view=rev
Log:
svn propset svn:eol-style native *.java
svn propset svn:eol-style native *.properties
svn propset svn:eol-style native *.xml
svn propset svn:eol-style native *.html
svn propset svn:eol-style native *.txt
svn propset svn:eol-style native *.java
svn propset svn:eol-style native *.sh
svn propset svn:eol-style native *.bat
svn propset svn:executable *.sh
svn propset svn:executable *.bat
svn propset svn:executable *.exe
svn propset svn:mime-type image/gif *.gif
svn propset svn:mime-type image/jpeg *.jpg


[This commit notification would consist of 243 parts, 
which exceeds the limit of 50 ones, so it was shortened to the summary.]

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

SVN propset branch for tc6

[Mladen Turk]

Hi,

I have created a branch that shows the difference between
current trunk and the new one wit correctly set
svn:eol-style and svn:executable

For example the
java/org/apache/catalina/Context.java when checked
out on linux has DOS line endings with those ugly ^M.
The same file with svn:eol-style native from the
svn_props branch is perfect both on linux and windoze.

Any objections I apply that to the trunk?
Remy said -1, but I hope he changes his mind :)

In any case I'll delete the branch after 24 hrs.

Here is the script I used for that:
(name it to svnprops.bat)

@echo off
if "%OS%" == "Windows_NT" setlocal

if "%1" == "" (
set SCRIPT_NAME=%~f0
) else (
set SCRIPT_NAME=%~f1
)

for /D %%i in (*) do (
cd %%i
svn propset svn:eol-style native *.java
svn propset svn:eol-style native *.properties
svn propset svn:eol-style native *.xml
svn propset svn:eol-style native *.html
svn propset svn:eol-style native *.txt
svn propset svn:eol-style native *.java
svn propset svn:eol-style native *.sh
svn propset svn:eol-style native *.bat
svn propset svn:executable *.sh
svn propset svn:executable *.bat
svn propset svn:executable *.exe
svn propset svn:mime-type image/gif *.gif
svn propset svn:mime-type image/jpeg *.jpg

call %SCRIPT_NAME% %SCRIPT_NAME%
cd ..
)

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

svn commit: r423523 - /tomcat/tc6.0.x/trunk/java/javax/servlet/jsp/tagext/doc-files/Thumbs.db

[mturk]

Author: mturk
Date: Wed Jul 19 09:53:59 2006
New Revision: 423523

URL: http://svn.apache.org/viewvc?rev=423523&view=rev
Log:
Thumbs.db is not part of the servlet spec
I suppose. Seems someone committed that from the
Windows with folder image thumbnail cache.

Removed:
tomcat/tc6.0.x/trunk/java/javax/servlet/jsp/tagext/doc-files/Thumbs.db


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

Re: SVN propset branch for tc6

[Costin Manolache]

On 7/19/06, Mladen Turk <[EMAIL PROTECTED]> wrote:


Hi,

I have created a branch that shows the difference between
current trunk and the new one wit correctly set
svn:eol-style and svn:executable

For example the
java/org/apache/catalina/Context.java when checked
out on linux has DOS line endings with those ugly ^M.
The same file with svn:eol-style native from the
svn_props branch is perfect both on linux and windoze.

Any objections I apply that to the trunk?
Remy said -1, but I hope he changes his mind :)



-1 for what reason ?

Please get rid of the ugly CRLF !

Costin



In any case I'll delete the branch after 24 hrs.


Here is the script I used for that:
(name it to svnprops.bat)

@echo off
if "%OS%" == "Windows_NT" setlocal

if "%1" == "" (
set SCRIPT_NAME=%~f0
) else (
set SCRIPT_NAME=%~f1
)

for /D %%i in (*) do (
cd %%i
svn propset svn:eol-style native *.java
svn propset svn:eol-style native *.properties
svn propset svn:eol-style native *.xml
svn propset svn:eol-style native *.html
svn propset svn:eol-style native *.txt
svn propset svn:eol-style native *.java
svn propset svn:eol-style native *.sh
svn propset svn:eol-style native *.bat
svn propset svn:executable *.sh
svn propset svn:executable *.bat
svn propset svn:executable *.exe
svn propset svn:mime-type image/gif *.gif
svn propset svn:mime-type image/jpeg *.jpg

call %SCRIPT_NAME% %SCRIPT_NAME%
cd ..
)

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

svn commit: r423544 - in /tomcat/tc6.0.x/trunk/java/org/apache: coyote/http11/Http11NioProcessor.java coyote/http11/InternalNioOutputBuffer.java tomcat/util/net/NioEndpoint.java

[fhanik]

Author: fhanik
Date: Wed Jul 19 10:49:47 2006
New Revision: 423544

URL: http://svn.apache.org/viewvc?rev=423544&view=rev
Log:
Comet connection handling. When the response.getWriter().close() method has 
been called,
the comet connection is setup for closure instead of waiting for a timeout.
This is necessary since the servlet could have set a long timeout.
Also, improve on timeout checking. Only use the optimization for how frequently 
we need to check the keys if there has been no activity on the selector. During 
heavy activity, the optimization takes into effect.

Modified:
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java

tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java
tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java?rev=423544&r1=423543&r2=423544&view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java 
Wed Jul 19 10:49:47 2006
@@ -174,7 +174,14 @@
  * Comet used.
  */
 protected boolean comet = false;
-
+
+/**
+ * Closed flag, a Comet async thread can 
+ * signal for this Nio processor to be closed and recycled instead
+ * of waiting for a timeout.
+ * Closed by HttpServletResponse.getWriter().close()
+ */
+protected boolean cometClose = false;
 
 /**
  * Content delimitator for the request (if false, the connection will
@@ -970,6 +977,8 @@
 inputBuffer.recycle();
 outputBuffer.recycle();
 this.socket = null;
+this.cometClose = false;
+this.comet = false;
 }
 
 
@@ -1034,6 +1043,17 @@
 // transactions with the client
 
 comet = false;
+cometClose = true;
+SelectionKey key = 
socket.keyFor(endpoint.getPoller().getSelector());
+if ( key != null ) {
+NioEndpoint.KeyAttachment attach = (NioEndpoint.KeyAttachment) 
key.attachment();
+if ( attach!=null && attach.getComet()) {
+//we need to recycle
+
request.getAttributes().remove("org.apache.tomcat.comet.timeout");
+attach.setError(true);
+}
+}
+
 try {
 outputBuffer.endRequest();
 } catch (IOException e) {

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java?rev=423544&r1=423543&r2=423544&view=diff
==
--- 
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java 
(original)
+++ 
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java 
Wed Jul 19 10:49:47 2006
@@ -571,16 +571,11 @@
 
 int total = 0;
 private synchronized void addToBB(byte[] buf, int offset, int length) 
throws IOException {
-try {
-if (bbuf.capacity() <= (offset + length)) {
-flushBuffer();
-}
-bbuf.put(buf, offset, length);
-total += length;
-}catch ( Exception x ) {
-x.printStackTrace();
+if (bbuf.capacity() <= (offset + length)) {
+flushBuffer();
 }
-//System.out.println("Total:"+total);
+bbuf.put(buf, offset, length);
+total += length;
 }
 
 

Modified: tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java?rev=423544&r1=423543&r2=423544&view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java Wed 
Jul 19 10:49:47 2006
@@ -312,7 +312,7 @@
 public void setPollerThreadCount(int pollerThreadCount) { 
this.pollerThreadCount = pollerThreadCount; }
 public int getPollerThreadCount() { return pollerThreadCount; }
 
-protected long selectorTimeout = 5000;
+protected long selectorTimeout = 1000;
 public void setSelectorTimeout(long timeout){ this.selectorTimeout = 
timeout;}
 public long getSelectorTimeout(){ return this.selectorTimeout; }
 /**
@@ -1043,9 +1043,11 @@
 addEvent(r);
 }
 
-public void events() {
+public boolean events() {
+boolean result = false;
 synchronized (events) {
 

Re: SVN propset branch for tc6

[Filip Hanik - Dev Lists]

I would support this effort, I've been nailed a few times by line 
endings and them being inconsistent.
there are so many files in SVN for TC right now that have windows line 
endings.


Filip

Costin Manolache wrote:

On 7/19/06, Mladen Turk <[EMAIL PROTECTED]> wrote:


Hi,

I have created a branch that shows the difference between
current trunk and the new one wit correctly set
svn:eol-style and svn:executable

For example the
java/org/apache/catalina/Context.java when checked
out on linux has DOS line endings with those ugly ^M.
The same file with svn:eol-style native from the
svn_props branch is perfect both on linux and windoze.

Any objections I apply that to the trunk?
Remy said -1, but I hope he changes his mind :)



-1 for what reason ?

Please get rid of the ugly CRLF !

Costin



In any case I'll delete the branch after 24 hrs.


Here is the script I used for that:
(name it to svnprops.bat)

@echo off
if "%OS%" == "Windows_NT" setlocal

if "%1" == "" (
set SCRIPT_NAME=%~f0
) else (
set SCRIPT_NAME=%~f1
)

for /D %%i in (*) do (
cd %%i
svn propset svn:eol-style native *.java
svn propset svn:eol-style native *.properties
svn propset svn:eol-style native *.xml
svn propset svn:eol-style native *.html
svn propset svn:eol-style native *.txt
svn propset svn:eol-style native *.java
svn propset svn:eol-style native *.sh
svn propset svn:eol-style native *.bat
svn propset svn:executable *.sh
svn propset svn:executable *.bat
svn propset svn:executable *.exe
svn propset svn:mime-type image/gif *.gif
svn propset svn:mime-type image/jpeg *.jpg

call %SCRIPT_NAME% %SCRIPT_NAME%
cd ..
)

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






No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.10.1/391 - Release Date: 7/18/2006
  



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

svn commit: r423548 - /tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java

[fhanik]

Author: fhanik
Date: Wed Jul 19 11:03:23 2006
New Revision: 423548

URL: http://svn.apache.org/viewvc?rev=423548&view=rev
Log:
Adjusted comment

Modified:
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java?rev=423548&r1=423547&r2=423548&view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java 
Wed Jul 19 11:03:23 2006
@@ -1048,7 +1048,8 @@
 if ( key != null ) {
 NioEndpoint.KeyAttachment attach = (NioEndpoint.KeyAttachment) 
key.attachment();
 if ( attach!=null && attach.getComet()) {
-//we need to recycle
+//if this is a comet connection
+//then execute the connection closure at the next selector 
loop
 
request.getAttributes().remove("org.apache.tomcat.comet.timeout");
 attach.setError(true);
 }



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

Re: SVN propset branch for tc6

[Yoav Shapira]

Hi,
+1.  Why wouldn't we want native line endings?

Yoav

On 7/19/06, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote:

I would support this effort, I've been nailed a few times by line
endings and them being inconsistent.
there are so many files in SVN for TC right now that have windows line
endings.

Filip

Costin Manolache wrote:
> On 7/19/06, Mladen Turk <[EMAIL PROTECTED]> wrote:
>>
>> Hi,
>>
>> I have created a branch that shows the difference between
>> current trunk and the new one wit correctly set
>> svn:eol-style and svn:executable
>>
>> For example the
>> java/org/apache/catalina/Context.java when checked
>> out on linux has DOS line endings with those ugly ^M.
>> The same file with svn:eol-style native from the
>> svn_props branch is perfect both on linux and windoze.
>>
>> Any objections I apply that to the trunk?
>> Remy said -1, but I hope he changes his mind :)
>
>
> -1 for what reason ?
>
> Please get rid of the ugly CRLF !
>
> Costin
>
>
>
> In any case I'll delete the branch after 24 hrs.
>>
>> Here is the script I used for that:
>> (name it to svnprops.bat)
>>
>> @echo off
>> if "%OS%" == "Windows_NT" setlocal
>>
>> if "%1" == "" (
>> set SCRIPT_NAME=%~f0
>> ) else (
>> set SCRIPT_NAME=%~f1
>> )
>>
>> for /D %%i in (*) do (
>> cd %%i
>> svn propset svn:eol-style native *.java
>> svn propset svn:eol-style native *.properties
>> svn propset svn:eol-style native *.xml
>> svn propset svn:eol-style native *.html
>> svn propset svn:eol-style native *.txt
>> svn propset svn:eol-style native *.java
>> svn propset svn:eol-style native *.sh
>> svn propset svn:eol-style native *.bat
>> svn propset svn:executable *.sh
>> svn propset svn:executable *.bat
>> svn propset svn:executable *.exe
>> svn propset svn:mime-type image/gif *.gif
>> svn propset svn:mime-type image/jpeg *.jpg
>>
>> call %SCRIPT_NAME% %SCRIPT_NAME%
>> cd ..
>> )
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
> 
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.394 / Virus Database: 268.10.1/391 - Release Date: 7/18/2006
>


-
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: r423569 - /tomcat/container/tc5.5.x/modules/groupcom/to-do.txt

[fhanik]

Author: fhanik
Date: Wed Jul 19 12:06:24 2006
New Revision: 423569

URL: http://svn.apache.org/viewvc?rev=423569&view=rev
Log:
added bug to do

Modified:
tomcat/container/tc5.5.x/modules/groupcom/to-do.txt

Modified: tomcat/container/tc5.5.x/modules/groupcom/to-do.txt
URL: 
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/modules/groupcom/to-do.txt?rev=423569&r1=423568&r2=423569&view=diff
==
--- tomcat/container/tc5.5.x/modules/groupcom/to-do.txt (original)
+++ tomcat/container/tc5.5.x/modules/groupcom/to-do.txt Wed Jul 19 12:06:24 2006
@@ -38,6 +38,9 @@
  a) Somehow the first NIO connection made, always closes down, why
 
  b) pull the network cord and watch the membership layer freak out
+ 
+ c) AbstractReplicatedMap.size() throws ConcurrentModificationException,
+implement a size counter instead
 
 Code Tasks:
 ===



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

Re: mod_jk 1.2.17+ Recover time

[David Rees]

On 7/19/06, Mladen Turk <[EMAIL PROTECTED]> wrote:


Committed a fix that allows to have a
worker.name.recover_time lower then 60 seconds.
Previously the minimum value was 60 seconds, and
now is 1 second.
The default is still the same (60 seconds)


Thanks that should work around my issue quite nicely. I'll check out
SVN and give a whirl (unless a new tag is to be rolled again shortly?)

-Dave

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

Re: mod_jk 1.2.17+ Recover time

[David Rees]

On 7/19/06, Rainer Jung <[EMAIL PROTECTED]> wrote:

No, I think it's not:

1) This is not a regression, it was always implemented like that.


Really? I know it's been like this for a few releases now, but I
remember some very old versions of mod_jk (from a couple years ago?)
used to recover nearly instantly when Tomcat became available again.
So it may not be a new regression, but at one time it did seem to work
as I expected...


3) A worker that goes into error state is something
serious/heavy-weight. Timeouts leading to error state should not be
chosen to small, so that workers go into errors just because of regular
long running requests.


True, but the ping/pong feature avoids this problem quite nicely.


4) Recovering a worker is not something lightweight, because a stuck
tomcat might mean, that every recovery times out at full length.
Remember: we are doing recovery with real requests. I think it's not a
good idea to try recovering with real requests very often. That's the
reason for only trying to recover rarely.


But when all your workers are down, what is the harm in trying to
recover more quicky? If you have at least one good worker available,
then yes, I see no point in trying to rush recovery, but if none are
available...

-Dave

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

Re: mod_jk 1.2.17+ Recover time

[Jean-frederic Clere]

David Rees wrote:


On 7/19/06, Rainer Jung <[EMAIL PROTECTED]> wrote:


No, I think it's not:

1) This is not a regression, it was always implemented like that.



Really? I know it's been like this for a few releases now, but I
remember some very old versions of mod_jk (from a couple years ago?)
used to recover nearly instantly when Tomcat became available again.
So it may not be a new regression, but at one time it did seem to work
as I expected...


3) A worker that goes into error state is something
serious/heavy-weight. Timeouts leading to error state should not be
chosen to small, so that workers go into errors just because of regular
long running requests.



True, but the ping/pong feature avoids this problem quite nicely.


4) Recovering a worker is not something lightweight, because a stuck
tomcat might mean, that every recovery times out at full length.
Remember: we are doing recovery with real requests. I think it's not a
good idea to try recovering with real requests very often. That's the
reason for only trying to recover rarely.



But when all your workers are down, what is the harm in trying to
recover more quicky?


Because the TC on the other side is probably busy and you may  cause a 
huge increase of threads (X2)... And that will not help for the  recovery.


Cheers

Jean-Frederic


If you have at least one good worker available,
then yes, I see no point in trying to rush recovery, but if none are
available...

-Dave

-
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: mod_jk 1.2.17+ Recover time

[David Rees]

On 7/19/06, Jean-frederic Clere <[EMAIL PROTECTED]> wrote:

> But when all your workers are down, what is the harm in trying to
> recover more quicky?

Because the TC on the other side is probably busy and you may  cause a
huge increase of threads (X2)... And that will not help for the  recovery.


Like I mentioned earlier, using the ping/pong feature nearly
completely works around any issues with Apache processes/threads
getting stuck waiting for Tomcat to recover.

-Dave

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

Re: mod_jk 1.2.17+ Recover time

[David Rees]

On 7/19/06, Mladen Turk <[EMAIL PROTECTED]> wrote:

Committed a fix that allows to have a
worker.name.recover_time lower then 60 seconds.
Previously the minimum value was 60 seconds, and
now is 1 second.
The default is still the same (60 seconds)


While the change you made allows you to configure the worker to a
recover_time lower than 60 seconds, it doesn't let you change it to a
value lower than 60 using the status worker.

Still investigating, but it looks like there are a number of other
places it should be changed.

-Dave

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

svn commit: r423621 - /tomcat/connectors/trunk/jk/native/common/jk_status.c

[rjung]

Author: rjung
Date: Wed Jul 19 14:45:45 2006
New Revision: 423621

URL: http://svn.apache.org/viewvc?rev=423621&view=rev
Log:
Part two of: allow recovery interval below 60 seconds.
Caution: This fix for the status worker is still not complete,
since we need to be able to set the maintain time also.

Modified:
tomcat/connectors/trunk/jk/native/common/jk_status.c

Modified: tomcat/connectors/trunk/jk/native/common/jk_status.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_status.c?rev=423621&r1=423620&r2=423621&view=diff
==
--- tomcat/connectors/trunk/jk/native/common/jk_status.c (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_status.c Wed Jul 19 14:45:45 
2006
@@ -710,8 +710,9 @@
 if (i > 0)
 lb->s->retries = i;
 i = status_int("lt", s->query_string, lb->s->recover_wait_time);
-if (i > 59)
-lb->s->recover_wait_time = i;
+if (i < 1)
+i = 1;
+lb->s->recover_wait_time = i;
 lb->s->sticky_session = status_bool("ls", s->query_string);
 lb->s->sticky_session_force = status_bool("lf", s->query_string);
 }



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

svn commit: r423675 - in /tomcat/connectors/trunk/jk: conf/ native/ native/common/ native/iis/ tools/ xdocs/ xdocs/config/ xdocs/howto/ xdocs/news/

[rjung]

Author: rjung
Date: Wed Jul 19 17:15:01 2006
New Revision: 423675

URL: http://svn.apache.org/viewvc?rev=423675&view=rev
Log:
Preparing 1.2.18:
- increment version
- changelog
- added back doc for deprecated directives
- some doc for recover_time, added a few lines to worker.maintain
- replaced the deprecated directives in the default config
  (which is still very broken)
- changed directory structure in src-tarball (moved everything in jk/
  one directory up.

Modified:
tomcat/connectors/trunk/jk/conf/workers.properties
tomcat/connectors/trunk/jk/native/STATUS.txt
tomcat/connectors/trunk/jk/native/common/portable.h.sample
tomcat/connectors/trunk/jk/native/configure.in
tomcat/connectors/trunk/jk/native/iis/isapi_redirect.rc
tomcat/connectors/trunk/jk/tools/jkrelease.sh
tomcat/connectors/trunk/jk/xdocs/changelog.xml
tomcat/connectors/trunk/jk/xdocs/config/workers.xml
tomcat/connectors/trunk/jk/xdocs/howto/workers.xml
tomcat/connectors/trunk/jk/xdocs/index.xml
tomcat/connectors/trunk/jk/xdocs/news/20060101.xml

Modified: tomcat/connectors/trunk/jk/conf/workers.properties
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/conf/workers.properties?rev=423675&r1=423674&r2=423675&view=diff
==
--- tomcat/connectors/trunk/jk/conf/workers.properties (original)
+++ tomcat/connectors/trunk/jk/conf/workers.properties Wed Jul 19 17:15:01 2006
@@ -110,8 +110,8 @@
 worker.ajp13.lbfactor=1
 
 #
-# Specify the size of the open connection cache.
-#worker.ajp13.cachesize
+# Specify the size of the open connection pool.
+#worker.ajp13.connection_pool_size
 
 #
 #-- DEFAULT LOAD BALANCER WORKER DEFINITION --

Modified: tomcat/connectors/trunk/jk/native/STATUS.txt
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/STATUS.txt?rev=423675&r1=423674&r2=423675&view=diff
==
--- tomcat/connectors/trunk/jk/native/STATUS.txt (original)
+++ tomcat/connectors/trunk/jk/native/STATUS.txt Wed Jul 19 17:15:01 2006
@@ -3,8 +3,9 @@
 
 Release:
 
-1.2.18  : in development
-1.2.17  : released July, 2006
+1.2.19  : in development
+1.2.18  : released July, 2006
+1.2.17  : not released
 1.2.16  : not released
 1.2.15  : released November 8, 2005
 1.2.14  : released July 13, 2005

Modified: tomcat/connectors/trunk/jk/native/common/portable.h.sample
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/portable.h.sample?rev=423675&r1=423674&r2=423675&view=diff
==
--- tomcat/connectors/trunk/jk/native/common/portable.h.sample (original)
+++ tomcat/connectors/trunk/jk/native/common/portable.h.sample Wed Jul 19 
17:15:01 2006
@@ -90,4 +90,4 @@
 #define USE_SO_SNDTIMEO 1
 
 /* Version number of package */
-#define VERSION "1.2.17"
+#define VERSION "1.2.18"

Modified: tomcat/connectors/trunk/jk/native/configure.in
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/configure.in?rev=423675&r1=423674&r2=423675&view=diff
==
--- tomcat/connectors/trunk/jk/native/configure.in (original)
+++ tomcat/connectors/trunk/jk/native/configure.in Wed Jul 19 17:15:01 2006
@@ -11,7 +11,7 @@
 
 dnl package and version. (synchronization with common/jk_version.h ?)
 PACKAGE=mod_jk
-VERSION=1.2.17
+VERSION=1.2.18
 
 AM_INIT_AUTOMAKE(${PACKAGE}, ${VERSION})
 

Modified: tomcat/connectors/trunk/jk/native/iis/isapi_redirect.rc
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/iis/isapi_redirect.rc?rev=423675&r1=423674&r2=423675&view=diff
==
--- tomcat/connectors/trunk/jk/native/iis/isapi_redirect.rc (original)
+++ tomcat/connectors/trunk/jk/native/iis/isapi_redirect.rc Wed Jul 19 17:15:01 
2006
@@ -14,13 +14,13 @@
 "specific language governing permissions and " \
 "limitations under the License."
 
-#define JK_VERSION_STR  "1.2.17"
+#define JK_VERSION_STR  "1.2.18"
 #define JK_DLL_BASENAME "isapi_redirect-" JK_VERSION_STR
 
 
 1 VERSIONINFO
- FILEVERSION 1,2,17,0
- PRODUCTVERSION 1,2,17,0
+ FILEVERSION 1,2,18,0
+ PRODUCTVERSION 1,2,18,0
  FILEFLAGSMASK 0x3fL
 #if defined(_DEBUG)
  FILEFLAGS 0x01L

Modified: tomcat/connectors/trunk/jk/tools/jkrelease.sh
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/tools/jkrelease.sh?rev=423675&r1=423674&r2=423675&view=diff
==
--- tomcat/connectors/trunk/jk/tools/jkrelease.sh (original)
+++ tomcat/connectors/trunk/jk/tools/jkrelease.sh Wed Jul 19 17:15:01 2006
@@ -16,7 +16,7 @@
 # You need to change the version numbers
 JK_VERMAJOR="1"
 JK_VERMINOR="2"
-JK_VERFIX

svn commit: r423683 - /tomcat/connectors/tags/jk1.2.x/JK_1_2_18/

[rjung]

Author: rjung
Date: Wed Jul 19 17:37:08 2006
New Revision: 423683

URL: http://svn.apache.org/viewvc?rev=423683&view=rev
Log:
Tagging tomcat-connectors 1.2.18.

Added:
tomcat/connectors/tags/jk1.2.x/JK_1_2_18/
  - copied from r423681, tomcat/connectors/trunk/


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

svn commit: r423695 - /tomcat/connectors/tags/jk1.2.x/JK_1_2_18/

[rjung]

Author: rjung
Date: Wed Jul 19 18:24:27 2006
New Revision: 423695

URL: http://svn.apache.org/viewvc?rev=423695&view=rev
Log:
Revert the tag, nothing yet published.
There's still a 1.2.17 in the files (iis installer).

Removed:
tomcat/connectors/tags/jk1.2.x/JK_1_2_18/


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

svn commit: r423697 - /tomcat/connectors/trunk/jk/native/iis/installer/isapi-redirector-win32-msi.ism

[rjung]

Author: rjung
Date: Wed Jul 19 18:25:33 2006
New Revision: 423697

URL: http://svn.apache.org/viewvc?rev=423697&view=rev
Log:
Yet another version number to increment.

Modified:

tomcat/connectors/trunk/jk/native/iis/installer/isapi-redirector-win32-msi.ism

Modified: 
tomcat/connectors/trunk/jk/native/iis/installer/isapi-redirector-win32-msi.ism
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/iis/installer/isapi-redirector-win32-msi.ism?rev=423697&r1=423696&r2=423697&view=diff
==
--- 
tomcat/connectors/trunk/jk/native/iis/installer/isapi-redirector-win32-msi.ism 
(original)
+++ 
tomcat/connectors/trunk/jk/native/iis/installer/isapi-redirector-win32-msi.ism 
Wed Jul 19 18:25:33 2006
@@ -3288,7 +3288,7 @@
ProductIDnone
ProductLanguage1033
ProductNameJakarta Isapi 
Redirector
-   ProductVersion1.2.17
+   ProductVersion1.2.18
ProgressType0install
ProgressType1Installing
ProgressType2installed



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

svn commit: r423699 - /tomcat/connectors/tags/jk1.2.x/JK_1_2_18/

[rjung]

Author: rjung
Date: Wed Jul 19 18:27:25 2006
New Revision: 423699

URL: http://svn.apache.org/viewvc?rev=423699&view=rev
Log:
Tagging tomcat-connectors 1.2.18.

Added:
tomcat/connectors/tags/jk1.2.x/JK_1_2_18/
  - copied from r423697, tomcat/connectors/trunk/


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

Re: mod_jk 1.2.17+ Recover time

[Rainer Jung]

David Rees wrote:

While the change you made allows you to configure the worker to a
recover_time lower than 60 seconds, it doesn't let you change it to a
value lower than 60 using the status worker.

Still investigating, but it looks like there are a number of other
places it should be changed.


Done.

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

Re: mod_jk 1.2.17+ Recover time

[Rainer Jung]

David Rees wrote:

Thanks that should work around my issue quite nicely. I'll check out
SVN and give a whirl (unless a new tag is to be rolled again shortly?)


Try 1.2.18.

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

Yet another try: mod_jk 1.2.18 release candidate ready to test

[Rainer Jung]

Hi,

thanks to everyone who tested 1.2.17. We had one bug related to special 
types used in the networking code. Furthermore there was one request for 
enhancement we included in the next version 1.2.18.


Today this version 1.2.18 of the Apache Tomcat mod_jk web server 
connector has been tagged. This version fixes the found bugs from 
1.2.17. Please test and share your experience.


If no critical bugs will be found, we will have a formal release vote
starting at Monday, July 24th.

The source distribution can be downloaded from:

http://tomcat.apache.org/dev/dist/

The updated documentation can be found at

http://tomcat.apache.org/dev/docs/tomcat-connectors-1.2.18/

Please see

http://tomcat.apache.org/dev/docs/tomcat-connectors-1.2.18/changelog.html

for a complete list of changes.

Regards,

Rainer

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

DO NOT REPLY [Bug 40072] - New Session Created Randomly in Tomcat 5.0.28

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





--- Additional Comments From [EMAIL PROTECTED]  2006-07-20 06:25 ---
(In reply to comment #1)
> by default jsp's create a session. Its part of the spec.
> 
> See <%@ page session='false'%> in the JSP spec for disabling that.

  After Login, some information is kept in the session and is used through out
the application. If the JSP is creating a new session by default, i will lose
all the data. 
  I am facing the session problem while accessing a JSP with heavy JavaScript
Code. In rest of the JSP's with the application, new session is not getting 
created.


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