So, based on this scenario... the user sees that MW work is downloaded that he does not want ... so he continually resets the project and can circumvent the project limits?
This is now the fourth possible scenario (though it sounds like the only one tested) proposed ... we still have not come up with a way to prevent this from happening ... And yes, database load is an issue on MW ... so ... On the other hand, I thought recently that I *HAD* gotten work reissued to me on the occurence of an error, though I could be wrong ... On May 28, 2010, at 11:39 AM, Rattledagger wrote: > On Thu, 27 May 2010 16:09:59 -0400, you wrote: > >> One of our users has appeared to have found a way to get around the workunit >> cache limit. I was wondering if there's anything we can do about this. >> >> milky...@home has an 8 WU per core limit, and for some reason this user: >> >> http://milkyway.cs.rpi.edu/milkyway/show_host_detail.php?hostid=171705 >> >> has around 3000 tasks pending, which shouldn't be possible. >> >> Is this because of some bug, or malicious use? It really screws up some of >> the validation as a lot of those workunits are part of a quorum. >> > > Quick test, grab some work, reset project, connect to Milkyway again. > > Project haven't turned-on re-issue of "lost" wu, so client gets new work > instead. > > So basically, user doesn't need to do anything wrong, but for some of very > many > reasons, the scheduler-reply doesn't make it successfully back to client. > > For the user, if he looks on BOINC-client, the most likely result is he'll see > client asked for work, but the connection timed-out. > > For project, turning-on re-issue of "lost" work will stop this problem from > happening. But of course, it's possible due to database-performance that this > will add too much extra load so isn't an option... > > Oh, and in case someone thinks I've now got a bunch of work that will time-out > later-on, no problem, a detach & re-attach does work, and all work is marked > "client detached". ;) > > > > > -- > "I make so many mistakes. But then just think of all the mistakes > I don't make, although I might." > _______________________________________________ > boinc_dev mailing list > [email protected] > http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev > To unsubscribe, visit the above URL and > (near bottom of page) enter your email address. _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
