Re: Apache Ignite 2.6 - Packages roadmap

[Dmitriy Setrakyan]

Petr,

I think it was Denis who reworked the documentation. In any case, if you
see something lacking you can fix it.

Just to clarify, are you suggesting that you don't have to be root to run
the Ignite process after the package install?

D.

On Mon, Jun 4, 2018 at 9:31 PM, Petr Ivanov  wrote:

> >   1. Remove the requirement to run Ignite scripts as root. This will be a
> >   huge No in most environment and we should fix it.
>
>
> > There is already a ticket for point 1:
> > https://issues.apache.org/jira/browse/IGNITE-8695 <
> https://issues.apache.org/jira/browse/IGNITE-8695>
>
> 1. I am not the author of this part of instruction — someone, who
> completely reworked that section about running ignite as standalone process
> should also remove / rework the “require root permissions” part because in
> my version of documentation there was requirement to run as root, but
> requirement to run as ignite user (logining in into it with specified
> shell, because it is disabled by default — as it should be done for every
> service) due to packages’ postinstall scripts that assign ignite user
> permissions on all Apache Ignite directories.
>
>
> >   2. Add Ignite "bin" folder to PATH, so all Ignite scripts will be
> >   executable without specifying the whole path name (not sure if it is
> >   already done or not)
>
> 2. We should not. Instead, we have to symlink all required scripts from
> bin/ to /usr/bin, providing changes to scripts it selves, so that they can
> be called from /usr/bin as if from $IGNITE_HOME ('readlink' command to find
> real symlink location).
>
>
> > I do remember the multi-package approach was suggested as a solution to
> > trim down the size of the binary that is hosted by ASF. Since now the
> > binaries are hosted in Bintray, do we still have that issue? If it's fine
> > to preload and keep big binaries in Bintray then I would suggest us to
> > postpone the multi-package activities until there is a real demand.
>
>
> 3. The multi-package approach was also suggested for more accurate
> architecture and more flexible updates. And working with smaller packages
> on development stage is too more reliable and easy.
> Yes, we can postpone it (for how long?) but I’d like to insist on proposed
> layout (and reimplement it rather quickly), because ta least it shows our
> packages as more mature (no one ships theirs software in single monolith
> package, especially in official repositories).
>
>
> > - Make sqlline.sh callable from command line (PATH). E.g. symlink it as
> > /usr/bin/sqlline-ignite, make sure it works.
> > - Fix control.sh and visor-cmd, expose them too.
>
> 4. See p.2. Indeed they need to be fixes and exposes 'by the book’.
>
>
> > - Allow specifying of JDK implementation and JDK arguments for Apache
> > Ignite startup. Preferably on per configuration basis.
>
> 5. Agree. We need some kind of 'setenv.sh’ for user-side JDK configuration.
>
>
> > - Allow adding-removing "modules" to classpath of Ignite - again,
> > preferably on per configuration basis. E.g. what happens if I want to
> turn
> > ON geospatial/
>
> 6. Agree, was thinking of it too, in form of 'a2enmod'-like utility for
> enabling / disabling optional libs and modules.
>
>
> > - [OPTIONAL] Ship Apache Ignite with a special config which only listens
> on
> > localhost. This is for lazy people who can get into trouble by installing
> > package without looking without security implications.
>
> 7. Arguable. Even if we create such config and put into delivery, there is
> no guarantee that user will read documentation about necessity of using
> this special config for security reasons.
> I would add BIG warning text to Ignite’s log about security implications
> of unprotected cluster.
>
>
> > With regards to splitting package, I think we could have a few of them
> > (a-i-core, a-i-doc, a-i-c++, a-i-.net) but I don't think we need to have
> a
> > half dozen of those right away. This was mostly realised as an
> antipattern.
>
> 8. I would at least removed benchmarks, docs and platforms from the core
> package.

Re: Apache Ignite 2.6 - Packages roadmap

[Petr Ivanov]

>   1. Remove the requirement to run Ignite scripts as root. This will be a
>   huge No in most environment and we should fix it.


> There is already a ticket for point 1:
> https://issues.apache.org/jira/browse/IGNITE-8695 
> 

1. I am not the author of this part of instruction — someone, who completely 
reworked that section about running ignite as standalone process should also 
remove / rework the “require root permissions” part because in my version of 
documentation there was requirement to run as root, but requirement to run as 
ignite user (logining in into it with specified shell, because it is disabled 
by default — as it should be done for every service) due to packages’ 
postinstall scripts that assign ignite user permissions on all Apache Ignite 
directories.


>   2. Add Ignite "bin" folder to PATH, so all Ignite scripts will be
>   executable without specifying the whole path name (not sure if it is
>   already done or not)

2. We should not. Instead, we have to symlink all required scripts from bin/ to 
/usr/bin, providing changes to scripts it selves, so that they can be called 
from /usr/bin as if from $IGNITE_HOME ('readlink' command to find real symlink 
location).


> I do remember the multi-package approach was suggested as a solution to
> trim down the size of the binary that is hosted by ASF. Since now the
> binaries are hosted in Bintray, do we still have that issue? If it's fine
> to preload and keep big binaries in Bintray then I would suggest us to
> postpone the multi-package activities until there is a real demand.


3. The multi-package approach was also suggested for more accurate architecture 
and more flexible updates. And working with smaller packages on development 
stage is too more reliable and easy.
Yes, we can postpone it (for how long?) but I’d like to insist on proposed 
layout (and reimplement it rather quickly), because ta least it shows our 
packages as more mature (no one ships theirs software in single monolith 
package, especially in official repositories).


> - Make sqlline.sh callable from command line (PATH). E.g. symlink it as
> /usr/bin/sqlline-ignite, make sure it works.
> - Fix control.sh and visor-cmd, expose them too.

4. See p.2. Indeed they need to be fixes and exposes 'by the book’.


> - Allow specifying of JDK implementation and JDK arguments for Apache
> Ignite startup. Preferably on per configuration basis.

5. Agree. We need some kind of 'setenv.sh’ for user-side JDK configuration.


> - Allow adding-removing "modules" to classpath of Ignite - again,
> preferably on per configuration basis. E.g. what happens if I want to turn
> ON geospatial/

6. Agree, was thinking of it too, in form of 'a2enmod'-like utility for 
enabling / disabling optional libs and modules.


> - [OPTIONAL] Ship Apache Ignite with a special config which only listens on
> localhost. This is for lazy people who can get into trouble by installing
> package without looking without security implications.

7. Arguable. Even if we create such config and put into delivery, there is no 
guarantee that user will read documentation about necessity of using this 
special config for security reasons.
I would add BIG warning text to Ignite’s log about security implications of 
unprotected cluster.


> With regards to splitting package, I think we could have a few of them
> (a-i-core, a-i-doc, a-i-c++, a-i-.net) but I don't think we need to have a
> half dozen of those right away. This was mostly realised as an antipattern.

8. I would at least removed benchmarks, docs and platforms from the core 
package.

[jira] [Created] (IGNITE-8698) Presto can't query tables in ignite with '_' in name.

[arklet (JIRA)]

arklet created IGNITE-8698:
--

 Summary: Presto can't query tables in ignite with '_' in name.
 Key: IGNITE-8698
 URL: https://issues.apache.org/jira/browse/IGNITE-8698
 Project: Ignite
  Issue Type: Bug
  Components: jdbc
Affects Versions: 2.5, 2.4
 Environment: Presto plugin
Reporter: arklet
 Attachments: presto-ignite.jar

I tried to implement a plugin for presto to connect ignite.  Presto can list 
information_schema and public two schema. I have some tables in public schema 
that with underlines in the name. But,these tables can't be found in the table 
information_schema.columns. And, these tables can't be queried in the presto. 



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

[jira] [Created] (IGNITE-8697) Flink sink throws java.lang.IllegalArgumentException when running in flink cluster mode.

[Ray (JIRA)]

Ray created IGNITE-8697:
---

 Summary: Flink sink throws java.lang.IllegalArgumentException when 
running in flink cluster mode.
 Key: IGNITE-8697
 URL: https://issues.apache.org/jira/browse/IGNITE-8697
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.5, 2.4, 2.3
Reporter: Ray
Assignee: Roman Shtykh


if I submit the Application to the Flink Cluster using Ignite flink sink I get 
this error

 
java.lang.ExceptionInInitializerError
at 
org.apache.ignite.sink.flink.IgniteSink$SinkContext.getStreamer(IgniteSink.java:201)
at 
org.apache.ignite.sink.flink.IgniteSink$SinkContext.access$100(IgniteSink.java:175)
at org.apache.ignite.sink.flink.IgniteSink.invoke(IgniteSink.java:165)
at 
org.apache.flink.streaming.api.functions.sink.SinkFunction.invoke(SinkFunction.java:52)
at 
org.apache.flink.streaming.api.operators.StreamSink.processElement(StreamSink.java:56)
at 
org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.pushToOperator(OperatorChain.java:560)
at 
org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.collect(OperatorChain.java:535)
at 
org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.collect(OperatorChain.java:515)
at 
org.apache.flink.streaming.api.operators.AbstractStreamOperator$CountingOutput.collect(AbstractStreamOperator.java:679)
at 
org.apache.flink.streaming.api.operators.AbstractStreamOperator$CountingOutput.collect(AbstractStreamOperator.java:657)
at 
org.apache.flink.streaming.api.operators.TimestampedCollector.collect(TimestampedCollector.java:51)
at 
org.myorg.quickstart.InstrumentStreamer$Splitter.flatMap(InstrumentStreamer.java:97)
at 
org.myorg.quickstart.InstrumentStreamer$Splitter.flatMap(InstrumentStreamer.java:1)
at 
org.apache.flink.streaming.api.operators.StreamFlatMap.processElement(StreamFlatMap.java:50)
at 
org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.pushToOperator(OperatorChain.java:560)
at 
org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.collect(OperatorChain.java:535)
at 
org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.collect(OperatorChain.java:515)
at 
org.apache.flink.streaming.api.operators.AbstractStreamOperator$CountingOutput.collect(AbstractStreamOperator.java:679)
at 
org.apache.flink.streaming.api.operators.AbstractStreamOperator$CountingOutput.collect(AbstractStreamOperator.java:657)
at 
org.apache.flink.streaming.api.operators.StreamSourceContexts$NonTimestampContext.collect(StreamSourceContexts.java:104)
at 
org.apache.flink.streaming.api.functions.source.SocketTextStreamFunction.run(SocketTextStreamFunction.java:110)
at 
org.apache.flink.streaming.api.operators.StreamSource.run(StreamSource.java:87)
at 
org.apache.flink.streaming.api.operators.StreamSource.run(StreamSource.java:56)
at 
org.apache.flink.streaming.runtime.tasks.SourceStreamTask.run(SourceStreamTask.java:99)
at 
org.apache.flink.streaming.runtime.tasks.StreamTask.invoke(StreamTask.java:306)
at org.apache.flink.runtime.taskmanager.Task.run(Task.java:703)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.IllegalArgumentException: Ouch! Argument is invalid: Cache 
name must not be null or empty.
at 
org.apache.ignite.internal.util.GridArgumentCheck.ensure(GridArgumentCheck.java:109)
at 
org.apache.ignite.internal.processors.cache.GridCacheUtils.validateCacheName(GridCacheUtils.java:1581)
at 
org.apache.ignite.internal.IgniteKernal.dataStreamer(IgniteKernal.java:3284)
at 
org.apache.ignite.sink.flink.IgniteSink$SinkContext$Holder.(IgniteSink.java:183)
... 27 more



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

Re: Upgrading Ignite to JCache 1.1

[Dmitriy Setrakyan]

Thanks, Alex! Sounds like a good plan.

On Mon, Jun 4, 2018 at 5:52 AM, Александр Меньшиков 
wrote:

> Hi,
> Igniters!
>
> I have taken a look at the jcache 1.1 spec and TCK.
> And I can write a brief summary of my plan to solve the task.
>
> I have found 6 problems in current master with TCK 1.1 (104 failed tests).
> Of course, we should run this TCK on CI to be absolutely sure we didn't
> miss something.
>
> So the first step is an adding TCK 1.1 suite to our Team City.
> I have created sub-task [1] for it and prepared the PR [2].
> I need someone with access to merge PR and add suite to Team City.
> It going to be just a clone of the current jcache-tck suite, but with using
> the new profile.
> You can test new profile locally with the following command:
>
> mvn test -P-release,jcache-tck-1.1 -pl :ignite-core -am
>
>
> After that, I will start to add sub-task for every problem we have.
>
> Nikolay, can you please help me with merging [1] and adding to the suite?
>
> [1]JIRA: https://issues.apache.org/jira/browse/IGNITE-8687
> [2]PR: https://github.com/apache/ignite/pull/4114/files
> [3]CI:
> https://ci.ignite.apache.org/viewType.html?buildTypeId=
> IgniteTests24Java8_RunAll_IgniteTests24Java8=pull/4114/head=
> buildTypeStatusDiv
>
> 2018-05-23 14:31 GMT+03:00 Александр Меньшиков :
>
> > Thanks, Slava. You are right.
> >
> > 2018-05-23 14:00 GMT+03:00 Vyacheslav Daradur :
> >
> >> Hi, Alex!
> >>
> >> Please have a look at maven profile named "jcache-tck".
> >>
> >> I believe this is what you are looking for.
> >>
> >> On Wed, May 23, 2018 at 11:50 AM, Александр Меньшиков
> >>  wrote:
> >> > Igniters,
> >> > I think I can do it. As I see we already have JCache TCK tests in TC.
> >> > Can I take somewhere settings/script which we are using?
> >> >
> >> > 2018-05-23 2:58 GMT+03:00 Dmitriy Setrakyan :
> >> >
> >> >> Igniters,
> >> >>
> >> >> It will be great if someone in the community would pick this up. The
> >> amount
> >> >> of changes are minimal and many of them only have to do with
> >> clarifying the
> >> >> documentation. However, removing JSR 107 license confusion in 1.1
> >> would be
> >> >> great for Ignite.
> >> >>
> >> >> D.
> >> >>
> >> >> On Tue, May 22, 2018 at 3:04 PM, Denis Magda 
> >> wrote:
> >> >>
> >> >> > Here is a list of all changes:
> >> >> > https://groups.google.com/forum/#!topic/jsr107/BC1qKqknzKU
> >> >> >
> >> >> > The primary argument for the migration is a license. JCache 1.0 is
> >> >> licensed
> >> >> > by Oracle that causes legal issues for some of the users. Once we
> >> upgrade
> >> >> > to JCache 1.1 the won't longer be a big deal.
> >> >> >
> >> >> > However, once we move to 1.1 we need to be sure that we comply with
> >> the
> >> >> > updated specification.
> >> >> >
> >> >> > --
> >> >> > Denis
> >> >> >
> >> >> > On Tue, May 22, 2018 at 5:20 AM, Dmitry Pavlov <
> >> dpavlov@gmail.com>
> >> >> > wrote:
> >> >> >
> >> >> > > Hi Denis,
> >> >> > >
> >> >> > > What was improved in JCache 1.1?
> >> >> > >
> >> >> > > Would it be useful for product to change supported spec. version?
> >> >> > >
> >> >> > > Sincerely,
> >> >> > > Dmitriy Pavlov
> >> >> > >
> >> >> > > пн, 21 мая 2018 г. в 20:12, Denis Magda :
> >> >> > >
> >> >> > > > Igniters,
> >> >> > > >
> >> >> > > > Eventually, JCache was relicensed to Apache 2.0 and released
> 1.1
> >> >> > version:
> >> >> > > > https://groups.google.com/forum/#!topic/jsr107/BC1qKqknzKU
> >> >> > > >
> >> >> > > > Is there anyone interested in upgrading Ignite to the new
> >> version for
> >> >> > the
> >> >> > > > next release?
> >> >> > > > https://issues.apache.org/jira/browse/IGNITE-8548
> >> >> > > >
> >> >> > > > --
> >> >> > > > Denis
> >> >> > > >
> >> >> > >
> >> >> >
> >> >>
> >>
> >>
> >>
> >> --
> >> Best Regards, Vyacheslav D.
> >>
> >
> >
>

[GitHub] ignite pull request #4127: IGNITE-8696 add cache atomicity to cache list inf...

[macrergate]

GitHub user macrergate opened a pull request:

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

IGNITE-8696 add cache atomicity to cache list info



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

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

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

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

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

This closes #4127


commit aeb6cdea855a074c94314f25c20adf8700c23277
Author: Sergey Kosarev 
Date:   2018-06-05T01:09:08Z

IGNITE-8696 add cache atomicity to cache list info




---

[jira] [Created] (IGNITE-8696) control.sh utility does not show atomicity mode

[Sergey Kosarev (JIRA)]

Sergey Kosarev created IGNITE-8696:
--

 Summary: control.sh utility does not show atomicity mode
 Key: IGNITE-8696
 URL: https://issues.apache.org/jira/browse/IGNITE-8696
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.5
Reporter: Sergey Kosarev
Assignee: Sergey Kosarev
 Fix For: 2.6


In current implementation cache viewer list function:

./control.sh --cache list

does not show atomicity mode for caches. Please add this to the output.



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

[GitHub] ignite pull request #4120: IGNITE-8693 : Fix for SQL JOIN between REPLICATED...

[asfgit]

Github user asfgit closed the pull request at:

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


---

Re: Apache Ignite 2.6 - Packages roadmap

[Denis Magda]

There is already a ticket for point 1:
https://issues.apache.org/jira/browse/IGNITE-8695

--
Denis

On Mon, Jun 4, 2018 at 2:40 PM, Dmitriy Setrakyan 
wrote:

> Here is my list:
>
>1. Remove the requirement to run Ignite scripts as root. This will be a
>huge No in most environment and we should fix it.
>2. Add Ignite "bin" folder to PATH, so all Ignite scripts will be
>executable without specifying the whole path name (not sure if it is
>already done or not)
>
> D.
>
> On Mon, Jun 4, 2018 at 7:43 AM, Petr Ivanov  wrote:
>
> > Igniters!
> >
> >
> > Apache Ignite 2.5 is released and for the first time in it’s history is
> > shipped in both RPM and DEB packages.
> > And, I think, it is time to discuss the future roadmap of Apache Ignite
> in
> > Linux packages initiative.
> >
> > For the first “feature” I would suggest splitting of the packages on
> > smaller parts (at least the same way it was prepare but declined in 2.5)
> —
> > we can continue discussion here.
> > Also it would be great to hear community thoughts about other possible
> > improvements of delivering Apache Ignite in packages.
>

[jira] [Created] (IGNITE-8695) RPM|DEB: Remove requirement to run Ignite stand-along under root

[Denis Magda (JIRA)]

Denis Magda created IGNITE-8695:
---

 Summary: RPM|DEB: Remove requirement to run Ignite stand-along 
under root
 Key: IGNITE-8695
 URL: https://issues.apache.org/jira/browse/IGNITE-8695
 Project: Ignite
  Issue Type: Task
Reporter: Denis Magda
Assignee: Peter Ivanov
 Fix For: 2.6


If Ignite is started as a stand-alone process we require to do that under the 
root user:
https://apacheignite.readme.io/docs/getting-started#section-run-ignite-as-a-stand-alone-process

Noone would do that in prod. We need to remove this requirement.



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

Re: Apache Ignite 2.6 - Packages roadmap

[Dmitriy Setrakyan]

Here is my list:

   1. Remove the requirement to run Ignite scripts as root. This will be a
   huge No in most environment and we should fix it.
   2. Add Ignite "bin" folder to PATH, so all Ignite scripts will be
   executable without specifying the whole path name (not sure if it is
   already done or not)

D.

On Mon, Jun 4, 2018 at 7:43 AM, Petr Ivanov  wrote:

> Igniters!
>
>
> Apache Ignite 2.5 is released and for the first time in it’s history is
> shipped in both RPM and DEB packages.
> And, I think, it is time to discuss the future roadmap of Apache Ignite in
> Linux packages initiative.
>
> For the first “feature” I would suggest splitting of the packages on
> smaller parts (at least the same way it was prepare but declined in 2.5) —
> we can continue discussion here.
> Also it would be great to hear community thoughts about other possible
> improvements of delivering Apache Ignite in packages.

Re: Thin client protocol version release notes.

[Denis Magda]

The change list page is a good offer. As for the versions, it's clear that
the protocol version differs from an Ignite one. However, a next protocol
version officially becomes available with a next Ignite release meaning.
For me, it means, all the new protocol changes need to be documented on a
readme.io page for an upcoming release.

--
Denis

On Mon, Jun 4, 2018 at 3:54 AM, Igor Sapego  wrote:

> Igniters,
>
> Currently, our thin client specification is kept on readme.io [1].
> However, sometimes to introduce new features while keeping
> backward compatibility, we need to increase protocol version.
>
> The issue is: there is currently no easy way for thin client
> developers to find out when thin protocol version has been
> updated and what kind of new features have been introduced.
>
> We may want to make a rule, that a commiter, that merge a
> commit to the master, that introduces new thin client version,
> should send an update email to devlist.
>
> We may also want to have some kind of "Changes list" page on
> readme.io which will track protocol changes from version to
> version.
>
> What are your thoughts on the topic?
>
> [1] - https://apacheignite.readme.io/docs/binary-client-protocol
>
> Best Regards,
> Igor
>

Re: Apache Ignite 2.6 - Packages roadmap

[Denis Magda]

Petr,

I do remember the multi-package approach was suggested as a solution to
trim down the size of the binary that is hosted by ASF. Since now the
binaries are hosted in Bintray, do we still have that issue? If it's fine
to preload and keep big binaries in Bintray then I would suggest us to
postpone the multi-package activities until there is a real demand.

--
Denis

On Mon, Jun 4, 2018 at 7:43 AM, Petr Ivanov  wrote:

> Igniters!
>
>
> Apache Ignite 2.5 is released and for the first time in it’s history is
> shipped in both RPM and DEB packages.
> And, I think, it is time to discuss the future roadmap of Apache Ignite in
> Linux packages initiative.
>
> For the first “feature” I would suggest splitting of the packages on
> smaller parts (at least the same way it was prepare but declined in 2.5) —
> we can continue discussion here.
> Also it would be great to hear community thoughts about other possible
> improvements of delivering Apache Ignite in packages.

Re: Apache Ignite 2.6 - Packages roadmap

[Ilya Kasnacheev]

Hello!

Here's my list of improvements for AI package:
- Make sqlline.sh callable from command line (PATH). E.g. symlink it as
/usr/bin/sqlline-ignite, make sure it works.
- Fix control.sh and visor-cmd, expose them too.
- Allow specifying of JDK implementation and JDK arguments for Apache
Ignite startup. Preferably on per configuration basis.
- Allow adding-removing "modules" to classpath of Ignite - again,
preferably on per configuration basis. E.g. what happens if I want to turn
ON geospatial/
- [OPTIONAL] Ship Apache Ignite with a special config which only listens on
localhost. This is for lazy people who can get into trouble by installing
package without looking without security implications.

With regards to splitting package, I think we could have a few of them
(a-i-core, a-i-doc, a-i-c++, a-i-.net) but I don't think we need to have a
half dozen of those right away. This was mostly realised as an antipattern.

Regards,

-- 
Ilya Kasnacheev

2018-06-04 17:43 GMT+03:00 Petr Ivanov :

> Igniters!
>
>
> Apache Ignite 2.5 is released and for the first time in it’s history is
> shipped in both RPM and DEB packages.
> And, I think, it is time to discuss the future roadmap of Apache Ignite in
> Linux packages initiative.
>
> For the first “feature” I would suggest splitting of the packages on
> smaller parts (at least the same way it was prepare but declined in 2.5) —
> we can continue discussion here.
> Also it would be great to hear community thoughts about other possible
> improvements of delivering Apache Ignite in packages.

Re: Thin client protocol version release notes.

[Pavel Petroshenko]

Hi Igor,

That's a great idea! This would make the client developers' lives much
easier.

Pavel

On Mon, Jun 4, 2018 at 3:54 AM, Igor Sapego  wrote:

> Igniters,
>
> Currently, our thin client specification is kept on readme.io [1].
> However, sometimes to introduce new features while keeping
> backward compatibility, we need to increase protocol version.
>
> The issue is: there is currently no easy way for thin client
> developers to find out when thin protocol version has been
> updated and what kind of new features have been introduced.
>
> We may want to make a rule, that a commiter, that merge a
> commit to the master, that introduces new thin client version,
> should send an update email to devlist.
>
> We may also want to have some kind of "Changes list" page on
> readme.io which will track protocol changes from version to
> version.
>
> What are your thoughts on the topic?
>
> [1] - https://apacheignite.readme.io/docs/binary-client-protocol
>
> Best Regards,
> Igor
>

[GitHub] ignite pull request #4126: reproducer for atomic cache inconsistent state

[dgarus]

GitHub user dgarus opened a pull request:

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

reproducer for atomic cache inconsistent state



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

$ git pull https://github.com/dgarus/ignite inc_atomic

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

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

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

This closes #4126


commit 6d6a1c9ce056fec7f086a29fd0cdfc660583fe0c
Author: Garus Denis 
Date:   2018-06-04T13:57:18Z

reproducer

commit a3e544e929798b5ce4b1bb850385740ea5cef79e
Author: Garus Denis 
Date:   2018-06-04T14:31:17Z

reproducer

commit 76d0e4decfada1173ac41a0768bbeb8f1e6d4780
Author: Garus Denis 
Date:   2018-06-04T15:21:59Z

fix comments




---

[GitHub] ignite pull request #4125: IGNITE-8694 SQL JOIN between PARTITIONED and REPL...

[glukos]

GitHub user glukos opened a pull request:

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

IGNITE-8694 SQL JOIN between PARTITIONED and REPLICATED cache fails

Signed-off-by: Ivan Rakov 

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

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

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

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

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

This closes #4125


commit 78085fdb2f40747840d4a4b72b67de80d10e1afd
Author: Ivan Rakov 
Date:   2018-06-04T15:12:10Z

IGNITE-8694 SQL JOIN between PARTITIONED and REPLICATED cache fails

Signed-off-by: Ivan Rakov 




---

[GitHub] ignite pull request #4123: 1.9.13 stale

[antkr]

Github user antkr closed the pull request at:

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


---

[jira] [Created] (IGNITE-8694) SQL JOIN between PARTITIONED and REPLICATED cache fails

[Ivan Rakov (JIRA)]

Ivan Rakov created IGNITE-8694:
--

 Summary: SQL JOIN between PARTITIONED and REPLICATED cache fails
 Key: IGNITE-8694
 URL: https://issues.apache.org/jira/browse/IGNITE-8694
 Project: Ignite
  Issue Type: Bug
Reporter: Ivan Rakov
Assignee: Ivan Rakov
 Fix For: 2.6


We already have IGNITE-7766 where test fails due to the same problem.
Particular case with PARTITIONED and REPLICATED cache will be fixed under this 
ticket, while rest of the work will be completed under IGNITE-7766.



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

Apache Ignite 2.6 - Packages roadmap

[Petr Ivanov]

Igniters!


Apache Ignite 2.5 is released and for the first time in it’s history is shipped 
in both RPM and DEB packages.
And, I think, it is time to discuss the future roadmap of Apache Ignite in 
Linux packages initiative.

For the first “feature” I would suggest splitting of the packages on smaller 
parts (at least the same way it was prepare but declined in 2.5) — we can 
continue discussion here.
Also it would be great to hear community thoughts about other possible 
improvements of delivering Apache Ignite in packages.

[GitHub] ignite pull request #4124: IGNITE-8667 Splitting of dataset to test and trai...

[dmitrievanthony]

GitHub user dmitrievanthony opened a pull request:

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

IGNITE-8667 Splitting of dataset to test and training sets



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

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

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

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

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

This closes #4124


commit e392b6acafb3fa2752b77fcd942dc85b482b4bec
Author: Anton Dmitriev 
Date:   2018-05-31T14:57:26Z

IGNITE-8666 Add predicates into CacheBasedDatasetBuilder and 
LocalDatasetBuilder.

commit c50a645e3f3a0e277f98e02916eaf4b62731ff52
Author: Anton Dmitriev 
Date:   2018-05-31T15:08:58Z

IGNITE-8666 Add dataset predicate support to examples.

commit efa7e33ced5e9f313f4b9521aef76568f0e9d1bf
Author: Anton Dmitriev 
Date:   2018-05-31T15:09:08Z

IGNITE-8666 Add dataset predicate support to examples.

commit 737738febe0bedd8ceb362f6204b6a0d79679579
Author: Anton Dmitriev 
Date:   2018-05-31T15:26:13Z

IGNITE-8666 Add constructor with default predicate to CacheBased and Local 
Dataset Builders.

commit 28565c356057bc36c09fc17c8daf7aa3e2827eb5
Author: Anton Dmitriev 
Date:   2018-05-31T16:18:17Z

IGNITE-8666 Use default ScanQuery filter instead of custom cursor wrapper.

commit a7932692789b3ef59bfb713839bffb9b73aa0597
Author: dmitrievanthony 
Date:   2018-05-31T20:30:36Z

IGNITE-8666 Use default transformer instead of UpstreamCursorAdapter.

commit f77f13e9c7698be7bd0176d9f531875c572cd4d3
Author: dmitrievanthony 
Date:   2018-05-31T20:49:32Z

IGNITE-8666 Use default constructs of CacheBased and Local Dataset Builders.

commit e6eb7473645ed0bf248f7c4badd87ac4c20e34d4
Author: dmitrievanthony 
Date:   2018-05-31T20:52:58Z

IGNITE-8666 Fix code style.

commit b9e8a105a61912f9e7ceb6064d5528ba12f017b1
Author: Anton Dmitriev 
Date:   2018-06-01T08:06:49Z

IGNITE-8666 Add KNNRegressionTrainer to trainers hierarchy.

commit dd09c0a809c81c34a6ae8ac95278080565965b47
Author: Anton Dmitriev 
Date:   2018-06-01T08:23:34Z

IGNITE-8666 Fix javadoc in ComputeUtils class.

commit a004bf20342fef500045f830e821954616a2164b
Author: Anton Dmitriev 
Date:   2018-06-01T09:10:04Z

IGNITE-8666 Add concurrent modification checker to dataset builders.

commit 88b2483cf3a601935140f43edafe2e13b03506eb
Author: Anton Dmitriev 
Date:   2018-06-01T09:32:54Z

Merge branch 'ignite-8666' into ignite-8667

commit c2291f3e01b98c3f22a57652ecab500e67e29aef
Author: Anton Dmitriev 
Date:   2018-06-01T11:23:29Z

IGNITE-8666 Rename pred -> filter.

commit 05b527dd346cdedf3e2f823a6a5761d240ff381a
Author: Anton Dmitriev 
Date:   2018-06-01T11:24:49Z

Merge branch 'ignite-8666' into ignite-8667

commit 7bab5832d5a94f0f9f46f17286161b2738538179
Author: Anton Dmitriev 
Date:   2018-06-01T13:37:16Z

IGNITE-8667 First version of TrainTest dataset splitter.

commit 206a9cbaf132ea515b3e8aa7b3832df3332d2c71
Author: Anton Dmitriev 
Date:   2018-06-04T14:27:49Z

IGNITE-8667 Add unified mapper for train test splitter and tests.

commit fe6a7f05eb0926f8bfc07885c6f6ed3ab335956f
Author: Anton Dmitriev 
Date:   2018-06-04T14:34:45Z

Merge remote-tracking branch 'origin/master' into ignite-8667

# Conflicts:
#   
modules/ml/src/main/java/org/apache/ignite/ml/dataset/impl/cache/util/ComputeUtils.java




---

Re: [RESULT] [VOTE] Apache Ignite 2.5.0 Release (RC1)

[Petr Ivanov]

Dmitriy, thanks!
Fixed that typo.




> On 4 Jun 2018, at 17:09, Dmitriy Setrakyan  wrote:
> 
> Peter, can you please fix the text below to point to "log", not "lib"?
> 
> log directory is at /var/lib/apache-ignite (mapped to
>> /var/lib/apache-ignite/log)
> 
> 
> On Mon, Jun 4, 2018 at 7:07 AM, Petr Ivanov  wrote:
> 
>> Log directory is directly at /var/log/apache-ignite and mapped via symlink
>> to /var/lib/apache-ignite/log because /var/lib/apache-ignite/ (main work
>> dir which in its turn is mapped via symlink to
>> /usr/share/apache—ignite/work) is the place where running node of Apache
>> Ignite will write it’s logs.
>> 
>> 
>> 
>>> On 4 Jun 2018, at 16:56, Dmitriy Setrakyan 
>> wrote:
>>> 
>>> Thanks, Petr!
>>> 
>>> I think the log directory should be at /var/log, not /var/lib, right?
>>> 
>>> D.
>>> 
>>> On Mon, Jun 4, 2018 at 5:04 AM, Petr Ivanov  wrote:
>>> 
 Dmitriy,
 
 
 I’ve added requested information (see [1]).
 Can you check that this information is enough, please?
 
 
 [1] https://issues.apache.org/jira/browse/IGNITE-8671?focusedCom
 mentId=16500123=com.atlassian.jira.plugin.system.
 issuetabpanels:comment-tabpanel#comment-16500123
 
 
 
 
> On 3 Jun 2018, at 10:24, Dmitriy Setrakyan 
 wrote:
> 
> Peter,
> 
> I think what is really missing is the installation structure, i.e.
>> where
 is
> the bin, config, lib, work folders. Is IGNITE_HOME pointing somewhere
>> as
 a
> result of the installation? I think, if you explain it to users, there
 will
> be more understanding from the user stand point.
> 
> Can you please add that?
> 
> D.
> 
> On Sat, Jun 2, 2018 at 12:39 PM, Petr Ivanov 
 wrote:
> 
>> Dmitriy,
>> 
>> 
>> I've added warning snippet in the bottom of the Alternative
>> Installation
>> Options section with reference on how to start Apache Ignite installed
 from
>> RPM or DEB packages as standalone Java application (see [1]).
>> Hope it will be enough.
>> 
>> 
>> [1] https://issues.apache.org/jira/browse/IGNITE-8671?
>> focusedCommentId=16499157=com.atlassian.jira.
>> plugin.system.issuetabpanels:comment-tabpanel#comment-16499157
>> 
>> 
>> 
>> 
>>> On 2 Jun 2018, at 21:57, Dmitriy Setrakyan 
>> wrote:
>>> 
>>> Peter,
>>> 
>>> We cannot have a distribution that works sometimes.
>>> 
>>> I think you should read the ticket carefully. I don't beleive we need
 to
>>> make any changes to the release, it is a matter of fixing the
>>> documentation.
>>> 
>>> Can you confirm this?
>>> 
>>> D.
>>> 
>>> 
>>> On Jun 2, 2018 11:44, "Peter Ivanov"  wrote:
>>> 
>>> Dmitriy,
>>> 
>>> 
>>> You suggest removing fully working under corresponding Linux
 distributive
>>> RPM and DEB packages entirely from apache.org/dist/ignite only
>> because
>> they
>>> do not work in highly unlikely scenario (Windows 10 WSL) as service?
>>> 
>>> I will certainly add reference about running Apache Ignite from the
>>> packages as standalone Java application (with corresponding
>> permissions
>>> note) but I’d like to hear community opinion on the whole matter -
>>> everything that was done, was done with review and approve from lots
>> of
>>> Apache Ignite commiters and PMCs, including PMC chair.
>>> 
>>> 
>>> On Sat, 2 Jun 2018 at 16:12, Dmitriy Setrakyan <
>> dsetrak...@apache.org>
>>> wrote:
>>> 
>>> 
 Peter,
 
 I have reopened this ticket:
 https://issues.apache.org/jira/browse/IGNITE-8671
 
 I changed the priority to blocker. At this point I suggest the
>> following:
 - we either remove the DEB and RPM packages from the website and
 readme
 - or we fix this issue ASAP as stated in the ticket.
 
 I will leave it up to you to decide.
 
 D.
 
 On Thu, May 31, 2018 at 10:31 PM, Peter Ivanov >> 
 wrote:
 
> Dmitriy,
> 
> 
> SystemD supports running multiple instances of one service – this
>> is
>> done
> through @-like syntax: 'sudo systemctl start apache-ignite@
>>  file name>', so that with every unique command string there will be
> started
> / stopped unique instance of Apache Ignite. And all instances can
>> be
> restarted / stopped / enabled on boot / etc. simultaneously through
>> 'sudo
> systemctl  apache-ignite@*'.
> 
> Still, I can add a note about possibility of starting Apache Ignite
> manually through ignite.sh with a reference to corresponding
>>> documentation
> section, information where to look for the root of Apache Ignite
> installation and how to correctly start Apache Ignite 

[GitHub] ignite pull request #4123: 1.9.13 stale

[antkr]

GitHub user antkr opened a pull request:

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

1.9.13 stale

CI partial tests

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

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

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

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

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

This closes #4123


commit 024a01d6bf91b4f301c4aee7f4a747e810a9a30b
Author: nikolay_tikhonov 
Date:   2017-07-05T15:58:00Z

Merged 1.7.12 into 1.8.9

Signed-off-by: nikolay_tikhonov 

commit 3536a58982e4c264bb72b2ccc1953049d2b5c67f
Author: Alexey Kukushkin 
Date:   2017-07-05T16:36:41Z

IGNITE-4901 Decrease logging level for DataStremer retry

commit 6d3a3ff2d99697882232070e715928336a9180cd
Author: Alexey Kukushkin 
Date:   2017-07-05T17:05:02Z

Fixed merge conflicts

commit aedc6aa8b17a39a6460c4b7f69255cd07d635bfb
Author: nikolay_tikhonov 
Date:   2017-07-05T17:42:15Z

Merge branch 'ignite-1.7.12' into ignite-1.9.4

Signed-off-by: nikolay_tikhonov 

commit acfc400b22738fa46397d392f88d49614e687969
Author: nikolay_tikhonov 
Date:   2017-07-05T17:42:48Z

Merge branch 'ignite-1.7.12' into ignite-1.9.4

Signed-off-by: nikolay_tikhonov 

commit 8dea19ba41bb9eda16f47933b2c46a081116d5f7
Author: Andrey V. Mashenkov 
Date:   2017-07-06T09:02:07Z

Minor fix.

commit f208f434f944196d531a1b51066dfe8d6394d739
Author: Andrey V. Mashenkov 
Date:   2017-07-06T12:17:50Z

Test fixed "IGNITE-5390: Bug in 
IgniteCacheTxStoreSessionWriteBehindCoalescingTest."

commit 355a5283559c885f57c4557bba2c6d9170a9b5fc
Author: mcherkasov 
Date:   2017-06-30T17:23:55Z

IGNITE-5554 ServiceProcessor may process failed reassignments in timeout 
thread

commit 92aa7c6e3c0d9b5cc68002433861b175d54f9421
Author: agura 
Date:   2017-07-04T13:56:40Z

ignite-5685 JDBC prepared statement shouldn't clear parameters after 
execution

commit 9165a0f93b5173b543cc6b4fad5fde37bd215f91
Author: Slava Koptilin 
Date:   2017-07-07T12:35:33Z

ignite-5562: assert statements were changed to the 'if' blocks

commit d9fc20a61d5ac0a6e63b26faa7fa0af753b2fa06
Author: Dmitriy Govorukhin 
Date:   2017-04-07T11:28:22Z

IGNITE-4889 - Changed Hibernate integration to use custom keys

(cherry picked from commit 6b62a20)

commit 16067300c9124b79bfee42139eb881ae585c0914
Author: Dmitriy Govorukhin 
Date:   2017-04-07T11:28:22Z

IGNITE-4889 - Changed Hibernate integration to use custom keys

(cherry picked from commit 6b62a20)

commit c82e25d67a2f6825a27d26933199a436f6eabba2
Author: Dmitriy Govorukhin 
Date:   2017-04-07T11:28:22Z

IGNITE-4889 - Changed Hibernate integration to use custom keys

(cherry picked from commit 6b62a20)

commit a352951d91edde9c0029a8bf435d61b4a7cd8c11
Author: Andrey V. Mashenkov 
Date:   2017-07-04T17:24:52Z

IGNITE-4831: Add an option to disable MBeans.

commit e4d141e97ab4ec34b5fe6a7bc599413223944438
Author: dkarachentsev 
Date:   2017-07-14T11:40:02Z

IGNITE-5103 - Server drops client node from cluster when no heartbeat 
messages received in interval heartBeatsFrequency * maxMissedClientHeartBeats.

commit 45573945066113fd29548699f23c2bc9f22cef36
Author: Tikhonov Nikolay 
Date:   2017-06-21T14:55:05Z

ignite-5489 Fixed possible connection leaks when loadPreviousValue set to 
true

commit 37535634ef3325aaf9923fd17d24038dfd5cee38
Author: agura 
Date:   2017-07-11T13:24:54Z

ignite-5722 Cache entries stay in onheap after scan query execution for 
OFFHEAP_TIRED cache with expiry policy

commit c3e2eebeccbdc4bb3a7a0a70d09a8a7b63399c2c
Author: Evgenii Zhuravlev 
Date:   2017-07-18T15:50:48Z

IGNITE 5776 Add option to turn on filter reachable addresses in 
TcpCommunicationSpi

commit 97d3f42c1c95a6aafce1d0c300ccfe6708398c17
Author: shtykh_roman 
Date:   2016-09-07T05:35:31Z

IGNITE-3809: Fix for ArrayIndexOutOfBoundsException in GridUnsafeLru.

(cherry picked from commit 31b9bb8)

commit c2062d52a227dda5afee560d80c3bb4dd2ce09eb
Author: dkarachentsev 
Date:   2017-07-19T05:41:46Z

Remove empty test_utils.cpp

commit 45cbba4853bab1ba4ffe2ea0d3add99a9d454aab
Author: dkarachentsev 
Date:   2017-07-19T07:44:04Z

IGNITE-5768 - Retry resolving class name from marshaller cache and 
.classname file.

commit f24969f7e908645444df622642967a5f7fd3db23
Author: Evgenii Zhuravlev 
Date:   2017-07-19T16:30:07Z

IGNITE 5775 JobsProcessor fix bug with delay in compute

commit e5aab82f5629c2705e9bc82a7676f63c7c77062a
Author: dkarachentsev 
Date:   2017-07-20T07:37:08Z

Merge branch 'ignite-1.7.13' into ignite-1.8.9

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/jdbc2/JdbcPreparedStatement.java
#   

Re: [RESULT] [VOTE] Apache Ignite 2.5.0 Release (RC1)

[Dmitriy Setrakyan]

Peter, can you please fix the text below to point to "log", not "lib"?

log directory is at /var/lib/apache-ignite (mapped to
> /var/lib/apache-ignite/log)


On Mon, Jun 4, 2018 at 7:07 AM, Petr Ivanov  wrote:

> Log directory is directly at /var/log/apache-ignite and mapped via symlink
> to /var/lib/apache-ignite/log because /var/lib/apache-ignite/ (main work
> dir which in its turn is mapped via symlink to
> /usr/share/apache—ignite/work) is the place where running node of Apache
> Ignite will write it’s logs.
>
>
>
> > On 4 Jun 2018, at 16:56, Dmitriy Setrakyan 
> wrote:
> >
> > Thanks, Petr!
> >
> > I think the log directory should be at /var/log, not /var/lib, right?
> >
> > D.
> >
> > On Mon, Jun 4, 2018 at 5:04 AM, Petr Ivanov  wrote:
> >
> >> Dmitriy,
> >>
> >>
> >> I’ve added requested information (see [1]).
> >> Can you check that this information is enough, please?
> >>
> >>
> >> [1] https://issues.apache.org/jira/browse/IGNITE-8671?focusedCom
> >> mentId=16500123=com.atlassian.jira.plugin.system.
> >> issuetabpanels:comment-tabpanel#comment-16500123
> >>
> >>
> >>
> >>
> >>> On 3 Jun 2018, at 10:24, Dmitriy Setrakyan 
> >> wrote:
> >>>
> >>> Peter,
> >>>
> >>> I think what is really missing is the installation structure, i.e.
> where
> >> is
> >>> the bin, config, lib, work folders. Is IGNITE_HOME pointing somewhere
> as
> >> a
> >>> result of the installation? I think, if you explain it to users, there
> >> will
> >>> be more understanding from the user stand point.
> >>>
> >>> Can you please add that?
> >>>
> >>> D.
> >>>
> >>> On Sat, Jun 2, 2018 at 12:39 PM, Petr Ivanov 
> >> wrote:
> >>>
>  Dmitriy,
> 
> 
>  I've added warning snippet in the bottom of the Alternative
> Installation
>  Options section with reference on how to start Apache Ignite installed
> >> from
>  RPM or DEB packages as standalone Java application (see [1]).
>  Hope it will be enough.
> 
> 
>  [1] https://issues.apache.org/jira/browse/IGNITE-8671?
>  focusedCommentId=16499157=com.atlassian.jira.
>  plugin.system.issuetabpanels:comment-tabpanel#comment-16499157
> 
> 
> 
> 
> > On 2 Jun 2018, at 21:57, Dmitriy Setrakyan 
>  wrote:
> >
> > Peter,
> >
> > We cannot have a distribution that works sometimes.
> >
> > I think you should read the ticket carefully. I don't beleive we need
> >> to
> > make any changes to the release, it is a matter of fixing the
> > documentation.
> >
> > Can you confirm this?
> >
> > D.
> >
> >
> > On Jun 2, 2018 11:44, "Peter Ivanov"  wrote:
> >
> > Dmitriy,
> >
> >
> > You suggest removing fully working under corresponding Linux
> >> distributive
> > RPM and DEB packages entirely from apache.org/dist/ignite only
> because
>  they
> > do not work in highly unlikely scenario (Windows 10 WSL) as service?
> >
> > I will certainly add reference about running Apache Ignite from the
> > packages as standalone Java application (with corresponding
> permissions
> > note) but I’d like to hear community opinion on the whole matter -
> > everything that was done, was done with review and approve from lots
> of
> > Apache Ignite commiters and PMCs, including PMC chair.
> >
> >
> > On Sat, 2 Jun 2018 at 16:12, Dmitriy Setrakyan <
> dsetrak...@apache.org>
> > wrote:
> >
> >
> >> Peter,
> >>
> >> I have reopened this ticket:
> >> https://issues.apache.org/jira/browse/IGNITE-8671
> >>
> >> I changed the priority to blocker. At this point I suggest the
>  following:
> >> - we either remove the DEB and RPM packages from the website and
> >> readme
> >> - or we fix this issue ASAP as stated in the ticket.
> >>
> >> I will leave it up to you to decide.
> >>
> >> D.
> >>
> >> On Thu, May 31, 2018 at 10:31 PM, Peter Ivanov  >
> >> wrote:
> >>
> >>> Dmitriy,
> >>>
> >>>
> >>> SystemD supports running multiple instances of one service – this
> is
>  done
> >>> through @-like syntax: 'sudo systemctl start apache-ignite@
>   >>> file name>', so that with every unique command string there will be
> >>> started
> >>> / stopped unique instance of Apache Ignite. And all instances can
> be
> >>> restarted / stopped / enabled on boot / etc. simultaneously through
>  'sudo
> >>> systemctl  apache-ignite@*'.
> >>>
> >>> Still, I can add a note about possibility of starting Apache Ignite
> >>> manually through ignite.sh with a reference to corresponding
> > documentation
> >>> section, information where to look for the root of Apache Ignite
> >>> installation and how to correctly start Apache Ignite in terms of
> >>> permissions.
> >>>
> >>> File the documentation updates ticket?
> >>>
> >>>
> >>> On Fri, 1 Jun 2018 at 01:10, Dmitriy Setrakyan <
> >> 

[GitHub] ignite pull request #4122: GG-13862

[ilantukh]

GitHub user ilantukh opened a pull request:

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

GG-13862



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

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

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

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

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

This closes #4122


commit 1cea80d29f4f1c61ed56ad1261b74ed42611bf64
Author: Ilya Lantukh 
Date:   2018-04-06T10:49:10Z

IGNITE-8018 Optimized GridCacheMapEntry initialValue() - Fixes #3686.

Signed-off-by: Alexey Goncharuk 

commit 37fc72542eb6baa8be8b41aecd08a194102d13c1
Author: Алексей Стельмак 
Date:   2018-04-06T15:28:22Z

IGNITE-8049 Limit the number of operation cycles in B+Tree - Fixes #3769.

Signed-off-by: dpavlov 

(cherry picked from commit e491f10)

commit 76e293654e34c927d6c9efc85a12e736b58a21f2
Author: Eduard Shangareev 
Date:   2018-04-06T16:22:07Z

IGNITE-8114 Add fail recovery mechanism to tracking pages - Fixes #3734.

Signed-off-by: dpavlov 

(cherry picked from commit 0829397)

commit 49f11db727febc83297c7f0f5de9e6f98f0197fa
Author: Alexey Kuznetsov 
Date:   2018-04-09T02:25:50Z

IGNITE-8159 control.sh: Fixed NPE on adding nodes on empty baseline and not 
active cluster.

(cherry picked from commit 834869c)

commit 9ad7be2f51b6dcdcdf43fedb298cd4e240f0adab
Author: Ilya Borisov 
Date:   2018-04-09T13:59:32Z

IGNITE-8155 Web Console: Fixed number pattern warning in browser console.

(cherry picked from commit 5d8f570)

commit 4aa56751906e5db7aad025a7193933fa929aae26
Author: Vasiliy Sisko 
Date:   2018-04-09T15:13:21Z

IGNITE-7940 Visor CMD: Added "cache -slp" and "cache -rlp" commands to show 
and reset lost partitions for specified cache.

(cherry picked from commit abfa0f5)

commit cc04c5c70af1bdbba834f73330e73277b60e23fc
Author: Eduard Shangareev 
Date:   2018-04-09T16:15:50Z

IGNITE-8114 Additional fix for Add fail recovery mechanism to tracking pages

(cherry picked from commit 961fc35)

commit c70d85aa36c702ea0f29bd8668e9bf0790f9ba11
Author: Vasiliy Sisko 
Date:   2018-04-10T08:42:24Z

IGNITE-8126 Web Console: Fixed code generation for cache load.

(cherry picked from commit a0a187b)

commit 8d3755b9c58eef12c5fc9cabfc0b1c05f6db716e
Author: Semyon Boikov 
Date:   2018-04-10T08:37:39Z

IGNITE-7222 Added ZooKeeper discovery SPI

commit b096a463c338565a7661f8a853a257518d872997
Author: Stanislav Lukyanov 
Date:   2018-04-09T11:33:13Z

IGNITE-7904: Changed IgniteUtils::cast not to trim exception chains. This 
closes #3683.

commit 82a4c024fe06ef8c8deeaf762f0cc20a8e481252
Author: Roman Guseinov 
Date:   2018-04-09T11:45:44Z

IGNITE-7944: Disconnected client node tries to send JOB_CANCEL message. 
Applied fix:
- Skip sending message if client disconnected;
- Throw IgniteCheckedException if a client node is disconnected and 
communication client is null.
This closes #3737.

commit c1745de37891026e0a719f0c1d1afe768dfccbf3
Author: Vasiliy Sisko 
Date:   2018-04-10T10:48:52Z

IGNITE-7927 Web Console: Fixed demo for non-collocated joins.

(cherry picked from commit 647620b)

commit b28287d1861fd841a18d0eef95eff309d21a55ef
Author: Alexey Goncharuk 
Date:   2018-04-10T13:22:28Z

IGNITE-8025 Future must fail if assertion error has been thrown in the 
worker thread

commit a832f2b2e5788c45114c3cb5529d7cf53d08f9a6
Author: Andrey Kuznetsov 
Date:   2018-04-10T14:30:12Z

ignite-7772 System workers critical failures handling

Signed-off-by: Andrey Gura 

commit 912433ba9aa113508d05930691b251eccd8f5870
Author: Aleksey Plekhanov 
Date:   2018-04-10T15:54:03Z

IGNITE-8069 IgniteOutOfMemoryException should be handled accordingly to 
provided failure handler

Signed-off-by: Andrey Gura 

commit 99feab6ace66d011b677fd4d57b44fc54da8fd4f
Author: Alexey Goncharuk 
Date:   2018-04-10T17:33:47Z

IGNITE-6430 Complete failing test early

commit 526fb0ee612ef71fde58a1274db35e8205304a63
Author: Dmitriy Sorokin 
Date:   2018-04-10T19:20:41Z

IGNITE-8101 Ability to terminate system workers by JMX for test purposes.

Signed-off-by: Andrey Gura 

commit b4cb2f0df944534743a9d73811e047eda572258c
Author: mcherkasov 
Date:   2018-04-11T00:27:20Z

IGNITE-8153 Nodes fail to connect each other when SSL is enabled - Fixes 
#3773.

Signed-off-by: Valentin Kulichenko 

commit b4cc9f2d45d78c360abe224165e707c23533469e
Author: Pavel Kovalenko 
Date:   2018-04-11T08:23:46Z

IGNITE-7871 Implemented additional synchronization phase for correct 
partition counters update

commit 9abfee69aa153888456f9e8574ece1f2d0cbe4d9
Author: dmitrievanthony 
Date:   2018-04-10T09:46:43Z

IGNITE-8059: Integrate decision tree 

Re: [RESULT] [VOTE] Apache Ignite 2.5.0 Release (RC1)

[Petr Ivanov]

Log directory is directly at /var/log/apache-ignite and mapped via symlink to 
/var/lib/apache-ignite/log because /var/lib/apache-ignite/ (main work dir which 
in its turn is mapped via symlink to /usr/share/apache—ignite/work) is the 
place where running node of Apache Ignite will write it’s logs.



> On 4 Jun 2018, at 16:56, Dmitriy Setrakyan  wrote:
> 
> Thanks, Petr!
> 
> I think the log directory should be at /var/log, not /var/lib, right?
> 
> D.
> 
> On Mon, Jun 4, 2018 at 5:04 AM, Petr Ivanov  wrote:
> 
>> Dmitriy,
>> 
>> 
>> I’ve added requested information (see [1]).
>> Can you check that this information is enough, please?
>> 
>> 
>> [1] https://issues.apache.org/jira/browse/IGNITE-8671?focusedCom
>> mentId=16500123=com.atlassian.jira.plugin.system.
>> issuetabpanels:comment-tabpanel#comment-16500123
>> 
>> 
>> 
>> 
>>> On 3 Jun 2018, at 10:24, Dmitriy Setrakyan 
>> wrote:
>>> 
>>> Peter,
>>> 
>>> I think what is really missing is the installation structure, i.e. where
>> is
>>> the bin, config, lib, work folders. Is IGNITE_HOME pointing somewhere as
>> a
>>> result of the installation? I think, if you explain it to users, there
>> will
>>> be more understanding from the user stand point.
>>> 
>>> Can you please add that?
>>> 
>>> D.
>>> 
>>> On Sat, Jun 2, 2018 at 12:39 PM, Petr Ivanov 
>> wrote:
>>> 
 Dmitriy,
 
 
 I've added warning snippet in the bottom of the Alternative Installation
 Options section with reference on how to start Apache Ignite installed
>> from
 RPM or DEB packages as standalone Java application (see [1]).
 Hope it will be enough.
 
 
 [1] https://issues.apache.org/jira/browse/IGNITE-8671?
 focusedCommentId=16499157=com.atlassian.jira.
 plugin.system.issuetabpanels:comment-tabpanel#comment-16499157
 
 
 
 
> On 2 Jun 2018, at 21:57, Dmitriy Setrakyan 
 wrote:
> 
> Peter,
> 
> We cannot have a distribution that works sometimes.
> 
> I think you should read the ticket carefully. I don't beleive we need
>> to
> make any changes to the release, it is a matter of fixing the
> documentation.
> 
> Can you confirm this?
> 
> D.
> 
> 
> On Jun 2, 2018 11:44, "Peter Ivanov"  wrote:
> 
> Dmitriy,
> 
> 
> You suggest removing fully working under corresponding Linux
>> distributive
> RPM and DEB packages entirely from apache.org/dist/ignite only because
 they
> do not work in highly unlikely scenario (Windows 10 WSL) as service?
> 
> I will certainly add reference about running Apache Ignite from the
> packages as standalone Java application (with corresponding permissions
> note) but I’d like to hear community opinion on the whole matter -
> everything that was done, was done with review and approve from lots of
> Apache Ignite commiters and PMCs, including PMC chair.
> 
> 
> On Sat, 2 Jun 2018 at 16:12, Dmitriy Setrakyan 
> wrote:
> 
> 
>> Peter,
>> 
>> I have reopened this ticket:
>> https://issues.apache.org/jira/browse/IGNITE-8671
>> 
>> I changed the priority to blocker. At this point I suggest the
 following:
>> - we either remove the DEB and RPM packages from the website and
>> readme
>> - or we fix this issue ASAP as stated in the ticket.
>> 
>> I will leave it up to you to decide.
>> 
>> D.
>> 
>> On Thu, May 31, 2018 at 10:31 PM, Peter Ivanov 
>> wrote:
>> 
>>> Dmitriy,
>>> 
>>> 
>>> SystemD supports running multiple instances of one service – this is
 done
>>> through @-like syntax: 'sudo systemctl start apache-ignite@
 >> file name>', so that with every unique command string there will be
>>> started
>>> / stopped unique instance of Apache Ignite. And all instances can be
>>> restarted / stopped / enabled on boot / etc. simultaneously through
 'sudo
>>> systemctl  apache-ignite@*'.
>>> 
>>> Still, I can add a note about possibility of starting Apache Ignite
>>> manually through ignite.sh with a reference to corresponding
> documentation
>>> section, information where to look for the root of Apache Ignite
>>> installation and how to correctly start Apache Ignite in terms of
>>> permissions.
>>> 
>>> File the documentation updates ticket?
>>> 
>>> 
>>> On Fri, 1 Jun 2018 at 01:10, Dmitriy Setrakyan <
>> dsetrak...@apache.org>
>>> wrote:
>>> 
 Petr,
 
 Most of the users will download and install Ignite so they can
>> develop
>>> with
 it. This means that they will be starting more than one node, which
>> is
 impossible if Ignite is a service. We should provide instructions to
 do
 both.
 
 D.
 
 On Thu, May 31, 2018 at 2:47 PM, Peter Ivanov 
>>> wrote:
 
> Dmitriy,
> 
> 

Re: [RESULT] [VOTE] Apache Ignite 2.5.0 Release (RC1)

[Dmitriy Setrakyan]

Thanks, Petr!

I think the log directory should be at /var/log, not /var/lib, right?

D.

On Mon, Jun 4, 2018 at 5:04 AM, Petr Ivanov  wrote:

> Dmitriy,
>
>
> I’ve added requested information (see [1]).
> Can you check that this information is enough, please?
>
>
> [1] https://issues.apache.org/jira/browse/IGNITE-8671?focusedCom
> mentId=16500123=com.atlassian.jira.plugin.system.
> issuetabpanels:comment-tabpanel#comment-16500123
>
>
>
>
> > On 3 Jun 2018, at 10:24, Dmitriy Setrakyan 
> wrote:
> >
> > Peter,
> >
> > I think what is really missing is the installation structure, i.e. where
> is
> > the bin, config, lib, work folders. Is IGNITE_HOME pointing somewhere as
> a
> > result of the installation? I think, if you explain it to users, there
> will
> > be more understanding from the user stand point.
> >
> > Can you please add that?
> >
> > D.
> >
> > On Sat, Jun 2, 2018 at 12:39 PM, Petr Ivanov 
> wrote:
> >
> >> Dmitriy,
> >>
> >>
> >> I've added warning snippet in the bottom of the Alternative Installation
> >> Options section with reference on how to start Apache Ignite installed
> from
> >> RPM or DEB packages as standalone Java application (see [1]).
> >> Hope it will be enough.
> >>
> >>
> >> [1] https://issues.apache.org/jira/browse/IGNITE-8671?
> >> focusedCommentId=16499157=com.atlassian.jira.
> >> plugin.system.issuetabpanels:comment-tabpanel#comment-16499157
> >>
> >>
> >>
> >>
> >>> On 2 Jun 2018, at 21:57, Dmitriy Setrakyan 
> >> wrote:
> >>>
> >>> Peter,
> >>>
> >>> We cannot have a distribution that works sometimes.
> >>>
> >>> I think you should read the ticket carefully. I don't beleive we need
> to
> >>> make any changes to the release, it is a matter of fixing the
> >>> documentation.
> >>>
> >>> Can you confirm this?
> >>>
> >>> D.
> >>>
> >>>
> >>> On Jun 2, 2018 11:44, "Peter Ivanov"  wrote:
> >>>
> >>> Dmitriy,
> >>>
> >>>
> >>> You suggest removing fully working under corresponding Linux
> distributive
> >>> RPM and DEB packages entirely from apache.org/dist/ignite only because
> >> they
> >>> do not work in highly unlikely scenario (Windows 10 WSL) as service?
> >>>
> >>> I will certainly add reference about running Apache Ignite from the
> >>> packages as standalone Java application (with corresponding permissions
> >>> note) but I’d like to hear community opinion on the whole matter -
> >>> everything that was done, was done with review and approve from lots of
> >>> Apache Ignite commiters and PMCs, including PMC chair.
> >>>
> >>>
> >>> On Sat, 2 Jun 2018 at 16:12, Dmitriy Setrakyan 
> >>> wrote:
> >>>
> >>>
>  Peter,
> 
>  I have reopened this ticket:
>  https://issues.apache.org/jira/browse/IGNITE-8671
> 
>  I changed the priority to blocker. At this point I suggest the
> >> following:
>  - we either remove the DEB and RPM packages from the website and
> readme
>  - or we fix this issue ASAP as stated in the ticket.
> 
>  I will leave it up to you to decide.
> 
>  D.
> 
>  On Thu, May 31, 2018 at 10:31 PM, Peter Ivanov 
>  wrote:
> 
> > Dmitriy,
> >
> >
> > SystemD supports running multiple instances of one service – this is
> >> done
> > through @-like syntax: 'sudo systemctl start apache-ignite@
> >>  > file name>', so that with every unique command string there will be
> > started
> > / stopped unique instance of Apache Ignite. And all instances can be
> > restarted / stopped / enabled on boot / etc. simultaneously through
> >> 'sudo
> > systemctl  apache-ignite@*'.
> >
> > Still, I can add a note about possibility of starting Apache Ignite
> > manually through ignite.sh with a reference to corresponding
> >>> documentation
> > section, information where to look for the root of Apache Ignite
> > installation and how to correctly start Apache Ignite in terms of
> > permissions.
> >
> > File the documentation updates ticket?
> >
> >
> > On Fri, 1 Jun 2018 at 01:10, Dmitriy Setrakyan <
> dsetrak...@apache.org>
> > wrote:
> >
> >> Petr,
> >>
> >> Most of the users will download and install Ignite so they can
> develop
> > with
> >> it. This means that they will be starting more than one node, which
> is
> >> impossible if Ignite is a service. We should provide instructions to
> >> do
> >> both.
> >>
> >> D.
> >>
> >> On Thu, May 31, 2018 at 2:47 PM, Peter Ivanov 
> > wrote:
> >>
> >>> Dmitriy,
> >>>
> >>>
> >>> Current packages design (both RPM and DEB) was reviewed and
> approved
> > by
> >>> community. I do not quite remember why service-based startup was
> > chosen
> >> but
> >>> it seems rather logical and Unix-compliant – under Linux almost
> every
> >>> service software is packed this way, which gives some benefits like
> >> service
> >>> autostart on reboot, centralized running nodes management (through
> 

[GitHub] ignite pull request #4116: IGNITE-8690 Added missed package-infos.

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] ignite pull request #4118: IGNITE-8691 Removed jar-plugin from ignite-zookee...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] ignite pull request #4121: IGNITE-8562: Squashed partial commits.

[andrey-kuznetsov]

GitHub user andrey-kuznetsov opened a pull request:

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

IGNITE-8562: Squashed partial commits.



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

$ git pull https://github.com/andrey-kuznetsov/ignite ignite-8562

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

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

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

This closes #4121


commit cf466344de49c24f249e34e718ba4188beb606b6
Author: Andrey Kuznetsov 
Date:   2018-06-04T13:10:18Z

IGNITE-8562: Squashed partial commits.




---

[GitHub] ignite pull request #4120: IGNITE-8693 : Fix for SQL JOIN between REPLICATED...

[ilantukh]

GitHub user ilantukh opened a pull request:

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

IGNITE-8693 : Fix for SQL JOIN between REPLICATED and PARTITIONED caches

…hes.

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

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

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

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

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

This closes #4120


commit 9b4ae6520c9c701382bc5468141c4b709658f682
Author: Ilya Lantukh 
Date:   2018-06-01T14:01:43Z

ignite-8693 : Fix for SQL JOIN between REPLICATED and PARTITIONED caches.




---

Re: Ticket review checklist

[Dmitry Pavlov]

Requirement of green TC for each PR is community rule, not my.

I'll answer ro another question, what should we do with test failure:
"Ideally - fix, but at least mute test and create ticket. "

May be it's time to formalize Make TC Green Again process in details, so
let me share my draft.

If Igniter see test failure (in master, in release bracnh, etc), he should
consider following steps:

   - If your changes can led to this failure(s), please create issue with
   label MakeTeamCityGreenAgain and assign it to you.
  - If you have fix, please set ticket to PA state and write to dev
  list fix is ready.
  - For case fix will require some time please mute test and set label
  Muted_Test to issue
   - If you know which change caused failure please contact change author
   directly.
   - If you don't know which change caused failure please send message to
   dev list to find out




пн, 4 июн. 2018 г. в 15:27, Vladimir Ozerov :

> Dmitry,
>
> My question was how to proceed with your rules. Could you please clarify?
>
> On Mon, Jun 4, 2018 at 2:52 PM, Dmitry Pavlov 
> wrote:
>
> > Vladimir, I mean strict definition, how much previous runs should
> > contributor consider? What if test was failed by infrastructure reason in
> > master previously, how can contributor be sure test failure != broken
> code
> > in PR? In this case it should be double checked by contributor/reviewer.
> > I'm sure nobody can give strict definition of 'new' failure.
> >
> > Flaky tests detected by TC may be taken into account in check-list,
> because
> > contributor can check if failure is flaky. But again, not all tests with
> > floating failure is detected by TC as flaky.
> >
> > I don't understand what problem will be solved if we soften current
> > requirement with 'new' test? Everybody will continue to complain they
> PR's
> > test failures is not `new`. So let's keep it as is.
> >
> > пн, 4 июн. 2018 г. в 14:46, Vladimir Ozerov :
> >
> > > Dmitry,
> > >
> > > New failure is a failure hasn't happened on previous runs. If it do
> > > happened, then contributor should see if it is a flaky or not through
> > local
> > > and TC runs. The same works for timeout suites.
> > > Current statement in "Review Checklist" that there are should be no
> > failed
> > > tests is not applicable to real word. Almost every patch is pushed to
> > > repository with test failures.
> > >
> > > On Mon, Jun 4, 2018 at 2:22 PM, Dmitry Pavlov 
> > > wrote:
> > >
> > > > Hi Vladimir, could you provide definition what is new failure? how do
> > you
> > > > know it is new or not?
> > > >
> > > > And please forget for a moment you're Ignite expert & veteran,
> imagine
> > > you
> > > > are newcomer.
> > > >
> > > > I can't find any criteria that can be used by newbie to come to the
> > > > conclusion that test is new. Patch is accepted by reviewer, so it
> > should
> > > be
> > > > up to him to correctly register failures in tickets with
> > > > MakeTeamCityGreenAgain label and mute unimportant tests.
> > > >
> > > > пн, 4 июн. 2018 г. в 11:32, Vladimir Ozerov :
> > > >
> > > > > Dmitry,
> > > > >
> > > > > I still do not see how new patches could be accepted with this
> > > > requirement
> > > > > in place. Consider the following case: I created a patch and run it
> > on
> > > > TC,
> > > > > observed N failures, verified through TC history that none if them
> > are
> > > > new.
> > > > > Am I eligible to push the commit?
> > > > >
> > > > > On Thu, May 24, 2018 at 3:11 PM, Dmitry Pavlov <
> > dpavlov@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Petr, good point. It is more intuitive, we should mark test we
> can
> > > > ignore
> > > > > > by mute.
> > > > > >
> > > > > > So Vladimir, you or other Ignite veteran can mute test, if can
> say
> > it
> > > > is
> > > > > > not important.
> > > > > >
> > > > > > чт, 24 мая 2018 г. в 15:07, Petr Ivanov :
> > > > > >
> > > > > > > Why cannot we mute (and file corresponding tickets) all test
> > > failures
> > > > > > > (including flaky) to some date and start initiative Green TC?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > On 24 May 2018, at 15:04, Vladimir Ozerov <
> > voze...@gridgain.com>
> > > > > > wrote:
> > > > > > > >
> > > > > > > > Dmitry,
> > > > > > > >
> > > > > > > > We cannot add this requirements, because we do have failures
> on
> > > TC.
> > > > > > This
> > > > > > > > requirement implies that all development would stop until TC
> is
> > > > > green.
> > > > > > > > We never had old requirement work, neither we need to enforce
> > it
> > > > now.
> > > > > > > >
> > > > > > > > On Thu, May 24, 2018 at 2:59 PM, Dmitry Pavlov <
> > > > > dpavlov@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > >> 3.c
> > > > > > > >>
> > > > > > > >>   1. All test suites *MUST* be run on TeamCity [3] before
> > merge
> > > to
> > > > > > > master,
> > > > > > > >>   there *MUST NOT* be any test failures
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> 'New' 

[GitHub] ignite pull request #4119: Ignite 5954 30 time run test

[voipp]

GitHub user voipp opened a pull request:

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

Ignite 5954 30 time run test



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

$ git pull https://github.com/voipp/ignite IGNITE-5954-30-time-run-test

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

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

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

This closes #4119


commit d448653961658f85ce9223fd208321b93de0abe8
Author: voipp 
Date:   2018-05-23T13:14:51Z

IGNITE-5954 Remove obsolete near cache value from primary\backup node

commit 14ac8feaabf2a29f1cdb196d407b9b77723d6831
Author: voipp 
Date:   2018-06-04T12:51:59Z

#test run 30 times




---

Re: Upgrading Ignite to JCache 1.1

[Александр Меньшиков]

Hi,
Igniters!

I have taken a look at the jcache 1.1 spec and TCK.
And I can write a brief summary of my plan to solve the task.

I have found 6 problems in current master with TCK 1.1 (104 failed tests).
Of course, we should run this TCK on CI to be absolutely sure we didn't
miss something.

So the first step is an adding TCK 1.1 suite to our Team City.
I have created sub-task [1] for it and prepared the PR [2].
I need someone with access to merge PR and add suite to Team City.
It going to be just a clone of the current jcache-tck suite, but with using
the new profile.
You can test new profile locally with the following command:

mvn test -P-release,jcache-tck-1.1 -pl :ignite-core -am


After that, I will start to add sub-task for every problem we have.

Nikolay, can you please help me with merging [1] and adding to the suite?

[1]JIRA: https://issues.apache.org/jira/browse/IGNITE-8687
[2]PR: https://github.com/apache/ignite/pull/4114/files
[3]CI:
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_RunAll_IgniteTests24Java8=pull/4114/head=buildTypeStatusDiv

2018-05-23 14:31 GMT+03:00 Александр Меньшиков :

> Thanks, Slava. You are right.
>
> 2018-05-23 14:00 GMT+03:00 Vyacheslav Daradur :
>
>> Hi, Alex!
>>
>> Please have a look at maven profile named "jcache-tck".
>>
>> I believe this is what you are looking for.
>>
>> On Wed, May 23, 2018 at 11:50 AM, Александр Меньшиков
>>  wrote:
>> > Igniters,
>> > I think I can do it. As I see we already have JCache TCK tests in TC.
>> > Can I take somewhere settings/script which we are using?
>> >
>> > 2018-05-23 2:58 GMT+03:00 Dmitriy Setrakyan :
>> >
>> >> Igniters,
>> >>
>> >> It will be great if someone in the community would pick this up. The
>> amount
>> >> of changes are minimal and many of them only have to do with
>> clarifying the
>> >> documentation. However, removing JSR 107 license confusion in 1.1
>> would be
>> >> great for Ignite.
>> >>
>> >> D.
>> >>
>> >> On Tue, May 22, 2018 at 3:04 PM, Denis Magda 
>> wrote:
>> >>
>> >> > Here is a list of all changes:
>> >> > https://groups.google.com/forum/#!topic/jsr107/BC1qKqknzKU
>> >> >
>> >> > The primary argument for the migration is a license. JCache 1.0 is
>> >> licensed
>> >> > by Oracle that causes legal issues for some of the users. Once we
>> upgrade
>> >> > to JCache 1.1 the won't longer be a big deal.
>> >> >
>> >> > However, once we move to 1.1 we need to be sure that we comply with
>> the
>> >> > updated specification.
>> >> >
>> >> > --
>> >> > Denis
>> >> >
>> >> > On Tue, May 22, 2018 at 5:20 AM, Dmitry Pavlov <
>> dpavlov@gmail.com>
>> >> > wrote:
>> >> >
>> >> > > Hi Denis,
>> >> > >
>> >> > > What was improved in JCache 1.1?
>> >> > >
>> >> > > Would it be useful for product to change supported spec. version?
>> >> > >
>> >> > > Sincerely,
>> >> > > Dmitriy Pavlov
>> >> > >
>> >> > > пн, 21 мая 2018 г. в 20:12, Denis Magda :
>> >> > >
>> >> > > > Igniters,
>> >> > > >
>> >> > > > Eventually, JCache was relicensed to Apache 2.0 and released 1.1
>> >> > version:
>> >> > > > https://groups.google.com/forum/#!topic/jsr107/BC1qKqknzKU
>> >> > > >
>> >> > > > Is there anyone interested in upgrading Ignite to the new
>> version for
>> >> > the
>> >> > > > next release?
>> >> > > > https://issues.apache.org/jira/browse/IGNITE-8548
>> >> > > >
>> >> > > > --
>> >> > > > Denis
>> >> > > >
>> >> > >
>> >> >
>> >>
>>
>>
>>
>> --
>> Best Regards, Vyacheslav D.
>>
>
>

[jira] [Created] (IGNITE-8693) SQL JOIN between PARTITIONED and REPLICATED cache fails

[Ilya Lantukh (JIRA)]

Ilya Lantukh created IGNITE-8693:


 Summary: SQL JOIN between PARTITIONED and REPLICATED cache fails
 Key: IGNITE-8693
 URL: https://issues.apache.org/jira/browse/IGNITE-8693
 Project: Ignite
  Issue Type: Bug
Reporter: Ilya Lantukh
Assignee: Ilya Lantukh






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

[GitHub] ignite pull request #4118: IGNITE-8691 Removed jar-plugin from ignite-zookee...

[Jokser]

GitHub user Jokser opened a pull request:

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

IGNITE-8691 Removed jar-plugin from ignite-zookeeper module



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

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

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

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

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

This closes #4118


commit 0512f384fd85ebf5e03308aae1f459dc59855e71
Author: Pavel Kovalenko 
Date:   2018-06-04T12:31:25Z

IGNITE-8691 Removed jar-plugin from ignite-zookeeper module




---

[jira] [Created] (IGNITE-8692) MVCC TX: Always persistent TxLog

[Igor Seliverstov (JIRA)]

Igor Seliverstov created IGNITE-8692:


 Summary: MVCC TX: Always persistent TxLog
 Key: IGNITE-8692
 URL: https://issues.apache.org/jira/browse/IGNITE-8692
 Project: Ignite
  Issue Type: Task
  Components: cache, sql
Reporter: Igor Seliverstov


Currently TxLog may be overflowed in case a long running Tx prevents 
"vacuuming".

It can be solved by enabling persistence for TxLog data region by default.



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

Re: Ticket review checklist

[Vladimir Ozerov]

Dmitry,

My question was how to proceed with your rules. Could you please clarify?

On Mon, Jun 4, 2018 at 2:52 PM, Dmitry Pavlov  wrote:

> Vladimir, I mean strict definition, how much previous runs should
> contributor consider? What if test was failed by infrastructure reason in
> master previously, how can contributor be sure test failure != broken code
> in PR? In this case it should be double checked by contributor/reviewer.
> I'm sure nobody can give strict definition of 'new' failure.
>
> Flaky tests detected by TC may be taken into account in check-list, because
> contributor can check if failure is flaky. But again, not all tests with
> floating failure is detected by TC as flaky.
>
> I don't understand what problem will be solved if we soften current
> requirement with 'new' test? Everybody will continue to complain they PR's
> test failures is not `new`. So let's keep it as is.
>
> пн, 4 июн. 2018 г. в 14:46, Vladimir Ozerov :
>
> > Dmitry,
> >
> > New failure is a failure hasn't happened on previous runs. If it do
> > happened, then contributor should see if it is a flaky or not through
> local
> > and TC runs. The same works for timeout suites.
> > Current statement in "Review Checklist" that there are should be no
> failed
> > tests is not applicable to real word. Almost every patch is pushed to
> > repository with test failures.
> >
> > On Mon, Jun 4, 2018 at 2:22 PM, Dmitry Pavlov 
> > wrote:
> >
> > > Hi Vladimir, could you provide definition what is new failure? how do
> you
> > > know it is new or not?
> > >
> > > And please forget for a moment you're Ignite expert & veteran, imagine
> > you
> > > are newcomer.
> > >
> > > I can't find any criteria that can be used by newbie to come to the
> > > conclusion that test is new. Patch is accepted by reviewer, so it
> should
> > be
> > > up to him to correctly register failures in tickets with
> > > MakeTeamCityGreenAgain label and mute unimportant tests.
> > >
> > > пн, 4 июн. 2018 г. в 11:32, Vladimir Ozerov :
> > >
> > > > Dmitry,
> > > >
> > > > I still do not see how new patches could be accepted with this
> > > requirement
> > > > in place. Consider the following case: I created a patch and run it
> on
> > > TC,
> > > > observed N failures, verified through TC history that none if them
> are
> > > new.
> > > > Am I eligible to push the commit?
> > > >
> > > > On Thu, May 24, 2018 at 3:11 PM, Dmitry Pavlov <
> dpavlov@gmail.com>
> > > > wrote:
> > > >
> > > > > Petr, good point. It is more intuitive, we should mark test we can
> > > ignore
> > > > > by mute.
> > > > >
> > > > > So Vladimir, you or other Ignite veteran can mute test, if can say
> it
> > > is
> > > > > not important.
> > > > >
> > > > > чт, 24 мая 2018 г. в 15:07, Petr Ivanov :
> > > > >
> > > > > > Why cannot we mute (and file corresponding tickets) all test
> > failures
> > > > > > (including flaky) to some date and start initiative Green TC?
> > > > > >
> > > > > >
> > > > > >
> > > > > > > On 24 May 2018, at 15:04, Vladimir Ozerov <
> voze...@gridgain.com>
> > > > > wrote:
> > > > > > >
> > > > > > > Dmitry,
> > > > > > >
> > > > > > > We cannot add this requirements, because we do have failures on
> > TC.
> > > > > This
> > > > > > > requirement implies that all development would stop until TC is
> > > > green.
> > > > > > > We never had old requirement work, neither we need to enforce
> it
> > > now.
> > > > > > >
> > > > > > > On Thu, May 24, 2018 at 2:59 PM, Dmitry Pavlov <
> > > > dpavlov@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > >> 3.c
> > > > > > >>
> > > > > > >>   1. All test suites *MUST* be run on TeamCity [3] before
> merge
> > to
> > > > > > master,
> > > > > > >>   there *MUST NOT* be any test failures
> > > > > > >>
> > > > > > >>
> > > > > > >> 'New' word should be removed because we cant separate `new`
> and
> > > `non
> > > > > > new`
> > > > > > >> failures.
> > > > > > >>
> > > > > > >> Let's imagine example, we have 50 green runs in master. And PR
> > > > Run-All
> > > > > > >> contains this test failed. Is it new or not new? Actually we
> > don't
> > > > > know.
> > > > > > >>
> > > > > > >> Existing requirement is about all TC must be green, so let's
> > keep
> > > it
> > > > > as
> > > > > > is.
> > > > > > >>
> > > > > > >> ср, 23 мая 2018 г. в 17:02, Vladimir Ozerov <
> > voze...@gridgain.com
> > > >:
> > > > > > >>
> > > > > > >>> Igniters,
> > > > > > >>>
> > > > > > >>> I created review checklist on WIKI [1] and also fixed related
> > > pages
> > > > > > (e.g.
> > > > > > >>> "How To Contribute"). Please let me know if you have any
> > comments
> > > > > > before
> > > > > > >> I
> > > > > > >>> go with public announce.
> > > > > > >>>
> > > > > > >>> Vladimir.
> > > > > > >>>
> > > > > > >>> [1]
> > > > > >
> > https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist
> > > > > > >>>
> > > > > > >>> On Thu, May 10, 2018 at 5:10 PM, Vladimir Ozerov <
> > > > > voze...@gridgain.com
> > > > > > >
> > > > > > 

[GitHub] ignite pull request #4117: IGNITE-8663: Add Normalization Preprocessing supp...

[zaleslaw]

GitHub user zaleslaw opened a pull request:

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

IGNITE-8663: Add Normalization Preprocessing support



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

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

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

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

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

This closes #4117


commit 098d2832b3f4af23c72bc25f43e4ab8a95f2f416
Author: Zinoviev Alexey 
Date:   2018-04-11T18:40:27Z

IGNITE-7829: Added example

commit 78f9ea687bff77ec9f6bef87126569cb92cbe745
Author: Zinoviev Alexey 
Date:   2018-04-13T15:44:26Z

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

commit 199e17d19ccbde9f15aba5375d834c3930b3a989
Author: Zinoviev Alexey 
Date:   2018-04-27T10:12:47Z

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

commit aca9833df4d3cc4a641dd9109daaf628bc85acdf
Author: Zinoviev Alexey 
Date:   2018-05-08T05:29:49Z

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

commit bb244de762b89d0a1e5606aa282e34d92752595b
Author: Zinoviev Alexey 
Date:   2018-05-16T11:42:06Z

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

commit b4cb1a42d35a0da9f8b762207011a46c6f542a20
Author: Zinoviev Alexey 
Date:   2018-05-16T16:17:39Z

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

commit 5d447d57d61c77b9f415093d634df8f3dccd55eb
Author: Zinoviev Alexey 
Date:   2018-06-01T09:36:16Z

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

commit 81ddb1c5db410d50208ada6d3de869e127506f56
Author: Zinoviev Alexey 
Date:   2018-06-04T08:21:37Z

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

commit cb55f45a8fcf85668db73a286770fba14a25730e
Author: Zinoviev Alexey 
Date:   2018-06-04T12:17:19Z

IGNITE-8662: Added Normalization support




---

[GitHub] ignite pull request #4116: IGNITE-8690 Added missed package-infos.

[Jokser]

GitHub user Jokser opened a pull request:

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

IGNITE-8690 Added missed package-infos.



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

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

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

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

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

This closes #4116


commit 389c4553f399446cc1242772fc280e42eab1aeed
Author: Pavel Kovalenko 
Date:   2018-06-04T11:55:39Z

IGNITE-8690 Added package-info.

commit 41d27f6dde08483ea4c39c8bed46011d2eb4bdea
Author: Pavel Kovalenko 
Date:   2018-06-04T12:03:56Z

IGNITE-8690 Added package-info.




---

[GitHub] ignite pull request #4105: IGNITE-8675: Fixed flacky test PdsWithTtlCompatib...

[asfgit]

Github user asfgit closed the pull request at:

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


---

Re: [RESULT] [VOTE] Apache Ignite 2.5.0 Release (RC1)

[Petr Ivanov]

Dmitriy,


I’ve added requested information (see [1]).
Can you check that this information is enough, please?


[1] 
https://issues.apache.org/jira/browse/IGNITE-8671?focusedCommentId=16500123=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16500123




> On 3 Jun 2018, at 10:24, Dmitriy Setrakyan  wrote:
> 
> Peter,
> 
> I think what is really missing is the installation structure, i.e. where is
> the bin, config, lib, work folders. Is IGNITE_HOME pointing somewhere as a
> result of the installation? I think, if you explain it to users, there will
> be more understanding from the user stand point.
> 
> Can you please add that?
> 
> D.
> 
> On Sat, Jun 2, 2018 at 12:39 PM, Petr Ivanov  wrote:
> 
>> Dmitriy,
>> 
>> 
>> I've added warning snippet in the bottom of the Alternative Installation
>> Options section with reference on how to start Apache Ignite installed from
>> RPM or DEB packages as standalone Java application (see [1]).
>> Hope it will be enough.
>> 
>> 
>> [1] https://issues.apache.org/jira/browse/IGNITE-8671?
>> focusedCommentId=16499157=com.atlassian.jira.
>> plugin.system.issuetabpanels:comment-tabpanel#comment-16499157
>> 
>> 
>> 
>> 
>>> On 2 Jun 2018, at 21:57, Dmitriy Setrakyan 
>> wrote:
>>> 
>>> Peter,
>>> 
>>> We cannot have a distribution that works sometimes.
>>> 
>>> I think you should read the ticket carefully. I don't beleive we need to
>>> make any changes to the release, it is a matter of fixing the
>>> documentation.
>>> 
>>> Can you confirm this?
>>> 
>>> D.
>>> 
>>> 
>>> On Jun 2, 2018 11:44, "Peter Ivanov"  wrote:
>>> 
>>> Dmitriy,
>>> 
>>> 
>>> You suggest removing fully working under corresponding Linux distributive
>>> RPM and DEB packages entirely from apache.org/dist/ignite only because
>> they
>>> do not work in highly unlikely scenario (Windows 10 WSL) as service?
>>> 
>>> I will certainly add reference about running Apache Ignite from the
>>> packages as standalone Java application (with corresponding permissions
>>> note) but I’d like to hear community opinion on the whole matter -
>>> everything that was done, was done with review and approve from lots of
>>> Apache Ignite commiters and PMCs, including PMC chair.
>>> 
>>> 
>>> On Sat, 2 Jun 2018 at 16:12, Dmitriy Setrakyan 
>>> wrote:
>>> 
>>> 
 Peter,
 
 I have reopened this ticket:
 https://issues.apache.org/jira/browse/IGNITE-8671
 
 I changed the priority to blocker. At this point I suggest the
>> following:
 - we either remove the DEB and RPM packages from the website and readme
 - or we fix this issue ASAP as stated in the ticket.
 
 I will leave it up to you to decide.
 
 D.
 
 On Thu, May 31, 2018 at 10:31 PM, Peter Ivanov 
 wrote:
 
> Dmitriy,
> 
> 
> SystemD supports running multiple instances of one service – this is
>> done
> through @-like syntax: 'sudo systemctl start apache-ignite@
>>  file name>', so that with every unique command string there will be
> started
> / stopped unique instance of Apache Ignite. And all instances can be
> restarted / stopped / enabled on boot / etc. simultaneously through
>> 'sudo
> systemctl  apache-ignite@*'.
> 
> Still, I can add a note about possibility of starting Apache Ignite
> manually through ignite.sh with a reference to corresponding
>>> documentation
> section, information where to look for the root of Apache Ignite
> installation and how to correctly start Apache Ignite in terms of
> permissions.
> 
> File the documentation updates ticket?
> 
> 
> On Fri, 1 Jun 2018 at 01:10, Dmitriy Setrakyan 
> wrote:
> 
>> Petr,
>> 
>> Most of the users will download and install Ignite so they can develop
> with
>> it. This means that they will be starting more than one node, which is
>> impossible if Ignite is a service. We should provide instructions to
>> do
>> both.
>> 
>> D.
>> 
>> On Thu, May 31, 2018 at 2:47 PM, Peter Ivanov 
> wrote:
>> 
>>> Dmitriy,
>>> 
>>> 
>>> Current packages design (both RPM and DEB) was reviewed and approved
> by
>>> community. I do not quite remember why service-based startup was
> chosen
>> but
>>> it seems rather logical and Unix-compliant – under Linux almost every
>>> service software is packed this way, which gives some benefits like
>> service
>>> autostart on reboot, centralized running nodes management (through
>>> systemctl), etc. There is no point in packing binary into Linux
> packages
>> if
>>> it then will be used as standalone executable.
>>> Yet, current design does not limit advanced user from running Apache
>> Ignite
>>> as standalone process – executing
> /usr/share/apache-ignite/bin/ignite.sh
>>> with parameters will start Apache Ignite node as if it was delivered
> by
>>> binary archive.
>>> 

Re: Ticket review checklist

[Dmitry Pavlov]

Vladimir, I mean strict definition, how much previous runs should
contributor consider? What if test was failed by infrastructure reason in
master previously, how can contributor be sure test failure != broken code
in PR? In this case it should be double checked by contributor/reviewer.
I'm sure nobody can give strict definition of 'new' failure.

Flaky tests detected by TC may be taken into account in check-list, because
contributor can check if failure is flaky. But again, not all tests with
floating failure is detected by TC as flaky.

I don't understand what problem will be solved if we soften current
requirement with 'new' test? Everybody will continue to complain they PR's
test failures is not `new`. So let's keep it as is.

пн, 4 июн. 2018 г. в 14:46, Vladimir Ozerov :

> Dmitry,
>
> New failure is a failure hasn't happened on previous runs. If it do
> happened, then contributor should see if it is a flaky or not through local
> and TC runs. The same works for timeout suites.
> Current statement in "Review Checklist" that there are should be no failed
> tests is not applicable to real word. Almost every patch is pushed to
> repository with test failures.
>
> On Mon, Jun 4, 2018 at 2:22 PM, Dmitry Pavlov 
> wrote:
>
> > Hi Vladimir, could you provide definition what is new failure? how do you
> > know it is new or not?
> >
> > And please forget for a moment you're Ignite expert & veteran, imagine
> you
> > are newcomer.
> >
> > I can't find any criteria that can be used by newbie to come to the
> > conclusion that test is new. Patch is accepted by reviewer, so it should
> be
> > up to him to correctly register failures in tickets with
> > MakeTeamCityGreenAgain label and mute unimportant tests.
> >
> > пн, 4 июн. 2018 г. в 11:32, Vladimir Ozerov :
> >
> > > Dmitry,
> > >
> > > I still do not see how new patches could be accepted with this
> > requirement
> > > in place. Consider the following case: I created a patch and run it on
> > TC,
> > > observed N failures, verified through TC history that none if them are
> > new.
> > > Am I eligible to push the commit?
> > >
> > > On Thu, May 24, 2018 at 3:11 PM, Dmitry Pavlov 
> > > wrote:
> > >
> > > > Petr, good point. It is more intuitive, we should mark test we can
> > ignore
> > > > by mute.
> > > >
> > > > So Vladimir, you or other Ignite veteran can mute test, if can say it
> > is
> > > > not important.
> > > >
> > > > чт, 24 мая 2018 г. в 15:07, Petr Ivanov :
> > > >
> > > > > Why cannot we mute (and file corresponding tickets) all test
> failures
> > > > > (including flaky) to some date and start initiative Green TC?
> > > > >
> > > > >
> > > > >
> > > > > > On 24 May 2018, at 15:04, Vladimir Ozerov 
> > > > wrote:
> > > > > >
> > > > > > Dmitry,
> > > > > >
> > > > > > We cannot add this requirements, because we do have failures on
> TC.
> > > > This
> > > > > > requirement implies that all development would stop until TC is
> > > green.
> > > > > > We never had old requirement work, neither we need to enforce it
> > now.
> > > > > >
> > > > > > On Thu, May 24, 2018 at 2:59 PM, Dmitry Pavlov <
> > > dpavlov@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > >> 3.c
> > > > > >>
> > > > > >>   1. All test suites *MUST* be run on TeamCity [3] before merge
> to
> > > > > master,
> > > > > >>   there *MUST NOT* be any test failures
> > > > > >>
> > > > > >>
> > > > > >> 'New' word should be removed because we cant separate `new` and
> > `non
> > > > > new`
> > > > > >> failures.
> > > > > >>
> > > > > >> Let's imagine example, we have 50 green runs in master. And PR
> > > Run-All
> > > > > >> contains this test failed. Is it new or not new? Actually we
> don't
> > > > know.
> > > > > >>
> > > > > >> Existing requirement is about all TC must be green, so let's
> keep
> > it
> > > > as
> > > > > is.
> > > > > >>
> > > > > >> ср, 23 мая 2018 г. в 17:02, Vladimir Ozerov <
> voze...@gridgain.com
> > >:
> > > > > >>
> > > > > >>> Igniters,
> > > > > >>>
> > > > > >>> I created review checklist on WIKI [1] and also fixed related
> > pages
> > > > > (e.g.
> > > > > >>> "How To Contribute"). Please let me know if you have any
> comments
> > > > > before
> > > > > >> I
> > > > > >>> go with public announce.
> > > > > >>>
> > > > > >>> Vladimir.
> > > > > >>>
> > > > > >>> [1]
> > > > >
> https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist
> > > > > >>>
> > > > > >>> On Thu, May 10, 2018 at 5:10 PM, Vladimir Ozerov <
> > > > voze...@gridgain.com
> > > > > >
> > > > > >>> wrote:
> > > > > >>>
> > > > >  Ilya,
> > > > > 
> > > > >  We define that exception messages *SHOULD* have clear
> > explanation
> > > on
> > > > > >> what
> > > > >  is wrong. *SHOULD* mean that the rule should be followed
> unless
> > > > there
> > > > > >> is
> > > > > >>> a
> > > > >  reason not to follow. In your case you refer to some
> unexpected
> > > > > >> behavior.
> > > > >  I.e. an exceptional situation developer is not aware of. In
> 

[GitHub] ignite pull request #4115: IGNITE-8290: Trying to reproduce on TC.

[andrey-kuznetsov]

GitHub user andrey-kuznetsov opened a pull request:

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

IGNITE-8290: Trying to reproduce on TC.

Debug through CI.

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

$ git pull https://github.com/andrey-kuznetsov/ignite ignite-8290

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

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

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

This closes #4115


commit b8f4a20cee48220e47efaba8433820ed1c150153
Author: Andrey Kuznetsov 
Date:   2018-06-04T11:49:30Z

IGNITE-8290: Trying to reproduce on TC.




---

[jira] [Created] (IGNITE-8691) Get rid of tests jar artifact in ignite-zookeeper module

[Pavel Kovalenko (JIRA)]

Pavel Kovalenko created IGNITE-8691:
---

 Summary: Get rid of tests jar artifact in ignite-zookeeper module
 Key: IGNITE-8691
 URL: https://issues.apache.org/jira/browse/IGNITE-8691
 Project: Ignite
  Issue Type: Bug
  Components: zookeeper
Affects Versions: 2.5
Reporter: Pavel Kovalenko
Assignee: Pavel Kovalenko
 Fix For: 2.6


Currently Ignite building process produces 
{noformat}
org/apache/ignite/ignite-zookeeper/2.X.X/ignite-zookeeper-2.X.X-tests.jar
{noformat}
artifact which seems to be useless and should be excluded as result of 
packaging.



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

[jira] [Created] (IGNITE-8690) Missed package-info for some packages

[Pavel Kovalenko (JIRA)]

Pavel Kovalenko created IGNITE-8690:
---

 Summary: Missed package-info for some packages
 Key: IGNITE-8690
 URL: https://issues.apache.org/jira/browse/IGNITE-8690
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.5
Reporter: Pavel Kovalenko
Assignee: Pavel Kovalenko
 Fix For: 2.6


List of affected packages:

{noformat}
org.apache.ignite.spi.communication.tcp.internal
org.apache.ignite.spi.discovery.zk
org.apache.ignite.spi.discovery.zk.internal
org.apache.ignite.ml.structures.partition
{noformat}




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

Re: Ticket review checklist

[Vladimir Ozerov]

Dmitry,

New failure is a failure hasn't happened on previous runs. If it do
happened, then contributor should see if it is a flaky or not through local
and TC runs. The same works for timeout suites.
Current statement in "Review Checklist" that there are should be no failed
tests is not applicable to real word. Almost every patch is pushed to
repository with test failures.

On Mon, Jun 4, 2018 at 2:22 PM, Dmitry Pavlov  wrote:

> Hi Vladimir, could you provide definition what is new failure? how do you
> know it is new or not?
>
> And please forget for a moment you're Ignite expert & veteran, imagine you
> are newcomer.
>
> I can't find any criteria that can be used by newbie to come to the
> conclusion that test is new. Patch is accepted by reviewer, so it should be
> up to him to correctly register failures in tickets with
> MakeTeamCityGreenAgain label and mute unimportant tests.
>
> пн, 4 июн. 2018 г. в 11:32, Vladimir Ozerov :
>
> > Dmitry,
> >
> > I still do not see how new patches could be accepted with this
> requirement
> > in place. Consider the following case: I created a patch and run it on
> TC,
> > observed N failures, verified through TC history that none if them are
> new.
> > Am I eligible to push the commit?
> >
> > On Thu, May 24, 2018 at 3:11 PM, Dmitry Pavlov 
> > wrote:
> >
> > > Petr, good point. It is more intuitive, we should mark test we can
> ignore
> > > by mute.
> > >
> > > So Vladimir, you or other Ignite veteran can mute test, if can say it
> is
> > > not important.
> > >
> > > чт, 24 мая 2018 г. в 15:07, Petr Ivanov :
> > >
> > > > Why cannot we mute (and file corresponding tickets) all test failures
> > > > (including flaky) to some date and start initiative Green TC?
> > > >
> > > >
> > > >
> > > > > On 24 May 2018, at 15:04, Vladimir Ozerov 
> > > wrote:
> > > > >
> > > > > Dmitry,
> > > > >
> > > > > We cannot add this requirements, because we do have failures on TC.
> > > This
> > > > > requirement implies that all development would stop until TC is
> > green.
> > > > > We never had old requirement work, neither we need to enforce it
> now.
> > > > >
> > > > > On Thu, May 24, 2018 at 2:59 PM, Dmitry Pavlov <
> > dpavlov@gmail.com>
> > > > > wrote:
> > > > >
> > > > >> 3.c
> > > > >>
> > > > >>   1. All test suites *MUST* be run on TeamCity [3] before merge to
> > > > master,
> > > > >>   there *MUST NOT* be any test failures
> > > > >>
> > > > >>
> > > > >> 'New' word should be removed because we cant separate `new` and
> `non
> > > > new`
> > > > >> failures.
> > > > >>
> > > > >> Let's imagine example, we have 50 green runs in master. And PR
> > Run-All
> > > > >> contains this test failed. Is it new or not new? Actually we don't
> > > know.
> > > > >>
> > > > >> Existing requirement is about all TC must be green, so let's keep
> it
> > > as
> > > > is.
> > > > >>
> > > > >> ср, 23 мая 2018 г. в 17:02, Vladimir Ozerov  >:
> > > > >>
> > > > >>> Igniters,
> > > > >>>
> > > > >>> I created review checklist on WIKI [1] and also fixed related
> pages
> > > > (e.g.
> > > > >>> "How To Contribute"). Please let me know if you have any comments
> > > > before
> > > > >> I
> > > > >>> go with public announce.
> > > > >>>
> > > > >>> Vladimir.
> > > > >>>
> > > > >>> [1]
> > > > https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist
> > > > >>>
> > > > >>> On Thu, May 10, 2018 at 5:10 PM, Vladimir Ozerov <
> > > voze...@gridgain.com
> > > > >
> > > > >>> wrote:
> > > > >>>
> > > >  Ilya,
> > > > 
> > > >  We define that exception messages *SHOULD* have clear
> explanation
> > on
> > > > >> what
> > > >  is wrong. *SHOULD* mean that the rule should be followed unless
> > > there
> > > > >> is
> > > > >>> a
> > > >  reason not to follow. In your case you refer to some unexpected
> > > > >> behavior.
> > > >  I.e. an exceptional situation developer is not aware of. In this
> > > case
> > > > >> for
> > > >  sure we cannot force contributor to explain what is wrong,
> > because,
> > > > >> well,
> > > >  we don't know. This is why we relaxed the rule from *MUST* to
> > > > *SHOULD*.
> > > > 
> > > >  On Thu, May 10, 2018 at 3:50 PM, Ilya Kasnacheev <
> > > >  ilya.kasnach...@gmail.com> wrote:
> > > > 
> > > > > I don't think I quite understand how exception explanations
> > should
> > > > >> work.
> > > > >
> > > > > Imagine we have the following exception:
> > > > >
> > > > > // At least RuntimeException can be thrown by the code above
> when
> > > > > GridCacheContext is cleaned and there is
> > > > > // an attempt to use cleaned resources.
> > > > > U.error(log, "Unexpected exception during cache update", e);
> > > > >
> > > > > I mean, we genuinely don't know what happened here.
> > > > >
> > > > > Under new rules, what kind of "workaround" would that exception
> > > > >> suggest?
> > > > > "Try turning it off and then back on"?
> > > > > What explanation 

[jira] [Created] (IGNITE-8689) SQL query execution may lead to NullPointerException during node stop.

[Vyacheslav Koptilin (JIRA)]

Vyacheslav Koptilin created IGNITE-8689:
---

 Summary: SQL query execution may lead to NullPointerException 
during node stop.
 Key: IGNITE-8689
 URL: https://issues.apache.org/jira/browse/IGNITE-8689
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 2.4
Reporter: Vyacheslav Koptilin






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

Re: Ticket review checklist

[Dmitry Pavlov]

Hi Vladimir, could you provide definition what is new failure? how do you
know it is new or not?

And please forget for a moment you're Ignite expert & veteran, imagine you
are newcomer.

I can't find any criteria that can be used by newbie to come to the
conclusion that test is new. Patch is accepted by reviewer, so it should be
up to him to correctly register failures in tickets with
MakeTeamCityGreenAgain label and mute unimportant tests.

пн, 4 июн. 2018 г. в 11:32, Vladimir Ozerov :

> Dmitry,
>
> I still do not see how new patches could be accepted with this requirement
> in place. Consider the following case: I created a patch and run it on TC,
> observed N failures, verified through TC history that none if them are new.
> Am I eligible to push the commit?
>
> On Thu, May 24, 2018 at 3:11 PM, Dmitry Pavlov 
> wrote:
>
> > Petr, good point. It is more intuitive, we should mark test we can ignore
> > by mute.
> >
> > So Vladimir, you or other Ignite veteran can mute test, if can say it is
> > not important.
> >
> > чт, 24 мая 2018 г. в 15:07, Petr Ivanov :
> >
> > > Why cannot we mute (and file corresponding tickets) all test failures
> > > (including flaky) to some date and start initiative Green TC?
> > >
> > >
> > >
> > > > On 24 May 2018, at 15:04, Vladimir Ozerov 
> > wrote:
> > > >
> > > > Dmitry,
> > > >
> > > > We cannot add this requirements, because we do have failures on TC.
> > This
> > > > requirement implies that all development would stop until TC is
> green.
> > > > We never had old requirement work, neither we need to enforce it now.
> > > >
> > > > On Thu, May 24, 2018 at 2:59 PM, Dmitry Pavlov <
> dpavlov@gmail.com>
> > > > wrote:
> > > >
> > > >> 3.c
> > > >>
> > > >>   1. All test suites *MUST* be run on TeamCity [3] before merge to
> > > master,
> > > >>   there *MUST NOT* be any test failures
> > > >>
> > > >>
> > > >> 'New' word should be removed because we cant separate `new` and `non
> > > new`
> > > >> failures.
> > > >>
> > > >> Let's imagine example, we have 50 green runs in master. And PR
> Run-All
> > > >> contains this test failed. Is it new or not new? Actually we don't
> > know.
> > > >>
> > > >> Existing requirement is about all TC must be green, so let's keep it
> > as
> > > is.
> > > >>
> > > >> ср, 23 мая 2018 г. в 17:02, Vladimir Ozerov :
> > > >>
> > > >>> Igniters,
> > > >>>
> > > >>> I created review checklist on WIKI [1] and also fixed related pages
> > > (e.g.
> > > >>> "How To Contribute"). Please let me know if you have any comments
> > > before
> > > >> I
> > > >>> go with public announce.
> > > >>>
> > > >>> Vladimir.
> > > >>>
> > > >>> [1]
> > > https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist
> > > >>>
> > > >>> On Thu, May 10, 2018 at 5:10 PM, Vladimir Ozerov <
> > voze...@gridgain.com
> > > >
> > > >>> wrote:
> > > >>>
> > >  Ilya,
> > > 
> > >  We define that exception messages *SHOULD* have clear explanation
> on
> > > >> what
> > >  is wrong. *SHOULD* mean that the rule should be followed unless
> > there
> > > >> is
> > > >>> a
> > >  reason not to follow. In your case you refer to some unexpected
> > > >> behavior.
> > >  I.e. an exceptional situation developer is not aware of. In this
> > case
> > > >> for
> > >  sure we cannot force contributor to explain what is wrong,
> because,
> > > >> well,
> > >  we don't know. This is why we relaxed the rule from *MUST* to
> > > *SHOULD*.
> > > 
> > >  On Thu, May 10, 2018 at 3:50 PM, Ilya Kasnacheev <
> > >  ilya.kasnach...@gmail.com> wrote:
> > > 
> > > > I don't think I quite understand how exception explanations
> should
> > > >> work.
> > > >
> > > > Imagine we have the following exception:
> > > >
> > > > // At least RuntimeException can be thrown by the code above when
> > > > GridCacheContext is cleaned and there is
> > > > // an attempt to use cleaned resources.
> > > > U.error(log, "Unexpected exception during cache update", e);
> > > >
> > > > I mean, we genuinely don't know what happened here.
> > > >
> > > > Under new rules, what kind of "workaround" would that exception
> > > >> suggest?
> > > > "Try turning it off and then back on"?
> > > > What explanation how to resolve this exception can we offer?
> > "Please
> > > >>> write
> > > > to d...@apache.ignite.org or to Apache JIRA, and then wait for a
> > > >> release
> > > > with fix?"
> > > >
> > > > I'm really confused how we can implement 1.6 and 1.7 when dealing
> > > with
> > > > messy real-world code.
> > > >
> > > > Regards,
> > > >
> > > >
> > > > --
> > > > Ilya Kasnacheev
> > > >
> > > > 2018-05-10 11:39 GMT+03:00 Vladimir Ozerov  >:
> > > >
> > > >> Andrey, Anton, Alex
> > > >>
> > > >> Agree, *SHOULD* is more appropriate here.
> > > >>
> > > >> Please see latest version below. Does anyone want to add or
> change
> > > >> 

Thin client protocol version release notes.

[Igor Sapego]

Igniters,

Currently, our thin client specification is kept on readme.io [1].
However, sometimes to introduce new features while keeping
backward compatibility, we need to increase protocol version.

The issue is: there is currently no easy way for thin client
developers to find out when thin protocol version has been
updated and what kind of new features have been introduced.

We may want to make a rule, that a commiter, that merge a
commit to the master, that introduces new thin client version,
should send an update email to devlist.

We may also want to have some kind of "Changes list" page on
readme.io which will track protocol changes from version to
version.

What are your thoughts on the topic?

[1] - https://apacheignite.readme.io/docs/binary-client-protocol

Best Regards,
Igor

Re: What's new for thin client protocol v1.1.0 vs v1.0.0

[Igor Sapego]

No, we don't AFAIK.

Feel free to create one.

Best Regards,
Igor

On Mon, Jun 4, 2018 at 1:34 PM, Nikolay Izhikov  wrote:

> Hello, Igniters.
>
> AFAIK, we have backward compatibility for a thin client protocol.
> But, currently, we doesn't have any kind of tests to check it.
>
> Do we have a ticket to create backward compatibility tests?
>
>
>
> В Пн, 04/06/2018 в 13:30 +0300, Igor Sapego пишет:
> > Hi Aleksandr,
> >
> > There are no changes other than username/password support.
> >
> > But that's a good point to start a discussion on how do we publish
> > Thin Protocol changes. I'll start a thread for it on devlist - feel free
> to
> > take part in it.
> >
> > Best Regards,
> > Igor
> >
> > On Sun, Jun 3, 2018 at 11:23 AM, Aleksandr Sokolovskii <
> amso...@gmail.com>
> > wrote:
> >
> > > Hi All,
> > >
> > > Is there thin client protocol v1.1.0 release notes with summary of
> changes
> > > vs v1.0.0?
> > > It’s necessary to update Golang thin client.
> > > I have added TLS and username/password support for connection already.
> > > But I can’t find information about other changes.
> > >
> > > Thanks,
> > > Aleksandr
> > >
> > >
>

Re: What's new for thin client protocol v1.1.0 vs v1.0.0

[Nikolay Izhikov]

Hello, Igniters.

AFAIK, we have backward compatibility for a thin client protocol.
But, currently, we doesn't have any kind of tests to check it.

Do we have a ticket to create backward compatibility tests?



В Пн, 04/06/2018 в 13:30 +0300, Igor Sapego пишет:
> Hi Aleksandr,
> 
> There are no changes other than username/password support.
> 
> But that's a good point to start a discussion on how do we publish
> Thin Protocol changes. I'll start a thread for it on devlist - feel free to
> take part in it.
> 
> Best Regards,
> Igor
> 
> On Sun, Jun 3, 2018 at 11:23 AM, Aleksandr Sokolovskii 
> wrote:
> 
> > Hi All,
> > 
> > Is there thin client protocol v1.1.0 release notes with summary of changes
> > vs v1.0.0?
> > It’s necessary to update Golang thin client.
> > I have added TLS and username/password support for connection already.
> > But I can’t find information about other changes.
> > 
> > Thanks,
> > Aleksandr
> > 
> > 

signature.asc
Description: This is a digitally signed message part

Re: What's new for thin client protocol v1.1.0 vs v1.0.0

[Igor Sapego]

Hi Aleksandr,

There are no changes other than username/password support.

But that's a good point to start a discussion on how do we publish
Thin Protocol changes. I'll start a thread for it on devlist - feel free to
take part in it.

Best Regards,
Igor

On Sun, Jun 3, 2018 at 11:23 AM, Aleksandr Sokolovskii 
wrote:

> Hi All,
>
> Is there thin client protocol v1.1.0 release notes with summary of changes
> vs v1.0.0?
> It’s necessary to update Golang thin client.
> I have added TLS and username/password support for connection already.
> But I can’t find information about other changes.
>
> Thanks,
> Aleksandr
>
>

[jira] [Created] (IGNITE-8688) Pending tree is initialized outside of checkpoint lock

[Pavel Kovalenko (JIRA)]

Pavel Kovalenko created IGNITE-8688:
---

 Summary: Pending tree is initialized outside of checkpoint lock
 Key: IGNITE-8688
 URL: https://issues.apache.org/jira/browse/IGNITE-8688
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.5
Reporter: Pavel Kovalenko
Assignee: Andrew Mashenkov
 Fix For: 2.6


This may lead to possible page corruption.

{noformat}
handled accordingly to configured handler [hnd=class 
o.a.i.failure.StopNodeOrHaltFailureHandler, failureCtx=FailureContext 
[type=SYSTEM_WORKER_TERMINATION, err=java.lang.AssertionError]]
[00:11:56]W: [org.gridgain:gridgain-compatibility] 
java.lang.AssertionError
[00:11:56]W: [org.gridgain:gridgain-compatibility]  at 
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.allocatePage(PageMemoryImpl.java:463)
[00:11:56]W: [org.gridgain:gridgain-compatibility]  at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.allocateForTree(IgniteCacheOffheapManagerImpl.java:818)
[00:11:56]W: [org.gridgain:gridgain-compatibility]  at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.initPendingTree(IgniteCacheOffheapManagerImpl.java:164)
[00:11:56]W: [org.gridgain:gridgain-compatibility]  at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.onCacheStarted(IgniteCacheOffheapManagerImpl.java:151)
[00:11:56]W: [org.gridgain:gridgain-compatibility]  at 
org.apache.ignite.internal.processors.cache.CacheGroupContext.onCacheStarted(CacheGroupContext.java:283)
[00:11:56]W: [org.gridgain:gridgain-compatibility]  at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1965)
[00:11:56]W: [org.gridgain:gridgain-compatibility]  at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onCacheChangeRequest(CacheAffinitySharedManager.java:791)
[00:11:56]W: [org.gridgain:gridgain-compatibility]  at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest(GridDhtPartitionsExchangeFuture.java:946)
[00:11:56]W: [org.gridgain:gridgain-compatibility]  at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:651)
[00:11:56]W: [org.gridgain:gridgain-compatibility]  at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2458)
[00:11:56]W: [org.gridgain:gridgain-compatibility]  at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2338)
[00:11:56]W: [org.gridgain:gridgain-compatibility]  at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
[00:11:56]W: [org.gridgain:gridgain-compatibility]  at 
java.lang.Thread.run(Thread.java:748)
{noformat}




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

[GitHub] ignite pull request #4114: ignite-8687 Add JCache TCK 1.1.0 to TC

[SharplEr]

GitHub user SharplEr opened a pull request:

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

ignite-8687 Add JCache TCK 1.1.0 to TC

For [IGNITE-8687](https://issues.apache.org/jira/browse/IGNITE-8687)

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

$ git pull https://github.com/SharplEr/ignite ignite-8687

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

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

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

This closes #4114


commit 2f169ceaad811282998194257858ee3e3dadf74c
Author: Alexander Menshikov 
Date:   2018-06-04T09:11:31Z

ignite-8687 Add JCache TCK 1.1.0 to TC




---

[jira] [Created] (IGNITE-8687) Add JCache TCK 1.1.0 to TC

[Alexander Menshikov (JIRA)]

Alexander Menshikov created IGNITE-8687:
---

 Summary: Add JCache TCK 1.1.0 to TC
 Key: IGNITE-8687
 URL: https://issues.apache.org/jira/browse/IGNITE-8687
 Project: Ignite
  Issue Type: Sub-task
Reporter: Alexander Menshikov
Assignee: Alexander Menshikov


We need to add a new profile for run TCK 1.1.0 and add it to TC.

Until Ignite becomes JCache 1.1.0 compatible, this profile should coexist with 
TCK 1.0.1.



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

[jira] [Created] (IGNITE-8686) Web console: 'Get started' point to the wrong page

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-8686:
--

 Summary: Web console: 'Get started' point to the wrong page
 Key: IGNITE-8686
 URL: https://issues.apache.org/jira/browse/IGNITE-8686
 Project: Ignite
  Issue Type: Bug
Reporter: Pavel Konstantinov
 Attachments: screenshot-1.png

I'm noticed that 'Get started' button on the landing page points to 'signin' 
page, but should point to 'signup' page.



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

[jira] [Created] (IGNITE-8685) Incorrect size for switch segment record

[Dmitriy Govorukhin (JIRA)]

Dmitriy Govorukhin created IGNITE-8685:
--

 Summary: Incorrect size for switch segment record 
 Key: IGNITE-8685
 URL: https://issues.apache.org/jira/browse/IGNITE-8685
 Project: Ignite
  Issue Type: Bug
Reporter: Dmitriy Govorukhin


We have invariant that switch segment record should have the size of one byte.
Although, in the current implementation, size calculation with overhard for 
storing CRC and WAL pointer.



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

Re: Ticket review checklist

[Vladimir Ozerov]

Dmitry,

I still do not see how new patches could be accepted with this requirement
in place. Consider the following case: I created a patch and run it on TC,
observed N failures, verified through TC history that none if them are new.
Am I eligible to push the commit?

On Thu, May 24, 2018 at 3:11 PM, Dmitry Pavlov 
wrote:

> Petr, good point. It is more intuitive, we should mark test we can ignore
> by mute.
>
> So Vladimir, you or other Ignite veteran can mute test, if can say it is
> not important.
>
> чт, 24 мая 2018 г. в 15:07, Petr Ivanov :
>
> > Why cannot we mute (and file corresponding tickets) all test failures
> > (including flaky) to some date and start initiative Green TC?
> >
> >
> >
> > > On 24 May 2018, at 15:04, Vladimir Ozerov 
> wrote:
> > >
> > > Dmitry,
> > >
> > > We cannot add this requirements, because we do have failures on TC.
> This
> > > requirement implies that all development would stop until TC is green.
> > > We never had old requirement work, neither we need to enforce it now.
> > >
> > > On Thu, May 24, 2018 at 2:59 PM, Dmitry Pavlov 
> > > wrote:
> > >
> > >> 3.c
> > >>
> > >>   1. All test suites *MUST* be run on TeamCity [3] before merge to
> > master,
> > >>   there *MUST NOT* be any test failures
> > >>
> > >>
> > >> 'New' word should be removed because we cant separate `new` and `non
> > new`
> > >> failures.
> > >>
> > >> Let's imagine example, we have 50 green runs in master. And PR Run-All
> > >> contains this test failed. Is it new or not new? Actually we don't
> know.
> > >>
> > >> Existing requirement is about all TC must be green, so let's keep it
> as
> > is.
> > >>
> > >> ср, 23 мая 2018 г. в 17:02, Vladimir Ozerov :
> > >>
> > >>> Igniters,
> > >>>
> > >>> I created review checklist on WIKI [1] and also fixed related pages
> > (e.g.
> > >>> "How To Contribute"). Please let me know if you have any comments
> > before
> > >> I
> > >>> go with public announce.
> > >>>
> > >>> Vladimir.
> > >>>
> > >>> [1]
> > https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist
> > >>>
> > >>> On Thu, May 10, 2018 at 5:10 PM, Vladimir Ozerov <
> voze...@gridgain.com
> > >
> > >>> wrote:
> > >>>
> >  Ilya,
> > 
> >  We define that exception messages *SHOULD* have clear explanation on
> > >> what
> >  is wrong. *SHOULD* mean that the rule should be followed unless
> there
> > >> is
> > >>> a
> >  reason not to follow. In your case you refer to some unexpected
> > >> behavior.
> >  I.e. an exceptional situation developer is not aware of. In this
> case
> > >> for
> >  sure we cannot force contributor to explain what is wrong, because,
> > >> well,
> >  we don't know. This is why we relaxed the rule from *MUST* to
> > *SHOULD*.
> > 
> >  On Thu, May 10, 2018 at 3:50 PM, Ilya Kasnacheev <
> >  ilya.kasnach...@gmail.com> wrote:
> > 
> > > I don't think I quite understand how exception explanations should
> > >> work.
> > >
> > > Imagine we have the following exception:
> > >
> > > // At least RuntimeException can be thrown by the code above when
> > > GridCacheContext is cleaned and there is
> > > // an attempt to use cleaned resources.
> > > U.error(log, "Unexpected exception during cache update", e);
> > >
> > > I mean, we genuinely don't know what happened here.
> > >
> > > Under new rules, what kind of "workaround" would that exception
> > >> suggest?
> > > "Try turning it off and then back on"?
> > > What explanation how to resolve this exception can we offer?
> "Please
> > >>> write
> > > to d...@apache.ignite.org or to Apache JIRA, and then wait for a
> > >> release
> > > with fix?"
> > >
> > > I'm really confused how we can implement 1.6 and 1.7 when dealing
> > with
> > > messy real-world code.
> > >
> > > Regards,
> > >
> > >
> > > --
> > > Ilya Kasnacheev
> > >
> > > 2018-05-10 11:39 GMT+03:00 Vladimir Ozerov :
> > >
> > >> Andrey, Anton, Alex
> > >>
> > >> Agree, *SHOULD* is more appropriate here.
> > >>
> > >> Please see latest version below. Does anyone want to add or change
> > >> something? Let's wait for several days for more feedback and then
> > > publish
> > >> and announce this list. Note that it would not be carved in stone
> > >> and
> > >>> we
> > >> will be able to change it at any time if needed.
> > >>
> > >> 1) API
> > >> 1.1) API compatibility *MUST* be maintained between minor
> releases.
> > >> Do
> > > not
> > >> remove existing methods or change their signatures, deprecate them
> > > instead
> > >> 1.2) Default behaviour "SHOULD NOT* be changed between minor
> > >> releases,
> > >> unless absolutely needed. If change is made, it *MUST* be
> described
> > >> in
> > >> "Migration Guide"
> > >> 1.3) New operation *MUST* be well-documented in code (javadoc,
> > > dotnetdoc):
> > >> documentation