Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
From: Bee <nbee15@hotmail.com>
To: "users@qpid.apache.org" <users@qpid.apache.org>
Subject: Re: qpid-0.20 Execution exception: resource-locked
Thread-Topic: qpid-0.20 Execution exception: resource-locked
Thread-Index: AQHSTy4vlXAYIZLT50ShKkQ8AFmAa6D5zVgAgAAjpm4=
Date: Mon, 5 Dec 2016 22:38:36 +0000
Message-ID: <BY2PR17MB0456C00C7E7321C26B1462C5C7830@BY2PR17MB0456.namprd17.prod.outlook.com>
References: <BY2PR17MB0456ABAB2E82139D718566ECC7830@BY2PR17MB0456.namprd17.prod.outlook.com>,<d232f897-c56b-3af5-92d9-18502d1f0f63@redhat.com>
In-Reply-To: <d232f897-c56b-3af5-92d9-18502d1f0f63@redhat.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [lQ8YJ/2Q5nxmZAe0X83N90dyEZBqafkB]
x-incomingheadercount: 39
x-eopattributedmessage: 0
x-microsoft-exchange-diagnostics: 1;CY1NAM02HT038;5:EtfLERSR1xoZWY+2I5EYOYljaNZj2WQ9Q3roAb7TQkT3/r2cUtsMC2qtJcjZCNuR4BOlWXrEhbuFRu+pQQo35g9qUAWG2+/rZpRg6MUX1t+YjxmNRip0gnlvf/3AkwklPdG1mlaxXfaY8dz32cgXXVO9zySHYOLFoktmNSkzUM8=;24:qG2Db9+krBHo6q4rcp3fVKXFkGCoDlJxUwt+cBuoCoDpvvEWBrbyOqyp1EFVU9Urhs3KKsZBbOzfvzF2JoUJqWz0vH/UzIsA9A7G8jMGOY8=;7:liXNRoZhwD80jk10T93VyalLN7dhJp2JlIVCyt0d1nSOjnKEXqpSx/9rrL49RMcNh8QpcKzdhbk6ShrM93bfVmdBd6PzyR709l0CLQor38nCRioQyRRFxaczjqEIM1TSCb8B1n/awCQoOMbMw7LR45TES3qp52LlN9JU4LaPc79SrYOFJLLmGQbPbU3Kts930/M5ne5vmMQlFxMOd+xbzhV7BWbjZ0eYSP+7Dpl+t1c287HLJvrWwSJnEH5i+5zf+LVuOIsxtp/lcFQ66W2wYfAVAKESSD74X+S8sxz+aksSm6/TQ67KEBrVw8KeT3D+X/MMoGNv2iZ860yjl5Lf6JEMjxjb56lo1j5taWqXVpA=
x-forefront-antispam-report: EFV:NLI;SFV:NSPM;SFS:(10019020)(98900003);DIR:OUT;SFP:1102;SCL:1;SRVR:CY1NAM02HT038;H:BY2PR17MB0456.namprd17.prod.outlook.com;FPR:;SPF:None;LANG:en;
x-ms-office365-filtering-correlation-id: b646e9cf-d523-492e-5b55-08d41d5f73df
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(1601124038)(1603103113)(1601125047)(1603101340);SRVR:CY1NAM02HT038;
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(432015012)(82015046);SRVR:CY1NAM02HT038;BCL:0;PCL:0;RULEID:;SRVR:CY1NAM02HT038;
x-forefront-prvs: 0147E151B5
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
	boundary="_000_BY2PR17MB0456C00C7E7321C26B1462C5C7830BY2PR17MB0456namp_"
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Dec 2016 22:38:36.7447
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1NAM02HT038
X-OriginalArrivalTime: 05 Dec 2016 22:38:38.0560 (UTC) FILETIME=[52629E00:01D24F48]
archived-at: Mon, 05 Dec 2016 22:39:32 -0000

--_000_BY2PR17MB0456C00C7E7321C26B1462C5C7830BY2PR17MB0456namp_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Thank you Steve and Gordon for your suggestion.


Is this meaning the client tries to reconnect the first time, but gets the =
explicit error, then it stops trying to reconnect?

Can you explain how increasing reconnect_interval_min would help if the fir=
st reconnection attempt is supposed to happen immediately?


________________________________
From: Gordon Sim <gsim@redhat.com>
Sent: Monday, December 5, 2016 12:26 PM
To: users@qpid.apache.org
Subject: Re: qpid-0.20 Execution exception: resource-locked

On 05/12/16 19:41, Bee wrote:
> Hello, I'm quite new here.  Hopefully, I can get some help for qpid-0.20 =
I'm using at work.
>
> A few times now, I get this error:
> [Protocol] error Execution exception: resource-locked: Cannot grant exclu=
sive access to queue   (qpid/broker/SessionAdapter.cpp:324)
>
> Please correct me, but my understanding is this is a race condition where=
 connection unexpectedly close, broker-client tries to re-initiate the sess=
ion, but the exclusive queue has not been freed yet.
> When this happens, client or broker (I'm not sure) stops trying to establ=
ish the session again.

It will happen when the broker thinks there is already a session using
that queue. One possibility is that the client timed out due not not
receiving a heartbeat before the broker did.

Because the client gets an explicit error, it does not try to reconnect
(it only does that if the connection is lost).

> My question is, how can I ensure the session can re-establish again by it=
self.  And, how can I reproduce this issue.

You could try sending the SIGSTOP signal to the broker. That prevents
the broker sending out heartbeats, then send SIGCONT after 2*heartbeat
interval so that the broker wakes up in time to process the reconnect,
but may not have processed the disconnect fully. You'll need to run it
several times and perhaps vary the time between stop and cont a little
to try and reproduce.

> I've tried iptables, it seems to reconnect as it's supposed to.  I've tri=
ed qpid-config del queue, I get msg that queue is deleted, but not the same=
 error msg.
>
> I'm using these options for broker
> reconnect: true
> heartbeat: 1
> tcp_nodelay: true
> reconnect_timeout: 2.0

Just in passing, the reconnect_timeout is the maximum total time that
the client will spend trying to reconnect. 2 seconds seems like a small
value for that.

> reconnect_interval_min: 0.1
> reconnect_interval_max: 2.0
>
>
> Any insights will be very appreciated.

Steve's suggestion is probably the simplest, i.e. wait a bit longer
before the first reconnect attempt to try and avoid the race.

In recent versions of the API, there is an explicit reconnect() method
(assuming you are using c++ qpid::messaging of course) on Connection
that you could use when catching this particular error. Not available on
0.20 though, so would need a newer client.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


--_000_BY2PR17MB0456C00C7E7321C26B1462C5C7830BY2PR17MB0456namp_--