[jira] [Created] (IGNITE-12923) web-* docker images on Docker Hub are out of date

[Zaar Hai (Jira)]

Zaar Hai created IGNITE-12923:
-

 Summary: web-* docker images on Docker Hub are out of date
 Key: IGNITE-12923
 URL: https://issues.apache.org/jira/browse/IGNITE-12923
 Project: Ignite
  Issue Type: Bug
Reporter: Zaar Hai
 Attachments: Selection_574.png

Good day,

Looking at DockerHub, web-agent and web-console-* docker image were updated 
more than a year ago and there are no new images for Ignite 2.8.0.

It will be great if they can updated automatically with each new release of 
Ignite. As it is now, one cann't have out-of-the-box web console for Ignite 
2.8.0 without either rebuilding docker images manually or residing to GridGain 
centralized  UI.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-12676) .NET: Add partition-based AffinityCall and AffinityRun overloads

[Ignite TC Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17088123#comment-17088123
 ] 

Ignite TC Bot commented on IGNITE-12676:


{panel:title=Branch: [pull/7701/head] Base: [master] : Possible Blockers 
(3)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Queries 1{color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=5242412]]
* IgniteBinaryCacheQueryTestSuite: 
GridCacheFullTextQuerySelfTest.testTextQueryWithFieldLimited - Test has low 
fail rate in base branch 0,0% and is not flaky

{color:#d04437}Platform .NET (Core Linux){color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=5242407]]
* dll: DataStreamerTest.TestMultithreaded - New test duration 73s is more that 
1 minute

{color:#d04437}MVCC Cache 5{color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=5242424]]
* IgniteCacheMvccTestSuite5: 
IgniteCachePartitionLossPolicySelfTest.testReadWriteSafeAfterKillCrdWithPersistence[TRANSACTIONAL]
 - Test has low fail rate in base branch 0,0% and is not flaky

{panel}
[TeamCity *--> Run :: All* 
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5242436&buildTypeId=IgniteTests24Java8_RunAll]

> .NET: Add partition-based AffinityCall and AffinityRun overloads
> 
>
> Key: IGNITE-12676
> URL: https://issues.apache.org/jira/browse/IGNITE-12676
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Add partition-based AffinityCall and AffinityRun overloads to ICompute.See 
> corresponding methods in Java (IgniteCompute).
> Additionally, current affinity methods work through PlatformAbstractTask, 
> which does not lock partitions. We should refactor existing AffinityCall and 
> AffinityRun overloads to call corresponding IgniteCompute APIs.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-10940) Supply pre-built ./configure with Apache Ignite releases

[Ilya Kasnacheev (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-10940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17088122#comment-17088122
 ] 

Ilya Kasnacheev commented on IGNITE-10940:
--

It is an improvement to release procedures. I think that improving release 
procedures is a thing to do in patch releases, since major releases have too 
much stuff anyway and people have zero interest in improving release procedures 
when there is no release.

This is why I suggest we put IGNITE-10940 and IGNITE-12765 inti 2.8.1 or maybe 
2.8.2

> Supply pre-built ./configure with Apache Ignite releases
> 
>
> Key: IGNITE-10940
> URL: https://issues.apache.org/jira/browse/IGNITE-10940
> Project: Ignite
>  Issue Type: Improvement
>  Components: build
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
>  Labels: c++
> Fix For: 2.8.1
>
>
> Right now we have the following build steps for C++ in docs:
> {code}
> cd modules/platforms/cpp
> libtoolize && aclocal && autoheader && automake --add-missing && autoreconf
> ./configure
> make
> sudo make install
> {code}
> However, it is customary for C++ projects to ship release tarballs with first 
> step already done. ./configure should be pre-built and libtoolize, etc, are 
> already ran since you should not force user to install them, and the process 
> of their application is deterministic.
> I suggest we add libtoolize && etc step to release builds so that user's 
> first step will be ./configure.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-12919) Not all GridUuid renamed to IgniteUuid

[Amelchev Nikita (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17088109#comment-17088109
 ] 

Amelchev Nikita commented on IGNITE-12919:
--

[~mmuzaf] Hi. Could you take a look, please?

> Not all GridUuid renamed to IgniteUuid
> --
>
> Key: IGNITE-12919
> URL: https://issues.apache.org/jira/browse/IGNITE-12919
> Project: Ignite
>  Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Minor
> Fix For: 2.9
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> There are several places in javadocs and serialization mechanisms where 
> GridUuid is not renamed. For example:
> {noformat}
> /**
>  * Constructs {@code GridUuid} from a global and local identifiers.
>  ...
>  */
> public IgniteUuid(UUID gid, long locId) { ... }
> /**
>  * Reads {@link org.apache.ignite.lang.IgniteUuid} from input stream. 
>  ...
>  */
> @Nullable public static IgniteUuid readGridUuid(DataInput in) throws 
> IOException {...}
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-10075) .NET: Avoid binary configurations of Ignite Java service params and result when calling it from Ignite.NET

[Alexey Kukushkin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-10075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexey Kukushkin updated IGNITE-10075:
--
Description: 
Presently if there is an Ignite Java service taking parameters of complex 
(composite) types and returning a result of complex type then all the complex 
types must be explicitly specified in the binary configuration.

We need to enhance Ignite not to require binary configuration assuming that we 
use the same type, package/namespace and field/property names on both the .NET 
and Java sides (or provide a custom name mapper for relaxed naming conventions).
h2. Reproducer
h3. ICalculator.java
{code:java}
package Sandbox.Net;

public interface ICalculator {
Result Calculate(Parameter p);
}
{code}
h3. Parameter.java
{code:java}
package Sandbox.Net;

public class Parameter {
private int id;
private double val;

public int getId() {
return id;
}

public Parameter setId(int id) {
this.id = id;
return this;
}

public double getValue() {
return val;
}

public Parameter setValue(double val) {
this.val = val;
return this;
}
}
{code}
h3. Result .java
{code:java}
package Sandbox.Net;

public class Result {
private int id;
private double value;

public int getId() {
return id;
}

public Result setId(int id) {
this.id = id;
return this;
}

public double getValue() {
return value;
}

public Result setValue(double val) {
this.value = val;
return this;
}
}
{code}
h3. IgniteCalculatorService.java
{code:java}
package Sandbox.Net;

import org.apache.ignite.services.Service;
import org.apache.ignite.services.ServiceContext;

public class IgniteCalculatorService implements Service, ICalculator {
@Override public Result Calculate(Parameter p) {
return new Result().setId(p.getId()).setValue(p.getValue() * 
p.getValue());
}

@Override public void cancel(ServiceContext ctx) {
}

@Override public void init(ServiceContext ctx) {
}

@Override public void execute(ServiceContext ctx) {
}
}
{code}
h3. build.gradle
{code:groovy}
plugins {
id 'java'
}

group 'sandbox.net'
version '1.0-SNAPSHOT'

sourceCompatibility = 1.8

repositories {
mavenLocal()
mavenCentral()
}

def igniteVer='2.8.0'

dependencies {
compile group: 'org.apache.ignite', name: 'ignite-core', version: igniteVer

testCompile group: 'junit', name: 'junit', version: '4.12'
}
{code}
h3. ignite-config.xml
{code:xml}


http://www.springframework.org/schema/beans";
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
   xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd";>




















127.0.0.1:47500








{code}
h3. ICalculator.cs
{code:c#}
namespace Sandbox.Net
{
public interface ICalculator
{
Result Calculate(Parameter p);
}
}
{code}
h3. Parameter.cs
{code:c#}
namespace Sandbox.Net
{
public class Parameter
{
public int Id { get; set; }
public double Value { get; set; }
}
}
{code}
h3. Result.cs
{code:c#}
namespace Sandbox.Net
{
public class Result
{
public int Id { get; set; }
public double Value { get; set; }
}
}
{code}
h3. Reproducer.cs
{code:c#}
using Apache.Ignite.Core;
using System;

namespace Sandbox.Net
{
class Reproducer
{
static void Main(string[] args)
{
IgniteConfiguration CommonConfig(string name) => new 
IgniteConfiguration
{
IgniteInstanceName = name,
SpringConfigUrl = "ignite-config.xml",
JvmClasspath = "sandbox.net-1.0-SNAPSHOT.jar"
};

var igniteServerCfg = CommonConfig("server1");

var igniteAppCfg = CommonConfig("app");
igniteAppCfg.ClientMode = true;

using (var _ = Ignition.Start(igniteServerCfg))
using (var ignite = Ignition.Start(igniteAppCfg))
{
var calc = 
ignite.GetServices().GetServiceProxy("IgniteCalculatorService");
var res = calc.Calculate(new Parameter { Id = 2, Value = 2.0 });
Console.WriteLine($"> {res.Value}");
}
}
}
}
{code}
h2. Actual Result Exception
{code}
Apache.Ignite.Core.Services.ServiceInvocationE

[jira] [Commented] (IGNITE-10075) .NET: Avoid binary configurations of Ignite Java service params and result when calling it from Ignite.NET

[Alexey Kukushkin (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-10075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17088107#comment-17088107
 ] 

Alexey Kukushkin commented on IGNITE-10075:
---

[~zzzadruga], I added a Reproducer to the Description. 

> .NET: Avoid binary configurations of Ignite Java service params and result 
> when calling it from Ignite.NET
> --
>
> Key: IGNITE-10075
> URL: https://issues.apache.org/jira/browse/IGNITE-10075
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 2.6
>Reporter: Alexey Kukushkin
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET, sbcf
> Attachments: MyTest.cs, ignite-10075-vs-2.8.patch
>
>
> Presently if there is an Ignite Java service taking parameters of complex 
> (composite) types and returning a result of complex type then all the complex 
> types must be explicitly specified in the binary configuration.
> We need to enhance Ignite not to require binary configuration assuming that 
> we use the same type, package/namespace and field/property names on both the 
> .NET and Java sides (or provide a custom name mapper for relaxed naming 
> conventions).
> h2. Reproducer
> h3. ICalculator.java
> {code:java}
> package Sandbox.Net;
> public interface ICalculator {
> Result Calculate(Parameter p);
> }
> {code}
> h3. Parameter.java
> {code:java}
> package Sandbox.Net;
> public class Parameter {
> private int id;
> private double val;
> public int getId() {
> return id;
> }
> public Parameter setId(int id) {
> this.id = id;
> return this;
> }
> public double getValue() {
> return val;
> }
> public Parameter setValue(double val) {
> this.val = val;
> return this;
> }
> }
> {code}
> h3. Result .java
> {code:java}
> package Sandbox.Net;
> public class Result {
> private int id;
> private double value;
> public int getId() {
> return id;
> }
> public Result setId(int id) {
> this.id = id;
> return this;
> }
> public double getValue() {
> return value;
> }
> public Result setValue(double val) {
> this.value = val;
> return this;
> }
> }
> {code}
> h3. IgniteCalculatorService.java
> {code:java}
> package Sandbox.Net;
> import org.apache.ignite.services.Service;
> import org.apache.ignite.services.ServiceContext;
> public class IgniteCalculatorService implements Service, ICalculator {
> @Override public Result Calculate(Parameter p) {
> return new Result().setId(p.getId()).setValue(p.getValue() * 
> p.getValue());
> }
> @Override public void cancel(ServiceContext ctx) {
> }
> @Override public void init(ServiceContext ctx) {
> }
> @Override public void execute(ServiceContext ctx) {
> }
> }
> {code}
> h3. build.gradle
> {code:groovy}
> plugins {
> id 'java'
> }
> group 'sandbox.net'
> version '1.0-SNAPSHOT'
> sourceCompatibility = 1.8
> repositories {
> mavenLocal()
> mavenCentral()
> }
> def igniteVer='2.8.0'
> dependencies {
> compile group: 'org.apache.ignite', name: 'ignite-core', version: 
> igniteVer
> testCompile group: 'junit', name: 'junit', version: '4.12'
> }
> {code}
> h3. ignite-config.xml
> {code:xml}
> 
> http://www.springframework.org/schema/beans";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans.xsd";>
>  class="org.apache.ignite.configuration.IgniteConfiguration">
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  class="org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder">
> 
> 
> 127.0.0.1:47500
> 
> 
> 
> 
> 
> 
> 
> 
> {code}
> h3. ICalculator.cs
> {code:c#}
> namespace Sandbox.Net
> {
> public interface ICalculator
> {
> Result Calculate(Parameter p);
> }
> }
> {code}
> h3. Parameter.cs
> {code:c#}
> namespace Sandbox.Net
> {
> public class Parameter
> {
> public int Id { get; set; }
> public double Value { get; set; }
> }
> }
> {code}
> h3. Result.cs
> {code:c#}
> namespace Sandbox.Net
> {
> public class 

[jira] [Issue Comment Deleted] (IGNITE-12676) .NET: Add partition-based AffinityCall and AffinityRun overloads

[Pavel Tupitsyn (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-12676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Tupitsyn updated IGNITE-12676:

Comment: was deleted

(was: {panel:title=Branch: [pull/7701/head] Base: [master] : Possible Blockers 
(113)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform C++ (Linux)*{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242239]]

{color:#d04437}PDS (Indexing){color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242278]]

{color:#d04437}Platform .NET (Long Running){color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242288]]

{color:#d04437}MVCC Cache 7{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242304]]

{color:#d04437}ZooKeeper (Discovery) 3{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242292]]

{color:#d04437}Cache 6{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242268]]

{color:#d04437}ZooKeeper (Discovery) 2{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242238]]

{color:#d04437}Cache 5{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242267]]

{color:#d04437}Cache 7{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242269]]

{color:#d04437}ZooKeeper (Discovery) 1{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242237]]

{color:#d04437}SPI{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242230]]

{color:#d04437}Examples{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242211]]

{color:#d04437}Scala (Examples){color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242235]]

{color:#d04437}Platform .NET (NuGet)*{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242289]]

{color:#d04437}Cache (Expiry Policy){color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242253]]

{color:#d04437}PDS 1{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242280]]

{color:#d04437}Streamers{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242228]]

{color:#d04437}Start Nodes{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242229]]

{color:#d04437}Platform .NET{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242284]]

{color:#d04437}Basic 1{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242242]]

{color:#d04437}MVCC Queries{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242248]]

{color:#d04437}JCache TCK 1.1{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242244]]

{color:#d04437}MVCC Cache 1{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242298]]

{color:#d04437}Queries 1{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242290]]

{color:#d04437}Cache 2{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242264]]

{color:#d04437}Thin Client: Java{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242221]]

{color:#d04437}JDBC Driver{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=524]]

{color:#d04437}Platform .NET (Core Linux){color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242285]]

{color:#d04437}MVCC PDS 2{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242308]]

{color:#d04437}Continuous Query 4{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242274]]

{color:#d04437}Cache 1{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242263]]

{color:#d04437}MVCC PDS 1{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242307]]

{color:#d04437}Continuous Query 3{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242273]]

{color:#d04437}Queries 2{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242225]]

{color:#d04437}Cache 8{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242270]]

{color:#d04437}ZooKeeper (Discovery) 4{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242293]]

{color:#d04437}MVCC PDS 4{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242310]]

{color:#d04437}Basic 3{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242243]]

{color:#d04437}MVCC Cache 5{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242302]]

{color:#d0

[jira] [Commented] (IGNITE-12919) Not all GridUuid renamed to IgniteUuid

[Ignite TC Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17088087#comment-17088087
 ] 

Ignite TC Bot commented on IGNITE-12919:


{panel:title=Branch: [pull/7699/head] Base: [master] : Possible Blockers 
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}[Licenses Headers]{color} [[tests 0 Exit Code 
|https://ci.ignite.apache.org/viewLog.html?buildId=5241511]]

{panel}
[TeamCity *--> Run :: All* 
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5241339&buildTypeId=IgniteTests24Java8_RunAll]

> Not all GridUuid renamed to IgniteUuid
> --
>
> Key: IGNITE-12919
> URL: https://issues.apache.org/jira/browse/IGNITE-12919
> Project: Ignite
>  Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Minor
> Fix For: 2.9
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> There are several places in javadocs and serialization mechanisms where 
> GridUuid is not renamed. For example:
> {noformat}
> /**
>  * Constructs {@code GridUuid} from a global and local identifiers.
>  ...
>  */
> public IgniteUuid(UUID gid, long locId) { ... }
> /**
>  * Reads {@link org.apache.ignite.lang.IgniteUuid} from input stream. 
>  ...
>  */
> @Nullable public static IgniteUuid readGridUuid(DataInput in) throws 
> IOException {...}
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-12676) .NET: Add partition-based AffinityCall and AffinityRun overloads

[Ignite TC Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17088043#comment-17088043
 ] 

Ignite TC Bot commented on IGNITE-12676:


{panel:title=Branch: [pull/7701/head] Base: [master] : Possible Blockers 
(113)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform C++ (Linux)*{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242239]]

{color:#d04437}PDS (Indexing){color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242278]]

{color:#d04437}Platform .NET (Long Running){color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242288]]

{color:#d04437}MVCC Cache 7{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242304]]

{color:#d04437}ZooKeeper (Discovery) 3{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242292]]

{color:#d04437}Cache 6{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242268]]

{color:#d04437}ZooKeeper (Discovery) 2{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242238]]

{color:#d04437}Cache 5{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242267]]

{color:#d04437}Cache 7{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242269]]

{color:#d04437}ZooKeeper (Discovery) 1{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242237]]

{color:#d04437}SPI{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242230]]

{color:#d04437}Examples{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242211]]

{color:#d04437}Scala (Examples){color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242235]]

{color:#d04437}Platform .NET (NuGet)*{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242289]]

{color:#d04437}Cache (Expiry Policy){color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242253]]

{color:#d04437}PDS 1{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242280]]

{color:#d04437}Streamers{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242228]]

{color:#d04437}Start Nodes{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242229]]

{color:#d04437}Platform .NET{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242284]]

{color:#d04437}Basic 1{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242242]]

{color:#d04437}MVCC Queries{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242248]]

{color:#d04437}JCache TCK 1.1{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242244]]

{color:#d04437}MVCC Cache 1{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242298]]

{color:#d04437}Queries 1{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242290]]

{color:#d04437}Cache 2{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242264]]

{color:#d04437}Thin Client: Java{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242221]]

{color:#d04437}JDBC Driver{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=524]]

{color:#d04437}Platform .NET (Core Linux){color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242285]]

{color:#d04437}MVCC PDS 2{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242308]]

{color:#d04437}Continuous Query 4{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242274]]

{color:#d04437}Cache 1{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242263]]

{color:#d04437}MVCC PDS 1{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242307]]

{color:#d04437}Continuous Query 3{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242273]]

{color:#d04437}Queries 2{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242225]]

{color:#d04437}Cache 8{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242270]]

{color:#d04437}ZooKeeper (Discovery) 4{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242293]]

{color:#d04437}MVCC PDS 4{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242310]]

{color:#d04437}Basic 3{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5242243]]

{color:#d04437}MVCC Cache 5{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?build

[jira] [Commented] (IGNITE-2890) .NET: Add CacheConfiguration.NodeFilter

[Pavel Tupitsyn (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-2890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087992#comment-17087992
 ] 

Pavel Tupitsyn commented on IGNITE-2890:


We can add a shortcut to `AttributeNodeFilter` as a first iteration (allow this 
in .NET config) - should cover 90% use cases.

> .NET: Add CacheConfiguration.NodeFilter
> ---
>
> Key: IGNITE-2890
> URL: https://issues.apache.org/jira/browse/IGNITE-2890
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Pavel Tupitsyn
>Priority: Major
>  Labels: .net
>
> See ServiceConfiguration.NodeFilter
> * Caches start earlier than platform => need to pass pointer for static 
> CacheConfigurations
> * For dynamic cache start, no need for pointers



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-12676) .NET: Add partition-based AffinityCall and AffinityRun overloads

[Pavel Tupitsyn (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087969#comment-17087969
 ] 

Pavel Tupitsyn commented on IGNITE-12676:
-

[~ashapkin] PR ready, please review: https://github.com/apache/ignite/pull/7701

> .NET: Add partition-based AffinityCall and AffinityRun overloads
> 
>
> Key: IGNITE-12676
> URL: https://issues.apache.org/jira/browse/IGNITE-12676
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Add partition-based AffinityCall and AffinityRun overloads to ICompute.See 
> corresponding methods in Java (IgniteCompute).
> Additionally, current affinity methods work through PlatformAbstractTask, 
> which does not lock partitions. We should refactor existing AffinityCall and 
> AffinityRun overloads to call corresponding IgniteCompute APIs.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-12905) QueryKeyValueIterable missing custom spliterator() implementation

[Johnny Galatikitis (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087956#comment-17087956
 ] 

Johnny Galatikitis commented on IGNITE-12905:
-

Hello [~cyberdemon], 

Thank you for fast reply!

I registered for CI bot, commited fixes for PR review concerns and will check 
TC results tomorrow. 

> QueryKeyValueIterable missing custom spliterator() implementation
> -
>
> Key: IGNITE-12905
> URL: https://issues.apache.org/jira/browse/IGNITE-12905
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, general
>Affects Versions: 2.8
> Environment: Windows 10
> JDK 1.8.0_172
> ignite-core 2.8.0
> reactor-core 3.3.3
>Reporter: Johnny Galatikitis
>Priority: Critical
> Fix For: 2.8.1
>
> Attachments: 
> IGNITE-12905_-_add_QueryKeyValueSpliterator_and_corresponding_test.patch
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> We are using apache ignite with reactor-core and since reactors upgrade from 
> 3.2.12 to 3.3.3 {code:java}
> org.apache.ignite.internal.processors.query.QueryKeyValueIterable.iterator
> {code}
> is called multiple times. It starts with:
> 1. calling iterable.spliterator().hasCharacteristics(Spliterator.SIZED), 
> where iterable is instanceof QueryKeyValueIterable
> 2. calls default implementation 
> Spliterators.spliteratorUnknownSize(iterator(), 0)
> 3. which in turn calls ignite's QueryKeyValueIterable.iterator() call and 
> that "uses it up" for subsequent calls, i.e. throw IgniteException "Iterator 
> is already fetched or query was cancelled."



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-12688) Improve performance of index inline JAVA_OBJECT fields

[Ignite TC Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087940#comment-17087940
 ] 

Ignite TC Bot commented on IGNITE-12688:


{panel:title=Branch: [pull/7685/head] Base: [master] : No blockers 
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All* 
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5240447&buildTypeId=IgniteTests24Java8_RunAll]

> Improve performance of index inline JAVA_OBJECT fields
> --
>
> Key: IGNITE-12688
> URL: https://issues.apache.org/jira/browse/IGNITE-12688
> Project: Ignite
>  Issue Type: Bug
>Reporter: Konstantin Orlov
>Assignee: Konstantin Orlov
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Inline JAVA_OBJECT may be reason of performance drop on index creation.
> The *root cause* is the low selectivity of current part of JAVA_OBJECT that 
> is inlined.
> Now first N bytes of binary view of object is placed into inline space of the 
> index.
> But the first offset where the two objects with the same type may be 
> different is 8 (HASH_CODE_POS).
> With default inline = 10 we NEVER inline it:
> Inline format:
> 1 byte - type,
> 2 bytes - size
> >> 7 bytes - data;
> *My proposal:*
> - For metapage v4 (BPlusMetaIO) add flag *inlineObjectHash*;
> - use this flag to work in compatibility mode.
> - inline ONLY hash for JAVA_OBJECT fields for new indexes;
> Also this approach solves the inconsistent between comparison JAVA_OBJECT by 
> inline and full value, because value comparator uses hash to compare object 
> before compare byte arrays.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-12676) .NET: Add partition-based AffinityCall and AffinityRun overloads

[Pavel Tupitsyn (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-12676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Tupitsyn updated IGNITE-12676:

Release Note: .NET: Added partition-based AffinityCall and AffinityRun 
overloads, fixed existing AffinityCall and AffinityRun to reserve partition

> .NET: Add partition-based AffinityCall and AffinityRun overloads
> 
>
> Key: IGNITE-12676
> URL: https://issues.apache.org/jira/browse/IGNITE-12676
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
>
> Add partition-based AffinityCall and AffinityRun overloads to ICompute.See 
> corresponding methods in Java (IgniteCompute).
> Additionally, current affinity methods work through PlatformAbstractTask, 
> which does not lock partitions. We should refactor existing AffinityCall and 
> AffinityRun overloads to call corresponding IgniteCompute APIs.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-12676) .NET: Add partition-based AffinityCall and AffinityRun overloads

[Pavel Tupitsyn (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-12676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Tupitsyn updated IGNITE-12676:

Ignite Flags: Release Notes Required  (was: Docs Required,Release Notes 
Required)

> .NET: Add partition-based AffinityCall and AffinityRun overloads
> 
>
> Key: IGNITE-12676
> URL: https://issues.apache.org/jira/browse/IGNITE-12676
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
>
> Add partition-based AffinityCall and AffinityRun overloads to ICompute.See 
> corresponding methods in Java (IgniteCompute).
> Additionally, current affinity methods work through PlatformAbstractTask, 
> which does not lock partitions. We should refactor existing AffinityCall and 
> AffinityRun overloads to call corresponding IgniteCompute APIs.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-12676) .NET: Add partition-based AffinityCall and AffinityRun overloads

[Pavel Tupitsyn (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-12676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Tupitsyn updated IGNITE-12676:

Labels: .NET  (was: .NET newbie)

> .NET: Add partition-based AffinityCall and AffinityRun overloads
> 
>
> Key: IGNITE-12676
> URL: https://issues.apache.org/jira/browse/IGNITE-12676
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
>
> Add partition-based AffinityCall and AffinityRun overloads to ICompute.See 
> corresponding methods in Java (IgniteCompute).
> Additionally, current affinity methods work through PlatformAbstractTask, 
> which does not lock partitions. We should refactor existing AffinityCall and 
> AffinityRun overloads to call corresponding IgniteCompute APIs.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-12922) SqlViewMetricExporterSpi is redundant entity

[Andrey N. Gura (Jira)]

Andrey N. Gura created IGNITE-12922:
---

 Summary: SqlViewMetricExporterSpi is redundant entity 
 Key: IGNITE-12922
 URL: https://issues.apache.org/jira/browse/IGNITE-12922
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.8
Reporter: Andrey N. Gura
 Fix For: 2.8.1


{{SqlViewMetricExporterSpi}} is redundant entity both in terms of design and in 
terms of user experience.

{{METRICS}} SQL view is the internal entity that could exist regardless of any 
exporters configuration. So it should be created on indexing module 
initialization. Also from an user stand point it is strange to configure 
special exporter in order to get access to the {{METRICS}} view via SQL.

See also IGNITE-12921.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-12525) Spring boot starter

[Dmitry Pavlov (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087900#comment-17087900
 ] 

Dmitry Pavlov commented on IGNITE-12525:


BTW, it may also worth to create separate versions for spring-boot-starter, so 
it the difference with main Apache Ignite releases could be more obvious. E.g. 
1.0-sprint-boot-starter.

> Spring boot starter
> ---
>
> Key: IGNITE-12525
> URL: https://issues.apache.org/jira/browse/IGNITE-12525
> Project: Ignite
>  Issue Type: Improvement
>  Components: spring
>Affects Versions: 2.7.6
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: spring-boot-autoconfigure, 
> spring-boot-client-autoconfigure
> Fix For: 1.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> To improve user experience with Ignite we should provide an 
> ignite-spring-boot-starter like many of other projects do.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-12701) Disallow silent deactivation in CLI and REST.

[Nikolay Izhikov (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-12701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nikolay Izhikov updated IGNITE-12701:
-
Fix Version/s: (was: 2.8.1)

> Disallow silent deactivation in CLI and REST.
> -
>
> Key: IGNITE-12701
> URL: https://issues.apache.org/jira/browse/IGNITE-12701
> Project: Ignite
>  Issue Type: Sub-task
>Affects Versions: 2.7.6
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 7.5h
>  Remaining Estimate: 0h
>
> Disallow silent deactivation through the CLI and REST. 
> Skip JMX call 
> {code:java}
> void IgniteMXBean#active(boolean active)
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-12479) All binary types are registered twice

[Nikolay Izhikov (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-12479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nikolay Izhikov updated IGNITE-12479:
-
Fix Version/s: 2.8.1

> All binary types are registered twice
> -
>
> Key: IGNITE-12479
> URL: https://issues.apache.org/jira/browse/IGNITE-12479
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>Priority: Major
> Fix For: 2.9, 2.8.1
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> When a POJO is put into a cache, its binary type is registered twice during 
> marshalling.
> Example:
> {code:java}
> public class MetadataRegistrationExample {
> public static void main(String[] args) {
> Ignite ignite = Ignition.start("config/ignite.xml");
> Person p = new Person("Denis");
> ignite.getOrCreateCache("cache").put(1, p);
> }
> static class Person {
> private String name;
> public Person(String name) {
> this.name = name;
> }
> }
> }
> {code}
>  
> Here is the generated debug log from the package
> {noformat}
> [23:31:14,020][DEBUG][main][CacheObjectBinaryProcessorImpl] Requesting 
> metadata update [typeId=-1210012928, 
> typeName=binary.NestedObjectMarshallingExample$Person, changedSchemas=[], 
> holder=null, fut=MetadataUpdateResultFuture [key=SyncKey [typeId=-1210012928, 
> ver=0]]]
> [23:31:14,023][DEBUG][disco-notifier-worker-#41][CacheObjectBinaryProcessorImpl]
>  Received MetadataUpdateProposedListener [typeId=-1210012928, 
> typeName=binary.NestedObjectMarshallingExample$Person, pendingVer=0, 
> acceptedVer=0, schemasCnt=0]
> [23:31:14,024][DEBUG][disco-notifier-worker-#41][CacheObjectBinaryProcessorImpl]
>  Versions are stamped on coordinator [typeId=-1210012928, changedSchemas=[], 
> pendingVer=1, acceptedVer=0]
> [23:31:14,024][DEBUG][disco-notifier-worker-#41][CacheObjectBinaryProcessorImpl]
>  Updated metadata on originating node: [typeId=-1210012928, pendingVer=1, 
> acceptedVer=0]
> [23:31:14,025][DEBUG][disco-notifier-worker-#41][CacheObjectBinaryProcessorImpl]
>  Received MetadataUpdateAcceptedMessage MetadataUpdateAcceptedMessage 
> [id=599e0a86c61-183a790b-7038-4dd5-b99d-89f1483e3635, typeId=-1210012928, 
> acceptedVer=1, duplicated=false]
> [23:31:14,025][DEBUG][disco-notifier-worker-#41][CacheObjectBinaryProcessorImpl]
>  Completing future MetadataUpdateResultFuture [key=SyncKey 
> [typeId=-1210012928, ver=1]] for [typeId=-1210012928, pendingVer=1, 
> acceptedVer=1]
> [23:31:14,026][DEBUG][main][CacheObjectBinaryProcessorImpl] Completed 
> metadata update [typeId=-1210012928, 
> typeName=binary.NestedObjectMarshallingExample$Person, waitTime=4ms, 
> fut=MetadataUpdateResultFuture [key=SyncKey [typeId=-1210012928, ver=1]], 
> tx=null]
> [23:31:14,027][DEBUG][main][CacheObjectBinaryProcessorImpl] Requesting 
> metadata update [typeId=-1210012928, 
> typeName=binary.NestedObjectMarshallingExample$Person, 
> changedSchemas=[1975878747], holder=[typeId=-1210012928, pendingVer=1, 
> acceptedVer=1], fut=MetadataUpdateResultFuture [key=SyncKey 
> [typeId=-1210012928, ver=0]]]
> [23:31:14,027][DEBUG][disco-notifier-worker-#41][CacheObjectBinaryProcessorImpl]
>  Received MetadataUpdateProposedListener [typeId=-1210012928, 
> typeName=binary.NestedObjectMarshallingExample$Person, pendingVer=0, 
> acceptedVer=0, schemasCnt=1]
> [23:31:14,028][DEBUG][disco-notifier-worker-#41][CacheObjectBinaryProcessorImpl]
>  Versions are stamped on coordinator [typeId=-1210012928, 
> changedSchemas=[1975878747], pendingVer=2, acceptedVer=1]
> [23:31:14,028][DEBUG][disco-notifier-worker-#41][CacheObjectBinaryProcessorImpl]
>  Updated metadata on originating node: [typeId=-1210012928, pendingVer=2, 
> acceptedVer=1]
> [23:31:14,028][DEBUG][disco-notifier-worker-#41][CacheObjectBinaryProcessorImpl]
>  Received MetadataUpdateAcceptedMessage MetadataUpdateAcceptedMessage 
> [id=d99e0a86c61-183a790b-7038-4dd5-b99d-89f1483e3635, typeId=-1210012928, 
> acceptedVer=2, duplicated=false]
> [23:31:14,028][DEBUG][disco-notifier-worker-#41][CacheObjectBinaryProcessorImpl]
>  Completing future MetadataUpdateResultFuture [key=SyncKey 
> [typeId=-1210012928, ver=2]] for [typeId=-1210012928, pendingVer=2, 
> acceptedVer=2]
> [23:31:14,029][DEBUG][main][CacheObjectBinaryProcessorImpl] Completed 
> metadata update [typeId=-1210012928, 
> typeName=binary.NestedObjectMarshallingExample$Person, waitTime=1ms, 
> fut=MetadataUpdateResultFuture [key=SyncKey [typeId=-1210012928, ver=2]], 
> tx=null]
> {noformat}
> You can see, that a type is registered twice. First it's registered without 
> any fields, and only the second time the type is registered properly.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-12545) Introduce listener interface for components to react to partition map exchange events

[Nikolay Izhikov (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-12545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nikolay Izhikov updated IGNITE-12545:
-
Fix Version/s: 2.8.1

> Introduce listener interface for components to react to partition map 
> exchange events
> -
>
> Key: IGNITE-12545
> URL: https://issues.apache.org/jira/browse/IGNITE-12545
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Rakov
>Assignee: Ivan Rakov
>Priority: Major
> Fix For: 2.9, 2.8.1
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> It would be handly to have listener interface for components that should 
> react to PME instead of just adding more and more calls to 
> GridDhtPartitionsExchangeFuture.
> In general, there are four possible moments when a compnent can be notified: 
> on exchnage init (before and after topologies are updates and exchange latch 
> is acquired) and on exchange done (before and after readyTopVer is 
> incremented and user operations are unlocked).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-12921) System views design leads to bad user expirience.

[Andrey N. Gura (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-12921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrey N. Gura updated IGNITE-12921:

Summary: System views design leads to bad user expirience.  (was: System 
view design leads to bad user expirience.)

> System views design leads to bad user expirience.
> -
>
> Key: IGNITE-12921
> URL: https://issues.apache.org/jira/browse/IGNITE-12921
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Andrey N. Gura
>Priority: Critical
>  Labels: IEP-35
> Fix For: 2.8.1
>
>
> Current implementation of system views has broken system behavior which is 
> related with querying system views. 
> Before 2.8 system views were available via SQL queries (if indexing is 
> enabled). It did not depend on any configuration. 
> After implementation of IGNITE-12145 system views available only if 
> {{SqlViewExporterSpi}} is passed to 
> {{IgniteConfiguration.setSystemViewExporterSpi()}}. Now, if an user 
> configures some {{SystemViewExporterSpi}} then provided user configuration 
> will rewrite default configuration and {{SqlViewExporterSpi}} won't be 
> initialized. As result it is impossible to query system views and any query 
> to the views fails with exception. This behavior is not obvious for the user. 
> See tests below.
> The second problem is kind of design problem. System view is internal part of 
> the system and should be available regardless of any exporter configuration 
> (at least via SQL) such as it was implemented before 2.8 release. 
> My suggestion is the following: we should remove {{SqlViewExporterSpi}} and 
> configure all views on indexing module initialization. {{SqlViewExporterSPI}} 
> also doesn't make sense because:
> - it operates by some internal API ({{SchemaManager}}, {{GridKernalContext}}, 
> {{IgniteH2Indexing}}).
> - it doesn't allow to end user to add any new system view.
> Only thing that could be useful is a filtering. But it could be done with SQL.
> Reproducer of broken behavior:
> {code:java}
> package org.apache.ignite.internal.processors.cache.metric;
> import org.apache.ignite.cache.query.SqlFieldsQuery;
> import org.apache.ignite.cluster.ClusterState;
> import org.apache.ignite.configuration.DataRegionConfiguration;
> import org.apache.ignite.configuration.DataStorageConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.internal.IgniteEx;
> import org.apache.ignite.spi.systemview.jmx.JmxSystemViewExporterSpi;
> import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
> import org.junit.Test;
> import java.util.HashSet;
> import java.util.List;
> import java.util.Set;
> import static java.util.Arrays.asList;
> import static 
> org.apache.ignite.internal.processors.cache.index.AbstractSchemaSelfTest.queryProcessor;
> public class SystemViewTest extends GridCommonAbstractTest {
> private static boolean useDefaultSpi;
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String 
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> cfg.setConsistentId(igniteInstanceName);
> cfg.setDataStorageConfiguration(new DataStorageConfiguration()
> .setDataRegionConfigurations(
> new 
> DataRegionConfiguration().setName("in-memory").setMaxSize(100L * 1024 * 1024))
> .setDefaultDataRegionConfiguration(
> new DataRegionConfiguration()
> .setPersistenceEnabled(true)));
> if (!useDefaultSpi) {
> // Configure user provided system view exporter SPI.
> cfg.setSystemViewExporterSpi(new JmxSystemViewExporterSpi());
> }
> return cfg;
> }
> /**
>  * Will executed succefully.
>  */
> @Test
> public void testSystemViewWithDefaultSpi() throws Exception {
> useDefaultSpi = true;
> doTestSystemView();
> }
> /**
>  * Will fail with Table "VIEWS" not found.
>  */
> @Test
> public void testSystemViewWithCustomSpi() throws Exception {
> useDefaultSpi = false;
> doTestSystemView();
> }
> private void doTestSystemView() throws Exception {
> try (IgniteEx ignite = startGrid()) {
> ignite.cluster().state(ClusterState.ACTIVE);
> Set cacheNames = new HashSet<>(asList("cache-1", 
> "cache-2"));
> for (String name : cacheNames)
> ignite.getOrCreateCache(name);
> SqlFieldsQuery qry = new SqlFieldsQuery("SELECT * FROM 
> SYS.VIEWS");
> List> res = queryProcessor(ignite).querySqlFields(qry, 
> true).getAll();
> res.

[jira] [Created] (IGNITE-12921) System view design leads to bad user expirience.

[Andrey N. Gura (Jira)]

Andrey N. Gura created IGNITE-12921:
---

 Summary: System view design leads to bad user expirience.
 Key: IGNITE-12921
 URL: https://issues.apache.org/jira/browse/IGNITE-12921
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.8
Reporter: Andrey N. Gura
 Fix For: 2.8.1


Current implementation of system views has broken system behavior which is 
related with querying system views. 

Before 2.8 system views were available via SQL queries (if indexing is 
enabled). It did not depend on any configuration. 

After implementation of IGNITE-12145 system views available only if 
{{SqlViewExporterSpi}} is passed to 
{{IgniteConfiguration.setSystemViewExporterSpi()}}. Now, if an user configures 
some {{SystemViewExporterSpi}} then provided user configuration will rewrite 
default configuration and {{SqlViewExporterSpi}} won't be initialized. As 
result it is impossible to query system views and any query to the views fails 
with exception. This behavior is not obvious for the user. See tests below.

The second problem is kind of design problem. System view is internal part of 
the system and should be available regardless of any exporter configuration (at 
least via SQL) such as it was implemented before 2.8 release. 

My suggestion is the following: we should remove {{SqlViewExporterSpi}} and 
configure all views on indexing module initialization. {{SqlViewExporterSPI}} 
also doesn't make sense because:
- it operates by some internal API ({{SchemaManager}}, {{GridKernalContext}}, 
{{IgniteH2Indexing}}).
- it doesn't allow to end user to add any new system view.

Only thing that could be useful is a filtering. But it could be done with SQL.

Reproducer of broken behavior:

{code:java}
package org.apache.ignite.internal.processors.cache.metric;

import org.apache.ignite.cache.query.SqlFieldsQuery;
import org.apache.ignite.cluster.ClusterState;
import org.apache.ignite.configuration.DataRegionConfiguration;
import org.apache.ignite.configuration.DataStorageConfiguration;
import org.apache.ignite.configuration.IgniteConfiguration;
import org.apache.ignite.internal.IgniteEx;
import org.apache.ignite.spi.systemview.jmx.JmxSystemViewExporterSpi;
import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
import org.junit.Test;

import java.util.HashSet;
import java.util.List;
import java.util.Set;

import static java.util.Arrays.asList;
import static 
org.apache.ignite.internal.processors.cache.index.AbstractSchemaSelfTest.queryProcessor;

public class SystemViewTest extends GridCommonAbstractTest {

private static boolean useDefaultSpi;

/** {@inheritDoc} */
@Override protected IgniteConfiguration getConfiguration(String 
igniteInstanceName) throws Exception {
IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);

cfg.setConsistentId(igniteInstanceName);

cfg.setDataStorageConfiguration(new DataStorageConfiguration()
.setDataRegionConfigurations(
new 
DataRegionConfiguration().setName("in-memory").setMaxSize(100L * 1024 * 1024))
.setDefaultDataRegionConfiguration(
new DataRegionConfiguration()
.setPersistenceEnabled(true)));

if (!useDefaultSpi) {
// Configure user provided system view exporter SPI.
cfg.setSystemViewExporterSpi(new JmxSystemViewExporterSpi());
}

return cfg;
}

/**
 * Will executed succefully.
 */
@Test
public void testSystemViewWithDefaultSpi() throws Exception {
useDefaultSpi = true;

doTestSystemView();
}

/**
 * Will fail with Table "VIEWS" not found.
 */
@Test
public void testSystemViewWithCustomSpi() throws Exception {
useDefaultSpi = false;

doTestSystemView();
}

private void doTestSystemView() throws Exception {
try (IgniteEx ignite = startGrid()) {
ignite.cluster().state(ClusterState.ACTIVE);

Set cacheNames = new HashSet<>(asList("cache-1", 
"cache-2"));

for (String name : cacheNames)
ignite.getOrCreateCache(name);

SqlFieldsQuery qry = new SqlFieldsQuery("SELECT * FROM SYS.VIEWS");

List> res = queryProcessor(ignite).querySqlFields(qry, 
true).getAll();

res.forEach(item -> log.info("VIEW FOUND: " + item));
}
}

}
{code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-12525) Spring boot starter

[Dmitry Pavlov (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087854#comment-17087854
 ] 

Dmitry Pavlov commented on IGNITE-12525:


Hi [~nizhikov], yes, it seems for that case Phase 4 is actual. For main Apache 
Ignite release there are a lot of automation,  as well as, additional modules 
to be released. Almost all of these steps can be skipped.

It may worth to document specific steps that needs to be done for releasing 
spring-boot-starter.

> Spring boot starter
> ---
>
> Key: IGNITE-12525
> URL: https://issues.apache.org/jira/browse/IGNITE-12525
> Project: Ignite
>  Issue Type: Improvement
>  Components: spring
>Affects Versions: 2.7.6
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: spring-boot-autoconfigure, 
> spring-boot-client-autoconfigure
> Fix For: 1.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> To improve user experience with Ignite we should provide an 
> ignite-spring-boot-starter like many of other projects do.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-12920) Static hierarchy in jmx tree

[Igor Akkuratov (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-12920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Akkuratov updated IGNITE-12920:

Description: 
Current jmx tree hierarchy depends on jvm and ignite options and contains 
classloader by default.

!image-2020-04-20-17-05-36-451.png!

Monitoring systems like zabbix use bean path to discover metrics. Classloader 
is been changing after node restart and monitoring systems rediscover new 
metrics. If you'll try to disable classloader with option
{code:java}
IGNITE_MBEAN_APPEND_CLASS_LOADER_ID=false{code}
the jmx tree will exclude one level. This behavior excludes an opportunity to 
create single monitoring template for different deployments. It can also make 
troubles if you want to start more then one ignite instance in single jvm. In 
this case you'll have to set {color:#1d1c1d}igniteInstanceName{color} property 
to add one more level with the name of this instance. It will affect jmx tree 
hierarchy as well. 

 I propose to make hierarchy unchangeable and select one of the following 
values.

If exist instancename

else if exist consistantId

 

In cases with enabled persistent storage consistent id  would be the same 
between node restarts, in in-memory cases you will be able to specify 
instanceName.

  was:
Current jmx tree hierarchy depends on jvm and ignite options and by default 
contains classloader.

!image-2020-04-20-17-05-36-451.png!

Monitoring systems like zabbix use bean path to discover metrics. In this case 
classloader would be new after each node restart. If you'll disable classloader 
with option {color:#1d1c1d}{color}
{code:java}
IGNITE_MBEAN_APPEND_CLASS_LOADER_ID=false{code}
{color:#1d1c1d}{color} the jmx tree would exclude one level. This behavior 
excludes an opportunity to create single monitoring template for different 
deployments. And make troubles if you want to start more then one ignite 
instance in single jvm. In this case you should set 
{color:#1d1c1d}igniteInstanceName{color} property to add one more level with 
instance name. And it's also changes jmx tree hierarchy.

 

I offer to make hierarchy unchangeable and select one of the following values.

If exist instancename

else if exist consistantId

 

In persistent cases consistent id  would be the same between node restarts.


> Static hierarchy in jmx tree
> 
>
> Key: IGNITE-12920
> URL: https://issues.apache.org/jira/browse/IGNITE-12920
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Igor Akkuratov
>Assignee: Igor Akkuratov
>Priority: Major
> Attachments: image-2020-04-20-17-05-36-451.png
>
>
> Current jmx tree hierarchy depends on jvm and ignite options and contains 
> classloader by default.
> !image-2020-04-20-17-05-36-451.png!
> Monitoring systems like zabbix use bean path to discover metrics. Classloader 
> is been changing after node restart and monitoring systems rediscover new 
> metrics. If you'll try to disable classloader with option
> {code:java}
> IGNITE_MBEAN_APPEND_CLASS_LOADER_ID=false{code}
> the jmx tree will exclude one level. This behavior excludes an opportunity to 
> create single monitoring template for different deployments. It can also make 
> troubles if you want to start more then one ignite instance in single jvm. In 
> this case you'll have to set {color:#1d1c1d}igniteInstanceName{color} 
> property to add one more level with the name of this instance. It will affect 
> jmx tree hierarchy as well. 
>  I propose to make hierarchy unchangeable and select one of the following 
> values.
> If exist instancename
> else if exist consistantId
>  
> In cases with enabled persistent storage consistent id  would be the same 
> between node restarts, in in-memory cases you will be able to specify 
> instanceName.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-12920) Static hierarchy in jmx tree

[Igor Akkuratov (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-12920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Akkuratov updated IGNITE-12920:

Attachment: (was: image-2020-04-20-17-05-16-972.png)

> Static hierarchy in jmx tree
> 
>
> Key: IGNITE-12920
> URL: https://issues.apache.org/jira/browse/IGNITE-12920
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Igor Akkuratov
>Assignee: Igor Akkuratov
>Priority: Major
> Attachments: image-2020-04-20-17-05-36-451.png
>
>
> Current jmx tree hierarchy depends on jvm and ignite options and contains 
> classloader by default.
> !image-2020-04-20-17-05-36-451.png!
> Monitoring systems like zabbix use bean path to discover metrics. Classloader 
> is been changing after node restart and monitoring systems rediscover new 
> metrics. If you'll try to disable classloader with option
> {code:java}
> IGNITE_MBEAN_APPEND_CLASS_LOADER_ID=false{code}
> the jmx tree will exclude one level. This behavior excludes an opportunity to 
> create single monitoring template for different deployments. It can also make 
> troubles if you want to start more then one ignite instance in single jvm. In 
> this case you'll have to set {color:#1d1c1d}igniteInstanceName{color} 
> property to add one more level with the name of this instance. It will affect 
> jmx tree hierarchy as well. 
>  I propose to make hierarchy unchangeable and select one of the following 
> values.
> If exist instancename
> else if exist consistantId
>  
> In cases with enabled persistent storage consistent id  would be the same 
> between node restarts, in in-memory cases you will be able to specify 
> instanceName.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-12525) Spring boot starter

[Nikolay Izhikov (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087825#comment-17087825
 ] 

Nikolay Izhikov commented on IGNITE-12525:
--

Hello [~dpavlov]

I want to release extensions created in the scope of this ticket.

I read the guide for release - 
[https://cwiki.apache.org/confluence/display/IGNITE/Release+Process]

It seems I can start with the "P4. Vote preparation (building release 
candidate)" of the guide.
Can you confirm it? Or suggest another way to perform release.

> Spring boot starter
> ---
>
> Key: IGNITE-12525
> URL: https://issues.apache.org/jira/browse/IGNITE-12525
> Project: Ignite
>  Issue Type: Improvement
>  Components: spring
>Affects Versions: 2.7.6
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: spring-boot-autoconfigure, 
> spring-boot-client-autoconfigure
> Fix For: 1.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> To improve user experience with Ignite we should provide an 
> ignite-spring-boot-starter like many of other projects do.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-12904) Add method IgniteSecurity#securityContext(UUID subjId)

[Nikolay Izhikov (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087815#comment-17087815
 ] 

Nikolay Izhikov commented on IGNITE-12904:
--

Hello [~garus.d.g]

I reviewed your patch and have couple of comment:

1. For now, we have `IgniteSpiContext#authenticatedSubject(UUID subjId)` which 
is the same method as you suggested to add.
2. It's not clear for me, who and when should use this new method.
3. If we want to provide this method to the user we should do the following:
а. Add `authenticatedSubject(UUID subjId)` to the PluginContext to provide 
this feature into plugins.
b. Add `IgniteSecurity` public interface and methods 
`Collection authenticatedSubjects()`, `SecuritySubject 
authenticatedSubject(UUID subjId)` to it to provide this feature into public 
API.

It seems we should discuss this improvement on the dev-list.
Does it makes sense for you?



> Add method IgniteSecurity#securityContext(UUID subjId)
> --
>
> Key: IGNITE-12904
> URL: https://issues.apache.org/jira/browse/IGNITE-12904
> Project: Ignite
>  Issue Type: Improvement
>  Components: security
>Reporter: Denis Garus
>Assignee: Denis Garus
>Priority: Major
>  Labels: iep-41
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We should add method IgniteSecurity#securityContext(UUID subjId) to allow 
> users to get a security subject info.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (IGNITE-12904) Add method IgniteSecurity#securityContext(UUID subjId)

[Nikolay Izhikov (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087815#comment-17087815
 ] 

Nikolay Izhikov edited comment on IGNITE-12904 at 4/20/20, 2:54 PM:


Hello [~garus.d.g]

I reviewed your patch and have couple of comment:

* For now, we have `IgniteSpiContext#authenticatedSubject(UUID subjId)` which 
is the same method as you suggested to add.
* It's not clear for me, who and when should use this new method.
* If we want to provide this method to the user we should do the following:
 ** Add `authenticatedSubject(UUID subjId)` to the PluginContext to provide 
this feature into plugins.
** Add `IgniteSecurity` public interface and methods 
`Collection authenticatedSubjects()`, `SecuritySubject 
authenticatedSubject(UUID subjId)` to it to provide this feature into public 
API.

It seems we should discuss this improvement on the dev-list.
Does it makes sense for you?




was (Author: nizhikov):
Hello [~garus.d.g]

I reviewed your patch and have couple of comment:

1. For now, we have `IgniteSpiContext#authenticatedSubject(UUID subjId)` which 
is the same method as you suggested to add.
2. It's not clear for me, who and when should use this new method.
3. If we want to provide this method to the user we should do the following:
а. Add `authenticatedSubject(UUID subjId)` to the PluginContext to provide 
this feature into plugins.
b. Add `IgniteSecurity` public interface and methods 
`Collection authenticatedSubjects()`, `SecuritySubject 
authenticatedSubject(UUID subjId)` to it to provide this feature into public 
API.

It seems we should discuss this improvement on the dev-list.
Does it makes sense for you?



> Add method IgniteSecurity#securityContext(UUID subjId)
> --
>
> Key: IGNITE-12904
> URL: https://issues.apache.org/jira/browse/IGNITE-12904
> Project: Ignite
>  Issue Type: Improvement
>  Components: security
>Reporter: Denis Garus
>Assignee: Denis Garus
>Priority: Major
>  Labels: iep-41
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We should add method IgniteSecurity#securityContext(UUID subjId) to allow 
> users to get a security subject info.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-12920) Static hierarchy in jmx tree

[Igor Akkuratov (Jira)]

Igor Akkuratov created IGNITE-12920:
---

 Summary: Static hierarchy in jmx tree
 Key: IGNITE-12920
 URL: https://issues.apache.org/jira/browse/IGNITE-12920
 Project: Ignite
  Issue Type: Improvement
Reporter: Igor Akkuratov
Assignee: Igor Akkuratov
 Attachments: image-2020-04-20-17-05-16-972.png, 
image-2020-04-20-17-05-36-451.png

Current jmx tree hierarchy depends on jvm and ignite options and by default 
contains classloader.

!image-2020-04-20-17-05-36-451.png!

Monitoring systems like zabbix use bean path to discover metrics. In this case 
classloader would be new after each node restart. If you'll disable classloader 
with option {color:#1d1c1d}{color}
{code:java}
IGNITE_MBEAN_APPEND_CLASS_LOADER_ID=false{code}
{color:#1d1c1d}{color} the jmx tree would exclude one level. This behavior 
excludes an opportunity to create single monitoring template for different 
deployments. And make troubles if you want to start more then one ignite 
instance in single jvm. In this case you should set 
{color:#1d1c1d}igniteInstanceName{color} property to add one more level with 
instance name. And it's also changes jmx tree hierarchy.

 

I offer to make hierarchy unchangeable and select one of the following values.

If exist instancename

else if exist consistantId

 

In persistent cases consistent id  would be the same between node restarts.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (IGNITE-12901) SQL: Uncorrelated subquery should run only once.

[Ivan Daschinskiy (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087750#comment-17087750
 ] 

Ivan Daschinskiy edited comment on IGNITE-12901 at 4/20/20, 1:50 PM:
-

[~kukushal][~nizhikov] I found, that this feature is supported in H2 by 
default, but intentionally switched off. However, it's possible to enable it in 
similar manner, as {{SqlFieldsQuery#setLazy}} or  
{{SqlFieldsQuery#setEnforceJoinOrder}} manner and switched off by default. WDYT?

N.B. Also, this feature is conflicted with lazy flag (it's is understandable). 
So I suggests to throw an error if both these flags are true.


was (Author: ivandasch):
[~kukushal][~nizhikov] I found, that this feature is supported in H2 by 
default, but intentionally switched off. However, it's possible to enable it in 
similar manner, as {{SqlFieldsQuery#setLazy}} or  
{{SqlFieldsQuery#setEnforceJoinOrder}} manner and switched off by default. WDYT?

> SQL: Uncorrelated subquery should run only once.
> 
>
> Key: IGNITE-12901
> URL: https://issues.apache.org/jira/browse/IGNITE-12901
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Assignee: Ivan Daschinskiy
>Priority: Major
>  Labels: sbcf
>
> Currently uncorrelated subqueries (where subquery is not depends on the outer 
> query) are executed on each nested loop iteration in the 
> org.h2.command.dml.Select#isConditionMet method. 
> We may avoid this, for example, using results caching.
> h2. Reproducer
> {code:java}
> public class SubQueryTest extends AbstractIndexingCommonTest {
> /** Keys counts at the RIGHT table. */
> private static final int RIGHT_CNT = 10;
> /** Keys counts at the LEFT table. */
> private static final int LEFT_CNT = 50;
> /** {@inheritDoc} */
> @SuppressWarnings("unchecked")
> @Override protected void beforeTest() throws Exception {
> super.beforeTest();
> startGrids(1);
> IgniteCache cacheA = grid(0).createCache(new CacheConfiguration Long>()
> .setName("A")
> .setSqlSchema("TEST")
> .setQueryEntities(Collections.singleton(new 
> QueryEntity(Long.class.getTypeName(), "A_VAL")
> .setTableName("A")
> .addQueryField("ID", Long.class.getName(), null)
> .addQueryField("JID", Long.class.getName(), null)
> .addQueryField("VAL", Long.class.getName(), null)
> .setKeyFieldName("ID")
> )));
> IgniteCache cacheB = grid(0).createCache(new CacheConfiguration()
> .setCacheMode(CacheMode.REPLICATED)
> .setName("B")
> .setSqlSchema("TEST")
> .setQueryEntities(Collections.singleton(new 
> QueryEntity(Long.class.getName(), "B_VAL")
> .setTableName("B")
> .addQueryField("ID", Long.class.getName(), null)
> .addQueryField("A_JID", Long.class.getName(), null)
> .addQueryField("VAL0", String.class.getName(), null)
> .setKeyFieldName("ID")
> )));
> Map batch = new HashMap<>();
> for (long i = 0; i < LEFT_CNT; ++i) {
> batch.put(i, grid(0).binary().builder("A_VAL")
> .setField("JID", i % RIGHT_CNT)
> .setField("VAL", i)
> .build());
> if (batch.size() > 1000) {
> cacheA.putAll(batch);
> batch.clear();
> }
> }
> if (batch.size() > 0) {
> cacheA.putAll(batch);
> batch.clear();
> }
> for (long i = 0; i < RIGHT_CNT; ++i)
> cacheB.put(i, grid(0).binary().builder("B_VAL")
> .setField("A_JID", i)
> .setField("VAL0", String.format("val%03d", i))
> .build());
> }
> /** {@inheritDoc} */
> @Override protected void afterTest() throws Exception {
> stopAllGrids();
> super.afterTest();
> }
> /**
>  * Test local query execution.
>  */
> @Test
> public void test() {
> sql(true, "SELECT * FROM A WHERE A.JID IN (SELECT A_JID FROM 
> B)").getAll();
> }
> /**
>  * @param enforceJoinOrder Enforce join order mode.
>  * @param sql SQL query.
>  * @param args Query parameters.
>  * @return Results cursor.
>  */
> private FieldsQueryCursor> sql(boolean enforceJoinOrder, String 
> sql, Object... args) {
> return grid(0).context().query().querySqlFields(new 
> SqlFieldsQuery(sql)
> .setSchema("TEST")
> .setLazy(true)
> .setEnforceJoinOrder(enforceJoinOrder)
>  

[jira] [Comment Edited] (IGNITE-12901) SQL: Uncorrelated subquery should run only once.

[Ivan Daschinskiy (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087750#comment-17087750
 ] 

Ivan Daschinskiy edited comment on IGNITE-12901 at 4/20/20, 1:50 PM:
-

[~kukushal] [~nizhikov] I found, that this feature is supported in H2 by 
default, but intentionally switched off. However, it's possible to enable it in 
similar manner, as {{SqlFieldsQuery#setLazy}} or  
{{SqlFieldsQuery#setEnforceJoinOrder}} manner and switched off by default. WDYT?

N.B. Also, this feature is conflicted with lazy flag (it's is understandable). 
So I suggests to throw an error if both these flags are true.


was (Author: ivandasch):
[~kukushal][~nizhikov] I found, that this feature is supported in H2 by 
default, but intentionally switched off. However, it's possible to enable it in 
similar manner, as {{SqlFieldsQuery#setLazy}} or  
{{SqlFieldsQuery#setEnforceJoinOrder}} manner and switched off by default. WDYT?

N.B. Also, this feature is conflicted with lazy flag (it's is understandable). 
So I suggests to throw an error if both these flags are true.

> SQL: Uncorrelated subquery should run only once.
> 
>
> Key: IGNITE-12901
> URL: https://issues.apache.org/jira/browse/IGNITE-12901
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Assignee: Ivan Daschinskiy
>Priority: Major
>  Labels: sbcf
>
> Currently uncorrelated subqueries (where subquery is not depends on the outer 
> query) are executed on each nested loop iteration in the 
> org.h2.command.dml.Select#isConditionMet method. 
> We may avoid this, for example, using results caching.
> h2. Reproducer
> {code:java}
> public class SubQueryTest extends AbstractIndexingCommonTest {
> /** Keys counts at the RIGHT table. */
> private static final int RIGHT_CNT = 10;
> /** Keys counts at the LEFT table. */
> private static final int LEFT_CNT = 50;
> /** {@inheritDoc} */
> @SuppressWarnings("unchecked")
> @Override protected void beforeTest() throws Exception {
> super.beforeTest();
> startGrids(1);
> IgniteCache cacheA = grid(0).createCache(new CacheConfiguration Long>()
> .setName("A")
> .setSqlSchema("TEST")
> .setQueryEntities(Collections.singleton(new 
> QueryEntity(Long.class.getTypeName(), "A_VAL")
> .setTableName("A")
> .addQueryField("ID", Long.class.getName(), null)
> .addQueryField("JID", Long.class.getName(), null)
> .addQueryField("VAL", Long.class.getName(), null)
> .setKeyFieldName("ID")
> )));
> IgniteCache cacheB = grid(0).createCache(new CacheConfiguration()
> .setCacheMode(CacheMode.REPLICATED)
> .setName("B")
> .setSqlSchema("TEST")
> .setQueryEntities(Collections.singleton(new 
> QueryEntity(Long.class.getName(), "B_VAL")
> .setTableName("B")
> .addQueryField("ID", Long.class.getName(), null)
> .addQueryField("A_JID", Long.class.getName(), null)
> .addQueryField("VAL0", String.class.getName(), null)
> .setKeyFieldName("ID")
> )));
> Map batch = new HashMap<>();
> for (long i = 0; i < LEFT_CNT; ++i) {
> batch.put(i, grid(0).binary().builder("A_VAL")
> .setField("JID", i % RIGHT_CNT)
> .setField("VAL", i)
> .build());
> if (batch.size() > 1000) {
> cacheA.putAll(batch);
> batch.clear();
> }
> }
> if (batch.size() > 0) {
> cacheA.putAll(batch);
> batch.clear();
> }
> for (long i = 0; i < RIGHT_CNT; ++i)
> cacheB.put(i, grid(0).binary().builder("B_VAL")
> .setField("A_JID", i)
> .setField("VAL0", String.format("val%03d", i))
> .build());
> }
> /** {@inheritDoc} */
> @Override protected void afterTest() throws Exception {
> stopAllGrids();
> super.afterTest();
> }
> /**
>  * Test local query execution.
>  */
> @Test
> public void test() {
> sql(true, "SELECT * FROM A WHERE A.JID IN (SELECT A_JID FROM 
> B)").getAll();
> }
> /**
>  * @param enforceJoinOrder Enforce join order mode.
>  * @param sql SQL query.
>  * @param args Query parameters.
>  * @return Results cursor.
>  */
> private FieldsQueryCursor> sql(boolean enforceJoinOrder, String 
> sql, Object... args) {
> return grid(0).context().query().querySqlFields(new 

[jira] [Comment Edited] (IGNITE-12901) SQL: Uncorrelated subquery should run only once.

[Ivan Daschinskiy (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087750#comment-17087750
 ] 

Ivan Daschinskiy edited comment on IGNITE-12901 at 4/20/20, 1:49 PM:
-

[~kukushal][~nizhikov] I found, that this feature is supported in H2 by 
default, but intentionally switched off. However, it's possible to enable it in 
similar manner, as {{SqlFieldsQuery#setLazy}} or  
{{SqlFieldsQuery#setEnforceJoinOrder}} manner and switched off by default. WDYT?


was (Author: ivandasch):
[~kukushal][~nizhikov] I found, that this feature is supported in H2 by 
default, but intentionally switched off. However, it's possible to enable it in 
similar manner, as {{ SqlFieldsQuery#setLazy }} or  {{ 
SqlFieldsQuery#setEnforceJoinOrder }} manner and switched off by default. WDYT?

> SQL: Uncorrelated subquery should run only once.
> 
>
> Key: IGNITE-12901
> URL: https://issues.apache.org/jira/browse/IGNITE-12901
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Assignee: Ivan Daschinskiy
>Priority: Major
>  Labels: sbcf
>
> Currently uncorrelated subqueries (where subquery is not depends on the outer 
> query) are executed on each nested loop iteration in the 
> org.h2.command.dml.Select#isConditionMet method. 
> We may avoid this, for example, using results caching.
> h2. Reproducer
> {code:java}
> public class SubQueryTest extends AbstractIndexingCommonTest {
> /** Keys counts at the RIGHT table. */
> private static final int RIGHT_CNT = 10;
> /** Keys counts at the LEFT table. */
> private static final int LEFT_CNT = 50;
> /** {@inheritDoc} */
> @SuppressWarnings("unchecked")
> @Override protected void beforeTest() throws Exception {
> super.beforeTest();
> startGrids(1);
> IgniteCache cacheA = grid(0).createCache(new CacheConfiguration Long>()
> .setName("A")
> .setSqlSchema("TEST")
> .setQueryEntities(Collections.singleton(new 
> QueryEntity(Long.class.getTypeName(), "A_VAL")
> .setTableName("A")
> .addQueryField("ID", Long.class.getName(), null)
> .addQueryField("JID", Long.class.getName(), null)
> .addQueryField("VAL", Long.class.getName(), null)
> .setKeyFieldName("ID")
> )));
> IgniteCache cacheB = grid(0).createCache(new CacheConfiguration()
> .setCacheMode(CacheMode.REPLICATED)
> .setName("B")
> .setSqlSchema("TEST")
> .setQueryEntities(Collections.singleton(new 
> QueryEntity(Long.class.getName(), "B_VAL")
> .setTableName("B")
> .addQueryField("ID", Long.class.getName(), null)
> .addQueryField("A_JID", Long.class.getName(), null)
> .addQueryField("VAL0", String.class.getName(), null)
> .setKeyFieldName("ID")
> )));
> Map batch = new HashMap<>();
> for (long i = 0; i < LEFT_CNT; ++i) {
> batch.put(i, grid(0).binary().builder("A_VAL")
> .setField("JID", i % RIGHT_CNT)
> .setField("VAL", i)
> .build());
> if (batch.size() > 1000) {
> cacheA.putAll(batch);
> batch.clear();
> }
> }
> if (batch.size() > 0) {
> cacheA.putAll(batch);
> batch.clear();
> }
> for (long i = 0; i < RIGHT_CNT; ++i)
> cacheB.put(i, grid(0).binary().builder("B_VAL")
> .setField("A_JID", i)
> .setField("VAL0", String.format("val%03d", i))
> .build());
> }
> /** {@inheritDoc} */
> @Override protected void afterTest() throws Exception {
> stopAllGrids();
> super.afterTest();
> }
> /**
>  * Test local query execution.
>  */
> @Test
> public void test() {
> sql(true, "SELECT * FROM A WHERE A.JID IN (SELECT A_JID FROM 
> B)").getAll();
> }
> /**
>  * @param enforceJoinOrder Enforce join order mode.
>  * @param sql SQL query.
>  * @param args Query parameters.
>  * @return Results cursor.
>  */
> private FieldsQueryCursor> sql(boolean enforceJoinOrder, String 
> sql, Object... args) {
> return grid(0).context().query().querySqlFields(new 
> SqlFieldsQuery(sql)
> .setSchema("TEST")
> .setLazy(true)
> .setEnforceJoinOrder(enforceJoinOrder)
> .setArgs(args), false);
> }
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-12901) SQL: Uncorrelated subquery should run only once.

[Ivan Daschinskiy (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087750#comment-17087750
 ] 

Ivan Daschinskiy commented on IGNITE-12901:
---

[~kukushal][~nizhikov] I found, that this feature is supported in H2 by 
default, but intentionally switched off. However, it's possible to enable it in 
similar manner, as {{ SqlFieldsQuery#setLazy }} or  {{ 
SqlFieldsQuery#setEnforceJoinOrder }} manner and switched off by default. WDYT?

> SQL: Uncorrelated subquery should run only once.
> 
>
> Key: IGNITE-12901
> URL: https://issues.apache.org/jira/browse/IGNITE-12901
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Assignee: Ivan Daschinskiy
>Priority: Major
>  Labels: sbcf
>
> Currently uncorrelated subqueries (where subquery is not depends on the outer 
> query) are executed on each nested loop iteration in the 
> org.h2.command.dml.Select#isConditionMet method. 
> We may avoid this, for example, using results caching.
> h2. Reproducer
> {code:java}
> public class SubQueryTest extends AbstractIndexingCommonTest {
> /** Keys counts at the RIGHT table. */
> private static final int RIGHT_CNT = 10;
> /** Keys counts at the LEFT table. */
> private static final int LEFT_CNT = 50;
> /** {@inheritDoc} */
> @SuppressWarnings("unchecked")
> @Override protected void beforeTest() throws Exception {
> super.beforeTest();
> startGrids(1);
> IgniteCache cacheA = grid(0).createCache(new CacheConfiguration Long>()
> .setName("A")
> .setSqlSchema("TEST")
> .setQueryEntities(Collections.singleton(new 
> QueryEntity(Long.class.getTypeName(), "A_VAL")
> .setTableName("A")
> .addQueryField("ID", Long.class.getName(), null)
> .addQueryField("JID", Long.class.getName(), null)
> .addQueryField("VAL", Long.class.getName(), null)
> .setKeyFieldName("ID")
> )));
> IgniteCache cacheB = grid(0).createCache(new CacheConfiguration()
> .setCacheMode(CacheMode.REPLICATED)
> .setName("B")
> .setSqlSchema("TEST")
> .setQueryEntities(Collections.singleton(new 
> QueryEntity(Long.class.getName(), "B_VAL")
> .setTableName("B")
> .addQueryField("ID", Long.class.getName(), null)
> .addQueryField("A_JID", Long.class.getName(), null)
> .addQueryField("VAL0", String.class.getName(), null)
> .setKeyFieldName("ID")
> )));
> Map batch = new HashMap<>();
> for (long i = 0; i < LEFT_CNT; ++i) {
> batch.put(i, grid(0).binary().builder("A_VAL")
> .setField("JID", i % RIGHT_CNT)
> .setField("VAL", i)
> .build());
> if (batch.size() > 1000) {
> cacheA.putAll(batch);
> batch.clear();
> }
> }
> if (batch.size() > 0) {
> cacheA.putAll(batch);
> batch.clear();
> }
> for (long i = 0; i < RIGHT_CNT; ++i)
> cacheB.put(i, grid(0).binary().builder("B_VAL")
> .setField("A_JID", i)
> .setField("VAL0", String.format("val%03d", i))
> .build());
> }
> /** {@inheritDoc} */
> @Override protected void afterTest() throws Exception {
> stopAllGrids();
> super.afterTest();
> }
> /**
>  * Test local query execution.
>  */
> @Test
> public void test() {
> sql(true, "SELECT * FROM A WHERE A.JID IN (SELECT A_JID FROM 
> B)").getAll();
> }
> /**
>  * @param enforceJoinOrder Enforce join order mode.
>  * @param sql SQL query.
>  * @param args Query parameters.
>  * @return Results cursor.
>  */
> private FieldsQueryCursor> sql(boolean enforceJoinOrder, String 
> sql, Object... args) {
> return grid(0).context().query().querySqlFields(new 
> SqlFieldsQuery(sql)
> .setSchema("TEST")
> .setLazy(true)
> .setEnforceJoinOrder(enforceJoinOrder)
> .setArgs(args), false);
> }
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (IGNITE-12912) Calcite integration: Add filters merge rule to the planner

[Taras Ledkov (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-12912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Taras Ledkov reassigned IGNITE-12912:
-

Assignee: Taras Ledkov

> Calcite integration: Add filters merge rule to the planner
> --
>
> Key: IGNITE-12912
> URL: https://issues.apache.org/jira/browse/IGNITE-12912
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Roman Kondakov
>Assignee: Taras Ledkov
>Priority: Major
>
> We need to add  next rules to planner
>  * FilterMergeRule
>  * FilterProjectTransposeRule
> In order to be able to make this transformation for the query:
> {noformat}
> "select name from (\n"
> + "  select *\n"
> + "  from dept\n"
> + "  where deptno = 10)\n"
> + "where deptno = 10\n"
> BEFORE=
> LogicalProject(NAME=[$1])
>   LogicalFilter(condition=[=(CAST($0):INTEGER, 10)])
> LogicalProject(DEPTNO=[$0], NAME=[$1])
>   LogicalFilter(condition=[=(CAST($0):INTEGER, 10)])
> IgniteTableScan(table=[[PUBLIC, DEPT]])
> AFTER=
> IgniteProject(NAME=[$1])
>   IgniteProject(DEPTNO=[$0], NAME=[$1])
> IgniteFilter(condition=[=(CAST($0):INTEGER, 10)])
>   IgniteTableScan(table=[[PUBLIC, DEPT]])
> {noformat}
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-10940) Supply pre-built ./configure with Apache Ignite releases

[Nikolay Izhikov (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-10940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087684#comment-17087684
 ] 

Nikolay Izhikov commented on IGNITE-10940:
--

[~ilyak]

> I have pushed this change to master branch

Great news! Thank you!

Why do we need this in 2.8.1?

2.8.1 is bugfix release.
Personally, I'm against to cherry-pick this to 2.8.1

> Supply pre-built ./configure with Apache Ignite releases
> 
>
> Key: IGNITE-10940
> URL: https://issues.apache.org/jira/browse/IGNITE-10940
> Project: Ignite
>  Issue Type: Improvement
>  Components: build
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
>  Labels: c++
> Fix For: 2.8.1
>
>
> Right now we have the following build steps for C++ in docs:
> {code}
> cd modules/platforms/cpp
> libtoolize && aclocal && autoheader && automake --add-missing && autoreconf
> ./configure
> make
> sudo make install
> {code}
> However, it is customary for C++ projects to ship release tarballs with first 
> step already done. ./configure should be pre-built and libtoolize, etc, are 
> already ran since you should not force user to install them, and the process 
> of their application is deterministic.
> I suggest we add libtoolize && etc step to release builds so that user's 
> first step will be ./configure.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-10947) CPP: Fix documentation on how to build Ignite C++ on Linux

[Ilya Kasnacheev (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-10947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ilya Kasnacheev updated IGNITE-10947:
-
Fix Version/s: 2.8.1

> CPP: Fix documentation on how to build Ignite C++ on Linux
> --
>
> Key: IGNITE-10947
> URL: https://issues.apache.org/jira/browse/IGNITE-10947
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation, platforms
>Reporter: Igor Sapego
>Priority: Major
> Fix For: 2.8.1
>
>
> We now have build step (IGNITE-10940) that performs following steps during 
> release of the binary package of the Ignite:
> {code}
> # libtoolize
> # aclocal
> # autoheader
> # automake --add-missing
> # autoreconf
> {code}
> So we now should change documentation, that users only need to run following 
> commands to build Ignite C++ from binary distribution of Ignite.
> {code}
> # ./configure
> # make
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-12608) [ignite-extensions] Setup tests for ignite-client-spring-boot-autoconfigure, ignite-spring-boot-autoconfigure on TC

[Nikolay Izhikov (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-12608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nikolay Izhikov updated IGNITE-12608:
-
Fix Version/s: 1.0

> [ignite-extensions] Setup tests for ignite-client-spring-boot-autoconfigure, 
> ignite-spring-boot-autoconfigure on TC
> ---
>
> Key: IGNITE-12608
> URL: https://issues.apache.org/jira/browse/IGNITE-12608
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Minor
>  Labels: spring-boot-autoconfigure, 
> spring-boot-client-autoconfigure
> Fix For: 1.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Changes relating to setting up new modules tests on TC.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-12525) Spring boot starter

[Nikolay Izhikov (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-12525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nikolay Izhikov updated IGNITE-12525:
-
Fix Version/s: 1.0

> Spring boot starter
> ---
>
> Key: IGNITE-12525
> URL: https://issues.apache.org/jira/browse/IGNITE-12525
> Project: Ignite
>  Issue Type: Improvement
>  Components: spring
>Affects Versions: 2.7.6
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: spring-boot-autoconfigure, 
> spring-boot-client-autoconfigure
> Fix For: 1.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> To improve user experience with Ignite we should provide an 
> ignite-spring-boot-starter like many of other projects do.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-10940) Supply pre-built ./configure with Apache Ignite releases

[Ilya Kasnacheev (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-10940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ilya Kasnacheev updated IGNITE-10940:
-
Ignite Flags:   (was: Docs Required)

> Supply pre-built ./configure with Apache Ignite releases
> 
>
> Key: IGNITE-10940
> URL: https://issues.apache.org/jira/browse/IGNITE-10940
> Project: Ignite
>  Issue Type: Improvement
>  Components: build
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
>  Labels: c++
> Fix For: 2.8.1
>
>
> Right now we have the following build steps for C++ in docs:
> {code}
> cd modules/platforms/cpp
> libtoolize && aclocal && autoheader && automake --add-missing && autoreconf
> ./configure
> make
> sudo make install
> {code}
> However, it is customary for C++ projects to ship release tarballs with first 
> step already done. ./configure should be pre-built and libtoolize, etc, are 
> already ran since you should not force user to install them, and the process 
> of their application is deterministic.
> I suggest we add libtoolize && etc step to release builds so that user's 
> first step will be ./configure.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-10940) Supply pre-built ./configure with Apache Ignite releases

[Ilya Kasnacheev (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-10940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087681#comment-17087681
 ] 

Ilya Kasnacheev commented on IGNITE-10940:
--

[~nizhikov]I have pushed this change to master branch

{code}
commit 50cd0a853a7720cb5970fa354cf9f4916a094a8b (HEAD -> master, asf/master)
Author: Ilya Kasnacheev 
Date:   Fri Apr 17 18:50:10 2020 +0300

IGNITE-10940 Pre-run C++ autotools in Apache Ignite releases.

{code}

Please cherry-pick it to 2.8.1.

> Supply pre-built ./configure with Apache Ignite releases
> 
>
> Key: IGNITE-10940
> URL: https://issues.apache.org/jira/browse/IGNITE-10940
> Project: Ignite
>  Issue Type: Improvement
>  Components: build
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
>  Labels: c++
> Fix For: 2.8.1
>
>
> Right now we have the following build steps for C++ in docs:
> {code}
> cd modules/platforms/cpp
> libtoolize && aclocal && autoheader && automake --add-missing && autoreconf
> ./configure
> make
> sudo make install
> {code}
> However, it is customary for C++ projects to ship release tarballs with first 
> step already done. ./configure should be pre-built and libtoolize, etc, are 
> already ran since you should not force user to install them, and the process 
> of their application is deterministic.
> I suggest we add libtoolize && etc step to release builds so that user's 
> first step will be ./configure.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-10947) CPP: Fix documentation on how to build Ignite C++ on Linux

[Ilya Kasnacheev (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-10947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ilya Kasnacheev updated IGNITE-10947:
-
Component/s: documentation

> CPP: Fix documentation on how to build Ignite C++ on Linux
> --
>
> Key: IGNITE-10947
> URL: https://issues.apache.org/jira/browse/IGNITE-10947
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation, platforms
>Reporter: Igor Sapego
>Priority: Major
>
> We now have build step (IGNITE-10940) that performs following steps during 
> release of the binary package of the Ignite:
> {code}
> # libtoolize
> # aclocal
> # autoheader
> # automake --add-missing
> # autoreconf
> {code}
> So we now should change documentation, that users only need to run following 
> commands to build Ignite C++ from binary distribution of Ignite.
> {code}
> # ./configure
> # make
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-12919) Not all GridUuid renamed to IgniteUuid

[Amelchev Nikita (Jira)]

Amelchev Nikita created IGNITE-12919:


 Summary: Not all GridUuid renamed to IgniteUuid
 Key: IGNITE-12919
 URL: https://issues.apache.org/jira/browse/IGNITE-12919
 Project: Ignite
  Issue Type: Bug
Reporter: Amelchev Nikita
Assignee: Amelchev Nikita
 Fix For: 2.9


There are several places in javadocs and serialization mechanisms where 
GridUuid is not renamed. For example:
{noformat}
/**
 * Constructs {@code GridUuid} from a global and local identifiers.
 ...
 */
public IgniteUuid(UUID gid, long locId) { ... }

/**
 * Reads {@link org.apache.ignite.lang.IgniteUuid} from input stream. 
 ...
 */
@Nullable public static IgniteUuid readGridUuid(DataInput in) throws 
IOException {...}
{noformat}




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-12525) Spring boot starter

[Dmitry Pavlov (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087678#comment-17087678
 ] 

Dmitry Pavlov commented on IGNITE-12525:


[~nizhikov] could you please set a fix version where change will be available 
(presumably)?

> Spring boot starter
> ---
>
> Key: IGNITE-12525
> URL: https://issues.apache.org/jira/browse/IGNITE-12525
> Project: Ignite
>  Issue Type: Improvement
>  Components: spring
>Affects Versions: 2.7.6
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: spring-boot-autoconfigure, 
> spring-boot-client-autoconfigure
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> To improve user experience with Ignite we should provide an 
> ignite-spring-boot-starter like many of other projects do.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-12918) .NET: Add Travis job

[Pavel Tupitsyn (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-12918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Tupitsyn updated IGNITE-12918:

Description: Add .NET build to .travis.yml

> .NET: Add Travis job
> 
>
> Key: IGNITE-12918
> URL: https://issues.apache.org/jira/browse/IGNITE-12918
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Add .NET build to .travis.yml



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-12918) .NET: Add Travis job

[Pavel Tupitsyn (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-12918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Tupitsyn updated IGNITE-12918:

Summary: .NET: Add Travis job  (was: .NET: Add dotnet build to travis-ci)

> .NET: Add Travis job
> 
>
> Key: IGNITE-12918
> URL: https://issues.apache.org/jira/browse/IGNITE-12918
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-12608) [ignite-extensions] Setup tests for ignite-client-spring-boot-autoconfigure, ignite-spring-boot-autoconfigure on TC

[Nikolay Izhikov (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-12608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nikolay Izhikov updated IGNITE-12608:
-
Labels: spring-boot-autoconfigure spring-boot-client-autoconfigure  (was: 
spring-boot-clienautoconfigure spring-boot-client-autoconfigure)

> [ignite-extensions] Setup tests for ignite-client-spring-boot-autoconfigure, 
> ignite-spring-boot-autoconfigure on TC
> ---
>
> Key: IGNITE-12608
> URL: https://issues.apache.org/jira/browse/IGNITE-12608
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Minor
>  Labels: spring-boot-autoconfigure, 
> spring-boot-client-autoconfigure
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Changes relating to setting up new modules tests on TC.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-12918) .NET: Add dotnet build to travis-ci

[Pavel Tupitsyn (Jira)]

Pavel Tupitsyn created IGNITE-12918:
---

 Summary: .NET: Add dotnet build to travis-ci
 Key: IGNITE-12918
 URL: https://issues.apache.org/jira/browse/IGNITE-12918
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn






--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-12888) Add support for ConstantName to checkstyle rules

[Amelchev Nikita (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087665#comment-17087665
 ] 

Amelchev Nikita commented on IGNITE-12888:
--

[~mmuzaf], I have reviewed your patch. I left a couple of comments at PR. 
Overall, changes look good.

I suggest reaching an agreement with contributors about such rules for maps, TL 
and other mutable types.

> Add support for ConstantName to checkstyle rules
> 
>
> Key: IGNITE-12888
> URL: https://issues.apache.org/jira/browse/IGNITE-12888
> Project: Ignite
>  Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Add a new rule to checkstyle according to Apache Ignite naming conventions.
> 
> https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-Naming



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-12608) [ignite-extensions] Setup tests for ignite-client-spring-boot-autoconfigure, ignite-spring-boot-autoconfigure on TC

[Nikolay Izhikov (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-12608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nikolay Izhikov updated IGNITE-12608:
-
Labels: spring-boot-clienautoconfigure spring-boot-client-autoconfigure  
(was: )

> [ignite-extensions] Setup tests for ignite-client-spring-boot-autoconfigure, 
> ignite-spring-boot-autoconfigure on TC
> ---
>
> Key: IGNITE-12608
> URL: https://issues.apache.org/jira/browse/IGNITE-12608
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Minor
>  Labels: spring-boot-clienautoconfigure, 
> spring-boot-client-autoconfigure
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Changes relating to setting up new modules tests on TC.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-12525) Spring boot starter

[Nikolay Izhikov (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-12525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nikolay Izhikov updated IGNITE-12525:
-
Labels: spring-boot-autoconfigure spring-boot-client-autoconfigure  (was: )

> Spring boot starter
> ---
>
> Key: IGNITE-12525
> URL: https://issues.apache.org/jira/browse/IGNITE-12525
> Project: Ignite
>  Issue Type: Improvement
>  Components: spring
>Affects Versions: 2.7.6
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: spring-boot-autoconfigure, 
> spring-boot-client-autoconfigure
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> To improve user experience with Ignite we should provide an 
> ignite-spring-boot-starter like many of other projects do.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-12905) QueryKeyValueIterable missing custom spliterator() implementation

[Dmitriy Sorokin (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087662#comment-17087662
 ] 

Dmitriy Sorokin commented on IGNITE-12905:
--

Hello, [~bleedah]!

Thanks for your contribution!

I made several review comments on your test class at github, it needs some 
fixes.

Also, you have to register at [https://ci.ignite.apache.org/] and get an 
approval for your PR from [TC Bot|https://mtcga.gridgain.com/prs.html], see 
[howto|https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+Teamcity+Bot#ApacheIgniteTeamcityBot-HowtocheckaPRwiththeTCBot]
 page.

> QueryKeyValueIterable missing custom spliterator() implementation
> -
>
> Key: IGNITE-12905
> URL: https://issues.apache.org/jira/browse/IGNITE-12905
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, general
>Affects Versions: 2.8
> Environment: Windows 10
> JDK 1.8.0_172
> ignite-core 2.8.0
> reactor-core 3.3.3
>Reporter: Johnny Galatikitis
>Priority: Critical
> Fix For: 2.8.1
>
> Attachments: 
> IGNITE-12905_-_add_QueryKeyValueSpliterator_and_corresponding_test.patch
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> We are using apache ignite with reactor-core and since reactors upgrade from 
> 3.2.12 to 3.3.3 {code:java}
> org.apache.ignite.internal.processors.query.QueryKeyValueIterable.iterator
> {code}
> is called multiple times. It starts with:
> 1. calling iterable.spliterator().hasCharacteristics(Spliterator.SIZED), 
> where iterable is instanceof QueryKeyValueIterable
> 2. calls default implementation 
> Spliterators.spliteratorUnknownSize(iterator(), 0)
> 3. which in turn calls ignite's QueryKeyValueIterable.iterator() call and 
> that "uses it up" for subsequent calls, i.e. throw IgniteException "Iterator 
> is already fetched or query was cancelled."



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-12917) SQL: print warning log message when query's result is big

[Taras Ledkov (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-12917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Taras Ledkov updated IGNITE-12917:
--
Ignite Flags:   (was: Docs Required,Release Notes Required)

> SQL: print warning log message when query's result is big
> -
>
> Key: IGNITE-12917
> URL: https://issues.apache.org/jira/browse/IGNITE-12917
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We have to track queries with big result set.
> Print warning log message when query's result is bigger than threshold 
> specified by JMX.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-10940) Supply pre-built ./configure with Apache Ignite releases

[Igor Sapego (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-10940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087618#comment-17087618
 ] 

Igor Sapego commented on IGNITE-10940:
--

[~ilyak] changes looks OK, I was also able to download and successfully build 
artifacts from nightly release

> Supply pre-built ./configure with Apache Ignite releases
> 
>
> Key: IGNITE-10940
> URL: https://issues.apache.org/jira/browse/IGNITE-10940
> Project: Ignite
>  Issue Type: Improvement
>  Components: build
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
>  Labels: c++
> Fix For: 2.8.1
>
>
> Right now we have the following build steps for C++ in docs:
> {code}
> cd modules/platforms/cpp
> libtoolize && aclocal && autoheader && automake --add-missing && autoreconf
> ./configure
> make
> sudo make install
> {code}
> However, it is customary for C++ projects to ship release tarballs with first 
> step already done. ./configure should be pre-built and libtoolize, etc, are 
> already ran since you should not force user to install them, and the process 
> of their application is deterministic.
> I suggest we add libtoolize && etc step to release builds so that user's 
> first step will be ./configure.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-12917) SQL: print warning log message when query's result is big

[Taras Ledkov (Jira)]

Taras Ledkov created IGNITE-12917:
-

 Summary: SQL: print warning log message when query's result is big
 Key: IGNITE-12917
 URL: https://issues.apache.org/jira/browse/IGNITE-12917
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Taras Ledkov
Assignee: Taras Ledkov
 Fix For: 2.9


We have to track queries with big result set.
Print warning log message when query's result is bigger than threshold 
specified by JMX.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-12853) ThinClient: Introduce Features for thin clients

[Igor Sapego (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087576#comment-17087576
 ] 

Igor Sapego commented on IGNITE-12853:
--

[~ptupitsyn], [~alex_pl] if there are no further comments, I'm going to merge 
it to master tomorrow.

> ThinClient: Introduce Features for thin clients
> ---
>
> Key: IGNITE-12853
> URL: https://issues.apache.org/jira/browse/IGNITE-12853
> Project: Ignite
>  Issue Type: Bug
>  Components: thin client
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> As we have a lot of different thin clients now, maintained by different 
> people, the issues with our backward compatibility mechanism becomes more and 
> more prominent.
> Currently, we use protocol versioning as the only approach to provide 
> backward compatibility. The main issue of this approach is that we can not 
> skip some change in protocol and implement i.e. protocol of version 1.5 
> without implementation of 1.4. There are many cases when one may want to do 
> so: e.g. when feature provided in 1.4 is not relevant for a specific client, 
> or when protocol version 1.5 contains urgent fix or feature which is easy to 
> implement, but its blocked by not-so-urgent and hard-to-implement feature 
> introduced in 1.4.
> So to fix this issue I propose to introduce another backward compatibility 
> mechanism. The idea is to send "supported features" mask by a client to a 
> server, which should be answered with the same mask by the server. The 
> resulting set of enabled features is acquired with a simple logical "AND" 
> operation on these two masks.
> This change has many other positive effects: 
> 1. It improves readability and also potentially simplifies debugging.
> 2. It gives users the ability to enable or disable features of thin clients 
> on both server and client as they desire.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-7369) .NET: Thin client: Transactions

[Pavel Tupitsyn (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087574#comment-17087574
 ] 

Pavel Tupitsyn commented on IGNITE-7369:


[~GuruStron] ok, great. Any estimates?

> .NET: Thin client: Transactions
> ---
>
> Key: IGNITE-7369
> URL: https://issues.apache.org/jira/browse/IGNITE-7369
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Sergey Stronchinskiy
>Priority: Major
>  Labels: .NET, iep-34
> Fix For: 2.9
>
>
> Implement transactions in thin client protocol and .NET thin client.
> Main issue: Ignite transactions are tied to a specific thread.
> See how JDBC works around this by starting a dedicated thread.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-7369) .NET: Thin client: Transactions

[Sergey Stronchinskiy (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087573#comment-17087573
 ] 

Sergey Stronchinskiy commented on IGNITE-7369:
--

[~ptupitsyn], yes, I have. Sorry for not updating ticket status.

> .NET: Thin client: Transactions
> ---
>
> Key: IGNITE-7369
> URL: https://issues.apache.org/jira/browse/IGNITE-7369
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Sergey Stronchinskiy
>Priority: Major
>  Labels: .NET, iep-34
> Fix For: 2.9
>
>
> Implement transactions in thin client protocol and .NET thin client.
> Main issue: Ignite transactions are tied to a specific thread.
> See how JDBC works around this by starting a dedicated thread.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-12853) ThinClient: Introduce Features for thin clients

[Igor Sapego (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087570#comment-17087570
 ] 

Igor Sapego commented on IGNITE-12853:
--

[~nizhikov] If no thin client features is going to be included in 2.8.1, then 
OK, let's move it to 2.9

> ThinClient: Introduce Features for thin clients
> ---
>
> Key: IGNITE-12853
> URL: https://issues.apache.org/jira/browse/IGNITE-12853
> Project: Ignite
>  Issue Type: Bug
>  Components: thin client
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> As we have a lot of different thin clients now, maintained by different 
> people, the issues with our backward compatibility mechanism becomes more and 
> more prominent.
> Currently, we use protocol versioning as the only approach to provide 
> backward compatibility. The main issue of this approach is that we can not 
> skip some change in protocol and implement i.e. protocol of version 1.5 
> without implementation of 1.4. There are many cases when one may want to do 
> so: e.g. when feature provided in 1.4 is not relevant for a specific client, 
> or when protocol version 1.5 contains urgent fix or feature which is easy to 
> implement, but its blocked by not-so-urgent and hard-to-implement feature 
> introduced in 1.4.
> So to fix this issue I propose to introduce another backward compatibility 
> mechanism. The idea is to send "supported features" mask by a client to a 
> server, which should be answered with the same mask by the server. The 
> resulting set of enabled features is acquired with a simple logical "AND" 
> operation on these two masks.
> This change has many other positive effects: 
> 1. It improves readability and also potentially simplifies debugging.
> 2. It gives users the ability to enable or disable features of thin clients 
> on both server and client as they desire.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (IGNITE-12908) Confusing check for presence of SqlViewExporterSpi class in classpath during initialization

[Mikhail Petrov (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-12908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mikhail Petrov reassigned IGNITE-12908:
---

Assignee: Mikhail Petrov

> Confusing check for presence of SqlViewExporterSpi class in classpath during 
> initialization
> ---
>
> Key: IGNITE-12908
> URL: https://issues.apache.org/jira/browse/IGNITE-12908
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Andrey N. Gura
>Assignee: Mikhail Petrov
>Priority: Minor
>  Labels: IEP-35
> Fix For: 2.8.1
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> {{IgnitionEx.initializeDefaultSpi()}} method checks for presence of 
> {{SqlViewExporterSpi}} class in classpath whilst actual intention is to check 
> for presence of indexing in classpath. It could be done just using 
> {{IgniteComponentType.INDEXING.inClassPath()}} method.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-12717) SQL: index creation refactoring

[Nikolay Izhikov (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087533#comment-17087533
 ] 

Nikolay Izhikov commented on IGNITE-12717:
--

> Did you add the 2.8.1 version by bulk update tickets and review one-by-one?

Yep :)

I marked all tickets proposed by the community in release dev-list thread with 
2.8.1 and now trying to cherry-pick them in 2.8 branch

> SQL: index creation refactoring
> ---
>
> Key: IGNITE-12717
> URL: https://issues.apache.org/jira/browse/IGNITE-12717
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Do refactoring children of the H2 IndexBase to simplify the H2 upgrade.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-12717) SQL: index creation refactoring

[Nikolay Izhikov (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-12717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nikolay Izhikov updated IGNITE-12717:
-
Fix Version/s: (was: 2.8.1)

> SQL: index creation refactoring
> ---
>
> Key: IGNITE-12717
> URL: https://issues.apache.org/jira/browse/IGNITE-12717
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Do refactoring children of the H2 IndexBase to simplify the H2 upgrade.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-7369) .NET: Thin client: Transactions

[Pavel Tupitsyn (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087531#comment-17087531
 ] 

Pavel Tupitsyn commented on IGNITE-7369:


[~GuruStron] are you working on this ticket? Can I take it?

> .NET: Thin client: Transactions
> ---
>
> Key: IGNITE-7369
> URL: https://issues.apache.org/jira/browse/IGNITE-7369
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Sergey Stronchinskiy
>Priority: Major
>  Labels: .NET, iep-34
> Fix For: 2.9
>
>
> Implement transactions in thin client protocol and .NET thin client.
> Main issue: Ignite transactions are tied to a specific thread.
> See how JDBC works around this by starting a dedicated thread.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-12717) SQL: index creation refactoring

[Taras Ledkov (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087528#comment-17087528
 ] 

Taras Ledkov commented on IGNITE-12717:
---

[~nizhikov], I think no. I didn't add this version. The improvements related to 
change index inline behavior depend on this patch.
But i don't see these issues in the 2.8.1 scope.

I've added 2.8.1 to some ticket that looks like critical bug (e.g. connection 
leaks, node stops etc). 

Did you add the 2.8.1 version by bulk update tickets and review one-by-one?

> SQL: index creation refactoring
> ---
>
> Key: IGNITE-12717
> URL: https://issues.apache.org/jira/browse/IGNITE-12717
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.9, 2.8.1
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Do refactoring children of the H2 IndexBase to simplify the H2 upgrade.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-12907) GridSystemViewManager is not thread safe

[Mikhail Petrov (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087519#comment-17087519
 ] 

Mikhail Petrov commented on IGNITE-12907:
-

[~agura], could you clarify, please. I see no {{registerWalker()}} method in 
GridSystemViewManager and ConcurrentHashMap is used to store the SystemView at 
current master. Does this mean that the problem has been already solved?

> GridSystemViewManager is not thread safe
> 
>
> Key: IGNITE-12907
> URL: https://issues.apache.org/jira/browse/IGNITE-12907
> Project: Ignite
>  Issue Type: Bug
>Reporter: Andrey N. Gura
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: IEP-35
> Fix For: 2.8.1
>
>
> {{GridSystemViewManager}} is not thread safe because it allows to registers 
> walkers using public  {{registerWalker()}} that just adds walker to a 
> {{HashMap}}.
> It seems the simplest solution here: make {{registerWalker()}} method private 
> because it has usages only from {{GridSystemViewManager}} constructor.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-12827) OutOfMemory exception when calling grid service from .NET with user type array parameter

[Ivan Daschinskiy (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087503#comment-17087503
 ] 

Ivan Daschinskiy commented on IGNITE-12827:
---

[~nizhikov] I added benchmark and detailed analyzis in jupyter notebook, please 
see 
[here|https://github.com/ivandasch/ignite-12827-benchmarks-analysis/blob/master/report.ipynb]

> OutOfMemory exception when calling grid service from .NET with user type 
> array parameter
> 
>
> Key: IGNITE-12827
> URL: https://issues.apache.org/jira/browse/IGNITE-12827
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Assignee: Ivan Daschinskiy
>Priority: Major
>  Labels: sbcf
> Fix For: 2.8.1
>
> Attachments: ignite-12827-vs-2.8.patch
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Calling a grid service from .NET with a parameter of user type array leads to 
> Java OutOfMemory exception.
> +*Reproducer*+:
>  * Limit JVM heap with 128 MB.
>  * Create a .NET or Java service with a parameter of type 
> *array of* Parameter { 
>   Id: int, 
>   *array of* ParameterValue { 
>     PeriodId: int, 
>     Value: double? 
>   }
> }
>  * Call service with an array of 200 Parameters
> +*Expected*+:
> 128 MB of heap must be enough to call Java or .NET service with 200 
> Parameters.
>  
> +*Actual*+:
> Java OutOfMemory exception on 21st Parameter
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-12916) Add travis-ci configuration to run builds

[Maxim Muzafarov (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087486#comment-17087486
 ] 

Maxim Muzafarov commented on IGNITE-12916:
--

Merged to the master branch.

> Add travis-ci configuration to run builds
> -
>
> Key: IGNITE-12916
> URL: https://issues.apache.org/jira/browse/IGNITE-12916
> Project: Ignite
>  Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> {{.travis.yml}} configuration for running builds over Travis-ci 
> (https://travis-ci.org/github/apache/ignite) needs to be added for builds.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-12096) Used memory metric does not contract when cache is emptied - FreeList REUSE_BUCKET is not accounted for

[Colin Cassidy (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087484#comment-17087484
 ] 

Colin Cassidy commented on IGNITE-12096:


Apologies for the delay in submitting a PR with the above test. I can confirm 
that 2.8.0 does indeed allow us to work-around this issue and make the above 
test pass - although we have not upgraded due to existence of a separate 
regression: IGNITE-12579

> Used memory metric does not contract when cache is emptied - FreeList 
> REUSE_BUCKET is not accounted for
> ---
>
> Key: IGNITE-12096
> URL: https://issues.apache.org/jira/browse/IGNITE-12096
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.7
>Reporter: Colin Cassidy
>Priority: Major
> Fix For: 2.9
>
>
> When using the Ignite metrics API to measure available memory, the usage 
> figures appear to be accurate while memory is being consumed - but when 
> memory is freed the metrics do not drop. They appear to report that memory 
> has not been freed up, even though it has.
> A reliable estimate of memory consumption is very important for solutions 
> that don't use native persistence - as this is the only controllable way of 
> avoiding a critical OOM condition.
> Reproducer below. This affects Ignite 2.7+.
> {{public class MemoryTest2 { }}
> {{    private static final String CACHE_NAME = "cache"; }}
>  {{    private static final String DEFAULT_MEMORY_REGION = "Default_Region"; 
> }}
>  {{    private static final long MEM_SIZE = 100L * 1024 * 1024; }}
> {{    @Test }}
>  {{    public void testOOM() throws InterruptedException { }}
>  {{        try (Ignite ignite = startIgnite("IgniteMemoryMonitorTest1")) { }}
>  {{            fillDataRegion(ignite); }}
>  {{            CacheConfiguration cfg = new }}
>  {{CacheConfiguration<>(CACHE_NAME); }}
>  {{            cfg.setStatisticsEnabled(true); }}
>  {{            IgniteCache cache = }}
>  {{ignite.getOrCreateCache(cfg); }}
> {{            // Clear all entries from the cache to free up memory }}
>  {{            memUsed(ignite); }}
>  {{            cache.clear(); }}
>  {{            cache.removeAll(); }}
>  {{            cache.put("Key", "Value"); }}
>  {{            memUsed(ignite); }}
>  {{            cache.destroy(); }}
>  {{            Thread.sleep(5000); }}
> {{            // Should now report close to 0% but reports 59% still }}
>  {{            memUsed(ignite); }}
>  {{        } }}
>  {{    } }}
>  {{    }}
>  {{    private Ignite startIgnite(String instanceName) { }}
>  {{        IgniteConfiguration cfg = new IgniteConfiguration(); }}
>  {{        cfg.setIgniteInstanceName(instanceName); }}
>  {{        cfg.setDataStorageConfiguration(createDataStorageConfiguration()); 
> }}
>  {{        cfg.setFailureHandler(new NoOpFailureHandler()); }}
>  {{        return Ignition.start(cfg); }}
>  {{    } }}
> {{    private DataStorageConfiguration createDataStorageConfiguration() { }}
>  {{        return new DataStorageConfiguration() }}
>  {{                .setDefaultDataRegionConfiguration( }}
>  {{                        new DataRegionConfiguration() }}
>  {{                                .setName(DEFAULT_MEMORY_REGION) }}
>  {{                                .setInitialSize(MEM_SIZE) }}
>  {{                                .setMaxSize(MEM_SIZE) }}
>  {{                                .setMetricsEnabled(true)); }}
>  {{    } }}
> {{    private void fillDataRegion(Ignite ignite) { }}
>  {{        byte[] megabyte = new byte[1024 * 1024]; }}
>  {{            IgniteCache cache = }}
>  {{                    ignite.getOrCreateCache(CACHE_NAME); }}
>  {{            for (int i = 0; i < 50; i++) { }}
>  {{                cache.put(i, megabyte); }}
>  {{                memUsed(ignite); }}
>  {{            } }}
>  {{    } }}
> {{    private void memUsed(Ignite ignite) { }}
>  {{        DataRegionConfiguration defaultDataRegionCfg = }}
>  {{ignite.configuration() }}
>  {{                .getDataStorageConfiguration() }}
>  {{                .getDefaultDataRegionConfiguration(); }}
>  {{        String regionName = defaultDataRegionCfg.getName(); }}
>  {{        DataRegionMetrics metrics = ignite.dataRegionMetrics(regionName); 
> }}
>  {{        float usedMem = metrics.getPagesFillFactor() * }}
>  {{metrics.getTotalAllocatedPages() * metrics.getPageSize(); }}
>  {{        float pctUsed = 100 * usedMem / defaultDataRegionCfg.getMaxSize(); 
> }}
>  {{        System.out.println("Memory used: " + pctUsed + "%"); }}
>  {{    } }}
>  {{} }}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-12889) checkRingLatency loops if there is only one server node with client in topology

[Ignite TC Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087474#comment-17087474
 ] 

Ignite TC Bot commented on IGNITE-12889:


{panel:title=Branch: [pull/7672/head] Base: [master] : No blockers 
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All* 
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5222681&buildTypeId=IgniteTests24Java8_RunAll]

> checkRingLatency loops if there is only one server node with client in 
> topology
> ---
>
> Key: IGNITE-12889
> URL: https://issues.apache.org/jira/browse/IGNITE-12889
> Project: Ignite
>  Issue Type: Bug
>Reporter: Igor Akkuratov
>Assignee: Igor Akkuratov
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> If there is only one server node with any count of clients in topology call 
> checkRingLatency loops until any server node join the topology.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-12916) Add travis-ci configuration to run builds

[Maxim Muzafarov (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-12916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maxim Muzafarov updated IGNITE-12916:
-
Fix Version/s: 2.9

> Add travis-ci configuration to run builds
> -
>
> Key: IGNITE-12916
> URL: https://issues.apache.org/jira/browse/IGNITE-12916
> Project: Ignite
>  Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> {{.travis.yml}} configuration for running builds over Travis-ci 
> (https://travis-ci.org/github/apache/ignite) needs to be added for builds.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)