I am getting complaints new material is not getting to RAS. EDIRC additions from Jan 8 are still not there. While they are in adrepec, they are not integrated in searchable data. Is there something that needs to be started for that? Christian Zimmermann FIGUGEGL! Department of Economics University of Connecticut 341 Mansfield Road, Unit 1063 Storrs, CT 06269-1063 http://ideas.repec.org/zimm/ christian.zimmermann@uconn.edu http://ideas.repec.org/e/pzi1.html
Christian Zimmermann writes
I am getting complaints new material is not getting to RAS.
I am afraid that while rid is interrupting itself, you will have to run a special updareq to make sure that the complained about records are added. Cheers, Thomas Krichel http://openlib.org/home/krichel http://authorclaim.org/profile/pkr1 skype: thomaskrichel
Yes this is what I am doing. But knowing a minority complain, this is not reassuring. On Thu, 13 Jan 2011, Thomas Krichel wrote:
Christian Zimmermann writes
I am getting complaints new material is not getting to RAS.
I am afraid that while rid is interrupting itself, you will have to run a special updareq to make sure that the complained about records are added.
Cheers,
Thomas Krichel http://openlib.org/home/krichel http://authorclaim.org/profile/pkr1 skype: thomaskrichel
Christian Zimmermann writes
Yes this is what I am doing. But knowing a minority complain, this is not reassuring.
I am spending yet more time trying to took into this. Cheers, Thomas Krichel http://openlib.org/home/krichel http://authorclaim.org/profile/pkr1 skype: thomaskrichel
Thomas Krichel writes
Christian Zimmermann writes
Yes this is what I am doing. But knowing a minority complain, this is not reassuring.
I am spending yet more time trying to took into this.
I tried an elaborate method today, #!/bin/bash db4.6_dump /home/aras/acis/RI/data/ACIS/records > ~/acis_records.dump db4.6_load -f acis_records.dump -h /home/aras/acis/RI/data ~/acis/RI/data/ACIS/records db4.6_load -r lsn -h /home/aras/acis/RI/data ~/acis/RI/data/ACIS/records and the ame for RePEc/records, but now found it still has helped, we still have corruption. Cheers, Thomas Krichel http://openlib.org/home/krichel http://authorclaim.org/profile/pkr1 skype: thomaskrichel
Guys, when did you have corruption errors for the first time? Was there an upgrade or something exactly before that? -ivan On Fri, Jan 14, 2011 at 11:45 PM, Thomas Krichel <krichel@openlib.org> wrote:
Thomas Krichel writes
Christian Zimmermann writes
Yes this is what I am doing. But knowing a minority complain, this is not reassuring.
I am spending yet more time trying to took into this.
I tried an elaborate method today,
#!/bin/bash db4.6_dump /home/aras/acis/RI/data/ACIS/records > ~/acis_records.dump db4.6_load -f acis_records.dump -h /home/aras/acis/RI/data ~/acis/RI/data/ACIS/records db4.6_load -r lsn -h /home/aras/acis/RI/data ~/acis/RI/data/ACIS/records
and the ame for RePEc/records, but now found it still has helped, we still have corruption.
Cheers,
Thomas Krichel http://openlib.org/home/krichel http://authorclaim.org/profile/pkr1 skype: thomaskrichel
_______________________________________________ RAS-run mailing list RAS-run@lists.openlib.org http://lists.openlib.org/cgi-bin/mailman/listinfo/ras-run
Another stupid idea: did you tweak the checks that update daemon (and/or rid script) does at it's start to ensure that only one copy of the daemon is running at any single moment? If you somehow get multiple copies of the update deamon running, there might be a chance of them corrupting the database..... But probably this is bullshit, since berkeley db has a database type for concurrent access and it was the one that I used for update daemon, I think. I just do not remember the details anymore. -i On Sat, Jan 15, 2011 at 12:15 AM, Ivan Kurmanov <duraley@gmail.com> wrote:
Guys, when did you have corruption errors for the first time? Was there an upgrade or something exactly before that?
-ivan
On Fri, Jan 14, 2011 at 11:45 PM, Thomas Krichel <krichel@openlib.org> wrote:
Thomas Krichel writes
Christian Zimmermann writes
Yes this is what I am doing. But knowing a minority complain, this is not reassuring.
I am spending yet more time trying to took into this.
I tried an elaborate method today,
#!/bin/bash db4.6_dump /home/aras/acis/RI/data/ACIS/records > ~/acis_records.dump db4.6_load -f acis_records.dump -h /home/aras/acis/RI/data ~/acis/RI/data/ACIS/records db4.6_load -r lsn -h /home/aras/acis/RI/data ~/acis/RI/data/ACIS/records
and the ame for RePEc/records, but now found it still has helped, we still have corruption.
Cheers,
Thomas Krichel http://openlib.org/home/krichel http://authorclaim.org/profile/pkr1 skype: thomaskrichel
_______________________________________________ RAS-run mailing list RAS-run@lists.openlib.org http://lists.openlib.org/cgi-bin/mailman/listinfo/ras-run
Ivan Kurmanov writes
Another stupid idea:
I am not sure about stupid ideas, but am sure about stupid guys who don't check the obvious and that is did you tweak the checks that update daemon
(and/or rid script) does at it's start to ensure that only one copy of the daemon is running at any single moment?
If you somehow get multiple copies of the update deamon running, there might be a chance of them corrupting the database.....
But probably this is bullshit, since berkeley db has a database type for concurrent access and it was the one that I used for update daemon, I think.
I tihnk you are correct, but still it's an avenue worth checking. Cheers, Thomas Krichel http://openlib.org/home/krichel http://authorclaim.org/profile/pkr1 skype: thomaskrichel
Thomas Krichel writes
Ivan Kurmanov writes
Another stupid idea:
I am not sure about stupid ideas, but am sure about stupid guys who don't check the obvious and that is
actually present, we had more than one process running. Thankn you so much. This may turn out to fix the issue... Cheers, Thomas Krichel http://openlib.org/home/krichel http://authorclaim.org/profile/pkr1 skype: thomaskrichel
The daemon itself is supposed to run several child processes. But having a single master process and a single BDB environment ensures that only a single process works on a part of the collection (ie RePEc) it works on. That is critical for database integrity. But issues you have look more like BDB or disk issues. 15.01.2011 10:38 пользователь "Thomas Krichel" <krichel@openlib.org> написал:
Thomas Krichel writes
Ivan Kurmanov writes
Another stupid idea:
I am not sure about stupid ideas, but am sure about stupid guys who don't check the obvious and that is
actually present, we had more than one process running.
Thankn you so much. This may turn out to fix the issue...
Cheers,
Thomas Krichel http://openlib.org/home/krichel http://authorclaim.org/profile/pkr1 skype: thomaskrichel
Ivan Kurmanov writes
The daemon itself is supposed to run several child processes. But having a single master process and a single BDB environment ensures that only a single process works on a part of the collection (ie RePEc) it works on. That is critical for database integrity. But issues you have look more like BDB or disk issues.
Yes. I am taking RAS down. While I was doing the reload, rid got up again. We need time to reload the databases and can't have RAS running. I will be flighing tommorrow. Argh!!! Cheers, Thomas Krichel http://openlib.org/home/krichel http://authorclaim.org/profile/pkr1 skype: thomaskrichel
participants (3)
-
Christian Zimmermann -
Ivan Kurmanov -
Thomas Krichel