ideas at this time now.
--
*
Vijay Sekhri
*
> (SOLR-5850.patch), and include a note about what you found (I've already
> added a comment).
>
> Thanks!
> Erick
>
> On Wed, Jan 28, 2015 at 9:18 AM, Vijay Sekhri
> wrote:
>
> > Hi Shawn,
> > Thank you so much for the assistance. Building is not a p
, Jan 27, 2015 at 6:20 PM, Shawn Heisey wrote:
> On 1/27/2015 2:52 PM, Vijay Sekhri wrote:
> > Hi Shawn,
> > Here is some update. We found the main issue
> > We have configured our cluster to run under jetty and when we tried full
> > indexing, we did not see the original I
olr/solrnodes/solrnode1/search1_shard7_replica1/data/index.20150127135840219
2386491 [RecoveryThread] WARN org.apache.solr.handler.SnapPuller – File
_89e.fdt expected to be 811432 while it is 4204287
-regards
Vijay
On Tue, Jan 27, 2015 at 12:07 AM, Shawn Heisey wrote:
> On 1/26/2015 9:3
:55:07,681 INFO [org.apache.solr.cloud.ZkController] (Thread-443) Wrote
recovering to /collections/search1/leader_initiated_recovery
/shard4/core_node192
On Mon, Jan 26, 2015 at 10:34 PM, Vijay Sekhri
wrote:
> Hi Shawn, Erick
> So it turned out that once we increased our indexing rate t
not happen. We write gc logs to separate file and also
monitored these process via visualvm . It seems to have enough memory
On Mon, Jan 26, 2015 at 5:13 PM, Shawn Heisey wrote:
> On 1/26/2015 2:26 PM, Vijay Sekhri wrote:
> > Hi Erick,
> > In solr.xml file I had zk timeout set
archerExecutor-6-thread-1]: delete
"_5co_a.del"
14:16:58,367 INFO [org.apache.solr.update.LoggingInfoStream]
(searcherExecutor-6-thread-1) [IFD][searcherExecutor-6-thread-1]: delete
"_5q0_6.del"
14:16:58,367 INFO [org.apache.solr.update.LoggingInfoStream]
(searcherExecutor-6-thread-1) [
--
*
Vijay Sekhri
*
Hi Erick,
In solr.xml file I had zk timeout set to* ${zkClientTimeout:45}*
One thing that made a it a bit better now is the zk tick time and syncLimit
settings. I set it to a higher value as below. This may not be advisable
though.
tickTime=3
initLimit=30
syncLimit=20
Now we observed tha
27;ll hit OOM errors, but that'll give you a lower limit on what the JVM
> needs.
>
> Unless I've mis-interpreted what you've written, though, I doubt you'll get
> stable with that much memory allocated
> to the JVM.
>
> Best,
> Erick
>
>
>
> On S
goes in recovery We have increased the zookeeper timeout from 30 seconds to
5 minutes and the problem persists. Is there any setting that would fix
this issue ?
--
*
Vijay Sekhri
*
10 matches
Mail list logo
