Wait - the JPLEPH.405 file shouldn't have a tag, right?
Why then does the server (here: locality scheduler) knows about the file at all, so it can send a delete request?
BM
Well, whether or not there's a tag, the v7.0.44 sched_request file contains (now - after your fix):
Quote:
...
l1_0424.00_S6GC1
7624592.000000
1
JPLEPH.405
9319680.000000
1
Repeating the 'fetch FGRP', 'start running', 'fetch other work' cycle now no longer triggers the 'will delete' message in either the sched_reply file or the server log - and it remains in client_state.
Maybe implies an automatic ? There's no tag like that on the GW files either.
Anyway, whatever the mechanism, Sherlock and Dr. Watson are claiming another bugsplat ;)
Maybe implies an automatic ? There's no tag like that on the GW files either.
It does now, since DA "simplified handling of sticky files" in the Client.
I know, however, of no other project that will be affected, i.e. that does have locality- and non-locality applications, both having "sticky" files, but only a subset of these being managed by one scheduler.
You will probably find the tag in the scheduler_reply and also in the client_state.xml of 6.12. and older Clients. Newer Clients simply ignore it, don't put it in the client_state.xml and just report any file that has a tag. And yes, when these get a "delete" message from the scheduler, they simply remove the tag, instead of tagging it with as earlier Clients did.
I built and published a new Linux App (0.02) which should fix this problem fo rnow. For a number of reasons this doesn't include David's fix, but instead was built with an old version of the BOINC API that is known to work.
BM
This definitely fixed it here, thanks. The old 0.01 app always failed within a few seconds, the new 0.02 app has been rock solid on linux, both 7.0.28 and 7.1-prerelease (probably 7.0.36/.37, as Claggy explained above).
I got the same no heartbeat problem on Mac OS 10.6.8 with Boinc 7.0.44 and 47, any chance for an official release of the 0.02 app for this platform too?
I got the same no heartbeat problem on Mac OS 10.6.8 with Boinc 7.0.44 and 47, any chance for an official release of the 0.02 app for this platform too?
I'm currently testing a fresh new build v. 1.04 for all platforms over at [http://albert.phys.uwm.edu]Albert@Home[/url].
When this comes out successful, this version will be published here on Einstein.
I got the same no heartbeat problem on Mac OS 10.6.8 with Boinc 7.0.44 and 47, any chance for an official release of the 0.02 app for this platform too?
I'm currently testing a fresh new build v. 1.04 for all platforms over at [http://albert.phys.uwm.edu]Albert@Home[/url].
When this comes out successful, this version will be published here on Einstein.
I got the same no heartbeat problem on Mac OS 10.6.8 with Boinc 7.0.44 and 47, any chance for an official release of the 0.02 app for this platform too?
I'm currently testing a fresh new build v. 1.04 for all platforms over at [http://albert.phys.uwm.edu]Albert@Home[/url].
When this comes out successful, this version will be published here on Einstein.
Done.
BM
Nice timing ;)
2 WUs with FGRP2 1.04 got processed and looking good, thanks.
RE: Wait - the JPLEPH.405
)
Well, whether or not there's a tag, the v7.0.44 sched_request file contains (now - after your fix):
Repeating the 'fetch FGRP', 'start running', 'fetch other work' cycle now no longer triggers the 'will delete' message in either the sched_reply file or the server log - and it remains in client_state.
Maybe implies an automatic ? There's no tag like that on the GW files either.
Anyway, whatever the mechanism, Sherlock and Dr. Watson are claiming another bugsplat ;)
Yep, we got the
)
Yep, we got the culprit.
Thanks,
Oliver
Einstein@Home Project
RE: Maybe implies an
)
It does now, since DA "simplified handling of sticky files" in the Client.
I know, however, of no other project that will be affected, i.e. that does have locality- and non-locality applications, both having "sticky" files, but only a subset of these being managed by one scheduler.
You will probably find the tag in the scheduler_reply and also in the client_state.xml of 6.12. and older Clients. Newer Clients simply ignore it, don't put it in the client_state.xml and just report any file that has a tag. And yes, when these get a "delete" message from the scheduler, they simply remove the tag, instead of tagging it with as earlier Clients did.
BM
BM
I'm
)
I'm back!!!!!!!!!!
LOL...
Good Job guys.
I'm raising your rating from 'Gold' to 'Platinum' when it comes to BOINC user customer service.
EAH... There is no substitute. Period! :-D
Al
RE: RE: I built and
)
I got the same no heartbeat problem on Mac OS 10.6.8 with Boinc 7.0.44 and 47, any chance for an official release of the 0.02 app for this platform too?
RE: Good Job guys. I'm
)
No doubt about it, I wouldn't have set up 6 hosts for any other project not to mention thinking about adding more here at home.
This is my 9th consecutive year here too.
RE: I got the same no
)
I'm currently testing a fresh new build v. 1.04 for all platforms over at [http://albert.phys.uwm.edu]Albert@Home[/url].
When this comes out successful, this version will be published here on Einstein.
BM
BM
RE: RE: I got the same no
)
Done.
BM
BM
RE: RE: RE: I got the
)
Nice timing ;)
2 WUs with FGRP2 1.04 got processed and looking good, thanks.