[ZBXNEXT-1946] Probably wrong queue calculation for items behind proxies Created: 2013 Oct 03  Updated: 2017 May 31  Resolved: 2014 Sep 04

Status: Closed
Project: ZABBIX FEATURE REQUESTS
Component/s: Frontend (F), Server (S)
Affects Version/s: 2.0.8
Fix Version/s: None

Type: Change Request Priority: Minor
Reporter: Marc Assignee: Unassigned
Resolution: Won't fix Votes: 2
Labels: calculation, flexibleintervals, proxy, queue
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by ZBX-8656 Incorrect queue calculation when item... Closed

 Description   

It's probably rather a request for improvement than a bug.

When using items with flexible intervals only (regular interval set to 0) behind proxies then the calculation of delayed items is not correct.
As soon as the time window of the flexible interval ends (5mins/day) the corresponding item gets calculated as delayed.

A quick investigation shows that flexible intervals are not taken into account behind proxies:

  1. sed -n '933,934p' src/libs/zbxdbhigh/db.c
    if (0 != proxy_hostid)
    nextcheck = lastclock + effective_delay;
  1. grep -A1 "!= \$row['proxy_hostid']" frontends/php/queue.php
    if(0 != $row['proxy_hostid']){
    $res['nextcheck'] = $row['lastclock'] + $res['delay'];
    –
    if(0 != $row['proxy_hostid']){
    $res['nextcheck'] = $row['lastclock'] + $res['delay'];
    –
    if(0 != $row['proxy_hostid']){
    $res['nextcheck'] = $row['lastclock'] + $res['delay'];

I'm sure there was a good reason for this. But is it intended to work this way for above mentioned scenarios?

 Comments   
Comment by richlv [ 2014 May 13 ]

ZBX-8202 could be related

Comment by Filipe Paternot [ 2014 May 13 ]

ZBX-8035 could be related too?

Comment by Aleksandrs Saveljevs [ 2014 Sep 04 ]

It was probably done that way to workaround the case where server and proxy clock are not synchronized.

In the latest Zabbix 2.2, where delayed item queue is calculated by the server (rather than the frontend, as in 2.0), this problem is not present (excepting the soon-to-be-fixed ZBX-8476).

So we decided not to fix it in Zabbix 2.0, which would be hard to fix in the frontend alone. For this reason, closing as "Won't fix".

Comment by Marc [ 2014 Sep 04 ]

Sounds reasonable to me.
Thanks for the explanation.

Generated at Fri Apr 19 15:16:34 EEST 2024 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.