On Wed, Jul 8, 2009 at 10:14 PM, solr jay wrote:
> Thanks. The patch looks good, and I now see the new index directory and it
> is in sync with the one on master. I'll do more testing.
>
> It is probably not important, but I am just curious why we switch index
> directory. I thought it would be eas
jay,
Thanks. The testcase was not enough. I have given a new patch . I
guess that should solve this
On Wed, Jul 8, 2009 at 3:48 AM, solr jay wrote:
> I guess in this case it doesn't matter whether the two directories
> tmpIndexDir and indexDir are the same or not. It looks that the index
> directo
I guess in this case it doesn't matter whether the two directories
tmpIndexDir and indexDir are the same or not. It looks that the index
directory is switched to tmpIndexDir and then it is deleted inside
"finally".
On Tue, Jul 7, 2009 at 12:31 PM, solr jay wrote:
> In fact, I saw the directory w
In fact, I saw the directory was created and then deleted.
On Tue, Jul 7, 2009 at 12:29 PM, solr jay wrote:
> Ok, Here is the problem. In the function, the two directories tmpIndexDir
> and indexDir are the same (in this case only?), and then at the end of the
> function, the directory tmpIndexD
Ok, Here is the problem. In the function, the two directories tmpIndexDir
and indexDir are the same (in this case only?), and then at the end of the
function, the directory tmpIndexDir is deleted, which deletes the new index
directory.
} finally {
delTree(tmpIndexDir);
}
On
I see. So I tried it again. Now index.properties has
#index properties
#Tue Jul 07 12:13:49 PDT 2009
index=index.20090707121349
but there is no such directory index.20090707121349 under the data
directory.
Thanks,
J
On Tue, Jul 7, 2009 at 11:50 AM, Shalin Shekhar Mangar <
shalinman...@gmail.co
On Tue, Jul 7, 2009 at 11:50 PM, solr jay wrote:
> It seemed that the patch fixed the symptom, but not the problem itself.
>
> Now the log messages looks good. After one download and installed the
> index,
> it printed out
>
> *Jul 7, 2009 10:35:10 AM org.apache.solr.handler.SnapPuller
> fetchLat
It seemed that the patch fixed the symptom, but not the problem itself.
Now the log messages looks good. After one download and installed the index,
it printed out
*Jul 7, 2009 10:35:10 AM org.apache.solr.handler.SnapPuller fetchLatestIndex
INFO: Slave in sync with master.*
but the files inside
Jay ,
I am opening an issue SOLR-1264
https://issues.apache.org/jira/browse/SOLR-1264
I have attached a patch as well . I guess that is the fix. could you
please confirm that.
On Tue, Jul 7, 2009 at 12:59 AM, solr jay wrote:
> It looks that the problem is here or before that in
> SnapPuller.fetc
It looks that the problem is here or before that in
SnapPuller.fetchLatestIndex():
terminateAndWaitFsyncService();
LOG.info("Conf files are not downloaded or are in sync");
if (isSnapNeeded) {
modifyIndexProps(tmpIndexDir.getName());
} else {
I tried it with the latest nightly build and got the same result.
Actually that was the symptom and it made me looking at the index directory.
The same log messages repeated again and again, never end.
2009/7/2 Noble Paul നോബിള് नोब्ळ्
> jay , I see updating index properties... twice
>
>
>
>
jay , I see updating index properties... twice
this should happen rarely. in your case it should have happened only
once. because you cleaned up the master only once
On Fri, Jul 3, 2009 at 6:09 AM, Otis
Gospodnetic wrote:
>
> Jay,
>
> You didn't mention which version of Solr you are using. It
it's nightly build of May 10. I'll try the latest.
Thanks,
J
On Thu, Jul 2, 2009 at 8:09 PM, Otis Gospodnetic wrote:
>
> Jay,
>
> You didn't mention which version of Solr you are using. It looks like some
> trunk or nightly version. Maybe you can try the latest nightly?
>
> Otis
> --
> Sem
Jay,
You didn't mention which version of Solr you are using. It looks like some
trunk or nightly version. Maybe you can try the latest nightly?
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
> From: solr jay
> To: solr-user@lucene.apache.org
14 matches
Mail list logo
