[
https://issues.apache.org/jira/browse/SOLR-8522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15104043#comment-15104043
]
Arcadius Ahouansou edited comment on SOLR-8522 at 1/18/16 1:44 AM:
-------------------------------------------------------------------
Thank you very much [~noble.paul]ul] for taking the time to look into this
{quote}
The solr node string may not always be an IP address. It could be something
like {[host:port}} . So IP address needs a lookup
{quote}
You are right about this. I was not aware of this.
Turned out that a user could start Solr with -Dhost=someHostName.
Doing the lookup as suggested is quite simple. However, 1 host could have
multiple public and private IPs. We could pick the first public one or
something...
This led me to start contemplating the idea of a more generic snitch that will
deal with host names as well as IPs like
{{192.168.1.2 -> host_1=2, host_2=1, host_3=168, host_4=192}}
and
{{serv1.dc1.london.uk.apache.org -> host_1=org, host_2=apache, host_3=uk,
host_4=london, host_5=dc1, host_6=serv1}}
Any comment about this?
{quote}Let's start from least significant to most significant{quote}
Yes, makes sense
{quote}Do not blindly add a tag . Add if it is only requested{quote}
The current implementation adds only the tags that are requested.
The one that are not requested are not added to the response.
This is tested in
- {{testGetTagsWithEmptyIPv4RequestedTag()}} where no tag is requested -> none
returned, and
- {{testGetTagsWithIPv4RequestedTags_ip_2_ip_4()}} where only 2 tags are
requested leading to only 2 out of 4 being returned
Please let me know about the idea of a more generic snitch that could handle
host names as well.
Many thanks
was (Author: arcadius):
Thank you very much [~noble.paul]ul] for taking the time to look into this
{quote}
The solr node string may not always be an IP address. It could be something
like {[host:port}} . So IP address needs a lookup
{quote}
You are right about this. I was not aware of this.
Turned out that a user could start Solr with -Dhost=someHostName.
Doing the lookup as suggested is quite simple. However, 1 host could have
multiple public and private IPs. We could pick the first public one or
something...
This led me to start contemplating the idea of a more generic snitch like
{{192.168.1.2 -> host_1=2, host_2=1, host_3=168, host_4=192}}
and
{{serv1.dc1.london.uk.apache.org -> host_1=org, host_2=apache, host_3=uk,
host_4=london, host_5=dc1, host_6=serv1}}
Any comment about this?
{quote}Let's start from least significant to most significant{quote}
Yes, makes sense
{quote}Do not blindly add a tag . Add if it is only requested{quote}
The current implementation adds only the tags that are requested.
The one that are not requested are not added to the response.
This is tested in
- {{testGetTagsWithEmptyIPv4RequestedTag()}} where no tag is requested -> none
returned, and
- {{testGetTagsWithIPv4RequestedTags_ip_2_ip_4()}} where only 2 tags are
requested leading to only 2 out of 4 being returned
Please let me know about the idea of a more generic snitch that could handle
host names as well.
Many thanks
> ImplicitSnitch to support IPv4 based tags
> -----------------------------------------
>
> Key: SOLR-8522
> URL: https://issues.apache.org/jira/browse/SOLR-8522
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
> Affects Versions: 5.4
> Reporter: Arcadius Ahouansou
> Assignee: Noble Paul
> Priority: Minor
> Attachments: SOLR-8522.patch
>
>
> This is a description from [~noble.paul]'s comment on SOLR-8146
> Lets assume a Solr node IPv4 address is 192.93.255.255 .
> This is about enhancing the current {{ImplicitSnitch}} to support IP based
> tags like:
> - {{ip_1 = 192}}
> - {{ip_2 = 93}}
> - {{ip_3 = 255}}
> - {{ip_4 = 255}}
> Note that IPv6 support will be implemented by a separate ticket
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
