Hey Charles, see my explanation above on why this is needed. If Solr has to be killed, it would generally be immediately restarted. This would normally not the case, except when things are potentially misconfigured or if there is a bug, but not doing so makes the impact worse..
In any case, turns out really that reuseAddress is true by default for the connectors we use, so that really isn't the issue. The issue more specifically is that the stop port doesn't do it, so the actual port by itself starts just fine on a restart, but the stop port fails to bind -- and there's no way currently in Jetty to configure that. Based on my question in the jetty mailing list, I have now created an issue for them.. https://bugs.eclipse.org/bugs/show_bug.cgi?id=461133 On Fri, Feb 27, 2015 at 3:03 PM, Reitzel, Charles < [email protected]> wrote: > Disclaimer: I’m not a Solr committer. But, as a developer, I’ve never > seen a good case for reusing the listening port. Better to find and fix > the root cause on the zombie state (or just slow shutdown, sometimes) and > release the port. > > > > *From:* Mark Miller [mailto:[email protected]] > *Sent:* Thursday, February 26, 2015 5:28 PM > *To:* [email protected] > *Subject:* Re: reuseAddress default in Solr jetty.xml > > > > +1 > > - Mark > > > > On Thu, Feb 26, 2015 at 1:54 PM Ramkumar R. Aiyengar < > [email protected]> wrote: > > The jetty.xml we currently ship by default doesn't set reuseAddress=true. > If you are having a bad GC day with things going OOM and resulting in Solr > not even being able to shutdown cleanly (or the oom_solr.sh script killing > it), whatever external service management mechanism you have is probably > going to try respawn it and fail with the default config because the ports > will be in TIME_WAIT. I guess there's the usual disclaimer with > reuseAddress causing stray packets to reach the restarted server, but > sounds like at least the default should be true.. > > I can raise a JIRA, but just wanted to check if anyone has any opinions > either way.. > > > > > ************************************************************************* > This e-mail may contain confidential or privileged information. > If you are not the intended recipient, please notify the sender > immediately and then delete it. > > TIAA-CREF > ************************************************************************* > -- Not sent from my iPhone or my Blackberry or anyone else's
