Bug 3495 – queue information, job count not reported to MDS

Bug 3495 - queue information, job count not reported to MDS

Summary:

queue information, job count not reported to MDS

Status:	RESOLVED FIXED

Product:	GRAM
Component:	wsrf discovery interface
Version:	4.0.0
Platform:	PC Linux

Importance:	P3 major
Target Milestone:	4.0.1
Assigned To:	Neill Miller

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2005-06-17 09:01 by Alex
Modified:	2007-02-14 14:52 (History)

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note

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

Description From Alex 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 Peter Lane 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 Peter Lane 2006-10-02 14:22:46 -------

This should have been reassigned a while ago.

------- Comment #3 From Neill Miller 2007-02-13 13:27:00 -------

this has been fixed a while ago and never noted. closing now.