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.
