Bug 857176 - Coordinator archived calls collection grows without bound
Coordinator archived calls collection grows without bound
Status: CLOSED CURRENTRELEASE
Product: Pulp
Classification: Community
Component: async/tasks (Show other bugs)
2.0.6
Unspecified Unspecified
unspecified Severity urgent
: ---
: Sprint 40
Assigned To: Jason Connor
Preethi Thomas
:
Depends On:
Blocks: 848520 857177
  Show dependency treegraph
 
Reported: 2012-09-13 14:07 EDT by Jay Dobies
Modified: 2014-03-30 21:40 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 857177 (view as bug list)
Environment:
Last Closed: 2013-01-07 09:10:08 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jay Dobies 2012-09-13 14:07:14 EDT
This first came up as part of the v0002.py migration script. Two developers ran into an issue running the script which is suspected to be because the collection was too full.

The issue boils down to a central coordinator collection growing without boundary. If this was indeed the issue that the developers saw with the migration script, this is really bad; development environments don't typically see the level of uptime or usage an actual server would.
Comment 1 Jason Connor 2012-09-13 19:02:41 EDT
Added a reaper thread and timestamps to archived calls in order to periodically clean them out
Comment 2 Jeff Ortel 2012-09-17 18:56:27 EDT
build: 2.0.4
Comment 3 Jay Dobies 2012-09-19 10:53:01 EDT
Jason - Can you give Preethi an idea of how to verify this? We should be able to tell her to set the reaper to something like 30 minutes, do some stuff, and then leave the server alone for 30 minutes and make sure there's nothing left. Can you give her the info on that config option and the mongo query to check that the collection is empty?
Comment 4 Jason Connor 2012-09-19 15:11:44 EDT
there's a new config value under [tasks] called: archived_call_lifetime
1:09 it's the length of time, in hours, to keep archived calls
1:10 the archived call db collection is: archived_calls
1:10 you can watch that collection grow as you execute tasks through the REST API
1:10 for instance, create a repo, sync a repo, publish a repo should result in 3 archived calls
just set the config value to something nice and low, say 0
1:11 and watch them get cleaned up
Comment 5 Preethi Thomas 2012-09-20 13:25:42 EDT
verified

[root@preethi-el6-pulp ~]# rpm -q pulp-rpm-server
pulp-rpm-server-2.0.5-1.el6.noarch
[root@preethi-el6-pulp ~]# 

 [tasks]
     concurrency_threshold: 9
     dispatch_interval: 0.5
     archived_call_lifetime: 1
     consumer_content_weight: 0
     create_weight: 0
     publish_weight: 1
     sync_weight: 2

after running repo create, sync, and publish waited for over and hour and checked the db

 db.archived_calls.find()

saw no archived calls
Comment 6 Jay Dobies 2013-01-03 15:03:02 EST
Moving these up against the 2.0 Beta so we can delete the CR-2 version from bugzilla.
Comment 7 Preethi Thomas 2013-01-07 09:10:08 EST
Pulp 2.0 released.

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