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 <ke1g...@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 <g...@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-unsubscr...@qpid.apache.org >> For additional commands, e-mail: users-h...@qpid.apache.org >> >> >
