Pascal Proulx created SOLR-12353:
------------------------------------

             Summary: SolrDispatchFilter expensive non-conditional debug line 
degrades performance
                 Key: SOLR-12353
                 URL: https://issues.apache.org/jira/browse/SOLR-12353
             Project: Solr
          Issue Type: Bug
      Security Level: Public (Default Security Level. Issues are Public)
          Components: Admin UI, Authentication, logging
    Affects Versions: 6.6.3
            Reporter: Pascal Proulx


Hello,

We use Solr 6.6.3. Recently on one network when switching on authentication 
(security.json) began experiencing significant delays (5-10 seconds) to fulfill 
each request to /solr index.

I debugged the issue and it was essentially triggered by line 456 of 
SolrDispatchFilter.java:
{code:java}
log.debug("Request to authenticate: {}, domain: {}, port: {}", request, 
request.getLocalName(), request.getLocalPort());
{code}
The issue is that on machines and networks with poor configuration or routing 
issues in particular, request.getLocalName() can trigger expensive reverse DNS 
queries for the ethernet interfaces, and will only return within reasonable 
timeframe if manually written into /etc/hosts.

More to the point, request.getLocalName() should be considered an expensive 
operation in general, and in SolrDispatchFilter it runs unconditionally even if 
debug is disabled.

I would suggest to either replace request.getLocalName/Port here, or at the 
least, wrap the debug operation so it doesn't affect any production systems:
{code:java}
if (log.isDebugEnabled()) {
    log.debug("Request to authenticate: {}, domain: {}, port: {}", request, 
request.getLocalName(), request.getLocalPort());
}
{code}
The authenticateRequest method in question is private so we could not override 
it and making another HttpServletRequestWrapper to circumvent the servlet API 
was doubtful.

Thank you

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to