cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Podkowinski (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-13457) Diag. Events: Add base classes
Date Thu, 16 Aug 2018 13:05:00 GMT

    [ 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: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org


Mime
View raw message