Sharing a possible bug we found on 8.3.9 with the Core Historian, in case it's useful to others.
An averaged system.tag.queryTagHistory whose startDate is exactly the epoch (Date(0)) doesn't return when there's stored data in the range. The gateway thread keeps running at 100% of one core until the gateway restarts. The same query starting 1 ms later returns right away.
Reproduction in the Script Console (the Date(0) query leaves a running thread until restart):
from java.util import Date
path = '[default]Your/Historized/Tag'
now = system.date.now()
for start in (Date(1), Date(0)):
ds = system.tag.queryTagHistory(paths=[path], startDate=start, endDate=now, returnSize=300,
aggregationMode='Average', returnFormat='Wide', timeout=15000)
print start.getTime(), ds.getRowCount()
Date(1) returns immediately. Date(0) times out with "Gateway Error 500", and gateway CPU stays one core higher afterwards.
We found it through a Perspective binding that polled every 5 s and took its start date from a DateTime tag that reads 1970-01-01 (Good_Initial) until it's set. Each poll left another running thread. After about 30 minutes there were 290 of them and all 24 cores were busy. timeout= didn't limit it, since it isn't used in gateway scope.
Each thread was in:
CalculatingResultNode.finishAggregationWindow(CalculatingResultNode.java:133)
CalculatingResultNode.processValue(CalculatingResultNode.java:214)
HistorianDataColumn.processValue(HistorianDataColumn.java:122)
From the bytecode, finishAggregationWindow appears to treat currentBlock == 0 as "no window yet". With a query start of 0, the window doesn't advance, so the while (currentBlock < blockId) loop in processValue doesn't end.
Avoiding a start date of exactly the epoch prevents it.