-Re: Exception using SolrJ
Shawn Heisey 2011-12-20, 16:32
On 12/20/2011 2:57 AM, Chantal Ackermann wrote:
> Hi Shawn,
> the exception indicates that the connection was lost. I'm sure you
> figured that out for yourself.
> - is that specific server instance really running? That is, can you
> reach it via browser?
> - If yes: how is your connection pool configured and how do you
> initialize it? More specifically: from what I know, CommonsHttp is
> already multi threaded so in your initializing code should not be using
> multiple threads to access it. Not completely sure about that in
> combination with SolrJ, though. I just had that issue when using
> CommonsHttp directly in the wrong way.
> I am using SolrJ with CommonsHttp pool for a some time now, and it all
> works very reliably. I've encountered those Connection reset exceptions
> also but they were always caused by the server not being reachable.
Yes, I did figure out it's a disconnected socket, but I can find no
reason for it.
The server is likely reachable via a browser, but as it usually happens
when I am sleeping or otherwise occupied, I am not able to check. The
updates run once a minute, and everything works fine on the next
update. If the server were down, I would get an email once a minute
until the problem were solved, but it happens only once, then it's fine
for a good long while. I am the only person who works on these servers,
so I know that nothing is going on when the exception occurs. These
Solr servers are not overloaded - the long term average requests per
second are about 0.3, very low.
The main reason I am creating my own HttpClient and connection manager
is so that I can be sure of the connection timeout applied. If
something should go wrong and it takes more than 30 seconds to establish
the HTTP connection, I don't want my code to silently keep on waiting
for it, I want to know about it. The other options are likely the
default setting, but they are the settings I want, so I am just ensuring
they are set, against a potential future change in the default.
The problem is not caused by the configured 30 second connection
timeout. As I said in the first message, this happens very quickly,
usually within 2 seconds of the start of the update, often within the