Hi Shawn, Why don't you write a delegating SolrServer class that lazily instantiates an HttpSolrServer and catches and logs exceptions when something's down?
Michael Della Bitta ------------------------------------------------ Appinions 18 East 41st Street, 2nd Floor New York, NY 10017-6271 www.appinions.com Where Influence Isn’t a Game On Mon, Feb 4, 2013 at 4:25 PM, Shawn Heisey <s...@elyograg.org> wrote: > I have a SolrJ app that talks to four Solr servers. For each server, it > creates 14 HttpSolrServer objects, each for a different core. > > Once it's running, the app knows how to deal with errors, especially those > caused when the server goes down. > > The problem is at program startup -- when 'new HttpSolrServer(url)' is > called, it goes and makes sure that the server is up and responsive. If any > of those 56 object creation calls fails, then my app won't even start. > > Due to the design of my app, a server being down at startup is not really a > problem. When the program tries to update an index that's down, that fact > will be noticed. If the situation continues for long enough, an alarm email > is generated, but the program will continue to operate correctly on the > servers that are still up. > > As far as I can tell, there is no built-in way to bypass the health check at > object creation. Is there an alternate way of initializing these objects > that would bypass this? > > Someone on the IRC channel brought up the possibility of initializing the > HttpClient myself instead of letting the Solr object do it. If the health > check is actually in HttpClient, this might work, if there's a way to > initialize the HttpClient without a health check. I've actually been > wondering if it makes any sense to re-use a single HttpClient object across > all 56 server objects. > > Should I file a Jira for an alternate SolrServer constructor that doesn't > perform a healthcheck? > > Thanks, > Shawn
