Description of problem: More and more frequently we are seeing: # subscription-manager attach --pool=... Runtime Error Lock wait timeout exceeded; try restarting transaction at com.mysql.jdbc.SQLError.createSQLException:1,078 errors Version-Release number of selected component (if applicable): subscription-manager-1.16.8-8.el6.x86_64 How reproducible: Intermittent bug frequent Steps to Reproduce: 1. Install RHEL 6[.8] 2. Use subscription-manager to register and the attach subscriptions Actual results: Runtime Error Lock wait timeout exceeded; try restarting transaction at com.mysql.jdbc.SQLError.createSQLException:1,078 Expected results: Should just attach successfully Additional info:
You are not authorized to access bug #1322853. That's what I get when I try to view the See Also: link.
(In reply to Brian J. Murrell from comment #2) > You are not authorized to access bug #1322853. > > That's what I get when I try to view the See Also: link. That would be because it is a Red Hat internal bug. I was performing research and wanted to stash that ID away for reference. On another note you reported this same defect against the Entitlements product (seen on RHEL 7): Bug 1390629 - Runtime Error Lock wait timeout exceeded ... I'll work on seeing if someone can look in to these. Travis
Brian, How many concurrent bind requests against the same pool were active at the time of the error? Please provide the consumer ids of the consumers, so we could investigate further.
(In reply to vritant from comment #6) > Brian, > How many concurrent bind requests against the same pool were active at the > time of the error? Does this mean how many nodes did we have registered against the same pool at the same time? If so, I cannot possibly know this. This pool can be used by any engineer at Intel. > Please provide the consumer ids of the consumers, so we could investigate > further. That list is never static. Even within our own group, we are constantly registering and unregistering hosts so how many are in use at any one time is impossible to determine.
(In reply to Brian J. Murrell from comment #7) > (In reply to vritant from comment #6) > > Brian, > > How many concurrent bind requests against the same pool were active at the > > time of the error? > > Does this mean how many nodes did we have registered against the same pool > at the same time? I believe what is being asked is how many systems from your automated framework are registering all at the same time. I.e. how many registrations are in flight when you see the issue. Maybe. > If so, I cannot possibly know this. This pool can be used by any engineer > at Intel. > > > Please provide the consumer ids of the consumers, so we could investigate > > further. > > That list is never static. Even within our own group, we are constantly > registering and unregistering hosts so how many are in use at any one time > is impossible to determine. I wonder if you had time stamps when you saw this issue if that could be correlated to the account to glean the details being requested.
(In reply to Travis Gummels from comment #8) > > I believe what is being asked is how many systems from your automated > framework are registering all at the same time. So, we deploy 8 nodes in parallel that want to register. Timing of course could mean that all 8 don't necessarily start registering at the exact same time or even are running in parallel, but odds are good that more than one will be running at a time.
Brian, Do you continue to be impacted by this bug? Please let me know. Thank you, Travis
It could very well be masked now by the retry loops[1] that we wrap around all of our subscription-manager invocations. [1] just because it fails once or twice or even three times doesn't mean that if I keep trying it won't succeed eventually -- unfortunately. Or well, fortunately I guess for persistence, unfortunately for software quality and predictability.
Given the amount of work that has gone into auto-attach speed over the past 2 years I am closing this as current release. If you are still seeing this issue, please re-open with new details of your specific case (account, number & type of subscription pools, consumer count, etc.).