[GitHub] ignite pull request #4322: IGNITE-8950 More informative file validation chec...

[asfgit]

Github user asfgit closed the pull request at:

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


---

Re: [Discussion] revert of commit MVCC, ignite-9320

[Dmitriy Pavlov]

Hi Vladimir,

https://issues.apache.org/jira/browse/IGNITE-9320 is named configuration
finalization.

Why finalization was considered as done without tests passing?

Why can't ve revert finalization change, re-do finalization with passing
tests and merge changes?

Sincerely,
Dmitriy Pavlov

пт, 28 сент. 2018 г. в 8:16, Vladimir Ozerov :

> Test is going to be fixed in the scope of AI 2.7 [1]. This is not
> one-minute fix as there are multiple places where configuration should be
> passed, and changes should be covered with tests. I muted the test for now.
>
> [1] https://issues.apache.org/jira/browse/IGNITE-9390
>
> On Fri, Sep 28, 2018 at 2:40 AM Dmitriy Setrakyan 
> wrote:
>
> > Let's not revert any commits yet. Can we find out who did the commit and
> > why he/she is not fixing the test?
> >
> > D.
> >
> > On Thu, Sep 27, 2018 at 4:21 PM Vyacheslav Daradur 
> > wrote:
> >
> > > Hi,
> > >
> > > Are you talking about
> > > 'IgniteConfigurationParityTest#TestIgniteConfiguration'?
> > >
> > > Seems it's not hard to fix this test, it's necessary just to implement
> > > missing members (at least as stubs) on .NET side in
> > > IgniteConfiguration class.
> > >
> > > Is there a Jira issue?
> > >
> > > On Fri, Sep 28, 2018 at 2:12 AM Dmitriy Pavlov 
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > I'm grateful for contributions made in that area, but it seems folks
> > > don't
> > > > have time to fix the test.
> > > >
> > > >
> > > > Tomorrow I'm going to revert commit.
> > > >
> > > > It seems it is the only way we can keep master more or less green.
> > > >
> > > >
> > >
> >
> https://ci.ignite.apache.org/viewLog.html?buildId=1888723&tab=buildChangesDiv&buildTypeId=IgniteTests24Java8_PlatformNet
> > > >
> > > >
> > > > Sincerely
> > > > Dmitry Pavlov
> > >
> > >
> > >
> > > --
> > > Best Regards, Vyacheslav D.
> > >
> >
>

[GitHub] ignite pull request #4862: IGNITE-9723: use blockingSectionBegin method to w...

[Mmuzaf]

GitHub user Mmuzaf opened a pull request:

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

IGNITE-9723: use blockingSectionBegin method to wrap exch future



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

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

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

https://github.com/apache/ignite/pull/4862.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 #4862


commit e1d0df6c1e647f523c10f424d642564122f0119e
Author: Maxim Muzafarov 
Date:   2018-09-28T07:23:56Z

IGNITE-9723: use blockingSectionBegin method to wrap exch future




---

Re: [Discussion] revert of commit MVCC, ignite-9320

[Dmitriy Pavlov]

Hi Dmitriy,

Why not revert the change?

This test failure was appropriately reported to the dev list, and the
contributor did not fix it:
http://apache-ignite-developers.2346864.n4.nabble.com/MTCGA-new-failures-in-builds-1888723-needs-to-be-handled-td35239.html


It seems this idea of filing blockers does not work well.  It means for
community member:
- someday/maybe/someone will fix this blocker
- or he/she will move it to 3.0
- or we will reclassify and minor and mute test.

I can see tons of tests fixes going from 2.7 to 2.8. It always means I, for
example, will break test today, and someone will come and do not-so-fun
work for me.

I see tons of tickets about fixing the tests, so I prefer that Igniters who
invest their time here should achieve the result (green master), but not
those who are ignoring How To Contribute, even it is GridGain'ers.

I suggest reverts of new stable test failures should be more or less
automatic after 72h as a reasonable time to fix it. If contributor would
like to finalize solution (and most of the cases it is so), a test will be
fixed in 3 days.

If not, why to have not ready solutions in master, let's have it in
separate branches.

So, what do you suggest instead?

Sincerely,
Dmitriy Pavlov

пт, 28 сент. 2018 г. в 2:40, Dmitriy Setrakyan :

> Let's not revert any commits yet. Can we find out who did the commit and
> why he/she is not fixing the test?
>
> D.
>
> On Thu, Sep 27, 2018 at 4:21 PM Vyacheslav Daradur 
> wrote:
>
> > Hi,
> >
> > Are you talking about
> > 'IgniteConfigurationParityTest#TestIgniteConfiguration'?
> >
> > Seems it's not hard to fix this test, it's necessary just to implement
> > missing members (at least as stubs) on .NET side in
> > IgniteConfiguration class.
> >
> > Is there a Jira issue?
> >
> > On Fri, Sep 28, 2018 at 2:12 AM Dmitriy Pavlov 
> > wrote:
> > >
> > > Hi,
> > >
> > > I'm grateful for contributions made in that area, but it seems folks
> > don't
> > > have time to fix the test.
> > >
> > >
> > > Tomorrow I'm going to revert commit.
> > >
> > > It seems it is the only way we can keep master more or less green.
> > >
> > >
> >
> https://ci.ignite.apache.org/viewLog.html?buildId=1888723&tab=buildChangesDiv&buildTypeId=IgniteTests24Java8_PlatformNet
> > >
> > >
> > > Sincerely
> > > Dmitry Pavlov
> >
> >
> >
> > --
> > Best Regards, Vyacheslav D.
> >
>

Re: [Discussion] revert of commit MVCC, ignite-9320

[Vladimir Ozerov]

Because a lot of other activities depended on configuration in Java, and we
didn't have expertise to fix .NET immediately.

If you want to revert it - please go ahead. But I'd better suggest you to
think about the impact and project priorities first, instead of trying to
apply the some sort rules blindly. We are not robots.

On Fri, Sep 28, 2018 at 10:19 AM Dmitriy Pavlov 
wrote:

> Hi Vladimir,
>
> https://issues.apache.org/jira/browse/IGNITE-9320 is named configuration
> finalization.
>
> Why finalization was considered as done without tests passing?
>
> Why can't ve revert finalization change, re-do finalization with passing
> tests and merge changes?
>
> Sincerely,
> Dmitriy Pavlov
>
> пт, 28 сент. 2018 г. в 8:16, Vladimir Ozerov :
>
> > Test is going to be fixed in the scope of AI 2.7 [1]. This is not
> > one-minute fix as there are multiple places where configuration should be
> > passed, and changes should be covered with tests. I muted the test for
> now.
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-9390
> >
> > On Fri, Sep 28, 2018 at 2:40 AM Dmitriy Setrakyan  >
> > wrote:
> >
> > > Let's not revert any commits yet. Can we find out who did the commit
> and
> > > why he/she is not fixing the test?
> > >
> > > D.
> > >
> > > On Thu, Sep 27, 2018 at 4:21 PM Vyacheslav Daradur <
> daradu...@gmail.com>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > Are you talking about
> > > > 'IgniteConfigurationParityTest#TestIgniteConfiguration'?
> > > >
> > > > Seems it's not hard to fix this test, it's necessary just to
> implement
> > > > missing members (at least as stubs) on .NET side in
> > > > IgniteConfiguration class.
> > > >
> > > > Is there a Jira issue?
> > > >
> > > > On Fri, Sep 28, 2018 at 2:12 AM Dmitriy Pavlov <
> dpavlov@gmail.com>
> > > > wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > I'm grateful for contributions made in that area, but it seems
> folks
> > > > don't
> > > > > have time to fix the test.
> > > > >
> > > > >
> > > > > Tomorrow I'm going to revert commit.
> > > > >
> > > > > It seems it is the only way we can keep master more or less green.
> > > > >
> > > > >
> > > >
> > >
> >
> https://ci.ignite.apache.org/viewLog.html?buildId=1888723&tab=buildChangesDiv&buildTypeId=IgniteTests24Java8_PlatformNet
> > > > >
> > > > >
> > > > > Sincerely
> > > > > Dmitry Pavlov
> > > >
> > > >
> > > >
> > > > --
> > > > Best Regards, Vyacheslav D.
> > > >
> > >
> >
>

Re: [Discussion] revert of commit MVCC, ignite-9320

[Dmitriy Pavlov]

Yep, we're humans and we constantly make mistakes. It is a very human thing
to do mistakes.

So I suggest we will be under the control and protection of robot to avoid
mistakes, I suggest robot will revert such commits in 72h without its own
personal attitudes, emotions, etc.

Someone who is interested in contribution usually can find time to make
contribution perfect.

I'm not aware of project priorities, please share it. I believe different
priorities can co-exist. A number of contributors are fixing tests, so it
is a priority for them, isn't it? So why to add work to that guys because
of you have other priorities?

пт, 28 сент. 2018 г. в 10:39, Vladimir Ozerov :

> Because a lot of other activities depended on configuration in Java, and we
> didn't have expertise to fix .NET immediately.
>
> If you want to revert it - please go ahead. But I'd better suggest you to
> think about the impact and project priorities first, instead of trying to
> apply the some sort rules blindly. We are not robots.
>
> On Fri, Sep 28, 2018 at 10:19 AM Dmitriy Pavlov 
> wrote:
>
> > Hi Vladimir,
> >
> > https://issues.apache.org/jira/browse/IGNITE-9320 is named configuration
> > finalization.
> >
> > Why finalization was considered as done without tests passing?
> >
> > Why can't ve revert finalization change, re-do finalization with passing
> > tests and merge changes?
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > пт, 28 сент. 2018 г. в 8:16, Vladimir Ozerov :
> >
> > > Test is going to be fixed in the scope of AI 2.7 [1]. This is not
> > > one-minute fix as there are multiple places where configuration should
> be
> > > passed, and changes should be covered with tests. I muted the test for
> > now.
> > >
> > > [1] https://issues.apache.org/jira/browse/IGNITE-9390
> > >
> > > On Fri, Sep 28, 2018 at 2:40 AM Dmitriy Setrakyan <
> dsetrak...@apache.org
> > >
> > > wrote:
> > >
> > > > Let's not revert any commits yet. Can we find out who did the commit
> > and
> > > > why he/she is not fixing the test?
> > > >
> > > > D.
> > > >
> > > > On Thu, Sep 27, 2018 at 4:21 PM Vyacheslav Daradur <
> > daradu...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > Are you talking about
> > > > > 'IgniteConfigurationParityTest#TestIgniteConfiguration'?
> > > > >
> > > > > Seems it's not hard to fix this test, it's necessary just to
> > implement
> > > > > missing members (at least as stubs) on .NET side in
> > > > > IgniteConfiguration class.
> > > > >
> > > > > Is there a Jira issue?
> > > > >
> > > > > On Fri, Sep 28, 2018 at 2:12 AM Dmitriy Pavlov <
> > dpavlov@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I'm grateful for contributions made in that area, but it seems
> > folks
> > > > > don't
> > > > > > have time to fix the test.
> > > > > >
> > > > > >
> > > > > > Tomorrow I'm going to revert commit.
> > > > > >
> > > > > > It seems it is the only way we can keep master more or less
> green.
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://ci.ignite.apache.org/viewLog.html?buildId=1888723&tab=buildChangesDiv&buildTypeId=IgniteTests24Java8_PlatformNet
> > > > > >
> > > > > >
> > > > > > Sincerely
> > > > > > Dmitry Pavlov
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best Regards, Vyacheslav D.
> > > > >
> > > >
> > >
> >
>

Re: Apache Ignite 2.7 release

[Vladimir Ozerov]

Dmitry,

Community agreement was to perform the release in October. Of course we can
wait a bit for services. Then we wait a bit for other cool features ready
by that time, then again and again, and release will never happen. And
while we are waiting for new features to come, already completerd features
cannot be used by anyone.

This is why we have an agreement that if feature is not ready, it should be
moved to future release, instead of shifting release. The sole reason to
have strict dates when decisions are made is to let release happen.



On Fri, Sep 28, 2018 at 2:22 AM Dmitriy Pavlov 
wrote:

> Vladimir,  I'm not searching for enemy, and not fighting with you. I'm not
> happy about cases when we are hurrying.
>
> We can't fix test, fill ticket details, can't wait for contributions to
> finish their tasks.  It is not best idea to use experience from commercial
> companies in open source. Are there any pressure outside community? Did
> someone promised rest of features to be released at 30 September?
>
> Let's remember principle do-orcracy, power of those who do. If contribor
> does change and reviewer does review, let's give right of making decision
> to them, but not to some closed club of people who privately discuss
> something.
>
> Sincerely
> Dmitriy Pavlov
>
> чт, 27 сент. 2018 г., 23:42 Vyacheslav Daradur :
>
> > Hi Igniters!
> >
> > As I have written about Service Grid before [1] I'm finalizing the
> > solution to be sure that implementation is reliable.
> >
> > About including it in 2.7, if we talk that code freeze tomorrow then
> > the solution is not ready to merge yet.
> > I hope that prereviewers Anton Vinogradov and Nikolay Izhikov will be
> > able to answer if solution out of scope or not in a couple of days.
> >
> > [1]
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-2-7-release-td34076.html#a34485
> > On Thu, Sep 27, 2018 at 11:14 PM Dmitriy Pavlov 
> > wrote:
> > >
> > > Yes, I agree, NPE during WAL flush is definitely a blocker.
> > >
> > > It is strange why the current test set did not fail after commit.
> > >
> > > чт, 27 сент. 2018 г. в 21:45, Andrey Kuznetsov :
> > >
> > > > Igniters,
> > > >
> > > > I've bumped into a new bug in WAL manager recently, see [1]. It looks
> > > > critical enough, and can be a good candidate for fixing before 2.7
> > release.
> > > >
> > > > Do you agree?
> > > >
> > > > [1] https://issues.apache.org/jira/browse/IGNITE-9731
> > > >
> > > > чт, 27 сент. 2018 г. в 19:45, Dmitriy Pavlov  >:
> > > >
> > > > > I need Vhyacheslav's opinion to be absolutely sure what status is
> > now.
> > > > >
> > > > > We never committed to dates of release, as well. I don't quite
> > understand
> > > > > what can mean 'the community committed to doing/releasing
> something'.
> > > > >
> > > > > About SG, I also concerned why such a big feature has quite a few
> > > > > discussions on the list. But it is another story.
> > > > >
> > > > > чт, 27 сент. 2018 г. в 19:33, Vladimir Ozerov <
> voze...@gridgain.com
> > >:
> > > > >
> > > > > > Folks,
> > > > > >
> > > > > > Please stop looking for enemies everywhere. Just went through
> this
> > > > thread
> > > > > > and search for "service" word.
> > > > > >
> > > > > > On Thu, Sep 27, 2018 at 7:30 PM Denis Magda 
> > wrote:
> > > > > >
> > > > > >> >
> > > > > >> > Denis, as PMC Chair, could you please control, that Service
> Grid
> > > > > >> > inclusion/exclusion is discussed properly according to the
> > Apache
> > > > Way.
> > > > > >>
> > > > > >>
> > > > > >> It's fine when committers/contributors have private discussions
> > > > related
> > > > > to
> > > > > >> a feature they've been working on. Not everything should go
> > through
> > > > the
> > > > > >> dev
> > > > > >> list. Otherwise, it will be inundated.  However, agree, that
> > > > > architectural
> > > > > >> and release decisions need to be done publicly.
> > > > > >>
> > > > > >> Speaking about Service Grid, there was a discussion where I saw
> > that
> > > > it
> > > > > >> was
> > > > > >> questionable whether it gets added to the release or not.
> > > > > >>
> > > > > >> *Vladislav*, could you please shed some light on the current
> > status of
> > > > > the
> > > > > >> service grid?
> > > > > >>
> > > > > >> On Thu, Sep 27, 2018 at 9:12 AM Dmitriy Pavlov <
> > dpavlov@gmail.com
> > > > >
> > > > > >> wrote:
> > > > > >>
> > > > > >> > Ok, let's wait for feedback from SG Author(s)/Reviewer(s)
> > first. If
> > > > it
> > > > > >> is
> > > > > >> > not ready, ok. But I thought it is almost done.
> > > > > >> >
> > > > > >> > I apologize if I missed some discussion (it can happen), but
> > > > > >> > According to the statement "our current agreement"
> > > > > >> > I can suspect some members are making some sort of private
> > > > agreements,
> > > > > >> and
> > > > > >> > do not to discuss it on the list.
> > > > > >> >
> > > > > >> > Let's build consensus here first, and then name an agreement.
> > > > > >> >
> > > > 

Re: Apache Ignite 2.7 release

[Dmitriy Pavlov]

My point we can wait a bit for services because
1  we are open-minded and we don't have outside pressure to do release in
October
2  and services it is not some new feature, which suddenly appeared in
autumn, it is a well known and important feature.

So it is up to Vyacheslav, Anton and Nikolay to decide.

Decisions can be services are not ready/ready to merge only to master/ready
to merge to master and to 2.7.


пт, 28 сент. 2018 г. в 10:46, Vladimir Ozerov :

> Dmitry,
>
> Community agreement was to perform the release in October. Of course we can
> wait a bit for services. Then we wait a bit for other cool features ready
> by that time, then again and again, and release will never happen. And
> while we are waiting for new features to come, already completerd features
> cannot be used by anyone.
>
> This is why we have an agreement that if feature is not ready, it should be
> moved to future release, instead of shifting release. The sole reason to
> have strict dates when decisions are made is to let release happen.
>
>
>
> On Fri, Sep 28, 2018 at 2:22 AM Dmitriy Pavlov 
> wrote:
>
> > Vladimir,  I'm not searching for enemy, and not fighting with you. I'm
> not
> > happy about cases when we are hurrying.
> >
> > We can't fix test, fill ticket details, can't wait for contributions to
> > finish their tasks.  It is not best idea to use experience from
> commercial
> > companies in open source. Are there any pressure outside community? Did
> > someone promised rest of features to be released at 30 September?
> >
> > Let's remember principle do-orcracy, power of those who do. If contribor
> > does change and reviewer does review, let's give right of making decision
> > to them, but not to some closed club of people who privately discuss
> > something.
> >
> > Sincerely
> > Dmitriy Pavlov
> >
> > чт, 27 сент. 2018 г., 23:42 Vyacheslav Daradur :
> >
> > > Hi Igniters!
> > >
> > > As I have written about Service Grid before [1] I'm finalizing the
> > > solution to be sure that implementation is reliable.
> > >
> > > About including it in 2.7, if we talk that code freeze tomorrow then
> > > the solution is not ready to merge yet.
> > > I hope that prereviewers Anton Vinogradov and Nikolay Izhikov will be
> > > able to answer if solution out of scope or not in a couple of days.
> > >
> > > [1]
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-2-7-release-td34076.html#a34485
> > > On Thu, Sep 27, 2018 at 11:14 PM Dmitriy Pavlov  >
> > > wrote:
> > > >
> > > > Yes, I agree, NPE during WAL flush is definitely a blocker.
> > > >
> > > > It is strange why the current test set did not fail after commit.
> > > >
> > > > чт, 27 сент. 2018 г. в 21:45, Andrey Kuznetsov :
> > > >
> > > > > Igniters,
> > > > >
> > > > > I've bumped into a new bug in WAL manager recently, see [1]. It
> looks
> > > > > critical enough, and can be a good candidate for fixing before 2.7
> > > release.
> > > > >
> > > > > Do you agree?
> > > > >
> > > > > [1] https://issues.apache.org/jira/browse/IGNITE-9731
> > > > >
> > > > > чт, 27 сент. 2018 г. в 19:45, Dmitriy Pavlov <
> dpavlov@gmail.com
> > >:
> > > > >
> > > > > > I need Vhyacheslav's opinion to be absolutely sure what status is
> > > now.
> > > > > >
> > > > > > We never committed to dates of release, as well. I don't quite
> > > understand
> > > > > > what can mean 'the community committed to doing/releasing
> > something'.
> > > > > >
> > > > > > About SG, I also concerned why such a big feature has quite a few
> > > > > > discussions on the list. But it is another story.
> > > > > >
> > > > > > чт, 27 сент. 2018 г. в 19:33, Vladimir Ozerov <
> > voze...@gridgain.com
> > > >:
> > > > > >
> > > > > > > Folks,
> > > > > > >
> > > > > > > Please stop looking for enemies everywhere. Just went through
> > this
> > > > > thread
> > > > > > > and search for "service" word.
> > > > > > >
> > > > > > > On Thu, Sep 27, 2018 at 7:30 PM Denis Magda  >
> > > wrote:
> > > > > > >
> > > > > > >> >
> > > > > > >> > Denis, as PMC Chair, could you please control, that Service
> > Grid
> > > > > > >> > inclusion/exclusion is discussed properly according to the
> > > Apache
> > > > > Way.
> > > > > > >>
> > > > > > >>
> > > > > > >> It's fine when committers/contributors have private
> discussions
> > > > > related
> > > > > > to
> > > > > > >> a feature they've been working on. Not everything should go
> > > through
> > > > > the
> > > > > > >> dev
> > > > > > >> list. Otherwise, it will be inundated.  However, agree, that
> > > > > > architectural
> > > > > > >> and release decisions need to be done publicly.
> > > > > > >>
> > > > > > >> Speaking about Service Grid, there was a discussion where I
> saw
> > > that
> > > > > it
> > > > > > >> was
> > > > > > >> questionable whether it gets added to the release or not.
> > > > > > >>
> > > > > > >> *Vladislav*, could you please shed some light on the current
> > > status of
> > > > > > the
> > > > > > >> service grid?
>

Re: Apache Ignite 2.7 release

[Vladimir Ozerov]

Dmitriy,

Did I read your words correctly that it is up to implementor of a single
feature to decide whether release of all other features and fixes to be
delayed?

пт, 28 сент. 2018 г. в 11:00, Dmitriy Pavlov :

> My point we can wait a bit for services because
> 1  we are open-minded and we don't have outside pressure to do release in
> October
> 2  and services it is not some new feature, which suddenly appeared in
> autumn, it is a well known and important feature.
>
> So it is up to Vyacheslav, Anton and Nikolay to decide.
>
> Decisions can be services are not ready/ready to merge only to master/ready
> to merge to master and to 2.7.
>
>
> пт, 28 сент. 2018 г. в 10:46, Vladimir Ozerov :
>
> > Dmitry,
> >
> > Community agreement was to perform the release in October. Of course we
> can
> > wait a bit for services. Then we wait a bit for other cool features ready
> > by that time, then again and again, and release will never happen. And
> > while we are waiting for new features to come, already completerd
> features
> > cannot be used by anyone.
> >
> > This is why we have an agreement that if feature is not ready, it should
> be
> > moved to future release, instead of shifting release. The sole reason to
> > have strict dates when decisions are made is to let release happen.
> >
> >
> >
> > On Fri, Sep 28, 2018 at 2:22 AM Dmitriy Pavlov 
> > wrote:
> >
> > > Vladimir,  I'm not searching for enemy, and not fighting with you. I'm
> > not
> > > happy about cases when we are hurrying.
> > >
> > > We can't fix test, fill ticket details, can't wait for contributions to
> > > finish their tasks.  It is not best idea to use experience from
> > commercial
> > > companies in open source. Are there any pressure outside community? Did
> > > someone promised rest of features to be released at 30 September?
> > >
> > > Let's remember principle do-orcracy, power of those who do. If
> contribor
> > > does change and reviewer does review, let's give right of making
> decision
> > > to them, but not to some closed club of people who privately discuss
> > > something.
> > >
> > > Sincerely
> > > Dmitriy Pavlov
> > >
> > > чт, 27 сент. 2018 г., 23:42 Vyacheslav Daradur :
> > >
> > > > Hi Igniters!
> > > >
> > > > As I have written about Service Grid before [1] I'm finalizing the
> > > > solution to be sure that implementation is reliable.
> > > >
> > > > About including it in 2.7, if we talk that code freeze tomorrow then
> > > > the solution is not ready to merge yet.
> > > > I hope that prereviewers Anton Vinogradov and Nikolay Izhikov will be
> > > > able to answer if solution out of scope or not in a couple of days.
> > > >
> > > > [1]
> > > >
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-2-7-release-td34076.html#a34485
> > > > On Thu, Sep 27, 2018 at 11:14 PM Dmitriy Pavlov <
> dpavlov@gmail.com
> > >
> > > > wrote:
> > > > >
> > > > > Yes, I agree, NPE during WAL flush is definitely a blocker.
> > > > >
> > > > > It is strange why the current test set did not fail after commit.
> > > > >
> > > > > чт, 27 сент. 2018 г. в 21:45, Andrey Kuznetsov  >:
> > > > >
> > > > > > Igniters,
> > > > > >
> > > > > > I've bumped into a new bug in WAL manager recently, see [1]. It
> > looks
> > > > > > critical enough, and can be a good candidate for fixing before
> 2.7
> > > > release.
> > > > > >
> > > > > > Do you agree?
> > > > > >
> > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-9731
> > > > > >
> > > > > > чт, 27 сент. 2018 г. в 19:45, Dmitriy Pavlov <
> > dpavlov@gmail.com
> > > >:
> > > > > >
> > > > > > > I need Vhyacheslav's opinion to be absolutely sure what status
> is
> > > > now.
> > > > > > >
> > > > > > > We never committed to dates of release, as well. I don't quite
> > > > understand
> > > > > > > what can mean 'the community committed to doing/releasing
> > > something'.
> > > > > > >
> > > > > > > About SG, I also concerned why such a big feature has quite a
> few
> > > > > > > discussions on the list. But it is another story.
> > > > > > >
> > > > > > > чт, 27 сент. 2018 г. в 19:33, Vladimir Ozerov <
> > > voze...@gridgain.com
> > > > >:
> > > > > > >
> > > > > > > > Folks,
> > > > > > > >
> > > > > > > > Please stop looking for enemies everywhere. Just went through
> > > this
> > > > > > thread
> > > > > > > > and search for "service" word.
> > > > > > > >
> > > > > > > > On Thu, Sep 27, 2018 at 7:30 PM Denis Magda <
> dma...@apache.org
> > >
> > > > wrote:
> > > > > > > >
> > > > > > > >> >
> > > > > > > >> > Denis, as PMC Chair, could you please control, that
> Service
> > > Grid
> > > > > > > >> > inclusion/exclusion is discussed properly according to the
> > > > Apache
> > > > > > Way.
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> It's fine when committers/contributors have private
> > discussions
> > > > > > related
> > > > > > > to
> > > > > > > >> a feature they've been working on. Not everything should go
> > > > through
> > > > > > the
> > > >

Re: Apache Ignite 2.7 release

[Dmitriy Pavlov]

No, it is up to the community to discuss after their review results.

пт, 28 сент. 2018 г. в 11:09, Vladimir Ozerov :

> Dmitriy,
>
> Did I read your words correctly that it is up to implementor of a single
> feature to decide whether release of all other features and fixes to be
> delayed?
>
> пт, 28 сент. 2018 г. в 11:00, Dmitriy Pavlov :
>
> > My point we can wait a bit for services because
> > 1  we are open-minded and we don't have outside pressure to do release in
> > October
> > 2  and services it is not some new feature, which suddenly appeared in
> > autumn, it is a well known and important feature.
> >
> > So it is up to Vyacheslav, Anton and Nikolay to decide.
> >
> > Decisions can be services are not ready/ready to merge only to
> master/ready
> > to merge to master and to 2.7.
> >
> >
> > пт, 28 сент. 2018 г. в 10:46, Vladimir Ozerov :
> >
> > > Dmitry,
> > >
> > > Community agreement was to perform the release in October. Of course we
> > can
> > > wait a bit for services. Then we wait a bit for other cool features
> ready
> > > by that time, then again and again, and release will never happen. And
> > > while we are waiting for new features to come, already completerd
> > features
> > > cannot be used by anyone.
> > >
> > > This is why we have an agreement that if feature is not ready, it
> should
> > be
> > > moved to future release, instead of shifting release. The sole reason
> to
> > > have strict dates when decisions are made is to let release happen.
> > >
> > >
> > >
> > > On Fri, Sep 28, 2018 at 2:22 AM Dmitriy Pavlov 
> > > wrote:
> > >
> > > > Vladimir,  I'm not searching for enemy, and not fighting with you.
> I'm
> > > not
> > > > happy about cases when we are hurrying.
> > > >
> > > > We can't fix test, fill ticket details, can't wait for contributions
> to
> > > > finish their tasks.  It is not best idea to use experience from
> > > commercial
> > > > companies in open source. Are there any pressure outside community?
> Did
> > > > someone promised rest of features to be released at 30 September?
> > > >
> > > > Let's remember principle do-orcracy, power of those who do. If
> > contribor
> > > > does change and reviewer does review, let's give right of making
> > decision
> > > > to them, but not to some closed club of people who privately discuss
> > > > something.
> > > >
> > > > Sincerely
> > > > Dmitriy Pavlov
> > > >
> > > > чт, 27 сент. 2018 г., 23:42 Vyacheslav Daradur  >:
> > > >
> > > > > Hi Igniters!
> > > > >
> > > > > As I have written about Service Grid before [1] I'm finalizing the
> > > > > solution to be sure that implementation is reliable.
> > > > >
> > > > > About including it in 2.7, if we talk that code freeze tomorrow
> then
> > > > > the solution is not ready to merge yet.
> > > > > I hope that prereviewers Anton Vinogradov and Nikolay Izhikov will
> be
> > > > > able to answer if solution out of scope or not in a couple of days.
> > > > >
> > > > > [1]
> > > > >
> > > >
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-2-7-release-td34076.html#a34485
> > > > > On Thu, Sep 27, 2018 at 11:14 PM Dmitriy Pavlov <
> > dpavlov@gmail.com
> > > >
> > > > > wrote:
> > > > > >
> > > > > > Yes, I agree, NPE during WAL flush is definitely a blocker.
> > > > > >
> > > > > > It is strange why the current test set did not fail after commit.
> > > > > >
> > > > > > чт, 27 сент. 2018 г. в 21:45, Andrey Kuznetsov <
> stku...@gmail.com
> > >:
> > > > > >
> > > > > > > Igniters,
> > > > > > >
> > > > > > > I've bumped into a new bug in WAL manager recently, see [1]. It
> > > looks
> > > > > > > critical enough, and can be a good candidate for fixing before
> > 2.7
> > > > > release.
> > > > > > >
> > > > > > > Do you agree?
> > > > > > >
> > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-9731
> > > > > > >
> > > > > > > чт, 27 сент. 2018 г. в 19:45, Dmitriy Pavlov <
> > > dpavlov@gmail.com
> > > > >:
> > > > > > >
> > > > > > > > I need Vhyacheslav's opinion to be absolutely sure what
> status
> > is
> > > > > now.
> > > > > > > >
> > > > > > > > We never committed to dates of release, as well. I don't
> quite
> > > > > understand
> > > > > > > > what can mean 'the community committed to doing/releasing
> > > > something'.
> > > > > > > >
> > > > > > > > About SG, I also concerned why such a big feature has quite a
> > few
> > > > > > > > discussions on the list. But it is another story.
> > > > > > > >
> > > > > > > > чт, 27 сент. 2018 г. в 19:33, Vladimir Ozerov <
> > > > voze...@gridgain.com
> > > > > >:
> > > > > > > >
> > > > > > > > > Folks,
> > > > > > > > >
> > > > > > > > > Please stop looking for enemies everywhere. Just went
> through
> > > > this
> > > > > > > thread
> > > > > > > > > and search for "service" word.
> > > > > > > > >
> > > > > > > > > On Thu, Sep 27, 2018 at 7:30 PM Denis Magda <
> > dma...@apache.org
> > > >
> > > > > wrote:
> > > > > > > > >
> > > > > > > > >> >
> > > > > > > > >> > Denis, as PM

Re: Apache Ignite 2.7 release

[Maxim Muzafarov]

Andrey, Dmitry,

> I've bumped into a new bug in WAL manager recently, see [1]. It looks
critical enough and can be a good candidate for fixing before 2.7 release.

I've found that commit [2] is also lead the exchange worker to hang in my
branch related to IGNITE-7196.
Not sure, I'm able to fix the whole [1] issue, but I will take a look at it.

[1] https://issues.apache.org/jira/browse/IGNITE-9731
[2]
https://github.com/apache/ignite/commit/2f72fe758d4256c4eb4610e5922ad3d174b43dc5



On Fri, 28 Sep 2018 at 11:11 Dmitriy Pavlov  wrote:

> No, it is up to the community to discuss after their review results.
>
> пт, 28 сент. 2018 г. в 11:09, Vladimir Ozerov :
>
> > Dmitriy,
> >
> > Did I read your words correctly that it is up to implementor of a single
> > feature to decide whether release of all other features and fixes to be
> > delayed?
> >
> > пт, 28 сент. 2018 г. в 11:00, Dmitriy Pavlov :
> >
> > > My point we can wait a bit for services because
> > > 1  we are open-minded and we don't have outside pressure to do release
> in
> > > October
> > > 2  and services it is not some new feature, which suddenly appeared in
> > > autumn, it is a well known and important feature.
> > >
> > > So it is up to Vyacheslav, Anton and Nikolay to decide.
> > >
> > > Decisions can be services are not ready/ready to merge only to
> > master/ready
> > > to merge to master and to 2.7.
> > >
> > >
> > > пт, 28 сент. 2018 г. в 10:46, Vladimir Ozerov :
> > >
> > > > Dmitry,
> > > >
> > > > Community agreement was to perform the release in October. Of course
> we
> > > can
> > > > wait a bit for services. Then we wait a bit for other cool features
> > ready
> > > > by that time, then again and again, and release will never happen.
> And
> > > > while we are waiting for new features to come, already completerd
> > > features
> > > > cannot be used by anyone.
> > > >
> > > > This is why we have an agreement that if feature is not ready, it
> > should
> > > be
> > > > moved to future release, instead of shifting release. The sole reason
> > to
> > > > have strict dates when decisions are made is to let release happen.
> > > >
> > > >
> > > >
> > > > On Fri, Sep 28, 2018 at 2:22 AM Dmitriy Pavlov <
> dpavlov@gmail.com>
> > > > wrote:
> > > >
> > > > > Vladimir,  I'm not searching for enemy, and not fighting with you.
> > I'm
> > > > not
> > > > > happy about cases when we are hurrying.
> > > > >
> > > > > We can't fix test, fill ticket details, can't wait for
> contributions
> > to
> > > > > finish their tasks.  It is not best idea to use experience from
> > > > commercial
> > > > > companies in open source. Are there any pressure outside community?
> > Did
> > > > > someone promised rest of features to be released at 30 September?
> > > > >
> > > > > Let's remember principle do-orcracy, power of those who do. If
> > > contribor
> > > > > does change and reviewer does review, let's give right of making
> > > decision
> > > > > to them, but not to some closed club of people who privately
> discuss
> > > > > something.
> > > > >
> > > > > Sincerely
> > > > > Dmitriy Pavlov
> > > > >
> > > > > чт, 27 сент. 2018 г., 23:42 Vyacheslav Daradur <
> daradu...@gmail.com
> > >:
> > > > >
> > > > > > Hi Igniters!
> > > > > >
> > > > > > As I have written about Service Grid before [1] I'm finalizing
> the
> > > > > > solution to be sure that implementation is reliable.
> > > > > >
> > > > > > About including it in 2.7, if we talk that code freeze tomorrow
> > then
> > > > > > the solution is not ready to merge yet.
> > > > > > I hope that prereviewers Anton Vinogradov and Nikolay Izhikov
> will
> > be
> > > > > > able to answer if solution out of scope or not in a couple of
> days.
> > > > > >
> > > > > > [1]
> > > > > >
> > > > >
> > > >
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-2-7-release-td34076.html#a34485
> > > > > > On Thu, Sep 27, 2018 at 11:14 PM Dmitriy Pavlov <
> > > dpavlov@gmail.com
> > > > >
> > > > > > wrote:
> > > > > > >
> > > > > > > Yes, I agree, NPE during WAL flush is definitely a blocker.
> > > > > > >
> > > > > > > It is strange why the current test set did not fail after
> commit.
> > > > > > >
> > > > > > > чт, 27 сент. 2018 г. в 21:45, Andrey Kuznetsov <
> > stku...@gmail.com
> > > >:
> > > > > > >
> > > > > > > > Igniters,
> > > > > > > >
> > > > > > > > I've bumped into a new bug in WAL manager recently, see [1].
> It
> > > > looks
> > > > > > > > critical enough, and can be a good candidate for fixing
> before
> > > 2.7
> > > > > > release.
> > > > > > > >
> > > > > > > > Do you agree?
> > > > > > > >
> > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-9731
> > > > > > > >
> > > > > > > > чт, 27 сент. 2018 г. в 19:45, Dmitriy Pavlov <
> > > > dpavlov@gmail.com
> > > > > >:
> > > > > > > >
> > > > > > > > > I need Vhyacheslav's opinion to be absolutely sure what
> > status
> > > is
> > > > > > now.
> > > > > > > > >
> > > > > > > > > We never committed to

Re: Apache Ignite 2.7 release

[Vladimir Ozerov]

Exactly. So correct statement is “it is up to *community* to decide whether
something goes to 2.7”.

пт, 28 сент. 2018 г. в 11:11, Dmitriy Pavlov :

> No, it is up to the community to discuss after their review results.
>
> пт, 28 сент. 2018 г. в 11:09, Vladimir Ozerov :
>
> > Dmitriy,
> >
> > Did I read your words correctly that it is up to implementor of a single
> > feature to decide whether release of all other features and fixes to be
> > delayed?
> >
> > пт, 28 сент. 2018 г. в 11:00, Dmitriy Pavlov :
> >
> > > My point we can wait a bit for services because
> > > 1  we are open-minded and we don't have outside pressure to do release
> in
> > > October
> > > 2  and services it is not some new feature, which suddenly appeared in
> > > autumn, it is a well known and important feature.
> > >
> > > So it is up to Vyacheslav, Anton and Nikolay to decide.
> > >
> > > Decisions can be services are not ready/ready to merge only to
> > master/ready
> > > to merge to master and to 2.7.
> > >
> > >
> > > пт, 28 сент. 2018 г. в 10:46, Vladimir Ozerov :
> > >
> > > > Dmitry,
> > > >
> > > > Community agreement was to perform the release in October. Of course
> we
> > > can
> > > > wait a bit for services. Then we wait a bit for other cool features
> > ready
> > > > by that time, then again and again, and release will never happen.
> And
> > > > while we are waiting for new features to come, already completerd
> > > features
> > > > cannot be used by anyone.
> > > >
> > > > This is why we have an agreement that if feature is not ready, it
> > should
> > > be
> > > > moved to future release, instead of shifting release. The sole reason
> > to
> > > > have strict dates when decisions are made is to let release happen.
> > > >
> > > >
> > > >
> > > > On Fri, Sep 28, 2018 at 2:22 AM Dmitriy Pavlov <
> dpavlov@gmail.com>
> > > > wrote:
> > > >
> > > > > Vladimir,  I'm not searching for enemy, and not fighting with you.
> > I'm
> > > > not
> > > > > happy about cases when we are hurrying.
> > > > >
> > > > > We can't fix test, fill ticket details, can't wait for
> contributions
> > to
> > > > > finish their tasks.  It is not best idea to use experience from
> > > > commercial
> > > > > companies in open source. Are there any pressure outside community?
> > Did
> > > > > someone promised rest of features to be released at 30 September?
> > > > >
> > > > > Let's remember principle do-orcracy, power of those who do. If
> > > contribor
> > > > > does change and reviewer does review, let's give right of making
> > > decision
> > > > > to them, but not to some closed club of people who privately
> discuss
> > > > > something.
> > > > >
> > > > > Sincerely
> > > > > Dmitriy Pavlov
> > > > >
> > > > > чт, 27 сент. 2018 г., 23:42 Vyacheslav Daradur <
> daradu...@gmail.com
> > >:
> > > > >
> > > > > > Hi Igniters!
> > > > > >
> > > > > > As I have written about Service Grid before [1] I'm finalizing
> the
> > > > > > solution to be sure that implementation is reliable.
> > > > > >
> > > > > > About including it in 2.7, if we talk that code freeze tomorrow
> > then
> > > > > > the solution is not ready to merge yet.
> > > > > > I hope that prereviewers Anton Vinogradov and Nikolay Izhikov
> will
> > be
> > > > > > able to answer if solution out of scope or not in a couple of
> days.
> > > > > >
> > > > > > [1]
> > > > > >
> > > > >
> > > >
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-2-7-release-td34076.html#a34485
> > > > > > On Thu, Sep 27, 2018 at 11:14 PM Dmitriy Pavlov <
> > > dpavlov@gmail.com
> > > > >
> > > > > > wrote:
> > > > > > >
> > > > > > > Yes, I agree, NPE during WAL flush is definitely a blocker.
> > > > > > >
> > > > > > > It is strange why the current test set did not fail after
> commit.
> > > > > > >
> > > > > > > чт, 27 сент. 2018 г. в 21:45, Andrey Kuznetsov <
> > stku...@gmail.com
> > > >:
> > > > > > >
> > > > > > > > Igniters,
> > > > > > > >
> > > > > > > > I've bumped into a new bug in WAL manager recently, see [1].
> It
> > > > looks
> > > > > > > > critical enough, and can be a good candidate for fixing
> before
> > > 2.7
> > > > > > release.
> > > > > > > >
> > > > > > > > Do you agree?
> > > > > > > >
> > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-9731
> > > > > > > >
> > > > > > > > чт, 27 сент. 2018 г. в 19:45, Dmitriy Pavlov <
> > > > dpavlov@gmail.com
> > > > > >:
> > > > > > > >
> > > > > > > > > I need Vhyacheslav's opinion to be absolutely sure what
> > status
> > > is
> > > > > > now.
> > > > > > > > >
> > > > > > > > > We never committed to dates of release, as well. I don't
> > quite
> > > > > > understand
> > > > > > > > > what can mean 'the community committed to doing/releasing
> > > > > something'.
> > > > > > > > >
> > > > > > > > > About SG, I also concerned why such a big feature has
> quite a
> > > few
> > > > > > > > > discussions on the list. But it is another story.
> > > > > > > > >
> > > > > > > > > чт, 27 сент. 

Re: Apache Ignite 2.7 release

[Dmitriy Pavlov]

Hi Maxim,

Once 1) you are sure that commit is related to the failure, and 2) in case
contributors are not responding,
please let me know, probably we need to open one more separate topic about
revert.

Sincerely,
Dmitriy Pavlov

пт, 28 сент. 2018 г. в 11:15, Maxim Muzafarov :

> Andrey, Dmitry,
>
> > I've bumped into a new bug in WAL manager recently, see [1]. It looks
> critical enough and can be a good candidate for fixing before 2.7 release.
>
> I've found that commit [2] is also lead the exchange worker to hang in my
> branch related to IGNITE-7196.
> Not sure, I'm able to fix the whole [1] issue, but I will take a look at
> it.
>
> [1] https://issues.apache.org/jira/browse/IGNITE-9731
> [2]
>
> https://github.com/apache/ignite/commit/2f72fe758d4256c4eb4610e5922ad3d174b43dc5
>
>
>
> On Fri, 28 Sep 2018 at 11:11 Dmitriy Pavlov  wrote:
>
> > No, it is up to the community to discuss after their review results.
> >
> > пт, 28 сент. 2018 г. в 11:09, Vladimir Ozerov :
> >
> > > Dmitriy,
> > >
> > > Did I read your words correctly that it is up to implementor of a
> single
> > > feature to decide whether release of all other features and fixes to be
> > > delayed?
> > >
> > > пт, 28 сент. 2018 г. в 11:00, Dmitriy Pavlov :
> > >
> > > > My point we can wait a bit for services because
> > > > 1  we are open-minded and we don't have outside pressure to do
> release
> > in
> > > > October
> > > > 2  and services it is not some new feature, which suddenly appeared
> in
> > > > autumn, it is a well known and important feature.
> > > >
> > > > So it is up to Vyacheslav, Anton and Nikolay to decide.
> > > >
> > > > Decisions can be services are not ready/ready to merge only to
> > > master/ready
> > > > to merge to master and to 2.7.
> > > >
> > > >
> > > > пт, 28 сент. 2018 г. в 10:46, Vladimir Ozerov  >:
> > > >
> > > > > Dmitry,
> > > > >
> > > > > Community agreement was to perform the release in October. Of
> course
> > we
> > > > can
> > > > > wait a bit for services. Then we wait a bit for other cool features
> > > ready
> > > > > by that time, then again and again, and release will never happen.
> > And
> > > > > while we are waiting for new features to come, already completerd
> > > > features
> > > > > cannot be used by anyone.
> > > > >
> > > > > This is why we have an agreement that if feature is not ready, it
> > > should
> > > > be
> > > > > moved to future release, instead of shifting release. The sole
> reason
> > > to
> > > > > have strict dates when decisions are made is to let release happen.
> > > > >
> > > > >
> > > > >
> > > > > On Fri, Sep 28, 2018 at 2:22 AM Dmitriy Pavlov <
> > dpavlov@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Vladimir,  I'm not searching for enemy, and not fighting with
> you.
> > > I'm
> > > > > not
> > > > > > happy about cases when we are hurrying.
> > > > > >
> > > > > > We can't fix test, fill ticket details, can't wait for
> > contributions
> > > to
> > > > > > finish their tasks.  It is not best idea to use experience from
> > > > > commercial
> > > > > > companies in open source. Are there any pressure outside
> community?
> > > Did
> > > > > > someone promised rest of features to be released at 30 September?
> > > > > >
> > > > > > Let's remember principle do-orcracy, power of those who do. If
> > > > contribor
> > > > > > does change and reviewer does review, let's give right of making
> > > > decision
> > > > > > to them, but not to some closed club of people who privately
> > discuss
> > > > > > something.
> > > > > >
> > > > > > Sincerely
> > > > > > Dmitriy Pavlov
> > > > > >
> > > > > > чт, 27 сент. 2018 г., 23:42 Vyacheslav Daradur <
> > daradu...@gmail.com
> > > >:
> > > > > >
> > > > > > > Hi Igniters!
> > > > > > >
> > > > > > > As I have written about Service Grid before [1] I'm finalizing
> > the
> > > > > > > solution to be sure that implementation is reliable.
> > > > > > >
> > > > > > > About including it in 2.7, if we talk that code freeze tomorrow
> > > then
> > > > > > > the solution is not ready to merge yet.
> > > > > > > I hope that prereviewers Anton Vinogradov and Nikolay Izhikov
> > will
> > > be
> > > > > > > able to answer if solution out of scope or not in a couple of
> > days.
> > > > > > >
> > > > > > > [1]
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-2-7-release-td34076.html#a34485
> > > > > > > On Thu, Sep 27, 2018 at 11:14 PM Dmitriy Pavlov <
> > > > dpavlov@gmail.com
> > > > > >
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Yes, I agree, NPE during WAL flush is definitely a blocker.
> > > > > > > >
> > > > > > > > It is strange why the current test set did not fail after
> > commit.
> > > > > > > >
> > > > > > > > чт, 27 сент. 2018 г. в 21:45, Andrey Kuznetsov <
> > > stku...@gmail.com
> > > > >:
> > > > > > > >
> > > > > > > > > Igniters,
> > > > > > > > >
> > > > > > > > > I've bumped into a new bug in WAL manager recently, see
> 

Re: Apache Ignite 2.7 release

[Dmitriy Pavlov]

Yes, so correct statement is "community did not make any decisions about
services not go to 2.7/ services are out of scope".

If so, please forgive me my confusion.

пт, 28 сент. 2018 г. в 11:19, Vladimir Ozerov :

> Exactly. So correct statement is “it is up to *community* to decide whether
> something goes to 2.7”.
>
> пт, 28 сент. 2018 г. в 11:11, Dmitriy Pavlov :
>
> > No, it is up to the community to discuss after their review results.
> >
> > пт, 28 сент. 2018 г. в 11:09, Vladimir Ozerov :
> >
> > > Dmitriy,
> > >
> > > Did I read your words correctly that it is up to implementor of a
> single
> > > feature to decide whether release of all other features and fixes to be
> > > delayed?
> > >
> > > пт, 28 сент. 2018 г. в 11:00, Dmitriy Pavlov :
> > >
> > > > My point we can wait a bit for services because
> > > > 1  we are open-minded and we don't have outside pressure to do
> release
> > in
> > > > October
> > > > 2  and services it is not some new feature, which suddenly appeared
> in
> > > > autumn, it is a well known and important feature.
> > > >
> > > > So it is up to Vyacheslav, Anton and Nikolay to decide.
> > > >
> > > > Decisions can be services are not ready/ready to merge only to
> > > master/ready
> > > > to merge to master and to 2.7.
> > > >
> > > >
> > > > пт, 28 сент. 2018 г. в 10:46, Vladimir Ozerov  >:
> > > >
> > > > > Dmitry,
> > > > >
> > > > > Community agreement was to perform the release in October. Of
> course
> > we
> > > > can
> > > > > wait a bit for services. Then we wait a bit for other cool features
> > > ready
> > > > > by that time, then again and again, and release will never happen.
> > And
> > > > > while we are waiting for new features to come, already completerd
> > > > features
> > > > > cannot be used by anyone.
> > > > >
> > > > > This is why we have an agreement that if feature is not ready, it
> > > should
> > > > be
> > > > > moved to future release, instead of shifting release. The sole
> reason
> > > to
> > > > > have strict dates when decisions are made is to let release happen.
> > > > >
> > > > >
> > > > >
> > > > > On Fri, Sep 28, 2018 at 2:22 AM Dmitriy Pavlov <
> > dpavlov@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Vladimir,  I'm not searching for enemy, and not fighting with
> you.
> > > I'm
> > > > > not
> > > > > > happy about cases when we are hurrying.
> > > > > >
> > > > > > We can't fix test, fill ticket details, can't wait for
> > contributions
> > > to
> > > > > > finish their tasks.  It is not best idea to use experience from
> > > > > commercial
> > > > > > companies in open source. Are there any pressure outside
> community?
> > > Did
> > > > > > someone promised rest of features to be released at 30 September?
> > > > > >
> > > > > > Let's remember principle do-orcracy, power of those who do. If
> > > > contribor
> > > > > > does change and reviewer does review, let's give right of making
> > > > decision
> > > > > > to them, but not to some closed club of people who privately
> > discuss
> > > > > > something.
> > > > > >
> > > > > > Sincerely
> > > > > > Dmitriy Pavlov
> > > > > >
> > > > > > чт, 27 сент. 2018 г., 23:42 Vyacheslav Daradur <
> > daradu...@gmail.com
> > > >:
> > > > > >
> > > > > > > Hi Igniters!
> > > > > > >
> > > > > > > As I have written about Service Grid before [1] I'm finalizing
> > the
> > > > > > > solution to be sure that implementation is reliable.
> > > > > > >
> > > > > > > About including it in 2.7, if we talk that code freeze tomorrow
> > > then
> > > > > > > the solution is not ready to merge yet.
> > > > > > > I hope that prereviewers Anton Vinogradov and Nikolay Izhikov
> > will
> > > be
> > > > > > > able to answer if solution out of scope or not in a couple of
> > days.
> > > > > > >
> > > > > > > [1]
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-2-7-release-td34076.html#a34485
> > > > > > > On Thu, Sep 27, 2018 at 11:14 PM Dmitriy Pavlov <
> > > > dpavlov@gmail.com
> > > > > >
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Yes, I agree, NPE during WAL flush is definitely a blocker.
> > > > > > > >
> > > > > > > > It is strange why the current test set did not fail after
> > commit.
> > > > > > > >
> > > > > > > > чт, 27 сент. 2018 г. в 21:45, Andrey Kuznetsov <
> > > stku...@gmail.com
> > > > >:
> > > > > > > >
> > > > > > > > > Igniters,
> > > > > > > > >
> > > > > > > > > I've bumped into a new bug in WAL manager recently, see
> [1].
> > It
> > > > > looks
> > > > > > > > > critical enough, and can be a good candidate for fixing
> > before
> > > > 2.7
> > > > > > > release.
> > > > > > > > >
> > > > > > > > > Do you agree?
> > > > > > > > >
> > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-9731
> > > > > > > > >
> > > > > > > > > чт, 27 сент. 2018 г. в 19:45, Dmitriy Pavlov <
> > > > > dpavlov@gmail.com
> > > > > > >:
> > > > > > > > >
> > > > > > > > > > I need Vhyacheslav's opin

[jira] [Created] (IGNITE-9734) Fix flacky test GridIndexRebuildSelfTest.testIndexRebuild.

[Andrew Mashenkov (JIRA)]

Andrew Mashenkov created IGNITE-9734:


 Summary: Fix flacky test GridIndexRebuildSelfTest.testIndexRebuild.
 Key: IGNITE-9734
 URL: https://issues.apache.org/jira/browse/IGNITE-9734
 Project: Ignite
  Issue Type: Bug
Reporter: Andrew Mashenkov


Test fails sporadically on TC due to intensive disk usage. (Query1 and Queries 
(Binary) suites).

We should move this test to "PDS  with Indexing" suite.
Also, we have to check if GridIndexRebuildWithMvccEnabledSelfTest also runs on 
TC agents with SSD disks.

 



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

Re: Critical worker threads liveness checking drawbacks

[Nikolay Izhikov]

Hello, Igniters.

I found that this feature can't be disabled from config.
The only way to disable it is from JMX bean.

I think it very dangerous: If we have some corner case or a bug in this Watch 
Dog it can make Ignite unusable.
I propose to implement possibility to disable this feature both - from config 
and from JVM options.

What do you think?

В Чт, 27/09/2018 в 16:14 +0300, Andrey Kuznetsov пишет:
> Maxim,
> 
> Thanks for being attentive! It's definitely a typo. Could you please create
> an issue?
> 
> чт, 27 сент. 2018 г. в 16:00, Maxim Muzafarov :
> 
> > Folks,
> > 
> > I've found in `GridCachePartitionExchangeManager:2684` [1] (master branch)
> > exchange future wrapped
> > with double `blockingSectionEnd` method. Is it correct? I just want to
> > understand this change and
> > how should I use this in the future.
> > 
> > Should I file a new issue to fix this? I think here `blockingSectionBegin`
> > method should be used.
> > 
> > -
> > blockingSectionEnd();
> > 
> > try {
> > resVer = exchFut.get(exchTimeout, TimeUnit.MILLISECONDS);
> > } finally {
> > blockingSectionEnd();
> > }
> > 
> > 
> > [1]
> > 
> > https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCachePartitionExchangeManager.java#L2684
> > 
> > On Wed, 26 Sep 2018 at 22:47 Vyacheslav Daradur 
> > wrote:
> > 
> > > Andrey Gura, thank you for the answer!
> > > 
> > > I agree that wrapping of 'init' method reduces the profit of watchdog
> > > service in case of PME worker, but in other cases, we should wrap all
> > > possible long sections on GridDhtPartitionExchangeFuture. For example
> > > 'onCacheChangeRequest' method or
> > > 'cctx.affinity().onCacheChangeRequest' inside because it may take
> > > significant time (reproducer attached).
> > > 
> > > I only want to point out a possible issue which may allow to end-user
> > > halt the Ignite cluster accidentally.
> > > 
> > > I'm sure that PME experts know how to fix this issue properly.
> > > On Wed, Sep 26, 2018 at 10:28 PM Andrey Gura  wrote:
> > > > 
> > > > Vyacheslav,
> > > > 
> > > > Exchange worker is strongly tied with
> > > > GridDhtPartitionExchangeFuture#init and it is ok. Exchange worker also
> > > > shouldn't be blocked for long time but in reality it happens.It also
> > > > means that your change doesn't make sense.
> > > > 
> > > > What actually make sense it is identification of places which
> > > > intentionally blocking. May be some places/actions should be braced by
> > > > blocking guards.
> > > > 
> > > > If you have failing tests please make sure that your failureHandler is
> > > > NoOpFailureHandler or any other handler with ignoreFailureTypes =
> > > > [CRITICAL_WORKER_BLOCKED].
> > > > 
> > > > 
> > > > On Wed, Sep 26, 2018 at 9:43 PM Vyacheslav Daradur <
> > 
> > daradu...@gmail.com>
> > > wrote:
> > > > > 
> > > > > Hi Igniters!
> > > > > 
> > > > > Thank you for this important improvement!
> > > > > 
> > > > > I've looked through implementation and noticed that
> > > > > GridDhtPartitionsExchangeFuture#init has not been wrapped in blocked
> > > > > section. This means it easy to halt the node in case of longrunning
> > > > > actions during PME, for example when we create a cache with
> > > > > StoreFactrory which connect to 3rd party DB.
> > > > > 
> > > > > I'm not sure that it is the right behavior.
> > > > > 
> > > > > I filled the issue [1] and prepared the PR [2] with reproducer and
> > > 
> > > possible fix.
> > > > > 
> > > > > Andrey, could you please look at and confirm that it makes sense?
> > > > > 
> > > > > [1] https://issues.apache.org/jira/browse/IGNITE-9710
> > > > > [2] https://github.com/apache/ignite/pull/4845
> > > > > On Mon, Sep 24, 2018 at 9:46 PM Andrey Kuznetsov 
> > > 
> > > wrote:
> > > > > > 
> > > > > > Denis,
> > > > > > 
> > > > > > I've created the ticket [1] with short description of the
> > > 
> > > functionality.
> > > > > > 
> > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-9679
> > > > > > 
> > > > > > 
> > > > > > пн, 24 сент. 2018 г. в 17:46, Denis Magda :
> > > > > > 
> > > > > > > Andrey K. and G.,
> > > > > > > 
> > > > > > > Thanks, do we have a documentation ticket created? Prachi
> > 
> > (copied)
> > > can help
> > > > > > > with the documentation.
> > > > > > > 
> > > > > > > --
> > > > > > > Denis
> > > > > > > 
> > > > > > > On Mon, Sep 24, 2018 at 5:51 AM Andrey Gura 
> > > 
> > > wrote:
> > > > > > > 
> > > > > > > > Andrey,
> > > > > > > > 
> > > > > > > > finally your change is merged to master branch. Congratulations
> > > 
> > > and
> > > > > > > > thank you very much! :)
> > > > > > > > 
> > > > > > > > I think that the next step is feature that will allow signal
> > > 
> > > about
> > > > > > > > blocked threads to the monitoring tools via MXBean.
> > > > > > > > 
> > > > > > > > I hope you will continue development of this feature and
> > 
> > provide
> > > your
> > > > > > > > vision in new JIRA is

Re: Critical worker threads liveness checking drawbacks

[Alexey Goncharuk]

Nikolay, I agree, a user should be able to disable both thread liveness
check and checkpoint read lock timeout check from config and a system
property.

пт, 28 сент. 2018 г. в 11:30, Nikolay Izhikov :

> Hello, Igniters.
>
> I found that this feature can't be disabled from config.
> The only way to disable it is from JMX bean.
>
> I think it very dangerous: If we have some corner case or a bug in this
> Watch Dog it can make Ignite unusable.
> I propose to implement possibility to disable this feature both - from
> config and from JVM options.
>
> What do you think?
>
> В Чт, 27/09/2018 в 16:14 +0300, Andrey Kuznetsov пишет:
> > Maxim,
> >
> > Thanks for being attentive! It's definitely a typo. Could you please
> create
> > an issue?
> >
> > чт, 27 сент. 2018 г. в 16:00, Maxim Muzafarov :
> >
> > > Folks,
> > >
> > > I've found in `GridCachePartitionExchangeManager:2684` [1] (master
> branch)
> > > exchange future wrapped
> > > with double `blockingSectionEnd` method. Is it correct? I just want to
> > > understand this change and
> > > how should I use this in the future.
> > >
> > > Should I file a new issue to fix this? I think here
> `blockingSectionBegin`
> > > method should be used.
> > >
> > > -
> > > blockingSectionEnd();
> > >
> > > try {
> > > resVer = exchFut.get(exchTimeout, TimeUnit.MILLISECONDS);
> > > } finally {
> > > blockingSectionEnd();
> > > }
> > >
> > >
> > > [1]
> > >
> > >
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCachePartitionExchangeManager.java#L2684
> > >
> > > On Wed, 26 Sep 2018 at 22:47 Vyacheslav Daradur 
> > > wrote:
> > >
> > > > Andrey Gura, thank you for the answer!
> > > >
> > > > I agree that wrapping of 'init' method reduces the profit of watchdog
> > > > service in case of PME worker, but in other cases, we should wrap all
> > > > possible long sections on GridDhtPartitionExchangeFuture. For example
> > > > 'onCacheChangeRequest' method or
> > > > 'cctx.affinity().onCacheChangeRequest' inside because it may take
> > > > significant time (reproducer attached).
> > > >
> > > > I only want to point out a possible issue which may allow to end-user
> > > > halt the Ignite cluster accidentally.
> > > >
> > > > I'm sure that PME experts know how to fix this issue properly.
> > > > On Wed, Sep 26, 2018 at 10:28 PM Andrey Gura 
> wrote:
> > > > >
> > > > > Vyacheslav,
> > > > >
> > > > > Exchange worker is strongly tied with
> > > > > GridDhtPartitionExchangeFuture#init and it is ok. Exchange worker
> also
> > > > > shouldn't be blocked for long time but in reality it happens.It
> also
> > > > > means that your change doesn't make sense.
> > > > >
> > > > > What actually make sense it is identification of places which
> > > > > intentionally blocking. May be some places/actions should be
> braced by
> > > > > blocking guards.
> > > > >
> > > > > If you have failing tests please make sure that your
> failureHandler is
> > > > > NoOpFailureHandler or any other handler with ignoreFailureTypes =
> > > > > [CRITICAL_WORKER_BLOCKED].
> > > > >
> > > > >
> > > > > On Wed, Sep 26, 2018 at 9:43 PM Vyacheslav Daradur <
> > >
> > > daradu...@gmail.com>
> > > > wrote:
> > > > > >
> > > > > > Hi Igniters!
> > > > > >
> > > > > > Thank you for this important improvement!
> > > > > >
> > > > > > I've looked through implementation and noticed that
> > > > > > GridDhtPartitionsExchangeFuture#init has not been wrapped in
> blocked
> > > > > > section. This means it easy to halt the node in case of
> longrunning
> > > > > > actions during PME, for example when we create a cache with
> > > > > > StoreFactrory which connect to 3rd party DB.
> > > > > >
> > > > > > I'm not sure that it is the right behavior.
> > > > > >
> > > > > > I filled the issue [1] and prepared the PR [2] with reproducer
> and
> > > >
> > > > possible fix.
> > > > > >
> > > > > > Andrey, could you please look at and confirm that it makes sense?
> > > > > >
> > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-9710
> > > > > > [2] https://github.com/apache/ignite/pull/4845
> > > > > > On Mon, Sep 24, 2018 at 9:46 PM Andrey Kuznetsov <
> stku...@gmail.com>
> > > >
> > > > wrote:
> > > > > > >
> > > > > > > Denis,
> > > > > > >
> > > > > > > I've created the ticket [1] with short description of the
> > > >
> > > > functionality.
> > > > > > >
> > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-9679
> > > > > > >
> > > > > > >
> > > > > > > пн, 24 сент. 2018 г. в 17:46, Denis Magda :
> > > > > > >
> > > > > > > > Andrey K. and G.,
> > > > > > > >
> > > > > > > > Thanks, do we have a documentation ticket created? Prachi
> > >
> > > (copied)
> > > > can help
> > > > > > > > with the documentation.
> > > > > > > >
> > > > > > > > --
> > > > > > > > Denis
> > > > > > > >
> > > > > > > > On Mon, Sep 24, 2018 at 5:51 AM Andrey Gura <
> ag...@apache.org>
> > > >
> > > > wrote:
> > > > > > > >
> > > > > > > > > Andrey,
>

[GitHub] ignite pull request #4863: IGNITE-9731 hold segmentId on constructor of File...

[akalash]

GitHub user akalash opened a pull request:

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

IGNITE-9731 hold segmentId on constructor of FileHandle



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

$ git pull https://github.com/gridgain/apache-ignite ignite-9731

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

https://github.com/apache/ignite/pull/4863.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 #4863


commit e78214306c02a969ecc9bd250895b89f889abbb5
Author: Anton Kalashnikov 
Date:   2018-09-28T08:43:41Z

IGNITE-9731 hold segmentId on constructor of FileHandle




---

Re: Apache Ignite 2.7 release

[Alexey Goncharuk]

I think if a commit does not lead to any test failure in the current
master, there are no reasons to revert the commit. If there are valid
scenarios which are failing, corresponding tests should be added and the
root cause should be fixed under a separate issue.

пт, 28 сент. 2018 г. в 11:19, Dmitriy Pavlov :

> Hi Maxim,
>
> Once 1) you are sure that commit is related to the failure, and 2) in case
> contributors are not responding,
> please let me know, probably we need to open one more separate topic about
> revert.
>
> Sincerely,
> Dmitriy Pavlov
>
> пт, 28 сент. 2018 г. в 11:15, Maxim Muzafarov :
>
> > Andrey, Dmitry,
> >
> > > I've bumped into a new bug in WAL manager recently, see [1]. It looks
> > critical enough and can be a good candidate for fixing before 2.7
> release.
> >
> > I've found that commit [2] is also lead the exchange worker to hang in my
> > branch related to IGNITE-7196.
> > Not sure, I'm able to fix the whole [1] issue, but I will take a look at
> > it.
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-9731
> > [2]
> >
> >
> https://github.com/apache/ignite/commit/2f72fe758d4256c4eb4610e5922ad3d174b43dc5
> >
> >
> >
> > On Fri, 28 Sep 2018 at 11:11 Dmitriy Pavlov 
> wrote:
> >
> > > No, it is up to the community to discuss after their review results.
> > >
> > > пт, 28 сент. 2018 г. в 11:09, Vladimir Ozerov :
> > >
> > > > Dmitriy,
> > > >
> > > > Did I read your words correctly that it is up to implementor of a
> > single
> > > > feature to decide whether release of all other features and fixes to
> be
> > > > delayed?
> > > >
> > > > пт, 28 сент. 2018 г. в 11:00, Dmitriy Pavlov  >:
> > > >
> > > > > My point we can wait a bit for services because
> > > > > 1  we are open-minded and we don't have outside pressure to do
> > release
> > > in
> > > > > October
> > > > > 2  and services it is not some new feature, which suddenly appeared
> > in
> > > > > autumn, it is a well known and important feature.
> > > > >
> > > > > So it is up to Vyacheslav, Anton and Nikolay to decide.
> > > > >
> > > > > Decisions can be services are not ready/ready to merge only to
> > > > master/ready
> > > > > to merge to master and to 2.7.
> > > > >
> > > > >
> > > > > пт, 28 сент. 2018 г. в 10:46, Vladimir Ozerov <
> voze...@gridgain.com
> > >:
> > > > >
> > > > > > Dmitry,
> > > > > >
> > > > > > Community agreement was to perform the release in October. Of
> > course
> > > we
> > > > > can
> > > > > > wait a bit for services. Then we wait a bit for other cool
> features
> > > > ready
> > > > > > by that time, then again and again, and release will never
> happen.
> > > And
> > > > > > while we are waiting for new features to come, already completerd
> > > > > features
> > > > > > cannot be used by anyone.
> > > > > >
> > > > > > This is why we have an agreement that if feature is not ready, it
> > > > should
> > > > > be
> > > > > > moved to future release, instead of shifting release. The sole
> > reason
> > > > to
> > > > > > have strict dates when decisions are made is to let release
> happen.
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Fri, Sep 28, 2018 at 2:22 AM Dmitriy Pavlov <
> > > dpavlov@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Vladimir,  I'm not searching for enemy, and not fighting with
> > you.
> > > > I'm
> > > > > > not
> > > > > > > happy about cases when we are hurrying.
> > > > > > >
> > > > > > > We can't fix test, fill ticket details, can't wait for
> > > contributions
> > > > to
> > > > > > > finish their tasks.  It is not best idea to use experience from
> > > > > > commercial
> > > > > > > companies in open source. Are there any pressure outside
> > community?
> > > > Did
> > > > > > > someone promised rest of features to be released at 30
> September?
> > > > > > >
> > > > > > > Let's remember principle do-orcracy, power of those who do. If
> > > > > contribor
> > > > > > > does change and reviewer does review, let's give right of
> making
> > > > > decision
> > > > > > > to them, but not to some closed club of people who privately
> > > discuss
> > > > > > > something.
> > > > > > >
> > > > > > > Sincerely
> > > > > > > Dmitriy Pavlov
> > > > > > >
> > > > > > > чт, 27 сент. 2018 г., 23:42 Vyacheslav Daradur <
> > > daradu...@gmail.com
> > > > >:
> > > > > > >
> > > > > > > > Hi Igniters!
> > > > > > > >
> > > > > > > > As I have written about Service Grid before [1] I'm
> finalizing
> > > the
> > > > > > > > solution to be sure that implementation is reliable.
> > > > > > > >
> > > > > > > > About including it in 2.7, if we talk that code freeze
> tomorrow
> > > > then
> > > > > > > > the solution is not ready to merge yet.
> > > > > > > > I hope that prereviewers Anton Vinogradov and Nikolay Izhikov
> > > will
> > > > be
> > > > > > > > able to answer if solution out of scope or not in a couple of
> > > days.
> > > > > > > >
> > > > > > > > [1]
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://apache-ignite-deve

[GitHub] ignite pull request #4847: IGNITE-9706: Update ignite-tensorflow to support ...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] ignite pull request #4525: IGNITE-9253: Rename activation/deactivation comma...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] ignite pull request #4849: IGNITE-9711: [ML] Remove IgniteThread wrapper fro...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] ignite pull request #4864: IGNITE-9612 test fix

[ascherbakoff]

GitHub user ascherbakoff opened a pull request:

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

IGNITE-9612 test fix



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

$ git pull https://github.com/gridgain/apache-ignite ignite-9612

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

https://github.com/apache/ignite/pull/4864.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 #4864


commit 7e3c341ff4b99d3ca6f10283da539464d45a1c17
Author: ascherbakoff 
Date:   2018-09-23T16:34:09Z

IGNITE-9612 wip.

commit 5ab5553e989df5971472978d36515cfe1565627b
Author: Aleksei Scherbakov 
Date:   2018-09-24T10:49:59Z

IGNITE-9612 wip.

commit 5ad45b70e1fe6a921b49aec943bec874dcf64758
Author: Aleksei Scherbakov 
Date:   2018-09-25T10:30:18Z

IGNITE-9612 wip.

commit 53c99ba9bb02cd83ee9752224ca27a82312b731d
Author: Aleksei Scherbakov 
Date:   2018-09-25T10:33:15Z

IGNITE-9612 wip.

commit 795f296cfa7cd0783f03d76b1b7066b835a3d4c2
Author: Aleksei Scherbakov 
Date:   2018-09-25T10:33:34Z

Merge branch 'master' of https://github.com/apache/ignite into ignite-9612

commit 9a5b1519c333953fb24621742ff0ad6aa03a011a
Author: Aleksei Scherbakov 
Date:   2018-09-26T09:48:25Z

Merge branch 'master' of https://github.com/apache/ignite into ignite-9612

commit b105f7beb8643ad971d33352b8fd3fd90e6bb3f4
Author: Aleksei Scherbakov 
Date:   2018-09-26T17:20:48Z

IGNITE-9612 wip.

commit db622f6f709d758324f15b6aa582c40c3bbea13d
Author: ascherbakoff 
Date:   2018-09-27T19:28:57Z

Merge branch 'master' of https://github.com/apache/ignite into ignite-9612

commit 12c36d2771e870c08e6bfc2d3eef561f9ac6c8ca
Author: Aleksei Scherbakov 
Date:   2018-09-28T08:34:05Z

Merge branch 'master' of https://github.com/apache/ignite into ignite-9612

commit a2c6b48127f9d1a4660c43e05b9302c7c16dc2d1
Author: Aleksei Scherbakov 
Date:   2018-09-28T08:36:38Z

Merge branch 'ignite-9612' of https://github.com/gridgain/apache-ignite 
into ignite-9612

commit 0b2b24a58bcd0a9a6f35536852628ddde4bcb846
Author: Aleksei Scherbakov 
Date:   2018-09-28T09:04:57Z

IGNITE-9612 wip.




---

[GitHub] ignite pull request #4860: IGNITE-9501 Backward compatibility fix

[asfgit]

Github user asfgit closed the pull request at:

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


---

Re: Apache Ignite 2.7 release

[Dmitriy Setrakyan]

If services is not ready, which it is not, then we should include them into
the next release. There is no need to force them into 2.7. I suggest we
move according to the schedule we all agreed on.

D.

On Fri, Sep 28, 2018 at 1:22 AM Dmitriy Pavlov 
wrote:

> Yes, so correct statement is "community did not make any decisions about
> services not go to 2.7/ services are out of scope".
>
> If so, please forgive me my confusion.
>
> пт, 28 сент. 2018 г. в 11:19, Vladimir Ozerov :
>
> > Exactly. So correct statement is “it is up to *community* to decide
> whether
> > something goes to 2.7”.
> >
> > пт, 28 сент. 2018 г. в 11:11, Dmitriy Pavlov :
> >
> > > No, it is up to the community to discuss after their review results.
> > >
> > > пт, 28 сент. 2018 г. в 11:09, Vladimir Ozerov :
> > >
> > > > Dmitriy,
> > > >
> > > > Did I read your words correctly that it is up to implementor of a
> > single
> > > > feature to decide whether release of all other features and fixes to
> be
> > > > delayed?
> > > >
> > > > пт, 28 сент. 2018 г. в 11:00, Dmitriy Pavlov  >:
> > > >
> > > > > My point we can wait a bit for services because
> > > > > 1  we are open-minded and we don't have outside pressure to do
> > release
> > > in
> > > > > October
> > > > > 2  and services it is not some new feature, which suddenly appeared
> > in
> > > > > autumn, it is a well known and important feature.
> > > > >
> > > > > So it is up to Vyacheslav, Anton and Nikolay to decide.
> > > > >
> > > > > Decisions can be services are not ready/ready to merge only to
> > > > master/ready
> > > > > to merge to master and to 2.7.
> > > > >
> > > > >
> > > > > пт, 28 сент. 2018 г. в 10:46, Vladimir Ozerov <
> voze...@gridgain.com
> > >:
> > > > >
> > > > > > Dmitry,
> > > > > >
> > > > > > Community agreement was to perform the release in October. Of
> > course
> > > we
> > > > > can
> > > > > > wait a bit for services. Then we wait a bit for other cool
> features
> > > > ready
> > > > > > by that time, then again and again, and release will never
> happen.
> > > And
> > > > > > while we are waiting for new features to come, already completerd
> > > > > features
> > > > > > cannot be used by anyone.
> > > > > >
> > > > > > This is why we have an agreement that if feature is not ready, it
> > > > should
> > > > > be
> > > > > > moved to future release, instead of shifting release. The sole
> > reason
> > > > to
> > > > > > have strict dates when decisions are made is to let release
> happen.
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Fri, Sep 28, 2018 at 2:22 AM Dmitriy Pavlov <
> > > dpavlov@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Vladimir,  I'm not searching for enemy, and not fighting with
> > you.
> > > > I'm
> > > > > > not
> > > > > > > happy about cases when we are hurrying.
> > > > > > >
> > > > > > > We can't fix test, fill ticket details, can't wait for
> > > contributions
> > > > to
> > > > > > > finish their tasks.  It is not best idea to use experience from
> > > > > > commercial
> > > > > > > companies in open source. Are there any pressure outside
> > community?
> > > > Did
> > > > > > > someone promised rest of features to be released at 30
> September?
> > > > > > >
> > > > > > > Let's remember principle do-orcracy, power of those who do. If
> > > > > contribor
> > > > > > > does change and reviewer does review, let's give right of
> making
> > > > > decision
> > > > > > > to them, but not to some closed club of people who privately
> > > discuss
> > > > > > > something.
> > > > > > >
> > > > > > > Sincerely
> > > > > > > Dmitriy Pavlov
> > > > > > >
> > > > > > > чт, 27 сент. 2018 г., 23:42 Vyacheslav Daradur <
> > > daradu...@gmail.com
> > > > >:
> > > > > > >
> > > > > > > > Hi Igniters!
> > > > > > > >
> > > > > > > > As I have written about Service Grid before [1] I'm
> finalizing
> > > the
> > > > > > > > solution to be sure that implementation is reliable.
> > > > > > > >
> > > > > > > > About including it in 2.7, if we talk that code freeze
> tomorrow
> > > > then
> > > > > > > > the solution is not ready to merge yet.
> > > > > > > > I hope that prereviewers Anton Vinogradov and Nikolay Izhikov
> > > will
> > > > be
> > > > > > > > able to answer if solution out of scope or not in a couple of
> > > days.
> > > > > > > >
> > > > > > > > [1]
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-2-7-release-td34076.html#a34485
> > > > > > > > On Thu, Sep 27, 2018 at 11:14 PM Dmitriy Pavlov <
> > > > > dpavlov@gmail.com
> > > > > > >
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Yes, I agree, NPE during WAL flush is definitely a blocker.
> > > > > > > > >
> > > > > > > > > It is strange why the current test set did not fail after
> > > commit.
> > > > > > > > >
> > > > > > > > > чт, 27 сент. 2018 г. в 21:45, Andrey Kuznetsov <
> > > > stku...@gmail.com
> > > > > >:
> > > > > > > > >
> > > > > > > > > > 

Re: [Discussion] revert of commit MVCC, ignite-9320

[Dmitriy Setrakyan]

Guys, let's just fix the tests without reverting commits. Reverting a
commit may trigger a time machine, where all following commits may be
broken because of it. Fixing that scenario will be much harder.

Going forward, I would agree that we should not merge anything that breaks
tests. This is about following a basic engineering discipline. We should
all do it.

D.


On Fri, Sep 28, 2018 at 12:47 AM Dmitriy Pavlov 
wrote:

> Yep, we're humans and we constantly make mistakes. It is a very human thing
> to do mistakes.
>
> So I suggest we will be under the control and protection of robot to avoid
> mistakes, I suggest robot will revert such commits in 72h without its own
> personal attitudes, emotions, etc.
>
> Someone who is interested in contribution usually can find time to make
> contribution perfect.
>
> I'm not aware of project priorities, please share it. I believe different
> priorities can co-exist. A number of contributors are fixing tests, so it
> is a priority for them, isn't it? So why to add work to that guys because
> of you have other priorities?
>
> пт, 28 сент. 2018 г. в 10:39, Vladimir Ozerov :
>
> > Because a lot of other activities depended on configuration in Java, and
> we
> > didn't have expertise to fix .NET immediately.
> >
> > If you want to revert it - please go ahead. But I'd better suggest you to
> > think about the impact and project priorities first, instead of trying to
> > apply the some sort rules blindly. We are not robots.
> >
> > On Fri, Sep 28, 2018 at 10:19 AM Dmitriy Pavlov 
> > wrote:
> >
> > > Hi Vladimir,
> > >
> > > https://issues.apache.org/jira/browse/IGNITE-9320 is named
> configuration
> > > finalization.
> > >
> > > Why finalization was considered as done without tests passing?
> > >
> > > Why can't ve revert finalization change, re-do finalization with
> passing
> > > tests and merge changes?
> > >
> > > Sincerely,
> > > Dmitriy Pavlov
> > >
> > > пт, 28 сент. 2018 г. в 8:16, Vladimir Ozerov :
> > >
> > > > Test is going to be fixed in the scope of AI 2.7 [1]. This is not
> > > > one-minute fix as there are multiple places where configuration
> should
> > be
> > > > passed, and changes should be covered with tests. I muted the test
> for
> > > now.
> > > >
> > > > [1] https://issues.apache.org/jira/browse/IGNITE-9390
> > > >
> > > > On Fri, Sep 28, 2018 at 2:40 AM Dmitriy Setrakyan <
> > dsetrak...@apache.org
> > > >
> > > > wrote:
> > > >
> > > > > Let's not revert any commits yet. Can we find out who did the
> commit
> > > and
> > > > > why he/she is not fixing the test?
> > > > >
> > > > > D.
> > > > >
> > > > > On Thu, Sep 27, 2018 at 4:21 PM Vyacheslav Daradur <
> > > daradu...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > Are you talking about
> > > > > > 'IgniteConfigurationParityTest#TestIgniteConfiguration'?
> > > > > >
> > > > > > Seems it's not hard to fix this test, it's necessary just to
> > > implement
> > > > > > missing members (at least as stubs) on .NET side in
> > > > > > IgniteConfiguration class.
> > > > > >
> > > > > > Is there a Jira issue?
> > > > > >
> > > > > > On Fri, Sep 28, 2018 at 2:12 AM Dmitriy Pavlov <
> > > dpavlov@gmail.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > I'm grateful for contributions made in that area, but it seems
> > > folks
> > > > > > don't
> > > > > > > have time to fix the test.
> > > > > > >
> > > > > > >
> > > > > > > Tomorrow I'm going to revert commit.
> > > > > > >
> > > > > > > It seems it is the only way we can keep master more or less
> > green.
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://ci.ignite.apache.org/viewLog.html?buildId=1888723&tab=buildChangesDiv&buildTypeId=IgniteTests24Java8_PlatformNet
> > > > > > >
> > > > > > >
> > > > > > > Sincerely
> > > > > > > Dmitry Pavlov
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best Regards, Vyacheslav D.
> > > > > >
> > > > >
> > > >
> > >
> >
>

[jira] [Created] (IGNITE-9735) Determine partitions during parsing for MVCC DML statements

[Ivan Pavlukhin (JIRA)]

Ivan Pavlukhin created IGNITE-9735:
--

 Summary: Determine partitions during parsing for MVCC DML 
statements
 Key: IGNITE-9735
 URL: https://issues.apache.org/jira/browse/IGNITE-9735
 Project: Ignite
  Issue Type: Bug
  Components: mvcc
Reporter: Ivan Pavlukhin


Now with for MVCC caches query like below is broadcasted instead off sending to 
single node only.
{code:java}
update table set _val = _val + 1 where _key = ?{code}



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

[jira] [Created] (IGNITE-9736) Public interface DiscoverySpiListener.onDiscovery returns private API class

[Andrew Mashenkov (JIRA)]

Andrew Mashenkov created IGNITE-9736:


 Summary: Public interface DiscoverySpiListener.onDiscovery returns 
private API class
 Key: IGNITE-9736
 URL: https://issues.apache.org/jira/browse/IGNITE-9736
 Project: Ignite
  Issue Type: Bug
  Components: general
Reporter: Andrew Mashenkov
 Fix For: 2.8


Public interface DiscoverySpiListener.onDiscovery returns IgniteInternalFuture 
of 'internal' package.

We should wrap internal future into IgniteFuture of public API.



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

[jira] [Created] (IGNITE-9737) Ignite WatchDog service should be configurable

[Nikolay Izhikov (JIRA)]

Nikolay Izhikov created IGNITE-9737:
---

 Summary: Ignite WatchDog service should be configurable
 Key: IGNITE-9737
 URL: https://issues.apache.org/jira/browse/IGNITE-9737
 Project: Ignite
  Issue Type: Bug
Reporter: Nikolay Izhikov
 Fix For: 2.7


At the moment, there is no way to disable Ignite WatchDog service from config 
or JVM option.
In any corner case or bug in that feature Ignite can become fully unusable due 
to unpredictable shutdown.

We should provide a way to enable/disable this feature from config or from JVM 
option.



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

Re: Critical worker threads liveness checking drawbacks

[Nikolay Izhikov]

Ticket created - https://issues.apache.org/jira/browse/IGNITE-9737

Fixed version is 2.7.

В Пт, 28/09/2018 в 11:41 +0300, Alexey Goncharuk пишет:
> Nikolay, I agree, a user should be able to disable both thread liveness
> check and checkpoint read lock timeout check from config and a system
> property.
> 
> пт, 28 сент. 2018 г. в 11:30, Nikolay Izhikov :
> 
> > Hello, Igniters.
> > 
> > I found that this feature can't be disabled from config.
> > The only way to disable it is from JMX bean.
> > 
> > I think it very dangerous: If we have some corner case or a bug in this
> > Watch Dog it can make Ignite unusable.
> > I propose to implement possibility to disable this feature both - from
> > config and from JVM options.
> > 
> > What do you think?
> > 
> > В Чт, 27/09/2018 в 16:14 +0300, Andrey Kuznetsov пишет:
> > > Maxim,
> > > 
> > > Thanks for being attentive! It's definitely a typo. Could you please
> > 
> > create
> > > an issue?
> > > 
> > > чт, 27 сент. 2018 г. в 16:00, Maxim Muzafarov :
> > > 
> > > > Folks,
> > > > 
> > > > I've found in `GridCachePartitionExchangeManager:2684` [1] (master
> > 
> > branch)
> > > > exchange future wrapped
> > > > with double `blockingSectionEnd` method. Is it correct? I just want to
> > > > understand this change and
> > > > how should I use this in the future.
> > > > 
> > > > Should I file a new issue to fix this? I think here
> > 
> > `blockingSectionBegin`
> > > > method should be used.
> > > > 
> > > > -
> > > > blockingSectionEnd();
> > > > 
> > > > try {
> > > > resVer = exchFut.get(exchTimeout, TimeUnit.MILLISECONDS);
> > > > } finally {
> > > > blockingSectionEnd();
> > > > }
> > > > 
> > > > 
> > > > [1]
> > > > 
> > > > 
> > 
> > https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCachePartitionExchangeManager.java#L2684
> > > > 
> > > > On Wed, 26 Sep 2018 at 22:47 Vyacheslav Daradur 
> > > > wrote:
> > > > 
> > > > > Andrey Gura, thank you for the answer!
> > > > > 
> > > > > I agree that wrapping of 'init' method reduces the profit of watchdog
> > > > > service in case of PME worker, but in other cases, we should wrap all
> > > > > possible long sections on GridDhtPartitionExchangeFuture. For example
> > > > > 'onCacheChangeRequest' method or
> > > > > 'cctx.affinity().onCacheChangeRequest' inside because it may take
> > > > > significant time (reproducer attached).
> > > > > 
> > > > > I only want to point out a possible issue which may allow to end-user
> > > > > halt the Ignite cluster accidentally.
> > > > > 
> > > > > I'm sure that PME experts know how to fix this issue properly.
> > > > > On Wed, Sep 26, 2018 at 10:28 PM Andrey Gura 
> > 
> > wrote:
> > > > > > 
> > > > > > Vyacheslav,
> > > > > > 
> > > > > > Exchange worker is strongly tied with
> > > > > > GridDhtPartitionExchangeFuture#init and it is ok. Exchange worker
> > 
> > also
> > > > > > shouldn't be blocked for long time but in reality it happens.It
> > 
> > also
> > > > > > means that your change doesn't make sense.
> > > > > > 
> > > > > > What actually make sense it is identification of places which
> > > > > > intentionally blocking. May be some places/actions should be
> > 
> > braced by
> > > > > > blocking guards.
> > > > > > 
> > > > > > If you have failing tests please make sure that your
> > 
> > failureHandler is
> > > > > > NoOpFailureHandler or any other handler with ignoreFailureTypes =
> > > > > > [CRITICAL_WORKER_BLOCKED].
> > > > > > 
> > > > > > 
> > > > > > On Wed, Sep 26, 2018 at 9:43 PM Vyacheslav Daradur <
> > > > 
> > > > daradu...@gmail.com>
> > > > > wrote:
> > > > > > > 
> > > > > > > Hi Igniters!
> > > > > > > 
> > > > > > > Thank you for this important improvement!
> > > > > > > 
> > > > > > > I've looked through implementation and noticed that
> > > > > > > GridDhtPartitionsExchangeFuture#init has not been wrapped in
> > 
> > blocked
> > > > > > > section. This means it easy to halt the node in case of
> > 
> > longrunning
> > > > > > > actions during PME, for example when we create a cache with
> > > > > > > StoreFactrory which connect to 3rd party DB.
> > > > > > > 
> > > > > > > I'm not sure that it is the right behavior.
> > > > > > > 
> > > > > > > I filled the issue [1] and prepared the PR [2] with reproducer
> > 
> > and
> > > > > 
> > > > > possible fix.
> > > > > > > 
> > > > > > > Andrey, could you please look at and confirm that it makes sense?
> > > > > > > 
> > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-9710
> > > > > > > [2] https://github.com/apache/ignite/pull/4845
> > > > > > > On Mon, Sep 24, 2018 at 9:46 PM Andrey Kuznetsov <
> > 
> > stku...@gmail.com>
> > > > > 
> > > > > wrote:
> > > > > > > > 
> > > > > > > > Denis,
> > > > > > > > 
> > > > > > > > I've created the ticket [1] with short description of the
> > > > > 
> > > > > functionality.
> > > > > > > > 
> > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-9679
> >

Re: [Discussion] revert of commit MVCC, ignite-9320

[Andrey Mashenkov]

Hi,

Fix is trivial and ready.
Hope, it will be merged within IGNITE-7764 today.

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

On Fri, Sep 28, 2018 at 12:26 PM Dmitriy Setrakyan 
wrote:

> Guys, let's just fix the tests without reverting commits. Reverting a
> commit may trigger a time machine, where all following commits may be
> broken because of it. Fixing that scenario will be much harder.
>
> Going forward, I would agree that we should not merge anything that breaks
> tests. This is about following a basic engineering discipline. We should
> all do it.
>
> D.
>
>
> On Fri, Sep 28, 2018 at 12:47 AM Dmitriy Pavlov 
> wrote:
>
> > Yep, we're humans and we constantly make mistakes. It is a very human
> thing
> > to do mistakes.
> >
> > So I suggest we will be under the control and protection of robot to
> avoid
> > mistakes, I suggest robot will revert such commits in 72h without its own
> > personal attitudes, emotions, etc.
> >
> > Someone who is interested in contribution usually can find time to make
> > contribution perfect.
> >
> > I'm not aware of project priorities, please share it. I believe different
> > priorities can co-exist. A number of contributors are fixing tests, so it
> > is a priority for them, isn't it? So why to add work to that guys because
> > of you have other priorities?
> >
> > пт, 28 сент. 2018 г. в 10:39, Vladimir Ozerov :
> >
> > > Because a lot of other activities depended on configuration in Java,
> and
> > we
> > > didn't have expertise to fix .NET immediately.
> > >
> > > If you want to revert it - please go ahead. But I'd better suggest you
> to
> > > think about the impact and project priorities first, instead of trying
> to
> > > apply the some sort rules blindly. We are not robots.
> > >
> > > On Fri, Sep 28, 2018 at 10:19 AM Dmitriy Pavlov  >
> > > wrote:
> > >
> > > > Hi Vladimir,
> > > >
> > > > https://issues.apache.org/jira/browse/IGNITE-9320 is named
> > configuration
> > > > finalization.
> > > >
> > > > Why finalization was considered as done without tests passing?
> > > >
> > > > Why can't ve revert finalization change, re-do finalization with
> > passing
> > > > tests and merge changes?
> > > >
> > > > Sincerely,
> > > > Dmitriy Pavlov
> > > >
> > > > пт, 28 сент. 2018 г. в 8:16, Vladimir Ozerov :
> > > >
> > > > > Test is going to be fixed in the scope of AI 2.7 [1]. This is not
> > > > > one-minute fix as there are multiple places where configuration
> > should
> > > be
> > > > > passed, and changes should be covered with tests. I muted the test
> > for
> > > > now.
> > > > >
> > > > > [1] https://issues.apache.org/jira/browse/IGNITE-9390
> > > > >
> > > > > On Fri, Sep 28, 2018 at 2:40 AM Dmitriy Setrakyan <
> > > dsetrak...@apache.org
> > > > >
> > > > > wrote:
> > > > >
> > > > > > Let's not revert any commits yet. Can we find out who did the
> > commit
> > > > and
> > > > > > why he/she is not fixing the test?
> > > > > >
> > > > > > D.
> > > > > >
> > > > > > On Thu, Sep 27, 2018 at 4:21 PM Vyacheslav Daradur <
> > > > daradu...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > Are you talking about
> > > > > > > 'IgniteConfigurationParityTest#TestIgniteConfiguration'?
> > > > > > >
> > > > > > > Seems it's not hard to fix this test, it's necessary just to
> > > > implement
> > > > > > > missing members (at least as stubs) on .NET side in
> > > > > > > IgniteConfiguration class.
> > > > > > >
> > > > > > > Is there a Jira issue?
> > > > > > >
> > > > > > > On Fri, Sep 28, 2018 at 2:12 AM Dmitriy Pavlov <
> > > > dpavlov@gmail.com>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > I'm grateful for contributions made in that area, but it
> seems
> > > > folks
> > > > > > > don't
> > > > > > > > have time to fix the test.
> > > > > > > >
> > > > > > > >
> > > > > > > > Tomorrow I'm going to revert commit.
> > > > > > > >
> > > > > > > > It seems it is the only way we can keep master more or less
> > > green.
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://ci.ignite.apache.org/viewLog.html?buildId=1888723&tab=buildChangesDiv&buildTypeId=IgniteTests24Java8_PlatformNet
> > > > > > > >
> > > > > > > >
> > > > > > > > Sincerely
> > > > > > > > Dmitry Pavlov
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Best Regards, Vyacheslav D.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>


-- 
Best regards,
Andrey V. Mashenkov

Re: Critical worker threads liveness checking drawbacks

[Andrey Gura]

Guys,

why we need both config option and system property? I believe one way is enough.
On Fri, Sep 28, 2018 at 12:38 PM Nikolay Izhikov  wrote:
>
> Ticket created - https://issues.apache.org/jira/browse/IGNITE-9737
>
> Fixed version is 2.7.
>
> В Пт, 28/09/2018 в 11:41 +0300, Alexey Goncharuk пишет:
> > Nikolay, I agree, a user should be able to disable both thread liveness
> > check and checkpoint read lock timeout check from config and a system
> > property.
> >
> > пт, 28 сент. 2018 г. в 11:30, Nikolay Izhikov :
> >
> > > Hello, Igniters.
> > >
> > > I found that this feature can't be disabled from config.
> > > The only way to disable it is from JMX bean.
> > >
> > > I think it very dangerous: If we have some corner case or a bug in this
> > > Watch Dog it can make Ignite unusable.
> > > I propose to implement possibility to disable this feature both - from
> > > config and from JVM options.
> > >
> > > What do you think?
> > >
> > > В Чт, 27/09/2018 в 16:14 +0300, Andrey Kuznetsov пишет:
> > > > Maxim,
> > > >
> > > > Thanks for being attentive! It's definitely a typo. Could you please
> > >
> > > create
> > > > an issue?
> > > >
> > > > чт, 27 сент. 2018 г. в 16:00, Maxim Muzafarov :
> > > >
> > > > > Folks,
> > > > >
> > > > > I've found in `GridCachePartitionExchangeManager:2684` [1] (master
> > >
> > > branch)
> > > > > exchange future wrapped
> > > > > with double `blockingSectionEnd` method. Is it correct? I just want to
> > > > > understand this change and
> > > > > how should I use this in the future.
> > > > >
> > > > > Should I file a new issue to fix this? I think here
> > >
> > > `blockingSectionBegin`
> > > > > method should be used.
> > > > >
> > > > > -
> > > > > blockingSectionEnd();
> > > > >
> > > > > try {
> > > > > resVer = exchFut.get(exchTimeout, TimeUnit.MILLISECONDS);
> > > > > } finally {
> > > > > blockingSectionEnd();
> > > > > }
> > > > >
> > > > >
> > > > > [1]
> > > > >
> > > > >
> > >
> > > https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCachePartitionExchangeManager.java#L2684
> > > > >
> > > > > On Wed, 26 Sep 2018 at 22:47 Vyacheslav Daradur 
> > > > > wrote:
> > > > >
> > > > > > Andrey Gura, thank you for the answer!
> > > > > >
> > > > > > I agree that wrapping of 'init' method reduces the profit of 
> > > > > > watchdog
> > > > > > service in case of PME worker, but in other cases, we should wrap 
> > > > > > all
> > > > > > possible long sections on GridDhtPartitionExchangeFuture. For 
> > > > > > example
> > > > > > 'onCacheChangeRequest' method or
> > > > > > 'cctx.affinity().onCacheChangeRequest' inside because it may take
> > > > > > significant time (reproducer attached).
> > > > > >
> > > > > > I only want to point out a possible issue which may allow to 
> > > > > > end-user
> > > > > > halt the Ignite cluster accidentally.
> > > > > >
> > > > > > I'm sure that PME experts know how to fix this issue properly.
> > > > > > On Wed, Sep 26, 2018 at 10:28 PM Andrey Gura 
> > >
> > > wrote:
> > > > > > >
> > > > > > > Vyacheslav,
> > > > > > >
> > > > > > > Exchange worker is strongly tied with
> > > > > > > GridDhtPartitionExchangeFuture#init and it is ok. Exchange worker
> > >
> > > also
> > > > > > > shouldn't be blocked for long time but in reality it happens.It
> > >
> > > also
> > > > > > > means that your change doesn't make sense.
> > > > > > >
> > > > > > > What actually make sense it is identification of places which
> > > > > > > intentionally blocking. May be some places/actions should be
> > >
> > > braced by
> > > > > > > blocking guards.
> > > > > > >
> > > > > > > If you have failing tests please make sure that your
> > >
> > > failureHandler is
> > > > > > > NoOpFailureHandler or any other handler with ignoreFailureTypes =
> > > > > > > [CRITICAL_WORKER_BLOCKED].
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Sep 26, 2018 at 9:43 PM Vyacheslav Daradur <
> > > > >
> > > > > daradu...@gmail.com>
> > > > > > wrote:
> > > > > > > >
> > > > > > > > Hi Igniters!
> > > > > > > >
> > > > > > > > Thank you for this important improvement!
> > > > > > > >
> > > > > > > > I've looked through implementation and noticed that
> > > > > > > > GridDhtPartitionsExchangeFuture#init has not been wrapped in
> > >
> > > blocked
> > > > > > > > section. This means it easy to halt the node in case of
> > >
> > > longrunning
> > > > > > > > actions during PME, for example when we create a cache with
> > > > > > > > StoreFactrory which connect to 3rd party DB.
> > > > > > > >
> > > > > > > > I'm not sure that it is the right behavior.
> > > > > > > >
> > > > > > > > I filled the issue [1] and prepared the PR [2] with reproducer
> > >
> > > and
> > > > > >
> > > > > > possible fix.
> > > > > > > >
> > > > > > > > Andrey, could you please look at and confirm that it makes 
> > > > > > > > sense?
> > > > > > > >
> > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-971

Re: [Discussion] revert of commit MVCC, ignite-9320

[Vladimir Ozerov]

Andrey,

This is not a fix, but a hack, which covers real state of affairs.

пт, 28 сент. 2018 г. в 13:00, Andrey Mashenkov :

> Hi,
>
> Fix is trivial and ready.
> Hope, it will be merged within IGNITE-7764 today.
>
> https://issues.apache.org/jira/browse/IGNITE-7764
>
> On Fri, Sep 28, 2018 at 12:26 PM Dmitriy Setrakyan 
> wrote:
>
> > Guys, let's just fix the tests without reverting commits. Reverting a
> > commit may trigger a time machine, where all following commits may be
> > broken because of it. Fixing that scenario will be much harder.
> >
> > Going forward, I would agree that we should not merge anything that
> breaks
> > tests. This is about following a basic engineering discipline. We should
> > all do it.
> >
> > D.
> >
> >
> > On Fri, Sep 28, 2018 at 12:47 AM Dmitriy Pavlov 
> > wrote:
> >
> > > Yep, we're humans and we constantly make mistakes. It is a very human
> > thing
> > > to do mistakes.
> > >
> > > So I suggest we will be under the control and protection of robot to
> > avoid
> > > mistakes, I suggest robot will revert such commits in 72h without its
> own
> > > personal attitudes, emotions, etc.
> > >
> > > Someone who is interested in contribution usually can find time to make
> > > contribution perfect.
> > >
> > > I'm not aware of project priorities, please share it. I believe
> different
> > > priorities can co-exist. A number of contributors are fixing tests, so
> it
> > > is a priority for them, isn't it? So why to add work to that guys
> because
> > > of you have other priorities?
> > >
> > > пт, 28 сент. 2018 г. в 10:39, Vladimir Ozerov :
> > >
> > > > Because a lot of other activities depended on configuration in Java,
> > and
> > > we
> > > > didn't have expertise to fix .NET immediately.
> > > >
> > > > If you want to revert it - please go ahead. But I'd better suggest
> you
> > to
> > > > think about the impact and project priorities first, instead of
> trying
> > to
> > > > apply the some sort rules blindly. We are not robots.
> > > >
> > > > On Fri, Sep 28, 2018 at 10:19 AM Dmitriy Pavlov <
> dpavlov@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > Hi Vladimir,
> > > > >
> > > > > https://issues.apache.org/jira/browse/IGNITE-9320 is named
> > > configuration
> > > > > finalization.
> > > > >
> > > > > Why finalization was considered as done without tests passing?
> > > > >
> > > > > Why can't ve revert finalization change, re-do finalization with
> > > passing
> > > > > tests and merge changes?
> > > > >
> > > > > Sincerely,
> > > > > Dmitriy Pavlov
> > > > >
> > > > > пт, 28 сент. 2018 г. в 8:16, Vladimir Ozerov  >:
> > > > >
> > > > > > Test is going to be fixed in the scope of AI 2.7 [1]. This is not
> > > > > > one-minute fix as there are multiple places where configuration
> > > should
> > > > be
> > > > > > passed, and changes should be covered with tests. I muted the
> test
> > > for
> > > > > now.
> > > > > >
> > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-9390
> > > > > >
> > > > > > On Fri, Sep 28, 2018 at 2:40 AM Dmitriy Setrakyan <
> > > > dsetrak...@apache.org
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Let's not revert any commits yet. Can we find out who did the
> > > commit
> > > > > and
> > > > > > > why he/she is not fixing the test?
> > > > > > >
> > > > > > > D.
> > > > > > >
> > > > > > > On Thu, Sep 27, 2018 at 4:21 PM Vyacheslav Daradur <
> > > > > daradu...@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > Are you talking about
> > > > > > > > 'IgniteConfigurationParityTest#TestIgniteConfiguration'?
> > > > > > > >
> > > > > > > > Seems it's not hard to fix this test, it's necessary just to
> > > > > implement
> > > > > > > > missing members (at least as stubs) on .NET side in
> > > > > > > > IgniteConfiguration class.
> > > > > > > >
> > > > > > > > Is there a Jira issue?
> > > > > > > >
> > > > > > > > On Fri, Sep 28, 2018 at 2:12 AM Dmitriy Pavlov <
> > > > > dpavlov@gmail.com>
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > I'm grateful for contributions made in that area, but it
> > seems
> > > > > folks
> > > > > > > > don't
> > > > > > > > > have time to fix the test.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Tomorrow I'm going to revert commit.
> > > > > > > > >
> > > > > > > > > It seems it is the only way we can keep master more or less
> > > > green.
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://ci.ignite.apache.org/viewLog.html?buildId=1888723&tab=buildChangesDiv&buildTypeId=IgniteTests24Java8_PlatformNet
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Sincerely
> > > > > > > > > Dmitry Pavlov
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Best Regards, Vyacheslav D.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
>
> --
> Best regards,
> Andrey V. Mashenko

Re: Critical worker threads liveness checking drawbacks

[Vladimir Ozerov]

Then it should be config option.

пт, 28 сент. 2018 г. в 13:15, Andrey Gura :

> Guys,
>
> why we need both config option and system property? I believe one way is
> enough.
> On Fri, Sep 28, 2018 at 12:38 PM Nikolay Izhikov 
> wrote:
> >
> > Ticket created - https://issues.apache.org/jira/browse/IGNITE-9737
> >
> > Fixed version is 2.7.
> >
> > В Пт, 28/09/2018 в 11:41 +0300, Alexey Goncharuk пишет:
> > > Nikolay, I agree, a user should be able to disable both thread liveness
> > > check and checkpoint read lock timeout check from config and a system
> > > property.
> > >
> > > пт, 28 сент. 2018 г. в 11:30, Nikolay Izhikov :
> > >
> > > > Hello, Igniters.
> > > >
> > > > I found that this feature can't be disabled from config.
> > > > The only way to disable it is from JMX bean.
> > > >
> > > > I think it very dangerous: If we have some corner case or a bug in
> this
> > > > Watch Dog it can make Ignite unusable.
> > > > I propose to implement possibility to disable this feature both -
> from
> > > > config and from JVM options.
> > > >
> > > > What do you think?
> > > >
> > > > В Чт, 27/09/2018 в 16:14 +0300, Andrey Kuznetsov пишет:
> > > > > Maxim,
> > > > >
> > > > > Thanks for being attentive! It's definitely a typo. Could you
> please
> > > >
> > > > create
> > > > > an issue?
> > > > >
> > > > > чт, 27 сент. 2018 г. в 16:00, Maxim Muzafarov  >:
> > > > >
> > > > > > Folks,
> > > > > >
> > > > > > I've found in `GridCachePartitionExchangeManager:2684` [1]
> (master
> > > >
> > > > branch)
> > > > > > exchange future wrapped
> > > > > > with double `blockingSectionEnd` method. Is it correct? I just
> want to
> > > > > > understand this change and
> > > > > > how should I use this in the future.
> > > > > >
> > > > > > Should I file a new issue to fix this? I think here
> > > >
> > > > `blockingSectionBegin`
> > > > > > method should be used.
> > > > > >
> > > > > > -
> > > > > > blockingSectionEnd();
> > > > > >
> > > > > > try {
> > > > > > resVer = exchFut.get(exchTimeout, TimeUnit.MILLISECONDS);
> > > > > > } finally {
> > > > > > blockingSectionEnd();
> > > > > > }
> > > > > >
> > > > > >
> > > > > > [1]
> > > > > >
> > > > > >
> > > >
> > > >
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCachePartitionExchangeManager.java#L2684
> > > > > >
> > > > > > On Wed, 26 Sep 2018 at 22:47 Vyacheslav Daradur <
> daradu...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Andrey Gura, thank you for the answer!
> > > > > > >
> > > > > > > I agree that wrapping of 'init' method reduces the profit of
> watchdog
> > > > > > > service in case of PME worker, but in other cases, we should
> wrap all
> > > > > > > possible long sections on GridDhtPartitionExchangeFuture. For
> example
> > > > > > > 'onCacheChangeRequest' method or
> > > > > > > 'cctx.affinity().onCacheChangeRequest' inside because it may
> take
> > > > > > > significant time (reproducer attached).
> > > > > > >
> > > > > > > I only want to point out a possible issue which may allow to
> end-user
> > > > > > > halt the Ignite cluster accidentally.
> > > > > > >
> > > > > > > I'm sure that PME experts know how to fix this issue properly.
> > > > > > > On Wed, Sep 26, 2018 at 10:28 PM Andrey Gura  >
> > > >
> > > > wrote:
> > > > > > > >
> > > > > > > > Vyacheslav,
> > > > > > > >
> > > > > > > > Exchange worker is strongly tied with
> > > > > > > > GridDhtPartitionExchangeFuture#init and it is ok. Exchange
> worker
> > > >
> > > > also
> > > > > > > > shouldn't be blocked for long time but in reality it
> happens.It
> > > >
> > > > also
> > > > > > > > means that your change doesn't make sense.
> > > > > > > >
> > > > > > > > What actually make sense it is identification of places which
> > > > > > > > intentionally blocking. May be some places/actions should be
> > > >
> > > > braced by
> > > > > > > > blocking guards.
> > > > > > > >
> > > > > > > > If you have failing tests please make sure that your
> > > >
> > > > failureHandler is
> > > > > > > > NoOpFailureHandler or any other handler with
> ignoreFailureTypes =
> > > > > > > > [CRITICAL_WORKER_BLOCKED].
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, Sep 26, 2018 at 9:43 PM Vyacheslav Daradur <
> > > > > >
> > > > > > daradu...@gmail.com>
> > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Hi Igniters!
> > > > > > > > >
> > > > > > > > > Thank you for this important improvement!
> > > > > > > > >
> > > > > > > > > I've looked through implementation and noticed that
> > > > > > > > > GridDhtPartitionsExchangeFuture#init has not been wrapped
> in
> > > >
> > > > blocked
> > > > > > > > > section. This means it easy to halt the node in case of
> > > >
> > > > longrunning
> > > > > > > > > actions during PME, for example when we create a cache with
> > > > > > > > > StoreFactrory which connect to 3rd party DB.
> > > > > > > > >
> > > > > > > > > I'm not sure that it is the right beha

[GitHub] ignite pull request #4865: IGNITE-9717: Fixed setters in LogReg and SVM

[zaleslaw]

GitHub user zaleslaw opened a pull request:

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

IGNITE-9717: Fixed setters in LogReg and SVM



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

$ git pull https://github.com/gridgain/apache-ignite ignite-9717

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

https://github.com/apache/ignite/pull/4865.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 #4865


commit 10e030f426334baf3adb2b0ce2f2b038a0068254
Author: Zinoviev Alexey 
Date:   2018-09-28T10:20:49Z

IGNITE-9717: Added required methods and remove constructor

commit 6c7cf978bf58696890cc0d3fdf6daef90b8d0b0e
Author: Zinoviev Alexey 
Date:   2018-09-28T10:27:00Z

IGNITE-9717: Fixed examples

commit 6645aedfc21d5cc245332e3d2769d9084f1b2656
Author: Zinoviev Alexey 
Date:   2018-09-28T10:30:33Z

IGNITE-9717: Format code

commit fc41a6b722e282b6b39c41b1898fa037ac9605ee
Author: Zinoviev Alexey 
Date:   2018-09-28T10:58:59Z

IGNITE-9717: Fixed types




---

Re: [Discussion] revert of commit MVCC, ignite-9320

[Dmitriy Pavlov]

Hi Dmitriy S.,

I really prefer avoiding reverts, which why I've started this topic. If I
were reverting-fan, I could just write: "Vetoing commit  because of
test failures , commit reverted, ticket IGNITE- reopened."

But some time ago I several times asked newbie contributors to fix missed
test failures and they managed to do it in 1-2 days, I'm waiting these test
to be fixed by Ignite veteran(s) for 11 days.

Sincerely,
Dmitriy Pavlov


пт, 28 сент. 2018 г. в 13:16, Vladimir Ozerov :

> Andrey,
>
> This is not a fix, but a hack, which covers real state of affairs.
>
> пт, 28 сент. 2018 г. в 13:00, Andrey Mashenkov  >:
>
> > Hi,
> >
> > Fix is trivial and ready.
> > Hope, it will be merged within IGNITE-7764 today.
> >
> > https://issues.apache.org/jira/browse/IGNITE-7764
> >
> > On Fri, Sep 28, 2018 at 12:26 PM Dmitriy Setrakyan <
> dsetrak...@apache.org>
> > wrote:
> >
> > > Guys, let's just fix the tests without reverting commits. Reverting a
> > > commit may trigger a time machine, where all following commits may be
> > > broken because of it. Fixing that scenario will be much harder.
> > >
> > > Going forward, I would agree that we should not merge anything that
> > breaks
> > > tests. This is about following a basic engineering discipline. We
> should
> > > all do it.
> > >
> > > D.
> > >
> > >
> > > On Fri, Sep 28, 2018 at 12:47 AM Dmitriy Pavlov  >
> > > wrote:
> > >
> > > > Yep, we're humans and we constantly make mistakes. It is a very human
> > > thing
> > > > to do mistakes.
> > > >
> > > > So I suggest we will be under the control and protection of robot to
> > > avoid
> > > > mistakes, I suggest robot will revert such commits in 72h without its
> > own
> > > > personal attitudes, emotions, etc.
> > > >
> > > > Someone who is interested in contribution usually can find time to
> make
> > > > contribution perfect.
> > > >
> > > > I'm not aware of project priorities, please share it. I believe
> > different
> > > > priorities can co-exist. A number of contributors are fixing tests,
> so
> > it
> > > > is a priority for them, isn't it? So why to add work to that guys
> > because
> > > > of you have other priorities?
> > > >
> > > > пт, 28 сент. 2018 г. в 10:39, Vladimir Ozerov  >:
> > > >
> > > > > Because a lot of other activities depended on configuration in
> Java,
> > > and
> > > > we
> > > > > didn't have expertise to fix .NET immediately.
> > > > >
> > > > > If you want to revert it - please go ahead. But I'd better suggest
> > you
> > > to
> > > > > think about the impact and project priorities first, instead of
> > trying
> > > to
> > > > > apply the some sort rules blindly. We are not robots.
> > > > >
> > > > > On Fri, Sep 28, 2018 at 10:19 AM Dmitriy Pavlov <
> > dpavlov@gmail.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > Hi Vladimir,
> > > > > >
> > > > > > https://issues.apache.org/jira/browse/IGNITE-9320 is named
> > > > configuration
> > > > > > finalization.
> > > > > >
> > > > > > Why finalization was considered as done without tests passing?
> > > > > >
> > > > > > Why can't ve revert finalization change, re-do finalization with
> > > > passing
> > > > > > tests and merge changes?
> > > > > >
> > > > > > Sincerely,
> > > > > > Dmitriy Pavlov
> > > > > >
> > > > > > пт, 28 сент. 2018 г. в 8:16, Vladimir Ozerov <
> voze...@gridgain.com
> > >:
> > > > > >
> > > > > > > Test is going to be fixed in the scope of AI 2.7 [1]. This is
> not
> > > > > > > one-minute fix as there are multiple places where configuration
> > > > should
> > > > > be
> > > > > > > passed, and changes should be covered with tests. I muted the
> > test
> > > > for
> > > > > > now.
> > > > > > >
> > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-9390
> > > > > > >
> > > > > > > On Fri, Sep 28, 2018 at 2:40 AM Dmitriy Setrakyan <
> > > > > dsetrak...@apache.org
> > > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Let's not revert any commits yet. Can we find out who did the
> > > > commit
> > > > > > and
> > > > > > > > why he/she is not fixing the test?
> > > > > > > >
> > > > > > > > D.
> > > > > > > >
> > > > > > > > On Thu, Sep 27, 2018 at 4:21 PM Vyacheslav Daradur <
> > > > > > daradu...@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > Are you talking about
> > > > > > > > > 'IgniteConfigurationParityTest#TestIgniteConfiguration'?
> > > > > > > > >
> > > > > > > > > Seems it's not hard to fix this test, it's necessary just
> to
> > > > > > implement
> > > > > > > > > missing members (at least as stubs) on .NET side in
> > > > > > > > > IgniteConfiguration class.
> > > > > > > > >
> > > > > > > > > Is there a Jira issue?
> > > > > > > > >
> > > > > > > > > On Fri, Sep 28, 2018 at 2:12 AM Dmitriy Pavlov <
> > > > > > dpavlov@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > Hi,
> > > > > > > > > >
> > > > > > > > > > I'm grateful for contributions made in that area, but it
> >

Re: Apache Ignite 2.7 release

[Dmitriy Pavlov]

Hi Dmitriy, Vladimir,

I suggest we stop this nonsense with release dates-pushing because of some
open question.

Just because you disagreed with any include/exclude something into scope,
does not mean that whole community disagreed.

If folks will start a separate discussion with results of the review, I see
no reasons to reject their contribution, even if we need to revisit our
agreements and wait for a couple of days more.

Am I missing some reason why dates are so fundamentally important to you?

Sincerely,
Dmitriy Pavlov

пт, 28 сент. 2018 г. в 12:20, Dmitriy Setrakyan :

> If services is not ready, which it is not, then we should include them into
> the next release. There is no need to force them into 2.7. I suggest we
> move according to the schedule we all agreed on.
>
> D.
>
> On Fri, Sep 28, 2018 at 1:22 AM Dmitriy Pavlov 
> wrote:
>
> > Yes, so correct statement is "community did not make any decisions about
> > services not go to 2.7/ services are out of scope".
> >
> > If so, please forgive me my confusion.
> >
> > пт, 28 сент. 2018 г. в 11:19, Vladimir Ozerov :
> >
> > > Exactly. So correct statement is “it is up to *community* to decide
> > whether
> > > something goes to 2.7”.
> > >
> > > пт, 28 сент. 2018 г. в 11:11, Dmitriy Pavlov :
> > >
> > > > No, it is up to the community to discuss after their review results.
> > > >
> > > > пт, 28 сент. 2018 г. в 11:09, Vladimir Ozerov  >:
> > > >
> > > > > Dmitriy,
> > > > >
> > > > > Did I read your words correctly that it is up to implementor of a
> > > single
> > > > > feature to decide whether release of all other features and fixes
> to
> > be
> > > > > delayed?
> > > > >
> > > > > пт, 28 сент. 2018 г. в 11:00, Dmitriy Pavlov <
> dpavlov@gmail.com
> > >:
> > > > >
> > > > > > My point we can wait a bit for services because
> > > > > > 1  we are open-minded and we don't have outside pressure to do
> > > release
> > > > in
> > > > > > October
> > > > > > 2  and services it is not some new feature, which suddenly
> appeared
> > > in
> > > > > > autumn, it is a well known and important feature.
> > > > > >
> > > > > > So it is up to Vyacheslav, Anton and Nikolay to decide.
> > > > > >
> > > > > > Decisions can be services are not ready/ready to merge only to
> > > > > master/ready
> > > > > > to merge to master and to 2.7.
> > > > > >
> > > > > >
> > > > > > пт, 28 сент. 2018 г. в 10:46, Vladimir Ozerov <
> > voze...@gridgain.com
> > > >:
> > > > > >
> > > > > > > Dmitry,
> > > > > > >
> > > > > > > Community agreement was to perform the release in October. Of
> > > course
> > > > we
> > > > > > can
> > > > > > > wait a bit for services. Then we wait a bit for other cool
> > features
> > > > > ready
> > > > > > > by that time, then again and again, and release will never
> > happen.
> > > > And
> > > > > > > while we are waiting for new features to come, already
> completerd
> > > > > > features
> > > > > > > cannot be used by anyone.
> > > > > > >
> > > > > > > This is why we have an agreement that if feature is not ready,
> it
> > > > > should
> > > > > > be
> > > > > > > moved to future release, instead of shifting release. The sole
> > > reason
> > > > > to
> > > > > > > have strict dates when decisions are made is to let release
> > happen.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Sep 28, 2018 at 2:22 AM Dmitriy Pavlov <
> > > > dpavlov@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Vladimir,  I'm not searching for enemy, and not fighting with
> > > you.
> > > > > I'm
> > > > > > > not
> > > > > > > > happy about cases when we are hurrying.
> > > > > > > >
> > > > > > > > We can't fix test, fill ticket details, can't wait for
> > > > contributions
> > > > > to
> > > > > > > > finish their tasks.  It is not best idea to use experience
> from
> > > > > > > commercial
> > > > > > > > companies in open source. Are there any pressure outside
> > > community?
> > > > > Did
> > > > > > > > someone promised rest of features to be released at 30
> > September?
> > > > > > > >
> > > > > > > > Let's remember principle do-orcracy, power of those who do.
> If
> > > > > > contribor
> > > > > > > > does change and reviewer does review, let's give right of
> > making
> > > > > > decision
> > > > > > > > to them, but not to some closed club of people who privately
> > > > discuss
> > > > > > > > something.
> > > > > > > >
> > > > > > > > Sincerely
> > > > > > > > Dmitriy Pavlov
> > > > > > > >
> > > > > > > > чт, 27 сент. 2018 г., 23:42 Vyacheslav Daradur <
> > > > daradu...@gmail.com
> > > > > >:
> > > > > > > >
> > > > > > > > > Hi Igniters!
> > > > > > > > >
> > > > > > > > > As I have written about Service Grid before [1] I'm
> > finalizing
> > > > the
> > > > > > > > > solution to be sure that implementation is reliable.
> > > > > > > > >
> > > > > > > > > About including it in 2.7, if we talk that code freeze
> > tomorrow
> > > > > then
> > > > > > > > > the solution is not ready to merge yet.
> > > > > > >

[GitHub] ignite pull request #4866: IGNITE-9712: SQL Select query benchmarks suite

[pavel-kuznetsov]

GitHub user pavel-kuznetsov opened a pull request:

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

IGNITE-9712: SQL Select query benchmarks suite

Updated data model.
Added new configuration file for select benchmarks.

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

$ git pull https://github.com/gridgain/apache-ignite ignite-9712

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

https://github.com/apache/ignite/pull/4866.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 #4866


commit 021b209dea0c424b96fe1c2ff8b184563c2c971c
Author: Pavel Kuznetsov 
Date:   2018-09-27T15:04:25Z

ignite-9712: Added selects with filter by indexed fields.

Updated data model to use index on val field. Added flag that affects 
whether PK or indexed val field will be used in WHERE clause.

commit 7917e434522b80557d0b85e94864fa0c37963df5
Author: Pavel Kuznetsov 
Date:   2018-09-27T15:37:23Z

ignite-9712: Added configuration file for select benchmarks.

range (1, 1000) x select mode (by PK, by val) x driver (native, thin, 
thick) = 12

commit 9d2bcba3f9a860e83c71c976f581abb967eaf21e
Author: Pavel Kuznetsov 
Date:   2018-09-28T10:33:58Z

ignite-9712: Fixed table name.

commit d0789416f75175ed7f06ab593251522e59a41071
Author: Pavel Kuznetsov 
Date:   2018-09-28T11:29:43Z

ignite-9712: fixed cfg names.




---

[GitHub] ignite pull request #4867: IGNITE-9713: Improve JavaDocs for String Preproce...

[zaleslaw]

GitHub user zaleslaw opened a pull request:

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

IGNITE-9713: Improve JavaDocs for String Preprocessing



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

$ git pull https://github.com/gridgain/apache-ignite ignite-9713

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

https://github.com/apache/ignite/pull/4867.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 #4867


commit 63e182103c9c881536c93160cc7fd12c2d36fdf2
Author: Zinoviev Alexey 
Date:   2018-09-28T11:34:10Z

IGNITE-9713: Fixed javadocs

commit 2048b2e14416a68128d57b7253ccf92f31fbb2cc
Author: Zinoviev Alexey 
Date:   2018-09-28T11:35:11Z

Merge branch 'master' into ignite-9713




---

Re: [Discussion] revert of commit MVCC, ignite-9320

[Павлухин Иван]

Hi guys!

By the way, is it practically feasible to revert a single commit without
making harm? If I am getting it right in current case reverting commit will
lead to compilation errors for commits depending on commit in question.

2018-09-28 14:22 GMT+03:00 Dmitriy Pavlov :

> Hi Dmitriy S.,
>
> I really prefer avoiding reverts, which why I've started this topic. If I
> were reverting-fan, I could just write: "Vetoing commit  because of
> test failures , commit reverted, ticket IGNITE- reopened."
>
> But some time ago I several times asked newbie contributors to fix missed
> test failures and they managed to do it in 1-2 days, I'm waiting these test
> to be fixed by Ignite veteran(s) for 11 days.
>
> Sincerely,
> Dmitriy Pavlov
>
>
> пт, 28 сент. 2018 г. в 13:16, Vladimir Ozerov :
>
> > Andrey,
> >
> > This is not a fix, but a hack, which covers real state of affairs.
> >
> > пт, 28 сент. 2018 г. в 13:00, Andrey Mashenkov <
> andrey.mashen...@gmail.com
> > >:
> >
> > > Hi,
> > >
> > > Fix is trivial and ready.
> > > Hope, it will be merged within IGNITE-7764 today.
> > >
> > > https://issues.apache.org/jira/browse/IGNITE-7764
> > >
> > > On Fri, Sep 28, 2018 at 12:26 PM Dmitriy Setrakyan <
> > dsetrak...@apache.org>
> > > wrote:
> > >
> > > > Guys, let's just fix the tests without reverting commits. Reverting a
> > > > commit may trigger a time machine, where all following commits may be
> > > > broken because of it. Fixing that scenario will be much harder.
> > > >
> > > > Going forward, I would agree that we should not merge anything that
> > > breaks
> > > > tests. This is about following a basic engineering discipline. We
> > should
> > > > all do it.
> > > >
> > > > D.
> > > >
> > > >
> > > > On Fri, Sep 28, 2018 at 12:47 AM Dmitriy Pavlov <
> dpavlov@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > Yep, we're humans and we constantly make mistakes. It is a very
> human
> > > > thing
> > > > > to do mistakes.
> > > > >
> > > > > So I suggest we will be under the control and protection of robot
> to
> > > > avoid
> > > > > mistakes, I suggest robot will revert such commits in 72h without
> its
> > > own
> > > > > personal attitudes, emotions, etc.
> > > > >
> > > > > Someone who is interested in contribution usually can find time to
> > make
> > > > > contribution perfect.
> > > > >
> > > > > I'm not aware of project priorities, please share it. I believe
> > > different
> > > > > priorities can co-exist. A number of contributors are fixing tests,
> > so
> > > it
> > > > > is a priority for them, isn't it? So why to add work to that guys
> > > because
> > > > > of you have other priorities?
> > > > >
> > > > > пт, 28 сент. 2018 г. в 10:39, Vladimir Ozerov <
> voze...@gridgain.com
> > >:
> > > > >
> > > > > > Because a lot of other activities depended on configuration in
> > Java,
> > > > and
> > > > > we
> > > > > > didn't have expertise to fix .NET immediately.
> > > > > >
> > > > > > If you want to revert it - please go ahead. But I'd better
> suggest
> > > you
> > > > to
> > > > > > think about the impact and project priorities first, instead of
> > > trying
> > > > to
> > > > > > apply the some sort rules blindly. We are not robots.
> > > > > >
> > > > > > On Fri, Sep 28, 2018 at 10:19 AM Dmitriy Pavlov <
> > > dpavlov@gmail.com
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Hi Vladimir,
> > > > > > >
> > > > > > > https://issues.apache.org/jira/browse/IGNITE-9320 is named
> > > > > configuration
> > > > > > > finalization.
> > > > > > >
> > > > > > > Why finalization was considered as done without tests passing?
> > > > > > >
> > > > > > > Why can't ve revert finalization change, re-do finalization
> with
> > > > > passing
> > > > > > > tests and merge changes?
> > > > > > >
> > > > > > > Sincerely,
> > > > > > > Dmitriy Pavlov
> > > > > > >
> > > > > > > пт, 28 сент. 2018 г. в 8:16, Vladimir Ozerov <
> > voze...@gridgain.com
> > > >:
> > > > > > >
> > > > > > > > Test is going to be fixed in the scope of AI 2.7 [1]. This is
> > not
> > > > > > > > one-minute fix as there are multiple places where
> configuration
> > > > > should
> > > > > > be
> > > > > > > > passed, and changes should be covered with tests. I muted the
> > > test
> > > > > for
> > > > > > > now.
> > > > > > > >
> > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-9390
> > > > > > > >
> > > > > > > > On Fri, Sep 28, 2018 at 2:40 AM Dmitriy Setrakyan <
> > > > > > dsetrak...@apache.org
> > > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Let's not revert any commits yet. Can we find out who did
> the
> > > > > commit
> > > > > > > and
> > > > > > > > > why he/she is not fixing the test?
> > > > > > > > >
> > > > > > > > > D.
> > > > > > > > >
> > > > > > > > > On Thu, Sep 27, 2018 at 4:21 PM Vyacheslav Daradur <
> > > > > > > daradu...@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Hi,
> > > > > > > > > >
> > > > > > > > > > Are you talking abo

Re: Apache Ignite 2.7 release

[Vladimir Ozerov]

Importance come from the fact that we agreed on these dates. Neither
community, nor implementors of the feature were against it. And community
already work hard to met that dates: a lot of people already aligned their
plans, a lot very important tickets were moved out of scope to met the
dates.

Nonsense - is to come at the end of coding phase and suggest to replay the
plans all of a sudden. If you find it important - please start a separate
discussion where it will be your responsibility to prove community that we
have to realign our plans and delay release of all other features due to
Service Grid being ahead of schedule. And solution to that problem will be
very simple - to plan another release once Service Grid is coded, tested,
reviewed and benchmarked.

On Fri, Sep 28, 2018 at 2:31 PM Dmitriy Pavlov 
wrote:

> Hi Dmitriy, Vladimir,
>
> I suggest we stop this nonsense with release dates-pushing because of some
> open question.
>
> Just because you disagreed with any include/exclude something into scope,
> does not mean that whole community disagreed.
>
> If folks will start a separate discussion with results of the review, I see
> no reasons to reject their contribution, even if we need to revisit our
> agreements and wait for a couple of days more.
>
> Am I missing some reason why dates are so fundamentally important to you?
>
> Sincerely,
> Dmitriy Pavlov
>
> пт, 28 сент. 2018 г. в 12:20, Dmitriy Setrakyan :
>
> > If services is not ready, which it is not, then we should include them
> into
> > the next release. There is no need to force them into 2.7. I suggest we
> > move according to the schedule we all agreed on.
> >
> > D.
> >
> > On Fri, Sep 28, 2018 at 1:22 AM Dmitriy Pavlov 
> > wrote:
> >
> > > Yes, so correct statement is "community did not make any decisions
> about
> > > services not go to 2.7/ services are out of scope".
> > >
> > > If so, please forgive me my confusion.
> > >
> > > пт, 28 сент. 2018 г. в 11:19, Vladimir Ozerov :
> > >
> > > > Exactly. So correct statement is “it is up to *community* to decide
> > > whether
> > > > something goes to 2.7”.
> > > >
> > > > пт, 28 сент. 2018 г. в 11:11, Dmitriy Pavlov  >:
> > > >
> > > > > No, it is up to the community to discuss after their review
> results.
> > > > >
> > > > > пт, 28 сент. 2018 г. в 11:09, Vladimir Ozerov <
> voze...@gridgain.com
> > >:
> > > > >
> > > > > > Dmitriy,
> > > > > >
> > > > > > Did I read your words correctly that it is up to implementor of a
> > > > single
> > > > > > feature to decide whether release of all other features and fixes
> > to
> > > be
> > > > > > delayed?
> > > > > >
> > > > > > пт, 28 сент. 2018 г. в 11:00, Dmitriy Pavlov <
> > dpavlov@gmail.com
> > > >:
> > > > > >
> > > > > > > My point we can wait a bit for services because
> > > > > > > 1  we are open-minded and we don't have outside pressure to do
> > > > release
> > > > > in
> > > > > > > October
> > > > > > > 2  and services it is not some new feature, which suddenly
> > appeared
> > > > in
> > > > > > > autumn, it is a well known and important feature.
> > > > > > >
> > > > > > > So it is up to Vyacheslav, Anton and Nikolay to decide.
> > > > > > >
> > > > > > > Decisions can be services are not ready/ready to merge only to
> > > > > > master/ready
> > > > > > > to merge to master and to 2.7.
> > > > > > >
> > > > > > >
> > > > > > > пт, 28 сент. 2018 г. в 10:46, Vladimir Ozerov <
> > > voze...@gridgain.com
> > > > >:
> > > > > > >
> > > > > > > > Dmitry,
> > > > > > > >
> > > > > > > > Community agreement was to perform the release in October. Of
> > > > course
> > > > > we
> > > > > > > can
> > > > > > > > wait a bit for services. Then we wait a bit for other cool
> > > features
> > > > > > ready
> > > > > > > > by that time, then again and again, and release will never
> > > happen.
> > > > > And
> > > > > > > > while we are waiting for new features to come, already
> > completerd
> > > > > > > features
> > > > > > > > cannot be used by anyone.
> > > > > > > >
> > > > > > > > This is why we have an agreement that if feature is not
> ready,
> > it
> > > > > > should
> > > > > > > be
> > > > > > > > moved to future release, instead of shifting release. The
> sole
> > > > reason
> > > > > > to
> > > > > > > > have strict dates when decisions are made is to let release
> > > happen.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Fri, Sep 28, 2018 at 2:22 AM Dmitriy Pavlov <
> > > > > dpavlov@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Vladimir,  I'm not searching for enemy, and not fighting
> with
> > > > you.
> > > > > > I'm
> > > > > > > > not
> > > > > > > > > happy about cases when we are hurrying.
> > > > > > > > >
> > > > > > > > > We can't fix test, fill ticket details, can't wait for
> > > > > contributions
> > > > > > to
> > > > > > > > > finish their tasks.  It is not best idea to use experience
> > from
> > > > > > > > commercial
> > > > > > > > > companies in open source. 

Need Review IGNITE-7616 Mxbeans thread display.

[David Harvey]

   1.
  This is my second newbie submission, it could use a review, and I
  keep getting snapshot dependency errors in teamcity that seem like the
  cannot be related to my changes, even after rebasing 2 twice.
I couldn't
  find a crisp defintion of what a snapshot dependency is.

  It is a low regression risk fix to the mxbeans display of thread
  pools, where one type of pool mxbeans registration was simply
miscoded, and
  another type of pool was completely missing any code to display it.  It
  provides insight at runtime into two thread pools that are currently
  opaque.It makes one very modest change to actual production code.

  2. IGNITE-7616
GridDataStreamExecutor
   and GridCallbackExecutor JMX beans return incorrect values due to invalid
   interface registration.


https://github.com/apache/ignite/pull/4732
-DH

PS I have seen this movie before, and the future got much brighter future
when we completed the equivalent of making teamcity  whole again.

[GitHub] ignite pull request #4868: IGNITE-9736 Fixed public API for Discovery SPI li...

[Jokser]

GitHub user Jokser opened a pull request:

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

IGNITE-9736 Fixed public API for Discovery SPI listener



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

$ git pull https://github.com/gridgain/apache-ignite ignite-9736

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

https://github.com/apache/ignite/pull/4868.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 #4868


commit dc96fe07f4b73984e03e12dcc7f4201dc7bc7e05
Author: Pavel Kovalenko 
Date:   2018-09-28T12:37:41Z

IGNITE-9736 Changed return type of Discovery SPI listener for public API.

commit b67a61c7a2b8200e026d53aaebc0e274a38c7993
Author: Pavel Kovalenko 
Date:   2018-09-28T12:41:23Z

IGNITE-9736 Fixed usages of Discovery SPI listener.




---

[GitHub] ignite pull request #4725: IGNITE-7764: MVCC TX: make cache basic operations...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] ignite pull request #4867: IGNITE-9713: Improve JavaDocs for String Preproce...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[QUESTION] SegmentAware holder initialization (fix of WAL blocked rollOver)

[Maxim Muzafarov]

Igniters,

I would like to discuss this question here and create a separate topic for
it. Previously, I've posted some comments on the probable issue in Apache
Ignite 2.7 topic [2]. My question is related to the IGNITE-8559 [3] (commit
[4]). We've added a new SegmentAware class and change the
FileWriteAheadLogManager behaviour.


The FileWriteAheadLogManager now contains:

`private final SegmentAware segmentAware;`.

The SegmentAware have the `interrupt()` method which at manager
de-activation sets (e.g. for SegmentArchivedStorage) `interrupted` filed to
`true` value [5] but never revert it to `false` after activation. So, the
SegmentArchivedStorage after de-activation always remain interrupted.

I think it can lead us to unpredictable issues with multiple cluster
activation/de-activation. I don't know why all tests in master branch
suppose to be successful but in my local branch, they hang on exchange
future get() method.

My local solution (probably not ideal) is:
1) make it volatile - `private volatile SegmentAware segmentAware;`
2) move field init to the `start0()` method of FileWriteAheadLogManager;

With these changes, everything begins to work fine but I can miss something
because I don’t understand the whole this change well enough.

Can anyone comment on this and share details IGNITE-8559 implementation?


[1]
https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/wal/FileWriteAheadLogManager.java#L319
[2]
http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-2-7-release-tp34076p35863.html
[3] https://issues.apache.org/jira/browse/IGNITE-8559
[4]
https://github.com/apache/ignite/commit/2f72fe758d4256c4eb4610e5922ad3d174b43dc5
[5]
https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/wal/aware/SegmentArchivedStorage.java#L117
-- 
--
Maxim Muzafarov

[GitHub] ignite pull request #4865: IGNITE-9717: Fixed setters in LogReg and SVM

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] ignite pull request #4869: IGNITE-9282 Add Gaussian Naive Bayes Classifier

[dehasi]

GitHub user dehasi opened a pull request:

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

IGNITE-9282 Add Gaussian Naive Bayes Classifier



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

$ git pull https://github.com/dehasi/ignite feature/ignite-9282-naive-bayes

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

https://github.com/apache/ignite/pull/4869.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 #4869


commit a397a4e89bd57fd1062b9d2a8f4be35be74bf9e7
Author: dehasi 
Date:   2018-09-08T17:21:17Z

IGNITE-9282: Create bayes packages

commit 814d45516334b10264f49c6ff31b05883f7c7535
Author: dehasi 
Date:   2018-09-08T18:55:33Z

IGNITE-9282: Add gauss density function

commit 7600f9814806cfa377dc8c350d2540f5ffee34f7
Author: dehasi 
Date:   2018-09-08T20:16:07Z

IGNITE-9282: Implement model

commit 8b7a9e8ba7f423ffbec0153ad9f6dcafe1921c85
Author: dehasi 
Date:   2018-09-08T20:25:41Z

IGNITE-9282: Add java doc

commit bf943bd29395fed9a266c13a5c58960f9b41d5cd
Author: dehasi 
Date:   2018-09-08T20:26:04Z

IGNITE-9282: Add dot

commit a26865860f7fb5601178f02b93e930686a6669a1
Author: dehasi 
Date:   2018-09-09T15:46:16Z

IGNITE-9282: Update java doc

commit e266041820d4dddec6e3158a4d31731906ade8ec
Author: dehasi 
Date:   2018-09-09T15:54:26Z

IGNITE-9282: Add a trainer skeleton

commit c91bd79d3eaa84afa7557374cddae5053887266f
Author: dehasi 
Date:   2018-09-17T17:31:05Z

IGNITE-9282: Add javadoc

commit e9498bb5eac4fcb36244270a7d38239ebc31520e
Author: dehasi 
Date:   2018-09-21T12:22:18Z

IGNITE-9282: Add computation skeleton

commit bc98cc65e44ba3f98386007ff74d4fc9d6c6c36d
Author: dehasi 
Date:   2018-09-21T12:46:19Z

IGNITE-9282: count means for each label

commit 977b2393734ceabbe858d5aee8e9861039bb2ce5
Author: dehasi 
Date:   2018-09-23T20:50:55Z

IGNITE-9282: count means with map reduce

commit 117939be9a7f537d057d3454846b4389aba6e6d9
Author: dehasi 
Date:   2018-09-23T21:47:16Z

IGNITE-9282: Add trainer unit test

commit 2c8d29a51cde34e6356e922e8eccf378ca979221
Author: dehasi 
Date:   2018-09-23T22:03:40Z

IGNITE-9282: Add test checker

commit 3b05686321c77f0c36aaefe9757dbf43d04e0d8c
Author: dehasi 
Date:   2018-09-24T17:02:31Z

IGNITE-9282: compute variances

commit d2b42f94f9e2c4ff107457c5c0e39f3cfad738ee
Author: dehasi 
Date:   2018-09-24T17:22:26Z

IGNITE-9282: fix variance calc

commit 664b175f4d817ea17b5ede96bd8956978dbab3a6
Author: dehasi 
Date:   2018-09-24T18:54:01Z

IGNITE-9282: Add java docs to model

commit 4730a24d4594f6a77a1cfd9682b5bd911f9d6210
Author: dehasi 
Date:   2018-09-24T19:12:48Z

IGNITE-9282: Add java docs to trainer

commit 6982b4d5cfac77d118e7d922a292f0c2814383bf
Author: dehasi 
Date:   2018-09-24T19:12:59Z

IGNITE-9282: Add java docs to trainer

commit 8337b890ca2916566dda7f58ff31222b5d0b920c
Author: dehasi 
Date:   2018-09-24T19:23:30Z

IGNITE-9282: Add a test to check variance

commit c6e5eb2d11b3fff3ceac25769df5471c879bd5b9
Author: dehasi 
Date:   2018-09-24T19:43:52Z

Merge branch 'master' into feature/ignite-9282-naive-bayes

commit fdcf94ac8286c0212fd537982adf4369e704dfaa
Author: dehasi 
Date:   2018-09-24T20:30:11Z

IGNITE-9282: Add Naive Bayes Example

commit aa76b8dcc00f17d49627e0717318fa1ce0d1cac1
Author: dehasi 
Date:   2018-09-26T16:47:56Z

IGNITE-9282: Use double instead of object

commit 5ae89d1415b775f287cba371e37627129fd19fa6
Author: dehasi 
Date:   2018-09-26T16:55:01Z

IGNITE-9282: Use TrainerTest

commit 17b39e8a64b3d2c89411ffc0d3742af7cf816d84
Author: dehasi 
Date:   2018-09-26T17:56:08Z

IGNITE-9282: Use array instead of vector

commit 23fec409973d2635e9556fa8de3b21bb80067f65
Author: dehasi 
Date:   2018-09-26T18:01:07Z

IGNITE-9282: Add abitily to set class probabilities

commit a5021023bbe07ec5740e6b91085a631cb3f9d3ca
Author: dehasi 
Date:   2018-09-26T18:19:31Z

IGNITE-9282: Add abitily to set class probabilities

commit a5faf74b28ae3a7ea0a456a67d4fae7e7f16d66b
Author: dehasi 
Date:   2018-09-26T18:25:20Z

IGNITE-9282: Fix model test

commit 23b6ebc51416e6fafb92580046f4837c750a0cd2
Author: dehasi 
Date:   2018-09-26T18:32:36Z

IGNITE-9282: Update trainer setters

commit 92dabe2ec6f4bf6599e23db2f17c1a9fab5c4020
Author: dehasi 
Date:   2018-09-26T18:42:05Z

IGNITE-9282: Add wikipedia dataset test

commit 71a10b041faac953ea8a874561210f1299441a76
Author: dehasi 
Date:   2018-09-26T19:08:23Z

IGNITE-9282: Add scikit learn dataset test




---

Re: Critical worker threads liveness checking drawbacks

[Yakov Zhdanov]

Config option + mbean access. Does that make sense?

Yakov

On Fri, Sep 28, 2018, 17:17 Vladimir Ozerov  wrote:

> Then it should be config option.
>
> пт, 28 сент. 2018 г. в 13:15, Andrey Gura :
>
> > Guys,
> >
> > why we need both config option and system property? I believe one way is
> > enough.
> > On Fri, Sep 28, 2018 at 12:38 PM Nikolay Izhikov 
> > wrote:
> > >
> > > Ticket created - https://issues.apache.org/jira/browse/IGNITE-9737
> > >
> > > Fixed version is 2.7.
> > >
> > > В Пт, 28/09/2018 в 11:41 +0300, Alexey Goncharuk пишет:
> > > > Nikolay, I agree, a user should be able to disable both thread
> liveness
> > > > check and checkpoint read lock timeout check from config and a system
> > > > property.
> > > >
> > > > пт, 28 сент. 2018 г. в 11:30, Nikolay Izhikov :
> > > >
> > > > > Hello, Igniters.
> > > > >
> > > > > I found that this feature can't be disabled from config.
> > > > > The only way to disable it is from JMX bean.
> > > > >
> > > > > I think it very dangerous: If we have some corner case or a bug in
> > this
> > > > > Watch Dog it can make Ignite unusable.
> > > > > I propose to implement possibility to disable this feature both -
> > from
> > > > > config and from JVM options.
> > > > >
> > > > > What do you think?
> > > > >
> > > > > В Чт, 27/09/2018 в 16:14 +0300, Andrey Kuznetsov пишет:
> > > > > > Maxim,
> > > > > >
> > > > > > Thanks for being attentive! It's definitely a typo. Could you
> > please
> > > > >
> > > > > create
> > > > > > an issue?
> > > > > >
> > > > > > чт, 27 сент. 2018 г. в 16:00, Maxim Muzafarov <
> maxmu...@gmail.com
> > >:
> > > > > >
> > > > > > > Folks,
> > > > > > >
> > > > > > > I've found in `GridCachePartitionExchangeManager:2684` [1]
> > (master
> > > > >
> > > > > branch)
> > > > > > > exchange future wrapped
> > > > > > > with double `blockingSectionEnd` method. Is it correct? I just
> > want to
> > > > > > > understand this change and
> > > > > > > how should I use this in the future.
> > > > > > >
> > > > > > > Should I file a new issue to fix this? I think here
> > > > >
> > > > > `blockingSectionBegin`
> > > > > > > method should be used.
> > > > > > >
> > > > > > > -
> > > > > > > blockingSectionEnd();
> > > > > > >
> > > > > > > try {
> > > > > > > resVer = exchFut.get(exchTimeout, TimeUnit.MILLISECONDS);
> > > > > > > } finally {
> > > > > > > blockingSectionEnd();
> > > > > > > }
> > > > > > >
> > > > > > >
> > > > > > > [1]
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> >
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCachePartitionExchangeManager.java#L2684
> > > > > > >
> > > > > > > On Wed, 26 Sep 2018 at 22:47 Vyacheslav Daradur <
> > daradu...@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Andrey Gura, thank you for the answer!
> > > > > > > >
> > > > > > > > I agree that wrapping of 'init' method reduces the profit of
> > watchdog
> > > > > > > > service in case of PME worker, but in other cases, we should
> > wrap all
> > > > > > > > possible long sections on GridDhtPartitionExchangeFuture. For
> > example
> > > > > > > > 'onCacheChangeRequest' method or
> > > > > > > > 'cctx.affinity().onCacheChangeRequest' inside because it may
> > take
> > > > > > > > significant time (reproducer attached).
> > > > > > > >
> > > > > > > > I only want to point out a possible issue which may allow to
> > end-user
> > > > > > > > halt the Ignite cluster accidentally.
> > > > > > > >
> > > > > > > > I'm sure that PME experts know how to fix this issue
> properly.
> > > > > > > > On Wed, Sep 26, 2018 at 10:28 PM Andrey Gura <
> ag...@apache.org
> > >
> > > > >
> > > > > wrote:
> > > > > > > > >
> > > > > > > > > Vyacheslav,
> > > > > > > > >
> > > > > > > > > Exchange worker is strongly tied with
> > > > > > > > > GridDhtPartitionExchangeFuture#init and it is ok. Exchange
> > worker
> > > > >
> > > > > also
> > > > > > > > > shouldn't be blocked for long time but in reality it
> > happens.It
> > > > >
> > > > > also
> > > > > > > > > means that your change doesn't make sense.
> > > > > > > > >
> > > > > > > > > What actually make sense it is identification of places
> which
> > > > > > > > > intentionally blocking. May be some places/actions should
> be
> > > > >
> > > > > braced by
> > > > > > > > > blocking guards.
> > > > > > > > >
> > > > > > > > > If you have failing tests please make sure that your
> > > > >
> > > > > failureHandler is
> > > > > > > > > NoOpFailureHandler or any other handler with
> > ignoreFailureTypes =
> > > > > > > > > [CRITICAL_WORKER_BLOCKED].
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Wed, Sep 26, 2018 at 9:43 PM Vyacheslav Daradur <
> > > > > > >
> > > > > > > daradu...@gmail.com>
> > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Igniters!
> > > > > > > > > >
> > > > > > > > > > Thank you for this important improvement!
> > > > > > > > > >
> > > > > > > > > > I've looked thr

[MTCGA]: new failures in builds [1956989] needs to be handled

[dpavlov . tasks]

Hi Igniters,

 I've detected some new issue on TeamCity to be handled. You are more than 
welcomed to help.

 If your changes can lead to this failure(s): We're grateful that you were a 
volunteer to make the contribution to this project, but things change and you 
may no longer be able to finalize your contribution.
 Could you respond to this email and indicate if you wish to continue and fix 
test failures or step down and some committer may revert you commit. 

 *Recently contributed test failed in master 
HadoopIgfs20FileSystemShmemPrimarySelfTest.testRenameIfSrcPathIsAlreadyBeingOpenedToRead
 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-372293035920618304&branch=%3Cdefault%3E&tab=testDetails
 Changes may lead to failure were done by 
 - git 
http://ci.ignite.apache.org/viewModification.html?modId=832984&personal=false
 - ptupitsyn 
http://ci.ignite.apache.org/viewModification.html?modId=832978&personal=false
 - dmitriy.govorukhin 
http://ci.ignite.apache.org/viewModification.html?modId=832968&personal=false
 - polyakov.alexandr.alexandrovich 
http://ci.ignite.apache.org/viewModification.html?modId=832950&personal=false
 - eshangareev 
http://ci.ignite.apache.org/viewModification.html?modId=832941&personal=false

 - Here's a reminder of what contributors were agreed to do 
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute 
 - Should you have any questions please contact dev@ignite.apache.org 

Best Regards,
Apache Ignite TeamCity Bot 
https://github.com/apache/ignite-teamcity-bot
Notification generated at 17:16:52 28-09-2018 

Re: [MTCGA]: new failures in builds [1956989] needs to be handled

[Dmitriy Pavlov]

Hi, this failure does not seem to be a new failure.

This test was recently unmuted, and the Bot considers it as new.

Sincerely,
Dmitriy Pavlov

пт, 28 сент. 2018 г. в 17:17, :

> Hi Igniters,
>
>  I've detected some new issue on TeamCity to be handled. You are more than
> welcomed to help.
>
>  If your changes can lead to this failure(s): We're grateful that you were
> a volunteer to make the contribution to this project, but things change and
> you may no longer be able to finalize your contribution.
>  Could you respond to this email and indicate if you wish to continue and
> fix test failures or step down and some committer may revert you commit.
>
>  *Recently contributed test failed in master
> HadoopIgfs20FileSystemShmemPrimarySelfTest.testRenameIfSrcPathIsAlreadyBeingOpenedToRead
>
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-372293035920618304&branch=%3Cdefault%3E&tab=testDetails
>  Changes may lead to failure were done by
>  - git
> http://ci.ignite.apache.org/viewModification.html?modId=832984&personal=false
>  - ptupitsyn
> http://ci.ignite.apache.org/viewModification.html?modId=832978&personal=false
>  - dmitriy.govorukhin
> http://ci.ignite.apache.org/viewModification.html?modId=832968&personal=false
>  - polyakov.alexandr.alexandrovich
> http://ci.ignite.apache.org/viewModification.html?modId=832950&personal=false
>  - eshangareev
> http://ci.ignite.apache.org/viewModification.html?modId=832941&personal=false
>
>  - Here's a reminder of what contributors were agreed to do
> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
>  - Should you have any questions please contact
> dev@ignite.apache.org
>
> Best Regards,
> Apache Ignite TeamCity Bot
> https://github.com/apache/ignite-teamcity-bot
> Notification generated at 17:16:52 28-09-2018
>

[GitHub] ignite pull request #4870: Ignite 9171 for tests

[tledkov-gridgain]

GitHub user tledkov-gridgain opened a pull request:

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

Ignite 9171 for tests



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

$ git pull https://github.com/gridgain/apache-ignite ignite-9171-1

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

https://github.com/apache/ignite/pull/4870.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 #4870


commit cc434c2a158d2b43cdef8e5f8f880aa33bce3413
Author: Pavel Kuznetsov 
Date:   2018-08-10T18:41:36Z

Support to run multiply benchmark drivers.

commit 99b5e863039f5db7c8c8cbae94ef571653e4bdbb
Author: tledkov-gridgain 
Date:   2018-08-14T12:32:01Z

IGNITE-9171: save the progress

commit 42d274aec851436343b3d7648112234c44abb8cc
Author: tledkov-gridgain 
Date:   2018-08-14T13:20:06Z

Merge branch '_master' into ignite-9171

commit 7e479f79efd211a245ad35753d87bee3de554964
Author: tledkov-gridgain 
Date:   2018-08-15T10:13:31Z

IGNITE-9171: save the progress

commit b178d88d4afffbf6f79b62a74253ff47064e06aa
Author: tledkov-gridgain 
Date:   2018-08-15T13:39:25Z

IGNITE-9171: save the progress

commit 39233fb7fea48e1d527f6fd7ebf78f619ee4b0ef
Author: tledkov-gridgain 
Date:   2018-08-16T08:59:18Z

IGNITE-9171: save the progress

commit 6728f667f6423fd73f9869f0dde795405f9f3834
Author: tledkov-gridgain 
Date:   2018-08-16T09:11:46Z

IGNITE-9171: fix unlock H2 table

commit 5a80d3b17ac702461fec8cb1e6224ddc4a5814f3
Author: tledkov-gridgain 
Date:   2018-08-16T10:32:02Z

IGNITE-9171: fix connection management

commit 712099d1d94696ec451fe81220fcf4e3b19ad87f
Author: tledkov-gridgain 
Date:   2018-08-16T11:56:53Z

IGNITE-9171: fix statement cache test

commit 2c1a2fb3ce77ca518eff2bb9a13a5cbe74618f23
Author: tledkov-gridgain 
Date:   2018-08-16T12:47:21Z

Merge branch '_master' into ignite-9171

commit 0bb7127724fe66236f3d657e03fa1f4d42b7df33
Author: tledkov-gridgain 
Date:   2018-08-16T13:32:10Z

IGNITE-9171: add benchmarks

commit 77e9faed6d019863321556aee4f1c703395f8c64
Author: tledkov-gridgain 
Date:   2018-08-16T14:01:40Z

IGNITE-9171: fix statement cancel

commit b3a5e2b2ac6d95aa49b1792c4f8be4a00cf8f84d
Author: tledkov-gridgain 
Date:   2018-08-16T15:24:48Z

IGNITE-9171: fix: recycle connection of node stop

commit 3f8d5878c949e82e2ce341a52bf882d743919a6f
Author: tledkov-gridgain 
Date:   2018-08-16T15:57:33Z

Merge branch '_master' into ignite-9171

commit a5cc353b7f5495d52c688d38bbd1ce8fc95e6010
Author: tledkov-gridgain 
Date:   2018-08-16T16:09:40Z

IGNITE-9171: minors

commit 296dbbe1c45575dd429ed989d7204ed98d8239ae
Author: tledkov-gridgain 
Date:   2018-08-17T13:30:09Z

Merge branch '_master' into ignite-9171

commit 734871dadca8fb1bfe73b02bf9597a2626ed0aa3
Author: tledkov-gridgain 
Date:   2018-08-17T13:41:33Z

IGNITE-9171: change default value for 'lazy'

commit 8296bdcd1f2af44880e25d081e343a9ce7bc726e
Author: tledkov-gridgain 
Date:   2018-08-17T14:24:15Z

IGNITE-9171: modify tests according with:
change default value for 'lazy' mode to 'true'

commit dcd8b8c0b36766a015b19cda539d3a97f1acf7c9
Author: tledkov-gridgain 
Date:   2018-08-17T15:51:27Z

IGNITE-9171: fix benchmark for multi-client config

commit c66c89d851df7d27a67422ff67c1b04dd1e87402
Author: tledkov-gridgain 
Date:   2018-08-20T09:09:37Z

IGNITE-9171: change lazy flag default at the benchmarks

commit f265d5360752c0903f1cfa0712cad2eb7e154b5e
Author: tledkov-gridgain 
Date:   2018-08-20T09:14:19Z

Merge branch 'master' into ignite-9171

# Conflicts:
#   
modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/IgniteH2Indexing.java

commit 8c9491911182385219334825f0f83ae326424ba6
Author: Igor Sapego 
Date:   2018-08-20T15:39:59Z

IGNITE-9171: Changed ODBC default "lazy" value to "true"

commit 2b13d2b6eddea44013d5c6975aa1f42f2bae5637
Author: Igor Sapego 
Date:   2018-08-20T15:44:52Z

IGNITE-9171: Tests fixed.

commit 4f60c94088466a5c3a34ddb4b59a420680f615c3
Author: Igor Sapego 
Date:   2018-08-21T13:18:30Z

IGNITE-9171: Changed default lazy value for C++

commit 50008bf12c7a790828264388871b2e211facf5b5
Author: tledkov-gridgain 
Date:   2018-08-21T13:30:13Z

Merge branch 'master' into ignite-9171

commit 2cad898bf063392cc69c777a300a0aececcc92ad
Author: tledkov-gridgain 
Date:   2018-08-21T13:31:14Z

Merge remote-tracking branch 'professional/ignite-9171' into ignite-9171

commit a414b690721138050feac9b268f6f6a324b28622
Author: tledkov-gridgain 
Date:   2018-08-21T13:43:26Z

IGNITE-9171: change default lazy mode at .net

commit 2b0b6d2ce299f7b134697a48d36cffe54c7da720
Author: tledkov-gridgain 
Date:   2018-08-21T16:20:48Z

IGNITE-9171: fix table lock

commit 3511d13685f2397ef170375a468275b149c15500
Author: tledkov-gridgain 
Date:   2018-08-21T16:22:43Z

[MTCGA]: new failures in builds [1956991] needs to be handled

[dpavlov . tasks]

Hi Igniters,

 I've detected some new issue on TeamCity to be handled. You are more than 
welcomed to help.

 If your changes can lead to this failure(s): We're grateful that you were a 
volunteer to make the contribution to this project, but things change and you 
may no longer be able to finalize your contribution.
 Could you respond to this email and indicate if you wish to continue and fix 
test failures or step down and some committer may revert you commit. 

 *Recently contributed test failed in master 
HadoopIgfs20FileSystemLoopbackPrimarySelfTest.testRenameIfSrcPathIsAlreadyBeingOpenedToRead
 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-4905677460839115045&branch=%3Cdefault%3E&tab=testDetails

 *Recently contributed test failed in master 
IgniteHadoopFileSystemLoopbackEmbeddedPrimarySelfTest.testRenameIfSrcPathIsAlreadyBeingOpenedToRead
 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-1872512020562914340&branch=%3Cdefault%3E&tab=testDetails

 *Recently contributed test failed in master 
IgniteHadoopFileSystemClientBasedPrimarySelfTest.testRenameIfSrcPathIsAlreadyBeingOpenedToRead
 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-7411207899514584623&branch=%3Cdefault%3E&tab=testDetails
 Changes may lead to failure were done by 
 - git 
http://ci.ignite.apache.org/viewModification.html?modId=832984&personal=false
 - ptupitsyn 
http://ci.ignite.apache.org/viewModification.html?modId=832978&personal=false
 - dmitriy.govorukhin 
http://ci.ignite.apache.org/viewModification.html?modId=832968&personal=false
 - polyakov.alexandr.alexandrovich 
http://ci.ignite.apache.org/viewModification.html?modId=832950&personal=false
 - eshangareev 
http://ci.ignite.apache.org/viewModification.html?modId=832941&personal=false

 - Here's a reminder of what contributors were agreed to do 
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute 
 - Should you have any questions please contact dev@ignite.apache.org 

Best Regards,
Apache Ignite TeamCity Bot 
https://github.com/apache/ignite-teamcity-bot
Notification generated at 17:47:22 28-09-2018 

[GitHub] ignite pull request #4858: IGNITE-9687: update dependencies

[asfgit]

Github user asfgit closed the pull request at:

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


---

[jira] [Created] (IGNITE-9738) Client node can suddenly fail on start

[Vladislav Pyatkov (JIRA)]

Vladislav Pyatkov created IGNITE-9738:
-

 Summary: Client node can suddenly fail on start
 Key: IGNITE-9738
 URL: https://issues.apache.org/jira/browse/IGNITE-9738
 Project: Ignite
  Issue Type: Bug
Reporter: Vladislav Pyatkov


If client joining to large topology it can to spend some time on waiting 
{{TcpDiscoveryNodeAddFinishedMessage}}, but in that time it can not to send 
{{TcpDiscoveryClientMetricsUpdateMessage.}} By that reason server can to reset 
client from topology.

We should to sent {{TcpDiscoveryClientMetricsUpdateMessage as soon as 
possible}} without, waiting finish of join procedure.



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

Re: [MTCGA]: new failures in builds [1956991] needs to be handled

[Dmitriy Pavlov]

Hi,

These tests were recently unmuted, but not contributed. I would appreciate
if someone can provide more info why these tests were unmuted.

Sincerely,
Dmitriy Pavlov

пт, 28 сент. 2018 г. в 17:47, :

> Hi Igniters,
>
>  I've detected some new issue on TeamCity to be handled. You are more than
> welcomed to help.
>
>  If your changes can lead to this failure(s): We're grateful that you were
> a volunteer to make the contribution to this project, but things change and
> you may no longer be able to finalize your contribution.
>  Could you respond to this email and indicate if you wish to continue and
> fix test failures or step down and some committer may revert you commit.
>
>  *Recently contributed test failed in master
> HadoopIgfs20FileSystemLoopbackPrimarySelfTest.testRenameIfSrcPathIsAlreadyBeingOpenedToRead
>
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-4905677460839115045&branch=%3Cdefault%3E&tab=testDetails
>
>  *Recently contributed test failed in master
> IgniteHadoopFileSystemLoopbackEmbeddedPrimarySelfTest.testRenameIfSrcPathIsAlreadyBeingOpenedToRead
>
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-1872512020562914340&branch=%3Cdefault%3E&tab=testDetails
>
>  *Recently contributed test failed in master
> IgniteHadoopFileSystemClientBasedPrimarySelfTest.testRenameIfSrcPathIsAlreadyBeingOpenedToRead
>
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-7411207899514584623&branch=%3Cdefault%3E&tab=testDetails
>  Changes may lead to failure were done by
>  - git
> http://ci.ignite.apache.org/viewModification.html?modId=832984&personal=false
>  - ptupitsyn
> http://ci.ignite.apache.org/viewModification.html?modId=832978&personal=false
>  - dmitriy.govorukhin
> http://ci.ignite.apache.org/viewModification.html?modId=832968&personal=false
>  - polyakov.alexandr.alexandrovich
> http://ci.ignite.apache.org/viewModification.html?modId=832950&personal=false
>  - eshangareev
> http://ci.ignite.apache.org/viewModification.html?modId=832941&personal=false
>
>  - Here's a reminder of what contributors were agreed to do
> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
>  - Should you have any questions please contact
> dev@ignite.apache.org
>
> Best Regards,
> Apache Ignite TeamCity Bot
> https://github.com/apache/ignite-teamcity-bot
> Notification generated at 17:47:22 28-09-2018
>

[GitHub] ignite pull request #4831: IGNITE-9693 Add compression workers to scale up W...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] ignite pull request #4804: IGNITE-7251 Remove term "fabric" from Ignite deli...

[vveider]

Github user vveider closed the pull request at:

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


---

[GitHub] ignite pull request #4863: IGNITE-9731 hold segmentId on constructor of File...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] ignite pull request #4871: IGNITE-9727: fix ignite.sh & ignite.bat start scr...

[tledkov-gridgain]

GitHub user tledkov-gridgain opened a pull request:

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

IGNITE-9727: fix ignite.sh & ignite.bat start scripts for JDK 9/10/11



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

$ git pull https://github.com/gridgain/apache-ignite ignite-9727

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

https://github.com/apache/ignite/pull/4871.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 #4871


commit 79d170c61bb1614d92b47a42dba8d539a4cc85a2
Author: tledkov-gridgain 
Date:   2018-09-28T12:31:16Z

IGNITE-9727: fix ignite.sh & ignite.bat start scripts for JDK 9/10/11




---

[jira] [Created] (IGNITE-9739) Critical exception in transaction processing in case we have nodes out of baseline and non-persisted cache

[Sergey Kosarev (JIRA)]

Sergey Kosarev created IGNITE-9739:
--

 Summary: Critical exception in transaction processing in case we 
have nodes out of baseline and non-persisted cache
 Key: IGNITE-9739
 URL: https://issues.apache.org/jira/browse/IGNITE-9739
 Project: Ignite
  Issue Type: Bug
Reporter: Sergey Kosarev



Activation finished 
{code}
2018-09-20 20:47:05.169 [INFO 
][sys-#307%DPL_GRID%DplGridNodeName%][o.g.g.i.p.c.d.GridSnapshotAwareClusterStateProcessorImpl]
 Successfully performed final activation steps 
[nodeId=382437eb-fd8a-4f92-acd5-d9ea562c8557, client=false, 
topVer=AffinityTopologyVersion [topVer=160, minorTopVer=1]]
{code}

but we have nodes not in base line
{code}
2018-09-20 20:45:36.116 [INFO 
][sys-#305%DPL_GRID%DplGridNodeName%][o.g.g.i.p.c.d.GridSnapshotAwareClusterStateProcessorImpl]
 Local node is not included in Baseline Topology and will not be used for 
persistent data storage. Use control.(sh|bat) script or IgniteCluster interface 
to include the node to Baseline Topology.
{code}

And we have cache in the data region with persistanceEnabled=false
{code}
2018-09-20 20:49:01.825 [INFO 
][exchange-worker-#154%DPL_GRID%DplGridNodeName%][o.a.i.i.p.cache.GridCacheProcessor]
 Started cache [name=DPL_PUBLISHED_CACHES_REGISTRY$, *id=869481129*, group=SY
STEM_CACHEGROUP_PUBLISHED_REGISTRY, memoryPolicyName=not-persisted, 
mode=PARTITIONED, atomicity=TRANSACTIONAL, backups=3]
{code}

Transaction on this cache leads to critical error causing nodes by faulure 
handler:
{code}
2018-09-20 20:50:24.275 
[ERROR][sys-stripe-41-#42%DPL_GRID%DplGridNodeName%][o.a.i.i.p.cache.GridCacheIoManager]
 Failed processing message [senderId=62e986f0-62b5-4ec8-8cc7-27b74d345235, 
msg=GridDhtTxPrepareRequest [nearNodeId=814af7c4-2de5-4511-b1ea-065b91eaa774, 
futId=520e308f561-255fdea5-a996-4102-a120-afa380c54570, miniId=1, 
topVer=AffinityTopologyVersion [topVer=160, minorTopVer=2], 
invalidateNearEntries={}, nearWrites=null, owned=null, 
nearXidVer=GridCacheVersion [topVer=148944365, order=1537511036821, 
nodeOrder=132], subjId=814af7c4-2de5-4511-b1ea-065b91eaa774, taskNameHash=0, 
preloadKeys=null, skipCompletedVers=false, 
super=GridDistributedTxPrepareRequest [threadId=58, concurrency=PESSIMISTIC, 
isolation=READ_COMMITTED, writeVer=GridCacheVersion [topVer=148944365, 
order=1537511036824, nodeOrder=7], timeout=299970, reads=null, writes=ArrayList 
[

IgniteTxEntry [key=KeyCacheObjectImpl [part=27254, 
val=com.sbt.api.entities.out.IPublishedDocType, hasValBytes=true], 
*cacheId=869481129*,
txKey=IgniteTxKey [key=KeyCacheObjectImpl [part=27254, 
val=com.sbt.api.entities.out.IPublishedDocType, hasValBytes=true], 
*cacheId=869481129*], val=[op=CREATE, 
val=com.sbt.dpl.gridgain.PublishedRegistry$PublishedCacheTuple 
[idHash=811765531, hash=1522508040, 
cacheName=com.sbt.gbk.entities.DocType_DPL_union-module,indexes=ArrayList 
{com.sbt.dpl.gridgain.newModel.base.indexes.PublishedIndexType
[idHash=1583970836, hash=363194492, isSoftReference=false, 
unselectiveBuckets=4096, fieldNames=ArrayList {isDeleted},
moduleName=union-module
, cachedUnselectives=1, selectors=ArrayList {isDeleted}, 
exceptUnselectives=false, primitiveCollection=false, isVersioned=false, 
isComposite=false, isSystemTypeBelongs=false,
name=com.sbt.gbk.entities.DocType_DPL_isDeleted, isIndexedCollection=false, 
isGlobal=false, maxSelective=1000], 
com.sbt.dpl.gridgain.newModel.base.indexes.PublishedIndexType
[idHash=2060926101, hash=1983794578, isSoftReference=false, 
unselectiveBuckets=4096, fieldNames=ArrayList {code},moduleName=union-module, 
cachedUnselectives=1, selectors=ArrayList {code}, exceptUnselectives=false, 
primitiveCollection=false, isVersioned=false, isComposite=false, 
isSystemTypeBelongs=false, name=com.sbt.gbk.entities.DocType_DPL_code, 
isIndexedCollection=false, isGlobal=true, maxSelective=1000]
, com.sbt.dpl.gridgain.newModel.base.indexes.PublishedIndexType
[idHash=1821682714, hash=-1245813786, isSoftReference=false, 
unselectiveBuckets=4096, fieldNames=ArrayList {globalId},
moduleName=union-module, cachedUnselectives=1, selectors=ArrayList 
{globalId}, exceptUnselectives=false, primitiveCollection=false, 
isVersioned=false, isComposite=false, isSystemTypeBelongs=false,
name=com.sbt.gbk.entities.DocType_DPL_globalId, isIndexedCollection=false, 
isGlobal=false, maxSelective=1000]
}, partitionDependencyClassName=null, moduleName=union-module, 
cacheModuleName=union-module]
], prevVal=[op=NOOP, val=null], oldVal=[op=NOOP, val=null], 
entryProcessorsCol=null, ttl=-1, conflictExpireTime=-1, conflictVer=null, 
explicitVer=null, dhtVer=null, filters=CacheEntryPredicate[] [], 
filtersPassed=false, filtersSet=false, entry=GridCacheMapEntry 
[key=KeyCacheObjectImpl [part=27254, 
val=com.sbt.api.entities.out.IPublishedDocType, hasValBytes=true], val=null, 
startVer=1537511036806, ver=GridCacheVersion [topVer=148944365, 
order=1537511

Re: Critical worker threads liveness checking drawbacks

[Maxim Muzafarov]

Andrey, Andrey

> Thanks for being attentive! It's definitely a typo. Could you please
create
> an issue?

I've created an issue [1] and prepared PR [2].
Please, review this change.

[1] https://issues.apache.org/jira/browse/IGNITE-9723
[2] https://github.com/apache/ignite/pull/4862

On Fri, 28 Sep 2018 at 16:58 Yakov Zhdanov  wrote:

> Config option + mbean access. Does that make sense?
>
> Yakov
>
> On Fri, Sep 28, 2018, 17:17 Vladimir Ozerov  wrote:
>
> > Then it should be config option.
> >
> > пт, 28 сент. 2018 г. в 13:15, Andrey Gura :
> >
> > > Guys,
> > >
> > > why we need both config option and system property? I believe one way
> is
> > > enough.
> > > On Fri, Sep 28, 2018 at 12:38 PM Nikolay Izhikov 
> > > wrote:
> > > >
> > > > Ticket created - https://issues.apache.org/jira/browse/IGNITE-9737
> > > >
> > > > Fixed version is 2.7.
> > > >
> > > > В Пт, 28/09/2018 в 11:41 +0300, Alexey Goncharuk пишет:
> > > > > Nikolay, I agree, a user should be able to disable both thread
> > liveness
> > > > > check and checkpoint read lock timeout check from config and a
> system
> > > > > property.
> > > > >
> > > > > пт, 28 сент. 2018 г. в 11:30, Nikolay Izhikov  >:
> > > > >
> > > > > > Hello, Igniters.
> > > > > >
> > > > > > I found that this feature can't be disabled from config.
> > > > > > The only way to disable it is from JMX bean.
> > > > > >
> > > > > > I think it very dangerous: If we have some corner case or a bug
> in
> > > this
> > > > > > Watch Dog it can make Ignite unusable.
> > > > > > I propose to implement possibility to disable this feature both -
> > > from
> > > > > > config and from JVM options.
> > > > > >
> > > > > > What do you think?
> > > > > >
> > > > > > В Чт, 27/09/2018 в 16:14 +0300, Andrey Kuznetsov пишет:
> > > > > > > Maxim,
> > > > > > >
> > > > > > > Thanks for being attentive! It's definitely a typo. Could you
> > > please
> > > > > >
> > > > > > create
> > > > > > > an issue?
> > > > > > >
> > > > > > > чт, 27 сент. 2018 г. в 16:00, Maxim Muzafarov <
> > maxmu...@gmail.com
> > > >:
> > > > > > >
> > > > > > > > Folks,
> > > > > > > >
> > > > > > > > I've found in `GridCachePartitionExchangeManager:2684` [1]
> > > (master
> > > > > >
> > > > > > branch)
> > > > > > > > exchange future wrapped
> > > > > > > > with double `blockingSectionEnd` method. Is it correct? I
> just
> > > want to
> > > > > > > > understand this change and
> > > > > > > > how should I use this in the future.
> > > > > > > >
> > > > > > > > Should I file a new issue to fix this? I think here
> > > > > >
> > > > > > `blockingSectionBegin`
> > > > > > > > method should be used.
> > > > > > > >
> > > > > > > > -
> > > > > > > > blockingSectionEnd();
> > > > > > > >
> > > > > > > > try {
> > > > > > > > resVer = exchFut.get(exchTimeout, TimeUnit.MILLISECONDS);
> > > > > > > > } finally {
> > > > > > > > blockingSectionEnd();
> > > > > > > > }
> > > > > > > >
> > > > > > > >
> > > > > > > > [1]
> > > > > > > >
> > > > > > > >
> > > > > >
> > > > > >
> > >
> >
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCachePartitionExchangeManager.java#L2684
> > > > > > > >
> > > > > > > > On Wed, 26 Sep 2018 at 22:47 Vyacheslav Daradur <
> > > daradu...@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Andrey Gura, thank you for the answer!
> > > > > > > > >
> > > > > > > > > I agree that wrapping of 'init' method reduces the profit
> of
> > > watchdog
> > > > > > > > > service in case of PME worker, but in other cases, we
> should
> > > wrap all
> > > > > > > > > possible long sections on GridDhtPartitionExchangeFuture.
> For
> > > example
> > > > > > > > > 'onCacheChangeRequest' method or
> > > > > > > > > 'cctx.affinity().onCacheChangeRequest' inside because it
> may
> > > take
> > > > > > > > > significant time (reproducer attached).
> > > > > > > > >
> > > > > > > > > I only want to point out a possible issue which may allow
> to
> > > end-user
> > > > > > > > > halt the Ignite cluster accidentally.
> > > > > > > > >
> > > > > > > > > I'm sure that PME experts know how to fix this issue
> > properly.
> > > > > > > > > On Wed, Sep 26, 2018 at 10:28 PM Andrey Gura <
> > ag...@apache.org
> > > >
> > > > > >
> > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > Vyacheslav,
> > > > > > > > > >
> > > > > > > > > > Exchange worker is strongly tied with
> > > > > > > > > > GridDhtPartitionExchangeFuture#init and it is ok.
> Exchange
> > > worker
> > > > > >
> > > > > > also
> > > > > > > > > > shouldn't be blocked for long time but in reality it
> > > happens.It
> > > > > >
> > > > > > also
> > > > > > > > > > means that your change doesn't make sense.
> > > > > > > > > >
> > > > > > > > > > What actually make sense it is identification of places
> > which
> > > > > > > > > > intentionally blocking. May be some places/actions should
> > be
> > > > > >
> > > > > > braced by
> > > > > > > > > > blocking

[GitHub] ignite pull request #4864: IGNITE-9612 test fix

[ascherbakoff]

Github user ascherbakoff closed the pull request at:

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


---

[GitHub] ignite pull request #4872: IGNITE-1436: Build C++ API on the Mac

[sdarlington]

GitHub user sdarlington opened a pull request:

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

IGNITE-1436: Build C++ API on the Mac

Creating PR to 'advertise' that it's being worked on. Tasks still to 
complete:

* Test on Linux / Windows to make sure I've not broken anything
* Final step in build: need to `install_name_tool -add_rpath 
$(JAVA_HOME)/jre/lib/server ignite` but I've not found a way to automate that
* Tests, ODBC driver and thin-client don't currently build

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

$ git pull https://github.com/sdarlington/ignite cpp-mac

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

https://github.com/apache/ignite/pull/4872.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 #4872


commit 46a923720f64c8e920ff53d807f9c42d2b9270ef
Author: Stephen Darlington 
Date:   2018-09-25T12:52:30Z

Get past missing CLOCK_MONOTONIC on Macs error

commit 2707b263f27fd708b5525df0eb3b4398203f7549
Author: Stephen Darlington 
Date:   2018-09-25T14:08:47Z

Set right headers to allow Mac compile of C++ client

commit 0ee352f012ef7a802b52a1e9bfba7fb96ba3a335
Author: Stephen Darlington 
Date:   2018-09-25T14:34:53Z

Mac dynamic libraries are not '.so' files

commit 249588f2525c7c5b7588f01f02db876264d6df0c
Author: Stephen Darlington 
Date:   2018-09-28T16:03:06Z

Update DEVNOTES




---

[GitHub] ignite pull request #3212: IGNITE-6343: Index is not used properly if changi...

[rkondakov]

Github user rkondakov closed the pull request at:

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


---

[GitHub] ignite pull request #4873: IGNITE-5935: MVCC transaction recovery

[pavlukhin]

GitHub user pavlukhin opened a pull request:

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

IGNITE-5935: MVCC transaction recovery



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

$ git pull https://github.com/gridgain/apache-ignite ignite-5935

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

https://github.com/apache/ignite/pull/4873.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 #4873


commit 77dc283027793bee8831fe75c8947a825f81a539
Author: ipavlukhin 
Date:   2018-09-28T14:50:59Z

accumulate backups participating in transaction in 
GridDistributedTxMapping, retrieve them from received enlist response

commit 781dab6e0a2068acaaf859f4848f35c52327cc4f
Author: ipavlukhin 
Date:   2018-09-28T15:14:11Z

GridDistributedTxMapping normalize null backups to empty list

commit 090d17e40e56f45258a5a3f27c4da6e065343ed9
Author: ipavlukhin 
Date:   2018-09-28T15:32:01Z

pass backups to transaction mappings upon receiving response in 
GridNearTxEnlistFuture

commit 0d2446b27da80944d203cfd3c8a218a6904daa1c
Author: ipavlukhin 
Date:   2018-09-28T15:36:28Z

putIfAbsent -> put

commit 8d3eb13b40ba1bcd3fa70fa6af4c7af5ed521454
Author: ipavlukhin 
Date:   2018-09-28T15:48:16Z

remove outdated todo

commit 36a22a8b0ffc487dd47ab430057d185afdb81da9
Author: ipavlukhin 
Date:   2018-09-28T16:05:52Z

make backups in GridDistributedTxMapping thread-safe

commit 3ff50a1d2553d249f30858b478fc89986f344f8e
Author: ipavlukhin 
Date:   2018-09-28T16:07:41Z

add draft of a test




---

[GitHub] ignite pull request #4818: IGNITE-9451: Cache.size for key-value API

[pavlukhin]

Github user pavlukhin closed the pull request at:

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


---

[GitHub] ignite pull request #4874: IGNITE- 9658

[ascherbakoff]

GitHub user ascherbakoff opened a pull request:

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

IGNITE- 9658



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

$ git pull https://github.com/gridgain/apache-ignite ignite-9658-2

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

https://github.com/apache/ignite/pull/4874.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 #4874


commit 85a817c50347760f6d1264a4dcf39c7c2144b7fc
Author: Aleksei Scherbakov 
Date:   2018-09-28T07:59:43Z

IGNITE-9658 wip.

commit 991263cfdae6b8d2a4ec0a281088942ad00ac38b
Author: Aleksei Scherbakov 
Date:   2018-09-28T09:58:49Z

IGNITE-9658 wip.

commit 7b9df3ec28e200e6e3c9bc4447421592b6328571
Author: Aleksei Scherbakov 
Date:   2018-09-28T15:45:06Z

IGNITE-9658 wip.

commit df7e7a6d2f8460687702f17d99d7baa92f44729f
Author: Aleksei Scherbakov 
Date:   2018-09-28T16:19:24Z

IGNITE-9658 wip.

commit 40cd88f7227e5c7001b3ca40a19257558ccc08dc
Author: Aleksei Scherbakov 
Date:   2018-09-28T16:24:28Z

Merge branch 'master' of https://github.com/apache/ignite into ignite-9658




---

Re: Apache Ignite 2.7 release

[Dmitriy Setrakyan]

Dmitriy,

We agreed in the beginning of this thread that Service Grid changes are not
going to make the release because the community still did not approve the
design. Nothing has changed since. I have not seen any design discussions.
At this point, I have no confidence that the Service Grid changes will make
it into the 2.8 release. The 2.7 release seems out of question altogether.

Also, Nikolay is a release manager. We should let him drive the release. To
my knowledge, he is doing a great job and the release is going according to
the schedule he proposed.

D.

On Fri, Sep 28, 2018 at 4:31 AM Dmitriy Pavlov 
wrote:

> Hi Dmitriy, Vladimir,
>
> I suggest we stop this nonsense with release dates-pushing because of some
> open question.
>
> Just because you disagreed with any include/exclude something into scope,
> does not mean that whole community disagreed.
>
> If folks will start a separate discussion with results of the review, I see
> no reasons to reject their contribution, even if we need to revisit our
> agreements and wait for a couple of days more.
>
> Am I missing some reason why dates are so fundamentally important to you?
>
> Sincerely,
> Dmitriy Pavlov
>
> пт, 28 сент. 2018 г. в 12:20, Dmitriy Setrakyan :
>
> > If services is not ready, which it is not, then we should include them
> into
> > the next release. There is no need to force them into 2.7. I suggest we
> > move according to the schedule we all agreed on.
> >
> > D.
> >
> > On Fri, Sep 28, 2018 at 1:22 AM Dmitriy Pavlov 
> > wrote:
> >
> > > Yes, so correct statement is "community did not make any decisions
> about
> > > services not go to 2.7/ services are out of scope".
> > >
> > > If so, please forgive me my confusion.
> > >
> > > пт, 28 сент. 2018 г. в 11:19, Vladimir Ozerov :
> > >
> > > > Exactly. So correct statement is “it is up to *community* to decide
> > > whether
> > > > something goes to 2.7”.
> > > >
> > > > пт, 28 сент. 2018 г. в 11:11, Dmitriy Pavlov  >:
> > > >
> > > > > No, it is up to the community to discuss after their review
> results.
> > > > >
> > > > > пт, 28 сент. 2018 г. в 11:09, Vladimir Ozerov <
> voze...@gridgain.com
> > >:
> > > > >
> > > > > > Dmitriy,
> > > > > >
> > > > > > Did I read your words correctly that it is up to implementor of a
> > > > single
> > > > > > feature to decide whether release of all other features and fixes
> > to
> > > be
> > > > > > delayed?
> > > > > >
> > > > > > пт, 28 сент. 2018 г. в 11:00, Dmitriy Pavlov <
> > dpavlov@gmail.com
> > > >:
> > > > > >
> > > > > > > My point we can wait a bit for services because
> > > > > > > 1  we are open-minded and we don't have outside pressure to do
> > > > release
> > > > > in
> > > > > > > October
> > > > > > > 2  and services it is not some new feature, which suddenly
> > appeared
> > > > in
> > > > > > > autumn, it is a well known and important feature.
> > > > > > >
> > > > > > > So it is up to Vyacheslav, Anton and Nikolay to decide.
> > > > > > >
> > > > > > > Decisions can be services are not ready/ready to merge only to
> > > > > > master/ready
> > > > > > > to merge to master and to 2.7.
> > > > > > >
> > > > > > >
> > > > > > > пт, 28 сент. 2018 г. в 10:46, Vladimir Ozerov <
> > > voze...@gridgain.com
> > > > >:
> > > > > > >
> > > > > > > > Dmitry,
> > > > > > > >
> > > > > > > > Community agreement was to perform the release in October. Of
> > > > course
> > > > > we
> > > > > > > can
> > > > > > > > wait a bit for services. Then we wait a bit for other cool
> > > features
> > > > > > ready
> > > > > > > > by that time, then again and again, and release will never
> > > happen.
> > > > > And
> > > > > > > > while we are waiting for new features to come, already
> > completerd
> > > > > > > features
> > > > > > > > cannot be used by anyone.
> > > > > > > >
> > > > > > > > This is why we have an agreement that if feature is not
> ready,
> > it
> > > > > > should
> > > > > > > be
> > > > > > > > moved to future release, instead of shifting release. The
> sole
> > > > reason
> > > > > > to
> > > > > > > > have strict dates when decisions are made is to let release
> > > happen.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Fri, Sep 28, 2018 at 2:22 AM Dmitriy Pavlov <
> > > > > dpavlov@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Vladimir,  I'm not searching for enemy, and not fighting
> with
> > > > you.
> > > > > > I'm
> > > > > > > > not
> > > > > > > > > happy about cases when we are hurrying.
> > > > > > > > >
> > > > > > > > > We can't fix test, fill ticket details, can't wait for
> > > > > contributions
> > > > > > to
> > > > > > > > > finish their tasks.  It is not best idea to use experience
> > from
> > > > > > > > commercial
> > > > > > > > > companies in open source. Are there any pressure outside
> > > > community?
> > > > > > Did
> > > > > > > > > someone promised rest of features to be released at 30
> > > September?
> > > > > > > > >
> > > > > > > > > Let's re

Re: Apache Ignite 2.7 release

[Dmitriy Pavlov]

Hi Dmitriy,

The design is aligned totally. The thread you mention was not named
properly.

It seems to me some community members are trying to take over the community
and lead it instead of doing.

As a member of the Apache community, I value Do-ocracy and power of those
who do, but not just disagree. There are no leaders in open source, just
do'ers.

By do'ers here I mean Nikolay and Vyacheslav. For me, their conclusion has
more weight here. If Vladimir is ready to lead an additional release for SG
and SG developers agree, it works for me.

Sincerely,
Dmitriy Pavlov


пт, 28 сент. 2018 г. в 19:39, Dmitriy Setrakyan :

> Dmitriy,
>
> We agreed in the beginning of this thread that Service Grid changes are not
> going to make the release because the community still did not approve the
> design. Nothing has changed since. I have not seen any design discussions.
> At this point, I have no confidence that the Service Grid changes will make
> it into the 2.8 release. The 2.7 release seems out of question altogether.
>
> Also, Nikolay is a release manager. We should let him drive the release. To
> my knowledge, he is doing a great job and the release is going according to
> the schedule he proposed.
>
> D.
>
> On Fri, Sep 28, 2018 at 4:31 AM Dmitriy Pavlov 
> wrote:
>
> > Hi Dmitriy, Vladimir,
> >
> > I suggest we stop this nonsense with release dates-pushing because of
> some
> > open question.
> >
> > Just because you disagreed with any include/exclude something into scope,
> > does not mean that whole community disagreed.
> >
> > If folks will start a separate discussion with results of the review, I
> see
> > no reasons to reject their contribution, even if we need to revisit our
> > agreements and wait for a couple of days more.
> >
> > Am I missing some reason why dates are so fundamentally important to you?
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > пт, 28 сент. 2018 г. в 12:20, Dmitriy Setrakyan :
> >
> > > If services is not ready, which it is not, then we should include them
> > into
> > > the next release. There is no need to force them into 2.7. I suggest we
> > > move according to the schedule we all agreed on.
> > >
> > > D.
> > >
> > > On Fri, Sep 28, 2018 at 1:22 AM Dmitriy Pavlov 
> > > wrote:
> > >
> > > > Yes, so correct statement is "community did not make any decisions
> > about
> > > > services not go to 2.7/ services are out of scope".
> > > >
> > > > If so, please forgive me my confusion.
> > > >
> > > > пт, 28 сент. 2018 г. в 11:19, Vladimir Ozerov  >:
> > > >
> > > > > Exactly. So correct statement is “it is up to *community* to decide
> > > > whether
> > > > > something goes to 2.7”.
> > > > >
> > > > > пт, 28 сент. 2018 г. в 11:11, Dmitriy Pavlov <
> dpavlov@gmail.com
> > >:
> > > > >
> > > > > > No, it is up to the community to discuss after their review
> > results.
> > > > > >
> > > > > > пт, 28 сент. 2018 г. в 11:09, Vladimir Ozerov <
> > voze...@gridgain.com
> > > >:
> > > > > >
> > > > > > > Dmitriy,
> > > > > > >
> > > > > > > Did I read your words correctly that it is up to implementor
> of a
> > > > > single
> > > > > > > feature to decide whether release of all other features and
> fixes
> > > to
> > > > be
> > > > > > > delayed?
> > > > > > >
> > > > > > > пт, 28 сент. 2018 г. в 11:00, Dmitriy Pavlov <
> > > dpavlov@gmail.com
> > > > >:
> > > > > > >
> > > > > > > > My point we can wait a bit for services because
> > > > > > > > 1  we are open-minded and we don't have outside pressure to
> do
> > > > > release
> > > > > > in
> > > > > > > > October
> > > > > > > > 2  and services it is not some new feature, which suddenly
> > > appeared
> > > > > in
> > > > > > > > autumn, it is a well known and important feature.
> > > > > > > >
> > > > > > > > So it is up to Vyacheslav, Anton and Nikolay to decide.
> > > > > > > >
> > > > > > > > Decisions can be services are not ready/ready to merge only
> to
> > > > > > > master/ready
> > > > > > > > to merge to master and to 2.7.
> > > > > > > >
> > > > > > > >
> > > > > > > > пт, 28 сент. 2018 г. в 10:46, Vladimir Ozerov <
> > > > voze...@gridgain.com
> > > > > >:
> > > > > > > >
> > > > > > > > > Dmitry,
> > > > > > > > >
> > > > > > > > > Community agreement was to perform the release in October.
> Of
> > > > > course
> > > > > > we
> > > > > > > > can
> > > > > > > > > wait a bit for services. Then we wait a bit for other cool
> > > > features
> > > > > > > ready
> > > > > > > > > by that time, then again and again, and release will never
> > > > happen.
> > > > > > And
> > > > > > > > > while we are waiting for new features to come, already
> > > completerd
> > > > > > > > features
> > > > > > > > > cannot be used by anyone.
> > > > > > > > >
> > > > > > > > > This is why we have an agreement that if feature is not
> > ready,
> > > it
> > > > > > > should
> > > > > > > > be
> > > > > > > > > moved to future release, instead of shifting release. The
> > sole
> > > > > reason
> > > > > > > to
> > > > > > > > > have strict

Re: Apache Ignite 2.7 release

[Denis Magda]

Even though I was not involved in the Service Grid 2.0 architectural or
development discussions, my guts feel that we need to allocate enough time
to test them through. It won't be just a fix or minor improvement,
Vyacheslav has been working on a tremendous task that seems to re-engineer
many aspects of the component. Plus, keep in mind that the current service
grid engine is battle-tested and used in production, so every architectural
change has to be well tested.

Let's wait what the reviewers say (Anton and Nikolay). We need to allocate
enough time to test it thoroughly and that time can go beyond the timeframe
of 2.7.

--
Denis

On Fri, Sep 28, 2018 at 4:58 AM Vladimir Ozerov 
wrote:

> Importance come from the fact that we agreed on these dates. Neither
> community, nor implementors of the feature were against it. And community
> already work hard to met that dates: a lot of people already aligned their
> plans, a lot very important tickets were moved out of scope to met the
> dates.
>
> Nonsense - is to come at the end of coding phase and suggest to replay the
> plans all of a sudden. If you find it important - please start a separate
> discussion where it will be your responsibility to prove community that we
> have to realign our plans and delay release of all other features due to
> Service Grid being ahead of schedule. And solution to that problem will be
> very simple - to plan another release once Service Grid is coded, tested,
> reviewed and benchmarked.
>
> On Fri, Sep 28, 2018 at 2:31 PM Dmitriy Pavlov 
> wrote:
>
> > Hi Dmitriy, Vladimir,
> >
> > I suggest we stop this nonsense with release dates-pushing because of
> some
> > open question.
> >
> > Just because you disagreed with any include/exclude something into scope,
> > does not mean that whole community disagreed.
> >
> > If folks will start a separate discussion with results of the review, I
> see
> > no reasons to reject their contribution, even if we need to revisit our
> > agreements and wait for a couple of days more.
> >
> > Am I missing some reason why dates are so fundamentally important to you?
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > пт, 28 сент. 2018 г. в 12:20, Dmitriy Setrakyan :
> >
> > > If services is not ready, which it is not, then we should include them
> > into
> > > the next release. There is no need to force them into 2.7. I suggest we
> > > move according to the schedule we all agreed on.
> > >
> > > D.
> > >
> > > On Fri, Sep 28, 2018 at 1:22 AM Dmitriy Pavlov 
> > > wrote:
> > >
> > > > Yes, so correct statement is "community did not make any decisions
> > about
> > > > services not go to 2.7/ services are out of scope".
> > > >
> > > > If so, please forgive me my confusion.
> > > >
> > > > пт, 28 сент. 2018 г. в 11:19, Vladimir Ozerov  >:
> > > >
> > > > > Exactly. So correct statement is “it is up to *community* to decide
> > > > whether
> > > > > something goes to 2.7”.
> > > > >
> > > > > пт, 28 сент. 2018 г. в 11:11, Dmitriy Pavlov <
> dpavlov@gmail.com
> > >:
> > > > >
> > > > > > No, it is up to the community to discuss after their review
> > results.
> > > > > >
> > > > > > пт, 28 сент. 2018 г. в 11:09, Vladimir Ozerov <
> > voze...@gridgain.com
> > > >:
> > > > > >
> > > > > > > Dmitriy,
> > > > > > >
> > > > > > > Did I read your words correctly that it is up to implementor
> of a
> > > > > single
> > > > > > > feature to decide whether release of all other features and
> fixes
> > > to
> > > > be
> > > > > > > delayed?
> > > > > > >
> > > > > > > пт, 28 сент. 2018 г. в 11:00, Dmitriy Pavlov <
> > > dpavlov@gmail.com
> > > > >:
> > > > > > >
> > > > > > > > My point we can wait a bit for services because
> > > > > > > > 1  we are open-minded and we don't have outside pressure to
> do
> > > > > release
> > > > > > in
> > > > > > > > October
> > > > > > > > 2  and services it is not some new feature, which suddenly
> > > appeared
> > > > > in
> > > > > > > > autumn, it is a well known and important feature.
> > > > > > > >
> > > > > > > > So it is up to Vyacheslav, Anton and Nikolay to decide.
> > > > > > > >
> > > > > > > > Decisions can be services are not ready/ready to merge only
> to
> > > > > > > master/ready
> > > > > > > > to merge to master and to 2.7.
> > > > > > > >
> > > > > > > >
> > > > > > > > пт, 28 сент. 2018 г. в 10:46, Vladimir Ozerov <
> > > > voze...@gridgain.com
> > > > > >:
> > > > > > > >
> > > > > > > > > Dmitry,
> > > > > > > > >
> > > > > > > > > Community agreement was to perform the release in October.
> Of
> > > > > course
> > > > > > we
> > > > > > > > can
> > > > > > > > > wait a bit for services. Then we wait a bit for other cool
> > > > features
> > > > > > > ready
> > > > > > > > > by that time, then again and again, and release will never
> > > > happen.
> > > > > > And
> > > > > > > > > while we are waiting for new features to come, already
> > > completerd
> > > > > > > > features
> > > > > > > > > cannot be used by anyone.
> > > > > > > > >
> > > > > 

Re: [QUESTION] SegmentAware holder initialization (fix of WAL blocked rollOver)

[Anton Kalashnikov]

Hello.

Looks like you are right about interrupted flag. I don't understand why tests 
was pass successfully in master. Your solution  also looks correct.

SegmentAware - it's info object of actual state of WAL segments like "current 
work segment", "last archived segment" etc. Actually it's nothing new here. It 
just was extracted from FileWriteAheadLogManager for centralization and future 
simplification. It should not change a old behaviour if it was happened it  
will need to be investigate.

If you already have fix for it, please will create task and add me to the 
watchers. Or I can fix it by myself.

-- 
Best regards,
Anton Kalashnikov


28.09.2018, 16:06, "Maxim Muzafarov" :
> Igniters,
>
> I would like to discuss this question here and create a separate topic for
> it. Previously, I've posted some comments on the probable issue in Apache
> Ignite 2.7 topic [2]. My question is related to the IGNITE-8559 [3] (commit
> [4]). We've added a new SegmentAware class and change the
> FileWriteAheadLogManager behaviour.
>
> The FileWriteAheadLogManager now contains:
>
> `private final SegmentAware segmentAware;`.
>
> The SegmentAware have the `interrupt()` method which at manager
> de-activation sets (e.g. for SegmentArchivedStorage) `interrupted` filed to
> `true` value [5] but never revert it to `false` after activation. So, the
> SegmentArchivedStorage after de-activation always remain interrupted.
>
> I think it can lead us to unpredictable issues with multiple cluster
> activation/de-activation. I don't know why all tests in master branch
> suppose to be successful but in my local branch, they hang on exchange
> future get() method.
>
> My local solution (probably not ideal) is:
> 1) make it volatile - `private volatile SegmentAware segmentAware;`
> 2) move field init to the `start0()` method of FileWriteAheadLogManager;
>
> With these changes, everything begins to work fine but I can miss something
> because I don’t understand the whole this change well enough.
>
> Can anyone comment on this and share details IGNITE-8559 implementation?
>
> [1]
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/wal/FileWriteAheadLogManager.java#L319
> [2]
> http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-2-7-release-tp34076p35863.html
> [3] https://issues.apache.org/jira/browse/IGNITE-8559
> [4]
> https://github.com/apache/ignite/commit/2f72fe758d4256c4eb4610e5922ad3d174b43dc5
> [5]
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/wal/aware/SegmentArchivedStorage.java#L117
> --
> --
> Maxim Muzafarov

Re: Need Review IGNITE-7616 Mxbeans thread display.

[Dmitriy Pavlov]

Hi David,

Snapshot Dependency Error is TeamCity term means some from dependent builds
failed.

Because some percent of tests have constant floating failures, almost all
runs will get this error.

I will do some tests validation shortly.

Sincerely,
Dmitriy Pavlov

пт, 28 сент. 2018 г. в 15:17, David Harvey :

>1.
>   This is my second newbie submission, it could use a review, and I
>   keep getting snapshot dependency errors in teamcity that seem like
> the
>   cannot be related to my changes, even after rebasing 2 twice.
> I couldn't
>   find a crisp defintion of what a snapshot dependency is.
>
>   It is a low regression risk fix to the mxbeans display of thread
>   pools, where one type of pool mxbeans registration was simply
> miscoded, and
>   another type of pool was completely missing any code to display it.
> It
>   provides insight at runtime into two thread pools that are currently
>   opaque.It makes one very modest change to actual production code.
>
>   2. IGNITE-7616
> GridDataStreamExecutor
>and GridCallbackExecutor JMX beans return incorrect values due to
> invalid
>interface registration.
>
>
> https://github.com/apache/ignite/pull/4732
> -DH
>
> PS I have seen this movie before, and the future got much brighter future
> when we completed the equivalent of making teamcity  whole again.
>

Re: Need Review IGNITE-7616 Mxbeans thread display.

[Dmitriy Pavlov]

I've checked run.

There are no suspicious test failures here, all failures are more or less
the same with the master.

пт, 28 сент. 2018 г. в 20:03, Dmitriy Pavlov :

> Hi David,
>
> Snapshot Dependency Error is TeamCity term means some from dependent
> builds failed.
>
> Because some percent of tests have constant floating failures, almost all
> runs will get this error.
>
> I will do some tests validation shortly.
>
> Sincerely,
> Dmitriy Pavlov
>
> пт, 28 сент. 2018 г. в 15:17, David Harvey :
>
>>1.
>>   This is my second newbie submission, it could use a review, and I
>>   keep getting snapshot dependency errors in teamcity that seem like
>> the
>>   cannot be related to my changes, even after rebasing 2 twice.
>> I couldn't
>>   find a crisp defintion of what a snapshot dependency is.
>>
>>   It is a low regression risk fix to the mxbeans display of thread
>>   pools, where one type of pool mxbeans registration was simply
>> miscoded, and
>>   another type of pool was completely missing any code to display
>> it.  It
>>   provides insight at runtime into two thread pools that are currently
>>   opaque.It makes one very modest change to actual production
>> code.
>>
>>   2. IGNITE-7616
>> GridDataStreamExecutor
>>and GridCallbackExecutor JMX beans return incorrect values due to
>> invalid
>>interface registration.
>>
>>
>> https://github.com/apache/ignite/pull/4732
>> -DH
>>
>> PS I have seen this movie before, and the future got much brighter future
>> when we completed the equivalent of making teamcity  whole again.
>>
>

Re: Apache Ignite 2.7 release

[Nikolay Izhikov]

Hello, Igniters.

I think we shouldn't put so many emotions in discussion of any contribution.
Even so big and important as SG redesign.

The crucial point we all agreed about: Service Grid redesign a big feature that 
can significally improve Ignite.
We all want to have it in the product.

Let me write my vision of the current task state:   

1. Design of SG is discussed *and aligned* both: privately with Ignite 
experts(Vladimir Ozerov, Alexey Goncharyuk, Anton Vinogradov, Denis Mekhanikov)
and publicly on dev-list. This task is done.

2. Current PR state - *on my review*. 
I spend some time with this contribution and gave Vyacheslav a feedback.
I expect he can fix my comments in a day or two.
Seem we can ask of Anton Vinogradov review on the beginning of next week.

If Dmitriy or any community member wants to help *by doing things, not 
discussing them on dev-list*.
Please, join to the review - you are welcome. PR is here [1]

3. I think, we have two mutually exclusive options regarding of release 2.7 
a. We release 2.7 in planned dates.
b. We include SG in release scope.

My vote goes to option *a*.
I think we should release 2.7 with the bunch of new cool features.
*AND* we should plan 2.8 release at the end of the year with SG redesign and 
MVCC stabilization tasks.

Anyway, while we preparing release a lot of things can happen.
Let's come back to discussion of SG release version *when it will be ready to 
be merged to master*.

Guys, does it makes sense for you?

[1] https://github.com/apache/ignite/pull/4434

В Пт, 28/09/2018 в 19:47 +0300, Dmitriy Pavlov пишет:
> Hi Dmitriy,
> 
> The design is aligned totally. The thread you mention was not named
> properly.
> 
> It seems to me some community members are trying to take over the community
> and lead it instead of doing.
> 
> As a member of the Apache community, I value Do-ocracy and power of those
> who do, but not just disagree. There are no leaders in open source, just
> do'ers.
> 
> By do'ers here I mean Nikolay and Vyacheslav. For me, their conclusion has
> more weight here. If Vladimir is ready to lead an additional release for SG
> and SG developers agree, it works for me.
> 
> Sincerely,
> Dmitriy Pavlov
> 
> 
> пт, 28 сент. 2018 г. в 19:39, Dmitriy Setrakyan :
> 
> > Dmitriy,
> > 
> > We agreed in the beginning of this thread that Service Grid changes are not
> > going to make the release because the community still did not approve the
> > design. Nothing has changed since. I have not seen any design discussions.
> > At this point, I have no confidence that the Service Grid changes will make
> > it into the 2.8 release. The 2.7 release seems out of question altogether.
> > 
> > Also, Nikolay is a release manager. We should let him drive the release. To
> > my knowledge, he is doing a great job and the release is going according to
> > the schedule he proposed.
> > 
> > D.
> > 
> > On Fri, Sep 28, 2018 at 4:31 AM Dmitriy Pavlov 
> > wrote:
> > 
> > > Hi Dmitriy, Vladimir,
> > > 
> > > I suggest we stop this nonsense with release dates-pushing because of
> > 
> > some
> > > open question.
> > > 
> > > Just because you disagreed with any include/exclude something into scope,
> > > does not mean that whole community disagreed.
> > > 
> > > If folks will start a separate discussion with results of the review, I
> > 
> > see
> > > no reasons to reject their contribution, even if we need to revisit our
> > > agreements and wait for a couple of days more.
> > > 
> > > Am I missing some reason why dates are so fundamentally important to you?
> > > 
> > > Sincerely,
> > > Dmitriy Pavlov
> > > 
> > > пт, 28 сент. 2018 г. в 12:20, Dmitriy Setrakyan :
> > > 
> > > > If services is not ready, which it is not, then we should include them
> > > 
> > > into
> > > > the next release. There is no need to force them into 2.7. I suggest we
> > > > move according to the schedule we all agreed on.
> > > > 
> > > > D.
> > > > 
> > > > On Fri, Sep 28, 2018 at 1:22 AM Dmitriy Pavlov 
> > > > wrote:
> > > > 
> > > > > Yes, so correct statement is "community did not make any decisions
> > > 
> > > about
> > > > > services not go to 2.7/ services are out of scope".
> > > > > 
> > > > > If so, please forgive me my confusion.
> > > > > 
> > > > > пт, 28 сент. 2018 г. в 11:19, Vladimir Ozerov  > > 
> > > :
> > > > > 
> > > > > > Exactly. So correct statement is “it is up to *community* to decide
> > > > > 
> > > > > whether
> > > > > > something goes to 2.7”.
> > > > > > 
> > > > > > пт, 28 сент. 2018 г. в 11:11, Dmitriy Pavlov <
> > 
> > dpavlov@gmail.com
> > > > :
> > > > > > 
> > > > > > > No, it is up to the community to discuss after their review
> > > 
> > > results.
> > > > > > > 
> > > > > > > пт, 28 сент. 2018 г. в 11:09, Vladimir Ozerov <
> > > 
> > > voze...@gridgain.com
> > > > > :
> > > > > > > 
> > > > > > > > Dmitriy,
> > > > > > > > 
> > > > > > > > Did I read your words correctly that it is up to implementor
> > 
> > of a
> > > > > 

Re: Apache Ignite 2.7 release

[Denis Magda]

Nikolay,

Thanks for stepping in and giving more context. In general, I'm fully for
your proposal below:

My vote goes to option *a*.
> I think we should release 2.7 with the bunch of new cool features.
> *AND* we should plan 2.8 release at the end of the year with SG redesign
> and MVCC stabilization tasks.


--
Denis

On Fri, Sep 28, 2018 at 10:30 AM Nikolay Izhikov 
wrote:

> Hello, Igniters.
>
> I think we shouldn't put so many emotions in discussion of any
> contribution.
> Even so big and important as SG redesign.
>
> The crucial point we all agreed about: Service Grid redesign a big feature
> that can significally improve Ignite.
> We all want to have it in the product.
>
> Let me write my vision of the current task state:
>
> 1. Design of SG is discussed *and aligned* both: privately with Ignite
> experts(Vladimir Ozerov, Alexey Goncharyuk, Anton Vinogradov, Denis
> Mekhanikov)
> and publicly on dev-list. This task is done.
>
> 2. Current PR state - *on my review*.
> I spend some time with this contribution and gave Vyacheslav a feedback.
> I expect he can fix my comments in a day or two.
> Seem we can ask of Anton Vinogradov review on the beginning of next week.
>
> If Dmitriy or any community member wants to help *by doing things, not
> discussing them on dev-list*.
> Please, join to the review - you are welcome. PR is here [1]
>
> 3. I think, we have two mutually exclusive options regarding of release
> 2.7
> a. We release 2.7 in planned dates.
> b. We include SG in release scope.
>
> My vote goes to option *a*.
> I think we should release 2.7 with the bunch of new cool features.
> *AND* we should plan 2.8 release at the end of the year with SG redesign
> and MVCC stabilization tasks.
>
> Anyway, while we preparing release a lot of things can happen.
> Let's come back to discussion of SG release version *when it will be ready
> to be merged to master*.
>
> Guys, does it makes sense for you?
>
> [1] https://github.com/apache/ignite/pull/4434
>
> В Пт, 28/09/2018 в 19:47 +0300, Dmitriy Pavlov пишет:
> > Hi Dmitriy,
> >
> > The design is aligned totally. The thread you mention was not named
> > properly.
> >
> > It seems to me some community members are trying to take over the
> community
> > and lead it instead of doing.
> >
> > As a member of the Apache community, I value Do-ocracy and power of those
> > who do, but not just disagree. There are no leaders in open source, just
> > do'ers.
> >
> > By do'ers here I mean Nikolay and Vyacheslav. For me, their conclusion
> has
> > more weight here. If Vladimir is ready to lead an additional release for
> SG
> > and SG developers agree, it works for me.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> >
> > пт, 28 сент. 2018 г. в 19:39, Dmitriy Setrakyan :
> >
> > > Dmitriy,
> > >
> > > We agreed in the beginning of this thread that Service Grid changes
> are not
> > > going to make the release because the community still did not approve
> the
> > > design. Nothing has changed since. I have not seen any design
> discussions.
> > > At this point, I have no confidence that the Service Grid changes will
> make
> > > it into the 2.8 release. The 2.7 release seems out of question
> altogether.
> > >
> > > Also, Nikolay is a release manager. We should let him drive the
> release. To
> > > my knowledge, he is doing a great job and the release is going
> according to
> > > the schedule he proposed.
> > >
> > > D.
> > >
> > > On Fri, Sep 28, 2018 at 4:31 AM Dmitriy Pavlov 
> > > wrote:
> > >
> > > > Hi Dmitriy, Vladimir,
> > > >
> > > > I suggest we stop this nonsense with release dates-pushing because of
> > >
> > > some
> > > > open question.
> > > >
> > > > Just because you disagreed with any include/exclude something into
> scope,
> > > > does not mean that whole community disagreed.
> > > >
> > > > If folks will start a separate discussion with results of the
> review, I
> > >
> > > see
> > > > no reasons to reject their contribution, even if we need to revisit
> our
> > > > agreements and wait for a couple of days more.
> > > >
> > > > Am I missing some reason why dates are so fundamentally important to
> you?
> > > >
> > > > Sincerely,
> > > > Dmitriy Pavlov
> > > >
> > > > пт, 28 сент. 2018 г. в 12:20, Dmitriy Setrakyan <
> dsetrak...@apache.org>:
> > > >
> > > > > If services is not ready, which it is not, then we should include
> them
> > > >
> > > > into
> > > > > the next release. There is no need to force them into 2.7. I
> suggest we
> > > > > move according to the schedule we all agreed on.
> > > > >
> > > > > D.
> > > > >
> > > > > On Fri, Sep 28, 2018 at 1:22 AM Dmitriy Pavlov <
> dpavlov@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Yes, so correct statement is "community did not make any
> decisions
> > > >
> > > > about
> > > > > > services not go to 2.7/ services are out of scope".
> > > > > >
> > > > > > If so, please forgive me my confusion.
> > > > > >
> > > > > > пт, 28 сент. 2018 г. в 11:19, Vladimir Ozerov <
> voze..

Re: Apache Ignite 2.7 release

[Dmitriy Pavlov]

Nikolay, because I think you're a do'er, but not a commenter, like me, for
example, I can trust your opinion.

I will join review if I have spare cycles.

пт, 28 сент. 2018 г. в 20:34, Denis Magda :

> Nikolay,
>
> Thanks for stepping in and giving more context. In general, I'm fully for
> your proposal below:
>
> My vote goes to option *a*.
> > I think we should release 2.7 with the bunch of new cool features.
> > *AND* we should plan 2.8 release at the end of the year with SG redesign
> > and MVCC stabilization tasks.
>
>
> --
> Denis
>
> On Fri, Sep 28, 2018 at 10:30 AM Nikolay Izhikov 
> wrote:
>
> > Hello, Igniters.
> >
> > I think we shouldn't put so many emotions in discussion of any
> > contribution.
> > Even so big and important as SG redesign.
> >
> > The crucial point we all agreed about: Service Grid redesign a big
> feature
> > that can significally improve Ignite.
> > We all want to have it in the product.
> >
> > Let me write my vision of the current task state:
> >
> > 1. Design of SG is discussed *and aligned* both: privately with Ignite
> > experts(Vladimir Ozerov, Alexey Goncharyuk, Anton Vinogradov, Denis
> > Mekhanikov)
> > and publicly on dev-list. This task is done.
> >
> > 2. Current PR state - *on my review*.
> > I spend some time with this contribution and gave Vyacheslav a feedback.
> > I expect he can fix my comments in a day or two.
> > Seem we can ask of Anton Vinogradov review on the beginning of next week.
> >
> > If Dmitriy or any community member wants to help *by doing things, not
> > discussing them on dev-list*.
> > Please, join to the review - you are welcome. PR is here [1]
> >
> > 3. I think, we have two mutually exclusive options regarding of release
> > 2.7
> > a. We release 2.7 in planned dates.
> > b. We include SG in release scope.
> >
> > My vote goes to option *a*.
> > I think we should release 2.7 with the bunch of new cool features.
> > *AND* we should plan 2.8 release at the end of the year with SG redesign
> > and MVCC stabilization tasks.
> >
> > Anyway, while we preparing release a lot of things can happen.
> > Let's come back to discussion of SG release version *when it will be
> ready
> > to be merged to master*.
> >
> > Guys, does it makes sense for you?
> >
> > [1] https://github.com/apache/ignite/pull/4434
> >
> > В Пт, 28/09/2018 в 19:47 +0300, Dmitriy Pavlov пишет:
> > > Hi Dmitriy,
> > >
> > > The design is aligned totally. The thread you mention was not named
> > > properly.
> > >
> > > It seems to me some community members are trying to take over the
> > community
> > > and lead it instead of doing.
> > >
> > > As a member of the Apache community, I value Do-ocracy and power of
> those
> > > who do, but not just disagree. There are no leaders in open source,
> just
> > > do'ers.
> > >
> > > By do'ers here I mean Nikolay and Vyacheslav. For me, their conclusion
> > has
> > > more weight here. If Vladimir is ready to lead an additional release
> for
> > SG
> > > and SG developers agree, it works for me.
> > >
> > > Sincerely,
> > > Dmitriy Pavlov
> > >
> > >
> > > пт, 28 сент. 2018 г. в 19:39, Dmitriy Setrakyan  >:
> > >
> > > > Dmitriy,
> > > >
> > > > We agreed in the beginning of this thread that Service Grid changes
> > are not
> > > > going to make the release because the community still did not approve
> > the
> > > > design. Nothing has changed since. I have not seen any design
> > discussions.
> > > > At this point, I have no confidence that the Service Grid changes
> will
> > make
> > > > it into the 2.8 release. The 2.7 release seems out of question
> > altogether.
> > > >
> > > > Also, Nikolay is a release manager. We should let him drive the
> > release. To
> > > > my knowledge, he is doing a great job and the release is going
> > according to
> > > > the schedule he proposed.
> > > >
> > > > D.
> > > >
> > > > On Fri, Sep 28, 2018 at 4:31 AM Dmitriy Pavlov <
> dpavlov@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi Dmitriy, Vladimir,
> > > > >
> > > > > I suggest we stop this nonsense with release dates-pushing because
> of
> > > >
> > > > some
> > > > > open question.
> > > > >
> > > > > Just because you disagreed with any include/exclude something into
> > scope,
> > > > > does not mean that whole community disagreed.
> > > > >
> > > > > If folks will start a separate discussion with results of the
> > review, I
> > > >
> > > > see
> > > > > no reasons to reject their contribution, even if we need to revisit
> > our
> > > > > agreements and wait for a couple of days more.
> > > > >
> > > > > Am I missing some reason why dates are so fundamentally important
> to
> > you?
> > > > >
> > > > > Sincerely,
> > > > > Dmitriy Pavlov
> > > > >
> > > > > пт, 28 сент. 2018 г. в 12:20, Dmitriy Setrakyan <
> > dsetrak...@apache.org>:
> > > > >
> > > > > > If services is not ready, which it is not, then we should include
> > them
> > > > >
> > > > > into
> > > > > > the next release. There is no need to force them into 2.7. I

Re: Apache Ignite 2.7 release

[Dmitriy Setrakyan]

I am not sure I can agree. SG redesign includes:
- hot redeployment
- versioning

In my experience, features like these take about 1 month to test properly
and fix all the bugs, including redeployment tests and restart tests on
larger topologies, together with overnight runs. If this type of testing
has not been performed, I think it would be unreasonable to expect this
feature making it into the release.

Can someone comment on the testing?

D.


On Fri, Sep 28, 2018 at 10:38 AM Dmitriy Pavlov 
wrote:

> Nikolay, because I think you're a do'er, but not a commenter, like me, for
> example, I can trust your opinion.
>
> I will join review if I have spare cycles.
>
> пт, 28 сент. 2018 г. в 20:34, Denis Magda :
>
> > Nikolay,
> >
> > Thanks for stepping in and giving more context. In general, I'm fully for
> > your proposal below:
> >
> > My vote goes to option *a*.
> > > I think we should release 2.7 with the bunch of new cool features.
> > > *AND* we should plan 2.8 release at the end of the year with SG
> redesign
> > > and MVCC stabilization tasks.
> >
> >
> > --
> > Denis
> >
> > On Fri, Sep 28, 2018 at 10:30 AM Nikolay Izhikov 
> > wrote:
> >
> > > Hello, Igniters.
> > >
> > > I think we shouldn't put so many emotions in discussion of any
> > > contribution.
> > > Even so big and important as SG redesign.
> > >
> > > The crucial point we all agreed about: Service Grid redesign a big
> > feature
> > > that can significally improve Ignite.
> > > We all want to have it in the product.
> > >
> > > Let me write my vision of the current task state:
> > >
> > > 1. Design of SG is discussed *and aligned* both: privately with Ignite
> > > experts(Vladimir Ozerov, Alexey Goncharyuk, Anton Vinogradov, Denis
> > > Mekhanikov)
> > > and publicly on dev-list. This task is done.
> > >
> > > 2. Current PR state - *on my review*.
> > > I spend some time with this contribution and gave Vyacheslav a
> feedback.
> > > I expect he can fix my comments in a day or two.
> > > Seem we can ask of Anton Vinogradov review on the beginning of next
> week.
> > >
> > > If Dmitriy or any community member wants to help *by doing things, not
> > > discussing them on dev-list*.
> > > Please, join to the review - you are welcome. PR is here [1]
> > >
> > > 3. I think, we have two mutually exclusive options regarding of release
> > > 2.7
> > > a. We release 2.7 in planned dates.
> > > b. We include SG in release scope.
> > >
> > > My vote goes to option *a*.
> > > I think we should release 2.7 with the bunch of new cool features.
> > > *AND* we should plan 2.8 release at the end of the year with SG
> redesign
> > > and MVCC stabilization tasks.
> > >
> > > Anyway, while we preparing release a lot of things can happen.
> > > Let's come back to discussion of SG release version *when it will be
> > ready
> > > to be merged to master*.
> > >
> > > Guys, does it makes sense for you?
> > >
> > > [1] https://github.com/apache/ignite/pull/4434
> > >
> > > В Пт, 28/09/2018 в 19:47 +0300, Dmitriy Pavlov пишет:
> > > > Hi Dmitriy,
> > > >
> > > > The design is aligned totally. The thread you mention was not named
> > > > properly.
> > > >
> > > > It seems to me some community members are trying to take over the
> > > community
> > > > and lead it instead of doing.
> > > >
> > > > As a member of the Apache community, I value Do-ocracy and power of
> > those
> > > > who do, but not just disagree. There are no leaders in open source,
> > just
> > > > do'ers.
> > > >
> > > > By do'ers here I mean Nikolay and Vyacheslav. For me, their
> conclusion
> > > has
> > > > more weight here. If Vladimir is ready to lead an additional release
> > for
> > > SG
> > > > and SG developers agree, it works for me.
> > > >
> > > > Sincerely,
> > > > Dmitriy Pavlov
> > > >
> > > >
> > > > пт, 28 сент. 2018 г. в 19:39, Dmitriy Setrakyan <
> dsetrak...@apache.org
> > >:
> > > >
> > > > > Dmitriy,
> > > > >
> > > > > We agreed in the beginning of this thread that Service Grid changes
> > > are not
> > > > > going to make the release because the community still did not
> approve
> > > the
> > > > > design. Nothing has changed since. I have not seen any design
> > > discussions.
> > > > > At this point, I have no confidence that the Service Grid changes
> > will
> > > make
> > > > > it into the 2.8 release. The 2.7 release seems out of question
> > > altogether.
> > > > >
> > > > > Also, Nikolay is a release manager. We should let him drive the
> > > release. To
> > > > > my knowledge, he is doing a great job and the release is going
> > > according to
> > > > > the schedule he proposed.
> > > > >
> > > > > D.
> > > > >
> > > > > On Fri, Sep 28, 2018 at 4:31 AM Dmitriy Pavlov <
> > dpavlov@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Hi Dmitriy, Vladimir,
> > > > > >
> > > > > > I suggest we stop this nonsense with release dates-pushing
> because
> > of
> > > > >
> > > > > some
> > > > > > open question.
> > > > > >
> > > > > > Just because you disagree

[jira] [Created] (IGNITE-9740) [ML] Remove IgniteThread wrapper from ml unit test EvaluatorTest (follow up to IGNITE-9711)

[Oleg Ignatenko (JIRA)]

Oleg Ignatenko created IGNITE-9740:
--

 Summary: [ML] Remove IgniteThread wrapper from ml unit test 
EvaluatorTest (follow up to IGNITE-9711)
 Key: IGNITE-9740
 URL: https://issues.apache.org/jira/browse/IGNITE-9740
 Project: Ignite
  Issue Type: Bug
  Components: ml
Affects Versions: 2.6
Reporter: Oleg Ignatenko


[EvaluatorTest|https://github.com/apache/ignite/blob/master/modules/ml/src/test/java/org/apache/ignite/ml/selection/scoring/evaluator/EvaluatorTest.java]
 involves {{IgniteThread}} which is in fact not needed there and should be 
removed.

{{IgniteThread}} usage is a remainder / copy-paste from older tests and 
examples that were using API requiring it. This API has been removed and there 
is no need for wrapping like that anymore. For the reference on how to perform 
suggested cleanup check changes made to ml examples per IGNITE-9711.



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

[MTCGA]: new failures in builds [1962097] needs to be handled

[dpavlov . tasks]

Hi Igniters,

 I've detected some new issue on TeamCity to be handled. You are more than 
welcomed to help.

 If your changes can lead to this failure(s): We're grateful that you were a 
volunteer to make the contribution to this project, but things change and you 
may no longer be able to finalize your contribution.
 Could you respond to this email and indicate if you wish to continue and fix 
test failures or step down and some committer may revert you commit. 

 *New test failure in master 
CacheMvccTransactionsTest.testImplicitPartsScan_ClientServer_Backups0 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=1971996347915211795&branch=%3Cdefault%3E&tab=testDetails

 *Recently contributed test failed in master 
CacheMvccTransactionsTest.testPessimisticTxScanReadsSnapshot_SingleNode_SinglePartition
 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=6719097388814341473&branch=%3Cdefault%3E&tab=testDetails

 *New test failure in master 
CacheMvccTransactionsTest.testImplicitPartsScan_ClientServer_Backups1 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-4555704627702218679&branch=%3Cdefault%3E&tab=testDetails

 *New test failure in master 
CacheMvccTransactionsTest.testWaitPreviousTxAck 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=491100542068222422&branch=%3Cdefault%3E&tab=testDetails

 *New test failure in master 
CacheMvccTransactionsTest.testImplicitPartsScan_ClientServer_Backups2 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=4191768087058136159&branch=%3Cdefault%3E&tab=testDetails

 *New test failure in master 
CacheMvccTransactionsTest.testPessimisticTxGetAllReadsSnapshot_SingleNode_SinglePartition
 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-2948820371272452864&branch=%3Cdefault%3E&tab=testDetails

 *New test failure in master 
CacheMvccTransactionsTest.testPessimisticTxGetAllReadsSnapshot_ClientServer 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=5650831108120409159&branch=%3Cdefault%3E&tab=testDetails

 *New test failure in master 
DataStreamProcessorMvccSelfTest.testFlushTimeout 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-5813536155433712223&branch=%3Cdefault%3E&tab=testDetails

 *New test failure in master 
CacheMvccTransactionsTest.testImplicitPartsScan_SingleNode_SinglePartition 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=3584560224823040028&branch=%3Cdefault%3E&tab=testDetails

 *New test failure in master 
CacheMvccTransactionsTest.testCleanupWaitsForGet2 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=1054053153780357132&branch=%3Cdefault%3E&tab=testDetails

 *Recently contributed test failed in master 
CacheMvccTransactionsTest.testPessimisticTxScanReadsSnapshot_ClientServer 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-3463865944086743777&branch=%3Cdefault%3E&tab=testDetails

 *New test failure in master 
CacheMvccTransactionsTest.testImplicitPartsScan_SingleNode 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-3270586031300522945&branch=%3Cdefault%3E&tab=testDetails
 Changes may lead to failure were done by 
 - zaleslaw.sin 
http://ci.ignite.apache.org/viewModification.html?modId=833094&personal=false
 - zaleslaw.sin 
http://ci.ignite.apache.org/viewModification.html?modId=833090&personal=false
 - andrey.mashenkov 
http://ci.ignite.apache.org/viewModification.html?modId=833088&personal=false

 - Here's a reminder of what contributors were agreed to do 
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute 
 - Should you have any questions please contact dev@ignite.apache.org 

Best Regards,
Apache Ignite TeamCity Bot 
https://github.com/apache/ignite-teamcity-bot
Notification generated at 01:19:56 29-09-2018 

[MTCGA]: new failures in builds [1962099] needs to be handled

[dpavlov . tasks]

Hi Igniters,

 I've detected some new issue on TeamCity to be handled. You are more than 
welcomed to help.

 If your changes can lead to this failure(s): We're grateful that you were a 
volunteer to make the contribution to this project, but things change and you 
may no longer be able to finalize your contribution.
 Could you respond to this email and indicate if you wish to continue and fix 
test failures or step down and some committer may revert you commit. 

 *New test failure in master 
SqlTransactionsCommandsWithMvccEnabledSelfTest.testSqlOperationsWithinNonSqlTransaction
 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=303897293610722&branch=%3Cdefault%3E&tab=testDetails

 *New test failure in master 
CacheMvccPartitionedSqlQueriesTest.testUpdateSingleValue_ClientServer 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=2761105264585936058&branch=%3Cdefault%3E&tab=testDetails

 *New test failure in master 
CacheMvccPartitionedSqlQueriesTest.testUpdateSingleValue_LocalQuery_SingleNode 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=5626162623151877987&branch=%3Cdefault%3E&tab=testDetails

 *New test failure in master 
CacheMvccReplicatedSqlQueriesTest.testUpdateSingleValue_SingleNode 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=6418911975858855024&branch=%3Cdefault%3E&tab=testDetails

 *New test failure in master 
CacheMvccPartitionedSqlQueriesTest.testUpdateSingleValue_SingleNode 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=7318003475806527820&branch=%3Cdefault%3E&tab=testDetails

 *New test failure in master 
CacheMvccReplicatedSqlQueriesTest.testJoinTransactional_ClientServer 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-4002643224847652776&branch=%3Cdefault%3E&tab=testDetails

 *New test failure in master 
CacheMvccPartitionedSqlTxQueriesTest.testQueryInsertUpdateMultithread 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=6125040159057121411&branch=%3Cdefault%3E&tab=testDetails

 *New test failure in master 
CacheMvccPartitionedSqlQueriesTest.testJoinTransactional_ClientServer 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=4186919405298850984&branch=%3Cdefault%3E&tab=testDetails

 *New test failure in master 
CacheMvccReplicatedSqlQueriesTest.testJoinTransactional_DistributedJoins_ClientServer
 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-132656164139338378&branch=%3Cdefault%3E&tab=testDetails

 *New test failure in master 
CacheMvccReplicatedSqlQueriesTest.testUpdateSingleValue_LocalQuery_SingleNode 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-7184281060498878841&branch=%3Cdefault%3E&tab=testDetails

 *New test failure in master 
CacheMvccReplicatedSqlQueriesTest.testJoinTransactional_SingleNode 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-2448146712735885196&branch=%3Cdefault%3E&tab=testDetails

 *New test failure in master 
CacheMvccReplicatedSqlTxQueriesTest.testQueryInsertUpdateMultithread 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-6383377864627461005&branch=%3Cdefault%3E&tab=testDetails

 *New test failure in master 
CacheMvccPartitionedSqlQueriesTest.testJoinTransactional_DistributedJoins_ClientServer
 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-6466081321439161948&branch=%3Cdefault%3E&tab=testDetails

 *New test failure in master 
CacheMvccPartitionedSqlQueriesTest.testJoinTransactional_SingleNode 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-211573533276856&branch=%3Cdefault%3E&tab=testDetails

 *New test failure in master 
CacheMvccReplicatedSqlQueriesTest.testUpdateSingleValue_ClientServer 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-3154693824638814134&branch=%3Cdefault%3E&tab=testDetails
 Changes may lead to failure were done by 
 - zaleslaw.sin 
http://ci.ignite.apache.org/viewModification.html?modId=833094&personal=false
 - zaleslaw.sin 
http://ci.ignite.apache.org/viewModification.html?modId=833090&personal=false
 - andrey.mashenkov 
http://ci.ignite.apache.org/viewModification.html?modId=833088&personal=false

 - Here's a reminder of what contributors were agreed to do 
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute 
 - Should you have any questions please contact dev@ignite.apache.org 

Best Regards,
Apache Ignite TeamCity Bot 
https://github.com/apache/ignite-teamcity-bot
Notification generated at 01:34:38 29-09-2018 

Re: Request for review : IGNITE-3303 Apache Flink Integration - Flink source

[Saikat Maitra]

Hi Andrew,

I have updated the changes.

Can you please review and share feedback.

Regards
Saikat

On Sat, Sep 22, 2018 at 2:23 PM Saikat Maitra 
wrote:

> Hi Andrew
>
>
> I have updated the changes.
>
>
> Can you please review and share feedback.
>
>
> Regards
> Saikat
>
>
> On Wed, Sep 19, 2018 at 8:11 PM, Saikat Maitra 
> wrote:
>
>> Hi Andrew,
>>
>> I have updated the tests and also added java docs.
>>
>> Can you please review and share feedback.
>>
>>
>> Regards
>> Saikat
>>
>>
>>
>>
>> On Sun, Sep 16, 2018 at 11:53 AM, Saikat Maitra 
>> wrote:
>>
>>> Hi Andrew,
>>>
>>> I have updated the tests and also added java docs.
>>>
>>> Please review and share feedback.
>>>
>>> Regards
>>> Saikat
>>>
>>>
>>> On Sat, Sep 8, 2018 at 2:09 PM, Saikat Maitra 
>>> wrote:
>>>
 Hi Andrew, Alexey

 I have incorporated the review changes.

 I have also refactored the CacheEventSerializer class and moved it to
 test folder because it is used only in the FlinkIgniteSourceSelfExample and
 not required for IgniteSource.

 Build links https://ci.ignite.apache.org/viewLog.html?buildId=1821778&;

 https://ci.ignite.apache.org/viewLog.html?buildId=1821774&;

 Please review and share feedback.

 Regards
 Saikat

 On Tue, Sep 4, 2018 at 9:57 PM, Saikat Maitra 
 wrote:

> Hi Alexey,
>
> Thank you for reviewing the changes and sharing feedback, I am
> updating the PR. I will share the changes shortly.
>
> Regards,
> Saikat
>
> On Tue, Sep 4, 2018 at 10:59 AM, Alexey Goncharuk <
> alexey.goncha...@gmail.com> wrote:
>
>> Hello Saikat,
>>
>> I see a few fellow Igniters added some comments to your PR (including
>> me).
>> I believe the PR can be merged after you address them.
>>
>> Thanks,
>> AG
>>
>> пт, 31 авг. 2018 г. в 3:11, Saikat Maitra :
>>
>> > Thank you, Denis
>> >
>> > Regards,
>> > Saikat
>> >
>> > On Thu, Aug 30, 2018 at 7:01 PM, Denis Magda 
>> wrote:
>> >
>> > > Hello Saikat,
>> > >
>> > > Hopefully, someone from the community will review the changes in
>> the
>> > > nearest time.
>> > >
>> > > --
>> > > Denis
>> > >
>> > > On Thu, Aug 30, 2018 at 4:37 PM Saikat Maitra <
>> saikat.mai...@gmail.com>
>> > > wrote:
>> > >
>> > > > Hello,
>> > > >
>> > > > The changes for IGNITE-3303 for IgniteSource is complete. This
>> will
>> > help
>> > > is
>> > > > streaming data from Ignite cluster and process, filter,
>> transform and
>> > > > publish it back to Ignite using IgniteSink or in any other data
>> sink.
>> > > >
>> > > > I was hoping if the changes can be approved I can go ahead
>> merge the
>> > > > changes.
>> > > >
>> > > >
>> > > > Regards,
>> > > > Saikat
>> > > >
>> > > >
>> > > >
>> > > > On Tue, Aug 28, 2018 at 12:56 AM, Saikat Maitra <
>> > saikat.mai...@gmail.com
>> > > >
>> > > > wrote:
>> > > >
>> > > > > Hi Andrew,
>> > > > >
>> > > > > As discussed I have incorporated the changes. Please review
>> and let
>> > me
>> > > > > know if any changes required.
>> > > > >
>> > > > > Regards,
>> > > > > Saikat
>> > > > >
>> > > > > On Mon, Aug 27, 2018 at 1:45 AM, Saikat Maitra <
>> > > saikat.mai...@gmail.com>
>> > > > > wrote:
>> > > > >
>> > > > >> Hi,
>> > > > >>
>> > > > >> I have updated the PR with additional tests.
>> > > > >>
>> > > > >> Please review and share feedback.
>> > > > >>
>> > > > >> This PR is related to IgniteSink but allows to stream data
>> from
>> > > Ignite.
>> > > > >>
>> > > > >> PR https://github.com/apache/ignite/pull/870/files
>> > > > >>
>> > > > >> Review
>> https://reviews.ignite.apache.org/ignite/review/IGNT-CR-135
>> > > > >>
>> > > > >> Regards,
>> > > > >> Saikat
>> > > > >>
>> > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
>

>>>
>>
>

Re: Request for review : IGNITE-3303 Apache Flink Integration - Flink source

[Andrey Mashenkov]

Hi Saikat,

Sorry for late answer. I've checked changes a day ago. Now, looks good.
Hope, it will be merged soon.

Alex, would you please merge PR to master.

сб, 29 сент. 2018 г., 2:29 Saikat Maitra :

> Hi Andrew,
>
> I have updated the changes.
>
> Can you please review and share feedback.
>
> Regards
> Saikat
>
> On Sat, Sep 22, 2018 at 2:23 PM Saikat Maitra 
> wrote:
>
> > Hi Andrew
> >
> >
> > I have updated the changes.
> >
> >
> > Can you please review and share feedback.
> >
> >
> > Regards
> > Saikat
> >
> >
> > On Wed, Sep 19, 2018 at 8:11 PM, Saikat Maitra 
> > wrote:
> >
> >> Hi Andrew,
> >>
> >> I have updated the tests and also added java docs.
> >>
> >> Can you please review and share feedback.
> >>
> >>
> >> Regards
> >> Saikat
> >>
> >>
> >>
> >>
> >> On Sun, Sep 16, 2018 at 11:53 AM, Saikat Maitra <
> saikat.mai...@gmail.com>
> >> wrote:
> >>
> >>> Hi Andrew,
> >>>
> >>> I have updated the tests and also added java docs.
> >>>
> >>> Please review and share feedback.
> >>>
> >>> Regards
> >>> Saikat
> >>>
> >>>
> >>> On Sat, Sep 8, 2018 at 2:09 PM, Saikat Maitra  >
> >>> wrote:
> >>>
>  Hi Andrew, Alexey
> 
>  I have incorporated the review changes.
> 
>  I have also refactored the CacheEventSerializer class and moved it to
>  test folder because it is used only in the
> FlinkIgniteSourceSelfExample and
>  not required for IgniteSource.
> 
>  Build links
> https://ci.ignite.apache.org/viewLog.html?buildId=1821778&;
> 
>  https://ci.ignite.apache.org/viewLog.html?buildId=1821774&;
> 
>  Please review and share feedback.
> 
>  Regards
>  Saikat
> 
>  On Tue, Sep 4, 2018 at 9:57 PM, Saikat Maitra <
> saikat.mai...@gmail.com>
>  wrote:
> 
> > Hi Alexey,
> >
> > Thank you for reviewing the changes and sharing feedback, I am
> > updating the PR. I will share the changes shortly.
> >
> > Regards,
> > Saikat
> >
> > On Tue, Sep 4, 2018 at 10:59 AM, Alexey Goncharuk <
> > alexey.goncha...@gmail.com> wrote:
> >
> >> Hello Saikat,
> >>
> >> I see a few fellow Igniters added some comments to your PR
> (including
> >> me).
> >> I believe the PR can be merged after you address them.
> >>
> >> Thanks,
> >> AG
> >>
> >> пт, 31 авг. 2018 г. в 3:11, Saikat Maitra  >:
> >>
> >> > Thank you, Denis
> >> >
> >> > Regards,
> >> > Saikat
> >> >
> >> > On Thu, Aug 30, 2018 at 7:01 PM, Denis Magda 
> >> wrote:
> >> >
> >> > > Hello Saikat,
> >> > >
> >> > > Hopefully, someone from the community will review the changes in
> >> the
> >> > > nearest time.
> >> > >
> >> > > --
> >> > > Denis
> >> > >
> >> > > On Thu, Aug 30, 2018 at 4:37 PM Saikat Maitra <
> >> saikat.mai...@gmail.com>
> >> > > wrote:
> >> > >
> >> > > > Hello,
> >> > > >
> >> > > > The changes for IGNITE-3303 for IgniteSource is complete. This
> >> will
> >> > help
> >> > > is
> >> > > > streaming data from Ignite cluster and process, filter,
> >> transform and
> >> > > > publish it back to Ignite using IgniteSink or in any other
> data
> >> sink.
> >> > > >
> >> > > > I was hoping if the changes can be approved I can go ahead
> >> merge the
> >> > > > changes.
> >> > > >
> >> > > >
> >> > > > Regards,
> >> > > > Saikat
> >> > > >
> >> > > >
> >> > > >
> >> > > > On Tue, Aug 28, 2018 at 12:56 AM, Saikat Maitra <
> >> > saikat.mai...@gmail.com
> >> > > >
> >> > > > wrote:
> >> > > >
> >> > > > > Hi Andrew,
> >> > > > >
> >> > > > > As discussed I have incorporated the changes. Please review
> >> and let
> >> > me
> >> > > > > know if any changes required.
> >> > > > >
> >> > > > > Regards,
> >> > > > > Saikat
> >> > > > >
> >> > > > > On Mon, Aug 27, 2018 at 1:45 AM, Saikat Maitra <
> >> > > saikat.mai...@gmail.com>
> >> > > > > wrote:
> >> > > > >
> >> > > > >> Hi,
> >> > > > >>
> >> > > > >> I have updated the PR with additional tests.
> >> > > > >>
> >> > > > >> Please review and share feedback.
> >> > > > >>
> >> > > > >> This PR is related to IgniteSink but allows to stream data
> >> from
> >> > > Ignite.
> >> > > > >>
> >> > > > >> PR https://github.com/apache/ignite/pull/870/files
> >> > > > >>
> >> > > > >> Review
> >> https://reviews.ignite.apache.org/ignite/review/IGNT-CR-135
> >> > > > >>
> >> > > > >> Regards,
> >> > > > >> Saikat
> >> > > > >>
> >> > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
> >
> 
> >>>
> >>
> >
>

Re: Request for review : IGNITE-3303 Apache Flink Integration - Flink source

[Saikat Maitra]

Thank you Andrew

Regards,
Saikat

On Fri, Sep 28, 2018 at 7:00 PM Andrey Mashenkov 
wrote:

> Hi Saikat,
>
> Sorry for late answer. I've checked changes a day ago. Now, looks good.
> Hope, it will be merged soon.
>
> Alex, would you please merge PR to master.
>
> сб, 29 сент. 2018 г., 2:29 Saikat Maitra :
>
> > Hi Andrew,
> >
> > I have updated the changes.
> >
> > Can you please review and share feedback.
> >
> > Regards
> > Saikat
> >
> > On Sat, Sep 22, 2018 at 2:23 PM Saikat Maitra 
> > wrote:
> >
> > > Hi Andrew
> > >
> > >
> > > I have updated the changes.
> > >
> > >
> > > Can you please review and share feedback.
> > >
> > >
> > > Regards
> > > Saikat
> > >
> > >
> > > On Wed, Sep 19, 2018 at 8:11 PM, Saikat Maitra <
> saikat.mai...@gmail.com>
> > > wrote:
> > >
> > >> Hi Andrew,
> > >>
> > >> I have updated the tests and also added java docs.
> > >>
> > >> Can you please review and share feedback.
> > >>
> > >>
> > >> Regards
> > >> Saikat
> > >>
> > >>
> > >>
> > >>
> > >> On Sun, Sep 16, 2018 at 11:53 AM, Saikat Maitra <
> > saikat.mai...@gmail.com>
> > >> wrote:
> > >>
> > >>> Hi Andrew,
> > >>>
> > >>> I have updated the tests and also added java docs.
> > >>>
> > >>> Please review and share feedback.
> > >>>
> > >>> Regards
> > >>> Saikat
> > >>>
> > >>>
> > >>> On Sat, Sep 8, 2018 at 2:09 PM, Saikat Maitra <
> saikat.mai...@gmail.com
> > >
> > >>> wrote:
> > >>>
> >  Hi Andrew, Alexey
> > 
> >  I have incorporated the review changes.
> > 
> >  I have also refactored the CacheEventSerializer class and moved it
> to
> >  test folder because it is used only in the
> > FlinkIgniteSourceSelfExample and
> >  not required for IgniteSource.
> > 
> >  Build links
> > https://ci.ignite.apache.org/viewLog.html?buildId=1821778&;
> > 
> >  https://ci.ignite.apache.org/viewLog.html?buildId=1821774&;
> > 
> >  Please review and share feedback.
> > 
> >  Regards
> >  Saikat
> > 
> >  On Tue, Sep 4, 2018 at 9:57 PM, Saikat Maitra <
> > saikat.mai...@gmail.com>
> >  wrote:
> > 
> > > Hi Alexey,
> > >
> > > Thank you for reviewing the changes and sharing feedback, I am
> > > updating the PR. I will share the changes shortly.
> > >
> > > Regards,
> > > Saikat
> > >
> > > On Tue, Sep 4, 2018 at 10:59 AM, Alexey Goncharuk <
> > > alexey.goncha...@gmail.com> wrote:
> > >
> > >> Hello Saikat,
> > >>
> > >> I see a few fellow Igniters added some comments to your PR
> > (including
> > >> me).
> > >> I believe the PR can be merged after you address them.
> > >>
> > >> Thanks,
> > >> AG
> > >>
> > >> пт, 31 авг. 2018 г. в 3:11, Saikat Maitra <
> saikat.mai...@gmail.com
> > >:
> > >>
> > >> > Thank you, Denis
> > >> >
> > >> > Regards,
> > >> > Saikat
> > >> >
> > >> > On Thu, Aug 30, 2018 at 7:01 PM, Denis Magda  >
> > >> wrote:
> > >> >
> > >> > > Hello Saikat,
> > >> > >
> > >> > > Hopefully, someone from the community will review the changes
> in
> > >> the
> > >> > > nearest time.
> > >> > >
> > >> > > --
> > >> > > Denis
> > >> > >
> > >> > > On Thu, Aug 30, 2018 at 4:37 PM Saikat Maitra <
> > >> saikat.mai...@gmail.com>
> > >> > > wrote:
> > >> > >
> > >> > > > Hello,
> > >> > > >
> > >> > > > The changes for IGNITE-3303 for IgniteSource is complete.
> This
> > >> will
> > >> > help
> > >> > > is
> > >> > > > streaming data from Ignite cluster and process, filter,
> > >> transform and
> > >> > > > publish it back to Ignite using IgniteSink or in any other
> > data
> > >> sink.
> > >> > > >
> > >> > > > I was hoping if the changes can be approved I can go ahead
> > >> merge the
> > >> > > > changes.
> > >> > > >
> > >> > > >
> > >> > > > Regards,
> > >> > > > Saikat
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > On Tue, Aug 28, 2018 at 12:56 AM, Saikat Maitra <
> > >> > saikat.mai...@gmail.com
> > >> > > >
> > >> > > > wrote:
> > >> > > >
> > >> > > > > Hi Andrew,
> > >> > > > >
> > >> > > > > As discussed I have incorporated the changes. Please
> review
> > >> and let
> > >> > me
> > >> > > > > know if any changes required.
> > >> > > > >
> > >> > > > > Regards,
> > >> > > > > Saikat
> > >> > > > >
> > >> > > > > On Mon, Aug 27, 2018 at 1:45 AM, Saikat Maitra <
> > >> > > saikat.mai...@gmail.com>
> > >> > > > > wrote:
> > >> > > > >
> > >> > > > >> Hi,
> > >> > > > >>
> > >> > > > >> I have updated the PR with additional tests.
> > >> > > > >>
> > >> > > > >> Please review and share feedback.
> > >> > > > >>
> > >> > > > >> This PR is related to IgniteSink but allows to stream
> data
> > >> from
> > >> > > Ignite.
> > >> > > > >>
> > >> > > > >> PR https://git

[MTCGA]: new failures in builds [1962097] needs to be handled

[dpavlov . tasks]

Hi Igniters,

 I've detected some new issue on TeamCity to be handled. You are more than 
welcomed to help.

 If your changes can lead to this failure(s): We're grateful that you were a 
volunteer to make the contribution to this project, but things change and you 
may no longer be able to finalize your contribution.
 Could you respond to this email and indicate if you wish to continue and fix 
test failures or step down and some committer may revert you commit. 

 *New stable failure of a flaky test in master 
CacheMvccTransactionsTest.testMvccCoordinatorChangeSimple 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-6927219027805352920&branch=%3Cdefault%3E&tab=testDetails
 Changes may lead to failure were done by 
 - zaleslaw.sin 
http://ci.ignite.apache.org/viewModification.html?modId=833094&personal=false
 - zaleslaw.sin 
http://ci.ignite.apache.org/viewModification.html?modId=833090&personal=false
 - andrey.mashenkov 
http://ci.ignite.apache.org/viewModification.html?modId=833088&personal=false

 - Here's a reminder of what contributors were agreed to do 
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute 
 - Should you have any questions please contact dev@ignite.apache.org 

Best Regards,
Apache Ignite TeamCity Bot 
https://github.com/apache/ignite-teamcity-bot
Notification generated at 06:19:09 29-09-2018 

[MTCGA]: new failures in builds [1962099] needs to be handled

[dpavlov . tasks]

Hi Igniters,

 I've detected some new issue on TeamCity to be handled. You are more than 
welcomed to help.

 If your changes can lead to this failure(s): We're grateful that you were a 
volunteer to make the contribution to this project, but things change and you 
may no longer be able to finalize your contribution.
 Could you respond to this email and indicate if you wish to continue and fix 
test failures or step down and some committer may revert you commit. 

 *New stable failure of a flaky test in master 
CacheMvccPartitionedSelectForUpdateQueryTest.testSelectForUpdateDistributed 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=1496338037056950397&branch=%3Cdefault%3E&tab=testDetails

 *New stable failure of a flaky test in master 
CacheMvccReplicatedSelectForUpdateQueryTest.testSelectForUpdateDistributed 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-8174311597321065407&branch=%3Cdefault%3E&tab=testDetails
 Changes may lead to failure were done by 
 - zaleslaw.sin 
http://ci.ignite.apache.org/viewModification.html?modId=833094&personal=false
 - zaleslaw.sin 
http://ci.ignite.apache.org/viewModification.html?modId=833090&personal=false
 - andrey.mashenkov 
http://ci.ignite.apache.org/viewModification.html?modId=833088&personal=false

 - Here's a reminder of what contributors were agreed to do 
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute 
 - Should you have any questions please contact dev@ignite.apache.org 

Best Regards,
Apache Ignite TeamCity Bot 
https://github.com/apache/ignite-teamcity-bot
Notification generated at 06:34:22 29-09-2018 

Re: Apache Ignite 2.7 release

[Vyacheslav Daradur]

Dmitriy,

Hot redeployment and versioning will not be implemented in phase 1,
but it is scheduled once it is finished.

Here is an umbrella ticket [1] to track phase 1 scope.

It includes very few new features, but we completely rework component
to improve guarantees to be more reliable and we build the base for
new features.

[1] https://issues.apache.org/jira/browse/IGNITE-9607
On Fri, Sep 28, 2018 at 9:38 PM Dmitriy Setrakyan  wrote:
>
> I am not sure I can agree. SG redesign includes:
> - hot redeployment
> - versioning
>
> In my experience, features like these take about 1 month to test properly
> and fix all the bugs, including redeployment tests and restart tests on
> larger topologies, together with overnight runs. If this type of testing
> has not been performed, I think it would be unreasonable to expect this
> feature making it into the release.
>
> Can someone comment on the testing?
>
> D.
>
>
> On Fri, Sep 28, 2018 at 10:38 AM Dmitriy Pavlov 
> wrote:
>
> > Nikolay, because I think you're a do'er, but not a commenter, like me, for
> > example, I can trust your opinion.
> >
> > I will join review if I have spare cycles.
> >
> > пт, 28 сент. 2018 г. в 20:34, Denis Magda :
> >
> > > Nikolay,
> > >
> > > Thanks for stepping in and giving more context. In general, I'm fully for
> > > your proposal below:
> > >
> > > My vote goes to option *a*.
> > > > I think we should release 2.7 with the bunch of new cool features.
> > > > *AND* we should plan 2.8 release at the end of the year with SG
> > redesign
> > > > and MVCC stabilization tasks.
> > >
> > >
> > > --
> > > Denis
> > >
> > > On Fri, Sep 28, 2018 at 10:30 AM Nikolay Izhikov 
> > > wrote:
> > >
> > > > Hello, Igniters.
> > > >
> > > > I think we shouldn't put so many emotions in discussion of any
> > > > contribution.
> > > > Even so big and important as SG redesign.
> > > >
> > > > The crucial point we all agreed about: Service Grid redesign a big
> > > feature
> > > > that can significally improve Ignite.
> > > > We all want to have it in the product.
> > > >
> > > > Let me write my vision of the current task state:
> > > >
> > > > 1. Design of SG is discussed *and aligned* both: privately with Ignite
> > > > experts(Vladimir Ozerov, Alexey Goncharyuk, Anton Vinogradov, Denis
> > > > Mekhanikov)
> > > > and publicly on dev-list. This task is done.
> > > >
> > > > 2. Current PR state - *on my review*.
> > > > I spend some time with this contribution and gave Vyacheslav a
> > feedback.
> > > > I expect he can fix my comments in a day or two.
> > > > Seem we can ask of Anton Vinogradov review on the beginning of next
> > week.
> > > >
> > > > If Dmitriy or any community member wants to help *by doing things, not
> > > > discussing them on dev-list*.
> > > > Please, join to the review - you are welcome. PR is here [1]
> > > >
> > > > 3. I think, we have two mutually exclusive options regarding of release
> > > > 2.7
> > > > a. We release 2.7 in planned dates.
> > > > b. We include SG in release scope.
> > > >
> > > > My vote goes to option *a*.
> > > > I think we should release 2.7 with the bunch of new cool features.
> > > > *AND* we should plan 2.8 release at the end of the year with SG
> > redesign
> > > > and MVCC stabilization tasks.
> > > >
> > > > Anyway, while we preparing release a lot of things can happen.
> > > > Let's come back to discussion of SG release version *when it will be
> > > ready
> > > > to be merged to master*.
> > > >
> > > > Guys, does it makes sense for you?
> > > >
> > > > [1] https://github.com/apache/ignite/pull/4434
> > > >
> > > > В Пт, 28/09/2018 в 19:47 +0300, Dmitriy Pavlov пишет:
> > > > > Hi Dmitriy,
> > > > >
> > > > > The design is aligned totally. The thread you mention was not named
> > > > > properly.
> > > > >
> > > > > It seems to me some community members are trying to take over the
> > > > community
> > > > > and lead it instead of doing.
> > > > >
> > > > > As a member of the Apache community, I value Do-ocracy and power of
> > > those
> > > > > who do, but not just disagree. There are no leaders in open source,
> > > just
> > > > > do'ers.
> > > > >
> > > > > By do'ers here I mean Nikolay and Vyacheslav. For me, their
> > conclusion
> > > > has
> > > > > more weight here. If Vladimir is ready to lead an additional release
> > > for
> > > > SG
> > > > > and SG developers agree, it works for me.
> > > > >
> > > > > Sincerely,
> > > > > Dmitriy Pavlov
> > > > >
> > > > >
> > > > > пт, 28 сент. 2018 г. в 19:39, Dmitriy Setrakyan <
> > dsetrak...@apache.org
> > > >:
> > > > >
> > > > > > Dmitriy,
> > > > > >
> > > > > > We agreed in the beginning of this thread that Service Grid changes
> > > > are not
> > > > > > going to make the release because the community still did not
> > approve
> > > > the
> > > > > > design. Nothing has changed since. I have not seen any design
> > > > discussions.
> > > > > > At this point, I have no confidence that the Service Grid changes
> > > will
> > >