Perhaps re-add the settings virtual table mutability. That way the same
place can be used to update settings at runtime for multiple things instead
of creating a new virtual table per service we want to make hot props for.
Might be kinda nice to allow REGISTER and EVENT CQL events to be created
wi
>
> If one subscribes via JMX, this subscription is not propagated to the
>
underlying CQL table. So she might subscribe to 5 events but there
> would be none in vtable.
There isn't any need for any underlying CQL table here.
The enabled state, and subscriptions, is in DatabaseDescriptor
and Dia
Hi Mick,
I returned to this after some time and here are my questions about this.
I am waiting for 16806 to be merged which introduces abstract mutable
vtables (1) on top of which I want to build what you have proposed.
I do not think we need a non-virtual table for this and this is
actually supe
>
> I am not sure yet how the implementation in case of virtual tables
> fits into the overall picture of "pluggability".
Yeah, it was a goal of the design to make writing new types as easy as
possible, so having to wire up a new vtable for each new event type works
against that.
I'd be incline
Yes, limits are good, in case of a solution for virtual tables. I can
imagine that it will be use just for the sake of diagnostics what a
node is doing and so on and even we lift the limit to something like
1000, that is already a plenty to show a respective operator (as a
person) what a node does
Some input…
We don't need a CEP for this: Diagnostic Events already exists, as do
Virtual Tables. But if you want to take it to a CEP, that's to be
encouraged :)
Virtual Tables should remain virtual, i.e. they shouldn't be backed by
custom system_* tables solely for the sake of persisting the vir
Thank you both for the answers, really appreciate it.
My concern is that there would be "too much data" in them and it might
grow and grow as a node is live, however, that being said, I think
there is currently a hardcap like 200 events per event type in the
current implementation (1). Hence I see
Yes, I think it would make sense to have the events available in a virtual
table, especially if we are trying to move our operational management in that
direction.
But, why does it need to be bin log or virtual tables? Why not both? The
virtual tables could even return the data stored in the
I'm not very familiar with diagnostic events, but I think there's great
value in providing a Virtual Table implementation to diagnostic events,
since this will help in the long term objective of providing a unified
interface to node monitoring, so +1 from my side. I think it would
definitely help t
Hi,
should I create CEP first or people just absolutely do not care to
even drop an email and it does not make sense to them?
Regards
On Mon, 19 Jul 2021 at 15:32, Stefan Miklosovic
wrote:
>
> Hi,
>
> I wonder if people would be interested in having diagnostic events in
> virtual tables?
>
> I
Hi,
I wonder if people would be interested in having diagnostic events in
virtual tables?
I put something together here (heavy wip) (1) but that is the idea I have.
I know that Stefan Podkowinski did a spectacular job under
CASSANDRA-12944 and the possibility to persist locally was elaborated
on
11 matches
Mail list logo
