[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Pulp-list] QPID Issue Summary

On 04/12/2011 11:23 AM, Todd B Sanders wrote:
On 04/12/2011 11:50 AM, Jeff Ortel wrote:

Here's where we are with outstanding QPID related bugs:

692876 - package install hangs because gofer agent became unresponsive

The comments in this bug suggest (2) different issues and were split out into (2)
separate bugs.

What are the two bugs? I assume one in the yum file descriptor leaking, which we fixed on
our end?

Yes. The 1st bug was yum file descriptor leak, which we addressed in our code. There were two leaks. The first was by doing YumBase.closeRpmDb() which stopped the leaks to /var/lib/rpm. The second, is in yum. It adds a FileHandler on each instantiation of YumBase which causes a leak to /var/log/yum. In any case, we've addressed this.

The 2nd bug, mentioned her was split out into 692891 mentioned below.

This bug remains to call attention to David's objection to the perception to the user
when, for whatever reason, the agent does not respond. This isn't a defect but we need
to put some more thought in to the flow to mitigated this perception beyond what we did
with the heartbeat.

The heartbeat was introduced to address this, correct?

Yes. The heartbeat is used to warn users that the agent is not online. However, if the heartbeat interval is 10 seconds, a user can still issue an install package and not get a warning if the heartbeat is only 5 seconds overdue.

 Do you have any thoughts on how we
expand that to be a fail-safe in all situations?

Yes, but nothing we have time to do this sprint. I have a few options in mind but we need to discuss the trade-offs. I really haven't had time this sprint the think though them.

Recommend: We push the bug to next sprint.

692891 - gofer becomes unresponsive w/ Enqueue capacity threshold exceeded error

This bug pertains to a specific exception that caused us to stop using the
qpid-cpp-server-store. It's my understanding that only David has seen this since we
moved away from using the server-store on an F13 box. He's been running some automated
testing in an attempt to reproduce it without success. So, thread to RHUI? I /think/ low
but the nature of this bug is such that I really cant say for sure. There is always the
possibility that the pulp qpid consumer stopped consuming heartbeats when David saw this
and it was legitimate error. Not sure until we can reproduce and snoop around.

Recommend: We push the bug to next sprint and continue debugging.


695761 - QPID (python) driver goes crazy when VPN dropped between client and broker

This issue was originally reported by bkearney but I have been able to reproduce. I
don't think this presents risk to RHUI because the only way I've found to reproduce
involves a VPN. I've sent this information to the python-qpid maintainer Rafael
Schloming on several occasions (last email on 2/8 with no response).

Recommend: We push the bug to next sprint and continue debugging.

Possible that we could submit a patch to python-qpid to address the issue?

Probably, but it could take a fair amount of time to dig through the driver to understand how it works and how this can be fixed.




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]