Message boards : Server programs : Server not handing out work units
Message board moderation
Author | Message |
---|---|
Send message Joined: 3 Aug 18 Posts: 2 |
Hey all -- I'm working on a new BOINC project. Create the server -- done. Write generator, validator, assimilator programs -- done. Write a client program -- done. Generator is running, it generated a bunch of work units. I can see them from my project's admin page. But -- any time my clients request work, the server keeps saying "no work available". The results all have a status of "inactive", and I'm wracking my brain trying to figure out how to get them to...wherever they need to be to get distributed to the clients. Can anyone suggest some things I should check? |
Send message Joined: 21 Jun 06 Posts: 156 |
Try to enable debugging in config.xml and check the scheduler.log file. |
Send message Joined: 3 Aug 18 Posts: 2 |
Ok...managed to figure this one out. I did turn on debugging, it wasn't helpful. Had to attach a debugger to my generator and go digging through the BOINC code to figure this one out... The issue was that the size_class in the DB_WORKUNIT object was getting set to 0. When the size_class is less than 0, BOINC will immediately put the work unit into UNSENT status; but when the size_class is greater than or equal to 0, it will put it into INACTIVE status instead -- and it's the responsibility of the size_regulator script to move it out of that state (which it won't do if you don't have any size classes set up on your project). I was calling clear() on the work unit object -- which should have set the size_class to -1. Except...somehow my generator got linked to the BOINC client library. DB_WORKUNIT is a sub-class of WORKUNIT, and it turns out that the client library has its own definition of WORKUNIT. So, when I called clear() on the work unit object, it was actually calling clear() on the version of WORKUNIT defined by the client libraries. That version of WORKUNIT is significantly smaller than the one used by the scheduler (so not everything was getting zeroed out), and it also wasn't setting size_class to -1 afterwards. Still not entirely sure how this happened, but best guess is "order of the libraries on the g++ command line matters". |
Copyright © 2024 University of California.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License,
Version 1.2 or any later version published by the Free Software Foundation.