[GitHub] ignite pull request #3828: IGNITE-8154

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/3828


---

Re: GA Grid: Can IGNITE-8242 be include in 2.5 release?

[Yury Babak]

Denis,

In that case we should also add the following tickets into release:

https://issues.apache.org/jira/browse/IGNITE-7877 (Improve code style in GA
part)
https://issues.apache.org/jira/browse/IGNITE-7916 (GA Grid examples should
be ready for auto run on TeamCity)
https://issues.apache.org/jira/browse/IGNITE-8181 (fix for javadoc)

Andrey,

if you ok with it I could cherry pick those tickets into 2.5 branch

Regards,

Yury Babak
GridGain Systems

On Fri, Apr 20, 2018 at 1:48 AM, Denis Magda  wrote:

> Yuri, Andrey,
>
> Could you have a look and include the ticket into the release?
>
> --
> Denis
>
>
> On Thu, Apr 19, 2018 at 3:23 PM, techbysample  wrote:
>
>> Denis/Yury
>>
>> Can ticket https://issues.apache.org/jira/browse/IGNITE-8242  be included
>> within 2.5 release?
>> Upon review of my tickets today, I noticed the fixed version was updated
>> from 2.5 to 2.6?
>>
>> This ticket addresses a minor bug in GA Grid.
>>
>> I have removed method GAGridUtils.getGenesForChromosome() as it is
>> problematic when Chromosome contains duplicate genes.
>>
>> GAGridUtils.getGenesInOrderForChromosome() will be used instead.
>>
>> Please advise.
>>
>> Turik
>>
>>
>>
>> --
>> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
>>
>
>

Re: Service grid redesign

[Denis Magda]

Dmitriy,

Consider IEP page as a summary that was updated along the way:
https://cwiki.apache.org/confluence/display/IGNITE/IEP-17%3A+Oil+Change+in+Service+Grid

As far as I understand, Denis is going to create JIRA tickets basing on the
discussion results.

--
Denis

On Sat, Apr 21, 2018 at 3:04 AM, Dmitriy Setrakyan 
wrote:

> I am not sure why we are discussing a potential removal of the "init"
> method. I think it is useful, as the service may have to do some
> initialization before it goes online. I do not think this method is hurting
> anyone.
>
> This thread is getting too long, and I am sure that most readers are
> already getting lost in the proposed design. I would start a new thread
> with a summary of all proposed changes.
>
> D.
>
> On Fri, Apr 20, 2018 at 5:25 PM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Denis,
> >
> > > On the other hand, if exception is thrown from the *execute() *method,
> > then service won't be undeployed.
> >
> > This is actually weird... What is going to happen in this case and how
> user
> > would handle this?
> >
> > -Val
> >
> > On Fri, Apr 20, 2018 at 1:10 AM, Denis Mekhanikov  >
> > wrote:
> >
> > > Val,
> > >
> > > *init()* method is executed before a service is considered deployed.
> > > If any exception is thrown from it, then it will be handled as
> deployment
> > > failure.
> > >
> > > *execute() *method is run after the service is deployed, and it can
> keep
> > > running until the service is cancelled.
> > > This method has its own thread, so it can perform some background work.
> > >
> > > Suppose you want to deploy HTTP server as a service on one of your
> nodes.
> > > You can place HTTP server creation logic in the *init() *method.
> > > If some nodes don't have a permission to listen to needed ports, then a
> > > corresponding exception will be propagated to the user code.
> > > On the other hand, if exception is thrown from the *execute() *method,
> > then
> > > service won't be undeployed.
> > >
> > > Denis
> > >
> > > пт, 20 апр. 2018 г. в 2:35, Valentin Kulichenko <
> > > valentin.kuliche...@gmail.com>:
> > >
> > > > Denis,
> > > >
> > > > I totally agree with you. I'm just not sure why do we need two
> methods
> > > > (init and execute) that have virtually same semantics. With the new
> > > design,
> > > > what would be the difference between these methods from user point of
> > > view,
> > > > and how one would determine what exactly should go in each of them?
> > > Unless
> > > > I'm missing something, it looks like unnecessary complication.
> > > >
> > > > -Val
> > > >
> > > > On Tue, Apr 17, 2018 at 1:00 AM, Denis Mekhanikov <
> > dmekhani...@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > Val,
> > > > >
> > > > > Service initialisation is not going to happen in the discovery
> > thread.
> > > > > It should be done asynchronously, and initialisation results should
> > be
> > > > sent
> > > > > to the coordinator over communication.
> > > > > This is described in the IEP:
> > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-
> > > > > 17%3A+Oil+Change+in+Service+Grid#IEP-17:OilChangeinServiceGrid-
> > > > > Successfulscenario
> > > > >
> > > > > *init()* method is a validation step, making sure, that service is
> > > ready
> > > > > for work.
> > > > > And deployment shouldn't be considered successful until *init()*
> > > methods
> > > > > finish their work on the assigned nodes.
> > > > > Also *cancel() *and *init() *methods may be useful if we decide to
> > > > > implement moving existing services to new nodes
> > > > >  > > > > 17%3A+Oil+Change+in+Service+Grid#IEP-17:OilChangeinServiceGrid-
> > > > > Movingexistingservicestonewnodes>
> > > > >  in
> > > > > future.
> > > > > These methods can be used to save and restore service's state from
> > > cache,
> > > > > when it is rebalanced to another node.
> > > > >
> > > > > As Denis said, if we are not going to prevent nodes from starting
> on
> > > > > service failures, then we should at least generate corresponding
> > > events.
> > > > > Otherwise there won't be any way to react to service initialization
> > > > > failures during nodes startup.
> > > > >
> > > > > Denis
> > > > >
> > > > > вт, 17 апр. 2018 г. в 6:59, Valentin Kulichenko <
> > > > > valentin.kuliche...@gmail.com>:
> > > > >
> > > > > > I agree we shouldn't do anything synchronously within discovery
> > > > threads.
> > > > > If
> > > > > > something goes wrong, we just need to properly notify the user,
> > > logging
> > > > > and
> > > > > > events seem to be right options to achieve that.
> > > > > >
> > > > > > BTW, with this design I'm not sure init() method makes sense,
> > > probably
> > > > we
> > > > > > should deprecate it.
> > > > > >
> > > > > > -Val
> > > > > >
> > > > > > On Mon, Apr 16, 2018 at 12:03 PM, Denis Magda  >
> > > > wrote:
> > > > > >
> > 

[GitHub] ignite pull request #3895: Mmuzaf check ignite 8086

[Mmuzaf]

GitHub user Mmuzaf opened a pull request:

https://github.com/apache/ignite/pull/3895

Mmuzaf check ignite 8086



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/Mmuzaf/ignite mmuzaf-check-ignite-8086

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3895.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3895


commit 9392742f2b8b6e7f274717347fd269b2f0886db3
Author: Maxim Muzafarov 
Date:   2018-04-21T17:41:20Z

IGNITE-8086: add manual cache rebalance method

commit a4e8d70300a8a7066453200f7c0c41b320ed06cf
Author: Maxim Muzafarov 
Date:   2018-04-21T17:42:08Z

Merge branch 'master' into ignite-8086

commit b015690a69d62722e0f31975ba8f490975e5a906
Author: Maxim Muzafarov 
Date:   2018-04-21T17:48:09Z

IGNITE-8086: fix manual rebalancing

commit 95b347aca5c404a08737e1a8950d24bb0812b9be
Author: Maxim Muzafarov 
Date:   2018-04-21T17:50:40Z

IGNITE-8086: update suite for flaky tests




---

[GitHub] ignite pull request #3894: Ignite 8086: add manual rebalace method

[Mmuzaf]

GitHub user Mmuzaf opened a pull request:

https://github.com/apache/ignite/pull/3894

Ignite 8086: add manual rebalace method



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/Mmuzaf/ignite ignite-8086

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3894.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3894


commit 9392742f2b8b6e7f274717347fd269b2f0886db3
Author: Maxim Muzafarov 
Date:   2018-04-21T17:41:20Z

IGNITE-8086: add manual cache rebalance method

commit a4e8d70300a8a7066453200f7c0c41b320ed06cf
Author: Maxim Muzafarov 
Date:   2018-04-21T17:42:08Z

Merge branch 'master' into ignite-8086




---

Re: GA Grid Documentation for 2.5

[techbysample]

Denis,

I am in the process of updating docs and just created ticket:

https://issues.apache.org/jira/browse/IGNITE-8350

I will assign to Akmal for final review once I have completed.

Best,
Turik



--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

[jira] [Created] (IGNITE-8350) GA Grid: Prepare documentation for 2.5

[Turik Campbell (JIRA)]

Turik Campbell created IGNITE-8350:
--

 Summary: GA Grid: Prepare documentation for 2.5
 Key: IGNITE-8350
 URL: https://issues.apache.org/jira/browse/IGNITE-8350
 Project: Ignite
  Issue Type: New Feature
  Components: documentation
Reporter: Turik Campbell
Assignee: Turik Campbell
 Fix For: 2.5


Review documentation and prepare for 2.5.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Topology-wide notification on critical errors

[Dmitriy Setrakyan]

On Fri, Apr 20, 2018 at 4:50 AM, Anton Vinogradov  wrote:

> P.s. Andrey Kuznetsov, corrected me that we have no warranty that failed
> node able to notify cluster.
>
> But,
>
> try{
>sendDiscoveryMessageWithFail(...);
> } catch(){
>// No-op;
> }
>
> is better than nothing, I think.
>

Agree about the "better than nothing" part, but do not agree about the
"no-op" in the catch block. We should still log the fact that sending of
the failure message failed and provide the exception stack trace if there
is one.

Re: Service grid redesign

[Dmitriy Setrakyan]

I am not sure why we are discussing a potential removal of the "init"
method. I think it is useful, as the service may have to do some
initialization before it goes online. I do not think this method is hurting
anyone.

This thread is getting too long, and I am sure that most readers are
already getting lost in the proposed design. I would start a new thread
with a summary of all proposed changes.

D.

On Fri, Apr 20, 2018 at 5:25 PM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Denis,
>
> > On the other hand, if exception is thrown from the *execute() *method,
> then service won't be undeployed.
>
> This is actually weird... What is going to happen in this case and how user
> would handle this?
>
> -Val
>
> On Fri, Apr 20, 2018 at 1:10 AM, Denis Mekhanikov 
> wrote:
>
> > Val,
> >
> > *init()* method is executed before a service is considered deployed.
> > If any exception is thrown from it, then it will be handled as deployment
> > failure.
> >
> > *execute() *method is run after the service is deployed, and it can keep
> > running until the service is cancelled.
> > This method has its own thread, so it can perform some background work.
> >
> > Suppose you want to deploy HTTP server as a service on one of your nodes.
> > You can place HTTP server creation logic in the *init() *method.
> > If some nodes don't have a permission to listen to needed ports, then a
> > corresponding exception will be propagated to the user code.
> > On the other hand, if exception is thrown from the *execute() *method,
> then
> > service won't be undeployed.
> >
> > Denis
> >
> > пт, 20 апр. 2018 г. в 2:35, Valentin Kulichenko <
> > valentin.kuliche...@gmail.com>:
> >
> > > Denis,
> > >
> > > I totally agree with you. I'm just not sure why do we need two methods
> > > (init and execute) that have virtually same semantics. With the new
> > design,
> > > what would be the difference between these methods from user point of
> > view,
> > > and how one would determine what exactly should go in each of them?
> > Unless
> > > I'm missing something, it looks like unnecessary complication.
> > >
> > > -Val
> > >
> > > On Tue, Apr 17, 2018 at 1:00 AM, Denis Mekhanikov <
> dmekhani...@gmail.com
> > >
> > > wrote:
> > >
> > > > Val,
> > > >
> > > > Service initialisation is not going to happen in the discovery
> thread.
> > > > It should be done asynchronously, and initialisation results should
> be
> > > sent
> > > > to the coordinator over communication.
> > > > This is described in the IEP:
> > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-
> > > > 17%3A+Oil+Change+in+Service+Grid#IEP-17:OilChangeinServiceGrid-
> > > > Successfulscenario
> > > >
> > > > *init()* method is a validation step, making sure, that service is
> > ready
> > > > for work.
> > > > And deployment shouldn't be considered successful until *init()*
> > methods
> > > > finish their work on the assigned nodes.
> > > > Also *cancel() *and *init() *methods may be useful if we decide to
> > > > implement moving existing services to new nodes
> > > >  > > > 17%3A+Oil+Change+in+Service+Grid#IEP-17:OilChangeinServiceGrid-
> > > > Movingexistingservicestonewnodes>
> > > >  in
> > > > future.
> > > > These methods can be used to save and restore service's state from
> > cache,
> > > > when it is rebalanced to another node.
> > > >
> > > > As Denis said, if we are not going to prevent nodes from starting on
> > > > service failures, then we should at least generate corresponding
> > events.
> > > > Otherwise there won't be any way to react to service initialization
> > > > failures during nodes startup.
> > > >
> > > > Denis
> > > >
> > > > вт, 17 апр. 2018 г. в 6:59, Valentin Kulichenko <
> > > > valentin.kuliche...@gmail.com>:
> > > >
> > > > > I agree we shouldn't do anything synchronously within discovery
> > > threads.
> > > > If
> > > > > something goes wrong, we just need to properly notify the user,
> > logging
> > > > and
> > > > > events seem to be right options to achieve that.
> > > > >
> > > > > BTW, with this design I'm not sure init() method makes sense,
> > probably
> > > we
> > > > > should deprecate it.
> > > > >
> > > > > -Val
> > > > >
> > > > > On Mon, Apr 16, 2018 at 12:03 PM, Denis Magda 
> > > wrote:
> > > > >
> > > > > > Denis,
> > > > > >
> > > > > > In general, service initialization shouldn't prevent a node from
> > > > joining
> > > > > > the cluster or slowing down that process. Thus, I would start the
> > > > > > initialization routines only after the node is accepted by the
> > > cluster.
> > > > > If
> > > > > > the initialization fails then we need to report a respective
> > message
> > > to
> > > > > the
> > > > > > logs and, probably, generate a system event the user can be
> > > subscribed
> > > > > to.
> > > > > >
> > > > > > Regardless, of the service initialization time, I think we still
> > need
> > > >