[ https://issues.apache.org/jira/browse/SOLR-13700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16909083#comment-16909083 ]
Jan Høydahl commented on SOLR-13700: ------------------------------------ {quote}Also, I just spotted that both {{AuditLoggerPlugin.initializeMetrics}} and {{AuthenticationPlugin.initializeMetrics}}needlessly add metrics names to {{metricNames}} - this is already done as a part of each respective metric registration by using {{SolrInfoBean.this.registerName(name)}}. {quote} Can you file a new Jira for this one and I'll grab it? Don't remember which class I used as template back then, but there may be other places to clean up too. > Race condition in initializing metrics for new security plugins when > security.json is modified > ---------------------------------------------------------------------------------------------- > > Key: SOLR-13700 > URL: https://issues.apache.org/jira/browse/SOLR-13700 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Reporter: Hoss Man > Assignee: Hoss Man > Priority: Major > Attachments: SOLR-13700.patch > > > When new security plugins are initialized due to remote API requetss, there > is a delay between "registering" the new plugins for use in methods like > {{initializeAuthenticationPlugin()}} (by assigning them to CoreContainer's > volatile {{this.authenticationPlugin}} variable) and when the > {{initializeMetrics(..)}} method is called on these plugins, so that they > continue to use the existing {{Metric}} instances as the plugins they are > replacing. > Because these security plugins maintain local refrences to these Metrics (and > don't "get" them from the MetricRegisty everytime they need to {{inc()}} > them) this means that there is short race condition situation such that > during the window of time after a new plugin instance is put into use, but > before {{initializeMetrics(..)}} is called on them, at these plugins are > responsible for accepting/rejecting requests, and decisions in {{Metric}} > instances that are not registered and subsequently get thrown away (and GCed) > once the CoreContainer gets around to calling {{initializeMetrics(..)}} (and > the plugin starts using the pre-existing metric objects) > ---- > This has some noticible impacts on auth tests on CPU constrained jenkins > machines (even after putting in place SOLR-13464 work arounds) that make > assertions about the metrics recorded. > In real world situations, the impact of this bug on users is minor: for a few > micro/milli-seconds, requests may come in w/o being counted in the auth > metrics -- which may also result in descrepencies between the auth metrics > totals and the overall request metrics. -- This message was sent by Atlassian JIRA (v7.6.14#76016) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org