Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Date: Sun, 22 Mar 2015 20:07:10 +0000 (UTC)
From: =?utf-8?Q?Endre_St=C3=B8lsvik_=28JIRA=29?= <jira@apache.org>
To: dev@activemq.apache.org
Message-ID: <JIRA.12783784.1426891047000.2222.1427054830934@Atlassian.JIRA>
In-Reply-To: <JIRA.12783784.1426891047000@Atlassian.JIRA>
References: <JIRA.12783784.1426891047000@Atlassian.JIRA>
 <JIRA.12783784.1426891047794@arcas>
Subject: [jira] [Comment Edited] (AMQ-5681) inFlightCount of
 "ActiveMQ.Advisory.TempQueue" seems to rise forever.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/AMQ-5681?page=3Dcom.atlassian.j=
ira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D143751=
45#comment-14375145 ]=20

Endre St=C3=B8lsvik edited comment on AMQ-5681 at 3/22/15 8:06 PM:
--------------------------------------------------------------

1) Why does this not happen for any of the other Advisory destinations? Is =
it only the TempQueues that the connection needs to listen to? (For what re=
ason would that be?)

2) Why does then the inFlightCount keep on rising if this is how it is supp=
osed to be? I have well above 350.000 inFlightCount on my production instan=
ce. (What impact do the inFlightCount have? It does really not sound right =
to have anything else than 0 there for any period of time)

For future reference:
{code}
brokerService.setAdvisorySupport(false);
{code}
.. also disables these topics, "globally" from the Broker's side (as oppose=
d to the client/ConnectionFactory's side)


was (Author: stolsvik):
1) Why does this not happen for any of the other Advisory destinations? Is =
it onlyt the TempQueue that the connection needs to listen to? (For what re=
ason would that be?)

2) Why does then the inFlightCount keep on rising if this is how it is supp=
osed to be? I have well above 350.000 inFlightCount on my production instan=
ce. (What impact do the inFlightCount have? It does really not sound right =
to have anything else than 0 there for any period of time)

For future reference:
{code}
brokerService.setAdvisorySupport(false);
{code}
.. also disables these topics, "globally" from the Broker's side (as oppose=
d to the client/ConnectionFactory's side)

> inFlightCount of "ActiveMQ.Advisory.TempQueue" seems to rise forever.
> ---------------------------------------------------------------------
>
>                 Key: AMQ-5681
>                 URL: https://issues.apache.org/jira/browse/AMQ-5681
>             Project: ActiveMQ
>          Issue Type: Bug
>            Reporter: Endre St=C3=B8lsvik
>
> These are some lines from a monitor-thingy that I have:
> {code}
> ActiveMQ.Advisory.TempQueue
>   DLQ: false, consumer#:4, producer#:0 queueSize:0, enqueue#:10, dequeue#=
:0, dispatch#:40, inFlight#:40, expired#:0
> {code}
> The fact here is that no-one is subscribing to that advisory channel. The=
re are however a total of 4 Connections to the ActiveMQ instance.
> And there have been made a total of 10 temporary queues (to use as a requ=
est-reply channel for the statistics plugin: "ActiveMQ.Statistics.Broker").
> Evidently, for every Connection made to the broker, it somehow assumes th=
at the Connection wants these advisories, but then there is no one actually=
 consuming and acknowledging them, thus stacking up in the inFlightCount.
> ... after this JVM running has been running for a while, those monitor-li=
nes read like this (the "call" to the statistics-plugin goes every 10 secon=
d):
> {code}
> ActiveMQ.Advisory.TempQueue
>   DLQ: false, consumer#:4, producer#:0 queueSize:0, enqueue#:1174, dequeu=
e#:3004, dispatch#:4716, inFlight#:1712, expired#:0
> {code}
> I do not know how the "dequeueCount" ends up getting higher, reducing the=
 inFlightCount. However, in our production setup the net inFlightCount neve=
rtheless just continues to go higher (but I have not been able to deploy th=
at monitor thing there yet, so I do not know the ratio of dequeue vs. inFli=
ght - but inFlight is way over 200.000 after some days of running).
> Do note that this strange-ness does not hold for any other Advisory chann=
el (i.e. any Connection adds to the consumerCount, and any queue creation a=
dds to both enqueueCount and inFlightCount) - it is just TempQueue that han=
dles like this.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)