Bug 3495 - queue information, job count not reported to MDS
: queue information, job count not reported to MDS
Status: RESOLVED FIXED
: GRAM
wsrf discovery interface
: 4.0.0
: PC Linux
: P3 major
: 4.0.1
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2005-06-17 09:01 by
Modified: 2007-02-14 14:52 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2005-06-17 09:01:27
In the querying the DefaultIndexService of GT4 by
wsrf-query, no matter I use Condor or PBS,
the values of State element inside the ComputingElement element in the
XML is always 0 even there are queuing jobs reported by condor_q or
qstat respectively. Pls see below.
(The jobs are submitted by globusrun-ws with -Ft Condor or -Ft PBS,
and they can sucessfully run and return.)

on http://globus.org/toolkit/docs/4.0/info/key/ it says that:
----------------------------------------------------------------------
WS GRAM: The job submission service component of GT4. This WSRF service
publishes information about the local scheduler, including:

   * queue information
   * number of CPUs available and free
   * job count information
   * some memory statistics.

** But it seems that it can't. Any problem?



----extracted from WebMDS (wsrf-query results shows the same data)---
* ComputingElement:
        o Name: dque
        o UniqueID: dque
        o Info:
              + TotalCPUs: 0
        o State:
              + EstimatedResponseTime: 0
              + FreeCPUs: 0
              + RunningJobs: 0
              + Status: enabled
              + TotalJobs: 0
              + WaitingJobs: 0
              + WorstResponseTime: 0
        o Policy:
              + MaxCPUTime: 0
              + MaxRunningJobs: 0
              + MaxTotalJobs: 0
              + MaxWallClockTime: 0
              + Priority: 0
------- Comment #1 From 2005-11-02 19:30:09 -------
Neil should probably pick this up since this is an information provider issue. 
I think the two possibilities are 1) the provider is simply giving bogus values
because it is broken or doesn't actually support those values, or 2) the update
interval is too large for there to be any noticible difference when running a
relatively quick job.

There's no job description, so I can't say whether #2 is valid or not.
------- Comment #2 From 2006-10-02 14:22:46 -------
This should have been reassigned a while ago.
------- Comment #3 From 2007-02-13 13:27:00 -------
this has been fixed a while ago and never noted. closing now.