[
https://issues.apache.org/jira/browse/CASSANDRA-13457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16582478#comment-16582478
]
Stefan Podkowinski commented on CASSANDRA-13457:
------------------------------------------------
Rebased and pushed some changes for CASSANDRA-13457
([a5be8dc|https://github.com/spodkowinski/cassandra/commit/a5be8dc0214dff4974f5d299c9eebc69f04b650b]),
CASSANDRA-14435
([2d3549c|https://github.com/spodkowinski/cassandra/commit/2d3549c53ce11d5d94951f093b5db15a44f71325]),
CASSANDRA-13668
([c26219d|https://github.com/apache/cassandra/commit/c26219d36e611f0c72c1e82fc3d6dd9753571b2b])
(last one rebase only).
* Removed {{enableDiagnostics()}} in {{DiagnosticEventServiceMBean}} to enforce
explicit opt-in via cassandra yaml, as exposed data could contain security
sensitive details. The {{disableDiagnostics()}} method still exists to stop
events without having to restart a node.
* {{SchemaAnnouncementEvent}} will no longer depend on
{{SchemaTransformation.toString()}} output
([a5be8dc#L|https://github.com/spodkowinski/cassandra/commit/a5be8dc0214dff4974f5d299c9eebc69f04b650b#diff-4e80da086bdbd68b1295161b00719a10R66])
** The added {{toString()}} methods have been left as before, but can also be
removed if anyone minds having them
* Added threadName to returned events
([2d3549c#L|https://github.com/spodkowinski/cassandra/commit/2d3549c53ce11d5d94951f093b5db15a44f71325#diff-734577dc8c504d46702efa2262dfaac6R89])
* Moved getSource() to CASSANDRA-13458, so we don't have to discuss it now
Also
* Expose Gossiper state by calling getters instead of inspecting members
directly
([a5be8dc#L|https://github.com/spodkowinski/cassandra/commit/a5be8dc0214dff4974f5d299c9eebc69f04b650b#diff-8be666c70553b1f0017a01458c490f47R903])
There are several other ways to solve this (making a snapshot of the internal
state of a service like Gossiper).
* calling getters from the event class (as in latest version)
* have gossiper return an event or part of the event details (merged in
{{toMap()}})
* pass a builder object to gossip and have gossiper add any internal state to
that
I'd still prefer the first approach due to separations of concerns and to avoid
introducing leaky abstractions between services, such as Gossiper, and actual
event handling and persistence. We'd first have to agree on a more precise
contract for the kind of data to expose in events. The current {{Map<String,
Serializable>}} take is probably already too ambiguous, but I don't have any
better ideas for that, without opening the discussion again on how to persist
and remotely access events in general.
> Diag. Events: Add base classes
> ------------------------------
>
> Key: CASSANDRA-13457
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13457
> Project: Cassandra
> Issue Type: Sub-task
> Components: Core, Observability
> Reporter: Stefan Podkowinski
> Assignee: Stefan Podkowinski
> Priority: Major
>
> Base ticket for adding classes that will allow you to implement and subscribe
> to events.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
