Thanks, just created SOLR-14581 as an entry point.
And sure, beers sound good! ;-)
On 17/06/2020 23:13, Erick Erickson wrote:
> Please raise a JIRA and attach your patch to that….
>
> Best,
> Erick
>
> P.S. Buy me some beers sometime if we’re even in the same place...
>
>> On Jun 17, 2020, at
Please raise a JIRA and attach your patch to that….
Best,
Erick
P.S. Buy me some beers sometime if we’re even in the same place...
> On Jun 17, 2020, at 5:00 PM, Bram Van Dam wrote:
>
> Thanks for pointing that out. I'm attaching a patch for the ref-guide
> which summarizes what you said. Mayb
Thanks for pointing that out. I'm attaching a patch for the ref-guide
which summarizes what you said. Maybe other people will find this useful
as well?
Oh and Erick, thanks for your ever thoughtful replies. Given all the
hours of your time I've soaked up over the years, you should probably
start i
Each node has its own timer that starts when it receives an update.
So in your situation, 60 seconds after any give replica gets it’s first
update, all documents that have been received in the interval will
be committed.
But note several things:
1> commits will tend to cluster for a given shard.
good
--
View this message in context:
http://lucene.472066.n3.nabble.com/Autocommit-opensearchers-and-ingestion-tp4119604p4150558.html
Sent from the Solr - User mailing list archive at Nabble.com.
On Feb 26, 2014, at 5:24 PM, Joel Cohen wrote:
> he's told me that he's doing commits in his SolrJ code
> every 1000 items (configurable). Does that override my Solr server settings?
Yes. Even if you have configured autocommit - explicit commits are explicit
commits that happen on demand. Ge
I read that blog too! Great info. I've bumped up the commit times and
turned the ingestion up a bit as well. I've upped hard commit to 5 minutes
and the soft commit to 60 seconds.
${solr.autoCommit.maxTime:30}
false
${solr.autoSoftCommit.maxTime:6}
Gopal: I'm glad somebody noticed that blog!
Joel:
For bulk loads it's a Good Thing to lengthen out
your soft autocommit interval. A lot. Every second
poor Solr is trying to open up a new searcher while
you're throwing lots of documents at it. That's what's
generating the "too many searchers" probl
This blog by Eric will help you to understand different commit option and
transaction logs and it does provide some recommendation for ingestion
process.
http://searchhub.org/2013/08/23/understanding-transaction-logs-softcommit-and-commit-in-sorlcloud/
On Tue, Feb 25, 2014 at 11:40 AM, Furkan KA
Hi;
You should read here:
http://wiki.apache.org/solr/FAQ#What_does_.22exceeded_limit_of_maxWarmingSearchers.3DX.22_mean.3F
On the other hand do you have 4 Zookeeper instances as a quorum?
Thanks;
Furkan KAMACI
2014-02-25 20:31 GMT+02:00 Joel Cohen :
> Hi all,
>
> I'm working with Solr 4.6.1
Hi Shawn,
Thanks for the lesson! I really appreciate your help.
I'll figure out a way to use that knowledge to solve my problem.
Best Regards
--
View this message in context:
http://lucene.472066.n3.nabble.com/Autocommit-and-replication-have-been-slowing-down-tp4058361p4058584.html
Sent from
On 4/23/2013 3:44 PM, gustavonasu wrote:
If I understand well the autoWarmCount is the number of elements used from
the cache for new searches. I guess that this isn't the problem because
after the commit property increases on the "UPDATE HANDLERS" (admin UI) I
can see the new docs in the searche
Hi Shawn,
Thanks for the answer.
If I understand well the autoWarmCount is the number of elements used from
the cache for new searches. I guess that this isn't the problem because
after the commit property increases on the "UPDATE HANDLERS" (admin UI) I
can see the new docs in the searches result
On 4/23/2013 11:27 AM, gustavonasu wrote:
We migrated recently from Solr 1.4 to 3.6.1. In the new version we have
noticed that after some hours (around 8) the autocommit is taking more time
to be executed.
In the new version we have noticed that after some hours the autocommit
is takin
, 2011 12:00 AM
To: solr-user@lucene.apache.org
Subject: Re: Autocommit & Index Size
On 12/6/2011 1:01 AM, Husain, Yavar wrote:
> In solrconfig.xml I was experimenting with Indexing Performance. When I set
> the maxDocs (in autoCommit) to say 1 documents the index size is double
>
On 12/6/2011 1:01 AM, Husain, Yavar wrote:
In solrconfig.xml I was experimenting with Indexing Performance. When I set the
maxDocs (in autoCommit) to say 1 documents the index size is double to if I
just dont use autoCommit (i.e. keep it commented, i.e commit at the end only
after adding d
It means they never happen automatically, added documents wont' be committed
until you send a commit to solr.
Jonathan
From: Brian Whitman [br...@echonest.com]
Sent: Saturday, December 04, 2010 10:36 AM
To: solr-user@lucene.apache.org
Subject: autocommit
On Sat, Dec 4, 2010 at 10:36 AM, Brian Whitman wrote:
> Hi, if you comment out the block in solrconfig.xml
>
>
>
> Does this mean that (a) commits never happen automatically or (b) some
> default autocommit is applied?
Commented out means they never happen automatically (i.e., no default).
In ge
I'll see you, and raise. My solrconfig.xml wasn't being copied to the server by
the deployment script.
On Jul 23, 2010, at 3:26 PM, Jay Luker wrote:
> For the sake of any future googlers I'll report my own clueless but
> thankfully brief struggle with autocommit.
>
> There are two parts to the
For the sake of any future googlers I'll report my own clueless but
thankfully brief struggle with autocommit.
There are two parts to the story: Part One is where I realize my
config was not contained within my . In
Part Two I realized I had typed "" rather than
"".
--jay
On Fri, Jul 23, 2010 a
On Jul 23, 2010, at 9:37 AM, John DeRosa wrote:
> Hi! I'm a Solr newbie, and I don't understand why autocommits aren't
> happening in my Solr installation.
>
[snip]
"Never mind"... I have discovered my boneheaded mistake. It's so silly, I wish
I could retract my question from the archives.
On Jul 23, 2010, at 9:37 AM, John DeRosa wrote:
> Hi! I'm a Solr newbie, and I don't understand why autocommits aren't
> happening in my Solr installation.
>
> My one server running Solr:
>
> - Ubuntu 10.04 (Lucid Lynx), with all the latest updates.
> - Solr 1.4.0 running on Tomcat6
> - Install
Thanks Mike, I'm running it in a few environments that do not have
post-commit hooks and so far have not seen any issues. A white-box review
will be helpful in seeing things that may rarely occur, or if I had any
misuse if internal data structures that I do not know well enough to
measure.
--j
Hi Jayson,
It is on my list of things to do. I've been having a very busy week
and and am also working all weekend. I hope to get to it next week
sometime, if no-one else has taken it.
cheers,
-mike
On 8-May-09, at 10:15 PM, jayson.minard wrote:
First cut of updated handler now in:
ht
Indexing speed comes down to a lot of factors. The settings as talked about
above, VM settings, the size of the documents, how many are sent at a time,
how active you can keep the indexer (i.e. one thread sending documents lets
the indexer relax whereas N threads keeps pressure on the indexer), h
Siddharth,
The settings you have in your solrconfig for ramBufferSizeMB and
maxBufferedDocs control how much memory may be used during indexing besides
any overhead with the documents being "in-flight" at a given moment
(deserialized into memory but not yet handed to lucene). There are
streaming
to complete.
>
> Thanks,
> Siddharth
>
> -Original Message-
> From: jayson.minard [mailto:jayson.min...@gmail.com]
> Sent: Saturday, May 09, 2009 10:45 AM
> To: solr-user@lucene.apache.org
> Subject: Re: Autocommit blocking adds? AutoCommit Speedup?
>
>
&g
of the memory consumption by this queue if commit takes
much longer to complete.
Thanks,
Siddharth
-Original Message-
From: jayson.minard [mailto:jayson.min...@gmail.com]
Sent: Saturday, May 09, 2009 10:45 AM
To: solr-user@lucene.apache.org
Subject: Re: Autocommit blocking adds? AutoCommit
First cut of updated handler now in:
https://issues.apache.org/jira/browse/SOLR-1155
Needs review from those that know Lucene better, and double check for errors
in locking or other areas of the code. Thanks.
--j
jayson.minard wrote:
>
> Can we move this to patch files within the JIRA issue
Can we move this to patch files within the JIRA issue please. Will make it
easier to review and help out a as a patch to current trunk.
--j
Jim Murphy wrote:
>
>
>
> Yonik Seeley-2 wrote:
>>
>> ...your code snippit elided and edited below ...
>>
>
>
>
> Don't take this code as correct
Yonik Seeley-2 wrote:
>
> ...your code snippit elided and edited below ...
>
Don't take this code as correct (or even compiling) but is this the essence?
I moved shared access to the writer inside the read lock and kept the other
non-commit bits to the write lock. I'd need to rethink the
Created issue:
https://issues.apache.org/jira/browse/SOLR-1155
Jim Murphy wrote:
>
> Any pointers to this newer more concurrent behavior in lucene? I can try
> an experiment where I downgrade the iwCommit lock to the iwAccess lock to
> allow updates to happen during commit.
>
> Would you
On Fri, May 8, 2009 at 4:27 PM, Jim Murphy wrote:
>
> Any pointers to this newer more concurrent behavior in lucene?
At the API level we care about, IndexWriter.commit() instead of close()
Also, we shouldn't have to worry about other parts of the code closing
the writer on us since things like d
Any pointers to this newer more concurrent behavior in lucene? I can try an
experiment where I downgrade the iwCommit lock to the iwAccess lock to allow
updates to happen during commit.
Would you expect that to work?
Thanks for bootstrapping me on this.
Jim
Yonik Seeley-2 wrote:
>
> On
On Thu, May 7, 2009 at 8:37 PM, Jim Murphy wrote:
> Interesting. So is there a JIRA ticket open for this already? Any chance of
> getting it into 1.4?
No ticket currently open, but IMO it could make it for 1.4.
> Its seriously kicking out butts right now. We write
> into our masters with ~50ms
Interesting. So is there a JIRA ticket open for this already? Any chance of
getting it into 1.4? Its seriously kicking out butts right now. We write
into our masters with ~50ms response times till we hit the autocommit then
add/update response time is 10-30 seconds. Ouch.
I'd be willing to wo
On Thu, May 7, 2009 at 5:03 PM, Jim Murphy wrote:
> Question 1: I see in DirectUpdateHandler2 that there is a read/Write lock
> used between addDoc and commit.
>
> My mental model of the process was this: clients can add/update documents
> until the auto commit threshold was hit. At that point th
Hi Yonik,
Thanks for the response. If I shut down tomcat cleanly, does it
commit all uncommitted documents?
Best,
Jacob
-- Forwarded message --
From: Yonik Seeley
Date: Tue, Mar 24, 2009 at 8:48 PM
Subject: Re: autocommit and crashing tomcat
To: solr-user@lucene.apache.org
On Tue, Mar 24, 2009 at 5:52 AM, Jacob Singh wrote:
> If I'm using autocommit, and I have a crash of tomcat (or the whole
> machine) while there are still docs pending, will I lose those
> documents in limbo
Yep.
> If the answer is "they go away": Is there anyway to ensure integrity
> of an upda
> > I already posted a while ago a problem that one of the solr threads
> > starts using 100% of one of the processor cores on a 4 core
> > system.
>
> This sounds like warming / autowarming.
> The other possibility is garbage collection.
What can I do here? Decrease the autowarmcount?
My curren
On Dec 12, 2007 6:15 PM, Michael Thessel <[EMAIL PROTECTED]> wrote:
> I already posted a while ago a problem that one of the solr threads
> starts using 100% of one of the processor cores on a 4 core
> system.
This sounds like warming / autowarming.
The other possibility is garbage collection.
>
Thanks, Ryan
-Original Message-
From: Ryan McKinley [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 03, 2007 11:32 AM
To: solr-user@lucene.apache.org
Subject: Re: autocommit not working for delete?
Check:
https://issues.apache.org/jira/browse/SOLR-283
This is now fixed in trunk
ryan
Check:
https://issues.apache.org/jira/browse/SOLR-283
This is now fixed in trunk
ryan
Xuesong Luo wrote:
Hi,
I set up solr to autocommit each minute. It works well if I sent an add
request, but it does not work for delete, nothing happened after 1
minute. Is this a bug or a designed behavior?
43 matches
Mail list logo
