Re: Re[4]: Apache Ignite 2.7.6 (Time, Scope, and Release manager)

[Zhenya Stanilovsky]

Dmitriy, review passed, plz proceed.
thanks !

I removed  https://issues.apache.org/jira/browse/IGNITE-12032 until  
nobody

volunteer to complete the task.

Evgeniy, please keep me updated about IGNITE-12061.

чт, 15 авг. 2019 г. в 16:56, Zhenya Stanilovsky  

:



yep, i`l try to call someone who probably familiar with this problem.

>
>
>Ok, I've removed Spark from the scope.
>
>What about the unassigned issue related to ODBC? It is not looking like
>somebody will fix it before release.
>
>Evgeniy Stanilovsky, what about
>https://issues.apache.org/jira/browse/IGNITE-12061
>< https://issues.apache.org/jira/browse/IGNITE-12061?src=confmacro >
>do you have someone to review the fix?
>
>чт, 15 авг. 2019 г. в 16:05, Denis Magda < dma...@apache.org >:
>
>> Dmitry,
>>
>> It would be better for us to put off the Spark upgrade until 2.8 as
Nikolay
>> suggested. Let's release 2.7.6 as quickly as possible to let roll out
fixes
>> for the critical issues from the scope.
>>
>>
>> -
>> Denis
>>
>>
>> On Thu, Aug 15, 2019 at 3:29 PM Dmitriy Pavlov < dpav...@apache.org >
wrote:
>>
>> > Nikolay, how long does it take to update? I will be traveling from  
28

Aug
>> > till 16 Sept. We can select new dates for release if the majority  
of

>> fixes
>> > can be done by 16 Sept, but can't be by 20 Aug. Denis, please share
your
>> > vision about selecting new dates.
>> >
>> > *Voting Date: *Sept 18, 2019
>> >
>> > *Release Date: *Sept 23, 2019
>> >
>> > Issue  https://issues.apache.org/jira/browse/IGNITE-12032
>> > < https://issues.apache.org/jira/browse/IGNITE-12032?src=confmacro  
>

is
>> > still
>> > unassigned: Server node prints exception when ODBC driver  
disconnects

>> > Igniters, who would like to pick up it? By default, I'm going to
remove
>> it
>> > from release
>> >
>> >
>> > чт, 15 авг. 2019 г. в 14:54, Nikolay Izhikov < nizhi...@apache.org  
>:

>> >
>> > > Hello, Igniters.
>> > >
>> > > I try to upgrade Spark version but failed.
>> > >
>> > > Seems, internal Spark API(External Catalog, SQL planner) that we  
use

>> > > changed a lot.
>> > > So it will take some time to upgrade version.
>> > >
>> > > For now, I work hard to complete the second phase of IEP-35 so I
>> postpone
>> > > upgrade Spark version to Ignite 2.8.
>> > >
>> > > В Чт, 15/08/2019 в 14:51 +0300, Dmitriy Pavlov пишет:
>> > > > Hi Denis,
>> > > >
>> > > > Sure, since code freeze is planned for today, I don't mind to
include
>> > > this
>> > > > bug.
>> > > >
>> > > > Ivan, could you complete this issue by 20 August?
>> > > >
>> > > > BTW #1, Dmitriy Govoruchnin, please reply about commit for
>> > > >   
https://issues.apache.org/jira/browse/IGNITE-11953?src=confmacro

>> > > >
>> > > > BTW #2, FYI, release page is now available here
>> > > >
>>   
https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.7.6

>> > > >
>> > > > BTW #3, FYI, release related test PR is here
>> > > >  https://github.com/apache/ignite/pull/6775 and it's TC Bot
report is
>> > > here:
>> > > >
>> > >
>> >
>>
https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=ignite-2.7.6=Latest=ignite-2.7.6
>> > > >
>> > > >
>> > > > чт, 15 авг. 2019 г. в 13:55, Denis Magda < dma...@apache.org >:
>> > > >
>> > > > > An Ignite user just reported a silly issue that needs to be
fixed
>> in
>> > > 2.7.6:
>> > > > >  https://issues.apache.org/jira/browse/IGNITE-12068
>> > > > >
>> > > > > More details and context:
>> > > > >
>> > > > >
>> > >
>> >
>>
https://stackoverflow.com/questions/57479636/simple-select-query-missing-rows-in-ignite
>> > > > >
>> > > > > Ivan, please help us to make it to the release.
>> > > > >
>> > > > > -
>> > > > > Denis
>> > > > >
>> > > > >
>> > > > > On Tue, Aug 13, 2019 at 6:47 AM Denis Magda <  
dma...@apache.org

>
>> > wrote:
>> > > > >
>> > > > > > IGNITE-12507 (Persistence files are stored to temp dir) has
>> > > definitely be
>> > > > > > added the scope and treated one of the main release  
drivers.

>> > > > > >
>> > > > > > Dmitry, please let us know once the release wiki page is
ready so
>> > > that we
>> > > > > > can finalize the timelines based on chosen scope.
>> > > > > >
>> > > > > > -
>> > > > > > Denis
>> > > > > >
>> > > > > >
>> > > > > > On Mon, Aug 12, 2019 at 7:12 PM Dmitriy Pavlov <
>>  dpav...@apache.org
>> > >
>> > > > >
>> > > > > wrote:
>> > > > > >
>> > > > > > > Hi,
>> > > > > > >
>> > > > > > > Thanks to everyone, who participated in the discussion.
>> > > > > > >
>> > > > > > > I would like to wait also fix for
>> > > > > > >  https://issues.apache.org/jira/browse/IGNITE-12057
>> > > > > > >
>> > > > > > > and discussion results for that issue:
>> > > > > > >
>> > > > > > >
>> > > > >
>> > > > >
>> > >
>> >
>>
https://lists.apache.org/thread.html/498a14b3971950a45ef57f45cc23d2438ce1afba000b586e230927bf@%3Cdev.ignite.apache.org%3E
>> > > > > > >
>> > > > > > >
>> > > > > > > Since some issues are still open, we'll probably move  
some

>> dates
>> > > > >
>> > > > > forward,
>> > > > > > > 

[jira] [Created] (IGNITE-12077) Improve Checkstyle or other inspections profile to avoid using GG- reference in Ignite code base

[Dmitriy Pavlov (JIRA)]

Dmitriy Pavlov created IGNITE-12077:
---

 Summary: Improve Checkstyle or other inspections profile to avoid 
using GG- reference in Ignite code base
 Key: IGNITE-12077
 URL: https://issues.apache.org/jira/browse/IGNITE-12077
 Project: Ignite
  Issue Type: Test
Reporter: Dmitriy Pavlov


Time to time tests are Ignored or todo added with reference to 
 GG-  tickets "
For example here
https://github.com/apache/ignite/pull/6748/files#diff-2dd1dad039cddd36610c62a3dc2c1a28R223

It is suggested to add some inspection check on TC to reject patches if there 
is a line 
containing: 
- ": //ggsystems.atlassian.net/" 
- or at the same time Ignore or todo and "GG- [0-9] *" 



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

Re: Re[4]: Apache Ignite 2.7.6 (Time, Scope, and Release manager)

[Dmitriy Pavlov]

Sorry, it was too easy to do, no need to ask Maxim.

Cherry-picked to 2.7.6,
https://github.com/apache/ignite/commit/891e49fe1eeb28bc6b655024086c3f4d1324fda4

чт, 15 авг. 2019 г. в 19:02, Dmitriy Pavlov :

> Hi Ilya,
>
> I bypassed this problem in the Tc bot by
> "triggerBuild": true,
> "triggerBuildQuietPeriod": 480,  //triggering quiet period in minutes, 2
> builds per day
> "triggerParameters": [
>   {
> "name": "reverse.dep.*.IGNITE_LOGGING_OPTS",
> "value": "-DIGNITE_QUIET=false"
>   }
> ]
>
> But if is test code only, and Maxim would port it, it is a good thing to
> be there.
>
> Maxim, would you do it?
>
> Sincerely,
> Dmitriy Pavlov
>
> чт, 15 авг. 2019 г. в 18:56, Ilya Kasnacheev :
>
>> Hello!
>>
>> I suggest also including IGNITE-11736, otherwise we are going to run into
>> problems each time TC is invoked.
>>
>> https://issues.apache.org/jira/browse/IGNITE-11736
>>
>> Regards,
>> --
>> Ilya Kasnacheev
>>
>>
>> чт, 15 авг. 2019 г. в 16:56, Zhenya Stanilovsky
>> > >:
>>
>> > yep, i`l try to call someone who probably familiar with this problem.
>> >
>> > >
>> > >
>> > >Ok, I've removed Spark from the scope.
>> > >
>> > >What about the unassigned issue related to ODBC? It is not looking like
>> > >somebody will fix it before release.
>> > >
>> > >Evgeniy Stanilovsky, what about
>> > >https://issues.apache.org/jira/browse/IGNITE-12061
>> > >< https://issues.apache.org/jira/browse/IGNITE-12061?src=confmacro >
>> > >do you have someone to review the fix?
>> > >
>> > >чт, 15 авг. 2019 г. в 16:05, Denis Magda < dma...@apache.org >:
>> > >
>> > >> Dmitry,
>> > >>
>> > >> It would be better for us to put off the Spark upgrade until 2.8 as
>> > Nikolay
>> > >> suggested. Let's release 2.7.6 as quickly as possible to let roll out
>> > fixes
>> > >> for the critical issues from the scope.
>> > >>
>> > >>
>> > >> -
>> > >> Denis
>> > >>
>> > >>
>> > >> On Thu, Aug 15, 2019 at 3:29 PM Dmitriy Pavlov < dpav...@apache.org
>> >
>> > wrote:
>> > >>
>> > >> > Nikolay, how long does it take to update? I will be traveling from
>> 28
>> > Aug
>> > >> > till 16 Sept. We can select new dates for release if the majority
>> of
>> > >> fixes
>> > >> > can be done by 16 Sept, but can't be by 20 Aug. Denis, please share
>> > your
>> > >> > vision about selecting new dates.
>> > >> >
>> > >> > *Voting Date: *Sept 18, 2019
>> > >> >
>> > >> > *Release Date: *Sept 23, 2019
>> > >> >
>> > >> > Issue  https://issues.apache.org/jira/browse/IGNITE-12032
>> > >> > < https://issues.apache.org/jira/browse/IGNITE-12032?src=confmacro
>> >
>> > is
>> > >> > still
>> > >> > unassigned: Server node prints exception when ODBC driver
>> disconnects
>> > >> > Igniters, who would like to pick up it? By default, I'm going to
>> > remove
>> > >> it
>> > >> > from release
>> > >> >
>> > >> >
>> > >> > чт, 15 авг. 2019 г. в 14:54, Nikolay Izhikov < nizhi...@apache.org
>> >:
>> > >> >
>> > >> > > Hello, Igniters.
>> > >> > >
>> > >> > > I try to upgrade Spark version but failed.
>> > >> > >
>> > >> > > Seems, internal Spark API(External Catalog, SQL planner) that we
>> use
>> > >> > > changed a lot.
>> > >> > > So it will take some time to upgrade version.
>> > >> > >
>> > >> > > For now, I work hard to complete the second phase of IEP-35 so I
>> > >> postpone
>> > >> > > upgrade Spark version to Ignite 2.8.
>> > >> > >
>> > >> > > В Чт, 15/08/2019 в 14:51 +0300, Dmitriy Pavlov пишет:
>> > >> > > > Hi Denis,
>> > >> > > >
>> > >> > > > Sure, since code freeze is planned for today, I don't mind to
>> > include
>> > >> > > this
>> > >> > > > bug.
>> > >> > > >
>> > >> > > > Ivan, could you complete this issue by 20 August?
>> > >> > > >
>> > >> > > > BTW #1, Dmitriy Govoruchnin, please reply about commit for
>> > >> > > >
>> https://issues.apache.org/jira/browse/IGNITE-11953?src=confmacro
>> > >> > > >
>> > >> > > > BTW #2, FYI, release page is now available here
>> > >> > > >
>> > >>
>> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.7.6
>> > >> > > >
>> > >> > > > BTW #3, FYI, release related test PR is here
>> > >> > > >  https://github.com/apache/ignite/pull/6775 and it's TC Bot
>> > report is
>> > >> > > here:
>> > >> > > >
>> > >> > >
>> > >> >
>> > >>
>> >
>> https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=ignite-2.7.6=Latest=ignite-2.7.6
>> > >> > > >
>> > >> > > >
>> > >> > > > чт, 15 авг. 2019 г. в 13:55, Denis Magda < dma...@apache.org
>> >:
>> > >> > > >
>> > >> > > > > An Ignite user just reported a silly issue that needs to be
>> > fixed
>> > >> in
>> > >> > > 2.7.6:
>> > >> > > > >  https://issues.apache.org/jira/browse/IGNITE-12068
>> > >> > > > >
>> > >> > > > > More details and context:
>> > >> > > > >
>> > >> > > > >
>> > >> > >
>> > >> >
>> > >>
>> >
>> https://stackoverflow.com/questions/57479636/simple-select-query-missing-rows-in-ignite
>> > >> > > > >
>> > >> > > > > Ivan, please help us to make it to the release.
>> > >> > > > >
>> > >> > > > > -
>> > >> > > > > Denis
>> 

Re: Re[4]: Apache Ignite 2.7.6 (Time, Scope, and Release manager)

[Dmitriy Pavlov]

Hi Ilya,

I bypassed this problem in the Tc bot by
"triggerBuild": true,
"triggerBuildQuietPeriod": 480,  //triggering quiet period in minutes, 2
builds per day
"triggerParameters": [
  {
"name": "reverse.dep.*.IGNITE_LOGGING_OPTS",
"value": "-DIGNITE_QUIET=false"
  }
]

But if is test code only, and Maxim would port it, it is a good thing to be
there.

Maxim, would you do it?

Sincerely,
Dmitriy Pavlov

чт, 15 авг. 2019 г. в 18:56, Ilya Kasnacheev :

> Hello!
>
> I suggest also including IGNITE-11736, otherwise we are going to run into
> problems each time TC is invoked.
>
> https://issues.apache.org/jira/browse/IGNITE-11736
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> чт, 15 авг. 2019 г. в 16:56, Zhenya Stanilovsky  >:
>
> > yep, i`l try to call someone who probably familiar with this problem.
> >
> > >
> > >
> > >Ok, I've removed Spark from the scope.
> > >
> > >What about the unassigned issue related to ODBC? It is not looking like
> > >somebody will fix it before release.
> > >
> > >Evgeniy Stanilovsky, what about
> > >https://issues.apache.org/jira/browse/IGNITE-12061
> > >< https://issues.apache.org/jira/browse/IGNITE-12061?src=confmacro >
> > >do you have someone to review the fix?
> > >
> > >чт, 15 авг. 2019 г. в 16:05, Denis Magda < dma...@apache.org >:
> > >
> > >> Dmitry,
> > >>
> > >> It would be better for us to put off the Spark upgrade until 2.8 as
> > Nikolay
> > >> suggested. Let's release 2.7.6 as quickly as possible to let roll out
> > fixes
> > >> for the critical issues from the scope.
> > >>
> > >>
> > >> -
> > >> Denis
> > >>
> > >>
> > >> On Thu, Aug 15, 2019 at 3:29 PM Dmitriy Pavlov < dpav...@apache.org >
> > wrote:
> > >>
> > >> > Nikolay, how long does it take to update? I will be traveling from
> 28
> > Aug
> > >> > till 16 Sept. We can select new dates for release if the majority of
> > >> fixes
> > >> > can be done by 16 Sept, but can't be by 20 Aug. Denis, please share
> > your
> > >> > vision about selecting new dates.
> > >> >
> > >> > *Voting Date: *Sept 18, 2019
> > >> >
> > >> > *Release Date: *Sept 23, 2019
> > >> >
> > >> > Issue  https://issues.apache.org/jira/browse/IGNITE-12032
> > >> > < https://issues.apache.org/jira/browse/IGNITE-12032?src=confmacro
> >
> > is
> > >> > still
> > >> > unassigned: Server node prints exception when ODBC driver
> disconnects
> > >> > Igniters, who would like to pick up it? By default, I'm going to
> > remove
> > >> it
> > >> > from release
> > >> >
> > >> >
> > >> > чт, 15 авг. 2019 г. в 14:54, Nikolay Izhikov < nizhi...@apache.org
> >:
> > >> >
> > >> > > Hello, Igniters.
> > >> > >
> > >> > > I try to upgrade Spark version but failed.
> > >> > >
> > >> > > Seems, internal Spark API(External Catalog, SQL planner) that we
> use
> > >> > > changed a lot.
> > >> > > So it will take some time to upgrade version.
> > >> > >
> > >> > > For now, I work hard to complete the second phase of IEP-35 so I
> > >> postpone
> > >> > > upgrade Spark version to Ignite 2.8.
> > >> > >
> > >> > > В Чт, 15/08/2019 в 14:51 +0300, Dmitriy Pavlov пишет:
> > >> > > > Hi Denis,
> > >> > > >
> > >> > > > Sure, since code freeze is planned for today, I don't mind to
> > include
> > >> > > this
> > >> > > > bug.
> > >> > > >
> > >> > > > Ivan, could you complete this issue by 20 August?
> > >> > > >
> > >> > > > BTW #1, Dmitriy Govoruchnin, please reply about commit for
> > >> > > >
> https://issues.apache.org/jira/browse/IGNITE-11953?src=confmacro
> > >> > > >
> > >> > > > BTW #2, FYI, release page is now available here
> > >> > > >
> > >>
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.7.6
> > >> > > >
> > >> > > > BTW #3, FYI, release related test PR is here
> > >> > > >  https://github.com/apache/ignite/pull/6775 and it's TC Bot
> > report is
> > >> > > here:
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=ignite-2.7.6=Latest=ignite-2.7.6
> > >> > > >
> > >> > > >
> > >> > > > чт, 15 авг. 2019 г. в 13:55, Denis Magda < dma...@apache.org >:
> > >> > > >
> > >> > > > > An Ignite user just reported a silly issue that needs to be
> > fixed
> > >> in
> > >> > > 2.7.6:
> > >> > > > >  https://issues.apache.org/jira/browse/IGNITE-12068
> > >> > > > >
> > >> > > > > More details and context:
> > >> > > > >
> > >> > > > >
> > >> > >
> > >> >
> > >>
> >
> https://stackoverflow.com/questions/57479636/simple-select-query-missing-rows-in-ignite
> > >> > > > >
> > >> > > > > Ivan, please help us to make it to the release.
> > >> > > > >
> > >> > > > > -
> > >> > > > > Denis
> > >> > > > >
> > >> > > > >
> > >> > > > > On Tue, Aug 13, 2019 at 6:47 AM Denis Magda <
> dma...@apache.org
> > >
> > >> > wrote:
> > >> > > > >
> > >> > > > > > IGNITE-12507 (Persistence files are stored to temp dir) has
> > >> > > definitely be
> > >> > > > > > added the scope and treated one of the main release drivers.
> > >> > > > > >
> > >> > > > > > Dmitry, please let us know once the 

Re: Re[4]: Apache Ignite 2.7.6 (Time, Scope, and Release manager)

[Ilya Kasnacheev]

Hello!

I suggest also including IGNITE-11736, otherwise we are going to run into
problems each time TC is invoked.

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

Regards,
-- 
Ilya Kasnacheev


чт, 15 авг. 2019 г. в 16:56, Zhenya Stanilovsky :

> yep, i`l try to call someone who probably familiar with this problem.
>
> >
> >
> >Ok, I've removed Spark from the scope.
> >
> >What about the unassigned issue related to ODBC? It is not looking like
> >somebody will fix it before release.
> >
> >Evgeniy Stanilovsky, what about
> >https://issues.apache.org/jira/browse/IGNITE-12061
> >< https://issues.apache.org/jira/browse/IGNITE-12061?src=confmacro >
> >do you have someone to review the fix?
> >
> >чт, 15 авг. 2019 г. в 16:05, Denis Magda < dma...@apache.org >:
> >
> >> Dmitry,
> >>
> >> It would be better for us to put off the Spark upgrade until 2.8 as
> Nikolay
> >> suggested. Let's release 2.7.6 as quickly as possible to let roll out
> fixes
> >> for the critical issues from the scope.
> >>
> >>
> >> -
> >> Denis
> >>
> >>
> >> On Thu, Aug 15, 2019 at 3:29 PM Dmitriy Pavlov < dpav...@apache.org >
> wrote:
> >>
> >> > Nikolay, how long does it take to update? I will be traveling from 28
> Aug
> >> > till 16 Sept. We can select new dates for release if the majority of
> >> fixes
> >> > can be done by 16 Sept, but can't be by 20 Aug. Denis, please share
> your
> >> > vision about selecting new dates.
> >> >
> >> > *Voting Date: *Sept 18, 2019
> >> >
> >> > *Release Date: *Sept 23, 2019
> >> >
> >> > Issue  https://issues.apache.org/jira/browse/IGNITE-12032
> >> > < https://issues.apache.org/jira/browse/IGNITE-12032?src=confmacro >
> is
> >> > still
> >> > unassigned: Server node prints exception when ODBC driver disconnects
> >> > Igniters, who would like to pick up it? By default, I'm going to
> remove
> >> it
> >> > from release
> >> >
> >> >
> >> > чт, 15 авг. 2019 г. в 14:54, Nikolay Izhikov < nizhi...@apache.org >:
> >> >
> >> > > Hello, Igniters.
> >> > >
> >> > > I try to upgrade Spark version but failed.
> >> > >
> >> > > Seems, internal Spark API(External Catalog, SQL planner) that we use
> >> > > changed a lot.
> >> > > So it will take some time to upgrade version.
> >> > >
> >> > > For now, I work hard to complete the second phase of IEP-35 so I
> >> postpone
> >> > > upgrade Spark version to Ignite 2.8.
> >> > >
> >> > > В Чт, 15/08/2019 в 14:51 +0300, Dmitriy Pavlov пишет:
> >> > > > Hi Denis,
> >> > > >
> >> > > > Sure, since code freeze is planned for today, I don't mind to
> include
> >> > > this
> >> > > > bug.
> >> > > >
> >> > > > Ivan, could you complete this issue by 20 August?
> >> > > >
> >> > > > BTW #1, Dmitriy Govoruchnin, please reply about commit for
> >> > > >  https://issues.apache.org/jira/browse/IGNITE-11953?src=confmacro
> >> > > >
> >> > > > BTW #2, FYI, release page is now available here
> >> > > >
> >>  https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.7.6
> >> > > >
> >> > > > BTW #3, FYI, release related test PR is here
> >> > > >  https://github.com/apache/ignite/pull/6775 and it's TC Bot
> report is
> >> > > here:
> >> > > >
> >> > >
> >> >
> >>
> https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=ignite-2.7.6=Latest=ignite-2.7.6
> >> > > >
> >> > > >
> >> > > > чт, 15 авг. 2019 г. в 13:55, Denis Magda < dma...@apache.org >:
> >> > > >
> >> > > > > An Ignite user just reported a silly issue that needs to be
> fixed
> >> in
> >> > > 2.7.6:
> >> > > > >  https://issues.apache.org/jira/browse/IGNITE-12068
> >> > > > >
> >> > > > > More details and context:
> >> > > > >
> >> > > > >
> >> > >
> >> >
> >>
> https://stackoverflow.com/questions/57479636/simple-select-query-missing-rows-in-ignite
> >> > > > >
> >> > > > > Ivan, please help us to make it to the release.
> >> > > > >
> >> > > > > -
> >> > > > > Denis
> >> > > > >
> >> > > > >
> >> > > > > On Tue, Aug 13, 2019 at 6:47 AM Denis Magda < dma...@apache.org
> >
> >> > wrote:
> >> > > > >
> >> > > > > > IGNITE-12507 (Persistence files are stored to temp dir) has
> >> > > definitely be
> >> > > > > > added the scope and treated one of the main release drivers.
> >> > > > > >
> >> > > > > > Dmitry, please let us know once the release wiki page is
> ready so
> >> > > that we
> >> > > > > > can finalize the timelines based on chosen scope.
> >> > > > > >
> >> > > > > > -
> >> > > > > > Denis
> >> > > > > >
> >> > > > > >
> >> > > > > > On Mon, Aug 12, 2019 at 7:12 PM Dmitriy Pavlov <
> >>  dpav...@apache.org
> >> > >
> >> > > > >
> >> > > > > wrote:
> >> > > > > >
> >> > > > > > > Hi,
> >> > > > > > >
> >> > > > > > > Thanks to everyone, who participated in the discussion.
> >> > > > > > >
> >> > > > > > > I would like to wait also fix for
> >> > > > > > >  https://issues.apache.org/jira/browse/IGNITE-12057
> >> > > > > > >
> >> > > > > > > and discussion results for that issue:
> >> > > > > > >
> >> > > > > > >
> >> > > > >
> >> > > > >
> >> > >
> >> >
> >>
> 

Re: Re[4]: Apache Ignite 2.7.6 (Time, Scope, and Release manager)

[Dmitriy Pavlov]

I removed  https://issues.apache.org/jira/browse/IGNITE-12032 until nobody
volunteer to complete the task.

Evgeniy, please keep me updated about IGNITE-12061.

чт, 15 авг. 2019 г. в 16:56, Zhenya Stanilovsky :

> yep, i`l try to call someone who probably familiar with this problem.
>
> >
> >
> >Ok, I've removed Spark from the scope.
> >
> >What about the unassigned issue related to ODBC? It is not looking like
> >somebody will fix it before release.
> >
> >Evgeniy Stanilovsky, what about
> >https://issues.apache.org/jira/browse/IGNITE-12061
> >< https://issues.apache.org/jira/browse/IGNITE-12061?src=confmacro >
> >do you have someone to review the fix?
> >
> >чт, 15 авг. 2019 г. в 16:05, Denis Magda < dma...@apache.org >:
> >
> >> Dmitry,
> >>
> >> It would be better for us to put off the Spark upgrade until 2.8 as
> Nikolay
> >> suggested. Let's release 2.7.6 as quickly as possible to let roll out
> fixes
> >> for the critical issues from the scope.
> >>
> >>
> >> -
> >> Denis
> >>
> >>
> >> On Thu, Aug 15, 2019 at 3:29 PM Dmitriy Pavlov < dpav...@apache.org >
> wrote:
> >>
> >> > Nikolay, how long does it take to update? I will be traveling from 28
> Aug
> >> > till 16 Sept. We can select new dates for release if the majority of
> >> fixes
> >> > can be done by 16 Sept, but can't be by 20 Aug. Denis, please share
> your
> >> > vision about selecting new dates.
> >> >
> >> > *Voting Date: *Sept 18, 2019
> >> >
> >> > *Release Date: *Sept 23, 2019
> >> >
> >> > Issue  https://issues.apache.org/jira/browse/IGNITE-12032
> >> > < https://issues.apache.org/jira/browse/IGNITE-12032?src=confmacro >
> is
> >> > still
> >> > unassigned: Server node prints exception when ODBC driver disconnects
> >> > Igniters, who would like to pick up it? By default, I'm going to
> remove
> >> it
> >> > from release
> >> >
> >> >
> >> > чт, 15 авг. 2019 г. в 14:54, Nikolay Izhikov < nizhi...@apache.org >:
> >> >
> >> > > Hello, Igniters.
> >> > >
> >> > > I try to upgrade Spark version but failed.
> >> > >
> >> > > Seems, internal Spark API(External Catalog, SQL planner) that we use
> >> > > changed a lot.
> >> > > So it will take some time to upgrade version.
> >> > >
> >> > > For now, I work hard to complete the second phase of IEP-35 so I
> >> postpone
> >> > > upgrade Spark version to Ignite 2.8.
> >> > >
> >> > > В Чт, 15/08/2019 в 14:51 +0300, Dmitriy Pavlov пишет:
> >> > > > Hi Denis,
> >> > > >
> >> > > > Sure, since code freeze is planned for today, I don't mind to
> include
> >> > > this
> >> > > > bug.
> >> > > >
> >> > > > Ivan, could you complete this issue by 20 August?
> >> > > >
> >> > > > BTW #1, Dmitriy Govoruchnin, please reply about commit for
> >> > > >  https://issues.apache.org/jira/browse/IGNITE-11953?src=confmacro
> >> > > >
> >> > > > BTW #2, FYI, release page is now available here
> >> > > >
> >>  https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.7.6
> >> > > >
> >> > > > BTW #3, FYI, release related test PR is here
> >> > > >  https://github.com/apache/ignite/pull/6775 and it's TC Bot
> report is
> >> > > here:
> >> > > >
> >> > >
> >> >
> >>
> https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=ignite-2.7.6=Latest=ignite-2.7.6
> >> > > >
> >> > > >
> >> > > > чт, 15 авг. 2019 г. в 13:55, Denis Magda < dma...@apache.org >:
> >> > > >
> >> > > > > An Ignite user just reported a silly issue that needs to be
> fixed
> >> in
> >> > > 2.7.6:
> >> > > > >  https://issues.apache.org/jira/browse/IGNITE-12068
> >> > > > >
> >> > > > > More details and context:
> >> > > > >
> >> > > > >
> >> > >
> >> >
> >>
> https://stackoverflow.com/questions/57479636/simple-select-query-missing-rows-in-ignite
> >> > > > >
> >> > > > > Ivan, please help us to make it to the release.
> >> > > > >
> >> > > > > -
> >> > > > > Denis
> >> > > > >
> >> > > > >
> >> > > > > On Tue, Aug 13, 2019 at 6:47 AM Denis Magda < dma...@apache.org
> >
> >> > wrote:
> >> > > > >
> >> > > > > > IGNITE-12507 (Persistence files are stored to temp dir) has
> >> > > definitely be
> >> > > > > > added the scope and treated one of the main release drivers.
> >> > > > > >
> >> > > > > > Dmitry, please let us know once the release wiki page is
> ready so
> >> > > that we
> >> > > > > > can finalize the timelines based on chosen scope.
> >> > > > > >
> >> > > > > > -
> >> > > > > > Denis
> >> > > > > >
> >> > > > > >
> >> > > > > > On Mon, Aug 12, 2019 at 7:12 PM Dmitriy Pavlov <
> >>  dpav...@apache.org
> >> > >
> >> > > > >
> >> > > > > wrote:
> >> > > > > >
> >> > > > > > > Hi,
> >> > > > > > >
> >> > > > > > > Thanks to everyone, who participated in the discussion.
> >> > > > > > >
> >> > > > > > > I would like to wait also fix for
> >> > > > > > >  https://issues.apache.org/jira/browse/IGNITE-12057
> >> > > > > > >
> >> > > > > > > and discussion results for that issue:
> >> > > > > > >
> >> > > > > > >
> >> > > > >
> >> > > > >
> >> > >
> >> >
> >>
> 

Re[4]: Apache Ignite 2.7.6 (Time, Scope, and Release manager)

[Zhenya Stanilovsky]

yep, i`l try to call someone who probably familiar with this problem.

>
>
>Ok, I've removed Spark from the scope.
>
>What about the unassigned issue related to ODBC? It is not looking like
>somebody will fix it before release.
>
>Evgeniy Stanilovsky, what about
>https://issues.apache.org/jira/browse/IGNITE-12061
>< https://issues.apache.org/jira/browse/IGNITE-12061?src=confmacro >
>do you have someone to review the fix?
>
>чт, 15 авг. 2019 г. в 16:05, Denis Magda < dma...@apache.org >:
>
>> Dmitry,
>>
>> It would be better for us to put off the Spark upgrade until 2.8 as Nikolay
>> suggested. Let's release 2.7.6 as quickly as possible to let roll out fixes
>> for the critical issues from the scope.
>>
>>
>> -
>> Denis
>>
>>
>> On Thu, Aug 15, 2019 at 3:29 PM Dmitriy Pavlov < dpav...@apache.org > wrote:
>>
>> > Nikolay, how long does it take to update? I will be traveling from 28 Aug
>> > till 16 Sept. We can select new dates for release if the majority of
>> fixes
>> > can be done by 16 Sept, but can't be by 20 Aug. Denis, please share your
>> > vision about selecting new dates.
>> >
>> > *Voting Date: *Sept 18, 2019
>> >
>> > *Release Date: *Sept 23, 2019
>> >
>> > Issue  https://issues.apache.org/jira/browse/IGNITE-12032
>> > < https://issues.apache.org/jira/browse/IGNITE-12032?src=confmacro > is
>> > still
>> > unassigned: Server node prints exception when ODBC driver disconnects
>> > Igniters, who would like to pick up it? By default, I'm going to remove
>> it
>> > from release
>> >
>> >
>> > чт, 15 авг. 2019 г. в 14:54, Nikolay Izhikov < nizhi...@apache.org >:
>> >
>> > > Hello, Igniters.
>> > >
>> > > I try to upgrade Spark version but failed.
>> > >
>> > > Seems, internal Spark API(External Catalog, SQL planner) that we use
>> > > changed a lot.
>> > > So it will take some time to upgrade version.
>> > >
>> > > For now, I work hard to complete the second phase of IEP-35 so I
>> postpone
>> > > upgrade Spark version to Ignite 2.8.
>> > >
>> > > В Чт, 15/08/2019 в 14:51 +0300, Dmitriy Pavlov пишет:
>> > > > Hi Denis,
>> > > >
>> > > > Sure, since code freeze is planned for today, I don't mind to include
>> > > this
>> > > > bug.
>> > > >
>> > > > Ivan, could you complete this issue by 20 August?
>> > > >
>> > > > BTW #1, Dmitriy Govoruchnin, please reply about commit for
>> > > >  https://issues.apache.org/jira/browse/IGNITE-11953?src=confmacro
>> > > >
>> > > > BTW #2, FYI, release page is now available here
>> > > >
>>  https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.7.6
>> > > >
>> > > > BTW #3, FYI, release related test PR is here
>> > > >  https://github.com/apache/ignite/pull/6775 and it's TC Bot report is
>> > > here:
>> > > >
>> > >
>> >
>>  
>> https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=ignite-2.7.6=Latest=ignite-2.7.6
>> > > >
>> > > >
>> > > > чт, 15 авг. 2019 г. в 13:55, Denis Magda < dma...@apache.org >:
>> > > >
>> > > > > An Ignite user just reported a silly issue that needs to be fixed
>> in
>> > > 2.7.6:
>> > > > >  https://issues.apache.org/jira/browse/IGNITE-12068
>> > > > >
>> > > > > More details and context:
>> > > > >
>> > > > >
>> > >
>> >
>>  
>> https://stackoverflow.com/questions/57479636/simple-select-query-missing-rows-in-ignite
>> > > > >
>> > > > > Ivan, please help us to make it to the release.
>> > > > >
>> > > > > -
>> > > > > Denis
>> > > > >
>> > > > >
>> > > > > On Tue, Aug 13, 2019 at 6:47 AM Denis Magda < dma...@apache.org >
>> > wrote:
>> > > > >
>> > > > > > IGNITE-12507 (Persistence files are stored to temp dir) has
>> > > definitely be
>> > > > > > added the scope and treated one of the main release drivers.
>> > > > > >
>> > > > > > Dmitry, please let us know once the release wiki page is ready so
>> > > that we
>> > > > > > can finalize the timelines based on chosen scope.
>> > > > > >
>> > > > > > -
>> > > > > > Denis
>> > > > > >
>> > > > > >
>> > > > > > On Mon, Aug 12, 2019 at 7:12 PM Dmitriy Pavlov <
>>  dpav...@apache.org
>> > >
>> > > > >
>> > > > > wrote:
>> > > > > >
>> > > > > > > Hi,
>> > > > > > >
>> > > > > > > Thanks to everyone, who participated in the discussion.
>> > > > > > >
>> > > > > > > I would like to wait also fix for
>> > > > > > >  https://issues.apache.org/jira/browse/IGNITE-12057
>> > > > > > >
>> > > > > > > and discussion results for that issue:
>> > > > > > >
>> > > > > > >
>> > > > >
>> > > > >
>> > >
>> >
>>  
>> https://lists.apache.org/thread.html/498a14b3971950a45ef57f45cc23d2438ce1afba000b586e230927bf@%3Cdev.ignite.apache.org%3E
>> > > > > > >
>> > > > > > >
>> > > > > > > Since some issues are still open, we'll probably move some
>> dates
>> > > > >
>> > > > > forward,
>> > > > > > > but it seems we managed to discuss scope before scope freeze.
>> > > > > > >
>> > > > > > > I consider now the scope is frozen - no new feature can be
>> added
>> > > to the
>> > > > > > > scope of 2.7.6. We're entering the rampdown phase.
>> > > > > > >
>> > > > > > > Sincerely,
>> > > 

Re: Re[2]: Apache Ignite 2.7.6 (Time, Scope, and Release manager)

[Dmitriy Pavlov]

Ok, I've removed Spark from the scope.

What about the unassigned issue related to ODBC? It is not looking like
somebody will fix it before release.

Evgeniy Stanilovsky, what about
https://issues.apache.org/jira/browse/IGNITE-12061

do you have someone to review the fix?

чт, 15 авг. 2019 г. в 16:05, Denis Magda :

> Dmitry,
>
> It would be better for us to put off the Spark upgrade until 2.8 as Nikolay
> suggested. Let's release 2.7.6 as quickly as possible to let roll out fixes
> for the critical issues from the scope.
>
>
> -
> Denis
>
>
> On Thu, Aug 15, 2019 at 3:29 PM Dmitriy Pavlov  wrote:
>
> > Nikolay, how long does it take to update? I will be traveling from 28 Aug
> > till 16 Sept. We can select new dates for release if the majority of
> fixes
> > can be done by 16 Sept, but can't be by 20 Aug. Denis, please share your
> > vision about selecting new dates.
> >
> > *Voting Date: *Sept 18, 2019
> >
> > *Release Date: *Sept 23, 2019
> >
> > Issue https://issues.apache.org/jira/browse/IGNITE-12032
> >  is
> > still
> > unassigned: Server node prints exception when ODBC driver disconnects
> > Igniters, who would like to pick up it? By default, I'm going to remove
> it
> > from release
> >
> >
> > чт, 15 авг. 2019 г. в 14:54, Nikolay Izhikov :
> >
> > > Hello, Igniters.
> > >
> > > I try to upgrade Spark version but failed.
> > >
> > > Seems, internal Spark API(External Catalog, SQL planner) that we use
> > > changed a lot.
> > > So it will take some time to upgrade version.
> > >
> > > For now, I work hard to complete the second phase of IEP-35 so I
> postpone
> > > upgrade Spark version to Ignite 2.8.
> > >
> > > В Чт, 15/08/2019 в 14:51 +0300, Dmitriy Pavlov пишет:
> > > > Hi Denis,
> > > >
> > > > Sure, since code freeze is planned for today, I don't mind to include
> > > this
> > > > bug.
> > > >
> > > > Ivan, could you complete this issue by 20 August?
> > > >
> > > > BTW #1, Dmitriy Govoruchnin, please reply about commit for
> > > > https://issues.apache.org/jira/browse/IGNITE-11953?src=confmacro
> > > >
> > > > BTW #2, FYI, release page is now available here
> > > >
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.7.6
> > > >
> > > > BTW #3, FYI, release related test PR is here
> > > > https://github.com/apache/ignite/pull/6775 and it's TC Bot report is
> > > here:
> > > >
> > >
> >
> https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=ignite-2.7.6=Latest=ignite-2.7.6
> > > >
> > > >
> > > > чт, 15 авг. 2019 г. в 13:55, Denis Magda :
> > > >
> > > > > An Ignite user just reported a silly issue that needs to be fixed
> in
> > > 2.7.6:
> > > > > https://issues.apache.org/jira/browse/IGNITE-12068
> > > > >
> > > > > More details and context:
> > > > >
> > > > >
> > >
> >
> https://stackoverflow.com/questions/57479636/simple-select-query-missing-rows-in-ignite
> > > > >
> > > > > Ivan, please help us to make it to the release.
> > > > >
> > > > > -
> > > > > Denis
> > > > >
> > > > >
> > > > > On Tue, Aug 13, 2019 at 6:47 AM Denis Magda 
> > wrote:
> > > > >
> > > > > > IGNITE-12507 (Persistence files are stored to temp dir) has
> > > definitely be
> > > > > > added the scope and treated one of the main release drivers.
> > > > > >
> > > > > > Dmitry, please let us know once the release wiki page is ready so
> > > that we
> > > > > > can finalize the timelines based on chosen scope.
> > > > > >
> > > > > > -
> > > > > > Denis
> > > > > >
> > > > > >
> > > > > > On Mon, Aug 12, 2019 at 7:12 PM Dmitriy Pavlov <
> dpav...@apache.org
> > >
> > > > >
> > > > > wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > Thanks to everyone, who participated in the discussion.
> > > > > > >
> > > > > > > I would like to wait also fix for
> > > > > > > https://issues.apache.org/jira/browse/IGNITE-12057
> > > > > > >
> > > > > > > and discussion results for that issue:
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > >
> >
> https://lists.apache.org/thread.html/498a14b3971950a45ef57f45cc23d2438ce1afba000b586e230927bf@%3Cdev.ignite.apache.org%3E
> > > > > > >
> > > > > > >
> > > > > > > Since some issues are still open, we'll probably move some
> dates
> > > > >
> > > > > forward,
> > > > > > > but it seems we managed to discuss scope before scope freeze.
> > > > > > >
> > > > > > > I consider now the scope is frozen - no new feature can be
> added
> > > to the
> > > > > > > scope of 2.7.6. We're entering the rampdown phase.
> > > > > > >
> > > > > > > Sincerely,
> > > > > > > Dmitriy Pavlov
> > > > > > >
> > > > > > > See
> > > https://cwiki.apache.org/confluence/display/IGNITE/Release+Process
> > > > > > > for
> > > > > > > more details.
> > > > > > >
> > > > > > > пн, 12 авг. 2019 г. в 16:37, Zhenya Stanilovsky
> > > > > > >  > > > > > > > :
> > > > > > > > Hi al,, i also suggest to append [1], cause it could produce
> > 

Re: Re[2]: Apache Ignite 2.7.6 (Time, Scope, and Release manager)

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

Dmitriy,

> Ivan, could you complete this issue by 20 August?

Yes, almost for sure.

чт, 15 авг. 2019 г. в 16:05, Denis Magda :
>
> Dmitry,
>
> It would be better for us to put off the Spark upgrade until 2.8 as Nikolay
> suggested. Let's release 2.7.6 as quickly as possible to let roll out fixes
> for the critical issues from the scope.
>
>
> -
> Denis
>
>
> On Thu, Aug 15, 2019 at 3:29 PM Dmitriy Pavlov  wrote:
>
> > Nikolay, how long does it take to update? I will be traveling from 28 Aug
> > till 16 Sept. We can select new dates for release if the majority of fixes
> > can be done by 16 Sept, but can't be by 20 Aug. Denis, please share your
> > vision about selecting new dates.
> >
> > *Voting Date: *Sept 18, 2019
> >
> > *Release Date: *Sept 23, 2019
> >
> > Issue https://issues.apache.org/jira/browse/IGNITE-12032
> >  is
> > still
> > unassigned: Server node prints exception when ODBC driver disconnects
> > Igniters, who would like to pick up it? By default, I'm going to remove it
> > from release
> >
> >
> > чт, 15 авг. 2019 г. в 14:54, Nikolay Izhikov :
> >
> > > Hello, Igniters.
> > >
> > > I try to upgrade Spark version but failed.
> > >
> > > Seems, internal Spark API(External Catalog, SQL planner) that we use
> > > changed a lot.
> > > So it will take some time to upgrade version.
> > >
> > > For now, I work hard to complete the second phase of IEP-35 so I postpone
> > > upgrade Spark version to Ignite 2.8.
> > >
> > > В Чт, 15/08/2019 в 14:51 +0300, Dmitriy Pavlov пишет:
> > > > Hi Denis,
> > > >
> > > > Sure, since code freeze is planned for today, I don't mind to include
> > > this
> > > > bug.
> > > >
> > > > Ivan, could you complete this issue by 20 August?
> > > >
> > > > BTW #1, Dmitriy Govoruchnin, please reply about commit for
> > > > https://issues.apache.org/jira/browse/IGNITE-11953?src=confmacro
> > > >
> > > > BTW #2, FYI, release page is now available here
> > > > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.7.6
> > > >
> > > > BTW #3, FYI, release related test PR is here
> > > > https://github.com/apache/ignite/pull/6775 and it's TC Bot report is
> > > here:
> > > >
> > >
> > https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=ignite-2.7.6=Latest=ignite-2.7.6
> > > >
> > > >
> > > > чт, 15 авг. 2019 г. в 13:55, Denis Magda :
> > > >
> > > > > An Ignite user just reported a silly issue that needs to be fixed in
> > > 2.7.6:
> > > > > https://issues.apache.org/jira/browse/IGNITE-12068
> > > > >
> > > > > More details and context:
> > > > >
> > > > >
> > >
> > https://stackoverflow.com/questions/57479636/simple-select-query-missing-rows-in-ignite
> > > > >
> > > > > Ivan, please help us to make it to the release.
> > > > >
> > > > > -
> > > > > Denis
> > > > >
> > > > >
> > > > > On Tue, Aug 13, 2019 at 6:47 AM Denis Magda 
> > wrote:
> > > > >
> > > > > > IGNITE-12507 (Persistence files are stored to temp dir) has
> > > definitely be
> > > > > > added the scope and treated one of the main release drivers.
> > > > > >
> > > > > > Dmitry, please let us know once the release wiki page is ready so
> > > that we
> > > > > > can finalize the timelines based on chosen scope.
> > > > > >
> > > > > > -
> > > > > > Denis
> > > > > >
> > > > > >
> > > > > > On Mon, Aug 12, 2019 at 7:12 PM Dmitriy Pavlov  > >
> > > > >
> > > > > wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > Thanks to everyone, who participated in the discussion.
> > > > > > >
> > > > > > > I would like to wait also fix for
> > > > > > > https://issues.apache.org/jira/browse/IGNITE-12057
> > > > > > >
> > > > > > > and discussion results for that issue:
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > >
> > https://lists.apache.org/thread.html/498a14b3971950a45ef57f45cc23d2438ce1afba000b586e230927bf@%3Cdev.ignite.apache.org%3E
> > > > > > >
> > > > > > >
> > > > > > > Since some issues are still open, we'll probably move some dates
> > > > >
> > > > > forward,
> > > > > > > but it seems we managed to discuss scope before scope freeze.
> > > > > > >
> > > > > > > I consider now the scope is frozen - no new feature can be added
> > > to the
> > > > > > > scope of 2.7.6. We're entering the rampdown phase.
> > > > > > >
> > > > > > > Sincerely,
> > > > > > > Dmitriy Pavlov
> > > > > > >
> > > > > > > See
> > > https://cwiki.apache.org/confluence/display/IGNITE/Release+Process
> > > > > > > for
> > > > > > > more details.
> > > > > > >
> > > > > > > пн, 12 авг. 2019 г. в 16:37, Zhenya Stanilovsky
> > > > > > >  > > > > > > > :
> > > > > > > > Hi al,, i also suggest to append [1], cause it could produce
> > > > > > > > CorruptedTreeException in some scenario.
> > > > > > > >
> > > > > > > >
> > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-12061
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Hi all,
> > > > > > > > > Can we include
> > > 

[jira] [Created] (IGNITE-12076) Optimistic transaction initiated from client node and parallel cache stop may lead to node hang on the final phase of PME.

[Vyacheslav Koptilin (JIRA)]

Vyacheslav Koptilin created IGNITE-12076:


 Summary: Optimistic transaction initiated from client node and 
parallel cache stop may lead to node hang on the final phase of PME.
 Key: IGNITE-12076
 URL: https://issues.apache.org/jira/browse/IGNITE-12076
 Project: Ignite
  Issue Type: Bug
Reporter: Vyacheslav Koptilin
Assignee: Vyacheslav Koptilin
 Fix For: 2.8


It looks like the mentioned behavior was introduced by IGNITE-11592. The root 
cause of the hang is that optimistic transaction can be mapped on the topology 
version that corresponds to cache stop and is in progress.
{noformat}
"sys-#1" #108 prio=5 os_prio=0 tid=0x7f5328042000 nid=0x4fbc waiting on 
condition [0x7f5020ff3000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.rollbackTransactionsForCaches(IgniteTxManager.java:339)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.rollbackCoveredTx(GridCacheProcessor.java:3041)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.onExchangeDone(GridCacheProcessor.java:3013)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:2169)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processFullMessage(GridDhtPartitionsExchangeFuture.java:4094)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$1600(GridDhtPartitionsExchangeFuture.java:140)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$5.apply(GridDhtPartitionsExchangeFuture.java:3787)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$5.apply(GridDhtPartitionsExchangeFuture.java:3775)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:385)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:355)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onReceiveFullMessage(GridDhtPartitionsExchangeFuture.java:3775)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.processFullPartitionUpdate(GridCachePartitionExchangeManager.java:1778)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$3.onMessage(GridCachePartitionExchangeManager.java:423)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$3.onMessage(GridCachePartitionExchangeManager.java:410)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:3444)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:3423)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1077)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:587)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:386)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:312)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:102)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:301)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1091)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at 

Re: Re[2]: Apache Ignite 2.7.6 (Time, Scope, and Release manager)

[Denis Magda]

Dmitry,

It would be better for us to put off the Spark upgrade until 2.8 as Nikolay
suggested. Let's release 2.7.6 as quickly as possible to let roll out fixes
for the critical issues from the scope.


-
Denis


On Thu, Aug 15, 2019 at 3:29 PM Dmitriy Pavlov  wrote:

> Nikolay, how long does it take to update? I will be traveling from 28 Aug
> till 16 Sept. We can select new dates for release if the majority of fixes
> can be done by 16 Sept, but can't be by 20 Aug. Denis, please share your
> vision about selecting new dates.
>
> *Voting Date: *Sept 18, 2019
>
> *Release Date: *Sept 23, 2019
>
> Issue https://issues.apache.org/jira/browse/IGNITE-12032
>  is
> still
> unassigned: Server node prints exception when ODBC driver disconnects
> Igniters, who would like to pick up it? By default, I'm going to remove it
> from release
>
>
> чт, 15 авг. 2019 г. в 14:54, Nikolay Izhikov :
>
> > Hello, Igniters.
> >
> > I try to upgrade Spark version but failed.
> >
> > Seems, internal Spark API(External Catalog, SQL planner) that we use
> > changed a lot.
> > So it will take some time to upgrade version.
> >
> > For now, I work hard to complete the second phase of IEP-35 so I postpone
> > upgrade Spark version to Ignite 2.8.
> >
> > В Чт, 15/08/2019 в 14:51 +0300, Dmitriy Pavlov пишет:
> > > Hi Denis,
> > >
> > > Sure, since code freeze is planned for today, I don't mind to include
> > this
> > > bug.
> > >
> > > Ivan, could you complete this issue by 20 August?
> > >
> > > BTW #1, Dmitriy Govoruchnin, please reply about commit for
> > > https://issues.apache.org/jira/browse/IGNITE-11953?src=confmacro
> > >
> > > BTW #2, FYI, release page is now available here
> > > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.7.6
> > >
> > > BTW #3, FYI, release related test PR is here
> > > https://github.com/apache/ignite/pull/6775 and it's TC Bot report is
> > here:
> > >
> >
> https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=ignite-2.7.6=Latest=ignite-2.7.6
> > >
> > >
> > > чт, 15 авг. 2019 г. в 13:55, Denis Magda :
> > >
> > > > An Ignite user just reported a silly issue that needs to be fixed in
> > 2.7.6:
> > > > https://issues.apache.org/jira/browse/IGNITE-12068
> > > >
> > > > More details and context:
> > > >
> > > >
> >
> https://stackoverflow.com/questions/57479636/simple-select-query-missing-rows-in-ignite
> > > >
> > > > Ivan, please help us to make it to the release.
> > > >
> > > > -
> > > > Denis
> > > >
> > > >
> > > > On Tue, Aug 13, 2019 at 6:47 AM Denis Magda 
> wrote:
> > > >
> > > > > IGNITE-12507 (Persistence files are stored to temp dir) has
> > definitely be
> > > > > added the scope and treated one of the main release drivers.
> > > > >
> > > > > Dmitry, please let us know once the release wiki page is ready so
> > that we
> > > > > can finalize the timelines based on chosen scope.
> > > > >
> > > > > -
> > > > > Denis
> > > > >
> > > > >
> > > > > On Mon, Aug 12, 2019 at 7:12 PM Dmitriy Pavlov  >
> > > >
> > > > wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > Thanks to everyone, who participated in the discussion.
> > > > > >
> > > > > > I would like to wait also fix for
> > > > > > https://issues.apache.org/jira/browse/IGNITE-12057
> > > > > >
> > > > > > and discussion results for that issue:
> > > > > >
> > > > > >
> > > >
> > > >
> >
> https://lists.apache.org/thread.html/498a14b3971950a45ef57f45cc23d2438ce1afba000b586e230927bf@%3Cdev.ignite.apache.org%3E
> > > > > >
> > > > > >
> > > > > > Since some issues are still open, we'll probably move some dates
> > > >
> > > > forward,
> > > > > > but it seems we managed to discuss scope before scope freeze.
> > > > > >
> > > > > > I consider now the scope is frozen - no new feature can be added
> > to the
> > > > > > scope of 2.7.6. We're entering the rampdown phase.
> > > > > >
> > > > > > Sincerely,
> > > > > > Dmitriy Pavlov
> > > > > >
> > > > > > See
> > https://cwiki.apache.org/confluence/display/IGNITE/Release+Process
> > > > > > for
> > > > > > more details.
> > > > > >
> > > > > > пн, 12 авг. 2019 г. в 16:37, Zhenya Stanilovsky
> > > > > >  > > > > > > :
> > > > > > > Hi al,, i also suggest to append [1], cause it could produce
> > > > > > > CorruptedTreeException in some scenario.
> > > > > > >
> > > > > > >
> > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-12061
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Hi all,
> > > > > > > > Can we include
> > https://issues.apache.org/jira/browse/IGNITE-12060 ?
> > > > > > >
> > > > > > > This is
> > > > > > > > a  https://issues.apache.org/jira/browse/IGNITE-11953
> > > > > > > >
> > > > > > > > On Fri, Aug 9, 2019 at 10:04 AM Nikolay Izhikov <
> > > >
> > > > nizhi...@apache.org
> > > > > > >
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hello, Deni.
> > > > > > > > >
> > > > > > > > > > Nickolay, could you check if that's a quick upgrade?
> 

Re: Re[2]: Apache Ignite 2.7.6 (Time, Scope, and Release manager)

[Dmitriy Pavlov]

Nikolay, how long does it take to update? I will be traveling from 28 Aug
till 16 Sept. We can select new dates for release if the majority of fixes
can be done by 16 Sept, but can't be by 20 Aug. Denis, please share your
vision about selecting new dates.

*Voting Date: *Sept 18, 2019

*Release Date: *Sept 23, 2019

Issue https://issues.apache.org/jira/browse/IGNITE-12032
 is still
unassigned: Server node prints exception when ODBC driver disconnects
Igniters, who would like to pick up it? By default, I'm going to remove it
from release


чт, 15 авг. 2019 г. в 14:54, Nikolay Izhikov :

> Hello, Igniters.
>
> I try to upgrade Spark version but failed.
>
> Seems, internal Spark API(External Catalog, SQL planner) that we use
> changed a lot.
> So it will take some time to upgrade version.
>
> For now, I work hard to complete the second phase of IEP-35 so I postpone
> upgrade Spark version to Ignite 2.8.
>
> В Чт, 15/08/2019 в 14:51 +0300, Dmitriy Pavlov пишет:
> > Hi Denis,
> >
> > Sure, since code freeze is planned for today, I don't mind to include
> this
> > bug.
> >
> > Ivan, could you complete this issue by 20 August?
> >
> > BTW #1, Dmitriy Govoruchnin, please reply about commit for
> > https://issues.apache.org/jira/browse/IGNITE-11953?src=confmacro
> >
> > BTW #2, FYI, release page is now available here
> > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.7.6
> >
> > BTW #3, FYI, release related test PR is here
> > https://github.com/apache/ignite/pull/6775 and it's TC Bot report is
> here:
> >
> https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=ignite-2.7.6=Latest=ignite-2.7.6
> >
> >
> > чт, 15 авг. 2019 г. в 13:55, Denis Magda :
> >
> > > An Ignite user just reported a silly issue that needs to be fixed in
> 2.7.6:
> > > https://issues.apache.org/jira/browse/IGNITE-12068
> > >
> > > More details and context:
> > >
> > >
> https://stackoverflow.com/questions/57479636/simple-select-query-missing-rows-in-ignite
> > >
> > > Ivan, please help us to make it to the release.
> > >
> > > -
> > > Denis
> > >
> > >
> > > On Tue, Aug 13, 2019 at 6:47 AM Denis Magda  wrote:
> > >
> > > > IGNITE-12507 (Persistence files are stored to temp dir) has
> definitely be
> > > > added the scope and treated one of the main release drivers.
> > > >
> > > > Dmitry, please let us know once the release wiki page is ready so
> that we
> > > > can finalize the timelines based on chosen scope.
> > > >
> > > > -
> > > > Denis
> > > >
> > > >
> > > > On Mon, Aug 12, 2019 at 7:12 PM Dmitriy Pavlov 
> > >
> > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > Thanks to everyone, who participated in the discussion.
> > > > >
> > > > > I would like to wait also fix for
> > > > > https://issues.apache.org/jira/browse/IGNITE-12057
> > > > >
> > > > > and discussion results for that issue:
> > > > >
> > > > >
> > >
> > >
> https://lists.apache.org/thread.html/498a14b3971950a45ef57f45cc23d2438ce1afba000b586e230927bf@%3Cdev.ignite.apache.org%3E
> > > > >
> > > > >
> > > > > Since some issues are still open, we'll probably move some dates
> > >
> > > forward,
> > > > > but it seems we managed to discuss scope before scope freeze.
> > > > >
> > > > > I consider now the scope is frozen - no new feature can be added
> to the
> > > > > scope of 2.7.6. We're entering the rampdown phase.
> > > > >
> > > > > Sincerely,
> > > > > Dmitriy Pavlov
> > > > >
> > > > > See
> https://cwiki.apache.org/confluence/display/IGNITE/Release+Process
> > > > > for
> > > > > more details.
> > > > >
> > > > > пн, 12 авг. 2019 г. в 16:37, Zhenya Stanilovsky
> > > > >  > > > > > :
> > > > > > Hi al,, i also suggest to append [1], cause it could produce
> > > > > > CorruptedTreeException in some scenario.
> > > > > >
> > > > > >
> > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-12061
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Hi all,
> > > > > > > Can we include
> https://issues.apache.org/jira/browse/IGNITE-12060 ?
> > > > > >
> > > > > > This is
> > > > > > > a  https://issues.apache.org/jira/browse/IGNITE-11953
> > > > > > >
> > > > > > > On Fri, Aug 9, 2019 at 10:04 AM Nikolay Izhikov <
> > >
> > > nizhi...@apache.org
> > > > > >
> > > > > > wrote:
> > > > > > >
> > > > > > > > Hello, Deni.
> > > > > > > >
> > > > > > > > > Nickolay, could you check if that's a quick upgrade?
> > > > > > > >
> > > > > > > > Yes, I will take a look.
> > > > > > > >
> > > > > > > >
> > > > > > > > В Чт, 08/08/2019 в 11:08 -0700, Denis Magda пишет:
> > > > > > > > > Dmitry,
> > > > > > > > >
> > > > > > > > > Please add this BTree corruption fix to the scope:
> > > > > > > > >  https://issues.apache.org/jira/browse/IGNITE-11953
> > > > > > > > >
> > > > > > > > > Plus, I would upgrade our Spark integration to version 2.4
> as
> > >
> > > long
> > > > > as
> > > > > > 2.3
> > > > > > > > > goes with limitations reported by our users:
> > > > > > > > >  

Re: Re[2]: Apache Ignite 2.7.6 (Time, Scope, and Release manager)

[Nikolay Izhikov]

Hello, Igniters.

I try to upgrade Spark version but failed.

Seems, internal Spark API(External Catalog, SQL planner) that we use changed a 
lot.
So it will take some time to upgrade version.

For now, I work hard to complete the second phase of IEP-35 so I postpone 
upgrade Spark version to Ignite 2.8.

В Чт, 15/08/2019 в 14:51 +0300, Dmitriy Pavlov пишет:
> Hi Denis,
> 
> Sure, since code freeze is planned for today, I don't mind to include this
> bug.
> 
> Ivan, could you complete this issue by 20 August?
> 
> BTW #1, Dmitriy Govoruchnin, please reply about commit for
> https://issues.apache.org/jira/browse/IGNITE-11953?src=confmacro
> 
> BTW #2, FYI, release page is now available here
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.7.6
> 
> BTW #3, FYI, release related test PR is here
> https://github.com/apache/ignite/pull/6775 and it's TC Bot report is here:
> https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=ignite-2.7.6=Latest=ignite-2.7.6
> 
> 
> чт, 15 авг. 2019 г. в 13:55, Denis Magda :
> 
> > An Ignite user just reported a silly issue that needs to be fixed in 2.7.6:
> > https://issues.apache.org/jira/browse/IGNITE-12068
> > 
> > More details and context:
> > 
> > https://stackoverflow.com/questions/57479636/simple-select-query-missing-rows-in-ignite
> > 
> > Ivan, please help us to make it to the release.
> > 
> > -
> > Denis
> > 
> > 
> > On Tue, Aug 13, 2019 at 6:47 AM Denis Magda  wrote:
> > 
> > > IGNITE-12507 (Persistence files are stored to temp dir) has definitely be
> > > added the scope and treated one of the main release drivers.
> > > 
> > > Dmitry, please let us know once the release wiki page is ready so that we
> > > can finalize the timelines based on chosen scope.
> > > 
> > > -
> > > Denis
> > > 
> > > 
> > > On Mon, Aug 12, 2019 at 7:12 PM Dmitriy Pavlov 
> > 
> > wrote:
> > > 
> > > > Hi,
> > > > 
> > > > Thanks to everyone, who participated in the discussion.
> > > > 
> > > > I would like to wait also fix for
> > > > https://issues.apache.org/jira/browse/IGNITE-12057
> > > > 
> > > > and discussion results for that issue:
> > > > 
> > > > 
> > 
> > https://lists.apache.org/thread.html/498a14b3971950a45ef57f45cc23d2438ce1afba000b586e230927bf@%3Cdev.ignite.apache.org%3E
> > > > 
> > > > 
> > > > Since some issues are still open, we'll probably move some dates
> > 
> > forward,
> > > > but it seems we managed to discuss scope before scope freeze.
> > > > 
> > > > I consider now the scope is frozen - no new feature can be added to the
> > > > scope of 2.7.6. We're entering the rampdown phase.
> > > > 
> > > > Sincerely,
> > > > Dmitriy Pavlov
> > > > 
> > > > See https://cwiki.apache.org/confluence/display/IGNITE/Release+Process
> > > > for
> > > > more details.
> > > > 
> > > > пн, 12 авг. 2019 г. в 16:37, Zhenya Stanilovsky
> > > >  > > > > :
> > > > > Hi al,, i also suggest to append [1], cause it could produce
> > > > > CorruptedTreeException in some scenario.
> > > > > 
> > > > > 
> > > > > [1] https://issues.apache.org/jira/browse/IGNITE-12061
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > Hi all,
> > > > > > Can we include  https://issues.apache.org/jira/browse/IGNITE-12060 ?
> > > > > 
> > > > > This is
> > > > > > a  https://issues.apache.org/jira/browse/IGNITE-11953
> > > > > > 
> > > > > > On Fri, Aug 9, 2019 at 10:04 AM Nikolay Izhikov <
> > 
> > nizhi...@apache.org
> > > > > 
> > > > > wrote:
> > > > > > 
> > > > > > > Hello, Deni.
> > > > > > > 
> > > > > > > > Nickolay, could you check if that's a quick upgrade?
> > > > > > > 
> > > > > > > Yes, I will take a look.
> > > > > > > 
> > > > > > > 
> > > > > > > В Чт, 08/08/2019 в 11:08 -0700, Denis Magda пишет:
> > > > > > > > Dmitry,
> > > > > > > > 
> > > > > > > > Please add this BTree corruption fix to the scope:
> > > > > > > >  https://issues.apache.org/jira/browse/IGNITE-11953
> > > > > > > > 
> > > > > > > > Plus, I would upgrade our Spark integration to version 2.4 as
> > 
> > long
> > > > as
> > > > > 2.3
> > > > > > > > goes with limitations reported by our users:
> > > > > > > >  https://issues.apache.org/jira/browse/IGNITE-12054
> > > > > > > > 
> > > > > > > > Nickolay, could you check if that's a quick upgrade?
> > > > > > > > 
> > > > > > > > -
> > > > > > > > Denis
> > > > > > > > 
> > > > > > > > 
> > > > > > > > On Thu, Aug 8, 2019 at 10:40 AM Dmitriy Pavlov <
> > > > 
> > > > dpav...@apache.org >
> > > > > > > wrote:
> > > > > > > > 
> > > > > > > > > Hi Ivan, Ilya, Igniters,
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > I would like this release would be as minimal as possible.
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > According to dates proposed we could freeze scope at 12.08, 4
> > > > 
> > > > days
> > > > > is
> > > > > > > more
> > > > > > > > > than enough to stand up and say, ‘Hey, I have an urgent fix’.
> > 
> > But
> > > > > it is
> > > > > > > > > also ok for me if we 

Re: Re[2]: Apache Ignite 2.7.6 (Time, Scope, and Release manager)

[Dmitriy Pavlov]

Hi Denis,

Sure, since code freeze is planned for today, I don't mind to include this
bug.

Ivan, could you complete this issue by 20 August?

BTW #1, Dmitriy Govoruchnin, please reply about commit for
https://issues.apache.org/jira/browse/IGNITE-11953?src=confmacro

BTW #2, FYI, release page is now available here
https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.7.6

BTW #3, FYI, release related test PR is here
https://github.com/apache/ignite/pull/6775 and it's TC Bot report is here:
https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=ignite-2.7.6=Latest=ignite-2.7.6


чт, 15 авг. 2019 г. в 13:55, Denis Magda :

> An Ignite user just reported a silly issue that needs to be fixed in 2.7.6:
> https://issues.apache.org/jira/browse/IGNITE-12068
>
> More details and context:
>
> https://stackoverflow.com/questions/57479636/simple-select-query-missing-rows-in-ignite
>
> Ivan, please help us to make it to the release.
>
> -
> Denis
>
>
> On Tue, Aug 13, 2019 at 6:47 AM Denis Magda  wrote:
>
> > IGNITE-12507 (Persistence files are stored to temp dir) has definitely be
> > added the scope and treated one of the main release drivers.
> >
> > Dmitry, please let us know once the release wiki page is ready so that we
> > can finalize the timelines based on chosen scope.
> >
> > -
> > Denis
> >
> >
> > On Mon, Aug 12, 2019 at 7:12 PM Dmitriy Pavlov 
> wrote:
> >
> >> Hi,
> >>
> >> Thanks to everyone, who participated in the discussion.
> >>
> >> I would like to wait also fix for
> >> https://issues.apache.org/jira/browse/IGNITE-12057
> >>
> >> and discussion results for that issue:
> >>
> >>
> https://lists.apache.org/thread.html/498a14b3971950a45ef57f45cc23d2438ce1afba000b586e230927bf@%3Cdev.ignite.apache.org%3E
> >>
> >>
> >> Since some issues are still open, we'll probably move some dates
> forward,
> >> but it seems we managed to discuss scope before scope freeze.
> >>
> >> I consider now the scope is frozen - no new feature can be added to the
> >> scope of 2.7.6. We're entering the rampdown phase.
> >>
> >> Sincerely,
> >> Dmitriy Pavlov
> >>
> >> See https://cwiki.apache.org/confluence/display/IGNITE/Release+Process
> >> for
> >> more details.
> >>
> >> пн, 12 авг. 2019 г. в 16:37, Zhenya Stanilovsky
> >>  >> >:
> >>
> >> > Hi al,, i also suggest to append [1], cause it could produce
> >> > CorruptedTreeException in some scenario.
> >> >
> >> >
> >> > [1] https://issues.apache.org/jira/browse/IGNITE-12061
> >> >
> >> > >
> >> > >
> >> > >Hi all,
> >> > >Can we include  https://issues.apache.org/jira/browse/IGNITE-12060 ?
> >> > This is
> >> > >a  https://issues.apache.org/jira/browse/IGNITE-11953
> >> > >
> >> > >On Fri, Aug 9, 2019 at 10:04 AM Nikolay Izhikov <
> nizhi...@apache.org
> >> >
> >> > wrote:
> >> > >
> >> > >> Hello, Deni.
> >> > >>
> >> > >> > Nickolay, could you check if that's a quick upgrade?
> >> > >>
> >> > >> Yes, I will take a look.
> >> > >>
> >> > >>
> >> > >> В Чт, 08/08/2019 в 11:08 -0700, Denis Magda пишет:
> >> > >> > Dmitry,
> >> > >> >
> >> > >> > Please add this BTree corruption fix to the scope:
> >> > >> >  https://issues.apache.org/jira/browse/IGNITE-11953
> >> > >> >
> >> > >> > Plus, I would upgrade our Spark integration to version 2.4 as
> long
> >> as
> >> > 2.3
> >> > >> > goes with limitations reported by our users:
> >> > >> >  https://issues.apache.org/jira/browse/IGNITE-12054
> >> > >> >
> >> > >> > Nickolay, could you check if that's a quick upgrade?
> >> > >> >
> >> > >> > -
> >> > >> > Denis
> >> > >> >
> >> > >> >
> >> > >> > On Thu, Aug 8, 2019 at 10:40 AM Dmitriy Pavlov <
> >> dpav...@apache.org >
> >> > >> wrote:
> >> > >> >
> >> > >> > > Hi Ivan, Ilya, Igniters,
> >> > >> > >
> >> > >> > >
> >> > >> > >
> >> > >> > > I would like this release would be as minimal as possible.
> >> > >> > >
> >> > >> > >
> >> > >> > >
> >> > >> > > According to dates proposed we could freeze scope at 12.08, 4
> >> days
> >> > is
> >> > >> more
> >> > >> > > than enough to stand up and say, ‘Hey, I have an urgent fix’.
> But
> >> > it is
> >> > >> > > also ok for me if we decide to have more relaxed dates.
> >> > >> > >
> >> > >> > >
> >> > >> > >
> >> > >> > > For now, I suppose the following fixed should be cherry-picked:
> >> > >> > >
> >> > >> > >  https://issues.apache.org/jira/browse/IGNITE-11767 (Blocker)
> >> > >> > > GridDhtPartitionsFullMessage retains huge maps on heap in
> >> exchange
> >> > >> history
> >> > >> > >
> >> > >> > >
> >> > >> > >
> >> > >> > >  https://issues.apache.org/jira/browse/IGNITE-10451 (Major
> Bug)
> >> > .NET:
> >> > >> > > Persistence does not work with custom affinity function
> >> > >> > >
> >> > >> > >
> >> > >> > >
> >> > >> > >  https://issues.apache.org/jira/browse/IGNITE-9562 (Critical
> >> Bug)
> >> > >> Destroyed
> >> > >> > > cache that resurrected on an old offline node breaks PME
> >> > >> > >
> >> > >> > >
> >> > >> > >
> >> > >> > > But I will continue to research JIRA.
> >> > >> > >
> >> 

[jira] [Created] (IGNITE-12075) Wrong table alias when SUM used inside CASE WHEN

[Ilya Kasnacheev (JIRA)]

Ilya Kasnacheev created IGNITE-12075:


 Summary: Wrong table alias when SUM used inside CASE WHEN
 Key: IGNITE-12075
 URL: https://issues.apache.org/jira/browse/IGNITE-12075
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.7.5
Reporter: Ilya Kasnacheev


https://stackoverflow.com/questions/57472293/ignite-failed-to-run-reduce-query-locally

Consider the following queries: 

{code}
create table user (id int primary key, name varchar);
SELECT CASE WHEN id = 2016 THEN SUM(id) END FROM user GROUP BY id;
{code}

Will cause splitter to try executing wrong SQL:

```Caused by: org.h2.jdbc.JdbcSQLException: Столбец "__Z0.ID" не найден
Column "__Z0.ID" not found; SQL statement:
SELECT
CASE  WHEN (__Z0.ID = 2016) THEN SUM(__C0_0) END __C0_0
FROM PUBLIC.__T0 [42122-197]```



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

Re: SQL query timeout: in progress or abandoned

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

Saikat, Denis,

I left comments in the ticket [1].

[1] https://issues.apache.org/jira/browse/IGNITE-7285

вт, 13 авг. 2019 г. в 21:53, Denis Magda :
>
> Hi Saikat,
>
> Thanks for a quick turnaround! Ivan, could you please step in and do a
> review?
>
> -
> Denis
>
>
> On Sun, Aug 11, 2019 at 6:26 AM Saikat Maitra 
> wrote:
>
> > Hi Denis, Ivan
> >
> > As discussed I have updated the PR and incorporated review comments.
> >
> > https://github.com/apache/ignite/pull/6490/files
> >
> > Please take a look and share your feedback.
> >
> > Regard,
> > Saikat
> >
> >
> >
> > On Sat, Aug 10, 2019 at 5:51 PM Saikat Maitra 
> > wrote:
> >
> > > Hello Denis, Ivan
> > >
> > > Yes, I can take up the changes for IGNITE-7825.
> > >
> > > I had a doubt on the usage of the Default Query Timeout.
> > >
> > > I had raised the PR in an assumption that Default Query Timeout will only
> > > be used if user had not provided Cache Query Timeout
> > >
> > > https://github.com/apache/ignite/pull/6490/files
> > >
> > > I wanted to discuss if it is correct intended usage of Default Query
> > > Timeout or should we reconsider?
> > >
> > > Regards,
> > > Saikat
> > >
> > >
> > >
> > > On Fri, Aug 9, 2019 at 12:11 PM Denis Magda  wrote:
> > >
> > >> Ivan, thanks for sharing this discussion. Let's use it for our
> > >> conversation.
> > >>
> > >> -
> > >> Denis
> > >>
> > >>
> > >> On Thu, Aug 8, 2019 at 11:15 PM Павлухин Иван 
> > >> wrote:
> > >>
> > >> > Just for the protocol. There was an original dev-list discussion [1].
> > >> > Added a link to the ticket as well.
> > >> >
> > >> > [1]
> > >> >
> > >>
> > http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-7285-Add-default-query-timeout-td41828.html
> > >> >
> > >> > пт, 9 авг. 2019 г. в 01:22, Denis Magda :
> > >> > >
> > >> > > Hey Saikat,
> > >> > >
> > >> > > Are you still working on this ticket?
> > >> > > https://issues.apache.org/jira/browse/IGNITE-7285
> > >> > >
> > >> > > Seems that's the last API that doesn't support timeouts - JDBC and
> > >> ODBC
> > >> > > drivers already go with it.
> > >> > >
> > >> > > If you don't have time to complete the changes then someone else
> > from
> > >> the
> > >> > > community can take over. We see a lot of demand for this API and
> > here
> > >> is
> > >> > > one example:
> > >> > >
> > >> >
> > >>
> > https://stackoverflow.com/questions/57275301/how-to-set-a-query-timeout-for-apache-ignite-cache
> > >> > >
> > >> > > -
> > >> > > Denis
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > Best regards,
> > >> > Ivan Pavlukhin
> > >> >
> > >>
> > >
> >



-- 
Best regards,
Ivan Pavlukhin

Re: Re[2]: Apache Ignite 2.7.6 (Time, Scope, and Release manager)

[Denis Magda]

An Ignite user just reported a silly issue that needs to be fixed in 2.7.6:
https://issues.apache.org/jira/browse/IGNITE-12068

More details and context:
https://stackoverflow.com/questions/57479636/simple-select-query-missing-rows-in-ignite

Ivan, please help us to make it to the release.

-
Denis


On Tue, Aug 13, 2019 at 6:47 AM Denis Magda  wrote:

> IGNITE-12507 (Persistence files are stored to temp dir) has definitely be
> added the scope and treated one of the main release drivers.
>
> Dmitry, please let us know once the release wiki page is ready so that we
> can finalize the timelines based on chosen scope.
>
> -
> Denis
>
>
> On Mon, Aug 12, 2019 at 7:12 PM Dmitriy Pavlov  wrote:
>
>> Hi,
>>
>> Thanks to everyone, who participated in the discussion.
>>
>> I would like to wait also fix for
>> https://issues.apache.org/jira/browse/IGNITE-12057
>>
>> and discussion results for that issue:
>>
>> https://lists.apache.org/thread.html/498a14b3971950a45ef57f45cc23d2438ce1afba000b586e230927bf@%3Cdev.ignite.apache.org%3E
>>
>>
>> Since some issues are still open, we'll probably move some dates forward,
>> but it seems we managed to discuss scope before scope freeze.
>>
>> I consider now the scope is frozen - no new feature can be added to the
>> scope of 2.7.6. We're entering the rampdown phase.
>>
>> Sincerely,
>> Dmitriy Pavlov
>>
>> See https://cwiki.apache.org/confluence/display/IGNITE/Release+Process
>> for
>> more details.
>>
>> пн, 12 авг. 2019 г. в 16:37, Zhenya Stanilovsky
>> > >:
>>
>> > Hi al,, i also suggest to append [1], cause it could produce
>> > CorruptedTreeException in some scenario.
>> >
>> >
>> > [1] https://issues.apache.org/jira/browse/IGNITE-12061
>> >
>> > >
>> > >
>> > >Hi all,
>> > >Can we include  https://issues.apache.org/jira/browse/IGNITE-12060 ?
>> > This is
>> > >a  https://issues.apache.org/jira/browse/IGNITE-11953
>> > >
>> > >On Fri, Aug 9, 2019 at 10:04 AM Nikolay Izhikov < nizhi...@apache.org
>> >
>> > wrote:
>> > >
>> > >> Hello, Deni.
>> > >>
>> > >> > Nickolay, could you check if that's a quick upgrade?
>> > >>
>> > >> Yes, I will take a look.
>> > >>
>> > >>
>> > >> В Чт, 08/08/2019 в 11:08 -0700, Denis Magda пишет:
>> > >> > Dmitry,
>> > >> >
>> > >> > Please add this BTree corruption fix to the scope:
>> > >> >  https://issues.apache.org/jira/browse/IGNITE-11953
>> > >> >
>> > >> > Plus, I would upgrade our Spark integration to version 2.4 as long
>> as
>> > 2.3
>> > >> > goes with limitations reported by our users:
>> > >> >  https://issues.apache.org/jira/browse/IGNITE-12054
>> > >> >
>> > >> > Nickolay, could you check if that's a quick upgrade?
>> > >> >
>> > >> > -
>> > >> > Denis
>> > >> >
>> > >> >
>> > >> > On Thu, Aug 8, 2019 at 10:40 AM Dmitriy Pavlov <
>> dpav...@apache.org >
>> > >> wrote:
>> > >> >
>> > >> > > Hi Ivan, Ilya, Igniters,
>> > >> > >
>> > >> > >
>> > >> > >
>> > >> > > I would like this release would be as minimal as possible.
>> > >> > >
>> > >> > >
>> > >> > >
>> > >> > > According to dates proposed we could freeze scope at 12.08, 4
>> days
>> > is
>> > >> more
>> > >> > > than enough to stand up and say, ‘Hey, I have an urgent fix’. But
>> > it is
>> > >> > > also ok for me if we decide to have more relaxed dates.
>> > >> > >
>> > >> > >
>> > >> > >
>> > >> > > For now, I suppose the following fixed should be cherry-picked:
>> > >> > >
>> > >> > >  https://issues.apache.org/jira/browse/IGNITE-11767 (Blocker)
>> > >> > > GridDhtPartitionsFullMessage retains huge maps on heap in
>> exchange
>> > >> history
>> > >> > >
>> > >> > >
>> > >> > >
>> > >> > >  https://issues.apache.org/jira/browse/IGNITE-10451 (Major Bug)
>> > .NET:
>> > >> > > Persistence does not work with custom affinity function
>> > >> > >
>> > >> > >
>> > >> > >
>> > >> > >  https://issues.apache.org/jira/browse/IGNITE-9562 (Critical
>> Bug)
>> > >> Destroyed
>> > >> > > cache that resurrected on an old offline node breaks PME
>> > >> > >
>> > >> > >
>> > >> > >
>> > >> > > But I will continue to research JIRA.
>> > >> > >
>> > >> > >
>> > >> > >
>> > >> > > Sincerely,
>> > >> > >
>> > >> > > Dmitriy Pavlov
>> > >> > >
>> > >> > >
>> > >> > > чт, 8 авг. 2019 г. в 17:30, Павлухин Иван < vololo...@gmail.com
>> >:
>> > >> > >
>> > >> > > > > What's the scope for this release?
>> > >> > > >
>> > >> > > > Same question.
>> > >> > > >
>> > >> > > > On the other hand an idea of 2.7.6 release attracts me because
>> > having
>> > >> > > > a practice of doing frequent minor releases can help us to
>> build
>> > >> > > > reliable and predictable release rails.
>> > >> > > >
>> > >> > > > чт, 8 авг. 2019 г. в 15:09, Ilya Kasnacheev <
>> > >>  ilya.kasnach...@gmail.com >:
>> > >> > > > >
>> > >> > > > > Hello!
>> > >> > > > >
>> > >> > > > > What's the scope for this release?
>> > >> > > > >
>> > >> > > > > Regards,
>> > >> > > > > --
>> > >> > > > > Ilya Kasnacheev
>> > >> > > > >
>> > >> > > > >
>> > >> > > > > чт, 8 авг. 2019 г. в 15:07, Dmitriy Pavlov <
>> dpav...@apache.org
>> 

Re: Thin client: transactions support

[Alex Plehanov]

Hi Pavel,

Thank you for the review!

Igniters,

Also, I want to bring here a discussion about configuring limit for active
transactions per thin client connection.

I see two ways to configure such limit:
1. A new system property
2. A new ClientConnectorConfiguration class property.

In the current implementation, I've introduced a new system
property IGNITE_THIN_MAX_ACTIVE_TX_PER_CONNECTION. Pavel proposes to
configure limit via ClientConnectorConfiguration.

Such limit is only reliable to thin clients, but
ClientConnectorConfiguration is also used for JDBC and ODBC connections as
well. A new property in ClientConnectorConfiguration will be useless for
JDBC and ODBC (since they use one transaction per connection) and may be
confusing.

Which way is better, WDYT?



чт, 15 авг. 2019 г. в 11:46, Pavel Tupitsyn :

> Hi Alex,
>
> I've checked the patch, protocol changes look good to me. See reply in
> Jira.
> But we certainly need more eyes on this.
>
> On Thu, Aug 15, 2019 at 10:36 AM Alex Plehanov 
> wrote:
>
> > Hi Ivan,
> >
> > Java thin client doesn't support affinity awareness yet (ticket [1] is in
> > progress now), but changes to correctly work with protocol version 1.4.0
> > was made, so java thin client will work properly with 1.4.0 and 1.5.0
> > protocol versions.
> >
> > [1]: https://issues.apache.org/jira/browse/IGNITE-11898
> >
> > чт, 15 авг. 2019 г. в 10:23, Павлухин Иван :
> >
> > > Hi Alex,
> > >
> > > Could you please elaborate about thin client protocol versioning. As I
> > > see 1.5.0 is supposed to be a version supporting transactions. And we
> > > already have a version 1.4.0 with affinity awareness support. I
> > > forgot, does Java thin client support affinity awareness? Will it work
> > > properly if it does not?
> > >
> > > ср, 14 авг. 2019 г. в 13:59, Alex Plehanov :
> > > >
> > > > Hi Igniters,
> > > >
> > > > Finally, all dependent tickets are resolved and I've completed the
> > > > implementation of thin client transactions support. The patch [1]
> > > includes
> > > > server-side implementation and java thin client-side implementation.
> > > > Changes to thin client protocol and top-level view of implementation
> > also
> > > > described in IEP [2].
> > > > Can anyone review the patch?
> > > >
> > > > [1]: https://issues.apache.org/jira/browse/IGNITE-9410
> > > > [2]:
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
> > > >
> > > > пн, 27 мая 2019 г. в 13:27, Alex Plehanov :
> > > >
> > > > > Ivan,
> > > > >
> > > > > Yes, .NET client has such capability. Pavel Tupitsyn already
> mentions
> > > it
> > > > > in this thread. As far as I understand, in .NET client
> implementation
> > > to
> > > > > dispatch responses dedicated thread is used.
> > > > > In a draft implementation of IGNITE-11685 I've used another
> approach:
> > > each
> > > > > request thread can read a response (if lock is acquired by this
> > thread
> > > > > successfully) and complete a future of its own request or another
> > > threads
> > > > > request.
> > > > >
> > > > > пн, 27 мая 2019 г. в 13:01, Павлухин Иван :
> > > > >
> > > > >> Alex,
> > > > >>
> > > > >> I am quite curious about async implementations from other clients.
> > Is
> > > > >> there any design document describing such implementations? Does
> .NET
> > > > >> client have such capability?
> > > > >>
> > > > >> Actually, I forgot to finish my previous message. One of my
> concerns
> > > > >> is that a concurrent response dispatch does not sound as a trivial
> > > > >> thing. So, I would like to understand if we already have a good
> > > > >> approach for that. If not then I suppose it worth a discussion.
> > > > >>
> > > > >> пн, 27 мая 2019 г. в 12:51, Alex Plehanov <
> plehanov.a...@gmail.com
> > >:
> > > > >> >
> > > > >> > Hi Ivan.
> > > > >> >
> > > > >> > Thin client transactions support is not only for java thin
> client.
> > > There
> > > > >> > are other clients, some of them already work in async mode.
> > > > >> > Ticket IGNITE-11685 already has draft implementation too, but
> now
> > > it's
> > > > >> > based on some changes to java thin client which were made by
> > > > >> "transaction
> > > > >> > support" implementation. I think this ticket will be ready in a
> > > couple
> > > > >> of
> > > > >> > days after "transaction support" will be merged. And both
> patches
> > > will
> > > > >> be
> > > > >> > included in the same release.
> > > > >> >
> > > > >> > пн, 27 мая 2019 г. в 11:57, Павлухин Иван  >:
> > > > >> >
> > > > >> > > Hi Alex,
> > > > >> > >
> > > > >> > > Regarding a problem with possible deadlock when two concurrent
> > > > >> > > transactions from the same client are trying to lock the same
> > key
> > > and
> > > > >> > > an issue [1]. It seems to me that without fixing the issue
> [1] a
> > > > >> > > client transactions feature is not practical. Everyone who
> uses
> > a
> > > > >> > > client from multiple threads can face a deadlock which is
> 

Re: Thin client: transactions support

[Pavel Tupitsyn]

Hi Alex,

I've checked the patch, protocol changes look good to me. See reply in Jira.
But we certainly need more eyes on this.

On Thu, Aug 15, 2019 at 10:36 AM Alex Plehanov 
wrote:

> Hi Ivan,
>
> Java thin client doesn't support affinity awareness yet (ticket [1] is in
> progress now), but changes to correctly work with protocol version 1.4.0
> was made, so java thin client will work properly with 1.4.0 and 1.5.0
> protocol versions.
>
> [1]: https://issues.apache.org/jira/browse/IGNITE-11898
>
> чт, 15 авг. 2019 г. в 10:23, Павлухин Иван :
>
> > Hi Alex,
> >
> > Could you please elaborate about thin client protocol versioning. As I
> > see 1.5.0 is supposed to be a version supporting transactions. And we
> > already have a version 1.4.0 with affinity awareness support. I
> > forgot, does Java thin client support affinity awareness? Will it work
> > properly if it does not?
> >
> > ср, 14 авг. 2019 г. в 13:59, Alex Plehanov :
> > >
> > > Hi Igniters,
> > >
> > > Finally, all dependent tickets are resolved and I've completed the
> > > implementation of thin client transactions support. The patch [1]
> > includes
> > > server-side implementation and java thin client-side implementation.
> > > Changes to thin client protocol and top-level view of implementation
> also
> > > described in IEP [2].
> > > Can anyone review the patch?
> > >
> > > [1]: https://issues.apache.org/jira/browse/IGNITE-9410
> > > [2]:
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
> > >
> > > пн, 27 мая 2019 г. в 13:27, Alex Plehanov :
> > >
> > > > Ivan,
> > > >
> > > > Yes, .NET client has such capability. Pavel Tupitsyn already mentions
> > it
> > > > in this thread. As far as I understand, in .NET client implementation
> > to
> > > > dispatch responses dedicated thread is used.
> > > > In a draft implementation of IGNITE-11685 I've used another approach:
> > each
> > > > request thread can read a response (if lock is acquired by this
> thread
> > > > successfully) and complete a future of its own request or another
> > threads
> > > > request.
> > > >
> > > > пн, 27 мая 2019 г. в 13:01, Павлухин Иван :
> > > >
> > > >> Alex,
> > > >>
> > > >> I am quite curious about async implementations from other clients.
> Is
> > > >> there any design document describing such implementations? Does .NET
> > > >> client have such capability?
> > > >>
> > > >> Actually, I forgot to finish my previous message. One of my concerns
> > > >> is that a concurrent response dispatch does not sound as a trivial
> > > >> thing. So, I would like to understand if we already have a good
> > > >> approach for that. If not then I suppose it worth a discussion.
> > > >>
> > > >> пн, 27 мая 2019 г. в 12:51, Alex Plehanov  >:
> > > >> >
> > > >> > Hi Ivan.
> > > >> >
> > > >> > Thin client transactions support is not only for java thin client.
> > There
> > > >> > are other clients, some of them already work in async mode.
> > > >> > Ticket IGNITE-11685 already has draft implementation too, but now
> > it's
> > > >> > based on some changes to java thin client which were made by
> > > >> "transaction
> > > >> > support" implementation. I think this ticket will be ready in a
> > couple
> > > >> of
> > > >> > days after "transaction support" will be merged. And both patches
> > will
> > > >> be
> > > >> > included in the same release.
> > > >> >
> > > >> > пн, 27 мая 2019 г. в 11:57, Павлухин Иван :
> > > >> >
> > > >> > > Hi Alex,
> > > >> > >
> > > >> > > Regarding a problem with possible deadlock when two concurrent
> > > >> > > transactions from the same client are trying to lock the same
> key
> > and
> > > >> > > an issue [1]. It seems to me that without fixing the issue [1] a
> > > >> > > client transactions feature is not practical. Everyone who uses
> a
> > > >> > > client from multiple threads can face a deadlock which is
> > impossible
> > > >> > > to deal with. Or am I missing something here?
> > > >> > >
> > > >> > > One workaround I can imagine is failing a transactions execution
> > from
> > > >> > > concurrent threads for a first time.
> > > >> > >
> > > >> > > [1] https://issues.apache.org/jira/browse/IGNITE-11685
> > > >> > >
> > > >> > > вт, 21 мая 2019 г. в 19:05, Alex Plehanov <
> > plehanov.a...@gmail.com>:
> > > >> > > >
> > > >> > > > Guys,
> > > >> > > >
> > > >> > > > I've updated the IEP [1]. Please have a look.
> > > >> > > >
> > > >> > > > [1]
> > > >> > > >
> > > >> > >
> > > >>
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
> > > >> > > >
> > > >> > > >
> > > >> > > > вт, 21 мая 2019 г., 14:19 Alex Plehanov <
> > plehanov.a...@gmail.com>:
> > > >> > > >
> > > >> > > > > Ivan,
> > > >> > > > >
> > > >> > > > > Yes, I have plans to do that (at least for java thin
> client).
> > > >> Something
> > > >> > > > > like new class "ClientTransactionConfiguration" inside
> > > >> > > > > "ClientConfiguration".
> > > >> > > > >
> > > 

Re: Do I have to use --illegal-access=permit for Java thin client and JDBC with JDK 9/10/11.

[Denis Magda]

Denis,

Does it mean we don't need to pass any flags from this list [1] at all for
the JDBC and thin clients?

[1]
https://apacheignite.readme.io/docs/getting-started#section-running-ignite-with-java-9-10-11

-
Denis


On Wed, Aug 14, 2019 at 5:56 PM Denis Mekhanikov 
wrote:

> Hi!
>
> There are two JDK internal things that are used by Ignite: Unsafe and
> sun.nio.ch package.
> None of these things are used by thin clients. So, it’s fine to use thin
> clients without additional flags.
>
> Denis
>
> > On 13 Aug 2019, at 23:01, Shane Duan  wrote:
> >
> > Hi Igniter,
> >
> > I understand that --illegal-access=permit is required for JDK 9/10/11 on
> > Ignite server. But do I have to  include this JVM parameter for Ignite
> Java
> > thin client and JDBC client? I tried some simple test without it and it
> > seems working fine...
> >
> >
> > Thanks,
> > Shane
>
>

Re: Thin client: transactions support

[Alex Plehanov]

Hi Ivan,

Java thin client doesn't support affinity awareness yet (ticket [1] is in
progress now), but changes to correctly work with protocol version 1.4.0
was made, so java thin client will work properly with 1.4.0 and 1.5.0
protocol versions.

[1]: https://issues.apache.org/jira/browse/IGNITE-11898

чт, 15 авг. 2019 г. в 10:23, Павлухин Иван :

> Hi Alex,
>
> Could you please elaborate about thin client protocol versioning. As I
> see 1.5.0 is supposed to be a version supporting transactions. And we
> already have a version 1.4.0 with affinity awareness support. I
> forgot, does Java thin client support affinity awareness? Will it work
> properly if it does not?
>
> ср, 14 авг. 2019 г. в 13:59, Alex Plehanov :
> >
> > Hi Igniters,
> >
> > Finally, all dependent tickets are resolved and I've completed the
> > implementation of thin client transactions support. The patch [1]
> includes
> > server-side implementation and java thin client-side implementation.
> > Changes to thin client protocol and top-level view of implementation also
> > described in IEP [2].
> > Can anyone review the patch?
> >
> > [1]: https://issues.apache.org/jira/browse/IGNITE-9410
> > [2]:
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
> >
> > пн, 27 мая 2019 г. в 13:27, Alex Plehanov :
> >
> > > Ivan,
> > >
> > > Yes, .NET client has such capability. Pavel Tupitsyn already mentions
> it
> > > in this thread. As far as I understand, in .NET client implementation
> to
> > > dispatch responses dedicated thread is used.
> > > In a draft implementation of IGNITE-11685 I've used another approach:
> each
> > > request thread can read a response (if lock is acquired by this thread
> > > successfully) and complete a future of its own request or another
> threads
> > > request.
> > >
> > > пн, 27 мая 2019 г. в 13:01, Павлухин Иван :
> > >
> > >> Alex,
> > >>
> > >> I am quite curious about async implementations from other clients. Is
> > >> there any design document describing such implementations? Does .NET
> > >> client have such capability?
> > >>
> > >> Actually, I forgot to finish my previous message. One of my concerns
> > >> is that a concurrent response dispatch does not sound as a trivial
> > >> thing. So, I would like to understand if we already have a good
> > >> approach for that. If not then I suppose it worth a discussion.
> > >>
> > >> пн, 27 мая 2019 г. в 12:51, Alex Plehanov :
> > >> >
> > >> > Hi Ivan.
> > >> >
> > >> > Thin client transactions support is not only for java thin client.
> There
> > >> > are other clients, some of them already work in async mode.
> > >> > Ticket IGNITE-11685 already has draft implementation too, but now
> it's
> > >> > based on some changes to java thin client which were made by
> > >> "transaction
> > >> > support" implementation. I think this ticket will be ready in a
> couple
> > >> of
> > >> > days after "transaction support" will be merged. And both patches
> will
> > >> be
> > >> > included in the same release.
> > >> >
> > >> > пн, 27 мая 2019 г. в 11:57, Павлухин Иван :
> > >> >
> > >> > > Hi Alex,
> > >> > >
> > >> > > Regarding a problem with possible deadlock when two concurrent
> > >> > > transactions from the same client are trying to lock the same key
> and
> > >> > > an issue [1]. It seems to me that without fixing the issue [1] a
> > >> > > client transactions feature is not practical. Everyone who uses a
> > >> > > client from multiple threads can face a deadlock which is
> impossible
> > >> > > to deal with. Or am I missing something here?
> > >> > >
> > >> > > One workaround I can imagine is failing a transactions execution
> from
> > >> > > concurrent threads for a first time.
> > >> > >
> > >> > > [1] https://issues.apache.org/jira/browse/IGNITE-11685
> > >> > >
> > >> > > вт, 21 мая 2019 г. в 19:05, Alex Plehanov <
> plehanov.a...@gmail.com>:
> > >> > > >
> > >> > > > Guys,
> > >> > > >
> > >> > > > I've updated the IEP [1]. Please have a look.
> > >> > > >
> > >> > > > [1]
> > >> > > >
> > >> > >
> > >>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
> > >> > > >
> > >> > > >
> > >> > > > вт, 21 мая 2019 г., 14:19 Alex Plehanov <
> plehanov.a...@gmail.com>:
> > >> > > >
> > >> > > > > Ivan,
> > >> > > > >
> > >> > > > > Yes, I have plans to do that (at least for java thin client).
> > >> Something
> > >> > > > > like new class "ClientTransactionConfiguration" inside
> > >> > > > > "ClientConfiguration".
> > >> > > > >
> > >> > > > > вт, 21 мая 2019 г. в 13:37, Павлухин Иван <
> vololo...@gmail.com>:
> > >> > > > >
> > >> > > > >> Alex,
> > >> > > > >>
> > >> > > > >> Are you going to introduce settings specifying default values
> > >> for tx
> > >> > > > >> concurrency and isolation in client configuration?
> > >> > > > >>
> > >> > > > >> пн, 20 мая 2019 г. в 19:34, Alex Plehanov <
> > >> plehanov.a...@gmail.com>:
> > >> > > > >> >
> > >> > > > >> > Igor,
> > >> > > > 

Re: IGNITE-7285 Add default query timeout

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

Just to keep history connected. The discussion continued in
http://apache-ignite-developers.2346864.n4.nabble.com/SQL-query-timeout-in-progress-or-abandoned-td42964.html

вт, 18 июн. 2019 г. в 12:22, Павлухин Иван :
>
> Hi Saikat,
>
> Thank you for driving it. I left my comments [1].
>
> [1] https://issues.apache.org/jira/browse/IGNITE-7285
>
> сб, 15 июн. 2019 г. в 20:48, Saikat Maitra :
> >
> > Hi Ivan,
> >
> > Thank you for your email. I have updated the PR to use default query
> > timeout.
> >
> > Please take a look.
> >
> > https://github.com/apache/ignite/pull/6490/files
> >
> > Regards
> > Saikat
> >
> > On Tue, May 7, 2019 at 12:30 AM Ivan Pavlukhina  wrote:
> >
> > > Hi Saikat,
> > >
> > > It is good that we agreed how property in question should be configured.
> > > But I worry about the following. If the PR merged it will not contain a
> > > user value yet because an introduced property is not used. Consequently we
> > > must start using that property before a next AI release. Just one thing to
> > > keep in mind.
> > >
> > > Sent from my iPhone
> > >
> > > > On 4 May 2019, at 05:56, Saikat Maitra  wrote:
> > > >
> > > > Hi Ivan,
> > > >
> > > > Thank you for reviewing the PR. I have updated the PR. Please review and
> > > > share your feedback.
> > > >
> > > > I was thinking of making a separate PR for using the defaultQueryTimeout
> > > > property in query execution flow.
> > > >
> > > > Regards,
> > > > Saikat
> > > >
> > > >> On Wed, May 1, 2019 at 1:04 AM Павлухин Иван 
> > > wrote:
> > > >>
> > > >> Andrey K.,
> > > >>
> > > >>> I think we should develop some kind of "Queries" options on Ignite
> > > >>> configuration.
> > > >>
> > > >> Quite a reasonable idea. We already have couple of query-related
> > > >> properties in IgniteConfiguration and we can move them (in a
> > > >> compatible way) to a query properties sub-aggregate. I think it is
> > > >> better to raise a separate topic for that.
> > > >>
> > > >> ср, 1 мая 2019 г. в 09:00, Павлухин Иван :
> > > >>>
> > > >>> Hi Saikat,
> > > >>>
> > > >>> I left a couple of comment on GitHub [1].
> > > >>>
> > > >>> Perhaps I am missing it but what are the plans for making a default
> > > >>> query timeout workable by using an introduced property in query
> > > >>> execution flow?
> > > >>>
> > > >>> [1] https://github.com/apache/ignite/pull/6490
> > > >>>
> > > >>> вт, 30 апр. 2019 г. в 02:50, Saikat Maitra :
> > > 
> > >  Hi Ivan,
> > > 
> > >  Yes, I checked this CacheQuery default value
> > > 
> > > >>
> > > https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/query/CacheQuery.java#L200
> > > 
> > >  Also, Andrew recommended the same in review feedback.
> > > 
> > >  https://github.com/apache/ignite/pull/6490#discussion_r277730394
> > > 
> > >  Regards,
> > >  Saikat
> > > 
> > > 
> > >  On Mon, Apr 29, 2019 at 3:18 AM Павлухин Иван 
> > > >> wrote:
> > > 
> > > > Hi Saikat,
> > > >
> > > > It a compatibility with previous versions the reason for an
> > > >> indefinite
> > > > timeout by default?
> > > >
> > > > сб, 27 апр. 2019 г. в 16:58, Saikat Maitra  > > >>> :
> > > >>
> > > >> Hi Alexey, Ivan, Andrew
> > > >>
> > > >> I think we can provide an option to configure defaultQueryOption at
> > > >> IgniteConfiguration and set the default value = 0 to imply if not
> > > >> set it
> > > >> will be  execute indefinitely but then user can set this value
> > > >> based on
> > > > the
> > > >> application preferences and use it in addition to SQL query
> > > >> timeout.
> > > >>
> > > >> I have updated the PR accordingly.
> > > >>
> > > >> Please review and share if any changes required.
> > > >>
> > > >> Regards,
> > > >> Saikat
> > > >>
> > > >> On Wed, Apr 24, 2019 at 4:33 AM Alexey Kuznetsov <
> > > >> akuznet...@apache.org>
> > > >> wrote:
> > > >>
> > > >>> Hi Saikat and Ivan,
> > > >>>
> > > >>> I think that properties that related to SQL should not be
> > > >> configured on
> > > >>> caches.
> > > >>> We already put a lot of effort to decouple SQL from caches.
> > > >>>
> > > >>> I think we should develop some kind of "Queries" options on
> > > >> Ignite
> > > >>> configuration.
> > > >>>
> > > >>> What do you think?
> > > >>>
> > > >>>
> > > >>> On Wed, Apr 24, 2019 at 3:22 PM Павлухин Иван <
> > > >> vololo...@gmail.com>
> > > > wrote:
> > > >>>
> > >  Hi Saikat,
> > > 
> > >  I think that we should have a discussion and choose a place
> > > >> where a
> > >  "default query timeout" property will be configured.
> > > 
> > >  Generally, I think that a real (user) problem is possibility
> > > >> for
> > >  queries to execute indefinitely. And I have no doubts that we
> > > >> can
> > >  

Re: Coding guidelines. Useless JavaDoc comments.

[Anton Vinogradov]

Nikolay,

Params like
* @param tx Cache transaction.
* @param val Value to set.
* @param oldVal Old value.
* @param topVer Topology version.
* @param taskName Task name.
seems to be obvious to everyone.
No reason to hove the documented.

In case you doubt it obvious, just document it.

On Thu, Aug 15, 2019 at 10:12 AM Nikolay Izhikov 
wrote:

> Hello, Anton.
>
> > I'd like to propose to have only non-obvious params explained at
> > non-public method's Javadoc.
>
> Non-obvious for whom?
> Please, remember about guys who just came into Ignite community.
>
>
>
>
> В Чт, 15/08/2019 в 10:05 +0300, Anton Vinogradov пишет:
> > My +1 to optional Javadoc at private methods, fields, and classes.
> > The reviewer should guaranty that everything is clear.
> > But, in case everything is clear without redundant Javadoc there is no
> need
> > to have it.
> >
> > So, my proposal is to allow /** */ for non-public fields and methods (to
> > keep readability between documented and obvious fields/methods).
> > Also, I'd like to propose to have only non-obvious params explained at
> > non-public method's Javadoc.
> >
> > On Sun, Aug 11, 2019 at 9:13 AM Павлухин Иван 
> wrote:
> >
> > > Maxim,
> > >
> > > > I'd prefer to leave the current situation with Javadoc as it is and
> just
> > >
> > > to ask to apply the patch [1][2]. Can you? :-)
> > >
> > > You caught me. I left my comments for that PR
> > >
> > > .Pavel and all,
> > >
> > > > I think that API of our core internal things like PageMemory, WAL,
> all
> > >
> > > existing managers and processors should be as well documented as
> possible.
> > >
> > > No doubts here.
> > >
> > > > Documentation should be a result of a proper code review.
> > >
> > > I suppose it does not mean that documentation should be written after
> > > a review. I suppose it means that we should not have a poor
> > > documentation *after* a review. Overall, Pavel's last message conforms
> > > well with my opinion on the subject.
> > >
> > > чт, 8 авг. 2019 г. в 18:34, Pavel Kovalenko :
> > > >
> > > > I can agree that some part of javadocs we have is useless. It
> relates to
> > > > DTOs, getters/setters without side-effects, short self-descriptive
> > >
> > > methods.
> > > > In an ideal world, proper modularization of architecture, leading to
> > > > KISS/SOLID/DRY/etc. principles, writing self-documented code should
> > >
> > > result
> > > > in javadocs disappearing, as they become not needed.
> > > > We live in a not ideal world. We don't have good architecture and
> can't
> > > > always lead to mentioned principles, because we need sometimes
> sacrifice
> > > > readability for optimization, fixing a critical bug, etc.
> > > > I think that API of our core internal things like PageMemory, WAL,
> all
> > > > existing managers and processors should be as well documented as
> > >
> > > possible.
> > > > If a developer uses some module / manager / processor without looking
> > > > inside, reading the only description of public methods, it's a good
> sign
> > > > that this part of the functionality is well documented.
> > > > Internal implementation should be also clear for a developer who
> likes to
> > > > make a change inside it. Every optimization, avoiding
> race-condition, not
> > > > obvious thing and especially crutch must be documented as detailed as
> > > > possible.
> > > > Documentation should be a result of a proper code review. If a
> reviewer
> > >
> > > has
> > > > questions regarding any code line it should be either refactored to
> make
> > > > this thing obvious or well documented.
> > > > If a class or method is self-documented and obvious there is no need
> to
> > > > document it anyway.
> > > > if each person takes the code review as seriously as possible,
> > > > documentation and code will be better automatically.
> > > > Mandatory documentation in places where it's really not needed looks
> > >
> > > like a
> > > > burden. A developer will avoid write it properly everywhere or do it
> > >
> > > "just
> > > > for check" and this will influence on documentation with the negative
> > >
> > > side.
> > > > Flexible approach with mandatory / optional javadocs with good code
> > >
> > > review
> > > > will result in readability improvement overall.
> > > >
> > > >
> > > > чт, 8 авг. 2019 г. в 17:52, Maxim Muzafarov :
> > > >
> > > > > Ivan,
> > > > >
> > > > > It is not a problem to check Javadocs at the moment code syle
> checking
> > > > > performed, but do we really need this? And the human-factor you
> > > > > mentioned above is also related to the `self-descriptive` names. I
> > > > > assume, that someone now is desiring to use single-letter variables
> > > > > and single-letter class names to save space an time. We will always
> > > > > have such an opinion race.
> > > > >
> > > > > I'd prefer to leave the current situation with Javadoc as it is and
> > > > > just to ask to apply the patch [1][2]. Can you? :-)
> > > > >
> > > > > [1] 

Re: Re[2]: Asynchronous registration of binary metadata

[Sergey Chugunov]

Denis,

Thanks for bringing this issue up, decision to write binary metadata from
discovery thread was really a tough decision to make.
I don't think that moving metadata to metastorage is a silver bullet here
as this approach also has its drawbacks and is not an easy change.

In addition to workarounds suggested by Alexei we have two choices to
offload write operation from discovery thread:

   1. Your scheme with a separate writer thread and futures completed when
   write operation is finished.
   2. PME-like protocol with obvious complications like failover and
   asynchronous wait for replies over communication layer.

Your suggestion looks easier from code complexity perspective but in my
view it increases chances to get into starvation. Now if some node faces
really long delays during write op it is gonna be kicked out of topology by
discovery protocol. In your case it is possible that more and more threads
from other pools may stuck waiting on the operation future, it is also not
good.

What do you think?

I also think that if we want to approach this issue systematically, we need
to do a deep analysis of metastorage option as well and to finally choose
which road we wanna go.

Thanks!

On Thu, Aug 15, 2019 at 9:28 AM Zhenya Stanilovsky
 wrote:

>
> >
> >> 1. Yes, only on OS failures. In such case data will be received from
> alive
> >> nodes later.
> What behavior would be in case of one node ? I suppose someone can obtain
> cache data without unmarshalling schema, what in this case would be with
> grid operability?
>
> >
> >> 2. Yes, for walmode=FSYNC writes to metastore will be slow. But such
> mode
> >> should not be used if you have more than two nodes in grid because it
> has
> >> huge impact on performance.
> Is wal mode affects metadata store ?
>
> >
> >>
> >> ср, 14 авг. 2019 г. в 14:29, Denis Mekhanikov < dmekhani...@gmail.com
> >:
> >>
> >>> Folks,
> >>>
> >>> Thanks for showing interest in this issue!
> >>>
> >>> Alexey,
> >>>
>  I think removing fsync could help to mitigate performance issues with
> >>> current implementation
> >>>
> >>> Is my understanding correct, that if we remove fsync, then discovery
> won’t
> >>> be blocked, and data will be flushed to disk in background, and loss of
> >>> information will be possible only on OS failure? It sounds like an
> >>> acceptable workaround to me.
> >>>
> >>> Will moving metadata to metastore actually resolve this issue? Please
> >>> correct me if I’m wrong, but we will still need to write the
> information to
> >>> WAL before releasing the discovery thread. If WAL mode is FSYNC, then
> the
> >>> issue will still be there. Or is it planned to abandon the
> discovery-based
> >>> protocol at all?
> >>>
> >>> Evgeniy, Ivan,
> >>>
> >>> In my particular case the data wasn’t too big. It was a slow
> virtualised
> >>> disk with encryption, that made operations slow. Given that there are
> 200
> >>> nodes in a cluster, where every node writes slowly, and this process is
> >>> sequential, one piece of metadata is registered extremely slowly.
> >>>
> >>> Ivan, answering to your other questions:
> >>>
>  2. Do we need a persistent metadata for in-memory caches? Or is it so
> >>> accidentally?
> >>>
> >>> It should be checked, if it’s safe to stop writing marshaller mappings
> to
> >>> disk without loosing any guarantees.
> >>> But anyway, I would like to have a property, that would control this.
> If
> >>> metadata registration is slow, then initial cluster warmup may take a
> >>> while. So, if we preserve metadata on disk, then we will need to warm
> it up
> >>> only once, and further restarts won’t be affected.
> >>>
>  Do we really need a fast fix here?
> >>>
> >>> I would like a fix, that could be implemented now, since the activity
> with
> >>> moving metadata to metastore doesn’t sound like a quick one. Having a
> >>> temporary solution would be nice.
> >>>
> >>> Denis
> >>>
>  On 14 Aug 2019, at 11:53, Павлухин Иван < vololo...@gmail.com >
> wrote:
> 
>  Denis,
> 
>  Several clarifying questions:
>  1. Do you have an idea why metadata registration takes so long? So
>  poor disks? So many data to write? A contention with disk writes by
>  other subsystems?
>  2. Do we need a persistent metadata for in-memory caches? Or is it so
>  accidentally?
> 
>  Generally, I think that it is possible to move metadata saving
>  operations out of discovery thread without loosing required
>  consistency/integrity.
> 
>  As Alex mentioned using metastore looks like a better solution. Do we
>  really need a fast fix here? (Are we talking about fast fix?)
> 
>  ср, 14 авг. 2019 г. в 11:45, Zhenya Stanilovsky
> >>> < arzamas...@mail.ru.invalid >:
> >
> > Alexey, but in this case customer need to be informed, that whole
> (for
> >>> example 1 node) cluster crash (power off) could lead to partial data
> >>> unavailability.
> > And may be further index corruption.

Re: Thin client: transactions support

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

Hi Alex,

Could you please elaborate about thin client protocol versioning. As I
see 1.5.0 is supposed to be a version supporting transactions. And we
already have a version 1.4.0 with affinity awareness support. I
forgot, does Java thin client support affinity awareness? Will it work
properly if it does not?

ср, 14 авг. 2019 г. в 13:59, Alex Plehanov :
>
> Hi Igniters,
>
> Finally, all dependent tickets are resolved and I've completed the
> implementation of thin client transactions support. The patch [1] includes
> server-side implementation and java thin client-side implementation.
> Changes to thin client protocol and top-level view of implementation also
> described in IEP [2].
> Can anyone review the patch?
>
> [1]: https://issues.apache.org/jira/browse/IGNITE-9410
> [2]:
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
>
> пн, 27 мая 2019 г. в 13:27, Alex Plehanov :
>
> > Ivan,
> >
> > Yes, .NET client has such capability. Pavel Tupitsyn already mentions it
> > in this thread. As far as I understand, in .NET client implementation to
> > dispatch responses dedicated thread is used.
> > In a draft implementation of IGNITE-11685 I've used another approach: each
> > request thread can read a response (if lock is acquired by this thread
> > successfully) and complete a future of its own request or another threads
> > request.
> >
> > пн, 27 мая 2019 г. в 13:01, Павлухин Иван :
> >
> >> Alex,
> >>
> >> I am quite curious about async implementations from other clients. Is
> >> there any design document describing such implementations? Does .NET
> >> client have such capability?
> >>
> >> Actually, I forgot to finish my previous message. One of my concerns
> >> is that a concurrent response dispatch does not sound as a trivial
> >> thing. So, I would like to understand if we already have a good
> >> approach for that. If not then I suppose it worth a discussion.
> >>
> >> пн, 27 мая 2019 г. в 12:51, Alex Plehanov :
> >> >
> >> > Hi Ivan.
> >> >
> >> > Thin client transactions support is not only for java thin client. There
> >> > are other clients, some of them already work in async mode.
> >> > Ticket IGNITE-11685 already has draft implementation too, but now it's
> >> > based on some changes to java thin client which were made by
> >> "transaction
> >> > support" implementation. I think this ticket will be ready in a couple
> >> of
> >> > days after "transaction support" will be merged. And both patches will
> >> be
> >> > included in the same release.
> >> >
> >> > пн, 27 мая 2019 г. в 11:57, Павлухин Иван :
> >> >
> >> > > Hi Alex,
> >> > >
> >> > > Regarding a problem with possible deadlock when two concurrent
> >> > > transactions from the same client are trying to lock the same key and
> >> > > an issue [1]. It seems to me that without fixing the issue [1] a
> >> > > client transactions feature is not practical. Everyone who uses a
> >> > > client from multiple threads can face a deadlock which is impossible
> >> > > to deal with. Or am I missing something here?
> >> > >
> >> > > One workaround I can imagine is failing a transactions execution from
> >> > > concurrent threads for a first time.
> >> > >
> >> > > [1] https://issues.apache.org/jira/browse/IGNITE-11685
> >> > >
> >> > > вт, 21 мая 2019 г. в 19:05, Alex Plehanov :
> >> > > >
> >> > > > Guys,
> >> > > >
> >> > > > I've updated the IEP [1]. Please have a look.
> >> > > >
> >> > > > [1]
> >> > > >
> >> > >
> >> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
> >> > > >
> >> > > >
> >> > > > вт, 21 мая 2019 г., 14:19 Alex Plehanov :
> >> > > >
> >> > > > > Ivan,
> >> > > > >
> >> > > > > Yes, I have plans to do that (at least for java thin client).
> >> Something
> >> > > > > like new class "ClientTransactionConfiguration" inside
> >> > > > > "ClientConfiguration".
> >> > > > >
> >> > > > > вт, 21 мая 2019 г. в 13:37, Павлухин Иван :
> >> > > > >
> >> > > > >> Alex,
> >> > > > >>
> >> > > > >> Are you going to introduce settings specifying default values
> >> for tx
> >> > > > >> concurrency and isolation in client configuration?
> >> > > > >>
> >> > > > >> пн, 20 мая 2019 г. в 19:34, Alex Plehanov <
> >> plehanov.a...@gmail.com>:
> >> > > > >> >
> >> > > > >> > Igor,
> >> > > > >> >
> >> > > > >> > Perhaps we don't really need to use server's default values
> >> for tx
> >> > > > >> > parameters. It's a minor fix and can be easily implemented if
> >> it
> >> > > will be
> >> > > > >> > required in the future.
> >> > > > >> > I will update IEP tomorrow regarding point 1 and point 3.
> >> > > > >> > Thanks for your feedback.
> >> > > > >> >
> >> > > > >> > пн, 20 мая 2019 г. в 15:24, Igor Sapego :
> >> > > > >> >
> >> > > > >> > > Ivan,
> >> > > > >> > >
> >> > > > >> > > This may be a good point for a DBMS, but Ignite is much more
> >> than
> >> > > > >> just a
> >> > > > >> > > DBMS and Ignite client code is not just an SQL query (which
> >> > > 

Re: Coding guidelines. Useless JavaDoc comments.

[Nikolay Izhikov]

Hello, Anton.

> I'd like to propose to have only non-obvious params explained at
> non-public method's Javadoc.

Non-obvious for whom?
Please, remember about guys who just came into Ignite community.




В Чт, 15/08/2019 в 10:05 +0300, Anton Vinogradov пишет:
> My +1 to optional Javadoc at private methods, fields, and classes.
> The reviewer should guaranty that everything is clear.
> But, in case everything is clear without redundant Javadoc there is no need
> to have it.
> 
> So, my proposal is to allow /** */ for non-public fields and methods (to
> keep readability between documented and obvious fields/methods).
> Also, I'd like to propose to have only non-obvious params explained at
> non-public method's Javadoc.
> 
> On Sun, Aug 11, 2019 at 9:13 AM Павлухин Иван  wrote:
> 
> > Maxim,
> > 
> > > I'd prefer to leave the current situation with Javadoc as it is and just
> > 
> > to ask to apply the patch [1][2]. Can you? :-)
> > 
> > You caught me. I left my comments for that PR
> > 
> > .Pavel and all,
> > 
> > > I think that API of our core internal things like PageMemory, WAL, all
> > 
> > existing managers and processors should be as well documented as possible.
> > 
> > No doubts here.
> > 
> > > Documentation should be a result of a proper code review.
> > 
> > I suppose it does not mean that documentation should be written after
> > a review. I suppose it means that we should not have a poor
> > documentation *after* a review. Overall, Pavel's last message conforms
> > well with my opinion on the subject.
> > 
> > чт, 8 авг. 2019 г. в 18:34, Pavel Kovalenko :
> > > 
> > > I can agree that some part of javadocs we have is useless. It relates to
> > > DTOs, getters/setters without side-effects, short self-descriptive
> > 
> > methods.
> > > In an ideal world, proper modularization of architecture, leading to
> > > KISS/SOLID/DRY/etc. principles, writing self-documented code should
> > 
> > result
> > > in javadocs disappearing, as they become not needed.
> > > We live in a not ideal world. We don't have good architecture and can't
> > > always lead to mentioned principles, because we need sometimes sacrifice
> > > readability for optimization, fixing a critical bug, etc.
> > > I think that API of our core internal things like PageMemory, WAL, all
> > > existing managers and processors should be as well documented as
> > 
> > possible.
> > > If a developer uses some module / manager / processor without looking
> > > inside, reading the only description of public methods, it's a good sign
> > > that this part of the functionality is well documented.
> > > Internal implementation should be also clear for a developer who likes to
> > > make a change inside it. Every optimization, avoiding race-condition, not
> > > obvious thing and especially crutch must be documented as detailed as
> > > possible.
> > > Documentation should be a result of a proper code review. If a reviewer
> > 
> > has
> > > questions regarding any code line it should be either refactored to make
> > > this thing obvious or well documented.
> > > If a class or method is self-documented and obvious there is no need to
> > > document it anyway.
> > > if each person takes the code review as seriously as possible,
> > > documentation and code will be better automatically.
> > > Mandatory documentation in places where it's really not needed looks
> > 
> > like a
> > > burden. A developer will avoid write it properly everywhere or do it
> > 
> > "just
> > > for check" and this will influence on documentation with the negative
> > 
> > side.
> > > Flexible approach with mandatory / optional javadocs with good code
> > 
> > review
> > > will result in readability improvement overall.
> > > 
> > > 
> > > чт, 8 авг. 2019 г. в 17:52, Maxim Muzafarov :
> > > 
> > > > Ivan,
> > > > 
> > > > It is not a problem to check Javadocs at the moment code syle checking
> > > > performed, but do we really need this? And the human-factor you
> > > > mentioned above is also related to the `self-descriptive` names. I
> > > > assume, that someone now is desiring to use single-letter variables
> > > > and single-letter class names to save space an time. We will always
> > > > have such an opinion race.
> > > > 
> > > > I'd prefer to leave the current situation with Javadoc as it is and
> > > > just to ask to apply the patch [1][2]. Can you? :-)
> > > > 
> > > > [1] https://issues.apache.org/jira/browse/IGNITE-12051
> > > > [2] https://github.com/apache/ignite/pull/6760
> > > > 
> > > > On Thu, 8 Aug 2019 at 17:24, Павлухин Иван 
> > 
> > wrote:
> > > > > 
> > > > > Maxim,
> > > > > 
> > > > > My main concern here is a human factor. Humans are usually not so
> > 
> > good
> > > > > in keeping documentation always in sync with a code. Examples from an
> > > > > actual PR:
> > > > > /**
> > > > > * @param nodeId The remote node id.
> > > > > * @param channel The channel to notify listeners with.
> > > > > */
> > > > > private void onChannelOpened0(UUID nodeId, 

Re: Coding guidelines. Useless JavaDoc comments.

[Anton Vinogradov]

My +1 to optional Javadoc at private methods, fields, and classes.
The reviewer should guaranty that everything is clear.
But, in case everything is clear without redundant Javadoc there is no need
to have it.

So, my proposal is to allow /** */ for non-public fields and methods (to
keep readability between documented and obvious fields/methods).
Also, I'd like to propose to have only non-obvious params explained at
non-public method's Javadoc.

On Sun, Aug 11, 2019 at 9:13 AM Павлухин Иван  wrote:

> Maxim,
>
> > I'd prefer to leave the current situation with Javadoc as it is and just
> to ask to apply the patch [1][2]. Can you? :-)
>
> You caught me. I left my comments for that PR
>
> .Pavel and all,
>
> > I think that API of our core internal things like PageMemory, WAL, all
> existing managers and processors should be as well documented as possible.
>
> No doubts here.
>
> > Documentation should be a result of a proper code review.
>
> I suppose it does not mean that documentation should be written after
> a review. I suppose it means that we should not have a poor
> documentation *after* a review. Overall, Pavel's last message conforms
> well with my opinion on the subject.
>
> чт, 8 авг. 2019 г. в 18:34, Pavel Kovalenko :
> >
> > I can agree that some part of javadocs we have is useless. It relates to
> > DTOs, getters/setters without side-effects, short self-descriptive
> methods.
> > In an ideal world, proper modularization of architecture, leading to
> > KISS/SOLID/DRY/etc. principles, writing self-documented code should
> result
> > in javadocs disappearing, as they become not needed.
> > We live in a not ideal world. We don't have good architecture and can't
> > always lead to mentioned principles, because we need sometimes sacrifice
> > readability for optimization, fixing a critical bug, etc.
> > I think that API of our core internal things like PageMemory, WAL, all
> > existing managers and processors should be as well documented as
> possible.
> > If a developer uses some module / manager / processor without looking
> > inside, reading the only description of public methods, it's a good sign
> > that this part of the functionality is well documented.
> > Internal implementation should be also clear for a developer who likes to
> > make a change inside it. Every optimization, avoiding race-condition, not
> > obvious thing and especially crutch must be documented as detailed as
> > possible.
> > Documentation should be a result of a proper code review. If a reviewer
> has
> > questions regarding any code line it should be either refactored to make
> > this thing obvious or well documented.
> > If a class or method is self-documented and obvious there is no need to
> > document it anyway.
> > if each person takes the code review as seriously as possible,
> > documentation and code will be better automatically.
> > Mandatory documentation in places where it's really not needed looks
> like a
> > burden. A developer will avoid write it properly everywhere or do it
> "just
> > for check" and this will influence on documentation with the negative
> side.
> > Flexible approach with mandatory / optional javadocs with good code
> review
> > will result in readability improvement overall.
> >
> >
> > чт, 8 авг. 2019 г. в 17:52, Maxim Muzafarov :
> >
> > > Ivan,
> > >
> > > It is not a problem to check Javadocs at the moment code syle checking
> > > performed, but do we really need this? And the human-factor you
> > > mentioned above is also related to the `self-descriptive` names. I
> > > assume, that someone now is desiring to use single-letter variables
> > > and single-letter class names to save space an time. We will always
> > > have such an opinion race.
> > >
> > > I'd prefer to leave the current situation with Javadoc as it is and
> > > just to ask to apply the patch [1][2]. Can you? :-)
> > >
> > > [1] https://issues.apache.org/jira/browse/IGNITE-12051
> > > [2] https://github.com/apache/ignite/pull/6760
> > >
> > > On Thu, 8 Aug 2019 at 17:24, Павлухин Иван 
> wrote:
> > > >
> > > > Maxim,
> > > >
> > > > My main concern here is a human factor. Humans are usually not so
> good
> > > > in keeping documentation always in sync with a code. Examples from an
> > > > actual PR:
> > > > /**
> > > > * @param nodeId The remote node id.
> > > > * @param channel The channel to notify listeners with.
> > > > */
> > > > private void onChannelOpened0(UUID nodeId, GridIoMessage initMsg,
> > > > Channel channel)
> > > >
> > > > First, there is a mismatch between number of parameters in javadoc
> and
> > > > code. Second, e.g. nodeId name can be made self-descriptive rmtNodeId
> > > > name.
> > > >
> > > > Mandatory javadocs do not imply good javadocs. Good javadocs do not
> > > > imply javadocs for every method and field. For me, mandatory and good
> > > > javadocs are like communism. Sounds quite nice in theory, but not
> > > > feasible in practice.
> > > >
> > > > чт, 8 авг. 2019 г. в 16:55, Denis Garus :

Re[2]: Asynchronous registration of binary metadata

[Zhenya Stanilovsky]

>
>> 1. Yes, only on OS failures. In such case data will be received from alive
>> nodes later.
What behavior would be in case of one node ? I suppose someone can obtain cache 
data without unmarshalling schema, what in this case would be with grid 
operability?

>
>> 2. Yes, for walmode=FSYNC writes to metastore will be slow. But such mode
>> should not be used if you have more than two nodes in grid because it has
>> huge impact on performance.
Is wal mode affects metadata store ?

>
>> 
>> ср, 14 авг. 2019 г. в 14:29, Denis Mekhanikov < dmekhani...@gmail.com >:
>> 
>>> Folks,
>>> 
>>> Thanks for showing interest in this issue!
>>> 
>>> Alexey,
>>> 
 I think removing fsync could help to mitigate performance issues with
>>> current implementation
>>> 
>>> Is my understanding correct, that if we remove fsync, then discovery won’t
>>> be blocked, and data will be flushed to disk in background, and loss of
>>> information will be possible only on OS failure? It sounds like an
>>> acceptable workaround to me.
>>> 
>>> Will moving metadata to metastore actually resolve this issue? Please
>>> correct me if I’m wrong, but we will still need to write the information to
>>> WAL before releasing the discovery thread. If WAL mode is FSYNC, then the
>>> issue will still be there. Or is it planned to abandon the discovery-based
>>> protocol at all?
>>> 
>>> Evgeniy, Ivan,
>>> 
>>> In my particular case the data wasn’t too big. It was a slow virtualised
>>> disk with encryption, that made operations slow. Given that there are 200
>>> nodes in a cluster, where every node writes slowly, and this process is
>>> sequential, one piece of metadata is registered extremely slowly.
>>> 
>>> Ivan, answering to your other questions:
>>> 
 2. Do we need a persistent metadata for in-memory caches? Or is it so
>>> accidentally?
>>> 
>>> It should be checked, if it’s safe to stop writing marshaller mappings to
>>> disk without loosing any guarantees.
>>> But anyway, I would like to have a property, that would control this. If
>>> metadata registration is slow, then initial cluster warmup may take a
>>> while. So, if we preserve metadata on disk, then we will need to warm it up
>>> only once, and further restarts won’t be affected.
>>> 
 Do we really need a fast fix here?
>>> 
>>> I would like a fix, that could be implemented now, since the activity with
>>> moving metadata to metastore doesn’t sound like a quick one. Having a
>>> temporary solution would be nice.
>>> 
>>> Denis
>>> 
 On 14 Aug 2019, at 11:53, Павлухин Иван < vololo...@gmail.com > wrote:
 
 Denis,
 
 Several clarifying questions:
 1. Do you have an idea why metadata registration takes so long? So
 poor disks? So many data to write? A contention with disk writes by
 other subsystems?
 2. Do we need a persistent metadata for in-memory caches? Or is it so
 accidentally?
 
 Generally, I think that it is possible to move metadata saving
 operations out of discovery thread without loosing required
 consistency/integrity.
 
 As Alex mentioned using metastore looks like a better solution. Do we
 really need a fast fix here? (Are we talking about fast fix?)
 
 ср, 14 авг. 2019 г. в 11:45, Zhenya Stanilovsky
>>> < arzamas...@mail.ru.invalid >:
> 
> Alexey, but in this case customer need to be informed, that whole (for
>>> example 1 node) cluster crash (power off) could lead to partial data
>>> unavailability.
> And may be further index corruption.
> 1. Why your meta takes a substantial size? may be context leaking ?
> 2. Could meta be compressed ?
> 
> 
>> Среда, 14 августа 2019, 11:22 +03:00 от Alexei Scherbakov <
>>>  alexey.scherbak...@gmail.com >:
>> 
>> Denis Mekhanikov,
>> 
>> Currently metadata are fsync'ed on write. This might be the case of
>> slow-downs in case of metadata burst writes.
>> I think removing fsync could help to mitigate performance issues with
>> current implementation until proper solution will be implemented:
>>> moving
>> metadata to metastore.
>> 
>> 
>> вт, 13 авг. 2019 г. в 17:09, Denis Mekhanikov <  dmekhani...@gmail.com
 :
>> 
>>> I would also like to mention, that marshaller mappings are written to
>>> disk
>>> even if persistence is disabled.
>>> So, this issue affects purely in-memory clusters as well.
>>> 
>>> Denis
>>> 
 On 13 Aug 2019, at 17:06, Denis Mekhanikov <  dmekhani...@gmail.com >
>>> wrote:
 
 Hi!
 
 When persistence is enabled, binary metadata is written to disk upon
>>> registration. Currently it happens in the discovery thread, which
>>> makes
>>> processing of related messages very slow.
 There are cases, when a lot of nodes and slow disks can make every
>>> binary type be registered for several minutes. Plus it blocks
>>> processing of
>>> other messages.