[
https://issues.apache.org/jira/browse/SOLR-14050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16993118#comment-16993118
]
Robert Muir commented on SOLR-14050:
------------------------------------
I'm pretty sure part of this is my fault from years ago :( The addresses here
were like designated test addresses of some sort, I can't find them listed in
any special reserved space now? They seem to just be normal v6 multicast
addresses!
Of course, its really not good that so many tests are using "real networking"
at all, versus say mocks. Unit testing techniques would be much better here.
But I am going to try to clean up what is there.
> 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
>
> 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
