On 11/14/12 11:02 AM, chris derham wrote:
My simple thought was that it sounds like your code isn't working.
You have more load than one tomcat instance can handle, which
overloads that instance. You are trying to write code to handle
this situation, and seem convinced that the only solution is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris,
On 11/14/12 11:02 AM, chris derham wrote:
> My simple thought was that it sounds like your code isn't working.
> You have more load than one tomcat instance can handle, which
> overloads that instance. You are trying to write code to handle
> t
Having finally received the actual details of what the OP actually is doing
in email #37 of this thread, I was struck by a simple thought. I have
re-read the whole thread, and don't think/hope that I am about to say
anything completely stupid.
> "We develop software that routes millions of request
>> In addition, those clients will then get exactly the behaviour that
>> you are complaining about: a successful connection and then a 'connection
reset'
>> when doing I/O.
> No, they will not get an ACK to the SYN packet which is much better.
No, Asahnka, you are completely wrong about this. Cl
> From: selvakumar netaji [mailto:vvekselva...@gmail.com]
> Subject: Re: Handling requests when under load - ACCEPT and RST vs non-ACCEPT
> I'm new to this mailing list. I read the above mail list and not able to
> grasp the concepts like load balancing, keep alive. Can y
Hi All,
I'm new to this mailing list. I read the above mail list and not able to
grasp the concepts like load balancing, keep alive. Can you please give me
links where I can find links about it.
On Tue, Nov 13, 2012 at 6:32 AM, Mark Thomas wrote:
> "Asankha C. Perera" wrote:
>
> >I do not und
"Asankha C. Perera" wrote:
>I do not understand the negativity here..
You are trying to solve a problem no-one here recognises.
You are ignoring and/or dismissing people that ask difficult questions or point
out flaws in your proposal.
Your posts - this one in particular - come across as very
Esmond Pitt wrote:
>Asankha
>
>To reiterate what Christopher said, if you close the listening socket
>because you think you can't service one extra client, you will lose all
>the
>connections on the backlog queue, which could be hundreds of clients,
>that
>you *can* service.
Indeed. I'd like to
On 11/12/2012 10:47 PM, Terence M. Bandoian wrote:
On 11/9/2012 1:41 PM, Christopher Schultz wrote:
Closing the listening socket, as you seem to be now suggesting, is
>a very poor idea indeed: what happens if some other process grabs
>the port in the meantime: what is Tomcat supposed to do then?
Hi Esmond
To reiterate what Christopher said, if you close the listening socket
because you think you can't service one extra client, you will lose all the
connections on the backlog queue, which could be hundreds of clients, that
you *can* service.
I do not see a problem here. We develop softwar
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Esmond,
On 11/11/12 10:18 PM, Esmond Pitt wrote:
> Asankha
>
> To reiterate what Christopher said, if you close the listening
> socket because you think you can't service one extra client, you
> will lose all the connections on the backlog queue, whi
On 11/9/2012 1:41 PM, Christopher Schultz wrote:
Closing the listening socket, as you seem to be now suggesting, is
>a very poor idea indeed: what happens if some other process grabs
>the port in the meantime: what is Tomcat supposed to do then?
I haven't been following this thread closely eno
Asankha
To reiterate what Christopher said, if you close the listening socket
because you think you can't service one extra client, you will lose all the
connections on the backlog queue, which could be hundreds of clients, that
you *can* service.
In addition, those clients will then get exactly
On 10/11/2012 04:52, Asankha C. Perera wrote:
> Hi Chris
>> processing 1 connection through completion
>> (there are 99 others still running), re-binding, accepting a single
>> connection into the application plus 100 others into the backlog, then
>> choking again and dropping 100 connections,
Hi Chris
processing 1 connection through completion
(there are 99 others still running), re-binding, accepting a single
connection into the application plus 100 others into the backlog, then
choking again and dropping 100 connections, then processing another
single connection. That's a huge w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Esmond,
On 11/7/12 10:03 PM, Esmond Pitt wrote:
> Asankha
>
> I haven't said a word about your second program, that closes the
> listening socket. *Of course* that causes connection refusals, it
> can't possibly not, but it isn't relevant to the misc
On 11/09/2012 02:16 AM, Pid wrote:
On 08/11/2012 15:03, Asankha C. Perera wrote:
Hi Mark
what happens if some other process grabs the port in the meantime:
what is Tomcat supposed to do then?
In reality I do not know of a single client production deployment that
would allocate the same port to
On 08/11/2012 15:03, Asankha C. Perera wrote:
> Hi Mark
what happens if some other process grabs the port in the meantime:
what is Tomcat supposed to do then?
>>> In reality I do not know of a single client production deployment that
>>> would allocate the same port to possibly conflictin
Hi Mark
what happens if some other process grabs the port in the meantime:
what is Tomcat supposed to do then?
In reality I do not know of a single client production deployment that
would allocate the same port to possibly conflicting services, that may
grab another's port when its suffering und
On 08/11/2012 03:35, Asankha C. Perera wrote:
> Hi Esmond
>> Closing the listening socket, as you seem to be now suggesting, is a
>> very poor idea indeed:
> I personally do not think there is anything at all bad about turning it
> off. After all, if you are not ready to accept more, you should be
Hi Esmond
I haven't said a word about your second program, that closes the
listening socket. *Of course* that causes connection refusals, it
can't possibly not, but it isn't relevant to the misconceptions about
what OP_ACCEPT does that you have been expressing here and that I have
been address
Asankha
I haven't said a word about your second program, that closes the listening
socket. *Of course* that causes connection refusals, it can't possibly not,
but it isn't relevant to the misconceptions about what OP_ACCEPT does that
you have been expressing here and that I have been addressing.
On 11/08/2012 04:57 AM, Esmond Pitt wrote:
That wouldn't have any different effect to not calling accept() at all
in blocking mode
Clearly there is a difference.
There isn't a difference. All that deregistering OP_ACCEPT does is prevent
the application from calling accept(). It has exactly the
Hi Esmond
>> That wouldn't have any different effect to not calling accept() at all
>> in blocking mode
> Clearly there is a difference.
There isn't a difference. All that deregistering OP_ACCEPT does is prevent
the application from calling accept(). It has exactly the same effect as
thread-sta
Hi Mark
maxThreads limits the number of concurrent threads available for
processing requests. "connection" != "concurrent request", primarily
because of HTTP keep-alive.
maxConnections can be used to limit the number of connections.
Thanks for this insight.. I initially missed this when I went t
Tomcat?
>> And which connector implentation?
> Tomcat 7.0.29 and possibly 7.0.32 too, but I believe its common to all
> versions
>
> Connector config was already shared
> http://tomcat.10.n6.nabble.com/Handling-requests-when-under-load-ACCEPT-and-RST-vs-non-ACCEPT-tt4988
versions
Connector config was already shared
http://tomcat.10.n6.nabble.com/Handling-requests-when-under-load-ACCEPT-and-RST-vs-non-ACCEPT-tt4988693.html#a4988712
asankha
--
Asankha C. Perera
AdroitLogic, http://adroitlogic.org
http://esbmagic.bl
Mark Thomas wrote:
>"Asankha C. Perera" wrote:
>
>> My testing has been primarily on Linux / Ubuntu.
>
>With which version of Tomcat?
And which connector implentation?
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.
"Asankha C. Perera" wrote:
> My testing has been primarily on Linux / Ubuntu.
With which version of Tomcat?
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat
Hi Chris
My expectation from the backlog is:
1. Connections that can be handled directly will be accepted and work
will begin
2. Connections that cannot be handled will accumulate in the backlog
3. Connections that exceed the backlog will get "connection refused"
There are caveats, I would im
Hi Esmond
That wouldn't have any different effect to not calling accept() at all in
blocking mode
Clearly there is a difference. Please see the samples in [1] & [2] and
execute them to see this. The TestAccept1 below allows one to open more
than one connection at a time, even when only one acce
That wouldn't have any different effect to not calling accept() at all in
blocking mode, or to thread starvation such that the accept thread didn't
get a run. It wouldn't make any difference to whether the client got a
connection refused/reset. The backlog queue would still fill up in exactly
the s
Hi Chris
First, evidently, "acceptCount" almost does not appear in the Tomcat
source. It's real name is "backlog" if you want to do some searching.
It's been in there forever.
Yes, I found it too; but saw that it didn't perform what an 'end user'
would expect from Tomcat.
Second, all three conn
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Asankha,
On 11/5/12 8:36 AM, Asankha C. Perera wrote:
> Hi Chris / Mark
>>> Or you could just read the configuration documentation for the
>>> connector. Hint: acceptCount - and it has been there since at
>>> least Tomcat 4.
>
> The acceptCount WAS
Hi Chris / Mark
Or you could just read the configuration documentation for the
connector. Hint: acceptCount - and it has been there since at
least Tomcat 4.
The acceptCount WAS being used, but was not being honored as an end user
would expect in reality (See the configurations I've shared at the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mark,
On 11/2/12 3:51 PM, Mark Thomas wrote:
> On 02/11/2012 19:13, Asankha C. Perera wrote:
>> Hi Esmond
>>
>> You are correct. As I recently found out Tomcat and Java is not
>> causing this explicitly, as I first thought. So there is no 'bug'
>> to
On 02/11/2012 19:13, Asankha C. Perera wrote:
> Hi Esmond
>
> You are correct. As I recently found out Tomcat and Java is not causing
> this explicitly, as I first thought. So there is no 'bug' to be fixed.
>
> But I believe there is an elegant way to refuse further connections when
> under load
Hi Esmond
You are correct. As I recently found out Tomcat and Java is not causing
this explicitly, as I first thought. So there is no 'bug' to be fixed.
But I believe there is an elegant way to refuse further connections when
under load by turning off just the 'accepting' of new connections,
Asankha
What you are looking at is TCP platform-dependent behaviour. There is a
'backlog' queue of inbound connections that have been completed by the TCP
stack but not yet accepted by the application via the accept() API. This is
the queue whose length is specified in the 'C' listen() method (alt
Hi Chris
I was connecting locally to the same node over the local interface on
both EC2 and locally.
Since this went unresolved for sometime now for me, I investigated this
a bit myself, first looking at the Coyote source code, and then
experimenting with plain Java sockets. It seems like th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Asankha,
On 10/29/12 11:56 PM, Asankha C. Perera wrote:
> Hi Chris
>
>> Sorry, also what is your OS (be as specific as possible) and what
>> JVM are you running on?
> Locally for the Wireshark capture I ran this on:
> asankha@asankha-dm4:~$ uname -a
Hi Chris
Sorry, also what is your OS (be as specific as possible) and what JVM
are you running on?
Locally for the Wireshark capture I ran this on:
asankha@asankha-dm4:~$ uname -a
Linux asankha-dm4 3.2.0-31-generic #50-Ubuntu SMP Fri Sep 7 16:16:45 UTC
2012 x86_64 x86_64 x86_64 GNU/Linux
asan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Asankha,
On 10/29/12 12:29 PM, Asankha C. Perera wrote:
> Hi Chris
>
> protocol="org.apache.coyote.http11.Http11NioProtocol"
> connectionTimeout="2" redirectPort="8443"
> maxKeepAliveRequests="1" processorCache="1" acceptCount="1"
> maxThread
Hi Chris
protocol="org.apache.coyote.http11.Http11NioProtocol"
connectionTimeout="2"
redirectPort="8443"
maxKeepAliveRequests="1"
processorCache="1"
acceptCount="1"
maxThreads="1"/>
I used the abov
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Asankha,
On 10/29/12 9:20 AM, Asankha C. Perera wrote:
> During some performance testing I've seen that Tomcat resets
> accepted TCP connections when under load. I had seen this
> previously too [1], but was not able to analyze the scenario in
> detai
Hi All
During some performance testing I've seen that Tomcat resets accepted
TCP connections when under load. I had seen this previously too [1], but
was not able to analyze the scenario in detail earlier.
As per this dump from Wireshark [2], it seemed like Tomcat ACKed the
client request, a
46 matches
Mail list logo
