Re: how http connector backlog attribute works?

2013-12-30 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

侯树成,

On 12/27/13, 4:24 AM, 侯树成 wrote:
 Yes, this must use BIO mode, because the NIO maxConnections=1
 in default, it won't block the LimitLatch. In my test case,(use
 JMeter, thread number is 5), 2 requests will refused soon(just
 1s-2s later), then another 3 requests will served correctly.In
 source code, I find the backlog attribute will send to ServerSocket
 constructor, So, the backlog attribute is worked inside of JDK, not
 in Tomcat?

The backlog is technically handled in the OS kernel/TCP stack. This
page is Linux-specific, but implements a BSD standard.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSwaKaAAoJEBzwKT+lPKRYuwQP/2loOTXAeSXg15ptpUPOcRH6
8bKk/zf5bxuUCClrYSEaxiDT+RpD8yINynGZRrR+c+wVYuOBoKSSoFwpoFFgovrk
8KvNZHC6GC3/qDwDGs4t69cuiN/KBjLiSygJI/arxIoxDVbc1jKUzUsvGpBYC4Hm
FdiTddvyslQy+xR8Klw1Ak4ccTYKcZSPXDXZ/s9z8ELYlswAWq7LGRSJqdJI2BNG
Ja92dLSEQ4NTHSxfEXeWusrf51tJFqXLq1kjfALGlXdL9FC05Phc+PCXPBAbcQsW
acaUMy6ry8aqtZ3rdAdIHFSjxqHtxr5Ffehe8VmjcGXYqWBa7ez6q8zd+Ku9BDBB
NCna9X8NFRZT4J8/uJxaXiAiUvxUVEBG4uwRTMx8UebKWQNm8v25tKMHl0z0T/Jt
/YsqoTFjQ8/KniDrKaqTcn9BrQLiiTFUTI26t9e7S0V5xF2r8Pk98mkf0mCDl2+7
D7GCGAOwkOhyMFc9fQ2PGKzlKb3EjCas5+7ICRp6qFoa2NLvRls64E6iLlcAEcf1
lC86qqJbHVhE1KNAmSS0pGo/b7zTi54LkssmPzg7Z/3iJ0ugL0KbamPMfetr1HYP
9yINYpVlJK55zKgsvOz63UnUnciDJGxf9IRrgcGNZSaupPKbtj15ewqNLBr30X4F
sRcDOHUX8RdojgBljhAX
=ZYMg
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: how http connector backlog attribute works?

2013-12-29 Thread 侯树成
Hi,
Today, I find the acceptCount  of connector is not work like it's config.
You can try it like this:
Connector port=8080 protocol=HTTP/1.1
   connectionTimeout=2
   redirectPort=8443 acceptCount=2 maxThreads=1
minSpareThreads=1/

Also use LR/JMeter make more requests( 10) .  You will find that 5
requests will served correctly, others will be refused.

When the acceptCount=3
   Connector port=8080 protocol=HTTP/1.1
   connectionTimeout=2
   redirectPort=8443 acceptCount=3 maxThreads=1
minSpareThreads=1/

 You will find that 7 requests will served correctly, others will be
refused.


When the acceptCount=4
   Connector port=8080 protocol=HTTP/1.1
   connectionTimeout=2
   redirectPort=8443 acceptCount=4 maxThreads=1
minSpareThreads=1/

Also use LR/JMeter make more requests( 10) .  You will find that 9
requests will served correctly, others will be refused.

Yes, the SUCCESS requests = 2 * acceptCount + maxthead , is it right?

why the acceptCount is not work like it's configuration?

Could you help me?



2013/12/27 侯树成 chain...@gmail.com

 Yes, this must use BIO mode, because the NIO maxConnections=1 in
 default, it won't block the LimitLatch. In my test case,(use JMeter, thread
 number is 5), 2 requests will refused soon(just 1s-2s later), then another
 3 requests will served correctly.In source code, I find the backlog
 attribute will send to ServerSocket constructor, So, the backlog attribute
 is worked inside of JDK, not in Tomcat?
 Thank you all for reply.


 2013/12/27 Mark Thomas ma...@apache.org

 On 27/12/2013 08:53, Mark Eggers wrote:
  On 12/27/2013 12:37 AM, Mark Thomas wrote:
  On 27/12/2013 07:27, Mark Eggers wrote:
  On 12/26/2013 11:09 PM, 侯树成 wrote:
 
  1.set tomcat connector like this:
Connector port=8080 protocol=HTTP/1.1
   connectionTimeout=2
   redirectPort=8443 acceptCount=1 maxThreads=1
  minSpareThreads=1/
 
  2. deploy a war file, which contains a servlet that will sleep 60s in
  it's
  doPost method
 
  3. use LR or JMeter send 5 requests to the serlvet above
 
 
  I'm going to guess based on the Tomcat 7 documentation:
 
  request 1 gets executed and sits in your doPost for 60 seconds
  request 2 consumes the minSpareThread
  request 3 consumes the acceptCount
 
  Per documentation, connections 4 and 5 are dropped immediately.
 
  That is almost right except that there should not be a spare thread at
  step 2 since maxThreads includes any spare threads.
 
 
  Yep, that's what I would expect as well. I was just trying to
  rationalize the third accept.
 
  I agree, I would think that 1 would be served, 2 would wait, and 3-5
  would be dropped.

 Figured it out. The OP is using BIO where maxConnections == maxThreads
 by default.

 Request 1 uses the one available request processing thread.

 Request 2 is accepted but is blocked since the maximum number of
 connections has been reached.

 Request 3 uses the accept count.

 Requests 4  5 are blocked.

 It might be worth a note in the docs that the number of connections
 accepted will always be maxConnections + 1 with the + 1 being blocked
 in the acceptor thread until the number of connections drops below
 maxConnections again. I'll try and add something later today.

 Mark


 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org





Re: how http connector backlog attribute works?

2013-12-27 Thread Mark Thomas
On 27/12/2013 07:27, Mark Eggers wrote:
 On 12/26/2013 11:09 PM, 侯树成 wrote:

 1.set tomcat connector like this:
  Connector port=8080 protocol=HTTP/1.1
 connectionTimeout=2
 redirectPort=8443 acceptCount=1 maxThreads=1
 minSpareThreads=1/

 2. deploy a war file, which contains a servlet that will sleep 60s in
 it's
 doPost method

 3. use LR or JMeter send 5 requests to the serlvet above


 I'm going to guess based on the Tomcat 7 documentation:
 
 request 1 gets executed and sits in your doPost for 60 seconds
 request 2 consumes the minSpareThread
 request 3 consumes the acceptCount
 
 Per documentation, connections 4 and 5 are dropped immediately.

That is almost right except that there should not be a spare thread at
step 2 since maxThreads includes any spare threads.

I'd expect request 2 to use the accept count and 3, 4  5 to be dropped.
There may be an off-by-one error somewhere or it could just be an
artefact of how the limit is enforced.

 Please read the following and see if my interpretation is reasonable:
 
 http://tomcat.apache.org/tomcat-7.0-doc/config/http.html
 
 Pay particular attention to the Introduction section.
 
 If I have the particulars wrong, hopefully someone will come along and
 correct me.

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: how http connector backlog attribute works?

2013-12-27 Thread Mark Eggers

On 12/27/2013 12:37 AM, Mark Thomas wrote:

On 27/12/2013 07:27, Mark Eggers wrote:

On 12/26/2013 11:09 PM, 侯树成 wrote:



1.set tomcat connector like this:
  Connector port=8080 protocol=HTTP/1.1
 connectionTimeout=2
 redirectPort=8443 acceptCount=1 maxThreads=1
minSpareThreads=1/

2. deploy a war file, which contains a servlet that will sleep 60s in
it's
doPost method

3. use LR or JMeter send 5 requests to the serlvet above




I'm going to guess based on the Tomcat 7 documentation:

request 1 gets executed and sits in your doPost for 60 seconds
request 2 consumes the minSpareThread
request 3 consumes the acceptCount

Per documentation, connections 4 and 5 are dropped immediately.


That is almost right except that there should not be a spare thread at
step 2 since maxThreads includes any spare threads.



Yep, that's what I would expect as well. I was just trying to 
rationalize the third accept.


I agree, I would think that 1 would be served, 2 would wait, and 3-5 
would be dropped.



I'd expect request 2 to use the accept count and 3, 4  5 to be dropped.
There may be an off-by-one error somewhere or it could just be an
artefact of how the limit is enforced.


Please read the following and see if my interpretation is reasonable:

http://tomcat.apache.org/tomcat-7.0-doc/config/http.html

Pay particular attention to the Introduction section.

If I have the particulars wrong, hopefully someone will come along and
correct me.


Mark


I guess some tests are in order?

/mde/


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: how http connector backlog attribute works?

2013-12-27 Thread Mark Thomas
On 27/12/2013 08:53, Mark Eggers wrote:
 On 12/27/2013 12:37 AM, Mark Thomas wrote:
 On 27/12/2013 07:27, Mark Eggers wrote:
 On 12/26/2013 11:09 PM, 侯树成 wrote:

 1.set tomcat connector like this:
   Connector port=8080 protocol=HTTP/1.1
  connectionTimeout=2
  redirectPort=8443 acceptCount=1 maxThreads=1
 minSpareThreads=1/

 2. deploy a war file, which contains a servlet that will sleep 60s in
 it's
 doPost method

 3. use LR or JMeter send 5 requests to the serlvet above


 I'm going to guess based on the Tomcat 7 documentation:

 request 1 gets executed and sits in your doPost for 60 seconds
 request 2 consumes the minSpareThread
 request 3 consumes the acceptCount

 Per documentation, connections 4 and 5 are dropped immediately.

 That is almost right except that there should not be a spare thread at
 step 2 since maxThreads includes any spare threads.

 
 Yep, that's what I would expect as well. I was just trying to
 rationalize the third accept.
 
 I agree, I would think that 1 would be served, 2 would wait, and 3-5
 would be dropped.

Figured it out. The OP is using BIO where maxConnections == maxThreads
by default.

Request 1 uses the one available request processing thread.

Request 2 is accepted but is blocked since the maximum number of
connections has been reached.

Request 3 uses the accept count.

Requests 4  5 are blocked.

It might be worth a note in the docs that the number of connections
accepted will always be maxConnections + 1 with the + 1 being blocked
in the acceptor thread until the number of connections drops below
maxConnections again. I'll try and add something later today.

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: how http connector backlog attribute works?

2013-12-27 Thread 侯树成
Yes, this must use BIO mode, because the NIO maxConnections=1 in
default, it won't block the LimitLatch. In my test case,(use JMeter, thread
number is 5), 2 requests will refused soon(just 1s-2s later), then another
3 requests will served correctly.In source code, I find the backlog
attribute will send to ServerSocket constructor, So, the backlog attribute
is worked inside of JDK, not in Tomcat?
Thank you all for reply.


2013/12/27 Mark Thomas ma...@apache.org

 On 27/12/2013 08:53, Mark Eggers wrote:
  On 12/27/2013 12:37 AM, Mark Thomas wrote:
  On 27/12/2013 07:27, Mark Eggers wrote:
  On 12/26/2013 11:09 PM, 侯树成 wrote:
 
  1.set tomcat connector like this:
Connector port=8080 protocol=HTTP/1.1
   connectionTimeout=2
   redirectPort=8443 acceptCount=1 maxThreads=1
  minSpareThreads=1/
 
  2. deploy a war file, which contains a servlet that will sleep 60s in
  it's
  doPost method
 
  3. use LR or JMeter send 5 requests to the serlvet above
 
 
  I'm going to guess based on the Tomcat 7 documentation:
 
  request 1 gets executed and sits in your doPost for 60 seconds
  request 2 consumes the minSpareThread
  request 3 consumes the acceptCount
 
  Per documentation, connections 4 and 5 are dropped immediately.
 
  That is almost right except that there should not be a spare thread at
  step 2 since maxThreads includes any spare threads.
 
 
  Yep, that's what I would expect as well. I was just trying to
  rationalize the third accept.
 
  I agree, I would think that 1 would be served, 2 would wait, and 3-5
  would be dropped.

 Figured it out. The OP is using BIO where maxConnections == maxThreads
 by default.

 Request 1 uses the one available request processing thread.

 Request 2 is accepted but is blocked since the maximum number of
 connections has been reached.

 Request 3 uses the accept count.

 Requests 4  5 are blocked.

 It might be worth a note in the docs that the number of connections
 accepted will always be maxConnections + 1 with the + 1 being blocked
 in the acceptor thread until the number of connections drops below
 maxConnections again. I'll try and add something later today.

 Mark


 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org




how http connector backlog attribute works?

2013-12-26 Thread 侯树成
Hi,
I find a problem of http bio connector,I need help.
You can find it in flowing steps:

1.set tomcat connector like this:
Connector port=8080 protocol=HTTP/1.1
   connectionTimeout=2
   redirectPort=8443 acceptCount=1 maxThreads=1
minSpareThreads=1/

2. deploy a war file, which contains a servlet that will sleep 60s in it's
doPost method

3. use LR or JMeter send 5 requests to the serlvet above

4. use command jstack print current thread stack

NOTE: now the main acceptor thread stack like this:
http-bio-8080-Acceptor-0 daemon prio=6 tid=0x04b49800 nid=0x1a88 waiting
on condition [0x0536f000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  0x29a06cd0 (a
org.apache.tomcat.util.threads.LimitLatch$Sync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:969)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281)
at
org.apache.tomcat.util.threads.LimitLatch.countUpOrAwait(LimitLatch.java:115)
at
org.apache.tomcat.util.net.AbstractEndpoint.countUpOrAwaitConnection(AbstractEndpoint.java:733)
at org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(JIoEndpoint.java:210)
at java.lang.Thread.run(Thread.java:662)

Now, In the 5 requests, 3 request will served correctly, but another 2
requests will received Connection refused error like this

Caused by: java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:529)

Why the 2 requests not entering the thread pool executor or taskQueue, but
get refused quickly?

Thanks in advance.


Re: how http connector backlog attribute works?

2013-12-26 Thread André Warnier

侯树成 wrote:

Hi,
I find a problem of http bio connector,I need help.
You can find it in flowing steps:

1.set tomcat connector like this:
Connector port=8080 protocol=HTTP/1.1
   connectionTimeout=2
   redirectPort=8443 acceptCount=1 maxThreads=1
minSpareThreads=1/

2. deploy a war file, which contains a servlet that will sleep 60s in it's
doPost method

3. use LR or JMeter send 5 requests to the serlvet above

4. use command jstack print current thread stack

NOTE: now the main acceptor thread stack like this:
http-bio-8080-Acceptor-0 daemon prio=6 tid=0x04b49800 nid=0x1a88 waiting
on condition [0x0536f000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  0x29a06cd0 (a
org.apache.tomcat.util.threads.LimitLatch$Sync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:969)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281)
at
org.apache.tomcat.util.threads.LimitLatch.countUpOrAwait(LimitLatch.java:115)
at
org.apache.tomcat.util.net.AbstractEndpoint.countUpOrAwaitConnection(AbstractEndpoint.java:733)
at org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(JIoEndpoint.java:210)
at java.lang.Thread.run(Thread.java:662)

Now, In the 5 requests, 3 request will served correctly, but another 2
requests will received Connection refused error like this

Caused by: java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:529)

Why the 2 requests not entering the thread pool executor or taskQueue, but
get refused quickly?

Thanks in advance.


Which java and Tomcat versions ?


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: how http connector backlog attribute works?

2013-12-26 Thread Mark Eggers

On 12/26/2013 11:09 PM, 侯树成 wrote:

Hi,
I find a problem of http bio connector,I need help.
You can find it in flowing steps:

1.set tomcat connector like this:
 Connector port=8080 protocol=HTTP/1.1
connectionTimeout=2
redirectPort=8443 acceptCount=1 maxThreads=1
minSpareThreads=1/

2. deploy a war file, which contains a servlet that will sleep 60s in it's
doPost method

3. use LR or JMeter send 5 requests to the serlvet above

4. use command jstack print current thread stack

NOTE: now the main acceptor thread stack like this:
http-bio-8080-Acceptor-0 daemon prio=6 tid=0x04b49800 nid=0x1a88 waiting
on condition [0x0536f000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  0x29a06cd0 (a
org.apache.tomcat.util.threads.LimitLatch$Sync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:969)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281)
at
org.apache.tomcat.util.threads.LimitLatch.countUpOrAwait(LimitLatch.java:115)
at
org.apache.tomcat.util.net.AbstractEndpoint.countUpOrAwaitConnection(AbstractEndpoint.java:733)
at org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(JIoEndpoint.java:210)
at java.lang.Thread.run(Thread.java:662)

Now, In the 5 requests, 3 request will served correctly, but another 2
requests will received Connection refused error like this

Caused by: java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:529)

Why the 2 requests not entering the thread pool executor or taskQueue, but
get refused quickly?

Thanks in advance.



I'm going to guess based on the Tomcat 7 documentation:

request 1 gets executed and sits in your doPost for 60 seconds
request 2 consumes the minSpareThread
request 3 consumes the acceptCount

Per documentation, connections 4 and 5 are dropped immediately.

Please read the following and see if my interpretation is reasonable:

http://tomcat.apache.org/tomcat-7.0-doc/config/http.html

Pay particular attention to the Introduction section.

If I have the particulars wrong, hopefully someone will come along and 
correct me.


. . . just my two cents
/mde/

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org