Bug 1410559 - [Intel CP Bug] Runtime Error Lock wait timeout exceeded; try restarting transaction at com.mysql.jdbc.SQLError.createSQLException:1,078
Summary: [Intel CP Bug] Runtime Error Lock wait timeout exceeded; try restarting trans...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Candlepin
Classification: Community
Component: candlepin
Version: 0.9.51
Hardware: x86_64
OS: Linux
high
high
Target Milestone: ---
: ---
Assignee: candlepin-bugs
QA Contact: Katello QA List
URL:
Whiteboard:
Depends On:
Blocks: 1691630
TreeView+ depends on / blocked
 
Reported: 2017-01-05 18:23 UTC by Brian J. Murrell
Modified: 2019-09-20 15:31 UTC (History)
15 users (show)

Fixed In Version: candlepin-2.9.0-1
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-09-20 15:31:12 UTC


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1357117 1 None None None 2021-01-20 06:05:38 UTC
Red Hat Bugzilla 1561798 0 urgent CLOSED While attaching a subscription using pool id subscription-manager returns "Runtime Error could not extract ResultSet at ... 2021-02-22 00:41:40 UTC

Internal Links: 1357117 1561798

Description Brian J. Murrell 2017-01-05 18:23:59 UTC
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:

Comment 2 Brian J. Murrell 2017-01-06 13:05:13 UTC
You are not authorized to access bug #1322853.

That's what I get when I try to view the See Also: link.

Comment 3 Travis Gummels 2017-01-06 20:51:54 UTC
(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

Comment 6 vritant 2017-01-16 15:49:03 UTC
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.

Comment 7 Brian J. Murrell 2017-01-16 22:36:13 UTC
(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.

Comment 8 Travis Gummels 2017-01-16 23:02:17 UTC
(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.

Comment 9 Brian J. Murrell 2017-01-17 00:04:21 UTC
(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.

Comment 15 Travis Gummels 2018-01-15 18:38:55 UTC
Brian,

Do you continue to be impacted by this bug?  Please let me know.

Thank you,

Travis

Comment 17 Brian J. Murrell 2018-01-30 20:50:45 UTC
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.

Comment 18 Barnaby Court 2019-09-20 15:31:12 UTC
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.).


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