You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Ognen Duzlevski <og...@gmail.com> on 2015/04/18 22:27:39 UTC
Joining an ignite cluster (via ignite.sh) delay
Hello,
I have noticed that with 1.0.0-incubating there is somewhat of a delay with
"joining" an ignite cluster. I have 6 EC2 instances - I start ignite.sh
examples/configs/example-ignite.sh & and then move on the next instance.
The same command on the next instance takes about 5-10 seconds before it
returns and each additional instance seems to take even longer. Anyone else
notice this?
What ports do I need to have open on the instances so that they can all
talk to each other?
I have these so far:
ACCEPT udp -- anywhere anywhere udp dpt:31100
ACCEPT udp -- anywhere anywhere udp dpt:47400
ACCEPT tcp -- anywhere anywhere tcp dpt:47500
ACCEPT tcp -- anywhere anywhere tcp dpt:47100
Anything else necessary? Or is the above too much - some of them can be
closed - which ones?
Finally,
I get this when I run ingnite.sh (1.0.0-incubating):
[15:22:31] Topology snapshot [ver=3, nodes=3, CPUs=24, heap=3.0GB]
[15:22:32] New version is available at ignite.incubator.apache.org: 1.0.2
Where is 1.0.2 available for downloads? All I see is 1.0.0-incubating.
Thanks!
Re: Joining an ignite cluster (via ignite.sh) delay
Posted by Nikita Ivanov <ni...@gmail.com>.
Additional ticket on version notification update filed:
https://issues.apache.org/jira/browse/IGNITE-776
--
Nikita Ivanov
On Sun, Apr 19, 2015 at 8:49 PM, Branko Čibej <br...@apache.org> wrote:
> On 19.04.2015 17:11, Konstantin Boudnik wrote:
>
> On Sun, Apr 19, 2015 at 09:01AM, Branko Čibej wrote:
>
> On 19.04.2015 00:57, Dmitriy Setrakyan wrote:
>
> On Sat, Apr 18, 2015 at 1:27 PM, Ognen Duzlevski <og...@gmail.com> <og...@gmail.com>
> wrote:
>
>
> Hello,
>
> I have noticed that with 1.0.0-incubating there is somewhat of a delay with
> "joining" an ignite cluster. I have 6 EC2 instances - I start ignite.sh
> examples/configs/example-ignite.sh & and then move on the next instance.
> The same command on the next instance takes about 5-10 seconds before it
> returns and each additional instance seems to take even longer. Anyone else
> notice this?
>
>
>
> You should not be getting such pauses. What OS are you running on?
>
>
>
> I get this when I run ingnite.sh (1.0.0-incubating):
> [15:22:31] Topology snapshot [ver=3, nodes=3, CPUs=24, heap=3.0GB]
> [15:22:32] New version is available at ignite.incubator.apache.org: 1.0.2
>
> Where is 1.0.2 available for downloads? All I see is 1.0.0-incubating.
>
>
> You can download it here: http://www.gridgain.com/download/editions/
>
> HUH?? Excuse me, is Ignite looking at GridGain's site for version
> updates? How on earth can GridGain be offering versions of Ignite that
> have not been released, and worse, how can you possibly call the package
>
> Brane, I believe we have agreed that if anyone wants to offer their own builds
> of Ignite - it is ok, until they are not confused with official Apache
> releases of Ignite? If so, then someone moving at the different pace than
> Ignite can put binaries for uploads and call it a dev snapshot or community
> edition or whatever, no? Just trying to make sure we're on the same page.
>
>
> Certainly, I have no argument with that. However:
>
> - The build is promoted on the site as "GridGain Community Edition",
> which is perfectly fine, but the package is called "gridgain-ignite" and
> that's not fine;
> - It would be OK if were called 'apache-ignite-x.y.z.-bin-blabla' and
> promoted as "Ignite Binaries provided by GridGain" or similar, but in that
> case, one can't actually use a different version number than whatever has
> been published by the Ignite podling.
>
> Also note that, according to the OP, the log message (see above) implies
> that there's a new version of Ignite available ... which implies it's
> looking at the GridGain site. That's OK for for a GridGain Community
> Edition to do, but not OK for (convenience) binaries or builds source
> published on ASF mirrors. I'm guessing there's some confusion here as to
> which binaries were actually used: the goal of our branding and trademarks
> policies are to avoid exactly this kind of confusion.
>
>
> To summarize:
>
> - GridGain Enterprise Edition (e.g.,
> gridgain-enterprise-foo-version.zip) is fine;
> - GridGain Community Edition (e.g.,
> gridgain-community-foo-version.zip) is fine;
> - Apache Ignite binaries provided by GridGain (e.g.,
> apache-ignite-foo-version.zip) is fine, too, as long as the binaries don't
> go announcing version updates from info published on the GridGain site (but
> it's OK to look for info on the Ignite site); and as long as they either
> don't contain the LGPL&Co. dependencies, or very explicitly warn users that
> distribution rights are not covered by ALv2;
> - What's currently published is confusing, i.e., not OK.
>
>
> I'd also recommend that whatever GridGain publishes as their open source
> edition should have licensing terms and restrictions explained clearly
> prominently; of course, if and how that's done is no longer our (the ASF
> project's) problem, as long as they adhere to the "principle of least
> surprise," q.v. above.
>
>
> 'gridgain-ignite'? There's no such thing.
>
> Really, I thought we had the brand dilution and trademark violation
> questions sorted out.
>
> That's a bad idea, indeed! There shouldn't be such thing as Foo Ignite, where
> Foo != Apache. That's a clear contradiction to TM policy.
>
>
> Yes.
>
>
> -- Brane
>
>
Re: Joining an ignite cluster (via ignite.sh) delay
Posted by Nikita Ivanov <ni...@gmail.com>.
Agree w/Brane. Ticket on naming is filed:
https://issues.apache.org/jira/browse/IGNITE-775
--
Nikita Ivanov
On Sun, Apr 19, 2015 at 8:49 PM, Branko Čibej <br...@apache.org> wrote:
> On 19.04.2015 17:11, Konstantin Boudnik wrote:
>
> On Sun, Apr 19, 2015 at 09:01AM, Branko Čibej wrote:
>
> On 19.04.2015 00:57, Dmitriy Setrakyan wrote:
>
> On Sat, Apr 18, 2015 at 1:27 PM, Ognen Duzlevski <og...@gmail.com> <og...@gmail.com>
> wrote:
>
>
> Hello,
>
> I have noticed that with 1.0.0-incubating there is somewhat of a delay with
> "joining" an ignite cluster. I have 6 EC2 instances - I start ignite.sh
> examples/configs/example-ignite.sh & and then move on the next instance.
> The same command on the next instance takes about 5-10 seconds before it
> returns and each additional instance seems to take even longer. Anyone else
> notice this?
>
>
>
> You should not be getting such pauses. What OS are you running on?
>
>
>
> I get this when I run ingnite.sh (1.0.0-incubating):
> [15:22:31] Topology snapshot [ver=3, nodes=3, CPUs=24, heap=3.0GB]
> [15:22:32] New version is available at ignite.incubator.apache.org: 1.0.2
>
> Where is 1.0.2 available for downloads? All I see is 1.0.0-incubating.
>
>
> You can download it here: http://www.gridgain.com/download/editions/
>
> HUH?? Excuse me, is Ignite looking at GridGain's site for version
> updates? How on earth can GridGain be offering versions of Ignite that
> have not been released, and worse, how can you possibly call the package
>
> Brane, I believe we have agreed that if anyone wants to offer their own builds
> of Ignite - it is ok, until they are not confused with official Apache
> releases of Ignite? If so, then someone moving at the different pace than
> Ignite can put binaries for uploads and call it a dev snapshot or community
> edition or whatever, no? Just trying to make sure we're on the same page.
>
>
> Certainly, I have no argument with that. However:
>
> - The build is promoted on the site as "GridGain Community Edition",
> which is perfectly fine, but the package is called "gridgain-ignite" and
> that's not fine;
> - It would be OK if were called 'apache-ignite-x.y.z.-bin-blabla' and
> promoted as "Ignite Binaries provided by GridGain" or similar, but in that
> case, one can't actually use a different version number than whatever has
> been published by the Ignite podling.
>
> Also note that, according to the OP, the log message (see above) implies
> that there's a new version of Ignite available ... which implies it's
> looking at the GridGain site. That's OK for for a GridGain Community
> Edition to do, but not OK for (convenience) binaries or builds source
> published on ASF mirrors. I'm guessing there's some confusion here as to
> which binaries were actually used: the goal of our branding and trademarks
> policies are to avoid exactly this kind of confusion.
>
>
> To summarize:
>
> - GridGain Enterprise Edition (e.g.,
> gridgain-enterprise-foo-version.zip) is fine;
> - GridGain Community Edition (e.g.,
> gridgain-community-foo-version.zip) is fine;
> - Apache Ignite binaries provided by GridGain (e.g.,
> apache-ignite-foo-version.zip) is fine, too, as long as the binaries don't
> go announcing version updates from info published on the GridGain site (but
> it's OK to look for info on the Ignite site); and as long as they either
> don't contain the LGPL&Co. dependencies, or very explicitly warn users that
> distribution rights are not covered by ALv2;
> - What's currently published is confusing, i.e., not OK.
>
>
> I'd also recommend that whatever GridGain publishes as their open source
> edition should have licensing terms and restrictions explained clearly
> prominently; of course, if and how that's done is no longer our (the ASF
> project's) problem, as long as they adhere to the "principle of least
> surprise," q.v. above.
>
>
> 'gridgain-ignite'? There's no such thing.
>
> Really, I thought we had the brand dilution and trademark violation
> questions sorted out.
>
> That's a bad idea, indeed! There shouldn't be such thing as Foo Ignite, where
> Foo != Apache. That's a clear contradiction to TM policy.
>
>
> Yes.
>
>
> -- Brane
>
>
Re: Joining an ignite cluster (via ignite.sh) delay
Posted by Branko Čibej <br...@apache.org>.
On 19.04.2015 17:11, Konstantin Boudnik wrote:
> On Sun, Apr 19, 2015 at 09:01AM, Branko Čibej wrote:
>> On 19.04.2015 00:57, Dmitriy Setrakyan wrote:
>>> On Sat, Apr 18, 2015 at 1:27 PM, Ognen Duzlevski <og...@gmail.com>
>>> wrote:
>>>
>>>> Hello,
>>>>
>>>> I have noticed that with 1.0.0-incubating there is somewhat of a delay with
>>>> "joining" an ignite cluster. I have 6 EC2 instances - I start ignite.sh
>>>> examples/configs/example-ignite.sh & and then move on the next instance.
>>>> The same command on the next instance takes about 5-10 seconds before it
>>>> returns and each additional instance seems to take even longer. Anyone else
>>>> notice this?
>>>>
>>>>
>>> You should not be getting such pauses. What OS are you running on?
>>>
>>>
>>>> I get this when I run ingnite.sh (1.0.0-incubating):
>>>> [15:22:31] Topology snapshot [ver=3, nodes=3, CPUs=24, heap=3.0GB]
>>>> [15:22:32] New version is available at ignite.incubator.apache.org: 1.0.2
>>>>
>>>> Where is 1.0.2 available for downloads? All I see is 1.0.0-incubating.
>>>>
>>> You can download it here: http://www.gridgain.com/download/editions/
>> HUH?? Excuse me, is Ignite looking at GridGain's site for version
>> updates? How on earth can GridGain be offering versions of Ignite that
>> have not been released, and worse, how can you possibly call the package
> Brane, I believe we have agreed that if anyone wants to offer their own builds
> of Ignite - it is ok, until they are not confused with official Apache
> releases of Ignite? If so, then someone moving at the different pace than
> Ignite can put binaries for uploads and call it a dev snapshot or community
> edition or whatever, no? Just trying to make sure we're on the same page.
Certainly, I have no argument with that. However:
* The build is promoted on the site as "GridGain Community Edition",
which is perfectly fine, but the package is called "gridgain-ignite"
and that's not fine;
* It would be OK if were called 'apache-ignite-x.y.z.-bin-blabla' and
promoted as "Ignite Binaries provided by GridGain" or similar, but
in that case, one can't actually use a different version number than
whatever has been published by the Ignite podling.
Also note that, according to the OP, the log message (see above) implies
that there's a new version of Ignite available ... which implies it's
looking at the GridGain site. That's OK for for a GridGain Community
Edition to do, but not OK for (convenience) binaries or builds source
published on ASF mirrors. I'm guessing there's some confusion here as to
which binaries were actually used: the goal of our branding and
trademarks policies are to avoid exactly this kind of confusion.
To summarize:
* GridGain Enterprise Edition (e.g.,
gridgain-enterprise-foo-version.zip) is fine;
* GridGain Community Edition (e.g.,
gridgain-community-foo-version.zip) is fine;
* Apache Ignite binaries provided by GridGain (e.g.,
apache-ignite-foo-version.zip) is fine, too, as long as the binaries
don't go announcing version updates from info published on the
GridGain site (but it's OK to look for info on the Ignite site); and
as long as they either don't contain the LGPL&Co. dependencies, or
very explicitly warn users that distribution rights are not covered
by ALv2;
* What's currently published is confusing, i.e., not OK.
I'd also recommend that whatever GridGain publishes as their open source
edition should have licensing terms and restrictions explained clearly
prominently; of course, if and how that's done is no longer our (the ASF
project's) problem, as long as they adhere to the "principle of least
surprise," q.v. above.
>
>> 'gridgain-ignite'? There's no such thing.
>>
>> Really, I thought we had the brand dilution and trademark violation
>> questions sorted out.
> That's a bad idea, indeed! There shouldn't be such thing as Foo Ignite, where
> Foo != Apache. That's a clear contradiction to TM policy.
Yes.
-- Brane
Re: Joining an ignite cluster (via ignite.sh) delay
Posted by Konstantin Boudnik <co...@apache.org>.
On Sun, Apr 19, 2015 at 09:01AM, Branko Čibej wrote:
> On 19.04.2015 00:57, Dmitriy Setrakyan wrote:
> > On Sat, Apr 18, 2015 at 1:27 PM, Ognen Duzlevski <og...@gmail.com>
> > wrote:
> >
> >> Hello,
> >>
> >> I have noticed that with 1.0.0-incubating there is somewhat of a delay with
> >> "joining" an ignite cluster. I have 6 EC2 instances - I start ignite.sh
> >> examples/configs/example-ignite.sh & and then move on the next instance.
> >> The same command on the next instance takes about 5-10 seconds before it
> >> returns and each additional instance seems to take even longer. Anyone else
> >> notice this?
> >>
> >>
> > You should not be getting such pauses. What OS are you running on?
> >
> >
> >> I get this when I run ingnite.sh (1.0.0-incubating):
> >> [15:22:31] Topology snapshot [ver=3, nodes=3, CPUs=24, heap=3.0GB]
> >> [15:22:32] New version is available at ignite.incubator.apache.org: 1.0.2
> >>
> >> Where is 1.0.2 available for downloads? All I see is 1.0.0-incubating.
> >>
> > You can download it here: http://www.gridgain.com/download/editions/
>
> HUH?? Excuse me, is Ignite looking at GridGain's site for version
> updates? How on earth can GridGain be offering versions of Ignite that
> have not been released, and worse, how can you possibly call the package
Brane, I believe we have agreed that if anyone wants to offer their own builds
of Ignite - it is ok, until they are not confused with official Apache
releases of Ignite? If so, then someone moving at the different pace than
Ignite can put binaries for uploads and call it a dev snapshot or community
edition or whatever, no? Just trying to make sure we're on the same page.
> 'gridgain-ignite'? There's no such thing.
>
> Really, I thought we had the brand dilution and trademark violation
> questions sorted out.
That's a bad idea, indeed! There shouldn't be such thing as Foo Ignite, where
Foo != Apache. That's a clear contradiction to TM policy.
Regards,
Cos
Re: Joining an ignite cluster (via ignite.sh) delay
Posted by Branko Čibej <br...@apache.org>.
On 19.04.2015 00:57, Dmitriy Setrakyan wrote:
> On Sat, Apr 18, 2015 at 1:27 PM, Ognen Duzlevski <og...@gmail.com>
> wrote:
>
>> Hello,
>>
>> I have noticed that with 1.0.0-incubating there is somewhat of a delay with
>> "joining" an ignite cluster. I have 6 EC2 instances - I start ignite.sh
>> examples/configs/example-ignite.sh & and then move on the next instance.
>> The same command on the next instance takes about 5-10 seconds before it
>> returns and each additional instance seems to take even longer. Anyone else
>> notice this?
>>
>>
> You should not be getting such pauses. What OS are you running on?
>
>
>> I get this when I run ingnite.sh (1.0.0-incubating):
>> [15:22:31] Topology snapshot [ver=3, nodes=3, CPUs=24, heap=3.0GB]
>> [15:22:32] New version is available at ignite.incubator.apache.org: 1.0.2
>>
>> Where is 1.0.2 available for downloads? All I see is 1.0.0-incubating.
>>
> You can download it here: http://www.gridgain.com/download/editions/
HUH?? Excuse me, is Ignite looking at GridGain's site for version
updates? How on earth can GridGain be offering versions of Ignite that
have not been released, and worse, how can you possibly call the package
'gridgain-ignite'? There's no such thing.
Really, I thought we had the brand dilution and trademark violation
questions sorted out.
-- Brane
Re: Joining an ignite cluster (via ignite.sh) delay
Posted by Ognen Duzlevski <og...@gmail.com>.
Dmitriy,
On Sun, Apr 19, 2015 at 12:57 AM, Dmitriy Setrakyan <ds...@apache.org>
wrote:
> On Sat, Apr 18, 2015 at 1:27 PM, Ognen Duzlevski <
> ognen.duzlevski@gmail.com>
> wrote:
>
> >> Hello,
> >>
> >> I have noticed that with 1.0.0-incubating there is somewhat of a delay
> with
> >> "joining" an ignite cluster. I have 6 EC2 instances - I start ignite.sh
> >> examples/configs/example-ignite.sh & and then move on the next instance.
> >> The same command on the next instance takes about 5-10 seconds before it
> >> returns and each additional instance seems to take even longer. Anyone
> else
> >> notice this?
> >
> >
> > You should not be getting such pauses. What OS are you running on?
>
>
Linux (the Amazon AMI on EC2).
Can you also tell me which ports (tcp and/or udp) need to be open on the
instances to make it all work? So far I have deduced a few from running
"netstat -lp" on the machines running ignite.sh but I did not have the time
to figure out which ones are actually necessary.
>> I get this when I run ingnite.sh (1.0.0-incubating):
> >> [15:22:31] Topology snapshot [ver=3, nodes=3, CPUs=24, heap=3.0GB]
> >> [15:22:32] New version is available at ignite.incubator.apache.org:
> 1.0.2
> >>
> >> Where is 1.0.2 available for downloads? All I see is 1.0.0-incubating.
> >>
> >
> >You can download it here: http://www.gridgain.com/download/editions/
Ah, OK. The ignite.sh script spits out the apache URL, not the gridgain one.
Thanks!
Re: Joining an ignite cluster (via ignite.sh) delay
Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Sat, Apr 18, 2015 at 1:27 PM, Ognen Duzlevski <og...@gmail.com>
wrote:
> Hello,
>
> I have noticed that with 1.0.0-incubating there is somewhat of a delay with
> "joining" an ignite cluster. I have 6 EC2 instances - I start ignite.sh
> examples/configs/example-ignite.sh & and then move on the next instance.
> The same command on the next instance takes about 5-10 seconds before it
> returns and each additional instance seems to take even longer. Anyone else
> notice this?
>
>
You should not be getting such pauses. What OS are you running on?
> I get this when I run ingnite.sh (1.0.0-incubating):
> [15:22:31] Topology snapshot [ver=3, nodes=3, CPUs=24, heap=3.0GB]
> [15:22:32] New version is available at ignite.incubator.apache.org: 1.0.2
>
> Where is 1.0.2 available for downloads? All I see is 1.0.0-incubating.
>
You can download it here: http://www.gridgain.com/download/editions/
>
> Thanks!
>