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? > Continuous replication is really our preferred solution for your > scenario. If you can live with interpreting the records in the > _local > document to verify that it's still running you'll end up with a more > efficient replication system all around. Yes i think that sould be possible. I will probably switch to that way. > Regarding the hangs, if you do write a test script I'll be more than > happy to try it and figure out what's going wrong. Best, I will do my best to make one available as soon as possible. Best regards Simon > > Adam -- Simon Eisenmann [ mailto:[email protected] ] [ struktur AG | Kronenstraße 22a | D-70173 Stuttgart ] [ T. +49.711.896656.68 | F.+49.711.89665610 ] [ http://www.struktur.de | mailto:[email protected] ]
smime.p7s
Description: S/MIME cryptographic signature
