[
https://issues.apache.org/jira/browse/SOLR-14050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16993995#comment-16993995
]
Uwe Schindler commented on SOLR-14050:
--------------------------------------
Yeah, you're right. Policeman machines are configured by one IPv6 longtime
policeman (if you would ask me shutdown IPv4 ASAP! :)), so they should behave
accoring to routing limitations on those special addresses!
UweSays: I think the "certain configurations" are bullshit like DSLite internet
CPEs used by some internet providers
([https://en.wikipedia.org/wiki/IPv6_transition_mechanism#Dual-Stack_Lite_.28DS-Lite.29]).
> 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
> Assignee: Robert Muir
> Priority: Major
> Fix For: 8.4
>
> 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
