[jira] [Created] (IGNITE-11361) Web console: Actualize grid configurator IgniteConfiguration

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-11361:
--

 Summary: Web console: Actualize grid configurator 
IgniteConfiguration
 Key: IGNITE-11361
 URL: https://issues.apache.org/jira/browse/IGNITE-11361
 Project: Ignite
  Issue Type: Improvement
  Components: wizards
Reporter: Vasiliy Sisko
Assignee: Vasiliy Sisko


Result for class: org.apache.ignite.configuration.IgniteConfiguration
  Missed
    authenticationEnabled
    sqlQueryHistorySize
    lifecycleBeans
    addressResolver
    allSegmentationResolversPassRequired
    localEventListeners
    mBeanServer
    networkCompressionLevel
    segmentCheckFrequency
    systemWorkerBlockedTimeout
    includeProperties
    cacheStoreSessionListenerFactories
    initBaselineAutoAdjustEnabled
    failureHandler
    initBaselineAutoAdjustTimeout
    autoActivationEnabled
    sqlSchemas
    segmentationPolicy
    segmentationResolveAttempts
    igniteInstanceName
    waitForSegmentOnStart
    igniteHome
    initBaselineAutoAdjustMaxTimeout
    communicationFailureResolver
    segmentationResolvers
    platformConfiguration
    encryptionSpi



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

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

[dpavlov . tasks]

Hi Igniters,

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

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

 *New stable failure of a flaky test in master 
IgniteChangingBaselineDownCachePutAllFailoverTest.testPutAllFailover 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-520509072736429699=%3Cdefault%3E=testDetails

 *New stable failure of a flaky test in master 
IgniteChangingBaselineDownCachePutAllFailoverTest.testPutAllFailoverPessimisticTx
 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-5323374852748359686=%3Cdefault%3E=testDetails
 Changes may lead to failure were done by 
 - kaa.dev 
https://ci.ignite.apache.org/viewModification.html?modId=876133
 - kaa.dev 
https://ci.ignite.apache.org/viewModification.html?modId=876116
 - 32207922+ololo3000 
https://ci.ignite.apache.org/viewModification.html?modId=876131

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

Best Regards,
Apache Ignite TeamCity Bot 
https://github.com/apache/ignite-teamcity-bot
Notification generated at 08:56:30 20-02-2019 

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

[dpavlov . tasks]

Hi Igniters,

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

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

 *New stable failure of a flaky test in master 
PersistenceTest.TestBaselineTopology 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=5018016709091941371=%3Cdefault%3E=testDetails
 No changes in the build

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

Best Regards,
Apache Ignite TeamCity Bot 
https://github.com/apache/ignite-teamcity-bot
Notification generated at 06:11:27 20-02-2019 

[jira] [Created] (IGNITE-11360) Web Console: Should detect situation when session on backed expired / removed

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-11360:
-

 Summary: Web Console: Should detect situation when session on 
backed expired / removed
 Key: IGNITE-11360
 URL: https://issues.apache.org/jira/browse/IGNITE-11360
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Reporter: Alexey Kuznetsov


Steps to reproduce:
# Start backend and frontend as usual.
# Sign in on frontend.
# Stop backend and wipe its DB.
# Start backend.
# Click some links on frontend.

Expected: Frontend should go to 403 page.

Errors in logs (from steps):
{code}

(anonymous) @ angular.js:13539
sendReq @ angular.js:13265
serverRequest @ angular.js:13006
processQueue @ angular.js:17922
(anonymous) @ angular.js:17970
$digest @ angular.js:19089
$apply @ angular.js:19477
(anonymous) @ angular.js:21578
completeTask @ angular.js:21208
(anonymous) @ angular.js:6789
setTimeout (async)
Browser.self.defer @ angular.js:6787
timeout @ angular.js:21568
(anonymous) @ stateDirectives.js:52
dispatch @ jquery.js:5206
elemData.handle @ jquery.js:5014
09:42:41.993 angular.js:13539 GET 
http://localhost:9000/api/v1/configuration/clusters/ 401 (Unauthorized)
(anonymous) @ angular.js:13539
sendReq @ angular.js:13265
serverRequest @ angular.js:13006
processQueue @ angular.js:17922
(anonymous) @ angular.js:17970
$digest @ angular.js:19089
$apply @ angular.js:19477
(anonymous) @ angular.js:21578
completeTask @ angular.js:21208
(anonymous) @ angular.js:6789
setTimeout (async)
Browser.self.defer @ angular.js:6787
timeout @ angular.js:21568
Grid.refreshCanvas @ ui-grid.js:5921
init @ ui-grid.js:3531
post @ ui-grid.js:3465
(anonymous) @ angular.js:1365
(anonymous) @ angular.js:11237
invokeLinkFn @ angular.js:11243
nodeLinkFn @ angular.js:10562
(anonymous) @ angular.js:10908
processQueue @ angular.js:17922
(anonymous) @ angular.js:17970
$digest @ angular.js:19089
$apply @ angular.js:19477
(anonymous) @ angular.js:21578
completeTask @ angular.js:21208
(anonymous) @ angular.js:6789
setTimeout (async)
Browser.self.defer @ angular.js:6787
timeout @ angular.js:21568
(anonymous) @ stateDirectives.js:52
dispatch @ jquery.js:5206
elemData.handle @ jquery.js:5014
09:42:42.019 angular.js:15544 Possibly unhandled rejection: 
{"type":"LOAD_USER_CLUSTERS_ERR","error":{"message":"Failed to load clusters: 
Access denied. You are not authorized to access this 
page."},"action":{"type":"LOAD_USER_CLUSTERS"}} undefined
(anonymous) @ angular.js:15544
(anonymous) @ exceptionHandler.js:32
processChecks @ angular.js:17954
$digest @ angular.js:19089
(anonymous) @ angular.js:19409
completeTask @ angular.js:21208
(anonymous) @ angular.js:6789
setTimeout (async)
Browser.self.defer @ angular.js:6787
$evalAsync @ angular.js:19407
(anonymous) @ angular.js:17794
scheduleProcessQueue @ angular.js:17970
then @ angular.js:17891
$http @ angular.js:12922
$http.(anonymous function) @ angular.js:13170
getClustersOverview @ Clusters.ts:106
ConfigEffects.loadUserClustersEffect$.ConfigureState.actions$.pipe.a @ 
effects.js:220
push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/operators/exhaustMap.js.ExhaustMapSubscriber.tryNext
 @ exhaustMap.js:44
push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/operators/exhaustMap.js.ExhaustMapSubscriber._next
 @ exhaustMap.js:37
push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/Subscriber.js.Subscriber.next
 @ Subscriber.js:54
push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/operators/filter.js.FilterSubscriber._next
 @ filter.js:38
push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/Subscriber.js.Subscriber.next
 @ Subscriber.js:54
push.../../../../incubator-ignite/modules/web-console/frontend/node_modules/rxjs/_esm5/internal/Subject.js.Subject.next
 @ Subject.js:47
dispatchAction @ ConfigureState.ts:58
setTimeout @ effects.js:744
setTimeout (async)
ConfigEffects.etp @ effects.js:744
$stateProvider.state.resolve._shortClusters @ states.ts:54
invokeResolveFn @ resolvable.js:73
processQueue @ angular.js:17922
(anonymous) @ angular.js:17970
$digest @ angular.js:19089
$apply @ angular.js:19477
(anonymous) @ angular.js:21578
completeTask @ angular.js:21208
(anonymous) @ angular.js:6789
setTimeout (async)
Browser.self.defer @ angular.js:6787
timeout @ angular.js:21568
(anonymous) @ stateDirectives.js:52
dispatch @ jquery.js:5206
elemData.handle @ jquery.js:5014
09:42:42.022 angular.js:15544 Possibly unhandled rejection: 
{"type":"LOAD_USER_CLUSTERS_ERR","error":{"message":"Failed to load clusters: 
Access denied. You are not authorized to access this 
page."},"action":{"type":"LOAD_USER_CLUSTERS"}} undefined
(anonymous) @ angular.js:15544
(anonymous) @ exceptionHandler.js:32
processChecks @ angular.js:17954
$digest @ 

Apache ignite tasks: IGNITE-11230, IGNITE-11131

[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: UriDeploymentSpi and GAR files

[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
> >
>

Asking to feature The Apache Ignite Book

[shamim]

We are happy to announce that we have finished the final manuscript of "The
Apache Ignite Book."  At this moment, the book is available at  leanpub
  . An old-fashioned paperback version of
the book will be published soon on Amazon. 

We strongly guess that this book will be an excellent resource beyond the
official documentation. Is it possible to feature this book on your website? 

Regards
  Shamim 



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

Re: [Discussion] Persistence compatibility framework refactoring

[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
> 
>
> 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 without additional changes. This feature covers p. 1 and 2 of the
> > > existing framework.
> > > 2) Unified API to access and run code on old and new versions of Ignite.
> > > Each of Ignite instance is represented by remote JVM with a single point
> > of
> > > interaction - running abstract closures. Each closure is just a class
> > which
> > > implement a "runner interface". Each closure object is serialized to a
> > file
> > > through Xstream library and executed on remote Ignite JVM. This approach
> > > gives unified access to interact with both old and new versions of Ignite
> > > and simplifies overall tests development.
> > > 3) Ignite versions support for closures. Sometimes a closure couldn't be
> > > run on newer or older Ignite version due to compile/runtime
> > incompatibility
> > > of that code. To resolve this 

Re: [Discussion] Persistence compatibility framework refactoring

[Pavel Kovalenko]

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


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 without additional changes. This feature covers p. 1 and 2 of the
> > existing framework.
> > 2) Unified API to access and run code on old and new versions of Ignite.
> > Each of Ignite instance is represented by remote JVM with a single point
> of
> > interaction - running abstract closures. Each closure is just a class
> which
> > implement a "runner interface". Each closure object is serialized to a
> file
> > through Xstream library and executed on remote Ignite JVM. This approach
> > gives unified access to interact with both old and new versions of Ignite
> > and simplifies overall tests development.
> > 3) Ignite versions support for closures. Sometimes a closure couldn't be
> > run on newer or older Ignite version due to compile/runtime
> incompatibility
> > of that code. To resolve this problem a special annotation has
> introduced.
> > This annotation named as "@Since" contains minimal possible Ignite
> product
> > version where annotated closure can be compiled and run. Such closures
> are
> > processed on Ignite versions compile phase and this makes it possible to
> > use one closure for multiple Ignite versions without additional code
> > changes. Closures and versioning resolve p. 3 of the existing framework.
> >
> > [1] - https://issues.apache.org/jira/browse/IGNITE-11133
> >
> > I would like to hear any opinions about the new framework.
> >
>

Re: UriDeploymentSpi and GAR files

[Ilya Kasnacheev]

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
>

UriDeploymentSpi and GAR files

[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

[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 without additional changes. This feature covers p. 1 and 2 of the
> existing framework.
> 2) Unified API to access and run code on old and new versions of Ignite.
> Each of Ignite instance is represented by remote JVM with a single point of
> interaction - running abstract closures. Each closure is just a class which
> implement a "runner interface". Each closure object is serialized to a file
> through Xstream library and executed on remote Ignite JVM. This approach
> gives unified access to interact with both old and new versions of Ignite
> and simplifies overall tests development.
> 3) Ignite versions support for closures. Sometimes a closure couldn't be
> run on newer or older Ignite version due to compile/runtime incompatibility
> of that code. To resolve this problem a special annotation has introduced.
> This annotation named as "@Since" contains minimal possible Ignite product
> version where annotated closure can be compiled and run. Such closures are
> processed on Ignite versions compile phase and this makes it possible to
> use one closure for multiple Ignite versions without additional code
> changes. Closures and versioning resolve p. 3 of the existing framework.
>
> [1] - https://issues.apache.org/jira/browse/IGNITE-11133
>
> I would like to hear any opinions about the new framework.
>

[Discussion] Persistence compatibility framework refactoring

[Pavel Kovalenko]

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 without additional changes. This feature covers p. 1 and 2 of the
existing framework.
2) Unified API to access and run code on old and new versions of Ignite.
Each of Ignite instance is represented by remote JVM with a single point of
interaction - running abstract closures. Each closure is just a class which
implement a "runner interface". Each closure object is serialized to a file
through Xstream library and executed on remote Ignite JVM. This approach
gives unified access to interact with both old and new versions of Ignite
and simplifies overall tests development.
3) Ignite versions support for closures. Sometimes a closure couldn't be
run on newer or older Ignite version due to compile/runtime incompatibility
of that code. To resolve this problem a special annotation has introduced.
This annotation named as "@Since" contains minimal possible Ignite product
version where annotated closure can be compiled and run. Such closures are
processed on Ignite versions compile phase and this makes it possible to
use one closure for multiple Ignite versions without additional code
changes. Closures and versioning resolve p. 3 of the existing framework.

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

I would like to hear any opinions about the new framework.

[jira] [Created] (IGNITE-11359) Improvement of tests. Add additional state check after each test.

[Stepachev Maksim (JIRA)]

Stepachev Maksim created IGNITE-11359:
-

 Summary: Improvement of tests. Add additional state check after 
each test.
 Key: IGNITE-11359
 URL: https://issues.apache.org/jira/browse/IGNITE-11359
 Project: Ignite
  Issue Type: Improvement
Reporter: Stepachev Maksim
Assignee: Stepachev Maksim


Sometimes, the Flaky tests are interrupted with OOM. There are many reasons for 
it, but the main is a memory leak in transactions. The good way of fast problem 
detection will additionally check of maps with transaction futures after a 
test. It must be empty. Add this logic into GridCommonAbstractTest.



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

[jira] [Created] (IGNITE-11358) Bug in ZK tests occurs periodically

[Pavel Voronkin (JIRA)]

Pavel Voronkin created IGNITE-11358:
---

 Summary: Bug in ZK tests occurs periodically
 Key: IGNITE-11358
 URL: https://issues.apache.org/jira/browse/IGNITE-11358
 Project: Ignite
  Issue Type: Bug
Reporter: Pavel Voronkin


java.lang.NullPointerException
at 
org.apache.ignite.spi.discovery.zk.ZookeeperDiscoverySpi.allNodesSupport(ZookeeperDiscoverySpi.java:342)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.isHandshakeWaitSupported(TcpCommunicationSpi.java:4109)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.access$400(TcpCommunicationSpi.java:277)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$2.onConnected(TcpCommunicationSpi.java:430)
at 
org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onSessionOpened(GridNioFilterChain.java:251)
at 
org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedSessionOpened(GridNioFilterAdapter.java:88)
at 
org.apache.ignite.internal.util.nio.GridNioCodecFilter.onSessionOpened(GridNioCodecFilter.java:66)
at 
org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedSessionOpened(GridNioFilterAdapter.java:88)
at 
org.apache.ignite.internal.util.nio.GridConnectionBytesVerifyFilter.onSessionOpened(GridConnectionBytesVerifyFilter.java:58)
at 
org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedSessionOpened(GridNioFilterAdapter.java:88)
at 
org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onSessionOpened(GridNioServer.java:3525)
at 
org.apache.ignite.internal.util.nio.GridNioFilterChain.onSessionOpened(GridNioFilterChain.java:139)
at 
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.register(GridNioServer.java:2639)
at 
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:1997)
at 
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1818)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)



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

Re: Best effort affinity: NPE on topology version check

[Igor Sapego]

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
>

[jira] [Created] (IGNITE-11357) MVCC: SQL tx operations and DDL inside tx block

[Ivan Pavlukhin (JIRA)]

Ivan Pavlukhin created IGNITE-11357:
---

 Summary: MVCC: SQL tx operations and DDL inside tx block
 Key: IGNITE-11357
 URL: https://issues.apache.org/jira/browse/IGNITE-11357
 Project: Ignite
  Issue Type: Bug
  Components: mvcc
Affects Versions: 2.7
Reporter: Ivan Pavlukhin


DLL and special tx (BEGIN, COMMIT) and DDL operations does not behave well 
inside explicit tx started using Java API. We should define how such operations 
behave inside tx or forbid them inside tx. See test 
{{SqlTransactionsCommandsWithMvccEnabledSelfTest#testSqlOperationsWithinNonSqlTransaction}}.
Here is an example of problematic construction:
{code}
try (Transaction tx = node.transactions().txStart(PESSIMISTIC, SERIALIZABLE)) {
cache.put(1, 1);
cache.query(new SqlFieldsQuery("commit"));
cache.put(2, 2);

tx.commit();
}
{code}



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

[jira] [Created] (IGNITE-11356) Test framework: Remove custom assumption exceptions handling

[Ivan Pavlukhin (JIRA)]

Ivan Pavlukhin created IGNITE-11356:
---

 Summary: Test framework: Remove custom assumption exceptions 
handling
 Key: IGNITE-11356
 URL: https://issues.apache.org/jira/browse/IGNITE-11356
 Project: Ignite
  Issue Type: Task
Reporter: Ivan Pavlukhin


It turns out that custom handling of {{AssumptionViolatedException}} can be 
removed. Currently with custom handling tests with unmet assumptions are marked 
as passed. With default handling failed assumptions on instance level mark 
tests as ignored.

Note: on class level reporting in case of unmet assumptions does not look 
perfect. But with custom handling a particular test is not included into TC 
report at all.



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

[jira] [Created] (IGNITE-11355) Mention CacheConfiguration.sqlIndexMaxInlineSize and QueryGroupIndex.inlineSize in inline size suggestions

[Stanislav Lukyanov (JIRA)]

Stanislav Lukyanov created IGNITE-11355:
---

 Summary: Mention CacheConfiguration.sqlIndexMaxInlineSize and 
QueryGroupIndex.inlineSize in inline size suggestions
 Key: IGNITE-11355
 URL: https://issues.apache.org/jira/browse/IGNITE-11355
 Project: Ignite
  Issue Type: Improvement
Reporter: Stanislav Lukyanov


Currently the suggestion for changing inline size of the PK and AK indexes 
reads like this
{code}
recommendation = "set system property "
+ IgniteSystemProperties.IGNITE_MAX_INDEX_PAYLOAD_SIZE + " 
with recommended size " +
"(be aware it will be used by default for all indexes 
without explicit inline size)";
{code}
However, there is also property CacheConfiguration.sqlIndexMaxInlineSize that 
can be used. In fact, in most cases it is even better to use the cache 
configuration property instead of the system property because 1) it is local, 
not global 2) it is a part of the static configuration and doesn't depend of 
the correct environment setup

The suggestion for other indexes reads 
{code}
recommendation = "use INLINE_SIZE option for CREATE INDEX 
command, " +
"QuerySqlField.inlineSize for annotated classes, or 
QueryIndex.inlineSize for explicit " +
"QueryEntity configuration";
{code}
It should also mention QueryGroupIndex.inlineSize for group indexes.



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

[jira] [Created] (IGNITE-11354) Web console: Actualize grid configurator discovery, store, abomic, communication

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-11354:
--

 Summary: Web console: Actualize grid configurator discovery, 
store, abomic, communication
 Key: IGNITE-11354
 URL: https://issues.apache.org/jira/browse/IGNITE-11354
 Project: Ignite
  Issue Type: Improvement
Reporter: Vasiliy Sisko
Assignee: Vasiliy Sisko


Result for class: org.apache.ignite.configuration.DataStorageConfiguration
  Missed
    maxWalArchiveSize
    checkpointReadLockTimeout
    walCompactionLevel

Result for class: org.apache.ignite.configuration.AtomicConfiguration
  Missed
    groupName

Result for class: org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi
  Missed
    nodeAttributes
    connectionRecoveryTimeout
    reconnectDelay


Result for class: org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi
  Missed
    usePairedConnections
    connectionsPerNode
    selectorSpins
    filterReachableAddresses
  Removed
    discoveryStartupDelay



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

[jira] [Created] (IGNITE-11353) Web console: responses with status 401 do not redirect to signin page

[Ilya Borisov (JIRA)]

Ilya Borisov created IGNITE-11353:
-

 Summary: Web console: responses with status 401 do not redirect to 
signin page
 Key: IGNITE-11353
 URL: https://issues.apache.org/jira/browse/IGNITE-11353
 Project: Ignite
  Issue Type: Improvement
  Components: wizards
Reporter: Ilya Borisov
Assignee: Ilya Borisov


What happens:
On page reload, when backend API responds with status of 401, the app is stuck 
on "loading" screen and does not redirect to signin screen.

What should happen:
The app should redirect to signin screen when 401 happens (except for a few 
exceptions).

How to reproduce:
1. Sign in.
2. Kill user session in db.
3. Reload the page.



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

[jira] [Created] (IGNITE-11352) Compatibility with 2.7 with mode: statistics enabled

[Stepachev Maksim (JIRA)]

Stepachev Maksim created IGNITE-11352:
-

 Summary: Compatibility with 2.7 with mode:  statistics enabled
 Key: IGNITE-11352
 URL: https://issues.apache.org/jira/browse/IGNITE-11352
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.7
Reporter: Stepachev Maksim
Assignee: Stepachev Maksim
 Fix For: 2.7


The problem was founded when we performed a rolling upgrade from 2.4 to 2.7. 
The root of the problem is CacheMetricsSnapshot, it doesn't work with the 
previous version of the protocol.

 



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