Many thanks for your reply and explanation. . To generate load on server (for load test) I generally run simulator (on the same machine) that creates around 6000 connections to the server. and each connection then generates request up to size 64k. Eventually server occupies all available memory, then runs out of memory and starts throwing (and handling) exceptions. This stress testing helps me to find weaknesses and bottlenecks in the server.
This scenario normally goes fine without any trouble. Occupying as much as available application memory shouldn't cause this connection error coz OS maintains separate network buffers in kernel (If am right). And as per ephemeral ports concerned, 6k connections in total can generate max 12k ports which is far below from max limits. On top of everything, I don't understand why "only some time randomly" I keep getting this error while most of the time this stress testing goes fine. On Monday, March 16, 2015 at 3:47:39 AM UTC+5:30, Bert Belder wrote: > > So on libuv-windows accepting a socket works like this: > > * Create a socket > * Wait for an incoming connection > * Associate the incoming connection with the socket created earlier. > > The comment you're referring to relates to failure of the first step > (creating a socket). If that fails something must be really wrong. It can > basically only fail if the network stack is broken, the OS is out of memory > or you've reached the maximum open handle limit (which is about 16 million). > > Of course I can't tell if that's actually happening in your application; > the accept callback would *also* receive an failure status if an error > occurred in one of the other steps. > > One thing I noticed about windows is that it sometimes reports ENOBUFS if > there are no more ephemeral ip ports available. That seems the most logical > explanation to me, did you check for this? > > On Saturday, March 14, 2015 at 11:41:26 PM UTC-7, Ashish wrote: >> >> >> In uv_process_tcp_accept_req function in (tcp.c) libuv says: >> >> /* If handle->accepted_socket is not a valid socket, then */ >> /* uv_queue_accept must have failed. This is a serious error. We stop */ >> /* accepting connections and report this error to the connection */ >> /* callback. */ >> >> What does this mean for application? It should not call uv_accept on *any >> further connections*? >> If yes, how can we close those connections (which have not been accepted >> so no handle associated with them to close) >> > -- You received this message because you are subscribed to the Google Groups "libuv" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/libuv. For more options, visit https://groups.google.com/d/optout.
