[
https://issues.apache.org/jira/browse/CASSANDRA-13457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16391026#comment-16391026
]
Stefan Podkowinski commented on CASSANDRA-13457:
------------------------------------------------
{quote}diagnostic_events_enabled: true
After recent discussions on the dev ML around the use of experimental flags, eg
on MV, would it make more sense that this was false by default?
{quote}
Publishing events without any subscribers should be noop anyways. I intended
the flag rather as a kill switch, in case the feature is causing any issues in
production. But you're right, it's a new feature and it should probably not be
enabled by default. It's not a big deal to change it to true if you're going to
use it.
([13b1e8adbd|https://github.com/apache/cassandra/commit/13b1e8adbd3f597311b7f67d71318dc939dd54fb])
{quote}DiagnosticEvent.addIfNotNull(..)
this seems it could be a bit trivial… Can we just enforce toString
serialisation in the subclasses instead? (like Hint does it)
{quote}
I'm not really a fan of such helper methods either. I guess my intention was to
keep null values absent from the return mapped and also prevent NPEs. But we
should catch any exception from {{toMap}} anyways, so I'm fine removing it in
favor of {{String.valueOf}} on the caller side.
([5770638d6|https://github.com/apache/cassandra/commit/5770638d689333d59f57a9ef977dbb1fa6964e30])
{quote}Can we avoid the static fields? So to be avoiding adding to the
CASSANDRA-7837 problems… I don't think C* has a better habit in place for this?
But a singleton would be one better than all static fields…
{quote}
I don't mind as long as we try to keep things consistent. What's the latest
trend handling this? {{instance()}}?
But I don't think swapping out the implementation like in {{Trace}} is a use
cases that we have to support here. Basically the "service" is just a
broadcaster that implements publish/subscribe semantics and I can't really
think of any reason someone wants to change that and use their own
implementation.
([ba09523d|https://github.com/apache/cassandra/commit/ba09523de7cad3b3732c0e7e60b072f84e809e21])
{quote}Not too sure why a number of fields in existing classes were changed
from private to package-protected, for example in Gossiper. If it's for tests
in latter branches should they deserve the @VisibleForTesting annotation? And
should that change also happen in the latter branches
{quote}
The {{GossiperEvent}} will access these members from the constructor to collect
relevant details for the event. Passing these values directly from {{Gossiper}}
to {{GossiperEvent.*}} would mean that {{Gossiper}} needs to generate some
garbage by creating immutable copies of some of the values, while at the same
time events might not even be enabled and would be discarded anyways.
{quote}Should the event classes be included in the client jarfile (or some
'type and deserialisation' part of the event classes). This would then
introduce issues of compatibility, (eg enums). If event classes are not exposed
client-side, could they then be package private? (they're not used outside
their package)
{quote}
The implementation in CASSANDRA-13459 would only expose events serialized as
strings. I'd not serialize any internal classes, as we don't have any
versioning in place and classes could change quickly enough to cause
deserialization issues, even on bugfix releases. The only reason for keeping
complex objects as event members would be to make them accessible in unit
tests, see CASSANDRA-13458. That's also the reason I'd prefer to keep classes
public, so they can be used for unit testing.
{quote}What about conglomeration between metrics, diag events, and tracing
events? For example i wonder if the latter two will often pair?, good example
in HintsDispatcher
{quote}
There's probably some overlap, but I'd expect to rather see metrics on hot
paths where you want histograms and need to do local buffering and sampling to
cope with the load. Diag. events should be emitted key events only. As you
mentioned the HintsDispatcher, one of the first versions had events for
dispatched hints. After some basic testing I quickly realized that way too much
events would be produced, if you happen to subscribe to them. You could easily
maintain a histogram for that, but not emit diag events. So it makes sense to
limit emitted events for the hints service to dispatcher and maybe pages.
Although there's some overlap when it comes to looking at the outcome, yes. But
other diag events such as dispatcherCreated, abortRequested, would not make
much sense to have as a metric, as you need a bit more context to make them
useful for further analyzis and the HintEvent has that (hostId, address,
dispatcher,..).
As for tracing events, I'd expect only some pairing between them and diag
events for repairs at this point. Avoiding redundancy should be possible, e.g.
by replacing {{Tracing.traceRepair()}} calls with
{{DiagnosticEventsService.publish()}} calls and by creating a consumer that
would subscribe to all repair events, creates tracing messages and calls
{{Tracing.traceRepair()}} afterwards. But that would mean that we would
enable/disable repair tracing through the {{diagnostic_events_enabled}} flag.
We should maybe do this the other way around then and keep
{{Tracing.traceRepair()}} which in turn would call
{{DiagnosticEventsService.publish()}}.
> 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]
