Thanks Jason. Appreciate your response.
Thanks
Fiz N.
On Thu, Jun 25, 2020 at 5:42 AM Jason Gerlowski
wrote:
> Hi Fiz,
>
> Since you're just looking for a POC solution, I think Solr's
> "bin/post" tool would probably help you achieve your first
> requirement.
>
> But I don't think "bin/post" gi
Hi Fiz,
Since you're just looking for a POC solution, I think Solr's
"bin/post" tool would probably help you achieve your first
requirement.
But I don't think "bin/post" gives you much control over the fields
that get indexed - if you need the file path to be stored, you might
be better off writi
: Problem solved. We gave the index space five times its original size, just
: to be safe. Then the optimize finished without problems and without
: leaving deleted, yet still open files behind. During the optimize the
: index directory peaked at almost three times its size, and now,
: afterwards,
Hi again,
Problem solved. We gave the index space five times its original size, just
to be safe. Then the optimize finished without problems and without
leaving deleted, yet still open files behind. During the optimize the
index directory peaked at almost three times its size, and now,
afterwards,
Dominik,
Form my experiences with Solr, I have seen the index double its size during
an optimize.
I always keep my index directory in a partition that has at least its triple
size, so I have a margin for optimize and for natural doc quantity growth.
2009/1/16 Dominik Schramm
> On more thing th
On more thing that might help to identify the problem source (which I've
discovered just now) -- at the time the optimize "finished" (or broke
off), Tomcat logged the following:
r...@cms004:~# /opt/apache-tomcat-sba1-live/logs/catalina.2009-01-16.log
...
Jan 16, 2009 11:40:14 AM org.apache.solr.co
So, this problem came up again. Now it only happens in a linux environment
when searches are being conducted while an index is running.
Does anything need to be closed on the searching side?
AgentHubcap wrote:
>
> As it turns out I was modifying code that wasn't being run. Running an
> opti
As it turns out I was modifying code that wasn't being run. Running an
optimize after deleting did solve my problem. =)
AgentHubcap wrote:
>
> I'm running 1.2.
>
> Acutally, i am doing an optimize after I delete the indexes. (twice, as I
> read there was an issue with the optimize). Do I
I'm running 1.2.
Acutally, i am doing an optimize after I delete the indexes. (twice, as I
read there was an issue with the optimize). Do I need to close something
manually?
Here's my optimize code:
private void optimize() throws IOException
{
UpdateHandler upd
- Delete all index files via a delete command
make sure to optimize after deleting the docs -- optimize has lucene get
rid of deleted files rather then appending them to the end of the index.
what version of solr are you running? if you are running 1.3-dev
deleting *:* is fast -- if you ar
On 3/29/07, Michael Beccaria <[EMAIL PROTECTED]> wrote:
Simple curious question from a newbie:
Can I have another computer index my data, then copy the index folder
files into my live system and run a commit?
The project idea I have is for a library catalog which will update
holdings informatio
11 matches
Mail list logo
