You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Bill Freeman <ke...@gmail.com> on 2014/04/09 16:13:46 UTC
Can someone help me better understand this error:
We run a three node cluster, fed by federation links from non-clustered
brokers on what we call workflow servers. All C++ brokers (0.18,
probably). As near to simultaneously as we can tell (log has 1 second
resolution) we are seeing the following error on three (probably all of
the) workflow servers:
Apr 1 16:27:03 dt2apweb04nj qpidd[3154]: 2014-04-01 16:27:03 [Protocol]
error Execution exception: not-allowed: Consumer tags must be unique (
qpid/broker/SessionAdapter.cpp:404)
We would like a deeper understanding of what this means.
Can someone help?
Bill
Re: Can someone help me better understand this error:
Posted by Bill Freeman <ke...@gmail.com>.
Gordon,
Thanks. I'm trying to get trace logging enabled and/or a tcpdump. The
latter is probably problematic since the system is carrying sensitive data.
Bill
On Wed, Apr 9, 2014 at 11:27 AM, Gordon Sim <gs...@redhat.com> wrote:
> On 04/09/2014 04:12 PM, Bill Freeman wrote:
>
>> Let me wool gather a bit further.
>>
>> Though logged by the broker, it sounds as though this must be a result of
>> a
>> client action. Is it safe to assume that an error would have been
>> reported
>> to the client? Or might there not have been a path to do so?
>>
>
> Yes, it should have been reported to the client (the 'client' *may* have
> been another broker).
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: Can someone help me better understand this error:
Posted by Gordon Sim <gs...@redhat.com>.
On 04/09/2014 04:12 PM, Bill Freeman wrote:
> Let me wool gather a bit further.
>
> Though logged by the broker, it sounds as though this must be a result of a
> client action. Is it safe to assume that an error would have been reported
> to the client? Or might there not have been a path to do so?
Yes, it should have been reported to the client (the 'client' *may* have
been another broker).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Can someone help me better understand this error:
Posted by Bill Freeman <ke...@gmail.com>.
Let me wool gather a bit further.
Though logged by the broker, it sounds as though this must be a result of a
client action. Is it safe to assume that an error would have been reported
to the client? Or might there not have been a path to do so?
Bill
On Wed, Apr 9, 2014 at 10:29 AM, Bill Freeman <ke...@gmail.com> wrote:
> Gordon,
>
> Thanks. We'll go about gathering more information as you suggest. (I
> haven't been directly involved. I'm just the stuckee for all matter Qpid,
> or so it seems.)
>
> Bill
>
>
>
> On Wed, Apr 9, 2014 at 10:28 AM, Gordon Sim <gs...@redhat.com> wrote:
>
>> On 04/09/2014 03:13 PM, Bill Freeman wrote:
>>
>>> We run a three node cluster, fed by federation links from non-clustered
>>> brokers on what we call workflow servers. All C++ brokers (0.18,
>>> probably). As near to simultaneously as we can tell (log has 1 second
>>> resolution) we are seeing the following error on three (probably all of
>>> the) workflow servers:
>>>
>>> Apr 1 16:27:03 dt2apweb04nj qpidd[3154]: 2014-04-01 16:27:03 [Protocol]
>>> error Execution exception: not-allowed: Consumer tags must be unique (
>>> qpid/broker/SessionAdapter.cpp:404)
>>>
>>> We would like a deeper understanding of what this means.
>>>
>>
>> This means that the client session created a subscription with an
>> identifier[1] that was already in use by that same session.
>>
>> Are you able to get a tcpdump or a trace level broker log while
>> reproducing the issue? That would quickly point to the interaction that led
>> to the problem. Are there any other errors, e.g. in the non-clustered
>> broker logs?
>>
>> Federation routes should use a separate session for each subscription,
>> and so should not hit this. Likewise client libraries should usualy ensure
>> this doesn't happen by choosing unique destination values. Always possible
>> there is some bug though.
>>
>> [1] More specifically a message-subscribe command had the destination
>> field set to a value that was used for an existing active subscription on
>> the session.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>
>
Re: Can someone help me better understand this error:
Posted by Bill Freeman <ke...@gmail.com>.
Gordon,
Thanks. We'll go about gathering more information as you suggest. (I
haven't been directly involved. I'm just the stuckee for all matter Qpid,
or so it seems.)
Bill
On Wed, Apr 9, 2014 at 10:28 AM, Gordon Sim <gs...@redhat.com> wrote:
> On 04/09/2014 03:13 PM, Bill Freeman wrote:
>
>> We run a three node cluster, fed by federation links from non-clustered
>> brokers on what we call workflow servers. All C++ brokers (0.18,
>> probably). As near to simultaneously as we can tell (log has 1 second
>> resolution) we are seeing the following error on three (probably all of
>> the) workflow servers:
>>
>> Apr 1 16:27:03 dt2apweb04nj qpidd[3154]: 2014-04-01 16:27:03 [Protocol]
>> error Execution exception: not-allowed: Consumer tags must be unique (
>> qpid/broker/SessionAdapter.cpp:404)
>>
>> We would like a deeper understanding of what this means.
>>
>
> This means that the client session created a subscription with an
> identifier[1] that was already in use by that same session.
>
> Are you able to get a tcpdump or a trace level broker log while
> reproducing the issue? That would quickly point to the interaction that led
> to the problem. Are there any other errors, e.g. in the non-clustered
> broker logs?
>
> Federation routes should use a separate session for each subscription, and
> so should not hit this. Likewise client libraries should usualy ensure this
> doesn't happen by choosing unique destination values. Always possible there
> is some bug though.
>
> [1] More specifically a message-subscribe command had the destination
> field set to a value that was used for an existing active subscription on
> the session.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: Can someone help me better understand this error:
Posted by Gordon Sim <gs...@redhat.com>.
On 04/09/2014 03:13 PM, Bill Freeman wrote:
> We run a three node cluster, fed by federation links from non-clustered
> brokers on what we call workflow servers. All C++ brokers (0.18,
> probably). As near to simultaneously as we can tell (log has 1 second
> resolution) we are seeing the following error on three (probably all of
> the) workflow servers:
>
> Apr 1 16:27:03 dt2apweb04nj qpidd[3154]: 2014-04-01 16:27:03 [Protocol]
> error Execution exception: not-allowed: Consumer tags must be unique (
> qpid/broker/SessionAdapter.cpp:404)
>
> We would like a deeper understanding of what this means.
This means that the client session created a subscription with an
identifier[1] that was already in use by that same session.
Are you able to get a tcpdump or a trace level broker log while
reproducing the issue? That would quickly point to the interaction that
led to the problem. Are there any other errors, e.g. in the
non-clustered broker logs?
Federation routes should use a separate session for each subscription,
and so should not hit this. Likewise client libraries should usualy
ensure this doesn't happen by choosing unique destination values. Always
possible there is some bug though.
[1] More specifically a message-subscribe command had the destination
field set to a value that was used for an existing active subscription
on the session.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org