Hi Kirk, thanks for the response!
I just realized that I wrongly describe the problem as I tried so many case.
Sorry!
We have system with two servers. If the redundancy is 0 then we have properly
that on the first server is activeCqCount=1 and on the second is
activeCqCount=0.
After close CQ we got on first server activeCqCount=0 and on the second is
activeCqCount=-1.
gfsh>show metrics --categories=query
Cluster-wide Metrics
Category | Metric | Value
-------- | ---------------- | -----
query | activeCQCount | -1
| queryRequestRate | 0.0
In case we set redundancy to 1 it increments properly as expected, on both
servers by one. But when cq is closed we got on both servers activeCqCount=-1.
And show metrics command has the following output
gfsh>show metrics --categories=query
Cluster-wide Metrics
Category | Metric | Value
-------- | ---------------- | -----
query | activeCQCount | -1
| queryRequestRate | 0.0
What I found is that when server register cq on one server it send message to
other servers in the system with opType=REGISTER_CQ and in that case it creates
new instance of ServerCqImpl on second server(with empty constructor of
ServerCqImpl). When we close CQ there is two different instances on servers and
it closed both of them, but as they are in RUNNING state before closing, it
decrements activeCqCount on both of them.
BR,
Mario
________________________________
Šalje: Kirk Lund <kl...@apache.org>
Poslano: 30. lipnja 2020. 19:54
Prima: dev@geode.apache.org <dev@geode.apache.org>
Predmet: Re: negative ActiveCQCount
I think *show metrics --categories=query* is showing you the query stats
from DistributedSystemMXBean (see
ShowMetricsCommand#writeSystemWideMetricValues). DistributedSystemMXBean
aggregates values across all members in the cluster, so I would have
expected activeCQCount to initially show a value of 2 after you create a
ServerCQImpl in 2 servers. Then after closing the CQ, it should drop to a
value of 0.
When you create a CQ on a Server, it should be reflected asynchronously on
the CacheServerMXBean in that Server. Each Server has its own
CacheServerMXBean. Over on the Locator (JMX Manager), the
DistributedSystemMXBean aggregates the count of active CQs in
ServerClusterStatsMonitor by invoking
DistributedSystemBridge#updateCacheServer when the CacheServerMXBean state
is federated to the Locator (JMX Manager).
Based on what I see in code and in the description on GEODE-8293, I think
you might want to see if increment has a problem instead of decrement.
I don't see anything that would limit the activeCQCount to only count the
CQs on primaries. So, I would expect redundancy=1 to result in a value of
2. Does anyone else have different info about this?
On Tue, Jun 30, 2020 at 5:31 AM Mario Kevo <mario.k...@est.tech> wrote:
> Hi geode-dev,
>
> I have a question about CQ(
> https://issues.apache.org/jira/browse/GEODE-8293).
> If we run CQ it register cq on one of the
> servers(setPoolSubscriptionRedundancy is 1) and increment activeCQCount.
> As I understand then it processInputBuffer to another server and there is
> deserialization of the message. In case if opType is REGISTER_CQ or
> SET_CQ_STATE it will call readCq from CqServiceProvider, at the end calls
> empty contructor ServerCQImpl which is used for deserialization.
>
> The problem is when we close CQ then it has ServerCqImpl reference on both
> servers, close them, and decrement on both of them. In that case we have
> negative value of activeCQCount in show metrics command.
>
> Does anyone knows how to get in close method which is the primary and only
> decrement on it?
> Any advice is welcome!
>
> BR,
> Mario
>
