You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Novin Novin <to...@gmail.com> on 2016/04/14 12:40:09 UTC
Solr 5.5 timeout of solrj client
Hi guys,
I'm having error
when sending solr doc
mid15955728
org.apache.solr.client.solrj.SolrServerException: Timeout occured
while waiting response from server at:
http://localhost.com:8983/solr/analysis
at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:585)
at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:240)
at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:229)
at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:106)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:71)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:85)
at com.temetra.wms.textindexer.TextIndexer$7.run(TextIndexer.java:544)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:152)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:139)
at org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:155)
at org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:284)
at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:140)
at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
at org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165)
at org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:167)
at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271)
at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:481)
... 10 more
Don't really able find why is this happening.
Does any body know what could have cause such error?
Thanks in advance.
Novin
Re: Solr 5.5 timeout of solrj client
Posted by Novin Novin <to...@gmail.com>.
Thanks for the great advice Erick.
On 14 April 2016 at 18:18, Erick Erickson <er...@gmail.com> wrote:
> BTW, the place optimize seems best used is when the index isn't
> updated very often. I've seen a pattern where the index is updated
> once a night (or even less). In that situation, optimization makes
> more sense. But when an index is continually updated, it's mostly
> wasted effort.
>
> Best,
> Erick
>
> On Thu, Apr 14, 2016 at 10:17 AM, Erick Erickson
> <er...@gmail.com> wrote:
> > Unless you have somewhat unusual circumstances, I wouldn't optimize at
> > all, despite the name it really doesn't help all that much in _most_
> > cases.
> >
> > If your percentage deleted docs doesn't exceed, say, 15-20% I wouldn't
> > bother. Most of what optimize does is reclaim resources from deleted
> > docs. This happens as part of general background merging anyway.
> >
> > There have been some reports of 10-15% query performance after
> > optimizing, but I would measure on your system before expending the
> > resources optimizing.
> >
> > Best,
> > Erick
> >
> > On Thu, Apr 14, 2016 at 9:56 AM, Novin Novin <to...@gmail.com>
> wrote:
> >> Thanks Erick, for pointing out. You are right. I was optimizing
> every 10
> >> mins. And I have change this to every day in night.
> >> On 14-Apr-2016 5:20 pm, "Erick Erickson" <er...@gmail.com>
> wrote:
> >>
> >>> don't issue an optimize command... either you have a solrj client that
> >>> issues a client.optimize() command or you pressed the "optimize now"
> >>> in the admin UI. Solr doesn't do this by itself.
> >>>
> >>> Best,
> >>> Erick
> >>>
> >>> On Thu, Apr 14, 2016 at 8:30 AM, Novin Novin <to...@gmail.com>
> wrote:
> >>> > How can I stop happening "DirectUpdateHandler2 Starting optimize...
> >>> Reading
> >>> > and rewriting the entire index! Use with care"
> >>> >
> >>> > Thanks
> >>> > novin
> >>> >
> >>> > On 14 April 2016 at 14:36, Shawn Heisey <ap...@elyograg.org> wrote:
> >>> >
> >>> >> On 4/14/2016 7:23 AM, Novin Novin wrote:
> >>> >> > Thanks for reply Shawn.
> >>> >> >
> >>> >> > Below is snippet of jetty.xml and jetty-https.xml
> >>> >> >
> >>> >> > jetty.xml:38: <Set name="idleTimeout" type="int"><Property
> >>> >> > name="solr.jetty.threads.idle.timeout" default="5000"/></Set>
> >>> >> > /// I presume this one I should increase, But I believe 5 second
> is
> >>> >> enough
> >>> >> > time for 250 docs to add to solr.
> >>> >>
> >>> >> 5 seconds might not be enough time. The *add* probably completes in
> >>> >> time, but the entire request might take longer, especially if you
> use
> >>> >> commit=true with the request. I would definitely NOT set this
> timeout
> >>> >> so low -- requests that take longer than 5 seconds are very likely
> going
> >>> >> to happen.
> >>> >>
> >>> >> > I'm also seeing "DirectUpdateHandler2 Starting optimize...
> Reading and
> >>> >> > rewriting the entire index! Use with care". Would this be causing
> >>> delay
> >>> >> > response from solr?
> >>> >>
> >>> >> Exactly how long an optimize takes is dependent on the size of your
> >>> >> index. Rewriting an index that's a few hundred megabytes may take
> 30
> >>> >> seconds to a minute. Rewriting an index that's several gigabytes
> will
> >>> >> take a few minutes. Performance is typically lower during an
> optimize,
> >>> >> because the CPU and disks are very busy.
> >>> >>
> >>> >> Thanks,
> >>> >> Shawn
> >>> >>
> >>> >>
> >>>
>
Re: Solr 5.5 timeout of solrj client
Posted by Erick Erickson <er...@gmail.com>.
BTW, the place optimize seems best used is when the index isn't
updated very often. I've seen a pattern where the index is updated
once a night (or even less). In that situation, optimization makes
more sense. But when an index is continually updated, it's mostly
wasted effort.
Best,
Erick
On Thu, Apr 14, 2016 at 10:17 AM, Erick Erickson
<er...@gmail.com> wrote:
> Unless you have somewhat unusual circumstances, I wouldn't optimize at
> all, despite the name it really doesn't help all that much in _most_
> cases.
>
> If your percentage deleted docs doesn't exceed, say, 15-20% I wouldn't
> bother. Most of what optimize does is reclaim resources from deleted
> docs. This happens as part of general background merging anyway.
>
> There have been some reports of 10-15% query performance after
> optimizing, but I would measure on your system before expending the
> resources optimizing.
>
> Best,
> Erick
>
> On Thu, Apr 14, 2016 at 9:56 AM, Novin Novin <to...@gmail.com> wrote:
>> Thanks Erick, for pointing out. You are right. I was optimizing every 10
>> mins. And I have change this to every day in night.
>> On 14-Apr-2016 5:20 pm, "Erick Erickson" <er...@gmail.com> wrote:
>>
>>> don't issue an optimize command... either you have a solrj client that
>>> issues a client.optimize() command or you pressed the "optimize now"
>>> in the admin UI. Solr doesn't do this by itself.
>>>
>>> Best,
>>> Erick
>>>
>>> On Thu, Apr 14, 2016 at 8:30 AM, Novin Novin <to...@gmail.com> wrote:
>>> > How can I stop happening "DirectUpdateHandler2 Starting optimize...
>>> Reading
>>> > and rewriting the entire index! Use with care"
>>> >
>>> > Thanks
>>> > novin
>>> >
>>> > On 14 April 2016 at 14:36, Shawn Heisey <ap...@elyograg.org> wrote:
>>> >
>>> >> On 4/14/2016 7:23 AM, Novin Novin wrote:
>>> >> > Thanks for reply Shawn.
>>> >> >
>>> >> > Below is snippet of jetty.xml and jetty-https.xml
>>> >> >
>>> >> > jetty.xml:38: <Set name="idleTimeout" type="int"><Property
>>> >> > name="solr.jetty.threads.idle.timeout" default="5000"/></Set>
>>> >> > /// I presume this one I should increase, But I believe 5 second is
>>> >> enough
>>> >> > time for 250 docs to add to solr.
>>> >>
>>> >> 5 seconds might not be enough time. The *add* probably completes in
>>> >> time, but the entire request might take longer, especially if you use
>>> >> commit=true with the request. I would definitely NOT set this timeout
>>> >> so low -- requests that take longer than 5 seconds are very likely going
>>> >> to happen.
>>> >>
>>> >> > I'm also seeing "DirectUpdateHandler2 Starting optimize... Reading and
>>> >> > rewriting the entire index! Use with care". Would this be causing
>>> delay
>>> >> > response from solr?
>>> >>
>>> >> Exactly how long an optimize takes is dependent on the size of your
>>> >> index. Rewriting an index that's a few hundred megabytes may take 30
>>> >> seconds to a minute. Rewriting an index that's several gigabytes will
>>> >> take a few minutes. Performance is typically lower during an optimize,
>>> >> because the CPU and disks are very busy.
>>> >>
>>> >> Thanks,
>>> >> Shawn
>>> >>
>>> >>
>>>
Re: Solr 5.5 timeout of solrj client
Posted by Erick Erickson <er...@gmail.com>.
Unless you have somewhat unusual circumstances, I wouldn't optimize at
all, despite the name it really doesn't help all that much in _most_
cases.
If your percentage deleted docs doesn't exceed, say, 15-20% I wouldn't
bother. Most of what optimize does is reclaim resources from deleted
docs. This happens as part of general background merging anyway.
There have been some reports of 10-15% query performance after
optimizing, but I would measure on your system before expending the
resources optimizing.
Best,
Erick
On Thu, Apr 14, 2016 at 9:56 AM, Novin Novin <to...@gmail.com> wrote:
> Thanks Erick, for pointing out. You are right. I was optimizing every 10
> mins. And I have change this to every day in night.
> On 14-Apr-2016 5:20 pm, "Erick Erickson" <er...@gmail.com> wrote:
>
>> don't issue an optimize command... either you have a solrj client that
>> issues a client.optimize() command or you pressed the "optimize now"
>> in the admin UI. Solr doesn't do this by itself.
>>
>> Best,
>> Erick
>>
>> On Thu, Apr 14, 2016 at 8:30 AM, Novin Novin <to...@gmail.com> wrote:
>> > How can I stop happening "DirectUpdateHandler2 Starting optimize...
>> Reading
>> > and rewriting the entire index! Use with care"
>> >
>> > Thanks
>> > novin
>> >
>> > On 14 April 2016 at 14:36, Shawn Heisey <ap...@elyograg.org> wrote:
>> >
>> >> On 4/14/2016 7:23 AM, Novin Novin wrote:
>> >> > Thanks for reply Shawn.
>> >> >
>> >> > Below is snippet of jetty.xml and jetty-https.xml
>> >> >
>> >> > jetty.xml:38: <Set name="idleTimeout" type="int"><Property
>> >> > name="solr.jetty.threads.idle.timeout" default="5000"/></Set>
>> >> > /// I presume this one I should increase, But I believe 5 second is
>> >> enough
>> >> > time for 250 docs to add to solr.
>> >>
>> >> 5 seconds might not be enough time. The *add* probably completes in
>> >> time, but the entire request might take longer, especially if you use
>> >> commit=true with the request. I would definitely NOT set this timeout
>> >> so low -- requests that take longer than 5 seconds are very likely going
>> >> to happen.
>> >>
>> >> > I'm also seeing "DirectUpdateHandler2 Starting optimize... Reading and
>> >> > rewriting the entire index! Use with care". Would this be causing
>> delay
>> >> > response from solr?
>> >>
>> >> Exactly how long an optimize takes is dependent on the size of your
>> >> index. Rewriting an index that's a few hundred megabytes may take 30
>> >> seconds to a minute. Rewriting an index that's several gigabytes will
>> >> take a few minutes. Performance is typically lower during an optimize,
>> >> because the CPU and disks are very busy.
>> >>
>> >> Thanks,
>> >> Shawn
>> >>
>> >>
>>
Re: Solr 5.5 timeout of solrj client
Posted by Novin Novin <to...@gmail.com>.
Thanks Erick, for pointing out. You are right. I was optimizing every 10
mins. And I have change this to every day in night.
On 14-Apr-2016 5:20 pm, "Erick Erickson" <er...@gmail.com> wrote:
> don't issue an optimize command... either you have a solrj client that
> issues a client.optimize() command or you pressed the "optimize now"
> in the admin UI. Solr doesn't do this by itself.
>
> Best,
> Erick
>
> On Thu, Apr 14, 2016 at 8:30 AM, Novin Novin <to...@gmail.com> wrote:
> > How can I stop happening "DirectUpdateHandler2 Starting optimize...
> Reading
> > and rewriting the entire index! Use with care"
> >
> > Thanks
> > novin
> >
> > On 14 April 2016 at 14:36, Shawn Heisey <ap...@elyograg.org> wrote:
> >
> >> On 4/14/2016 7:23 AM, Novin Novin wrote:
> >> > Thanks for reply Shawn.
> >> >
> >> > Below is snippet of jetty.xml and jetty-https.xml
> >> >
> >> > jetty.xml:38: <Set name="idleTimeout" type="int"><Property
> >> > name="solr.jetty.threads.idle.timeout" default="5000"/></Set>
> >> > /// I presume this one I should increase, But I believe 5 second is
> >> enough
> >> > time for 250 docs to add to solr.
> >>
> >> 5 seconds might not be enough time. The *add* probably completes in
> >> time, but the entire request might take longer, especially if you use
> >> commit=true with the request. I would definitely NOT set this timeout
> >> so low -- requests that take longer than 5 seconds are very likely going
> >> to happen.
> >>
> >> > I'm also seeing "DirectUpdateHandler2 Starting optimize... Reading and
> >> > rewriting the entire index! Use with care". Would this be causing
> delay
> >> > response from solr?
> >>
> >> Exactly how long an optimize takes is dependent on the size of your
> >> index. Rewriting an index that's a few hundred megabytes may take 30
> >> seconds to a minute. Rewriting an index that's several gigabytes will
> >> take a few minutes. Performance is typically lower during an optimize,
> >> because the CPU and disks are very busy.
> >>
> >> Thanks,
> >> Shawn
> >>
> >>
>
Re: Solr 5.5 timeout of solrj client
Posted by Erick Erickson <er...@gmail.com>.
don't issue an optimize command... either you have a solrj client that
issues a client.optimize() command or you pressed the "optimize now"
in the admin UI. Solr doesn't do this by itself.
Best,
Erick
On Thu, Apr 14, 2016 at 8:30 AM, Novin Novin <to...@gmail.com> wrote:
> How can I stop happening "DirectUpdateHandler2 Starting optimize... Reading
> and rewriting the entire index! Use with care"
>
> Thanks
> novin
>
> On 14 April 2016 at 14:36, Shawn Heisey <ap...@elyograg.org> wrote:
>
>> On 4/14/2016 7:23 AM, Novin Novin wrote:
>> > Thanks for reply Shawn.
>> >
>> > Below is snippet of jetty.xml and jetty-https.xml
>> >
>> > jetty.xml:38: <Set name="idleTimeout" type="int"><Property
>> > name="solr.jetty.threads.idle.timeout" default="5000"/></Set>
>> > /// I presume this one I should increase, But I believe 5 second is
>> enough
>> > time for 250 docs to add to solr.
>>
>> 5 seconds might not be enough time. The *add* probably completes in
>> time, but the entire request might take longer, especially if you use
>> commit=true with the request. I would definitely NOT set this timeout
>> so low -- requests that take longer than 5 seconds are very likely going
>> to happen.
>>
>> > I'm also seeing "DirectUpdateHandler2 Starting optimize... Reading and
>> > rewriting the entire index! Use with care". Would this be causing delay
>> > response from solr?
>>
>> Exactly how long an optimize takes is dependent on the size of your
>> index. Rewriting an index that's a few hundred megabytes may take 30
>> seconds to a minute. Rewriting an index that's several gigabytes will
>> take a few minutes. Performance is typically lower during an optimize,
>> because the CPU and disks are very busy.
>>
>> Thanks,
>> Shawn
>>
>>
Re: Solr 5.5 timeout of solrj client
Posted by Novin Novin <to...@gmail.com>.
How can I stop happening "DirectUpdateHandler2 Starting optimize... Reading
and rewriting the entire index! Use with care"
Thanks
novin
On 14 April 2016 at 14:36, Shawn Heisey <ap...@elyograg.org> wrote:
> On 4/14/2016 7:23 AM, Novin Novin wrote:
> > Thanks for reply Shawn.
> >
> > Below is snippet of jetty.xml and jetty-https.xml
> >
> > jetty.xml:38: <Set name="idleTimeout" type="int"><Property
> > name="solr.jetty.threads.idle.timeout" default="5000"/></Set>
> > /// I presume this one I should increase, But I believe 5 second is
> enough
> > time for 250 docs to add to solr.
>
> 5 seconds might not be enough time. The *add* probably completes in
> time, but the entire request might take longer, especially if you use
> commit=true with the request. I would definitely NOT set this timeout
> so low -- requests that take longer than 5 seconds are very likely going
> to happen.
>
> > I'm also seeing "DirectUpdateHandler2 Starting optimize... Reading and
> > rewriting the entire index! Use with care". Would this be causing delay
> > response from solr?
>
> Exactly how long an optimize takes is dependent on the size of your
> index. Rewriting an index that's a few hundred megabytes may take 30
> seconds to a minute. Rewriting an index that's several gigabytes will
> take a few minutes. Performance is typically lower during an optimize,
> because the CPU and disks are very busy.
>
> Thanks,
> Shawn
>
>
Re: Solr 5.5 timeout of solrj client
Posted by Shawn Heisey <ap...@elyograg.org>.
On 4/14/2016 7:23 AM, Novin Novin wrote:
> Thanks for reply Shawn.
>
> Below is snippet of jetty.xml and jetty-https.xml
>
> jetty.xml:38: <Set name="idleTimeout" type="int"><Property
> name="solr.jetty.threads.idle.timeout" default="5000"/></Set>
> /// I presume this one I should increase, But I believe 5 second is enough
> time for 250 docs to add to solr.
5 seconds might not be enough time. The *add* probably completes in
time, but the entire request might take longer, especially if you use
commit=true with the request. I would definitely NOT set this timeout
so low -- requests that take longer than 5 seconds are very likely going
to happen.
> I'm also seeing "DirectUpdateHandler2 Starting optimize... Reading and
> rewriting the entire index! Use with care". Would this be causing delay
> response from solr?
Exactly how long an optimize takes is dependent on the size of your
index. Rewriting an index that's a few hundred megabytes may take 30
seconds to a minute. Rewriting an index that's several gigabytes will
take a few minutes. Performance is typically lower during an optimize,
because the CPU and disks are very busy.
Thanks,
Shawn
Re: Solr 5.5 timeout of solrj client
Posted by Novin Novin <to...@gmail.com>.
Thanks for reply Shawn.
Below is snippet of jetty.xml and jetty-https.xml
jetty.xml:38: <Set name="idleTimeout" type="int"><Property
name="solr.jetty.threads.idle.timeout" default="5000"/></Set>
/// I presume this one I should increase, But I believe 5 second is enough
time for 250 docs to add to solr.
jetty.xml:39: <Set name="stopTimeout" type="int"><Property
name="solr.jetty.threads.stop.timeout" default="60000"/></Set>
jetty-https.xml:45: <Set name="idleTimeout"><Property
name="solr.jetty.https.timeout" default="50000"/></Set>
I'm also seeing "DirectUpdateHandler2 Starting optimize... Reading and
rewriting the entire index! Use with care". Would this be causing delay
response from solr?
Thanks in advance,
Novin
On 14 April 2016 at 14:05, Shawn Heisey <ap...@elyograg.org> wrote:
> On 4/14/2016 4:40 AM, Novin Novin wrote:
> > I'm having error
> >
> > when sending solr doc
> > mid15955728
> > org.apache.solr.client.solrj.SolrServerException: Timeout occured
> > while waiting response from server at:
> > http://localhost.com:8983/solr/analysis
>
> <snip>
>
> > Caused by: java.net.SocketTimeoutException: Read timed out
>
> You encountered a socket timeout. This is a low-level TCP timeout.
> It's effectively an idle timeout -- no activity for X seconds and the
> TCP connection is severed.
>
> I believe the Jetty included with Solr has a socket timeout of 50
> seconds configured. You can also configure a socket timeout on the
> HttpClient used by various SolrClient implementations.
>
> The operating system (on either end of the connection) may also have a
> default socket timeout configured, but I believe that these defaults are
> normally measured in hours, not seconds.
>
> Thanks,
> Shawn
>
>
Re: Solr 5.5 timeout of solrj client
Posted by Shawn Heisey <ap...@elyograg.org>.
On 4/14/2016 4:40 AM, Novin Novin wrote:
> I'm having error
>
> when sending solr doc
> mid15955728
> org.apache.solr.client.solrj.SolrServerException: Timeout occured
> while waiting response from server at:
> http://localhost.com:8983/solr/analysis
<snip>
> Caused by: java.net.SocketTimeoutException: Read timed out
You encountered a socket timeout. This is a low-level TCP timeout.
It's effectively an idle timeout -- no activity for X seconds and the
TCP connection is severed.
I believe the Jetty included with Solr has a socket timeout of 50
seconds configured. You can also configure a socket timeout on the
HttpClient used by various SolrClient implementations.
The operating system (on either end of the connection) may also have a
default socket timeout configured, but I believe that these defaults are
normally measured in hours, not seconds.
Thanks,
Shawn