- Timestamp:
- Oct 4, 2012, 1:00:56 PM (14 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
branches/eam_branches/ipp-20120905/Ohana/src/opihi/doc/pantasks.controller.txt
r34495 r34508 181 181 readline timeout. 182 182 183 184 183 [1] : note that the command 'controller status' includes the job and 185 184 host ID values in the form X.X.X.X where X is a hexidecimal number. 186 185 Unfortunately, pcontrol does not understand this format for the IDs 187 186 for the 'check' command. 187 188 -- 189 190 Pantasks / Controller Interactions 191 192 Pantasks Threads & Controller Interactions 193 194 Pantasks has a server/client mode and a stand-alone mode. These share 195 the bulk of code, but there are some minor difference. In stand-alone 196 mode, there are 3 active threads. The main thread interprets the 197 commands (accepted by readline); a second thread manages the tasks and 198 jobs known to pantasks; the third thread manages interactions with the 199 parallel controller. In server/client mode, a fourth thread manages 200 the communcations with the remote clients. 201 202 The task/job thread is responsible for monitoring the task rules and 203 constructing the commands which corresponds to jobs when appropriate. 204 Those jobs which are defined to be local are executed on the local 205 machine, while remote jobs are sent to the thread which interacts with 206 the parallel controller. 207 208 The primary job of the controller thread is to monitor the status of 209 jobs submitted to the controller and to harvest jobs which have 210 finished. A secondary job is to flush the stdout and stderr buffers 211 of the pantasks / pcontrol connection. 212 213 Jobs are submitted to the controller directly by the Task/Job thread. 214 Other operations, check as manual checks of the job status are 215 performed by the main thread. 216 217 Commands send to pcontrol: 218 219 In addition to the user-level commands discussed above, the following 220 messages are sent to the controller: 221 222 * jobstack exit : the controller thread checks for the set of completed 223 jobs (which did not crash) by sending this command. The response is 224 a list of jobs ready for harvest. 225 226 * jobstack crash : the controller thread checks for the set of 227 complete jobs which crashed by sending this command. The response 228 is a list of jobs ready for harvest. 229 230 * delete : jobs which have completed and for which the stderr/stdout 231 have been received can be deleted from the controller. For 232 'pcontrol', this is necessary to free up resources managing the 233 specific job. 234 235 * check job : once the controller gets a list of jobs which have 236 exited or crashed, pantasks loops over those jobs, harvesting their 237 results. this command is used to get the needed stats (size of 238 stderr buffer, size of stdout buffer, exit status, etc). 239 240 * job : Submit a job to the controller. this command is used by the 241 function SubmitControllerJob to send a new job to the controller. 242 the function appends options such as +host, -nice as needed. the 243 function expects to receive a job ID from the controller for future 244 interactions. 245 246 * quit : shutdown the controller 247 248 --- 249 250 pantasks & condor 251 252 There are three classes of pcontrol operations which pantasks 253 currently perform: 254 255 * submit jobs to pcontrol 256 * detect completion and harvest job output 257 * manage the hosts used by pcontrol 258 259 The communication between pantasks and pcontrol uses a pipe; pcontrol 260 is run as a forked child of pantasks. The communication is done via 261 text blocks with fairly minimal hand-shaking. 262 263 If pantasks is integrated with condor, it is critical that it be able 264 to perform the first two of these functions. It is not required that 265 pantasks manage the condor hosts. 266 267 Condor client / server interaction could be performed via forked 268 commands or we could use the SOAP interface. I suspect that SOAP will 269 be more effective for the high-rate job harvesting process. 270 271 However jobs are submitted to condor, it is critical that condor be 272 able to respect the limit on the number of mistargeted jobs currently 273 active.
Note:
See TracChangeset
for help on using the changeset viewer.
