This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 426263 - Bugzilla - handling failed xmlrpc to Issue Tracker
Bugzilla - handling failed xmlrpc to Issue Tracker
Status: CLOSED WONTFIX
Product: Bugzilla
Classification: Community
Component: WebService (Show other bugs)
3.6
All Linux
medium Severity medium (vote)
: ---
: ---
Assigned To: Jeff Fearn
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-19 12:22 EST by David Lawrence
Modified: 2013-06-24 00:19 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-21 02:54:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description David Lawrence 2007-12-19 12:22:43 EST
Question:

what happens when the xmlrpc calls fail between Bugzilla & Issue Tracker and
vice versa?

Is the data left in an inconsistent state?

Could we queue failed queries up in a database table that a cron job could pick
up and run later on?

Task:

evaluate & add documentation (in Bz in the perldoc) about the impact of failure
when xmlrpc fails to IT. Evaluate if we are handling these situations correctly.

Subject: 	Re: [engineering.redhat.com #13889]
Date: 	Fri, 13 Jul 2007 15:03:41 -0400
To: 	engineering-services@redhat.com
From: 	Lisa Davidson <llu@redhat.com>

From I-T to BZ, when an event is propagated to BZ successfully, a record
is recored in a table. On I-T UI, it will display in this format to the
RH users:
event sent to $bug $at_this_time by $this_user as $private/$public
Once an event is sent successfully, I-T user can't propagate the event
to the same bug any more.

If an event failed t propagate to BZ, I-T errors end user on the web UI.
It will allow the end user to try as many time as they want to until it
succeeds.

Regarding the failed IT score update, there is a nightly cron job to
update BZ.

Lisa

From: kbaker@redhat.com

There is an idea of storing failed xmlrpc calls in a table for later process by
a cron job.

Psuedo code:

in package

EVAL callIT( @args )
IF failed
queueCallITlater( @args )
ENDIF

later in a cron space far away

FOR each queued IT call
IF call has to many errors THEN
notify bugzilla maintainer
next
ENDIF

EVAL callIT( @args )

IF failed THEN
count error
leave on queue for a later run
ELSE
remove from queue
ENDIF
ENDFOR

From: dkl@redhat.com

We could create a queue table that has all of the columns/values of the key
value pairs that we send to IT. But if add/remove key/value pairs later on this
may be a hassle. We could just create a queue table with bug_id, it_id,
last_attempt_date, num_tries, data where data is a TEXT column with Data::Dumper
structure of the data we were trying to
send.

Dave
Comment 1 David Lawrence 2010-01-15 12:33:23 EST
Red Hat Bugzilla is now using version 3.4 of the Bugzilla codebase and
therefore this feature will need to be implemented against the new release.
Updating bug version to 3.2.
Comment 2 David Lawrence 2010-08-25 17:44:03 EDT
Red Hat has now upgraded to Bugzilla 3.6 and this bug will now be reassigned to that version. It would be helpful to the Bugzilla Development Team if this bug is verified to still be an issue with the latest version. If it is no longer an issue, then feel free to close, otherwise please comment that it is still a problem and we will try to address the issue as soon as we can.

Thanks
Bugzilla Development Team
Comment 5 Jeff Fearn 2012-05-30 00:48:02 EDT
As part of the recent Bugzilla 2.4 upgrade the Bugzilla team are cleaning up bugs opened against old versions of Bugzilla. This bug has been flagged as an old bug and will be CLOSED WONTFIX in 7 days time.

If you believe this bug is an issue in the latest Bugzilla version please comment on this bug within 7 days. Doing so will ensure this bug is not closed automatically.

Thanks, the Bugzilla team.
Comment 6 Jeff Fearn 2012-06-21 02:54:28 EDT
Closing inactive bugs are part of Bugzilla cleanup.

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