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

Robert Muir commented on SOLR-14050:
------------------------------------

Can you open a separate issue for what you see there? We have to investigate 
it, it may be an issue such as SOLR-14047 causing insane behavior on different 
machines (depending on environment variable or something, who knows). Please 
include whole stacktrace, environment, etc. If we don't chase these things 
down, tests will always be really crazy.

> clean up tests use of network addresses
> ---------------------------------------
>
>                 Key: SOLR-14050
>                 URL: https://issues.apache.org/jira/browse/SOLR-14050
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>            Reporter: Robert Muir
>            Priority: Major
>         Attachments: SOLR-14050.patch
>
>
> Motivated by this tweet: 
> https://twitter.com/ichattopadhyaya/status/1204274908454219778
> I think we should clean up the "connect/resolve anywhere" security 
> permissions in the tests and make it stricter like lucene. This way we can 
> prevent tests from doing slow things now or in the future.
> The biggest issue I see exploring this so far is solr has lots of tests that 
> want to hit a "dead" node. If you get lucky test passes quickly. If you get 
> unlucky (e.g. it tries to route that multicast ipv6 address somewhere?) then 
> it passes slowly or maybe even times out or misbehaves.
> I think, depending on the networking environment (e.g. working ipv6 or not, 
> maybe OS), the current way its being done can be terribly slow. I have some 
> ideas, just need to do some testing.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

Reply via email to