You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ignite.apache.org by DLopez <d....@gmail.com> on 2016/01/18 10:21:16 UTC
TcpDiscoverySpi.setLocalPortRange, value must be > 0
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.
Re: TcpDiscoverySpi.setLocalPortRange, value must be > 0
Posted by Denis Magda <dm...@gridgain.com>.
Ticket is ready for a contribution :)
https://issues.apache.org/jira/browse/IGNITE-2404
If anyone has any thoughts then feel free to put them there or pick the
ticket up and fix.
--
Denis
On 1/19/2016 11:45 AM, Dmitriy Setrakyan wrote:
> I think it is not a bad change. How about we open a ticket and mark it
> as “newbie”, so new community members could get started with it.
>
> On Mon, Jan 18, 2016 at 4:52 AM, Denis Magda <dmagda@gridgain.com
> <ma...@gridgain.com>> wrote:
>
> 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.
>
>
Re: TcpDiscoverySpi.setLocalPortRange, value must be > 0
Posted by Dmitriy Setrakyan <ds...@apache.org>.
I think it is not a bad change. How about we open a ticket and mark it as
“newbie”, so new community members could get started with it.
On Mon, Jan 18, 2016 at 4:52 AM, Denis Magda <dm...@gridgain.com> wrote:
> 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.
>
>
>
Re: TcpDiscoverySpi.setLocalPortRange, value must be > 0
Posted by Dmitriy Setrakyan <ds...@apache.org>.
I think it is not a bad change. How about we open a ticket and mark it as
“newbie”, so new community members could get started with it.
On Mon, Jan 18, 2016 at 4:52 AM, Denis Magda <dm...@gridgain.com> wrote:
> 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.
>
>
>
Re: TcpDiscoverySpi.setLocalPortRange, value must be > 0
Posted by Denis Magda <dm...@gridgain.com>.
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.
Re: TcpDiscoverySpi.setLocalPortRange, value must be > 0
Posted by Denis Magda <dm...@gridgain.com>.
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.