Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java

2004-02-03 Thread Remy Maucherat
[EMAIL PROTECTED] wrote:
luehe   2004/02/02 15:08:29

  Modified:util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
  Log:
  Expose handshake failure as error, so it gets logged unconditionally
-1. Unlike what occurs for normal sockets, errors at this point are 
rather common, because the process is fairly long. So this was done on 
purpose to minimise the amount of logging.

Rémy

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


Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java

2004-01-13 Thread Remy Maucherat
   		if( usePool ) {
   			con=(TcpConnection)connectionCache.get();
   			if( con == null ) 
I would like to remove this pool thing. It is dead code (there's a 
static final flag to enable it at compile time), so I think it should go.

Rémy

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


Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java

2003-11-25 Thread Remy Maucherat
[EMAIL PROTECTED] wrote:
amyroh  2003/11/24 15:01:22

  Modified:http11/src/java/org/apache/coyote/http11 Http11Protocol.java
   util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
  Log:
  Add getters for all attributes defined in MBeanInfo so getAttribute calls suceed.
Doing this is not good: these are attributes of the thread pool, not of 
the protocol. I believe each one has its MBean, so there's no problem.

I will not integrate your last two patches in my 5.0.15 tag.

Rémy

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


Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java

2003-11-25 Thread Remy Maucherat
[EMAIL PROTECTED] wrote:
amyroh  2003/11/24 15:01:22

  Modified:http11/src/java/org/apache/coyote/http11 Http11Protocol.java
   util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
  Log:
  Add getters for all attributes defined in MBeanInfo so getAttribute calls suceed.
Rectification: I'll integrate your patch, but it would be best to remove 
the fields which are duplicated with the thread pool MBean.

Rémy



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


Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java

2003-11-25 Thread Bill Barker

- Original Message -
From: Remy Maucherat [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Tuesday, November 25, 2003 12:27 AM
Subject: Re: cvs commit:
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net
PoolTcpEndpoint.java


 [EMAIL PROTECTED] wrote:
  amyroh  2003/11/24 15:01:22
 
Modified:http11/src/java/org/apache/coyote/http11
Http11Protocol.java
 util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
Log:
Add getters for all attributes defined in MBeanInfo so getAttribute
calls suceed.

 Rectification: I'll integrate your patch, but it would be best to remove
 the fields which are duplicated with the thread pool MBean.


+1.  While I'm totally swamped right now to be able to properly review Amy's
original patch, the Endpoint is not the place for doing this type of JMX
configs.

 Rémy



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



This message is intended only for the use of the person(s) listed above as the 
intended recipient(s), and may contain information that is PRIVILEGED and 
CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or 
distribute this message or any attachment. If you received this communication in 
error, please notify us immediately by e-mail and then delete all copies of this 
message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through the 
Internet is not secure. Do not send confidential or sensitive information, such as 
social security numbers, account numbers, personal identification numbers and 
passwords, to us via ordinary (unencrypted) e-mail.

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

Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java

2003-11-25 Thread Amy Roh
- Original Message -
From: Remy Maucherat [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Tuesday, November 25, 2003 12:27 AM
Subject: Re: cvs commit:
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net
PoolTcpEndpoint.java


 [EMAIL PROTECTED] wrote:
  amyroh  2003/11/24 15:01:22
 
Modified:http11/src/java/org/apache/coyote/http11
Http11Protocol.java
 util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
Log:
Add getters for all attributes defined in MBeanInfo so getAttribute
calls suceed.

 Rectification: I'll integrate your patch, but it would be best to remove
 the fields which are duplicated with the thread pool MBean.

Question...  How are the attributes for these MBeans in j-t-c get generated?
I don't see descriptor files.  It seems if you have setters, the
correspondent attributes get automatically added to MBeanInfo.  And you get
an error trying to getAttribute on the attribute which is included in
MBeanInfo because it's missing getter methods.

Thanks,
Amy

 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]



Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java

2003-11-01 Thread Remy Maucherat
Bill Barker wrote:
Jan Luehe [EMAIL PROTECTED] wrote in message

Remy,

I think we should make any maxThreads setting work, as my patch
attempts to do, and update the documentation to make users aware of
the limitations they will run into when picking a low maxThreads.
I think that would be the cleanest solution.
The rationale is that there's no point adding complexity and checks into
the very critical algorithm, simply to be able to support broken cases.
I think we have 2 options:
1. Support any maxThreads setting (including 1, 2, etc.).
2. Reject any maxThreads values that are smaller than some
   threshold and throw an error.
The problem with 2. is that picking a value for the threshold (10? 20?)
seems
rather arbitrary. Therefore, I think we should do 1. The complexity it
is adding is not significant and is well-documented.
Please tell me you agree. :)
Well, I don't agree :).  There is no reason to accept a config value that
won't work, and it is cheaper and safer to handle in the config code then in
the critical runtime code (although, in this particular case, I admit that
the perfomance hit should be minimal).  Personally, I would be perfectly
happy with an enforced min setting of '2' (but Remy's suggestion is much
more practical, given that TC 5 does so much hand-holding already :).  As
long as the override is logged at WARN level, I don't see any problem with
enforcing a minimum.
I agree with Bill.
Hand holding is good :)
Remy

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


Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java

2003-11-01 Thread Tim Funk
Could a simple compromise be
- Die (with error message) if  2
- Warn if less than 10 (or ??). Letting the user be stupid, but warn them 
about it.

-Tim

Bill Barker wrote:

Jan Luehe [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Remy,


I agree we should help users come up with reasonable config values,
but I'm just afraid rejecting any maxThreads  10 or  20 will send the
wrong message, as if there was a bug in the way we dispatch incoming
requests that requires at least 10 threads.



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


Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java

2003-11-01 Thread Remy Maucherat
Tim Funk wrote:
Could a simple compromise be
- Die (with error message) if  2
- Warn if less than 10 (or ??). Letting the user be stupid, but warn 
them about it.
I don't agree with that behavior. Why should we fail or (worse) allow 
bad values ? Good defaults and being tolerant is a quality of good software.

Remy



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


Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java

2003-11-01 Thread Sriram N
+1 on that.

I'd rather that TC defaulted to safe values over my idotically low or even
absent settings.

-- Sriram

--- Remy Maucherat [EMAIL PROTECTED] wrote:
 Tim Funk wrote:
  Could a simple compromise be
  - Die (with error message) if  2
  - Warn if less than 10 (or ??). Letting the user be stupid, but warn 
  them about it.
 
 I don't agree with that behavior. Why should we fail or (worse) allow 
 bad values ? Good defaults and being tolerant is a quality of good software.
 
 Remy
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


__
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/

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



Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java

2003-10-31 Thread Remy Maucherat
Jan Luehe wrote:
Remy Maucherat wrote:
I guess I don't understand what makes 1 bad but 2 OK. Where do we 
draw the line of what is a stupid config?
Yes, definitely, 2 is nearly as stupid as 1. We need a reasonable 
minimal value for maxThreads; let's say 10 - 20.

Remy



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


Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java

2003-10-31 Thread Jan Luehe
Remy Maucherat wrote:
Jan Luehe wrote:

Remy Maucherat wrote:
I guess I don't understand what makes 1 bad but 2 OK. Where do we 
draw the line of what is a stupid config?


Yes, definitely, 2 is nearly as stupid as 1. We need a reasonable 
minimal value for maxThreads; let's say 10 - 20.
Remy,

I agree we should help users come up with reasonable config values,
but I'm just afraid rejecting any maxThreads  10 or  20 will send the
wrong message, as if there was a bug in the way we dispatch incoming
requests that requires at least 10 threads.
I think we should make any maxThreads setting work, as my patch
attempts to do, and update the documentation to make users aware of
the limitations they will run into when picking a low maxThreads.
I think that would be the cleanest solution.
Jan

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


Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java

2003-10-31 Thread Remy Maucherat
Jan Luehe wrote:
I agree we should help users come up with reasonable config values,
but I'm just afraid rejecting any maxThreads  10 or  20 will send the
wrong message, as if there was a bug in the way we dispatch incoming
requests that requires at least 10 threads.
Nope, I disagree. If maxThreads  (say) 10, then set it to 10. Allowing 
broken settings is bad, as there will be people out there who will use 
them, and then will assume Tomcat is broken.

I think we should make any maxThreads setting work, as my patch
attempts to do, and update the documentation to make users aware of
the limitations they will run into when picking a low maxThreads.
I think that would be the cleanest solution.
The rationale is that there's no point adding complexity and checks into 
the very critical algorithm, simply to be able to support broken cases.

Rémy



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


Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java

2003-10-31 Thread Jan Luehe
Remy,

I agree we should help users come up with reasonable config values,
but I'm just afraid rejecting any maxThreads  10 or  20 will send the
wrong message, as if there was a bug in the way we dispatch incoming
requests that requires at least 10 threads.


Nope, I disagree. If maxThreads  (say) 10, then set it to 10. Allowing 
broken settings is bad, as there will be people out there who will use 
them, and then will assume Tomcat is broken.
I think changing people's config values behind their backs is not such
a good idea in general.
I think we should make any maxThreads setting work, as my patch
attempts to do, and update the documentation to make users aware of
the limitations they will run into when picking a low maxThreads.
I think that would be the cleanest solution.


The rationale is that there's no point adding complexity and checks into 
the very critical algorithm, simply to be able to support broken cases.
I think we have 2 options:
1. Support any maxThreads setting (including 1, 2, etc.).
2. Reject any maxThreads values that are smaller than some
   threshold and throw an error.
The problem with 2. is that picking a value for the threshold (10? 20?) 
seems
rather arbitrary. Therefore, I think we should do 1. The complexity it 
is adding is not significant and is well-documented.

Please tell me you agree. :)

Jan

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


Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java

2003-10-31 Thread Bill Barker

Jan Luehe [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
 Remy,

  I agree we should help users come up with reasonable config values,
  but I'm just afraid rejecting any maxThreads  10 or  20 will send the
  wrong message, as if there was a bug in the way we dispatch incoming
  requests that requires at least 10 threads.
 
 
  Nope, I disagree. If maxThreads  (say) 10, then set it to 10. Allowing
  broken settings is bad, as there will be people out there who will use
  them, and then will assume Tomcat is broken.

 I think changing people's config values behind their backs is not such
 a good idea in general.

  I think we should make any maxThreads setting work, as my patch
  attempts to do, and update the documentation to make users aware of
  the limitations they will run into when picking a low maxThreads.
  I think that would be the cleanest solution.
 
 
  The rationale is that there's no point adding complexity and checks into
  the very critical algorithm, simply to be able to support broken cases.

 I think we have 2 options:
 1. Support any maxThreads setting (including 1, 2, etc.).
 2. Reject any maxThreads values that are smaller than some
 threshold and throw an error.

 The problem with 2. is that picking a value for the threshold (10? 20?)
 seems
 rather arbitrary. Therefore, I think we should do 1. The complexity it
 is adding is not significant and is well-documented.

 Please tell me you agree. :)


Well, I don't agree :).  There is no reason to accept a config value that
won't work, and it is cheaper and safer to handle in the config code then in
the critical runtime code (although, in this particular case, I admit that
the perfomance hit should be minimal).  Personally, I would be perfectly
happy with an enforced min setting of '2' (but Remy's suggestion is much
more practical, given that TC 5 does so much hand-holding already :).  As
long as the override is logged at WARN level, I don't see any problem with
enforcing a minimum.

I'm still -1 on this patch at heart, but I could be talked down to an
official -0 if enough of the rest of the community thinks that it is useful.

 Jan




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



Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java

2003-10-30 Thread Remy Maucherat
[EMAIL PROTECTED] wrote:

luehe   2003/10/30 13:01:39

  Modified:util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
  Log:
  Fixed problem where if maxThreads is set to 1,
  ThreadPool.findControlRunnable() will log this error on the first
  request:
  
SEVERE: All threads (1) are currently busy, waiting. Increase
maxThreads (1) or check the servlet status
  
  and then block forever
-1 for this patch.
1 is obviously a stupid configuration value, so the pool should refuse it.
Remy



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


Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java

2003-10-30 Thread Bill Barker

- Original Message -
From: Remy Maucherat [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Thursday, October 30, 2003 1:45 PM
Subject: Re: cvs commit:
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net
PoolTcpEndpoint.java


 [EMAIL PROTECTED] wrote:

  luehe   2003/10/30 13:01:39
 
Modified:util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
Log:
Fixed problem where if maxThreads is set to 1,
ThreadPool.findControlRunnable() will log this error on the first
request:
 
  SEVERE: All threads (1) are currently busy, waiting. Increase
  maxThreads (1) or check the servlet status
 
and then block forever

 -1 for this patch.
 1 is obviously a stupid configuration value, so the pool should refuse it.


I agree with Remy:  The place to check this is ThreadPool.


 Remy



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



This message is intended only for the use of the person(s) listed above as the 
intended recipient(s), and may contain information that is PRIVILEGED and 
CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or 
distribute this message or any attachment. If you received this communication in 
error, please notify us immediately by e-mail and then delete all copies of this 
message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through the 
Internet is not secure. Do not send confidential or sensitive information, such as 
social security numbers, account numbers, personal identification numbers and 
passwords, to us via ordinary (unencrypted) e-mail.

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

Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java

2003-10-30 Thread Remy Maucherat
Bill Barker wrote:
[EMAIL PROTECTED] wrote:


luehe   2003/10/30 13:01:39

 Modified:util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
 Log:
 Fixed problem where if maxThreads is set to 1,
 ThreadPool.findControlRunnable() will log this error on the first
 request:
   SEVERE: All threads (1) are currently busy, waiting. Increase
   maxThreads (1) or check the servlet status
 and then block forever
-1 for this patch.
1 is obviously a stupid configuration value, so the pool should refuse it.
I agree with Remy:  The place to check this is ThreadPool.
I'd like to add that my -1 is not because the patch is bad (the revised 
algorithm seems ok), but because the 1 value doesn't make sense, so I 
don't think there's a point adding a special case for it.

Remy



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


Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java

2003-10-30 Thread Jan Luehe
Remy Maucherat wrote:
Bill Barker wrote:

[EMAIL PROTECTED] wrote:


luehe   2003/10/30 13:01:39

 Modified:util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
 Log:
 Fixed problem where if maxThreads is set to 1,
 ThreadPool.findControlRunnable() will log this error on the first
 request:
   SEVERE: All threads (1) are currently busy, waiting. Increase
   maxThreads (1) or check the servlet status
 and then block forever


-1 for this patch.
1 is obviously a stupid configuration value, so the pool should 
refuse it.


I agree with Remy:  The place to check this is ThreadPool.


I'd like to add that my -1 is not because the patch is bad (the revised 
algorithm seems ok), but because the 1 value doesn't make sense, so I 
don't think there's a point adding a special case for it.
I guess I don't understand what makes 1 bad but 2 OK. Where do we 
draw the line of what is a stupid config?

Jan



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


Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java

2003-10-22 Thread Remy Maucherat
[EMAIL PROTECTED] wrote:

glenn   2003/10/22 06:46:28

  Modified:util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
  Log:
  SocketExceptions can occur in a networked app.
  No need to log a stack trace, just log the remote host
  name/ip and the exception message. Then there is less
  cruft in the logs.
I'd like more details :)
With HTTP/1.1, an exception can only occur while setting the socket 
options. I don't consider that very normal, though. What was your 
motivation for the change ? Did you see many logs coming out of here ?

Remy



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


Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java

2003-10-22 Thread Glenn Nielsen
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:

glenn   2003/10/22 06:46:28

  Modified:util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
  Log:
  SocketExceptions can occur in a networked app.
  No need to log a stack trace, just log the remote host
  name/ip and the exception message. Then there is less
  cruft in the logs.


I'd like more details :)
With HTTP/1.1, an exception can only occur while setting the socket 
options. I don't consider that very normal, though. What was your 
motivation for the change ? Did you see many logs coming out of here ?

Yes, that is where I saw the Exception:

[ERROR] PoolTcpEndpoint - -Unexpected error java.net.SocketException: Socket 
closedjava.net.SocketException: Socket close
d
at java.net.PlainSocketImpl.socketSetOption(Native Method)
at java.net.PlainSocketImpl.setOption(PlainSocketImpl.java:187)
at java.net.Socket.setTcpNoDelay(Socket.java:372)
at 
com.sun.net.ssl.internal.ssl.SSLSocketImpl.setTcpNoDelay([DashoPro-V1.2-120198])
at 
org.apache.tomcat.util.net.PoolTcpEndpoint.setSocketOptions(PoolTcpEndpoint.java:495)
at 
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:587)
at 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:666)
at java.lang.Thread.run(Thread.java:479)

This was due to simple external system monitoring that would periodically
connect to the Coyote port to verify that the port was accepting connections,
then immediately disconnect.  So the stack trace would end up in the logs
each time the system monitoring did its checks.  In this case the Coyote
connector implemented SSL so there was no easy way to get the system
monitoring software to do an actual HTTPS negotiation with it.
Regards,

Glenn

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java

2003-10-04 Thread Bill Barker

- Original Message - 
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, October 04, 2003 11:05 AM
Subject: cvs commit:
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net
PoolTcpEndpoint.java


 remm2003/10/04 11:05:29

   Modified:util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
   Log:
   - No bug fix !
   - Use the appropriate exception for killing the thread,
   - Improve ifs.
   - Replace while + break with a simpler (IMO) if.
   - Please let me know ASAP if there's a problem.

+1 for the patch.  But you still need to recycle the connection if the
ServerSocket is re-started.


This message is intended only for the use of the person(s) listed above as the 
intended recipient(s), and may contain information that is PRIVILEGED and 
CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or 
distribute this message or any attachment. If you received this communication in 
error, please notify us immediately by e-mail and then delete all copies of this 
message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through the 
Internet is not secure. Do not send confidential or sensitive information, such as 
social security numbers, account numbers, personal identification numbers and 
passwords, to us via ordinary (unencrypted) e-mail.

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

Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java

2003-10-04 Thread Bill Barker

- Original Message - 
From: Bill Barker [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Saturday, October 04, 2003 3:10 PM
Subject: Re: cvs commit:
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net
PoolTcpEndpoint.java



 - Original Message - 
 From: [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Saturday, October 04, 2003 11:05 AM
 Subject: cvs commit:
 jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net
 PoolTcpEndpoint.java


  remm2003/10/04 11:05:29
 
Modified:util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
Log:
- No bug fix !
- Use the appropriate exception for killing the thread,
- Improve ifs.
- Replace while + break with a simpler (IMO) if.
- Please let me know ASAP if there's a problem.

 +1 for the patch.  But you still need to recycle the connection if the
 ServerSocket is re-started.


Never mind. I'm blind today.









 This message is intended only for the use of the person(s) listed above as
the intended recipient(s), and may contain information that is PRIVILEGED
and CONFIDENTIAL.  If you are not an intended recipient, you may not read,
copy, or distribute this message or any attachment. If you received this
communication in error, please notify us immediately by e-mail and then
delete all copies of this message and any attachments.

 In addition you should be aware that ordinary (unencrypted) e-mail sent
through the Internet is not secure. Do not send confidential or sensitive
information, such as social security numbers, account numbers, personal
identification numbers and passwords, to us via ordinary (unencrypted)
e-mail.








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


This message is intended only for the use of the person(s) listed above as the 
intended recipient(s), and may contain information that is PRIVILEGED and 
CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or 
distribute this message or any attachment. If you received this communication in 
error, please notify us immediately by e-mail and then delete all copies of this 
message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through the 
Internet is not secure. Do not send confidential or sensitive information, such as 
social security numbers, account numbers, personal identification numbers and 
passwords, to us via ordinary (unencrypted) e-mail.

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

Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java

2003-09-12 Thread Stefan Bodewig
On 12 Sep 2003, [EMAIL PROTECTED] wrote:

  +++ PoolTcpEndpoint.java 12 Sep 2003 03:51:36 -  1.16
  @@ -389,12 +389,12 @@
   if (accepted != null) {
   try {
   accepted.close();
  -accepted = null;
   } catch(Exception ex) {
   msg = sm.getString(endpoint.err.nonfatal,
  accepted, ex);
   log.warn(msg, ex);
   }
  +accepted = null;
   }
   
   if( ! running ) return null;

wouldn't it be better to put the accepted = null into a finally
block so you clean up even in the (unlikely but possible) case where
close throws an Error (or Throwable) instead of an Exception?

Stefan

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



Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java

2003-09-12 Thread Bill Barker

- Original Message - 
From: Stefan Bodewig [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, September 12, 2003 12:58 AM
Subject: Re: cvs commit:
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net
PoolTcpEndpoint.java


 On 12 Sep 2003, [EMAIL PROTECTED] wrote:

   +++ PoolTcpEndpoint.java 12 Sep 2003 03:51:36 - 1.16
   @@ -389,12 +389,12 @@
if (accepted != null) {
try {
accepted.close();
   -accepted = null;
} catch(Exception ex) {
msg = sm.getString(endpoint.err.nonfatal,
   accepted, ex);
log.warn(msg, ex);
}
   +accepted = null;
}
 
if( ! running ) return null;

 wouldn't it be better to put the accepted = null into a finally
 block so you clean up even in the (unlikely but possible) case where
 close throws an Error (or Throwable) instead of an Exception?


Wouldn't do anything.  The 'accepted' variable is local to the stack-frame,
so it goes away if I throw clear of the method.  In this case you just get a
DoS condition where no threads are listening on the ServerSocket.  I briefly
thought about changing the catch to 'Throwable', but is it really possible
for Socket.close to throw anything other than an Exception?


 Stefan

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


This message is intended only for the use of the person(s) listed above as the 
intended recipient(s), and may contain information that is PRIVILEGED and 
CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or 
distribute this message or any attachment. If you received this communication in 
error, please notify us immediately by e-mail and then delete all copies of this 
message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through the 
Internet is not secure. Do not send confidential or sensitive information, such as 
social security numbers, account numbers, personal identification numbers and 
passwords, to us via ordinary (unencrypted) e-mail.

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

Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java

2003-09-12 Thread Remy Maucherat
Bill Barker wrote:
On 12 Sep 2003, [EMAIL PROTECTED] wrote:


+++ PoolTcpEndpoint.java 12 Sep 2003 03:51:36 - 1.16
@@ -389,12 +389,12 @@
 if (accepted != null) {
 try {
 accepted.close();
-accepted = null;
 } catch(Exception ex) {
 msg = sm.getString(endpoint.err.nonfatal,
accepted, ex);
 log.warn(msg, ex);
 }
+accepted = null;
 }
 if( ! running ) return null;
wouldn't it be better to put the accepted = null into a finally
block so you clean up even in the (unlikely but possible) case where
close throws an Error (or Throwable) instead of an Exception?
Wouldn't do anything.  The 'accepted' variable is local to the stack-frame,
so it goes away if I throw clear of the method.  In this case you just get a
DoS condition where no threads are listening on the ServerSocket.  I briefly
thought about changing the catch to 'Throwable', but is it really possible
for Socket.close to throw anything other than an Exception?
I don't know. From traces I saw, there are conditions where there could 
be no thread listening on the socket (at that point, the connector was 
dead, of course), while everything else in the TP was looking ok 
(including no deadlock). There didn't seem to be anything in the logs 
related to an error during accept.

I'd catch throwable just to be safe, personally :)

Remy



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


Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java

2003-09-12 Thread Stefan Bodewig
On Fri, 12 Sep 2003, Bill Barker [EMAIL PROTECTED] wrote:
 From: Stefan Bodewig [EMAIL PROTECTED]

 wouldn't it be better to put the accepted = null into a finally
 block
 
 Wouldn't do anything.  The 'accepted' variable is local to the
 stack-frame, so it goes away if I throw clear of the method.

OK, thanks.  I just looked at the commit mail as I suspect that one of
our customer production systems gets bitten by the bug - I didn't look
at the complete code.  Makes sense, then.

 I briefly thought about changing the catch to 'Throwable', but is it
 really possible for Socket.close to throw anything other than an
 Exception?

Everything is possible ;-)

I have no idea what the Socket implementation does if shutdown(2) sets
errno to ENOTCONN for example (I'd guess, throw a plain
SocketException).

I don't think that non-Exceptions are too likely to happen and if they
do it probably happens in a situation where you can't recover anyway
(OutOfMemory, StackOverflow, ThreadDeath ...).  Catching Throwable may
be the savest thing to do.

Stefan

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