Thanks for the info, I will look into the open file count and try to provide more info on how this is occurring.
Just to make sure that our scenarios were the same, in your tests did you simulate many concurrent inbound connections to your web app, with each connection sharing the same instance of HttpSolrServer for queries? On Thu, Feb 13, 2014 at 6:58 PM, Shawn Heisey <s...@elyograg.org> wrote: > On 2/13/2014 3:17 PM, Jared Rodriguez wrote: > >> I just regressed to Solrj 4.6.1 with http client 4.2.6 and am trying to >> reproduce the problem. Using YourKit to profile and even just manually >> simulating a few users at once, I see the same problem of open sockets. 6 >> sockets opened to the solr server and 2 of them still open after all is >> done and there is no server activity. Although this could be sockets kept >> in a connection pool. >> > > I did two separate upgrade steps, SolrJ 4.5.1 to 4.6.1, and HttpClient > 4.3.1 to 4.3.2, and I'm not seeing any evidence of connection leaks. > > > On your connections, if they are in TIME_WAIT, I'm pretty sure that means > that the program is done with them because it's closed the connection and > it's the operating system that is in charge. See the answer with the green > checkmark here: > > http://superuser.com/questions/173535/what-are-close-wait-and-time-wait- > states > > I think the default timeout for WAIT states on a modern Linux system is 60 > seconds, not four minutes as described on that answer. > > With your connection rate and the default 60 second timeout for WAIT > states, another resource that might be in short supply is file descriptors. > > Thanks, > Shawn > > -- Jared Rodriguez
