Hide Forgot
Description of problem: When registering, unregistering, and (likely) binding, entitlement, product, and identity certificates are re-read many times over, and the GUI is refreshed repeatedly. Version-Release number of selected component (if applicable): subscription-manager-0.96.3-1 How reproducible: Very. Steps to Reproduce: 1. tail -f /var/log/rhsm/rhsm.log 2. Unregister from a server. Actual results: In the rhsm.log output you will see *multiple* instances of: 2011-07-11 14:27:03,042 [DEBUG] @certlib.py:675 - Sorting product and entitlement cert status for: 2011-07-11 14:27:03.042224 2011-07-11 14:27:03,043 [DEBUG] @certlib.py:693 - Installed product IDs: ['37060'] 2011-07-11 14:27:03,044 [DEBUG] @certlib.py:684 - valid entitled products: [] 2011-07-11 14:27:03,044 [DEBUG] @certlib.py:685 - expired entitled products: [] Expected results: This should happen just once, or at least as little as possible. Additional info: These appear to all be triggering via the managergui.py MainWindow.refresh method. I believe this is related to the Backend classes file monitors. We monitor directories, I suspect the monitors are triggering once per file change. i.e. if we unregister, the identity cert, key, and their directory all get deleted, suspect this is triggering 3x refreshes right here. Secondly, the file monitors catch changes that are also dealt with explicitly in the code. For example, managergui.py _on_unregister_prompt_response method calls refresh explicitly, but the unregistration is also caught by the identity certificate file monitor. The same goes for registration refresh. I suspect if you have a number of entitlement certificates and unregister, you'll get additional GUI refreshes if you unregister and they all get removed. Marked as low priority because, while this is messy and strange, the UI still seems acceptably responsive. It should get fixed eventually however. Proposed fix: If possible, we should get the file monitors to only trigger once, perhaps monitoring the identity cert itself instead of the directory it lives in. Secondly we should examine calls to refresh() in managergui, and eliminate those that are duplicated by the monitors for identity and entitlement certificates. (let the file monitors trigger the refreshes)
As another example, on a bind, I think we re-read all certificates 6 times.
Another possible culprit, rather than the file monitors triggering for every change to any file in the dir (just a guess), it could perhaps be multiple Backend objects floating around, all triggering their own file monitors.
*** Bug 723051 has been marked as a duplicate of this bug. ***
Moved priority to high as it is a blocker for QA.
After changing the file monitor to use the polling implementation, GUI refreshes are kept to a minimum as the monitor seems to emit the correct number of changes. Committed to master branch: e7eae1b8f16dc943f32876448fcd5f28be8434d3 This should address the slowness that QA have been seeing when doing an auto subscribe with a lot of products, as well as cut down on some of the multiple GUI refreshes. i.e sudo subscription-manager subscribe --auto That being said, we should still look at trying to minimize the number of ways that the GUI is being refreshed (see Proposed Fix above). In light of this, I am lowering the priority of this bug, and moving it back to new so that it can be addressed at some other point. At this point I don't think it is a show stopper.
I have verified that this is no longer a blocker, the gui now completes the refresh in a reasonable amount of time as of versions: subscription-manager-gnome-0.96.4-1.git.47.e65faae.el6.x86_64 subscription-manager-0.96.4-1.git.47.e65faae.el6.x86_64 subscription-manager-firstboot-0.96.4-1.git.47.e65faae.el6.x86_64 python-rhsm-0.96.7-1.git.4.ae2c338.el6.noarch I am leaving the status as NEW as per comment 6 .
work on this will be continued in bug 723992. Original defect has been fixed in comment 6 and verified in comment 7.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2011-1695.html