Project

General

Profile

Bug #19157

"DOCumenteation" devices cause infinite downloads on OACs, MACALC

Added by Dennis Nicklaus about 3 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Start date:
02/27/2018
Due date:
% Done:

0%

Estimated time:
Duration:

Description

We discovered that MACALC was in a seemingly infinite loop of repeating its downloadComplete method actions. In the case of MACALC, downloadComplete kicks off starting the jobs for the equations for each of the devices. No known recent code changes.
By turning on ClassBugs in oac/OpenAccessClientDownload, we found messages like this:

OACDownload, downloadClient() on entry: OACDownload MACALC, additionalDownloadItem: AcceleratorDevic
esItem, number = 4, including AcceleratorObject: name: null, di: 151501, pr: 12, len: 0, off: 0, set
: false, ready: false, underTest: false, dbChange: true

So device DI 151501 triggering the download. That device was in the "Documentation" state.
We "undocumented the device" repeated the process a few times with additional devices, and got MACALC to stop repeating its download processing.

This is a list of the MACALC devices we undocumented:

  • I:TR714S - this device was moved to CACHE
  • I:TR702S
  • I:TR521S
  • I:TRF16S

But there's nothing internally unique about this to MACALC. It's just that MACALC has a particularly heavy amount of processing upon downloadComplete.

I strongly suspect that MACALC had been in this bad continually downloading state since Jan. 5, 2018, when Aisha DOCumented the devices.

I also found an email chain from 4/10/2012 that had described a similar situation (but at that time the problem might have been with OBSolete devices still having expressions). Here's my end of that conversation.

OK, bwbarnes OBSed several macalc devices on March 30. anybody looked at the dce10 log between then and today to see it is
rolling over? didn't think so.
My guess is it has been downloading since then.
None of the devices he OBSed are in dataloggers, but grep finds one, r:cbktln is read by the PBARSA OAC.
I unobs-ed it:
Result: MACALC OAC Download complete #1
and it stops.

(Notable diff. When the problem was with the device in the datalogger, you got a few seconds or minutes before
the oac started repetitively downloading. In this case, it started almost immediately after the 1st download.)

Crapola. I don't suppose you can make dabbel grep for the device being used anywhere in any application, huh?
No. Well, then I think we (meaning Charlie) should change the OAC code to be smarter about not downloading so much
in a row.

Dennis

On 4/10/2012 2:08 PM, Dennis Nicklaus wrote:

Grepping for brite or the DI's of t:pbrite and t:abrite in /usr/local/dae/gov/controls/oac turns up no matches.
So I have no idea who'se pushing those to a client logger.

In other news, after Brian unobsoleted those 2 devices, I restarted MAcalc's engine, twice, and it just immediately
goes into its download loop.
I've asked Glenn for a deeper history of obsoleted devices since it doesn't seem to be the BRITE devices causing
the problem (though they probably would, too).

History

#1 Updated by Richard Neswold over 2 years ago

  • Status changed from New to Assigned

I think this has been fixed. Charlie, can you confirm?

#2 Updated by Charles King over 2 years ago

  • Status changed from Assigned to Closed

The OAC automatic download code is now aware of documented devices and will not schedule a new download when these devices are requested.

Also available in: Atom PDF