Re: [RAS] Stuck: AUTOMATIC SEARCH SUGGESTIONS
That is a rather odd situation. This is the first time I see this. But we know something has been amiss in the service for the last two weeks that we have not really been able to pinpoint, and this is important information. Thanks. 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 On Sun, 21 Jun 2009, Richard Tol wrote:
Hi Christian,
My "automatic search suggestions" have been stuck in "Check the results in 20 seconds or so" for two weeks now. This function works fine for David Bradford and David Pearce (whose profiles I maintain) so I guess this is problem specific to me. If you "reboot" all profiles as part of the monthly update, then just ignore this message. If not, could you kindly have a look?
Thanks
Richard
This is simple. An obsolete record is left in the threads table in mysql, since the server shutdown/migration. I don't remember the details, but clearing that record should fix the problem immediately. I think the records in the threads table are organized by the short-id. -ivan On Sun, Jun 21, 2009 at 11:04 AM, Christian Zimmermann<christian.zimmermann@uconn.edu> wrote:
That is a rather odd situation. This is the first time I see this. But we know something has been amiss in the service for the last two weeks that we have not really been able to pinpoint, and this is important information. Thanks.
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
On Sun, 21 Jun 2009, Richard Tol wrote:
Hi Christian,
My "automatic search suggestions" have been stuck in "Check the results in 20 seconds or so" for two weeks now. This function works fine for David Bradford and David Pearce (whose profiles I maintain) so I guess this is problem specific to me. If you "reboot" all profiles as part of the monthly update, then just ignore this message. If not, could you kindly have a look?
Thanks
Richard
_______________________________________________ RAS-run mailing list RAS-run@lists.openlib.org http://lists.openlib.org/cgi-bin/mailman/listinfo/ras-run
Ivan Kurmanov writes
This is simple. An obsolete record is left in the threads table in mysql, since the server shutdown/migration.
The change of mySQL version also requires a change in the ACIS code to deal with the background searches. The code changes were not in place at the time of upgrade.
I don't remember the details, but clearing that record should fix the problem immediately.
If there are no new ones added... Looking at the table now, the threads are all old. psid type started checkpoint pto90 res-autosearch 2009-06-12 06:13:34 NULL pmi217 res-autosearch 2009-06-11 05:40:02 NULL pfu93 res-autosearch 2009-05-29 11:45:35 NULL phu74 res-autosearch 2009-05-21 10:29:18 NULL pva218 res-autosearch 2009-05-17 17:55:11 NULL I have cleared these threads. Cheers, Thomas Krichel http://openlib.org/home/krichel RePEc:per:1965-06-05:thomas_krichel skype: thomaskrichel
Thanks. Note that updating is still not working for various archives for which I have to perfom updareq after complaints. 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 On Tue, 30 Jun 2009, Thomas Krichel wrote:
Ivan Kurmanov writes
This is simple. An obsolete record is left in the threads table in mysql, since the server shutdown/migration.
The change of mySQL version also requires a change in the ACIS code to deal with the background searches. The code changes were not in place at the time of upgrade.
I don't remember the details, but clearing that record should fix the problem immediately.
If there are no new ones added...
Looking at the table now, the threads are all old.
psid type started checkpoint pto90 res-autosearch 2009-06-12 06:13:34 NULL pmi217 res-autosearch 2009-06-11 05:40:02 NULL pfu93 res-autosearch 2009-05-29 11:45:35 NULL phu74 res-autosearch 2009-05-21 10:29:18 NULL pva218 res-autosearch 2009-05-17 17:55:11 NULL
I have cleared these threads.
Cheers,
Thomas Krichel http://openlib.org/home/krichel RePEc:per:1965-06-05:thomas_krichel skype: thomaskrichel
Christian Zimmermann writes
Thanks. Note that updating is still not working for various archives for which I have to perfom updareq after complaints.
I currently don't see an error. ~/acis/RI$ grep ^Error * ~/acis/RI$ When you have done an updareq then things are normal? Then it should be just an issue of the frequency of updareq. Cheers, Thomas Krichel http://openlib.org/home/krichel RePEc:per:1965-06-05:thomas_krichel skype: thomaskrichel
No. I need to repeat updareq when new material is added. For some archives updates are not detected. 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 On Tue, 30 Jun 2009, Thomas Krichel wrote:
Christian Zimmermann writes
Thanks. Note that updating is still not working for various archives for which I have to perfom updareq after complaints.
I currently don't see an error.
~/acis/RI$ grep ^Error * ~/acis/RI$
When you have done an updareq then things are normal?
Then it should be just an issue of the frequency of updareq.
Cheers,
Thomas Krichel http://openlib.org/home/krichel RePEc:per:1965-06-05:thomas_krichel skype: thomaskrichel
Christian Zimmermann writes
No. I need to repeat updareq when new material is added. For some archives updates are not detected.
I am confused. aras@nebka:~$ crontab -l | grep updareq 33 2 * * * /home/aras/acis/bin/updareq RePEc / 1000000000 10 0 * * * /home/aras/acis/bin/updareq ACIS / 1000000000 9 4 * * * /home/aras/acis/bin/updareq citec / 1000000000 What additional command are you running? updareq RePEc /foo to update archive foo? If this fixes, it's strange because I think the default to_late parameter is a week, meaning that if update detection would fail, documents more recent than a week would not be seen. Cheers, Thomas Krichel http://openlib.org/home/krichel RePEc:per:1965-06-05:thomas_krichel skype: thomaskrichel
updareq RePEc mhr updareq RePEc taf updareq RePEc uct etc, on demand. 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 On Tue, 30 Jun 2009, Thomas Krichel wrote:
Christian Zimmermann writes
No. I need to repeat updareq when new material is added. For some archives updates are not detected.
I am confused.
aras@nebka:~$ crontab -l | grep updareq 33 2 * * * /home/aras/acis/bin/updareq RePEc / 1000000000 10 0 * * * /home/aras/acis/bin/updareq ACIS / 1000000000 9 4 * * * /home/aras/acis/bin/updareq citec / 1000000000
What additional command are you running?
updareq RePEc /foo
to update archive foo?
If this fixes, it's strange because I think the default to_late parameter is a week, meaning that if update detection would fail, documents more recent than a week would not be seen.
Cheers,
Thomas Krichel http://openlib.org/home/krichel RePEc:per:1965-06-05:thomas_krichel skype: thomaskrichel
Christian Zimmermann writes
updareq RePEc mhr updareq RePEc taf updareq RePEc uct
etc, on demand.
and then all the papers are there? verry peculiar. Cheers, Thomas Krichel http://openlib.org/home/krichel RePEc:per:1965-06-05:thomas_krichel skype: thomaskrichel
participants (3)
-
Christian Zimmermann -
Ivan Kurmanov -
Thomas Krichel