Mailing-List: contact user-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@ignite.apache.org
Subject: Re: TcpDiscoverySpi.setLocalPortRange, value must be > 0
To: user@ignite.apache.org, dev@ignite.apache.org
References: <1453108876139-2606.post@n6.nabble.com>
From: Denis Magda <dmagda@gridgain.com>
Message-ID: <569CD1E7.3010904@gridgain.com>
Date: Mon, 18 Jan 2016 14:52:07 +0300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <1453108876139-2606.post@n6.nabble.com>
Content-Type: multipart/alternative;
 boundary="------------020406060307030508000108"

This is a multi-part message in MIME format.
--------------020406060307030508000108
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

Thank for pointing out to this issue. Local port range set to 0 
presently doesn't work at least for TcpCommunicationSpi and 
TcpDiscoverySpi. However SPIs support it.

In my understanding the condition has to changed to the following one 
(from < to <=).

x = port; x*<=*  port + range

But this will violate the following from 
TcpCommunicationSpi.setLocalPortRange

implementation will try to increment the port number for as long as it 
is less than * initial value plus this range.

So it means that setLocalPortRange has to be treated a different way and 
in fact setLocalPortRange=0 will be the same as setLocalPortRange=1

I've copied the message to @dev list to get more thoughts on this.

Igniters, any thoughts? Should localPortRange=0 work the same as 
localPortRange=1?

--
Denis

On 1/18/2016 12:21 PM, DLopez wrote:
> Hi,
>
> While experimenting, as I was trying to just allow specific ports, I set the
> LocalPortRange of my configurations to 0. The result was not what I expected
> as you end up getting a NPE when starting the cluster. I traced the issue in
> the source and the cause is that when opening ports, the routine goes from
> the x = port; x < port + range. So you end up with no server socket, and
> when you try to listen to it, kaboum.
>
> So I think it might be interesting to clarify the docs, as the current
> definition (starting from getLocalPort() up until getLocalPort() +
> locPortRange) can be misunderstood and the handling of localport value,
> throwing an error if it is set to an incorrect value.
>
> Just to prevent other people having the same issue :). Not a top priority,
> of course, but such an easy change can prevent more support messages to the
> list to... What do you think?
>
> S!
> D.
>
>
>
> --
> View this message in context: http://apache-ignite-users.70518.x6.nabble.com/TcpDiscoverySpi-setLocalPortRange-value-must-be-0-tp2606.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.


--------------020406060307030508000108
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi,<br>
    <br>
    Thank for pointing out to this issue. Local port range set to 0
    presently doesn't work at least for TcpCommunicationSpi and
    TcpDiscoverySpi. However SPIs support it.<br>
    <br>
    In my understanding the condition has to changed to the following
    one (from &lt; to &lt;=).<br>
    <pre wrap="">x = port; x <b>&lt;=</b> port + range</pre>
    But this will violate the following from
    TcpCommunicationSpi.setLocalPortRange<br>
    <meta http-equiv="content-type" content="text/html;
      charset=windows-1252">
    <pre style="background-color:#ffffff;color:#000000;font-family:'Courier New';font-size:9.0pt;"><span style="color:#808080;font-style:italic;">implementation will try to increment the port number for as long as it is less than
</span><span style="color:#808080;font-style:italic;">* initial value plus this range.

</span></pre>
    <div class="moz-cite-prefix">So it means that setLocalPortRange has
      to be treated a different way and in fact setLocalPortRange=0 will
      be the same as setLocalPortRange=1<br>
      <br>
      I've copied the message to @dev list to get more thoughts on this.<br>
      <br>
      Igniters, any thoughts? Should localPortRange=0 work the same as
      localPortRange=1?<br>
      <br>
      --<br>
      Denis<br>
      �<br>
      On 1/18/2016 12:21 PM, DLopez wrote:<br>
    </div>
    <blockquote cite="mid:1453108876139-2606.post@n6.nabble.com"
      type="cite">
      <pre wrap="">Hi,

While experimenting, as I was trying to just allow specific ports, I set the
LocalPortRange of my configurations to 0. The result was not what I expected
as you end up getting a NPE when starting the cluster. I traced the issue in
the source and the cause is that when opening ports, the routine goes from
the x = port; x &lt; port + range. So you end up with no server socket, and
when you try to listen to it, kaboum.

So I think it might be interesting to clarify the docs, as the current
definition (starting from getLocalPort() up until getLocalPort() +
locPortRange) can be misunderstood and the handling of localport value,
throwing an error if it is set to an incorrect value.

Just to prevent other people having the same issue :). Not a top priority,
of course, but such an easy change can prevent more support messages to the
list to... What do you think?

S!
D.


--
View this message in context: <a class="moz-txt-link-freetext" href="http://apache-ignite-users.70518.x6.nabble.com/TcpDiscoverySpi-setLocalPortRange-value-must-be-0-tp2606.html">http://apache-ignite-users.70518.x6.nabble.com/TcpDiscoverySpi-setLocalPortRange-value-must-be-0-tp2606.html</a>
Sent from the Apache Ignite Users mailing list archive at Nabble.com.
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------020406060307030508000108--