[jira] [Created] (IGNITE-11377) Display time to baseline auto-adjust event in console.sh

[Anton Kalashnikov (JIRA)]

Anton Kalashnikov created IGNITE-11377:
--

 Summary: Display time to baseline auto-adjust event in console.sh
 Key: IGNITE-11377
 URL: https://issues.apache.org/jira/browse/IGNITE-11377
 Project: Ignite
  Issue Type: Improvement
Reporter: Anton Kalashnikov
Assignee: Anton Kalashnikov


It required to add information about next auto-adjust.



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

[jira] [Created] (IGNITE-11376) Web console: frontend cold build speed improvements

[Ilya Borisov (JIRA)]

Ilya Borisov created IGNITE-11376:
-

 Summary: Web console: frontend cold build speed improvements
 Key: IGNITE-11376
 URL: https://issues.apache.org/jira/browse/IGNITE-11376
 Project: Ignite
  Issue Type: Improvement
  Components: wizards
Reporter: Ilya Borisov
Assignee: Ilya Borisov


*The issue:*
Frontend cold build takes considerable time to build (~46s on my machine), 
which is rather annoying.

*What to do:*
1. Try both of these Webpack plugins and benchmark cold build results:
https://github.com/amireh/happypack
https://github.com/webpack-contrib/thread-loader
2. If we deem build time reduction considerable enough and no additional issues 
arise (like loader compatibility), add either of plugins to web console Webpack 
configuration.



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

[jira] [Created] (IGNITE-11375) Web console: Show appropriate message in no data component when demo is disabled on agent

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-11375:
--

 Summary: Web console: Show appropriate message in no data 
component when demo is disabled on agent
 Key: IGNITE-11375
 URL: https://issues.apache.org/jira/browse/IGNITE-11375
 Project: Ignite
  Issue Type: Improvement
  Components: wizards
Reporter: Vasiliy Sisko
Assignee: Alexander Kalinin


If the demo is opened and stay only an agent with disabled demo The no data 
component should show appropriate message.



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

[jira] [Created] (IGNITE-11374) Web console: fix frontend audit issues

[Ilya Borisov (JIRA)]

Ilya Borisov created IGNITE-11374:
-

 Summary: Web console: fix frontend audit issues
 Key: IGNITE-11374
 URL: https://issues.apache.org/jira/browse/IGNITE-11374
 Project: Ignite
  Issue Type: Improvement
  Components: wizards
Reporter: Ilya Borisov
Assignee: Ilya Borisov


The issue:
npm audit outputs several vulnerabilities in frontend dependencies, mostly 
related to unit tests. 

What to do:
Install packages suggested by `npm audit`. Ensure no regressions happen 
(anything besides unit tests?). It might be necessary to add package-lock.json.



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

[jira] [Created] (IGNITE-11373) varchar_ignorecase doesn't work properly

[Evgenii Zhuravlev (JIRA)]

Evgenii Zhuravlev created IGNITE-11373:
--

 Summary: varchar_ignorecase doesn't work properly
 Key: IGNITE-11373
 URL: https://issues.apache.org/jira/browse/IGNITE-11373
 Project: Ignite
  Issue Type: Bug
Reporter: Evgenii Zhuravlev


Looks like a field with type varchar_ignorecase can't be used for filtering the 
values for different cases.


{code:java}
Ignite ignite = Ignition.start("examples/config/example-ignite.xml");

IgniteCache cache = ignite.getOrCreateCache("TEST");

cache.query(new SqlFieldsQuery("CREATE TABLE IF NOT EXISTS TEST\n" +
"(\n" +
"  TEST_IDNUMBER(15)NOT NULL,\n" +
"  TEST_VALUE VARCHAR_IGNORECASE(100),\n" +
"  PRIMARY KEY (TEST_ID)\n" +
") "));

System.out.println("INSERTED:" + ignite.cache("TEST").query(new 
SqlFieldsQuery("INSERT INTO TEST values (1,'aAa')")).getAll().size());

System.out.println("FOUND:" + ignite.cache("TEST").query(new 
SqlFieldsQuery("Select * from TEST where TEST_VALUE like 
'%aaa%'")).getAll().size());
{code}



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

Re: Apache ignite tasks: IGNITE-11230, IGNITE-11131

[Dmitriy Pavlov]

Hi Ankit,

could you please share your JIRA username?

Sincerely,
Dmitriy Pavlov

ср, 20 февр. 2019 г. в 05:55, ankit singh :

> Hi,
>
> As newbie committer to apache ignite, I would like to start with following
> jiras
>
> IGNITE-11230
> IGNITE-11131 
>
> Kindly add me to the contributors list.
>
> Regards,
> Ankit
>

Re: Migration to JUnit 5

[Dmitriy Pavlov]

Done, please check access now.

ср, 20 февр. 2019 г. в 21:49, Ivan Fedotov :

> Dmitriy, thank you for the response.
>
> My wiki username is "ivanan", the related mailbox is ivanan...@gmail.com.
>
> ср, 20 февр. 2019 г. в 18:38, Dmitriy Pavlov :
>
> > Hi Ivan,
> >
> > Now admin service is unavailable (gives error 503). I'll add rights once
> it
> > is up and running.
> >
> > Could you share your wiki username? I can't find any users who signed up
> in
> > the wiki with any similar email/username
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > ср, 20 февр. 2019 г. в 18:26, Ivan Fedotov :
> >
> > > Hi, Igniters.
> > >
> > > I am planning to formalize migration to JUnit5 and create IEP which
> will
> > > include related issues.
> > >
> > > I already started to work on one of the issues [1] and created a draft
> > for
> > > the corresponding IEP [2].
> > >
> > > Please, give me rights for confluence to create IEP.
> > >
> > > [1] https://issues.apache.org/jira/browse/IGNITE-10973
> > > [2] https://gist.github.com/1vanan/1f81319f1dc6d6ebca30c216fdd82759
> > >
> > > Sincerely,
> > > Ivan Fedotov.
> > >
> > > ivanan...@gmail.com
> > >
> >
>
>
> --
> Ivan Fedotov.
>
> ivanan...@gmail.com
>

Re: Migration to JUnit 5

[Ivan Fedotov]

Dmitriy, thank you for the response.

My wiki username is "ivanan", the related mailbox is ivanan...@gmail.com.

ср, 20 февр. 2019 г. в 18:38, Dmitriy Pavlov :

> Hi Ivan,
>
> Now admin service is unavailable (gives error 503). I'll add rights once it
> is up and running.
>
> Could you share your wiki username? I can't find any users who signed up in
> the wiki with any similar email/username
>
> Sincerely,
> Dmitriy Pavlov
>
> ср, 20 февр. 2019 г. в 18:26, Ivan Fedotov :
>
> > Hi, Igniters.
> >
> > I am planning to formalize migration to JUnit5 and create IEP which will
> > include related issues.
> >
> > I already started to work on one of the issues [1] and created a draft
> for
> > the corresponding IEP [2].
> >
> > Please, give me rights for confluence to create IEP.
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-10973
> > [2] https://gist.github.com/1vanan/1f81319f1dc6d6ebca30c216fdd82759
> >
> > Sincerely,
> > Ivan Fedotov.
> >
> > ivanan...@gmail.com
> >
>


-- 
Ivan Fedotov.

ivanan...@gmail.com

Re: Migration to JUnit 5

[Dmitriy Pavlov]

Hi Ivan,

Now admin service is unavailable (gives error 503). I'll add rights once it
is up and running.

Could you share your wiki username? I can't find any users who signed up in
the wiki with any similar email/username

Sincerely,
Dmitriy Pavlov

ср, 20 февр. 2019 г. в 18:26, Ivan Fedotov :

> Hi, Igniters.
>
> I am planning to formalize migration to JUnit5 and create IEP which will
> include related issues.
>
> I already started to work on one of the issues [1] and created a draft for
> the corresponding IEP [2].
>
> Please, give me rights for confluence to create IEP.
>
> [1] https://issues.apache.org/jira/browse/IGNITE-10973
> [2] https://gist.github.com/1vanan/1f81319f1dc6d6ebca30c216fdd82759
>
> Sincerely,
> Ivan Fedotov.
>
> ivanan...@gmail.com
>

[jira] [Created] (IGNITE-11372) [ML] Fix javadoc in VectorWithDistributionId

[Alexey Platonov (JIRA)]

Alexey Platonov created IGNITE-11372:


 Summary: [ML] Fix javadoc in VectorWithDistributionId
 Key: IGNITE-11372
 URL: https://issues.apache.org/jira/browse/IGNITE-11372
 Project: Ignite
  Issue Type: Bug
  Components: ml
Reporter: Alexey Platonov
Assignee: Alexey Platonov


"mvn initialize -Pjavadoc" fails with error

"[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-antrun-plugin:1.7:run 
(javadoc-postprocessing-new) on project apache-ignite: An Ant BuildException 
has occured: Execution failed due to: Class doesn't have description in file: 
<..>/ml/util/generators/primitives/vector/VectorGeneratorsFamily.VectorWithDistributionId.html"



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

Migration to JUnit 5

[Ivan Fedotov]

Hi, Igniters.

I am planning to formalize migration to JUnit5 and create IEP which will
include related issues.

I already started to work on one of the issues [1] and created a draft for
the corresponding IEP [2].

Please, give me rights for confluence to create IEP.

[1] https://issues.apache.org/jira/browse/IGNITE-10973
[2] https://gist.github.com/1vanan/1f81319f1dc6d6ebca30c216fdd82759

Sincerely,
Ivan Fedotov.

ivanan...@gmail.com

[jira] [Created] (IGNITE-11371) Cache get operation with readThrough returns null if remove is performed concurrently

[Denis Mekhanikov (JIRA)]

Denis Mekhanikov created IGNITE-11371:
-

 Summary: Cache get operation with readThrough returns null if 
remove is performed concurrently
 Key: IGNITE-11371
 URL: https://issues.apache.org/jira/browse/IGNITE-11371
 Project: Ignite
  Issue Type: Bug
Reporter: Denis Mekhanikov
 Attachments: IgniteInvalidationNullRunner.java

Consider a situation, when you have a cache with {{CacheStore}} and 
{{readThrough}} configured.

One may expect, that {{IgniteCache#get(...)}} operation will never return 
{{null}} for keys, that are present in the underlying {{CacheStore}}. But 
actually it's possible to get {{null}} in case if remove operation is called on 
the same key while {{CacheStore#load}} is running.

Reproducer is attached.



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

Re: Python examples are missing in Ignite 2.7

[Petr Ivanov]

Fixed that.


> On 20 Feb 2019, at 14:50, Stepan Pilschikov  wrote:
> 
> Denis, Dmitry
> 
> Found that https://issues.apache.org/jira/browse/IGNITE-9922
> Release process just do not copy this folder
> And this directory do not copy because of Dmitry concerns described earlier
> 
> Agreed with Denis that examples folder should be in release build because
> of:
> - they really help to understand how client work
> - they understandable enough even without documentation
> - actually they contain link on examples documentation on readthedocs.io
> - others clients have common structure (examples, lib, README.md, artifacts
> to install package) but python client have not
> 
> Dmitry talk about PyPI package which is should not contain any redundant
> files and i agreed with him
> But Denis talk only about apache-ignite release build binaries
> 
> Also found https://issues.apache.org/jira/browse/IGNITE-10683
> Don't know how new folder is affected on release procedure of PyPi package
> because ignite do not have fully automated pypi package release process, i
> told only about release binaries
> 
> I've open new ticket to add examples in release build:
> https://issues.apache.org/jira/browse/IGNITE-11366
> 
> Dmitry, if you have any objections or improvements for this process you can
> described theys in ticket
> 
> чт, 14 февр. 2019 г. в 21:21, Denis Magda :
> 
>> Dmitry,
>> 
>> Thanks for looking into this. I think that something went wrong with our
>> release procedure and we forgot to include the "examples" folder in Ignite
>> binary package. Sergey K. is checking the release procedures.
>> 
>> 
>> -
>> Denis
>> 
>> 
>> On Tue, Feb 12, 2019 at 7:28 PM Dmitry Melnichuk <
>> dmitry.melnic...@nobitlost.com> wrote:
>> 
>>> We just browse through the contents of the latest Ignite bundles [1].
>>> 
>>> Source bundle [2] contains the examples all right; they are in this
>>> folder:
>>> 
>>> /apache-ignite-2.7.0-src/modules/platforms/python/examples/
>>> 
>>> Binary bundle [3] do not contain examples. I'm not totally sure, but
>>> the reasoning I gave earlier might apply to binary bundle too.
>>> 
>>> Can anyone who's aware of the bundling procedure/scripts chime in,
>>> please?
>>> 
>>> [1] https://ignite.apache.org/download.cgi
>>> 
>>> [2]
>>> 
>>> 
>> http://mirrors.standaloneinstaller.com/apache//ignite/2.7.0/apache-ignite-2.7.0-src.zip
>>> 
>>> [3]
>>> 
>>> 
>> http://mirrors.standaloneinstaller.com/apache//ignite/2.7.0/apache-ignite-2.7.0-bin.zip
>>> 
>>> On Wed, 2019-02-13 at 12:49 +1000, Dmitry Melnichuk wrote:
 Denis,
 
 If by “release procedure” you mean the contents of the PyPI package,
 then it is not a bug, but a deliberate decision, that was documented
 in
 README [1]:
 
> Installation
> 
> - for end user
> 
> If you only want to use the pyignite module in your project, do:
> 
> $ pip install pyignite
> 
> -- for developer
> 
> If you want to run tests, examples or build documentation, clone
> the
> whole repository…
 
 The reasoning:
 
 1. The examples do not have much value by themselves. They are useful
 only in conjunction with the documentation. If we do not ship the
 documentation via PyPI, then we should not ship the examples either.
 
 2. In production environment, the extra packaged stuff like examples
 will be just a waste of space.
 
 3. Most Python libraries and frameworks I know of, e.g. Django or
 Scrapy, use the same approach: they have examples and test apps in
 the
 repository and reference them through their docs, but do not ship
 them
 via PyPI.
 
 [1]
 
>>> 
>> https://github.com/apache/ignite/tree/master/modules/platforms/python#installation
 
 On Tue, 2019-02-12 at 16:23 -0800, Denis Magda wrote:
> Igniters,
> 
> Seems python examples were not added to the release bundle?
> 
>>> 
>> https://apacheignite.readme.io/v2.7/docs/python-thin-client#section-running-an-example
> 
> There is no "examples" folder for Python. Any flaws in the release
> procedure?
> 
> -
> Denis
>>> 
>>> 
>> 

Re: Would like to work on IGNITE-11369

[Dmitriy Pavlov]

Hi, this ticket is already assigned, so you can contact the contributor if
he wants to proceed with fix or not.

ср, 20 февр. 2019 г. в 16:08, ankit singh :

> Hi,
> As newbie to Apache ingnite Dev, I would like to work on following jira.
>
> IGNITE-11369
>

Re: [Discussion] Persistence compatibility framework refactoring

[Dmitriy Pavlov]

Just a reminder: Veto is valid with justification. I see no reasons either
(need some time to dive into details), but it is not a reason for a veto.

ср, 20 февр. 2019 г. в 16:39, Anton Vinogradov :

> Dmitriy,
>
> Please stop chilling community :)
> No one makes final decisions here.
> Please make sure you've got my position before chilling :)
>
> I see no arguments to replace one solution with another.
> In case no real reasons will be provided this merge will gain my Veto, just
> a warning...
>
> On Wed, Feb 20, 2019 at 4:37 PM Nikolay Izhikov 
> wrote:
>
> > Dmitriy,
> >
> > > So I suggest chilling a couple of days without any discussion.
> >
> > Why you trying to stop regular, positive dev-list discussion?
> >
> > I think, we should have a strong reason to throw away some subsystem and
> > completely rewrite it.
> > We will damage product robustness with it.
> >
> > >> 1. Automatic tests scaling for new versions.
> > >> 2. Automatic dependency management.
> >
> > This features needed by Ignite, for sure.
> > Pavel, can we extend current solution with new framework features?
> >
> >
> >
> > ср, 20 февр. 2019 г. в 16:23, Dmitriy Pavlov :
> >
> > > Hi, please do not rush to make any final decision. I think we all need
> > some
> > > time to think about these 2 solutions.
> > >
> > > So I suggest chilling a couple of days without any discussion.
> > >
> > > Later we can come back to this topic and dive into it once again, maybe
> > we
> > > can merge it into one taking the best parts of both.
> > >
> > > ср, 20 февр. 2019 г. в 16:07, Anton Vinogradov :
> > >
> > > > >> 1. Automatic tests scaling for new versions.
> > > > >> 2. Automatic dependency management.
> > > > Let's just improve the current solution.
> > > > See no problems here.
> > > >
> > > > You'll have my *Veto* on merge without real reasons to replace
> solution
> > > > instead of improvement.
> > > >
> > > > On Wed, Feb 20, 2019 at 3:55 PM Pavel Kovalenko 
> > > > wrote:
> > > >
> > > > > Anton,
> > > > >
> > > > > In my first message, I already noticed the usability problems of
> the
> > > > > current framework and showed how they can be solved using the new
> > > > > framework.
> > > > > It gives us 2 major advantages:
> > > > > 1. Automatic tests scaling for new versions.
> > > > > 2. Automatic dependency management.
> > > > > Described approach simplifies tests writing and supporting.
> > > > >
> > > > > I don't see now how we can avoid manual versions adding and
> > supporting
> > > in
> > > > > test suites and avoid manual dependency management using custom
> java
> > > api
> > > > > for Maven in the current version of the framework.
> > > > > If you have ideas how these problems can be resolved in the current
> > > > version
> > > > > please share it.
> > > > >
> > > > > Nikolay,
> > > > >
> > > > > The new framework is designed for persistence compatibility first
> but
> > > can
> > > > > be used for thin client testing as well.
> > > > > It works exactly as you described. It collects all available
> testing
> > > > > versions by scanning pom files. Then it builds jars for all old
> > > versions
> > > > > using Maven.
> > > > > Test framework run compatibility tests against all detected old
> > > versions.
> > > > > The number of versions to test is controlled by a property.
> > > > > Some versions can be excluded for particular test suite or the user
> > can
> > > > > bound it using versions range.
> > > > > In all of these cases, there are no needs to copy-paste methods for
> > > each
> > > > of
> > > > > testing Ignite versions.
> > > > >
> > > > > ср, 20 февр. 2019 г. в 12:45, Nikolay Izhikov  >:
> > > > >
> > > > > > Hello, Pavel.
> > > > > >
> > > > > > Please, clarify.
> > > > > >
> > > > > > What exactly your new compatibility framework should check?
> > > > > > I know at lease 2 compatible subsystem in Ignite that should work
> > > with
> > > > > > previous versions:
> > > > > >
> > > > > > 1. Persistence.
> > > > > > 2. Thin client.
> > > > > >
> > > > > > > A new version of Ignite has released and a developer should
> > update
> > > > > > compatibility tests to run it against the new version.
> > > > > >
> > > > > > I propose to change current approach - check version X with
> version
> > > Y.
> > > > > > We should check X with X - 1 with X - 2 and so on, depending on
> our
> > > > > > compatibility policies.
> > > > > >
> > > > > > This approach should lead to the following:
> > > > > >
> > > > > > 1. Tests should contains only number of previous versions we
> should
> > > > > check.
> > > > > > 2. Test framework should build versions list internally and use
> it
> > to
> > > > run
> > > > > > tests.
> > > > > >
> > > > > > What do you think?
> > > > > >
> > > > > >
> > > > > >
> > > > > > ср, 20 февр. 2019 г. в 11:41, Pavel Kovalenko <
> jokse...@gmail.com
> > >:
> > > > > >
> > > > > > > Vyacheslav,
> > > > > > >
> > > > > > > Thank you for answers!
> > > > > > >
> > > > > > > >> I'm not sure what is a problem here?
> 

Re: [Discussion] Persistence compatibility framework refactoring

[Anton Vinogradov]

Dmitriy,

Please stop chilling community :)
No one makes final decisions here.
Please make sure you've got my position before chilling :)

I see no arguments to replace one solution with another.
In case no real reasons will be provided this merge will gain my Veto, just
a warning...

On Wed, Feb 20, 2019 at 4:37 PM Nikolay Izhikov  wrote:

> Dmitriy,
>
> > So I suggest chilling a couple of days without any discussion.
>
> Why you trying to stop regular, positive dev-list discussion?
>
> I think, we should have a strong reason to throw away some subsystem and
> completely rewrite it.
> We will damage product robustness with it.
>
> >> 1. Automatic tests scaling for new versions.
> >> 2. Automatic dependency management.
>
> This features needed by Ignite, for sure.
> Pavel, can we extend current solution with new framework features?
>
>
>
> ср, 20 февр. 2019 г. в 16:23, Dmitriy Pavlov :
>
> > Hi, please do not rush to make any final decision. I think we all need
> some
> > time to think about these 2 solutions.
> >
> > So I suggest chilling a couple of days without any discussion.
> >
> > Later we can come back to this topic and dive into it once again, maybe
> we
> > can merge it into one taking the best parts of both.
> >
> > ср, 20 февр. 2019 г. в 16:07, Anton Vinogradov :
> >
> > > >> 1. Automatic tests scaling for new versions.
> > > >> 2. Automatic dependency management.
> > > Let's just improve the current solution.
> > > See no problems here.
> > >
> > > You'll have my *Veto* on merge without real reasons to replace solution
> > > instead of improvement.
> > >
> > > On Wed, Feb 20, 2019 at 3:55 PM Pavel Kovalenko 
> > > wrote:
> > >
> > > > Anton,
> > > >
> > > > In my first message, I already noticed the usability problems of the
> > > > current framework and showed how they can be solved using the new
> > > > framework.
> > > > It gives us 2 major advantages:
> > > > 1. Automatic tests scaling for new versions.
> > > > 2. Automatic dependency management.
> > > > Described approach simplifies tests writing and supporting.
> > > >
> > > > I don't see now how we can avoid manual versions adding and
> supporting
> > in
> > > > test suites and avoid manual dependency management using custom java
> > api
> > > > for Maven in the current version of the framework.
> > > > If you have ideas how these problems can be resolved in the current
> > > version
> > > > please share it.
> > > >
> > > > Nikolay,
> > > >
> > > > The new framework is designed for persistence compatibility first but
> > can
> > > > be used for thin client testing as well.
> > > > It works exactly as you described. It collects all available testing
> > > > versions by scanning pom files. Then it builds jars for all old
> > versions
> > > > using Maven.
> > > > Test framework run compatibility tests against all detected old
> > versions.
> > > > The number of versions to test is controlled by a property.
> > > > Some versions can be excluded for particular test suite or the user
> can
> > > > bound it using versions range.
> > > > In all of these cases, there are no needs to copy-paste methods for
> > each
> > > of
> > > > testing Ignite versions.
> > > >
> > > > ср, 20 февр. 2019 г. в 12:45, Nikolay Izhikov :
> > > >
> > > > > Hello, Pavel.
> > > > >
> > > > > Please, clarify.
> > > > >
> > > > > What exactly your new compatibility framework should check?
> > > > > I know at lease 2 compatible subsystem in Ignite that should work
> > with
> > > > > previous versions:
> > > > >
> > > > > 1. Persistence.
> > > > > 2. Thin client.
> > > > >
> > > > > > A new version of Ignite has released and a developer should
> update
> > > > > compatibility tests to run it against the new version.
> > > > >
> > > > > I propose to change current approach - check version X with version
> > Y.
> > > > > We should check X with X - 1 with X - 2 and so on, depending on our
> > > > > compatibility policies.
> > > > >
> > > > > This approach should lead to the following:
> > > > >
> > > > > 1. Tests should contains only number of previous versions we should
> > > > check.
> > > > > 2. Test framework should build versions list internally and use it
> to
> > > run
> > > > > tests.
> > > > >
> > > > > What do you think?
> > > > >
> > > > >
> > > > >
> > > > > ср, 20 февр. 2019 г. в 11:41, Pavel Kovalenko  >:
> > > > >
> > > > > > Vyacheslav,
> > > > > >
> > > > > > Thank you for answers!
> > > > > >
> > > > > > >> I'm not sure what is a problem here?
> > > > > > At the moment it's a little bit hard to understand the impact of
> > > such a
> > > > > > change because the number of test suites is small.
> > > > > > Let's Imagine you have X compatibility test suites where X is a
> > > > > relatively
> > > > > > big number, let's say 20.
> > > > > > A new version of Ignite has released and a developer should
> update
> > > > > > compatibility tests to run it against the new version.
> > > > > > A developer should manually find all of these 20 test suites and
> in
> > 

Re: [Discussion] Persistence compatibility framework refactoring

[Nikolay Izhikov]

Dmitriy,

> So I suggest chilling a couple of days without any discussion.

Why you trying to stop regular, positive dev-list discussion?

I think, we should have a strong reason to throw away some subsystem and
completely rewrite it.
We will damage product robustness with it.

>> 1. Automatic tests scaling for new versions.
>> 2. Automatic dependency management.

This features needed by Ignite, for sure.
Pavel, can we extend current solution with new framework features?



ср, 20 февр. 2019 г. в 16:23, Dmitriy Pavlov :

> Hi, please do not rush to make any final decision. I think we all need some
> time to think about these 2 solutions.
>
> So I suggest chilling a couple of days without any discussion.
>
> Later we can come back to this topic and dive into it once again, maybe we
> can merge it into one taking the best parts of both.
>
> ср, 20 февр. 2019 г. в 16:07, Anton Vinogradov :
>
> > >> 1. Automatic tests scaling for new versions.
> > >> 2. Automatic dependency management.
> > Let's just improve the current solution.
> > See no problems here.
> >
> > You'll have my *Veto* on merge without real reasons to replace solution
> > instead of improvement.
> >
> > On Wed, Feb 20, 2019 at 3:55 PM Pavel Kovalenko 
> > wrote:
> >
> > > Anton,
> > >
> > > In my first message, I already noticed the usability problems of the
> > > current framework and showed how they can be solved using the new
> > > framework.
> > > It gives us 2 major advantages:
> > > 1. Automatic tests scaling for new versions.
> > > 2. Automatic dependency management.
> > > Described approach simplifies tests writing and supporting.
> > >
> > > I don't see now how we can avoid manual versions adding and supporting
> in
> > > test suites and avoid manual dependency management using custom java
> api
> > > for Maven in the current version of the framework.
> > > If you have ideas how these problems can be resolved in the current
> > version
> > > please share it.
> > >
> > > Nikolay,
> > >
> > > The new framework is designed for persistence compatibility first but
> can
> > > be used for thin client testing as well.
> > > It works exactly as you described. It collects all available testing
> > > versions by scanning pom files. Then it builds jars for all old
> versions
> > > using Maven.
> > > Test framework run compatibility tests against all detected old
> versions.
> > > The number of versions to test is controlled by a property.
> > > Some versions can be excluded for particular test suite or the user can
> > > bound it using versions range.
> > > In all of these cases, there are no needs to copy-paste methods for
> each
> > of
> > > testing Ignite versions.
> > >
> > > ср, 20 февр. 2019 г. в 12:45, Nikolay Izhikov :
> > >
> > > > Hello, Pavel.
> > > >
> > > > Please, clarify.
> > > >
> > > > What exactly your new compatibility framework should check?
> > > > I know at lease 2 compatible subsystem in Ignite that should work
> with
> > > > previous versions:
> > > >
> > > > 1. Persistence.
> > > > 2. Thin client.
> > > >
> > > > > A new version of Ignite has released and a developer should update
> > > > compatibility tests to run it against the new version.
> > > >
> > > > I propose to change current approach - check version X with version
> Y.
> > > > We should check X with X - 1 with X - 2 and so on, depending on our
> > > > compatibility policies.
> > > >
> > > > This approach should lead to the following:
> > > >
> > > > 1. Tests should contains only number of previous versions we should
> > > check.
> > > > 2. Test framework should build versions list internally and use it to
> > run
> > > > tests.
> > > >
> > > > What do you think?
> > > >
> > > >
> > > >
> > > > ср, 20 февр. 2019 г. в 11:41, Pavel Kovalenko :
> > > >
> > > > > Vyacheslav,
> > > > >
> > > > > Thank you for answers!
> > > > >
> > > > > >> I'm not sure what is a problem here?
> > > > > At the moment it's a little bit hard to understand the impact of
> > such a
> > > > > change because the number of test suites is small.
> > > > > Let's Imagine you have X compatibility test suites where X is a
> > > > relatively
> > > > > big number, let's say 20.
> > > > > A new version of Ignite has released and a developer should update
> > > > > compatibility tests to run it against the new version.
> > > > > A developer should manually find all of these 20 test suites and in
> > > each
> > > > of
> > > > > these suites and add a new version to test it (new method).
> > > > > This is a long process and there could be developer mistakes, some
> of
> > > the
> > > > > test suites can be missed and nobody will know about it before real
> > > > > compatibility problem appears.
> > > > > We already faced with the situation when after new version release
> > > > > (2.5-2.6) no compatibility tests were modified to support new
> version
> > > > > because nobody remembers about it and there is no such process
> after
> > > > > release.
> > > > > Adding new pom is a very simple step and 

Re: [Discussion] Persistence compatibility framework refactoring

[Dmitriy Pavlov]

Hi, please do not rush to make any final decision. I think we all need some
time to think about these 2 solutions.

So I suggest chilling a couple of days without any discussion.

Later we can come back to this topic and dive into it once again, maybe we
can merge it into one taking the best parts of both.

ср, 20 февр. 2019 г. в 16:07, Anton Vinogradov :

> >> 1. Automatic tests scaling for new versions.
> >> 2. Automatic dependency management.
> Let's just improve the current solution.
> See no problems here.
>
> You'll have my *Veto* on merge without real reasons to replace solution
> instead of improvement.
>
> On Wed, Feb 20, 2019 at 3:55 PM Pavel Kovalenko 
> wrote:
>
> > Anton,
> >
> > In my first message, I already noticed the usability problems of the
> > current framework and showed how they can be solved using the new
> > framework.
> > It gives us 2 major advantages:
> > 1. Automatic tests scaling for new versions.
> > 2. Automatic dependency management.
> > Described approach simplifies tests writing and supporting.
> >
> > I don't see now how we can avoid manual versions adding and supporting in
> > test suites and avoid manual dependency management using custom java api
> > for Maven in the current version of the framework.
> > If you have ideas how these problems can be resolved in the current
> version
> > please share it.
> >
> > Nikolay,
> >
> > The new framework is designed for persistence compatibility first but can
> > be used for thin client testing as well.
> > It works exactly as you described. It collects all available testing
> > versions by scanning pom files. Then it builds jars for all old versions
> > using Maven.
> > Test framework run compatibility tests against all detected old versions.
> > The number of versions to test is controlled by a property.
> > Some versions can be excluded for particular test suite or the user can
> > bound it using versions range.
> > In all of these cases, there are no needs to copy-paste methods for each
> of
> > testing Ignite versions.
> >
> > ср, 20 февр. 2019 г. в 12:45, Nikolay Izhikov :
> >
> > > Hello, Pavel.
> > >
> > > Please, clarify.
> > >
> > > What exactly your new compatibility framework should check?
> > > I know at lease 2 compatible subsystem in Ignite that should work with
> > > previous versions:
> > >
> > > 1. Persistence.
> > > 2. Thin client.
> > >
> > > > A new version of Ignite has released and a developer should update
> > > compatibility tests to run it against the new version.
> > >
> > > I propose to change current approach - check version X with version Y.
> > > We should check X with X - 1 with X - 2 and so on, depending on our
> > > compatibility policies.
> > >
> > > This approach should lead to the following:
> > >
> > > 1. Tests should contains only number of previous versions we should
> > check.
> > > 2. Test framework should build versions list internally and use it to
> run
> > > tests.
> > >
> > > What do you think?
> > >
> > >
> > >
> > > ср, 20 февр. 2019 г. в 11:41, Pavel Kovalenko :
> > >
> > > > Vyacheslav,
> > > >
> > > > Thank you for answers!
> > > >
> > > > >> I'm not sure what is a problem here?
> > > > At the moment it's a little bit hard to understand the impact of
> such a
> > > > change because the number of test suites is small.
> > > > Let's Imagine you have X compatibility test suites where X is a
> > > relatively
> > > > big number, let's say 20.
> > > > A new version of Ignite has released and a developer should update
> > > > compatibility tests to run it against the new version.
> > > > A developer should manually find all of these 20 test suites and in
> > each
> > > of
> > > > these suites and add a new version to test it (new method).
> > > > This is a long process and there could be developer mistakes, some of
> > the
> > > > test suites can be missed and nobody will know about it before real
> > > > compatibility problem appears.
> > > > We already faced with the situation when after new version release
> > > > (2.5-2.6) no compatibility tests were modified to support new version
> > > > because nobody remembers about it and there is no such process after
> > > > release.
> > > > Adding new pom is a very simple step and can be done by any human who
> > > even
> > > > may not be familiar with the compatibility module and may not know
> > > anything
> > > > which compatibility tests are used. If we include adding pom file to
> > > > post-release process all existing tests will automatically detect new
> > > > version and next TC run will immediately show to us results. If there
> > are
> > > > some compatibility problems during development new version TC run
> will
> > > show
> > > > it. At the current approach, compatibility tests are out of focus and
> > we
> > > > may not see potential issues.
> > > >
> > > > >> This is not about usability, it's about the framework's internals
> > > > At the current approach, a developer should take care of dependency
> > > > management for 

Would like to work on IGNITE-11369

[ankit singh]

Hi,
As newbie to Apache ingnite Dev, I would like to work on following jira.

IGNITE-11369

Re: [Discussion] Persistence compatibility framework refactoring

[Anton Vinogradov]

>> 1. Automatic tests scaling for new versions.
>> 2. Automatic dependency management.
Let's just improve the current solution.
See no problems here.

You'll have my *Veto* on merge without real reasons to replace solution
instead of improvement.

On Wed, Feb 20, 2019 at 3:55 PM Pavel Kovalenko  wrote:

> Anton,
>
> In my first message, I already noticed the usability problems of the
> current framework and showed how they can be solved using the new
> framework.
> It gives us 2 major advantages:
> 1. Automatic tests scaling for new versions.
> 2. Automatic dependency management.
> Described approach simplifies tests writing and supporting.
>
> I don't see now how we can avoid manual versions adding and supporting in
> test suites and avoid manual dependency management using custom java api
> for Maven in the current version of the framework.
> If you have ideas how these problems can be resolved in the current version
> please share it.
>
> Nikolay,
>
> The new framework is designed for persistence compatibility first but can
> be used for thin client testing as well.
> It works exactly as you described. It collects all available testing
> versions by scanning pom files. Then it builds jars for all old versions
> using Maven.
> Test framework run compatibility tests against all detected old versions.
> The number of versions to test is controlled by a property.
> Some versions can be excluded for particular test suite or the user can
> bound it using versions range.
> In all of these cases, there are no needs to copy-paste methods for each of
> testing Ignite versions.
>
> ср, 20 февр. 2019 г. в 12:45, Nikolay Izhikov :
>
> > Hello, Pavel.
> >
> > Please, clarify.
> >
> > What exactly your new compatibility framework should check?
> > I know at lease 2 compatible subsystem in Ignite that should work with
> > previous versions:
> >
> > 1. Persistence.
> > 2. Thin client.
> >
> > > A new version of Ignite has released and a developer should update
> > compatibility tests to run it against the new version.
> >
> > I propose to change current approach - check version X with version Y.
> > We should check X with X - 1 with X - 2 and so on, depending on our
> > compatibility policies.
> >
> > This approach should lead to the following:
> >
> > 1. Tests should contains only number of previous versions we should
> check.
> > 2. Test framework should build versions list internally and use it to run
> > tests.
> >
> > What do you think?
> >
> >
> >
> > ср, 20 февр. 2019 г. в 11:41, Pavel Kovalenko :
> >
> > > Vyacheslav,
> > >
> > > Thank you for answers!
> > >
> > > >> I'm not sure what is a problem here?
> > > At the moment it's a little bit hard to understand the impact of such a
> > > change because the number of test suites is small.
> > > Let's Imagine you have X compatibility test suites where X is a
> > relatively
> > > big number, let's say 20.
> > > A new version of Ignite has released and a developer should update
> > > compatibility tests to run it against the new version.
> > > A developer should manually find all of these 20 test suites and in
> each
> > of
> > > these suites and add a new version to test it (new method).
> > > This is a long process and there could be developer mistakes, some of
> the
> > > test suites can be missed and nobody will know about it before real
> > > compatibility problem appears.
> > > We already faced with the situation when after new version release
> > > (2.5-2.6) no compatibility tests were modified to support new version
> > > because nobody remembers about it and there is no such process after
> > > release.
> > > Adding new pom is a very simple step and can be done by any human who
> > even
> > > may not be familiar with the compatibility module and may not know
> > anything
> > > which compatibility tests are used. If we include adding pom file to
> > > post-release process all existing tests will automatically detect new
> > > version and next TC run will immediately show to us results. If there
> are
> > > some compatibility problems during development new version TC run will
> > show
> > > it. At the current approach, compatibility tests are out of focus and
> we
> > > may not see potential issues.
> > >
> > > >> This is not about usability, it's about the framework's internals
> > > At the current approach, a developer should take care of dependency
> > > management for the old versions. E.g. if you look
> > > at IgnitePKIndexesMigrationToUnwrapPkTest you can see "magic" H2
> > dependency
> > > version. I still don't understand why this version was explicitly added
> > and
> > > not just inherited from ignite-indexing. If we delegate all dependency
> > > management to Maven itself it will simplify tests development. Tests
> will
> > > look much simpler.
> > >
> > > >> Please, describe the issue in more details?
> > > Suppose you have a closure that invokes some deprecated method which
> will
> > > be removed in next release. After method removal, such tests 

Re: [Discussion] Persistence compatibility framework refactoring

[Pavel Kovalenko]

Anton,

In my first message, I already noticed the usability problems of the
current framework and showed how they can be solved using the new framework.
It gives us 2 major advantages:
1. Automatic tests scaling for new versions.
2. Automatic dependency management.
Described approach simplifies tests writing and supporting.

I don't see now how we can avoid manual versions adding and supporting in
test suites and avoid manual dependency management using custom java api
for Maven in the current version of the framework.
If you have ideas how these problems can be resolved in the current version
please share it.

Nikolay,

The new framework is designed for persistence compatibility first but can
be used for thin client testing as well.
It works exactly as you described. It collects all available testing
versions by scanning pom files. Then it builds jars for all old versions
using Maven.
Test framework run compatibility tests against all detected old versions.
The number of versions to test is controlled by a property.
Some versions can be excluded for particular test suite or the user can
bound it using versions range.
In all of these cases, there are no needs to copy-paste methods for each of
testing Ignite versions.

ср, 20 февр. 2019 г. в 12:45, Nikolay Izhikov :

> Hello, Pavel.
>
> Please, clarify.
>
> What exactly your new compatibility framework should check?
> I know at lease 2 compatible subsystem in Ignite that should work with
> previous versions:
>
> 1. Persistence.
> 2. Thin client.
>
> > A new version of Ignite has released and a developer should update
> compatibility tests to run it against the new version.
>
> I propose to change current approach - check version X with version Y.
> We should check X with X - 1 with X - 2 and so on, depending on our
> compatibility policies.
>
> This approach should lead to the following:
>
> 1. Tests should contains only number of previous versions we should check.
> 2. Test framework should build versions list internally and use it to run
> tests.
>
> What do you think?
>
>
>
> ср, 20 февр. 2019 г. в 11:41, Pavel Kovalenko :
>
> > Vyacheslav,
> >
> > Thank you for answers!
> >
> > >> I'm not sure what is a problem here?
> > At the moment it's a little bit hard to understand the impact of such a
> > change because the number of test suites is small.
> > Let's Imagine you have X compatibility test suites where X is a
> relatively
> > big number, let's say 20.
> > A new version of Ignite has released and a developer should update
> > compatibility tests to run it against the new version.
> > A developer should manually find all of these 20 test suites and in each
> of
> > these suites and add a new version to test it (new method).
> > This is a long process and there could be developer mistakes, some of the
> > test suites can be missed and nobody will know about it before real
> > compatibility problem appears.
> > We already faced with the situation when after new version release
> > (2.5-2.6) no compatibility tests were modified to support new version
> > because nobody remembers about it and there is no such process after
> > release.
> > Adding new pom is a very simple step and can be done by any human who
> even
> > may not be familiar with the compatibility module and may not know
> anything
> > which compatibility tests are used. If we include adding pom file to
> > post-release process all existing tests will automatically detect new
> > version and next TC run will immediately show to us results. If there are
> > some compatibility problems during development new version TC run will
> show
> > it. At the current approach, compatibility tests are out of focus and we
> > may not see potential issues.
> >
> > >> This is not about usability, it's about the framework's internals
> > At the current approach, a developer should take care of dependency
> > management for the old versions. E.g. if you look
> > at IgnitePKIndexesMigrationToUnwrapPkTest you can see "magic" H2
> dependency
> > version. I still don't understand why this version was explicitly added
> and
> > not just inherited from ignite-indexing. If we delegate all dependency
> > management to Maven itself it will simplify tests development. Tests will
> > look much simpler.
> >
> > >> Please, describe the issue in more details?
> > Suppose you have a closure that invokes some deprecated method which will
> > be removed in next release. After method removal, such tests will be
> > broken. At the current framework, I can't see a resolution of that
> problem.
> > In a new framework, you can keep the old version of closure, mark it with
> > special annotation and place to separate module with old Ignite version
> > dependency. This closure will be compiled using an old version of Ignite
> > and the user can still run it on the old version.
> >
> >
> >
> > вт, 19 февр. 2019 г. в 21:44, Vyacheslav Daradur :
> >
> > > Hi, Pavel!
> > >
> > > First of all, I'd like to clarify that the Compatibility 

[jira] [Created] (IGNITE-11370) Doc: remove SqlQuery documentation

[Taras Ledkov (JIRA)]

Taras Ledkov created IGNITE-11370:
-

 Summary: Doc: remove SqlQuery documentation
 Key: IGNITE-11370
 URL: https://issues.apache.org/jira/browse/IGNITE-11370
 Project: Ignite
  Issue Type: Task
  Components: documentation
Affects Versions: 2.7
Reporter: Taras Ledkov
Assignee: Artem Budnikov
 Fix For: 2.8


Please remove [SqlQuery 
section|https://apacheignite-sql.readme.io/docs/java-sql-api#section-sqlquery} 
from documentation.



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

[jira] [Created] (IGNITE-11369) Remove H2 console form documentation

[Taras Ledkov (JIRA)]

Taras Ledkov created IGNITE-11369:
-

 Summary: Remove H2 console form documentation
 Key: IGNITE-11369
 URL: https://issues.apache.org/jira/browse/IGNITE-11369
 Project: Ignite
  Issue Type: Task
  Components: documentation
Affects Versions: 2.7
Reporter: Taras Ledkov
 Fix For: 2.8


Please remove the [H2 
console|https://apacheignite-sql.readme.io/docs/performance-and-debugging#using-h2-debug-console]
 section from documentation.



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

[jira] [Created] (IGNITE-11368) use the same information about indexes for ODBC JDBC drivers as for system view INDEXES

[Yury Gerzhedovich (JIRA)]

Yury Gerzhedovich created IGNITE-11368:
--

 Summary: use the same information about indexes for ODBC JDBC 
drivers as for system view INDEXES
 Key: IGNITE-11368
 URL: https://issues.apache.org/jira/browse/IGNITE-11368
 Project: Ignite
  Issue Type: Task
  Components: jdbc, odbc, sql
Reporter: Yury Gerzhedovich
 Fix For: 2.8


As of now indexes information for ODBC/JDBC drivers get by another way then 
system SQL view INDEXES. Need to use single source of the information to have 
consistent picture.

So, ODBC/JDBC drivers should use the same source as SQL view INDEXES 
(org.apache.ignite.internal.processors.query.h2.sys.view.SqlSystemViewIndexes)



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

[Review needed] IGNITE-11299 During SSL Handshake GridNioServer.processWrite is invoked constantly

[Dmitriy Pavlov]

Hi Igniters,

Grid NIO server experts review needed for issue
https://issues.apache.org/jira/browse/IGNITE-11299

It is an issue for Ignite to be run under Java 11 & Windows.

Sincerely,
Dmitriy Pavlov

Re: Python examples are missing in Ignite 2.7

[Stepan Pilschikov]

Denis, Dmitry

Found that https://issues.apache.org/jira/browse/IGNITE-9922
Release process just do not copy this folder
And this directory do not copy because of Dmitry concerns described earlier

Agreed with Denis that examples folder should be in release build because
of:
- they really help to understand how client work
- they understandable enough even without documentation
- actually they contain link on examples documentation on readthedocs.io
- others clients have common structure (examples, lib, README.md, artifacts
to install package) but python client have not

Dmitry talk about PyPI package which is should not contain any redundant
files and i agreed with him
But Denis talk only about apache-ignite release build binaries

Also found https://issues.apache.org/jira/browse/IGNITE-10683
Don't know how new folder is affected on release procedure of PyPi package
because ignite do not have fully automated pypi package release process, i
told only about release binaries

I've open new ticket to add examples in release build:
https://issues.apache.org/jira/browse/IGNITE-11366

Dmitry, if you have any objections or improvements for this process you can
described theys in ticket

чт, 14 февр. 2019 г. в 21:21, Denis Magda :

> Dmitry,
>
> Thanks for looking into this. I think that something went wrong with our
> release procedure and we forgot to include the "examples" folder in Ignite
> binary package. Sergey K. is checking the release procedures.
>
>
> -
> Denis
>
>
> On Tue, Feb 12, 2019 at 7:28 PM Dmitry Melnichuk <
> dmitry.melnic...@nobitlost.com> wrote:
>
> > We just browse through the contents of the latest Ignite bundles [1].
> >
> > Source bundle [2] contains the examples all right; they are in this
> > folder:
> >
> > /apache-ignite-2.7.0-src/modules/platforms/python/examples/
> >
> > Binary bundle [3] do not contain examples. I'm not totally sure, but
> > the reasoning I gave earlier might apply to binary bundle too.
> >
> > Can anyone who's aware of the bundling procedure/scripts chime in,
> > please?
> >
> > [1] https://ignite.apache.org/download.cgi
> >
> > [2]
> >
> >
> http://mirrors.standaloneinstaller.com/apache//ignite/2.7.0/apache-ignite-2.7.0-src.zip
> >
> > [3]
> >
> >
> http://mirrors.standaloneinstaller.com/apache//ignite/2.7.0/apache-ignite-2.7.0-bin.zip
> >
> > On Wed, 2019-02-13 at 12:49 +1000, Dmitry Melnichuk wrote:
> > > Denis,
> > >
> > > If by “release procedure” you mean the contents of the PyPI package,
> > > then it is not a bug, but a deliberate decision, that was documented
> > > in
> > > README [1]:
> > >
> > > > Installation
> > > > 
> > > > - for end user
> > > >
> > > > If you only want to use the pyignite module in your project, do:
> > > >
> > > > $ pip install pyignite
> > > >
> > > > -- for developer
> > > >
> > > > If you want to run tests, examples or build documentation, clone
> > > > the
> > > > whole repository…
> > >
> > > The reasoning:
> > >
> > > 1. The examples do not have much value by themselves. They are useful
> > > only in conjunction with the documentation. If we do not ship the
> > > documentation via PyPI, then we should not ship the examples either.
> > >
> > > 2. In production environment, the extra packaged stuff like examples
> > > will be just a waste of space.
> > >
> > > 3. Most Python libraries and frameworks I know of, e.g. Django or
> > > Scrapy, use the same approach: they have examples and test apps in
> > > the
> > > repository and reference them through their docs, but do not ship
> > > them
> > > via PyPI.
> > >
> > > [1]
> > >
> >
> https://github.com/apache/ignite/tree/master/modules/platforms/python#installation
> > >
> > > On Tue, 2019-02-12 at 16:23 -0800, Denis Magda wrote:
> > > > Igniters,
> > > >
> > > > Seems python examples were not added to the release bundle?
> > > >
> >
> https://apacheignite.readme.io/v2.7/docs/python-thin-client#section-running-an-example
> > > >
> > > > There is no "examples" folder for Python. Any flaws in the release
> > > > procedure?
> > > >
> > > > -
> > > > Denis
> >
> >
>

[jira] [Created] (IGNITE-11367) Fix several issues in PageMemoryTracker

[Ivan Rakov (JIRA)]

Ivan Rakov created IGNITE-11367:
---

 Summary: Fix several issues in PageMemoryTracker
 Key: IGNITE-11367
 URL: https://issues.apache.org/jira/browse/IGNITE-11367
 Project: Ignite
  Issue Type: Bug
Reporter: Ivan Rakov
 Fix For: 2.8


I've discovered some issues in PageMemoryTracker while debugging IGNITE-10873:
1) Mock page memory doesn't implement PageMemoryImpl#pageBuffer. As a result, 
some delta records (which applies changes via buffer) can't be applied. Example:
{code:java}
Caused by: java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.cache.persistence.tree.io.TrackingPageIO.getLastSnapshotTag0(TrackingPageIO.java:235)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.io.TrackingPageIO.getLastSnapshotTag(TrackingPageIO.java:227)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.io.TrackingPageIO.validateSnapshotTag(TrackingPageIO.java:135)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.io.TrackingPageIO.markChanged(TrackingPageIO.java:93)
at 
org.apache.ignite.internal.pagemem.wal.record.delta.TrackingPageDeltaRecord.applyDelta(TrackingPageDeltaRecord.java:75)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.memtracker.PageMemoryTracker.applyWalRecord(PageMemoryTracker.java:447)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.memtracker.PageMemoryTracker.access$000(PageMemoryTracker.java:81)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.memtracker.PageMemoryTracker$1.log(PageMemoryTracker.java:159)
at 
org.gridgain.grid.internal.processors.cache.database.snapshot.GridCacheSnapshotManager.onChangeTrackerPage(GridCacheSnapshotManager.java:2801)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$5.applyx(GridCacheDatabaseSharedManager.java:1084)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$5.applyx(GridCacheDatabaseSharedManager.java:1077)
at 
org.apache.ignite.internal.util.lang.GridInClosure3X.apply(GridInClosure3X.java:34)
at 
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.writeUnlockPage(PageMemoryImpl.java:1572)
at 
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.writeUnlock(PageMemoryImpl.java:495)
at 
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.writeUnlock(PageMemoryImpl.java:487)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.writeUnlock(PageHandler.java:394)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.writePage(PageHandler.java:369)
at 
org.apache.ignite.internal.processors.cache.persistence.DataStructure.write(DataStructure.java:285)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.access$11500(BPlusTree.java:92)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.tryReplace(BPlusTree.java:3638)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putDown(BPlusTree.java:2565)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2293)
... 33 more
{code}
2) During binary recovery phase, page memory is changed with applying delta 
records and page snapshots (GridCacheDatabaseSharedManager#applyPageDelta, 
#applyPageSnapshot). Such changes are not replicated by logging delta records 
to WAL (we don't log physical records on binary recovery - we just apply 
already logged ones). This leads to false positive broken consistency reports. 
To prevent this, we should apply changes to both regular page memory and mock 
page memory in PageMemoryTracker.
3) PagesList.java:918:
{code:java}
// Here we should never write full page, because it is 
known to be new.
if (needWalDeltaRecord(nextId, nextPage, FALSE))
wal.log(new PagesListInitNewPageRecord(
grpId,
nextId,
io.getType(),
io.getVersion(),
nextId,
prevId,
0L
));
{code}

[jira] [Created] (IGNITE-11366) python thin client: add python examples in release build

[Stepan Pilschikov (JIRA)]

Stepan Pilschikov created IGNITE-11366:
--

 Summary: python thin client: add python examples in release build
 Key: IGNITE-11366
 URL: https://issues.apache.org/jira/browse/IGNITE-11366
 Project: Ignite
  Issue Type: Improvement
Affects Versions: 2.7
Reporter: Stepan Pilschikov


Examples directory should be added in release build because they exists in 
sources and they really help to understand how to work with this client

I think they understandable enough for end user

Also they have readme.md which is contain link on examples documentation



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

[jira] [Created] (IGNITE-11365) Partition sizes differ after streaming with allowOverwrite=false with concurrent PME

[Stanislav Lukyanov (JIRA)]

Stanislav Lukyanov created IGNITE-11365:
---

 Summary: Partition sizes differ after streaming with 
allowOverwrite=false with concurrent PME
 Key: IGNITE-11365
 URL: https://issues.apache.org/jira/browse/IGNITE-11365
 Project: Ignite
  Issue Type: Improvement
Reporter: Stanislav Lukyanov
 Attachments: DataStreamerRebalanceMissingDocTest.java

Scenario
- Start 3 nodes
- Run N threads, each thread starts a replicated cache and then streams data to 
that cache with allowOverwrite=false

During the streaming there are "Partition validation failed" warnings.
After the streaming in all threads ends, some caches have incorrect size and 
local SQL queries return less data.

Seems that PME can break an ongoing streaming with allowOverwrite=false.
allowOverwrite=true is a workaround.

Reproducer is attached.



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

[jira] [Created] (IGNITE-11364) Segmenting node can cause ring topology broke

[Ivan Daschinskiy (JIRA)]

Ivan Daschinskiy created IGNITE-11364:
-

 Summary: Segmenting node can cause ring topology broke
 Key: IGNITE-11364
 URL: https://issues.apache.org/jira/browse/IGNITE-11364
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.7, 2.6, 2.5
Reporter: Ivan Daschinskiy
 Fix For: 2.8


While segmenting by partial network drop, i.e. by applying iptables rules, can 
cause ring broke.
Scenario:
On each machine there are two nodes, client and server respectivelly.

Lets draw diagram (only server nodes for brevity, they have been started before 
clients).

=> grid915 => ... => grid947 => grid945 => grid703 => ..skip 12 nodes...=> 
grid952 => grid946.
On grid945 machine we drop incoming/outgoing connections by iptables.

During ongoing drop of connection, grid945 send TcpDiscoveryStatusCheckMessage, 
but cannot send them to grid703 and others mentioned above 12 nodes, but some 
next node accepted it with collection of failedNodes (13 nodes above). This 
message was received by grid947 and it skip these 13 nodes in 
org.apache.ignite.spi.discovery.tcp.ServerImpl.RingMessageWorker#sendMessageAcrossRing.

So we see this situation in topology:

.. => grid947 => grid952
 ^ 
//
grid703=>=>grid662

These nodes are not considere by topology as failed.


 









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

Re: [Discussion] Persistence compatibility framework refactoring

[Nikolay Izhikov]

Hello, Pavel.

Please, clarify.

What exactly your new compatibility framework should check?
I know at lease 2 compatible subsystem in Ignite that should work with
previous versions:

1. Persistence.
2. Thin client.

> A new version of Ignite has released and a developer should update
compatibility tests to run it against the new version.

I propose to change current approach - check version X with version Y.
We should check X with X - 1 with X - 2 and so on, depending on our
compatibility policies.

This approach should lead to the following:

1. Tests should contains only number of previous versions we should check.
2. Test framework should build versions list internally and use it to run
tests.

What do you think?



ср, 20 февр. 2019 г. в 11:41, Pavel Kovalenko :

> Vyacheslav,
>
> Thank you for answers!
>
> >> I'm not sure what is a problem here?
> At the moment it's a little bit hard to understand the impact of such a
> change because the number of test suites is small.
> Let's Imagine you have X compatibility test suites where X is a relatively
> big number, let's say 20.
> A new version of Ignite has released and a developer should update
> compatibility tests to run it against the new version.
> A developer should manually find all of these 20 test suites and in each of
> these suites and add a new version to test it (new method).
> This is a long process and there could be developer mistakes, some of the
> test suites can be missed and nobody will know about it before real
> compatibility problem appears.
> We already faced with the situation when after new version release
> (2.5-2.6) no compatibility tests were modified to support new version
> because nobody remembers about it and there is no such process after
> release.
> Adding new pom is a very simple step and can be done by any human who even
> may not be familiar with the compatibility module and may not know anything
> which compatibility tests are used. If we include adding pom file to
> post-release process all existing tests will automatically detect new
> version and next TC run will immediately show to us results. If there are
> some compatibility problems during development new version TC run will show
> it. At the current approach, compatibility tests are out of focus and we
> may not see potential issues.
>
> >> This is not about usability, it's about the framework's internals
> At the current approach, a developer should take care of dependency
> management for the old versions. E.g. if you look
> at IgnitePKIndexesMigrationToUnwrapPkTest you can see "magic" H2 dependency
> version. I still don't understand why this version was explicitly added and
> not just inherited from ignite-indexing. If we delegate all dependency
> management to Maven itself it will simplify tests development. Tests will
> look much simpler.
>
> >> Please, describe the issue in more details?
> Suppose you have a closure that invokes some deprecated method which will
> be removed in next release. After method removal, such tests will be
> broken. At the current framework, I can't see a resolution of that problem.
> In a new framework, you can keep the old version of closure, mark it with
> special annotation and place to separate module with old Ignite version
> dependency. This closure will be compiled using an old version of Ignite
> and the user can still run it on the old version.
>
>
>
> вт, 19 февр. 2019 г. в 21:44, Vyacheslav Daradur :
>
> > Hi, Pavel!
> >
> > First of all, I'd like to clarify that the Compatibility Testing
> > Framework was designed to work with a cluster of multi-version nodes.
> > The main idea is to run a test to verify backward compatibility or do
> > some kind of rolling upgrades.
> >
> > It's not about persistence compatibility, but actually, it is used for
> > this now.
> >
> > >> 1) It's uncomfortable to add and support new versions of Ignite
> product.
> >
> > I'm not sure what is a problem here?
> > As I understand you suggest to do similar things - adding new pom.xml
> > when new a version is released. Pay attention that not all tests
> > should be tested on all versions, some test may want to test specific
> > versions each other.
> >
> > >> 2) Manual maven dependency through java api.
> >
> > This is not about usability, it's about the framework's internals. If
> > you have issues let's fix it and improve approach if needed.
> >
> > >> 3) It doesn't cover the case when some code which works on the current
> > version will not work on older versions due to compile/runtime
> > incompatibility.
> >
> > Please, describe the issue in more details?
> >
> > On Tue, Feb 19, 2019 at 7:55 PM Pavel Kovalenko 
> > wrote:
> > >
> > > Anton,
> > >
> > > >> What about the current compatibility framework?
> > > Current compatibility framework will be removed after final adjusting
> to
> > > new framework.
> > >
> > > >> Could you please share examples for each feature you mentioned?
> > > You can see example in PR e.g. file
> > > 

Re: UriDeploymentSpi and GAR files

[Nikolay Izhikov]

Hello, Denis.

> This XML may contain task descriptors, but I couldn't find any
documentation on this format.
> This information can be provided in simple JAR files with the same file
structure.

I support you proposal. Let's:

1. Support jar files instead of gar.
2. Write down documentation about XML config format.
3. Provide some examples.

Can you crate a tickets for it?


ср, 20 февр. 2019 г. в 11:49, Denis Mekhanikov :

> Denis,
>
> This XML may contain task descriptors, but I couldn't find any
> documentation on this format.
> Also it may contain a userVersion [1] parameter, which can be used to force
> tasks redeployment in some cases.
>
> This information can be provided in simple JAR files with the same file
> structure.
> There is no need to confuse people and require their packages to have a GAR
> extension.
>
> Also if you don't specify the task descriptors, then all tasks in the file
> will be registered.
> So, I doubt, that anybody will bother specifying the descriptors. XML is
> not very user-friendly.
> This piece of configuration doesn't seem necessary to me.
>
> [1]
>
> https://apacheignite.readme.io/docs/deployment-modes#section-un-deployment-and-user-versions
>
> Denis
>
> ср, 20 февр. 2019 г. в 01:35, Denis Magda :
>
> > Denis,
> >
> > What was the purpose of having XML and other files within the GARs? Guess
> > it was somehow versioning related - you might have several tasks of the
> > same class but different versions running in a cluster.
> >
> > -
> > Denis
> >
> >
> > On Tue, Feb 19, 2019 at 8:40 AM Ilya Kasnacheev <
> ilya.kasnach...@gmail.com
> > >
> > wrote:
> >
> > > Hello!
> > >
> > > Yes, I think we should accept plain JARs if anybody needs this at all.
> > > Might still keep meta info support for compatibility.
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> > >
> > >
> > > вт, 19 февр. 2019 г. в 19:38, Denis Mekhanikov  >:
> > >
> > > > Hi!
> > > >
> > > > There is a feature in Ignite called DeploymentSpi [1], that allows
> > adding
> > > > and changing implementation of compute tasks without nodes' downtime.
> > > > The only usable implementation right now is UriDeploymentSpi [2],
> which
> > > > lets you provide classes of compute tasks packaged as an archive of a
> > > > special form. And this special form is the worst part.
> > > > GAR file is just like a JAR, but with some additional meta info. It
> may
> > > > contain an XML with description of tasks, a checksum and also
> > > dependencies.
> > > >
> > > > We barely have any tools to build these files, and they can be
> replaced
> > > > with simple uber-JARs.
> > > > The only tool we have right now is IgniteDeploymentGarAntTask, which
> is
> > > not
> > > > documented anywhere, and it's supposed to be used from a
> long-forgotten
> > > > Apache Ant build system.
> > > >
> > > > I don't think we need this file format. How about we deprecate and
> > remove
> > > > it and make UriDeploymentSpi support plain JARs?
> > > >
> > > > [1] https://apacheignite.readme.io/docs/deployment-spi
> > > > [2]
> > > >
> > > >
> > >
> >
> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/spi/deployment/uri/UriDeploymentSpi.html
> > > >
> > > > Denis
> > > >
> > >
> >
>

[jira] [Created] (IGNITE-11363) Document replicated cache performance degradation.

[Sergey Kozlov (JIRA)]

Sergey Kozlov created IGNITE-11363:
--

 Summary: Document replicated cache performance degradation.
 Key: IGNITE-11363
 URL: https://issues.apache.org/jira/browse/IGNITE-11363
 Project: Ignite
  Issue Type: Task
Reporter: Sergey Kozlov
 Fix For: 2.8






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

Re: Best effort affinity: NPE on topology version check

[Dmitry Melnichuk]

Igor,

Thank you! It helped. I adapted my code to the new protocol, so my
tests are passing.

On Tue, 2019-02-19 at 13:22 +0300, Igor Sapego wrote:
> This is my branch. I fixed an issue so re-merge and check if it
> helps.
> 
> Best Regards,
> Igor
> 
> 
> On Tue, Feb 19, 2019 at 8:14 AM Dmitry Melnichuk <
> dmitry.melnic...@nobitlost.com> wrote:
> 
> > Igniters,
> > 
> > I am currently trying to teach my thin client (pyignite) a new
> > trick
> > called “Best effort affinity”.
> > 
> > I have been told that this feature is being implemented in the
> > private
> > branch [1], so I checked it out, built it, and gave it a go.
> > 
> > The handshake goes as expected, I have actually managed to read the
> > node UUID. But on any subsequent request the server disconnects and
> > shows the following on its console:
> > 
> > [ERROR][client-connector-#60][ClientListenerNioListener] Failed to
> > process client request [
> > 
> > req=o.a.i.i.processors.platform.client.cache.ClientCacheGetOrCreateWithNameRequest@43e45ce3
> > ]
> > java.lang.NullPointerException
> > 
> > The full dump is in attachment.
> > 
> > Since I am not authorized to create an issue in the repository I
> > was
> > using, I have to address my question to this list. If anybody
> > involved
> > in server-side implementation of best effort affinity is reading
> > this,
> > please tell me am I doing something wrong, or it is an actual bug?
> > How
> > can this issue be resolved?
> > 
> > [1] https://github.com/gridgain/apache-ignite/tree/ignite-iep23
> > 

Re: UriDeploymentSpi and GAR files

[Denis Mekhanikov]

Denis,

This XML may contain task descriptors, but I couldn't find any
documentation on this format.
Also it may contain a userVersion [1] parameter, which can be used to force
tasks redeployment in some cases.

This information can be provided in simple JAR files with the same file
structure.
There is no need to confuse people and require their packages to have a GAR
extension.

Also if you don't specify the task descriptors, then all tasks in the file
will be registered.
So, I doubt, that anybody will bother specifying the descriptors. XML is
not very user-friendly.
This piece of configuration doesn't seem necessary to me.

[1]
https://apacheignite.readme.io/docs/deployment-modes#section-un-deployment-and-user-versions

Denis

ср, 20 февр. 2019 г. в 01:35, Denis Magda :

> Denis,
>
> What was the purpose of having XML and other files within the GARs? Guess
> it was somehow versioning related - you might have several tasks of the
> same class but different versions running in a cluster.
>
> -
> Denis
>
>
> On Tue, Feb 19, 2019 at 8:40 AM Ilya Kasnacheev  >
> wrote:
>
> > Hello!
> >
> > Yes, I think we should accept plain JARs if anybody needs this at all.
> > Might still keep meta info support for compatibility.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > вт, 19 февр. 2019 г. в 19:38, Denis Mekhanikov :
> >
> > > Hi!
> > >
> > > There is a feature in Ignite called DeploymentSpi [1], that allows
> adding
> > > and changing implementation of compute tasks without nodes' downtime.
> > > The only usable implementation right now is UriDeploymentSpi [2], which
> > > lets you provide classes of compute tasks packaged as an archive of a
> > > special form. And this special form is the worst part.
> > > GAR file is just like a JAR, but with some additional meta info. It may
> > > contain an XML with description of tasks, a checksum and also
> > dependencies.
> > >
> > > We barely have any tools to build these files, and they can be replaced
> > > with simple uber-JARs.
> > > The only tool we have right now is IgniteDeploymentGarAntTask, which is
> > not
> > > documented anywhere, and it's supposed to be used from a long-forgotten
> > > Apache Ant build system.
> > >
> > > I don't think we need this file format. How about we deprecate and
> remove
> > > it and make UriDeploymentSpi support plain JARs?
> > >
> > > [1] https://apacheignite.readme.io/docs/deployment-spi
> > > [2]
> > >
> > >
> >
> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/spi/deployment/uri/UriDeploymentSpi.html
> > >
> > > Denis
> > >
> >
>

Re: [Discussion] Persistence compatibility framework refactoring

[Pavel Kovalenko]

Vyacheslav,

Thank you for answers!

>> I'm not sure what is a problem here?
At the moment it's a little bit hard to understand the impact of such a
change because the number of test suites is small.
Let's Imagine you have X compatibility test suites where X is a relatively
big number, let's say 20.
A new version of Ignite has released and a developer should update
compatibility tests to run it against the new version.
A developer should manually find all of these 20 test suites and in each of
these suites and add a new version to test it (new method).
This is a long process and there could be developer mistakes, some of the
test suites can be missed and nobody will know about it before real
compatibility problem appears.
We already faced with the situation when after new version release
(2.5-2.6) no compatibility tests were modified to support new version
because nobody remembers about it and there is no such process after
release.
Adding new pom is a very simple step and can be done by any human who even
may not be familiar with the compatibility module and may not know anything
which compatibility tests are used. If we include adding pom file to
post-release process all existing tests will automatically detect new
version and next TC run will immediately show to us results. If there are
some compatibility problems during development new version TC run will show
it. At the current approach, compatibility tests are out of focus and we
may not see potential issues.

>> This is not about usability, it's about the framework's internals
At the current approach, a developer should take care of dependency
management for the old versions. E.g. if you look
at IgnitePKIndexesMigrationToUnwrapPkTest you can see "magic" H2 dependency
version. I still don't understand why this version was explicitly added and
not just inherited from ignite-indexing. If we delegate all dependency
management to Maven itself it will simplify tests development. Tests will
look much simpler.

>> Please, describe the issue in more details?
Suppose you have a closure that invokes some deprecated method which will
be removed in next release. After method removal, such tests will be
broken. At the current framework, I can't see a resolution of that problem.
In a new framework, you can keep the old version of closure, mark it with
special annotation and place to separate module with old Ignite version
dependency. This closure will be compiled using an old version of Ignite
and the user can still run it on the old version.



вт, 19 февр. 2019 г. в 21:44, Vyacheslav Daradur :

> Hi, Pavel!
>
> First of all, I'd like to clarify that the Compatibility Testing
> Framework was designed to work with a cluster of multi-version nodes.
> The main idea is to run a test to verify backward compatibility or do
> some kind of rolling upgrades.
>
> It's not about persistence compatibility, but actually, it is used for
> this now.
>
> >> 1) It's uncomfortable to add and support new versions of Ignite product.
>
> I'm not sure what is a problem here?
> As I understand you suggest to do similar things - adding new pom.xml
> when new a version is released. Pay attention that not all tests
> should be tested on all versions, some test may want to test specific
> versions each other.
>
> >> 2) Manual maven dependency through java api.
>
> This is not about usability, it's about the framework's internals. If
> you have issues let's fix it and improve approach if needed.
>
> >> 3) It doesn't cover the case when some code which works on the current
> version will not work on older versions due to compile/runtime
> incompatibility.
>
> Please, describe the issue in more details?
>
> On Tue, Feb 19, 2019 at 7:55 PM Pavel Kovalenko 
> wrote:
> >
> > Anton,
> >
> > >> What about the current compatibility framework?
> > Current compatibility framework will be removed after final adjusting to
> > new framework.
> >
> > >> Could you please share examples for each feature you mentioned?
> > You can see example in PR e.g. file
> > modules/compatibility/ignite-versions/2.1.0/pom.xml
> > <
> https://github.com/apache/ignite/pull/5974/files#diff-3c44ef223c31de9ff1e10bd7699cbcdc
> >
> >
> > I think such representing of Ignite product version is more cleaner than
> > existing approach with Java classes with dependencies and manual
> dependecy
> > management.
> >
> > >> Anyway. I don't like the idea to implement something new instead of
> > improving the existing.
> > If you have concrete proposals how to improve current framework please
> > share it.
> >
> >
> > вт, 19 февр. 2019 г. в 19:11, Anton Vinogradov :
> >
> > > +5,327 −59
> > > What about the current compatibility framework?
> > > I see no removal or updates.
> > >
> > > >> Each new version is represented by a single pom
> > > Sound not good.
> > > Could you please share examples for each feature you mentioned?
> > >
> > > Anyway. I don't like the idea to implement something new instead of
> > > improving the existing.
> 

Re: [Discussion] Persistence compatibility framework refactoring

[Anton Vinogradov]

Fully agree with Slava,

Pavel, please share your vision of compatibility framework (current and
desired).
It really looks like you don't love current just because you can't
understand how to use it properly.
But this should not mean we have to remove the current, we should
improve/refactor/document it instead, if necessary.

Please share features you're not able to implement using the current
framework, whole list.
And we will help you to find improvement way instead of replacement.

Evolution is always better than a revolution.

Viva La Evolucion! :)

On Tue, Feb 19, 2019 at 9:44 PM Vyacheslav Daradur 
wrote:

> Hi, Pavel!
>
> First of all, I'd like to clarify that the Compatibility Testing
> Framework was designed to work with a cluster of multi-version nodes.
> The main idea is to run a test to verify backward compatibility or do
> some kind of rolling upgrades.
>
> It's not about persistence compatibility, but actually, it is used for
> this now.
>
> >> 1) It's uncomfortable to add and support new versions of Ignite product.
>
> I'm not sure what is a problem here?
> As I understand you suggest to do similar things - adding new pom.xml
> when new a version is released. Pay attention that not all tests
> should be tested on all versions, some test may want to test specific
> versions each other.
>
> >> 2) Manual maven dependency through java api.
>
> This is not about usability, it's about the framework's internals. If
> you have issues let's fix it and improve approach if needed.
>
> >> 3) It doesn't cover the case when some code which works on the current
> version will not work on older versions due to compile/runtime
> incompatibility.
>
> Please, describe the issue in more details?
>
> On Tue, Feb 19, 2019 at 7:55 PM Pavel Kovalenko 
> wrote:
> >
> > Anton,
> >
> > >> What about the current compatibility framework?
> > Current compatibility framework will be removed after final adjusting to
> > new framework.
> >
> > >> Could you please share examples for each feature you mentioned?
> > You can see example in PR e.g. file
> > modules/compatibility/ignite-versions/2.1.0/pom.xml
> > <
> https://github.com/apache/ignite/pull/5974/files#diff-3c44ef223c31de9ff1e10bd7699cbcdc
> >
> >
> > I think such representing of Ignite product version is more cleaner than
> > existing approach with Java classes with dependencies and manual
> dependecy
> > management.
> >
> > >> Anyway. I don't like the idea to implement something new instead of
> > improving the existing.
> > If you have concrete proposals how to improve current framework please
> > share it.
> >
> >
> > вт, 19 февр. 2019 г. в 19:11, Anton Vinogradov :
> >
> > > +5,327 −59
> > > What about the current compatibility framework?
> > > I see no removal or updates.
> > >
> > > >> Each new version is represented by a single pom
> > > Sound not good.
> > > Could you please share examples for each feature you mentioned?
> > >
> > > Anyway. I don't like the idea to implement something new instead of
> > > improving the existing.
> > >
> > > On Tue, Feb 19, 2019 at 6:48 PM Pavel Kovalenko 
> > > wrote:
> > >
> > > > Igniters,
> > > >
> > > > I would like to start a discussion about replacement existing
> > > > persistence compatibility test framework with the newer version.
> > > > The main purpose of that action is simplifying compatibility tests
> > > > development and support.
> > > >
> > > > The current version of the test framework has 3 disadvantages:
> > > > 1) It's uncomfortable to add and support new versions of Ignite
> product.
> > > > When a new version has released a developer must manually add new
> test
> > > > methods to all existing test suites to support the new product
> version.
> > > > 2) Manual maven dependency through java api.
> > > > If a new version of Ignite product has some specific dependency
> version
> > > > (like H2) a developer should take care about and manually cover this
> case
> > > > using java api.
> > > > 3) It doesn't cover the case when some code which works on the
> current
> > > > version will not work on older versions due to compile/runtime
> > > > incompatibility.
> > > >
> > > > A new version of the framework that is under development right now
> [1]
> > > > doesn't have such problems.
> > > > Here is a list of key features and possibilities:
> > > >
> > > > 1) One codebase - multiple versions support.
> > > > The key feature of the new framework is significant simplifying
> adding
> > > and
> > > > supporting the new versions of Ignite product.
> > > > Each new version is represented by a single pom file that contains
> Ignite
> > > > dependencies of specific version (core, indexing, etc.). All
> > > subdependecies
> > > > like H2 are covered by Maven automatically.
> > > > To add a new version for compatibility a developer just need to add
> a new
> > > > pom file with a new version of Ignite. All existing tests will
> > > > automatically detect the new version and will run tests against this
> > > > version 

[jira] [Created] (IGNITE-11362) New protocol version is absent in baseline autoadjustment visor args

[Ivan Bessonov (JIRA)]

Ivan Bessonov created IGNITE-11362:
--

 Summary: New protocol version is absent in baseline autoadjustment 
visor args
 Key: IGNITE-11362
 URL: https://issues.apache.org/jira/browse/IGNITE-11362
 Project: Ignite
  Issue Type: Improvement
Reporter: Ivan Bessonov
Assignee: Ivan Bessonov


org.apache.ignite.internal.visor.VisorDataTransferObject#getProtocolVersion 
method should be overridden when updating visor classes. 



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