Author Topic: New Qube 5.4.2 and QubeGUI 5.4.6 Point Releases Now Available for Download  (Read 2966 times)

Scot Brew

  • Hero Member
  • *****
  • Posts: 272
    • PipelineFX

This point release adds Python 2.6 support for the Windows x64 and MacOSX
platforms.  This is primarily a bug fix release.   It includes supervisor, worker, and proxy fixes.  It adds qbkill enhancements and also addresses the per-frame stdout/stderr filtering issue introduced in 5.4.1.  The QubeGUI has a few bugfixes and minor tweaks to a few of the submission dialogs. The Maya and 3dsMax jobtypes also have also been updated.

For customers on support, this update can be downloaded directly from:


@FIX: Put back "requesting work for: " to print on stderr.
@FIX: fixed issue where modifying CPUs of a running job will mark the new subjobs as "running", but not dispatch them to a worker.
@FIX: Added back statements to print out "got work XXXX" to stderr.
@FIX: upgrade_supervisor -repair option is fixed.
@MINOR: added printing of message when supe releases global resources for "aberrant" subjobs
@FIX: Encode < > and " characters as well as & for .xja encoding.
@FIX: fixed issue where "qblock -purge" won't immediately kill off running subjobs from the worker.
@CHANGE: modified calls to qbout to qbpout in QbProxy.cpp, so that it's
   obvious to tell which lines in the workerlog are printed by which proxy
@CHANGE: "qbkill"ing a running work now always kills the subjob processing it, instead of just "interrupt"ing.
   This is a slight modification to behavior.  "qbkill" of a running work item
   used to NOT kill the subjob that's processing it, but now it does.  The old
   behavior was causing the default "qbkill" call, which requests to kill all
   work AND subjobs, to often not kill off subjobs properly, because the
   routine to kill off work items would "interrupt" the subjobs and put them
   to "pending" instead of "killed".
   This was requiring users to call "qbkill" multiple times to make sure the
   kill went thru.
   The obvious drawback is that if one wanted to really just kill a running
   work item, it will also take the subjob with it-- there's no way to kill
   just the work item (but I think it's fine).
@FIX: fix worker code so that locking and killing/migrating works properly.
   The lockCheck() routine was overwriting the "order" for subjobs that had
   previosly been set by, say, a qbkill.  For example, if a machine was locked
   without the "purge" option, then all running subjobs are marked for passive
   preemption.  Even if a user subsequently tried to kill the subjob, by using
   "qbkill", depending on the timing the worker would wipe the "kill" order
   and revert to a passive preemption for the subjob.  Code was added to the
   lockCheck() routine so that it only overwrites the "order" under specific
   conditions. see code for details.
   BUGZID: 61713
@CHANGE: Modified proxy code to print out proxy ID (jobid, subid) before all of its msgs to the workerlog.
@CHANGE: Added code to print out when the proxy exits on request (kill, interrupt, etc.)
@FIX: Added code to prepend proxy ID (jobid and subid) when the proxy outputs msgs in reportStatus().
@CHANGE: Modified proxy SIGUSR1 handler to prepend the jobID and subID, as in "[p1234.0]", to its msgs.
   Unix only so far.
@FIX: Fixed an issue with interpretting the return value of kill()
@FIX: Added code to supe to release reserved global resources when an "aberrant report" comes in from a subjob, and the subjob isn't assigned to a worker.
@CHANGE: Added code to check and print the errno when process termination had problems.
@FIX: modified so that query strings will print to error log when there was an error.
@FIX: fixed qblogin command to return 0 (zero) on success.
@FIX: blocking a running subjob now resets the "starttime".
@FIX: jobs qbmodify'ed to add more "cpus" now add subjobs with proper initial state.
   I.e., when a job is modified to add more subjobs, the new subjobs' initial
   state is now the same as the parent job, instead of always "pending".  This
   prevents the issue where "blocked" jobs are unexpectedly jump-started when
   their cpus count is increased via qbmodify.
@FIX: Fixed issue with worker_drive_map not working when there were no job-specified drive maps.
@FEATURE: Adding python 2.6 support on windows x64.
@FEATURE: Adding python 2.6 support for OSX.

@FEATURE:   Maya: Updating QubeGUI maya jobtype submission dialog to
        mirror the functionality in the in-app MEL submit dialog.
@FEATURE:   MayaBatch: Adding name.#.ext format
@FEATURE:   3dsMax Batchrender: Adding an executable choices dropdown list
        through Max 2010
@FIX:       MetaJobs: Status of metajob will now display
        "running" over "failed" or "killed"
        when evaluating the status based on the status of its jobs.
@FIX:       Changing stdout/stderr from searching for
        "request work:* got work:*" to just "got work: *" to match
        adjustments in Qube Worker 5.4.1.
@FIX:       Adjusting proc names so not to conflict with maya batchrender
        simplecmd in-app submission proc names when both in-app submission
        options are loaded in Maya.
@FIX:       SimpleCmds (File->Install AppUI): Install App UI will now create
        directories as needed when installing scripts for the in-app UI
        Addresses issue with maya jobtype, mayabatch simplecmd, and nuke
@FIX:       Handled bug when Supervisor is changed in QubeGUI and job filter
        is on.

3DStudio Max Jobtype 5.4.2
@FEATURE: Added 3ds Max 2010 support.
@FIX: Backwards compatibility fix for Max 9 (substituteString added in Max 2008)
@FIX: now uses output file path specified in the scenefile, if it's not
   given in submission.
@FIX: Added code to use a tmp copy of the scenefile on each subjob, in
   an attempt to workaround 3dsmax stalling issue.
@CHANGE: modified temp blank scene filename.
@CHANGE: Modified so that the copy of blank.max will have the hostname
   and process ID in its filename.
@FIX: added code to name the tmp logfile (pseudo-) uniquely, in an
   attempt to avoid 3dsmax deadlocks.
@FIX: modfied getAppVersion() code to guess 3dsmax version from the
   executable path, instead of from just the binary.

Maya Jobtype 5.4.3
@FIX: Fixed issue with and the way it calls
   "workspace -renderTypeEntry".
@FIX: Found and fixed a bug in the "batch mode" invocation of the maya
   The maya executable name is "maya" on Linux, but "mayaBatch.exe" on
   Windows. In batch mode, they're supposed to be translated to "Render" and
   "Render.exe" respectively, but the latter wasn't working properly.
   As a result of this issue, "batch mode" renders were "complete"-ing, but in
   fact they were failing.  The stdout from these jobs would have errors like
   the following:
   requesting work for: 340.0
   got work: 340:1 - running
   INFO: renderer not specified... using default
   -v                       prints the product version and cut number
   -batch                   for batch mode
@CHANGE: Moved the call to check for fatal errors
   (checkForFatalMayaErrors()) to earlier in the code.
   ... in order to catch errors earlier.