Hello everyone,
We still need a few eyes to help push the changes forward.
https://issues.apache.org/jira/browse/CASSANDRA-14572
Here's the post I prepared as a result of working on this issue (it
might help to review it):
https://dzone.com/articles/making-dropwizard-metrics-accessible-via-cql-i
Hello everyone and happy holidays,
The changes below are ready for review!
Benchmarks are also inside.
Expose all table metrics in virtual tables
https://issues.apache.org/jira/browse/CASSANDRA-14572
https://github.com/apache/cassandra/pull/2958/files
On Tue, 12 Dec 2023 at 22:05, Maxim Muzafaro
Hello everyone,
I still think Cassandra will benefit from having this idea implemented
and used through the source code, so I've done another round of
rethinking this concept and it seems I've found a solution. As a
result, we can significantly reduce the cost of implementing and
maintaining both
> I *think* this is arguably true for a vtable / CQL-based solution as well
> from the "you don't know how people are using your API" perspective.
Very fair point and think that justifies a different thread to talk about
backwards compatibility for our tables (virtual and not); maybe we can lump
First of all, I'd like to thank you all for the comments. It's crucial
for me to get the feedback considering the fact I'm limited in
discussing such details with anyone else :-)
We should start a new thread about the JMX deprecation for sure, but
let me make a few comments here as well.
In my p
Actually, Maxim's proposal does not depend on JMX being present or not.
What the proposal does is make it easier to create/sync multiple
presentations of the same internal data: Virtual Tables, JMX, Metrics,
next year's greatest data presentation strategy. Removing JMX from the
mix just reduces
+1 on starting that discussion, thank you for volunteering Benjamin!
On Mon, 30 Jan 2023 at 4:59, Benjamin Lerer wrote:
> It seems to me that the question that we need to answer, before Maxim puts
> more effort into this work, is: what is the future of JMX?
> I agree that we have never been clea
It seems to me that the question that we need to answer, before Maxim puts
more effort into this work, is: what is the future of JMX?
I agree that we have never been clear about that decision up to now. At
least now we have a reason to clarify that point.
I can start a discussion about that if peo
I’m also very interested in this area. I quickly skimmed the proposal and IIUC it doesn’t call for moving away from JMX. Instead I think it’s making it easier to expose metrics over various interfaces. Maxim please correct me if I’m wrong in my understanding.I also second Josh’s point on JMX usage.
First off - thanks so much for putting in this effort Maxim! This is excellent
work.
Some thoughts on the CEP and responses in thread:
> *Considering that JMX is usually not used and disabled in production
> environments for various performance and security reasons, the operator may
> not see
Overall I have similar thoughts and questions as David.
I just wanted to add a reminder about this thread from last summer[1]. We
already have issues with the alignment of JMX and Settings Virtual Table. I
guess this is how Maxim got inspired to suggest this framework proposal
which I want to than
I took a look and I see the result is an interface that looks like the vtable
interface, that is then used by vtables and JMX? My first thought is why not
just use the vtable logic?
I also wonder about if we should care about JMX? I know many wish to migrate
(its going to be a very long time)
Hello Cassandra Community,
I've been faced with a number of inconsistencies in the user APIs of
the internal data collections representation exposed through the
Cassandra monitoring interfaces that need to be fully aligned from an
operator perspective. First of all, I'm highlighting JMX, Dropwiza
13 matches
Mail list logo
