[jira] [Commented] (SOLR-12353) SolrDispatchFilter expensive non-conditional debug line degrades performance

2018-05-22 Thread Pascal Proulx (JIRA)

[ 
https://issues.apache.org/jira/browse/SOLR-12353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16484441#comment-16484441
 ] 

Pascal Proulx commented on SOLR-12353:
--

Sorry I thought I had replied. I believe any of that would remedy the issue in 
our case. I suppose I'd agree about hosts file on prod machines. But in our 
case it affects developer(s) as well, so it does happen.

> 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
>Assignee: Erick Erickson
>Priority: Major
>
> 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 DNS 
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org



[jira] [Commented] (SOLR-12353) SolrDispatchFilter expensive non-conditional debug line degrades performance

2018-05-14 Thread Shawn Heisey (JIRA)

[ 
https://issues.apache.org/jira/browse/SOLR-12353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16474821#comment-16474821
 ] 

Shawn Heisey commented on SOLR-12353:
-

General advice for logger usage is to NOT wrap with the isXxxxEnabled call 
except in cases where obtaining logging parameters is likely to be slow and the 
level being tested is not enabled by default.

The quick solution, which we could do as a stepping stone, is to wrap this 
logging in isDebugEnabled as you have suggested.

Thinking larger ... I don't see any point to having hostname and port 
information in the debug log at all.  If it is actually useful, then 
getLocalName could be replaced with getLocalAddr.  Such log entries are 
unlikely to be viewed by anybody who doesn't know how the system is configured, 
so having an IP address in the log would not introduce a significant 
administrative burden.  Possible replacements without isDebugEnabled, my 
preferred first:

{code:java}
log.debug("Request to authenticate: {}", request);
{code}

or

{code:java}
log.debug("Request to authenticate: {}, address: {}, port: {}", 
request, request.getLocalAddr(), request.getLocalPort());
{code}

Side note: IMHO the /etc/hosts file should always contain an entry for every 
network interface on the machine.  But the simple fact is that users have 
configurations that aren't perfect, and Solr should work well even if the 
system config is not ideal.  Thanks for bringing the issue to our attention!


> 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
>Priority: Major
>
> 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 DNS 
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org