Hi Chris,
As I understand your concern is "Many times I have seen this particular
call take quite a while to return". Are you concerned with asynchronous
nature of IgniteCache#size() or you think the existing implementation is
too slow and your own implementation would be faster?
If this is the former then you can just use the async version that would
not delay your monitoring engine something like:
IgniteFuture<Integer> sizeFut = cache.sizeAync(CahcePeekMode.PRIMARY);
sizeFut.chain(result -> {
Integer totalSize = result.get(); /* in this callback you have the
total cache size */
});
If this is the latter - then why do you think your framework will be
faster? The existing implementation simply starts a SizeTask on all nodes,
which calls IgniteCache#localSize() on each node and the result is reduced
in your application. Not sure how you can further optimize it.
On Thu, Sep 7, 2017 at 9:39 PM, Chris Berry <[email protected]> wrote:
> Hi,
>
> I need to monitor cache size – in a PARTITIONED cache (a 10 Node Cluster –
> 2
> backups).
> And I need to monitor this in the PRIMARY – (I assume – to get the true
> size
> at any time)
> Thus my monitor will call `cache.size(CachePeekMode.PRIMARY)` every few
> seconds – and evaluate the size vs the expected minimum size
> (I have found that one sure way to know I’m in trouble is when the cache
> size drops – which means I lost data)
>
> This, in most cases, is a remote call
>
> This frightens me. And I want to somehow add some protection around this
> call.
> Many times I have seen this particular call take quite a while to return –
> and I cannot slow down my overall metrics gathering much.
> (FYI: it is a Dropwizard app w/ embedded Ignite, with Codahale metrics,
> polled every N seconds)
>
> It seems I have a few options.
>
> 1) Of course, I can do the call on separate Thread and assassinate it if it
> takes too long.
> But that doesn’t really solve
>
> 2) I hoped that `localMetrics` could have helped. But it seems to know only
> about its bit of things – as far as I can tell.
> At least when I go to the MBean and hit `size`
> But, perhaps this may still work??
> If I pass that local `size` as a metric. And then sum them in my metrics
> framework. Will that add up to the overall size (or is it size + backups)??
>
> 3) Is there any way to know which Nodes are keeping bits of the PRIMARY?
> Or do I have that wrong – and every Node will have a bit of the PRIMARY (my
> understanding is that some have PRIMARY and some have Backups)?
> Because, if so, I could report the size metric doing a localPeek and sum
> them in my metrics framework.
> I.e. something like::
> if (cache.isPrimary()) {
> return cache.localSize()
> }
>
>
> THANKS,
> -- Chris
>
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>
--
Best regards,
Alexey
