You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Toralf Lund <to...@pgs.com> on 2019/03/19 13:09:25 UTC
Re: [External] Re: Check number of queue subscribers? And what does
consumerCnt mean in qpid-tool?
On 19/03/2019 12:15, Gordon Sim wrote:
> On 19/03/2019 9:17 am, Toralf Lund wrote:
>> Hi,
>>
>> Is there any way I can find out how many applications or processes
>> have connected to a certain queue on a qpid cpp broker?
>>
>> Related question: If I enter "show <id>" for a numeric queue id in
>> qpid-tool, it shows me a "consumerCount" value. What exactly does
>> this represent? I though it might give me something like what I'm
>> asking for above, but I see numbers like 204 and 458 for queues that
>> are supposed to have only a couple of subscribers...
>
> What does qpid-stats -q show for that queue?
$ qpid-stat -b cirm -q pgs.compass.control
Properties:
Name Durable AutoDelete Exclusive FlowStopped
FlowStoppedCount Consumers Bindings
=========================================================================================================
pgs.compass.control N N N N
0 257 2
Optional Properties:
Property Value
=============================================================================================================================================================================================
arguments {u'qpid.ha-uuid':
UUID('110fa007-74bc-4533-b510-4e2404155e95'), u'qpid.max_count': 100,
u'qpid.policy_type': u'ring', u'qpid.replicate': 'all',
u'qpid.browse-only': u'True'}
alt-exchange
Statistics:
Statistic Messages Bytes
==============================================
queue-depth 0 0
total-enqueues 91 28,617
total-dequeues 91 28,617
persistent-enqueues 0 0
persistent-dequeues 0 0
transactional-enqueues 0 0
transactional-dequeues 0 0
flow-to-disk-depth 0 0
flow-to-disk-enqueues 0 0
flow-to-disk-dequeues 0 0
acquires 0
releases 0
discards-ttl-expired 91
discards-limit-overflow 0
discards-ring-overflow 0
discards-lvq-replace 0
discards-subscriber-reject 0
discards-purged 0
reroutes 0
> The consumer count should indeed be the number of current consumers
> (subscribers) on the queue.
Right.
So I guess the problem is actually that there are somehow a lot of
"spurious" subscribers. I suspected something like that all along, but I
kind of assumed there would be 1 or 2 extra ones, not several 100. The
original issue was that it looked like someone else consumed all the
messages before they reached the intended receiver. That's for the queue
shown above - the consumer count is unexpectedly high on others, too,
but those are shared, "browse-only" queues, so it's kind of hard to
notice any effects. You may notice that "browse-only" is also "True"
above, but the queue was only set up that way as a workaround after
messages were lost.
I actually just noticed something that might be causing this:
It turns out that the applications attempts to receive messages from the
queues will every once in a while fail with error "Failed to connect
(reconnect disabled)". After that, I see indications that the following
piece of code actually re-opens the connection:
if(!connection.isOpen()) {
cerr << "Open AMQP connection...\n";
connection.open();
/* "session" might contain a dangling pointer to session object
from
a previously open connection - reset it. */
session=qpid::messaging::Session();
}
if(session.isValid() && session.hasError()) {
session.close();
session=qpid::messaging::Session();
}
if(!session.isValid())
session=connection.createSession();
I don't think connection.close() is ever called. "connection" is of type
qpid::messaging::Connection, of course.
Could that fit with what I'm seeing? Is there a chance that
Connection::isOpen() returns false after an error, yet the connection
isn't really released? How should I detect and handle that situation?
>> Related question to related question: It there any proper
>> documentation for qpid-tool? I've read
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__qpid.apache.org_releases_qpid-2Dcpp-2D1.37.0_cpp-2Dbroker_book_chapter-2DManaging-2DCPP-2DBroker.html&d=DwICaQ&c=KV_I7O14pmwRcmAVyJ1eg4Jwb8Y2JAxuL5YgMGHpjcQ&r=Q0oqxzgUp3xCCIiJDwS-RbNDndQ-KZDhj8wwveNoqU4&m=IW8dpoHLD8lt4A8nL_IMlHpiyevxre4ruTbRvUATO0k&s=NKBpvTIkzNv5BHoil8bbI2rA1ZGhg0sad8jowdoJt4g&e=,
>> but it only has a very brief overview that appears to be out-of-date.
>
> No, I don't think there is I'm afraid. You can type help at it and it
> will list the commands available.
Too bad :-(
I guess the "help" information was good enough in a sense in this case,
it was just that I got unsure about everything when the values didn't
seem to make sense, given an "obvious" interpretation of the field names...
- Toralf
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
Re: [External] Re: Check number of queue subscribers? And what does
consumerCnt mean in qpid-tool?
Posted by Toralf Lund <to...@pgs.com>.
On 20/03/2019 10:07, Gordon Sim wrote:
> On 20/03/2019 8:02 am, Toralf Lund wrote:
>> On 19/03/2019 22:07, Gordon Sim wrote:
>>> On 19/03/2019 1:09 pm, Toralf Lund wrote:
>>>> Could that fit with what I'm seeing? Is there a chance that
>>>> Connection::isOpen() returns false after an error, yet the
>>>> connection isn't really released? How should I detect and handle
>>>> that situation?
>>>
>>> I'm not sure what you mean by 'really released'. The isOpen()
>>> returns true if the AMQP connection is currently active, false
>>> otherwise.
>>
>> The question is, when the connection is automatically closed on
>> error, is everything fully closed down in the same way as when
>> calling Connection::close()?
>>
>> I've always assumed that close() would shut down all sessions and
>> their senders and receivers, but perhaps that's not the case?
>
> That is the case; an explcit close() will indeed close and remove all
> the sessions.
>
> However if the connection is closed by the peer or there is a
> transport error, then the sessions, though no longer actively open,
> will not be removed from the connection. So on 'reanimating' it so to
> speak by opening again, they will (I believe) be recreated. This is
> what the reconnect feature is supposed to do, and open uses much of
> the same code paths.
Fair enough.
I think I know how the software should be modified, then.
Thanks.
- Toralf
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [External] Re: Check number of queue subscribers? And what does
consumerCnt mean in qpid-tool?
Posted by Gordon Sim <gs...@redhat.com>.
On 20/03/2019 8:02 am, Toralf Lund wrote:
> On 19/03/2019 22:07, Gordon Sim wrote:
>> On 19/03/2019 1:09 pm, Toralf Lund wrote:
>>> Could that fit with what I'm seeing? Is there a chance that
>>> Connection::isOpen() returns false after an error, yet the connection
>>> isn't really released? How should I detect and handle that situation?
>>
>> I'm not sure what you mean by 'really released'. The isOpen() returns
>> true if the AMQP connection is currently active, false otherwise.
>
> The question is, when the connection is automatically closed on error,
> is everything fully closed down in the same way as when calling
> Connection::close()?
>
> I've always assumed that close() would shut down all sessions and their
> senders and receivers, but perhaps that's not the case?
That is the case; an explcit close() will indeed close and remove all
the sessions.
However if the connection is closed by the peer or there is a transport
error, then the sessions, though no longer actively open, will not be
removed from the connection. So on 'reanimating' it so to speak by
opening again, they will (I believe) be recreated. This is what the
reconnect feature is supposed to do, and open uses much of the same code
paths.
>> I suspect what may be happening is that when you open the same
>> connection that has been closed for some reason, if there were
>> previous sessions and consumers on it, those are recreated. If you
>> don't want that you can create a new connection instance before
>> opening it.
>
> So closing does not make the existing sessions go away?
>
> Actually, perhaps I've misunderstood the first sentence of the close()
> documentation;
>
> Closes a connection and all sessions associated with it. An opened
> connection must be closed before the last handle is allowed to go
> out of scope.
> I've taken this to mean that I should create new sessions using
> createSession() if I opened the connection again. Perhaps that's not the
> case? Or is the morale of the story that I really ought not to call
> open() a 2nd time?
If you want a 'fresh' connection, then I would create a new object and
open that as the simplest solution I think.
> I notice that there is now also a reconnect(), but I
> don't believe such a method existed at the time my application was written.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [External] Re: Check number of queue subscribers? And what does
consumerCnt mean in qpid-tool?
Posted by Toralf Lund <to...@pgs.com>.
On 19/03/2019 22:07, Gordon Sim wrote:
> On 19/03/2019 1:09 pm, Toralf Lund wrote:
>> Could that fit with what I'm seeing? Is there a chance that
>> Connection::isOpen() returns false after an error, yet the connection
>> isn't really released? How should I detect and handle that situation?
>
> I'm not sure what you mean by 'really released'. The isOpen() returns
> true if the AMQP connection is currently active, false otherwise.
The question is, when the connection is automatically closed on error,
is everything fully closed down in the same way as when calling
Connection::close()?
I've always assumed that close() would shut down all sessions and their
senders and receivers, but perhaps that's not the case?
>
> I suspect what may be happening is that when you open the same
> connection that has been closed for some reason, if there were
> previous sessions and consumers on it, those are recreated. If you
> don't want that you can create a new connection instance before
> opening it.
So closing does not make the existing sessions go away?
Actually, perhaps I've misunderstood the first sentence of the close()
documentation;
Closes a connection and all sessions associated with it. An opened
connection must be closed before the last handle is allowed to go
out of scope.
I've taken this to mean that I should create new sessions using
createSession() if I opened the connection again. Perhaps that's not the
case? Or is the morale of the story that I really ought not to call
open() a 2nd time? I notice that there is now also a reconnect(), but I
don't believe such a method existed at the time my application was written.
Thanks,
- Toralf
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
Re: [External] Re: Check number of queue subscribers? And what does
consumerCnt mean in qpid-tool?
Posted by Gordon Sim <gs...@redhat.com>.
On 19/03/2019 1:09 pm, Toralf Lund wrote:
> Could that fit with what I'm seeing? Is there a chance that
> Connection::isOpen() returns false after an error, yet the connection
> isn't really released? How should I detect and handle that situation?
I'm not sure what you mean by 'really released'. The isOpen() returns
true if the AMQP connection is currently active, false otherwise.
I suspect what may be happening is that when you open the same
connection that has been closed for some reason, if there were previous
sessions and consumers on it, those are recreated. If you don't want
that you can create a new connection instance before opening it.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org