On Oct 19, 2009, at 10:45 AM, Simon Eisenmann wrote:
Am Montag, den 19.10.2009, 10:37 -0400 schrieb Adam Kocoloski:
o, until JIRA comes back online I'll follow up with that here. I
think I could see how repeated pull replications in rapid succession
could end up blowing through sockets. Each pull replication sets up
one new connection for the _changes feed, and tears it down at the
end
(everything else replication-related goes through a connection
pool).
Do enough of those very short requests and you could end up with
lots
of connections in TIME_WAIT and eventually run out of sockets.
FWIW,
the default Erlang limit is slightly less than 1024. If your
update_notification process uses a new connection for every POST to
_replicate you'll hit the system limit (also 1024 in Ubuntu IIRC)
twice as fast.
I see that you mean. Though i am using a connection pool in the update
notification as well. I verified that i am not leaking connections on
the client side. The only reason i have to throw away and open a nw
connection is if the response is returned chunked.
I see the reasons for chunged transfer encoding. Is there a way to
disable it on connections so i can make sure i have a fixed connection
pool size on the client?
Hi Simon, I'm not sure I follow why chunked responses require new
connections, but in any event, I'm fairly certain that responses to
_replicate are not chunked.
(Digression more appropriate for dev@) Does the client really have any
control over whether the responses are chunked? I guess the "right"
way to force no chunking from the client side would be to make an HTTP/
1.0 request (with Connection: keep-alive if you still want the
connection pool). We should check at some point to see if that
actually works.
Adam
