[ https://issues.apache.org/jira/browse/SOLR-1951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Karl Wright closed SOLR-1951. ----------------------------- Fix Version/s: 1.4.1 1.5 Resolution: Fixed The overnight indexing run did not die due to resource starvation, so it appears that using keep-alive solves this problem, and no fix in Solr is required. > extractingUpdateHandler doesn't close socket handles promptly, and indexing > load tests eventually run out of resources > ---------------------------------------------------------------------------------------------------------------------- > > Key: SOLR-1951 > URL: https://issues.apache.org/jira/browse/SOLR-1951 > Project: Solr > Issue Type: Bug > Components: update > Affects Versions: 1.4.1, 1.5 > Environment: sun java > solr 1.5 build based on trunk > debian linux "lenny" > Reporter: Karl Wright > Fix For: 1.4.1, 1.5 > > Attachments: solr-1951.zip > > > When multiple threads pound on extractingUpdateRequestHandler using multipart > form posting over an extended period of time, I'm seeing a huge number of > sockets piling up in the following state: > tcp6 0 0 127.0.0.1:8983 127.0.0.1:44058 TIME_WAIT > Despite the fact that the client can only have 10 sockets open at a time, > huge numbers of sockets accumulate that are in this state: > r...@duck6:~# netstat -an | fgrep :8983 | wc > 28223 169338 2257840 > r...@duck6:~# > The sheer number of sockets lying around seems to eventually cause > commons-fileupload to fail (silently - another bug) in creating a temporary > file to contain the content data. This causes Solr to erroneously return a > 400 code with "missing_content_data" or some such to the indexing poster. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org