Project

General

Profile

Bug #2108

Frontend advertise not properly handling the update number

Added by Igor Sfiligoi about 9 years ago. Updated over 8 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Parag Mhashilkar
Category:
Integration with Condor
Target version:
Start date:
12/05/2011
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)
First Occurred:
Occurs In:
Stakeholders:
Duration:

Description

Hi all.

These is something wrong in how we use condor_advertise in the frontend;
the collector is not properly setting UpdatesHistory and UpdatesLost.

I know we have occasional failures in advertisement
(reported by VO Fronted admins)
yet the UpdateHistory is perfect:
gfactory@glidein-1$ condor_status -master -const 'GLIDEINMyType=?="glideclient"' -format '%s\n' UpdatesHistory |sort |uniq -c
458 0x00000000000000000000000000000000
gfactory@glidein-1$ condor_status -master -const 'GLIDEINMyType=?="glideclient"' -format '%s\n' UpdatesLost |sort |uniq -c
458 0

Can someone please investigate?

Thanks,
Igor

PS: All our frontends now use -tcp and -multi


Subtasks

Bug #2261: Handle UpdateSequenceNumber for v3+ClosedKrista Larson

History

#1 Updated by Parag Mhashilkar about 9 years ago

  • Category set to Integration with Condor
  • Assignee set to Parag Mhashilkar
  • Target version set to v2_5_4

#2 Updated by Parag Mhashilkar about 9 years ago

  • Status changed from New to Assigned

Did you ever see that in glideclient classads? I do not see anywhere in the code that we track UpdateSequenceNumber for classads except glidefactory.

I will add UpdateSequenceNumber tracking to glideclient, glidefactoryclient & glideresource classads

#3 Updated by Parag Mhashilkar about 9 years ago

  • Status changed from Assigned to Resolved

Now we advertise UpdateSequenceNumber for glideclient, glidefactoryclient and glideresource classads. commit:415cfe6d

#4 Updated by Parag Mhashilkar almost 9 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF