[jira] [Assigned] (IGNITE-6974) .NET: consoleWrite error during application shutdown

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn reassigned IGNITE-6974:
--

Assignee: Pavel Tupitsyn

> .NET: consoleWrite error during application shutdown
> 
>
> Key: IGNITE-6974
> URL: https://issues.apache.org/jira/browse/IGNITE-6974
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.3
>Reporter: Alexey Popov
>Assignee: Pavel Tupitsyn
>Priority: Minor
>  Labels: .NET
>
> from Gitter:
> Hey all (again xD)! Using Apache Ignite .NET 2.3 I (sometimes) get an error 
> when shutting down my application. The error is only observable on server 
> nodes and not on every shutdown. Seems like a kind of race condition.
> The application runs as windows service. The windows application event log 
> shows the following error (see above) and a I get a hs_err_pid[PID].log like 
> that (snip):
> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
> j  
> org.apache.ignite.internal.processors.platform.callback.PlatformCallbackUtils.consoleWrite(Ljava/lang/String;Z)V+0
> j  
> org.apache.ignite.internal.processors.platform.callback.PlatformCallbackGateway.consoleWrite(Ljava/lang/String;Z)V+2
> j  
> org.apache.ignite.internal.processors.platform.dotnet.PlatformDotNetConsoleStream.write([BII)V+18
> j  java.io.PrintStream.write([BII)V+16
> j  sun.nio.cs.StreamEncoder.writeBytes()V+120
> j  sun.nio.cs.StreamEncoder.implFlushBuffer()V+11
> j  sun.nio.cs.StreamEncoder.flushBuffer()V+15
> j  java.io.OutputStreamWriter.flushBuffer()V+4
> j  java.io.PrintStream.write(Ljava/lang/String;)V+27
> j  java.io.PrintStream.print(Ljava/lang/String;)V+9
> j  
> org.apache.ignite.internal.util.IgniteUtils.quiet(Z[Ljava/lang/Object;)V+126
> j  org.apache.ignite.internal.IgniteKernal.stop0(Z)V+943
> j  org.apache.ignite.internal.IgniteKernal.stop(Z)V+6
> j  org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(Z)V+162
> j  org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(Z)V+26
> j  org.apache.ignite.internal.IgnitionEx.stop(Ljava/lang/String;ZZ)Z+72
> j  org.apache.ignite.Ignition.stop(Ljava/lang/String;Z)Z+3
> j  
> org.apache.ignite.internal.processors.platform.PlatformIgnition.stop(Ljava/lang/String;Z)Z+2
> v  ~StubRoutines::call_stub
> For me it seems that the Java side wants to write something to the (.NET) 
> console using a callback and the underlying memory is already freed - 
> therefore we get a AccessViolation



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

[jira] [Assigned] (IGNITE-7117) .NET: Classpath resolver relies on Java examples

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn reassigned IGNITE-7117:
--

Assignee: Pavel Tupitsyn

> .NET: Classpath resolver relies on Java examples
> 
>
> Key: IGNITE-7117
> URL: https://issues.apache.org/jira/browse/IGNITE-7117
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
>
> We should rely solely on jar directory presence. See 
> {{IgniteHome.IsIgniteHome}} method.



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

[jira] [Closed] (IGNITE-7461) Web console: incorrect code generation

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov closed IGNITE-7461.
--

> Web console: incorrect code generation
> --
>
> Key: IGNITE-7461
> URL: https://issues.apache.org/jira/browse/IGNITE-7461
> Project: Ignite
>  Issue Type: Bug
> Environment: Error:(81, 23) java: cannot find symbol
>   symbol:   method setCheckpointPageBufferSize(long)
>   location: variable dataStorageCfg of type 
> org.apache.ignite.configuration.DataStorageConfiguration
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.4
>
>
> Do not forget to change generation of XML configuration



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

[jira] [Commented] (IGNITE-7036) Web console: Wrong export of grouped users

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-7036:


tested

> Web console: Wrong export of grouped users
> --
>
> Key: IGNITE-7036
> URL: https://issues.apache.org/jira/browse/IGNITE-7036
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Vasiliy Sisko
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.4
>
>
> On export of grouped users when group is collapsed in table only header row 
> is exported.



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

[jira] [Closed] (IGNITE-7036) Web console: Wrong export of grouped users

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov closed IGNITE-7036.
--

> Web console: Wrong export of grouped users
> --
>
> Key: IGNITE-7036
> URL: https://issues.apache.org/jira/browse/IGNITE-7036
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Vasiliy Sisko
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.4
>
>
> On export of grouped users when group is collapsed in table only header row 
> is exported.



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

[jira] [Commented] (IGNITE-7391) Web console: ClientConfigurationFactory class name is missing in generated project

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-7391:


tested

> Web console: ClientConfigurationFactory class name is missing in generated 
> project
> --
>
> Key: IGNITE-7391
> URL: https://issues.apache.org/jira/browse/IGNITE-7391
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.4
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>Priority: Blocker
> Fix For: 2.4
>
>
> It present in Java preview but absent in downloaded project



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

[jira] [Closed] (IGNITE-7391) Web console: ClientConfigurationFactory class name is missing in generated project

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov closed IGNITE-7391.
--

> Web console: ClientConfigurationFactory class name is missing in generated 
> project
> --
>
> Key: IGNITE-7391
> URL: https://issues.apache.org/jira/browse/IGNITE-7391
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.4
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>Priority: Blocker
> Fix For: 2.4
>
>
> It present in Java preview but absent in downloaded project



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

[jira] [Commented] (IGNITE-7461) Web console: incorrect code generation

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-7461:


Tested

> Web console: incorrect code generation
> --
>
> Key: IGNITE-7461
> URL: https://issues.apache.org/jira/browse/IGNITE-7461
> Project: Ignite
>  Issue Type: Bug
> Environment: Error:(81, 23) java: cannot find symbol
>   symbol:   method setCheckpointPageBufferSize(long)
>   location: variable dataStorageCfg of type 
> org.apache.ignite.configuration.DataStorageConfiguration
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.4
>
>
> Do not forget to change generation of XML configuration



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

[jira] [Commented] (IGNITE-6920) Web console: Prepare Web Console package with simple deploy.

[Andrey Novikov (JIRA)]

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

Andrey Novikov commented on IGNITE-6920:


Merged to master.

> Web console: Prepare Web Console package with simple deploy.
> 
>
> Key: IGNITE-6920
> URL: https://issues.apache.org/jira/browse/IGNITE-6920
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.0
>Reporter: Andrey Novikov
>Assignee: Andrey Novikov
>Priority: Minor
> Fix For: 2.5
>
>
> * Package Web Console backend into an executable that can be run even on 
> devices without Node.js installed.
> * Let Web Console backend will be used to serve static files (compiled Web 
> Console frontend)
> * Let Web Console backend download and run as child process mongoDB. if 
> mongoDB is not installed.



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

[jira] [Closed] (IGNITE-6920) Web console: Prepare Web Console package with simple deploy.

[Andrey Novikov (JIRA)]

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

Andrey Novikov closed IGNITE-6920.
--

> Web console: Prepare Web Console package with simple deploy.
> 
>
> Key: IGNITE-6920
> URL: https://issues.apache.org/jira/browse/IGNITE-6920
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.0
>Reporter: Andrey Novikov
>Assignee: Andrey Novikov
>Priority: Minor
> Fix For: 2.5
>
>
> * Package Web Console backend into an executable that can be run even on 
> devices without Node.js installed.
> * Let Web Console backend will be used to serve static files (compiled Web 
> Console frontend)
> * Let Web Console backend download and run as child process mongoDB. if 
> mongoDB is not installed.



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

[jira] [Commented] (IGNITE-7284) Introduce DEV_ONLY marker to IgniteLogger

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7284:


Github user asfgit closed the pull request at:

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


> Introduce DEV_ONLY marker to IgniteLogger
> -
>
> Key: IGNITE-7284
> URL: https://issues.apache.org/jira/browse/IGNITE-7284
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Major
> Fix For: 2.5
>
>
> Need to add markers support to {{IgniteLogger}} and then introduce 
> {{DEV_ONLY}} marker for warnings that can be suppressed in prod environments.
> Problem and solution are discussed in more detail here: 
> http://apache-ignite-developers.2346864.n4.nabble.com/Suppressing-quot-development-quot-warning-td25195.html
> Make sure to update Loggers documentation explaining how the parameter works 
> and what's it for:
> https://apacheignite.readme.io/docs/logging



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

[jira] [Closed] (IGNITE-7284) Introduce DEV_ONLY marker to IgniteLogger

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko closed IGNITE-7284.
---

> Introduce DEV_ONLY marker to IgniteLogger
> -
>
> Key: IGNITE-7284
> URL: https://issues.apache.org/jira/browse/IGNITE-7284
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Major
> Fix For: 2.5
>
>
> Need to add markers support to {{IgniteLogger}} and then introduce 
> {{DEV_ONLY}} marker for warnings that can be suppressed in prod environments.
> Problem and solution are discussed in more detail here: 
> http://apache-ignite-developers.2346864.n4.nabble.com/Suppressing-quot-development-quot-warning-td25195.html
> Make sure to update Loggers documentation explaining how the parameter works 
> and what's it for:
> https://apacheignite.readme.io/docs/logging



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

[jira] [Commented] (IGNITE-7284) Introduce DEV_ONLY marker to IgniteLogger

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko commented on IGNITE-7284:
-

[~slukyanov], I disagree about system property caching. I don't see much value 
in checking it every time the warning is added to the log. If we want to add an 
ability to change this value dynamically, there should be another way, probably 
via MBean. Feel free to create a separate ticket for this. Agree on the rest 
though, so I made the change myself and merged code to master. Thanks for the 
contribution!

> Introduce DEV_ONLY marker to IgniteLogger
> -
>
> Key: IGNITE-7284
> URL: https://issues.apache.org/jira/browse/IGNITE-7284
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Major
> Fix For: 2.5
>
>
> Need to add markers support to {{IgniteLogger}} and then introduce 
> {{DEV_ONLY}} marker for warnings that can be suppressed in prod environments.
> Problem and solution are discussed in more detail here: 
> http://apache-ignite-developers.2346864.n4.nabble.com/Suppressing-quot-development-quot-warning-td25195.html
> Make sure to update Loggers documentation explaining how the parameter works 
> and what's it for:
> https://apacheignite.readme.io/docs/logging



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

[jira] [Assigned] (IGNITE-7284) Introduce DEV_ONLY marker to IgniteLogger

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko reassigned IGNITE-7284:
---

Assignee: Valentin Kulichenko  (was: Stanislav Lukyanov)

> Introduce DEV_ONLY marker to IgniteLogger
> -
>
> Key: IGNITE-7284
> URL: https://issues.apache.org/jira/browse/IGNITE-7284
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Major
> Fix For: 2.5
>
>
> Need to add markers support to {{IgniteLogger}} and then introduce 
> {{DEV_ONLY}} marker for warnings that can be suppressed in prod environments.
> Problem and solution are discussed in more detail here: 
> http://apache-ignite-developers.2346864.n4.nabble.com/Suppressing-quot-development-quot-warning-td25195.html
> Make sure to update Loggers documentation explaining how the parameter works 
> and what's it for:
> https://apacheignite.readme.io/docs/logging



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

[jira] [Comment Edited] (IGNITE-2766) Cache instance is closed when client disconnects

[Mikhail Cherkasov (JIRA)]

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

Mikhail Cherkasov edited comment on IGNITE-2766 at 1/19/18 12:40 AM:
-

I can reproduce the issue with the following test:

 
{code:java}
import java.util.Arrays;
import org.apache.ignite.Ignite;
import org.apache.ignite.IgniteCache;
import org.apache.ignite.Ignition;
import org.apache.ignite.configuration.CacheConfiguration;
import org.apache.ignite.configuration.IgniteConfiguration;
import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
import org.jetbrains.annotations.NotNull;

public class ReconnectClient {
private static int id;

public static void main(String[] args) throws InterruptedException {
Ignition.setClientMode(false);

Ignite server = Ignition.start(getConfiguration());

Ignition.setClientMode(true);
Ignite client = Ignition.start(getConfiguration());

IgniteCache cache = client.cache("TEST");

cache.put("Hello", "World");

server.close();

Thread.sleep(2_000);

Ignition.setClientMode(false);
server = Ignition.start(getConfiguration());

Thread.sleep(4_000);

System.out.println(cache.get("Hello"));
cache.put("Ping", "Pong");

System.out.println("DONE");
}

@NotNull private static IgniteConfiguration getConfiguration() {
IgniteConfiguration cfg = new IgniteConfiguration();

TcpDiscoveryVmIpFinder finder = new TcpDiscoveryVmIpFinder(true);
finder.setAddresses(Arrays.asList("localhost:47500..47600"));

cfg.setIgniteInstanceName("test" + id++);

cfg.setCacheConfiguration(new CacheConfiguration("TEST"));

cfg.setDiscoverySpi( new TcpDiscoverySpi().setIpFinder(finder));
return cfg;
}
}
{code}
 


was (Author: mcherkasov):
I can reproduce the issue with the following test:

 
{code:java}
package multiplan;

import java.util.Arrays;
import org.apache.ignite.Ignite;
import org.apache.ignite.IgniteCache;
import org.apache.ignite.Ignition;
import org.apache.ignite.configuration.CacheConfiguration;
import org.apache.ignite.configuration.IgniteConfiguration;
import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
import org.jetbrains.annotations.NotNull;

public class ReconnectClient {
private static int id;

public static void main(String[] args) throws InterruptedException {
Ignition.setClientMode(false);

Ignite server = Ignition.start(getConfiguration());

Ignition.setClientMode(true);
Ignite client = Ignition.start(getConfiguration());

IgniteCache cache = client.cache("TEST");

cache.put("Hello", "World");

server.close();

Thread.sleep(2_000);

Ignition.setClientMode(false);
server = Ignition.start(getConfiguration());

Thread.sleep(4_000);

System.out.println(cache.get("Hello"));
cache.put("Ping", "Pong");

System.out.println("DONE");
}

@NotNull private static IgniteConfiguration getConfiguration() {
IgniteConfiguration cfg = new IgniteConfiguration();

TcpDiscoveryVmIpFinder finder = new TcpDiscoveryVmIpFinder(true);
finder.setAddresses(Arrays.asList("localhost:47500..47600"));

cfg.setIgniteInstanceName("test" + id++);

cfg.setCacheConfiguration(new CacheConfiguration("TEST"));

cfg.setDiscoverySpi( new TcpDiscoverySpi().setIpFinder(finder));
return cfg;
}
}
{code}
 

> Cache instance is closed when client disconnects
> 
>
> Key: IGNITE-2766
> URL: https://issues.apache.org/jira/browse/IGNITE-2766
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Ilya Kasnacheev
>Priority: Major
>
> In case client disconnects and reconnects after network timeout (i.e., with a 
> new ID), all cache instances acquired by this client are closed and are not 
> functional. User has to create a special logic to handle this case.
> Cache proxy should be able to handle this automatically.



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

[jira] [Reopened] (IGNITE-2766) Cache instance is closed when client disconnects

[Mikhail Cherkasov (JIRA)]

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

Mikhail Cherkasov reopened IGNITE-2766:
---

> Cache instance is closed when client disconnects
> 
>
> Key: IGNITE-2766
> URL: https://issues.apache.org/jira/browse/IGNITE-2766
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Ilya Kasnacheev
>Priority: Major
>
> In case client disconnects and reconnects after network timeout (i.e., with a 
> new ID), all cache instances acquired by this client are closed and are not 
> functional. User has to create a special logic to handle this case.
> Cache proxy should be able to handle this automatically.



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

[jira] [Commented] (IGNITE-2766) Cache instance is closed when client disconnects

[Mikhail Cherkasov (JIRA)]

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

Mikhail Cherkasov commented on IGNITE-2766:
---

I can reproduce the issue with the following test:

 
{code:java}
package multiplan;

import java.util.Arrays;
import org.apache.ignite.Ignite;
import org.apache.ignite.IgniteCache;
import org.apache.ignite.Ignition;
import org.apache.ignite.configuration.CacheConfiguration;
import org.apache.ignite.configuration.IgniteConfiguration;
import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
import org.jetbrains.annotations.NotNull;

public class ReconnectClient {
private static int id;

public static void main(String[] args) throws InterruptedException {
Ignition.setClientMode(false);

Ignite server = Ignition.start(getConfiguration());

Ignition.setClientMode(true);
Ignite client = Ignition.start(getConfiguration());

IgniteCache cache = client.cache("TEST");

cache.put("Hello", "World");

server.close();

Thread.sleep(2_000);

Ignition.setClientMode(false);
server = Ignition.start(getConfiguration());

Thread.sleep(4_000);

System.out.println(cache.get("Hello"));
cache.put("Ping", "Pong");

System.out.println("DONE");
}

@NotNull private static IgniteConfiguration getConfiguration() {
IgniteConfiguration cfg = new IgniteConfiguration();

TcpDiscoveryVmIpFinder finder = new TcpDiscoveryVmIpFinder(true);
finder.setAddresses(Arrays.asList("localhost:47500..47600"));

cfg.setIgniteInstanceName("test" + id++);

cfg.setCacheConfiguration(new CacheConfiguration("TEST"));

cfg.setDiscoverySpi( new TcpDiscoverySpi().setIpFinder(finder));
return cfg;
}
}
{code}
 

> Cache instance is closed when client disconnects
> 
>
> Key: IGNITE-2766
> URL: https://issues.apache.org/jira/browse/IGNITE-2766
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Ilya Kasnacheev
>Priority: Major
>
> In case client disconnects and reconnects after network timeout (i.e., with a 
> new ID), all cache instances acquired by this client are closed and are not 
> functional. User has to create a special logic to handle this case.
> Cache proxy should be able to handle this automatically.



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

[jira] [Updated] (IGNITE-5836) AffinityFunctionContext should provide consistent previous assignment

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-5836:

Fix Version/s: 2.5

> AffinityFunctionContext should provide consistent previous assignment
> -
>
> Key: IGNITE-5836
> URL: https://issues.apache.org/jira/browse/IGNITE-5836
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.0
>Reporter: Valentin Kulichenko
>Assignee: Evgenii Zhuravlev
>Priority: Critical
>  Labels: usability
> Fix For: 2.5
>
>
> Currently each cache maintains its own {{AffinityFunctionContext}}. This 
> leads to the case that {{previousAssignment}} can be different for two caches 
> created on different topology versions. In particular, this broke 
> {{FairAffinityFunction}} which was removed because of that.
> We should do the following:
> * Make sure that {{previousAssignment}} is consistent for all caches with 
> same affinity function, regardless of topology versions caches were created 
> on.
> * Add mechanism to enforce equality check for affinity functions. We probably 
> will need to force user to implement {{equals}} for cache node filter and 
> backup filter.
> * When above is done, bring back {{FairAffinityFunction}}.
> This is also discussed on dev list: 
> http://apache-ignite-developers.2346864.n4.nabble.com/Resurrect-FairAffinityFunction-td19987.html



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

[jira] [Closed] (IGNITE-7376) Document optional SQL on-heap row cache

[Prachi Garg (JIRA)]

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

Prachi Garg closed IGNITE-7376.
---

> Document optional SQL on-heap row cache
> ---
>
> Key: IGNITE-7376
> URL: https://issues.apache.org/jira/browse/IGNITE-7376
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Taras Ledkov
>Assignee: Prachi Garg
>Priority: Major
> Fix For: 2.4
>
>
> Add documentation for on-heap row cache implemented at IGNITE-7173



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

[jira] [Comment Edited] (IGNITE-7454) Wrong package in IgniteExamplesMLTestSuite after it was moved per IGNITE-7203

[Oleg Ignatenko (JIRA)]

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

Oleg Ignatenko edited comment on IGNITE-7454 at 1/18/18 8:21 PM:
-

Confirmed above observation from [~vveider]: "incorrect" package indeed doesn't 
break the compilation. I just tested this by creating a trial class in some 
code I worked with injected artificial package name that didn't match 
containing directory: build with {{mvn clean package}} passed successfully.

^^^ [~avinogradov] - you  might be interested in this as we yesterday discussed 
this issue. You may even try similar test with your own code - it turned out 
very easy to make and try and see for yourself.

-

As a side note Java 8 JLS uses appropriate example in [section 7.2. Host 
Support for 
Packages|https://docs.oracle.com/javase/specs/jls/se8/html/jls-7.html#jls-7.2] 
with package name {{children.activities.crafts.papierMâché}} explicitly 
differing from source code directory 
{{children/activities/crafts/papierM@00e2ch@00e9}} (concrete purpose of the 
example in JLS is to demonstrate options for supporting Unicode in package 
names but it also shows that generally this difference is not forbidden).


was (Author: oignatenko):
Confirmed above observation from [~vveider]: "incorrect" package indeed doesn't 
break the compilation. I just tested this by creating a trial class in some 
code I worked with injected artificial package name that didn't match 
containing directory: build with {{mvn clean package}} passed successfully.

^^^ [~avinogradov] - you  might be interested in this as we yesterday discussed 
this issue. You may even try similar test with your own code - it turned out 
very easy to make and try and see for yourself.

> Wrong package in IgniteExamplesMLTestSuite after it was moved per IGNITE-7203
> -
>
> Key: IGNITE-7454
> URL: https://issues.apache.org/jira/browse/IGNITE-7454
> Project: Ignite
>  Issue Type: Bug
>  Components: examples, ml, yardstick
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Fix For: 2.4
>
>
> Wrong package in IgniteExamplesMLTestSuite after it was moved per 
> IGNITE-7203: \{{org.apache.ignite.ml.testsuites}}. Also, it is not added to 
> the list in {{IgniteExamplesSelfTestSuite{{ which is supposed to run all 
> examples self-tests.
> Change to correct package: \{{org.apache.ignite.testsuites}} and add to main 
> testsuite.
> For the sake of completeness, a bunch of newer ml benchmarks (done per 
> IGNITE-7214 and IGNITE-7097) were forgotten to be moved in yardstick module 
> when merging to master. These should be fixed (moved to proper folder).



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

[jira] [Created] (IGNITE-7470) Eviction policy for SQL on-heap row cache

[Denis Magda (JIRA)]

Denis Magda created IGNITE-7470:
---

 Summary: Eviction policy for SQL on-heap row cache
 Key: IGNITE-7470
 URL: https://issues.apache.org/jira/browse/IGNITE-7470
 Project: Ignite
  Issue Type: New Feature
  Components: sql
Affects Versions: 2.4
Reporter: Denis Magda


SQL on-heap row cache was introduced in Ignite 2.4:

[https://apacheignite-sql.readme.io/v2.3/docs/performance-and-debugging_24_hidden#sql-on-heap-row-cache]

The cache can occupy as much RAM as allocated and used for off-heap data 
regions. If a user stores dozens or hundreds of gigabytes in the data regions 
the on-heap row cache will become enormous and the cluster will suffer from 
atrocious GC pauses.

Let's come up with an eviction policy for this cache. 



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

[jira] [Resolved] (IGNITE-6607) Thin client: protocol documentation

[Denis Magda (JIRA)]

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

Denis Magda resolved IGNITE-6607.
-
Resolution: Fixed

> Thin client: protocol documentation
> ---
>
> Key: IGNITE-6607
> URL: https://issues.apache.org/jira/browse/IGNITE-6607
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, platforms
>Affects Versions: 2.3
>Reporter: Pavel Tupitsyn
>Assignee: Denis Magda
>Priority: Blocker
> Fix For: 2.4
>
>
> Document thin client protocol on Apache Ignite readme.op:
> * Common message format (length, flags)
> * Data types (endianness, strings, etc)
> * Request/Response format for each message type
> * How to connect
> A list of supported commands can be taken from here:
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/platform/client/ClientMessageParser.java
> The protocol documentation format can be similar to REST API:
> https://apacheignite.readme.io/docs/rest-api



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

[jira] [Commented] (IGNITE-6607) Thin client: protocol documentation

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-6607:
-

[~pgarg] , great job! I've finished with the review and did minor improvements.

 

Please announce that the doc is ready for 2.4 on the @dev list sharing all the 
links prepared.

> Thin client: protocol documentation
> ---
>
> Key: IGNITE-6607
> URL: https://issues.apache.org/jira/browse/IGNITE-6607
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, platforms
>Affects Versions: 2.3
>Reporter: Pavel Tupitsyn
>Assignee: Denis Magda
>Priority: Blocker
> Fix For: 2.4
>
>
> Document thin client protocol on Apache Ignite readme.op:
> * Common message format (length, flags)
> * Data types (endianness, strings, etc)
> * Request/Response format for each message type
> * How to connect
> A list of supported commands can be taken from here:
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/platform/client/ClientMessageParser.java
> The protocol documentation format can be similar to REST API:
> https://apacheignite.readme.io/docs/rest-api



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

[jira] [Closed] (IGNITE-6607) Thin client: protocol documentation

[Denis Magda (JIRA)]

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

Denis Magda closed IGNITE-6607.
---

> Thin client: protocol documentation
> ---
>
> Key: IGNITE-6607
> URL: https://issues.apache.org/jira/browse/IGNITE-6607
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, platforms
>Affects Versions: 2.3
>Reporter: Pavel Tupitsyn
>Assignee: Denis Magda
>Priority: Blocker
> Fix For: 2.4
>
>
> Document thin client protocol on Apache Ignite readme.op:
> * Common message format (length, flags)
> * Data types (endianness, strings, etc)
> * Request/Response format for each message type
> * How to connect
> A list of supported commands can be taken from here:
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/platform/client/ClientMessageParser.java
> The protocol documentation format can be similar to REST API:
> https://apacheignite.readme.io/docs/rest-api



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

[jira] [Updated] (IGNITE-7351) Create a page for continuous queries

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-7351:

Fix Version/s: (was: 2.4)
   2.5

> Create a page for continuous queries
> 
>
> Key: IGNITE-7351
> URL: https://issues.apache.org/jira/browse/IGNITE-7351
> Project: Ignite
>  Issue Type: Sub-task
>  Components: site
>Reporter: Denis Magda
>Priority: Major
> Fix For: 2.5
>
>
> Create a page for continuous queries putting it under Features menu on the 
> site. This capability is a strong distinguisher from relational databases 
> that do not support continuous notifications and processing built around them.



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

[jira] [Updated] (IGNITE-7403) Improve content on What's Ignite page

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-7403:

Fix Version/s: 2.4

> Improve content on What's Ignite page
> -
>
> Key: IGNITE-7403
> URL: https://issues.apache.org/jira/browse/IGNITE-7403
> Project: Ignite
>  Issue Type: Task
>  Components: site
>Reporter: Denis Magda
>Assignee: Vica Abramova
>Priority: Major
> Fix For: 2.4
>
> Attachments: What.png, What_v2.png
>
>
> A proposed of a new draft for the What's Ignite page:
> https://ignite.apache.org/whatisignite-2.html
> The goal is to make the page more informative and tell about the main things 
> of Ignite or provide references to them. Overall, the structure should be as 
> follows:
> - Product name and definition.
> - Diagram.
> - Features and Benefits
> - Ignite facts



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

[jira] [Updated] (IGNITE-7404) Use various backgrounds for Ignite main page's main blocks

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-7404:

Fix Version/s: 2.4

> Use various backgrounds for Ignite main page's main blocks
> --
>
> Key: IGNITE-7404
> URL: https://issues.apache.org/jira/browse/IGNITE-7404
> Project: Ignite
>  Issue Type: Task
>  Components: site
>Reporter: Denis Magda
>Assignee: Prachi Garg
>Priority: Major
> Fix For: 2.4
>
> Attachments: Rotation.png
>
>
> This ticket is intended to improve the main page:
> https://ignite.apache.org
> All the content that goes below the banner is shown on a *white* background. 
> As a result, it's difficult to separate main building blocks from each other 
> *visually*.
> Suggest to come up with a second background and rotate it together with the 
> white one among the building blocks. For instance:
> - Apache Ignite definition and use cases (white)
> - Features (new background - probably grey)
> - How Ignite compares (white)
> - Screencast (new background)
> - News (white)



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

[jira] [Assigned] (IGNITE-6994) Need to document PartitionLossPolicy

[Denis Magda (JIRA)]

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

Denis Magda reassigned IGNITE-6994:
---

Assignee: Sergey Puchnin  (was: Prachi Garg)

> Need to document PartitionLossPolicy
> 
>
> Key: IGNITE-6994
> URL: https://issues.apache.org/jira/browse/IGNITE-6994
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Sergey Puchnin
>Priority: Critical
>  Labels: documentation
> Fix For: 2.4
>
>
> Since 2.0 we have a feature that makes cache(s) unavailable in case of data 
> loss; exact behavior is controlled by {{PartitionLossPolicy}}: 
> [https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/PartitionLossPolicy.html]
> However, there is no mentioning in the documentation about this. Need to 
> provide an explanation of how and when it should be used and provide 
> configuration examples.
> The documentation has to address questions and misunderstandings asked in 
> these discussions:
>  * 
> [http://apache-ignite-developers.2346864.n4.nabble.com/Partition-loss-policy-how-to-use-td25341.html]
>  * 
> [http://apache-ignite-developers.2346864.n4.nabble.com/Partition-loss-policy-to-disable-cache-completely-td26212.html]
> Improve the JavaDoc too whenever is possible.



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

[jira] [Commented] (IGNITE-6994) Need to document PartitionLossPolicy

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-6994:
-

[~sergey.puch...@gmail.com] , as agreed please document the policies and their 
usage under this section:

[https://apacheignite.readme.io/v2.3/docs/cache-modes-24#partition-loss-policies]

Presently the page is hidden and visible to doc writers.

Once you finish, please reassign the ticket on me.

> Need to document PartitionLossPolicy
> 
>
> Key: IGNITE-6994
> URL: https://issues.apache.org/jira/browse/IGNITE-6994
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Prachi Garg
>Priority: Critical
>  Labels: documentation
> Fix For: 2.4
>
>
> Since 2.0 we have a feature that makes cache(s) unavailable in case of data 
> loss; exact behavior is controlled by {{PartitionLossPolicy}}: 
> [https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/PartitionLossPolicy.html]
> However, there is no mentioning in the documentation about this. Need to 
> provide an explanation of how and when it should be used and provide 
> configuration examples.
> The documentation has to address questions and misunderstandings asked in 
> these discussions:
>  * 
> [http://apache-ignite-developers.2346864.n4.nabble.com/Partition-loss-policy-how-to-use-td25341.html]
>  * 
> [http://apache-ignite-developers.2346864.n4.nabble.com/Partition-loss-policy-to-disable-cache-completely-td26212.html]
> Improve the JavaDoc too whenever is possible.



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

[jira] [Updated] (IGNITE-6994) Need to document PartitionLossPolicy

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-6994:

Description: 
Since 2.0 we have a feature that makes cache(s) unavailable in case of data 
loss; exact behavior is controlled by {{PartitionLossPolicy}}: 
[https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/PartitionLossPolicy.html]

However, there is no mentioning in the documentation about this. Need to 
provide an explanation of how and when it should be used and provide 
configuration examples.

The documentation has to address questions and misunderstandings asked in these 
discussions:
 * 
[http://apache-ignite-developers.2346864.n4.nabble.com/Partition-loss-policy-how-to-use-td25341.html]
 * 
[http://apache-ignite-developers.2346864.n4.nabble.com/Partition-loss-policy-to-disable-cache-completely-td26212.html]

Improve the JavaDoc too whenever is possible.

  was:
Since 2.0 we have a feature that makes cache(s) unavailable in case of data 
loss; exact behavior is controlled by {{PartitionLossPolicy}}: 
https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/PartitionLossPolicy.html

However, there is no mentioning in documentation about this. Need to provide 
explanation of how and when it should be used and provide configuration 
examples.


> Need to document PartitionLossPolicy
> 
>
> Key: IGNITE-6994
> URL: https://issues.apache.org/jira/browse/IGNITE-6994
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Prachi Garg
>Priority: Critical
>  Labels: documentation
> Fix For: 2.4
>
>
> Since 2.0 we have a feature that makes cache(s) unavailable in case of data 
> loss; exact behavior is controlled by {{PartitionLossPolicy}}: 
> [https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/PartitionLossPolicy.html]
> However, there is no mentioning in the documentation about this. Need to 
> provide an explanation of how and when it should be used and provide 
> configuration examples.
> The documentation has to address questions and misunderstandings asked in 
> these discussions:
>  * 
> [http://apache-ignite-developers.2346864.n4.nabble.com/Partition-loss-policy-how-to-use-td25341.html]
>  * 
> [http://apache-ignite-developers.2346864.n4.nabble.com/Partition-loss-policy-to-disable-cache-completely-td26212.html]
> Improve the JavaDoc too whenever is possible.



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

[jira] [Updated] (IGNITE-6994) Need to document PartitionLossPolicy

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-6994:

Issue Type: Task  (was: Improvement)

> Need to document PartitionLossPolicy
> 
>
> Key: IGNITE-6994
> URL: https://issues.apache.org/jira/browse/IGNITE-6994
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Prachi Garg
>Priority: Critical
>  Labels: documentation
> Fix For: 2.4
>
>
> Since 2.0 we have a feature that makes cache(s) unavailable in case of data 
> loss; exact behavior is controlled by {{PartitionLossPolicy}}: 
> [https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/PartitionLossPolicy.html]
> However, there is no mentioning in the documentation about this. Need to 
> provide an explanation of how and when it should be used and provide 
> configuration examples.
> The documentation has to address questions and misunderstandings asked in 
> these discussions:
>  * 
> [http://apache-ignite-developers.2346864.n4.nabble.com/Partition-loss-policy-how-to-use-td25341.html]
>  * 
> [http://apache-ignite-developers.2346864.n4.nabble.com/Partition-loss-policy-to-disable-cache-completely-td26212.html]
> Improve the JavaDoc too whenever is possible.



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

[jira] [Comment Edited] (IGNITE-6994) Need to document PartitionLossPolicy

[Denis Magda (JIRA)]

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

Denis Magda edited comment on IGNITE-6994 at 1/18/18 6:36 PM:
--

The documentation has to address questions and misunderstandings asked in these 
discussions:
 * 
[http://apache-ignite-developers.2346864.n4.nabble.com/Partition-loss-policy-how-to-use-td25341.html]
 * 
http://apache-ignite-developers.2346864.n4.nabble.com/Partition-loss-policy-to-disable-cache-completely-td26212.html


was (Author: dmagda):
Discussion on @dev list: 
http://apache-ignite-developers.2346864.n4.nabble.com/Partition-loss-policy-how-to-use-td25341.html

> Need to document PartitionLossPolicy
> 
>
> Key: IGNITE-6994
> URL: https://issues.apache.org/jira/browse/IGNITE-6994
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Prachi Garg
>Priority: Critical
>  Labels: documentation
> Fix For: 2.4
>
>
> Since 2.0 we have a feature that makes cache(s) unavailable in case of data 
> loss; exact behavior is controlled by {{PartitionLossPolicy}}: 
> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/PartitionLossPolicy.html
> However, there is no mentioning in documentation about this. Need to provide 
> explanation of how and when it should be used and provide configuration 
> examples.



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

[jira] [Issue Comment Deleted] (IGNITE-6994) Need to document PartitionLossPolicy

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-6994:

Comment: was deleted

(was: The documentation has to address questions and misunderstandings asked in 
these discussions:
 * 
[http://apache-ignite-developers.2346864.n4.nabble.com/Partition-loss-policy-how-to-use-td25341.html]
 * 
http://apache-ignite-developers.2346864.n4.nabble.com/Partition-loss-policy-to-disable-cache-completely-td26212.html)

> Need to document PartitionLossPolicy
> 
>
> Key: IGNITE-6994
> URL: https://issues.apache.org/jira/browse/IGNITE-6994
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Prachi Garg
>Priority: Critical
>  Labels: documentation
> Fix For: 2.4
>
>
> Since 2.0 we have a feature that makes cache(s) unavailable in case of data 
> loss; exact behavior is controlled by {{PartitionLossPolicy}}: 
> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/PartitionLossPolicy.html
> However, there is no mentioning in documentation about this. Need to provide 
> explanation of how and when it should be used and provide configuration 
> examples.



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

[jira] [Resolved] (IGNITE-7463) .NET: Thin client: OP_BINARY_TYPE_GET uses writeIntArray for schemas

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn resolved IGNITE-7463.

Resolution: Fixed

> .NET: Thin client: OP_BINARY_TYPE_GET uses writeIntArray for schemas
> 
>
> Key: IGNITE-7463
> URL: https://issues.apache.org/jira/browse/IGNITE-7463
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms, thin client
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
> Fix For: 2.4
>
>
> OP_BINARY_TYPE_GET uses writeIntArray for schemas, which is not consistent 
> with OP_BINARY_TYPE_PUT.
> Make sure to fix the spec and readme.io doc.



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

[jira] [Comment Edited] (IGNITE-7463) .NET: Thin client: OP_BINARY_TYPE_GET uses writeIntArray for schemas

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn edited comment on IGNITE-7463 at 1/18/18 6:27 PM:
-

Merged to master: {{5f23f85a60e3e902d9b4014839fdeb8791e9ce5a}}.
Cherry-picked to ignite-2.4: {{bd6be8a4653322905a3b63850c7e033ce3801ce5}}.


was (Author: ptupitsyn):
Merged to master: {{5f23f85a60e3e902d9b4014839fdeb8791e9ce5a}}.

> .NET: Thin client: OP_BINARY_TYPE_GET uses writeIntArray for schemas
> 
>
> Key: IGNITE-7463
> URL: https://issues.apache.org/jira/browse/IGNITE-7463
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms, thin client
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
> Fix For: 2.4
>
>
> OP_BINARY_TYPE_GET uses writeIntArray for schemas, which is not consistent 
> with OP_BINARY_TYPE_PUT.
> Make sure to fix the spec and readme.io doc.



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

[jira] [Commented] (IGNITE-7463) .NET: Thin client: OP_BINARY_TYPE_GET uses writeIntArray for schemas

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-7463:


Merged to master: {{5f23f85a60e3e902d9b4014839fdeb8791e9ce5a}}.

> .NET: Thin client: OP_BINARY_TYPE_GET uses writeIntArray for schemas
> 
>
> Key: IGNITE-7463
> URL: https://issues.apache.org/jira/browse/IGNITE-7463
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms, thin client
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
> Fix For: 2.4
>
>
> OP_BINARY_TYPE_GET uses writeIntArray for schemas, which is not consistent 
> with OP_BINARY_TYPE_PUT.
> Make sure to fix the spec and readme.io doc.



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

[jira] [Commented] (IGNITE-7454) Wrong package in IgniteExamplesMLTestSuite after it was moved per IGNITE-7203

[Oleg Ignatenko (JIRA)]

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

Oleg Ignatenko commented on IGNITE-7454:


Confirmed above observation from [~vveider]: "incorrect" package indeed doesn't 
break the compilation. I just tested this by creating a trial class in some 
code I worked with injected artificial package name that didn't match 
containing directory: build with {{mvn clean package}} passed successfully.

^^^ [~avinogradov] - you  might be interested in this as we yesterday discussed 
this issue. You may even try similar test with your own code - it turned out 
very easy to make and try and see for yourself.

> Wrong package in IgniteExamplesMLTestSuite after it was moved per IGNITE-7203
> -
>
> Key: IGNITE-7454
> URL: https://issues.apache.org/jira/browse/IGNITE-7454
> Project: Ignite
>  Issue Type: Bug
>  Components: examples, ml, yardstick
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Fix For: 2.4
>
>
> Wrong package in IgniteExamplesMLTestSuite after it was moved per 
> IGNITE-7203: \{{org.apache.ignite.ml.testsuites}}. Also, it is not added to 
> the list in {{IgniteExamplesSelfTestSuite{{ which is supposed to run all 
> examples self-tests.
> Change to correct package: \{{org.apache.ignite.testsuites}} and add to main 
> testsuite.
> For the sake of completeness, a bunch of newer ml benchmarks (done per 
> IGNITE-7214 and IGNITE-7097) were forgotten to be moved in yardstick module 
> when merging to master. These should be fixed (moved to proper folder).



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

[jira] [Commented] (IGNITE-5298) .NET: DML update via LINQ

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-5298:


Another example: http://entityframework-extensions.net/

{code}
context.Customers.Where(x => !x.IsActif)
   .UpdateFromQuery(x => 
new Customer {IsActif = true});
{code}


> .NET: DML update via LINQ
> -
>
> Key: IGNITE-5298
> URL: https://issues.apache.org/jira/browse/IGNITE-5298
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Pavel Tupitsyn
>Assignee: Sergey Stronchinskiy
>Priority: Major
>  Labels: .NET, LINQ, important
>
> Bulk update with LINQ:
> {code}
> var persons = ignite.GetCache("persons").AsCacheQueryable();
> int affectedRows = persons.Where(x => x.Key > 10).UpdateAll(x => 
> x.Value.OrgId = 7);
> {code}
> See bulk delete with {{RemoveAll}}, IGNITE-4904.



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

[jira] [Assigned] (IGNITE-7469) Update Apache Ignite documentation about RPM-repository usage

[Denis Magda (JIRA)]

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

Denis Magda reassigned IGNITE-7469:
---

Assignee: Denis Magda

> Update Apache Ignite documentation about RPM-repository usage
> -
>
> Key: IGNITE-7469
> URL: https://issues.apache.org/jira/browse/IGNITE-7469
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Peter Ivanov
>Assignee: Denis Magda
>Priority: Major
> Fix For: 2.4
>
>
> After IGNITE-7107 release in 2.4 version Apache Ignite will be available 
> through custom RPM repository packed in RPM package. Corresponding 
> documentation (how to add RPM-repository and install from it) should be 
> created.



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

[jira] [Updated] (IGNITE-7469) Update Apache Ignite documentation about RPM-repository usage

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-7469:

Environment: (was: After IGNITE-7107 release in 2.4 version Apache 
Ignite will be available through custom RPM repository packed in RPM package. 
Corresponding documentation (how to add RPM-repository and install from it) 
should be created.)

> Update Apache Ignite documentation about RPM-repository usage
> -
>
> Key: IGNITE-7469
> URL: https://issues.apache.org/jira/browse/IGNITE-7469
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Peter Ivanov
>Priority: Major
> Fix For: 2.4
>
>




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

[jira] [Updated] (IGNITE-7469) Update Apache Ignite documentation about RPM-repository usage

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-7469:

Description: After IGNITE-7107 release in 2.4 version Apache Ignite will be 
available through custom RPM repository packed in RPM package. Corresponding 
documentation (how to add RPM-repository and install from it) should be created.

> Update Apache Ignite documentation about RPM-repository usage
> -
>
> Key: IGNITE-7469
> URL: https://issues.apache.org/jira/browse/IGNITE-7469
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Peter Ivanov
>Priority: Major
> Fix For: 2.4
>
>
> After IGNITE-7107 release in 2.4 version Apache Ignite will be available 
> through custom RPM repository packed in RPM package. Corresponding 
> documentation (how to add RPM-repository and install from it) should be 
> created.



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

[jira] [Commented] (IGNITE-7146) Assertion in GridCacheTxFinishSync

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov commented on IGNITE-7146:
--

Does anyone know why we need GridCacheTxFinishSync?
All master tests are passed if we completely remove this class from code

> Assertion in GridCacheTxFinishSync
> --
>
> Key: IGNITE-7146
> URL: https://issues.apache.org/jira/browse/IGNITE-7146
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Alexander Belyak
>Priority: Major
>
> Got assertion error in clear log:
> {noformat}
> 2017-12-07 17:24:10.358 
> [ERROR][sys-#2376%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.GridClosureProcessor]
>  Closure execution failed with error.
> java.lang.AssertionError: null
> at 
> org.apache.ignite.internal.processors.cache.distributed.GridCacheTxFinishSync$TxFinishSync.onSend(GridCacheTxFinishSync.java:250)
> at 
> org.apache.ignite.internal.processors.cache.distributed.GridCacheTxFinishSync$ThreadFinishSync.onSend(GridCacheTxFinishSync.java:163)
> at 
> org.apache.ignite.internal.processors.cache.distributed.GridCacheTxFinishSync.onFinishSend(GridCacheTxFinishSync.java:70)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.beforeFinishRemote(IgniteTxManager.java:1522)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:750)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:690)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:430)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.rollbackNearTxLocalAsync(GridNearTxLocal.java:3314)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.access$4900(GridNearTxLocal.java:122)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$26.run(GridNearTxLocal.java:4130)
> at 
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6685)
> at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
> at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> 2017-12-07 17:24:10.358 
> [ERROR][sys-#2376%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.GridClosureProcessor]
>  Runtime error caught during grid runnable execution: GridWorker 
> [name=closure-proc-worker, igniteInstanceName=DPL_GRID%DplGridNodeName, 
> finished=false, hashCode=1220995949, interrupted=false, 
> runner=sys-#2376%DPL_GRID%DplGridNodeName%]
> {noformat}



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

[jira] [Commented] (IGNITE-6846) Add metrics for entry processor invocations

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov commented on IGNITE-6846:
--

[~vkulichenko] Hi!

Sorry, for delay. I have resolved conflicts, rerun my new tests locally and 
they passed.
And started Run All 
[tests|https://ci.ignite.apache.org/viewQueued.html?itemId=1047828=queuedBuildOverviewTab]

> Add metrics for entry processor invocations
> ---
>
> Key: IGNITE-6846
> URL: https://issues.apache.org/jira/browse/IGNITE-6846
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Alexey Kuznetsov
>Priority: Critical
>  Labels: iep-6
> Fix For: 2.5
>
>
> {{CacheMetrics}} object has multiple metrics for various cache operations 
> like {{get}}, {{put}} and {{remove}}, but nothing for 
> {{invoke}}/{{EntryProcessor}}. It makes sense to add such metrics, for 
> example:
> * Total number of `invoke` operations executed.
> * Number of `invoke` operations that included updates.
> * Number of read-only `invoke` operations.
> * Min/max/avg execution time.
> * ...



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

[jira] [Commented] (IGNITE-5565) Replace Cron4J with Quartz or Spring scheduler for ignite-schedule module.

[Sergey Kosarev (JIRA)]

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

Sergey Kosarev commented on IGNITE-5565:


second version

change to Spring ThreadPoolTaskScheder

removed Cron4J and Quartz

> Replace Cron4J with Quartz or Spring scheduler for ignite-schedule module.
> --
>
> Key: IGNITE-5565
> URL: https://issues.apache.org/jira/browse/IGNITE-5565
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Reporter: Alexey Kuznetsov
>Assignee: Sergey Kosarev
>Priority: Major
>
> 1) Cron4J is very old:
>   Latest Cron4j 2.2.5 released: 28-Dec-2011 
>   Latest Quarz 2.3.0 released: 20-Apr-2017
> 2) Not very friendly license:
>   CronJ4 licensed under GNU LESSER GENERAL PUBLIC LICENSE
>   Quartz is freely usable, licensed under the Apache 2.0 license.
> So, if we replace Cron4J  with Quartz we can move ignite-schedule module
>  from lgpl profile to main distribution.
> Also spring's scheduler could be considered as Cron4J alternative.



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

[jira] [Assigned] (IGNITE-7314) Iterators could return multiple values of the same key when MVCC is enabled

[Roman Kondakov (JIRA)]

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

Roman Kondakov reassigned IGNITE-7314:
--

Assignee: Roman Kondakov

> Iterators could return multiple values of the same key when MVCC is enabled
> ---
>
> Key: IGNITE-7314
> URL: https://issues.apache.org/jira/browse/IGNITE-7314
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Vladimir Ozerov
>Assignee: Roman Kondakov
>Priority: Major
> Fix For: 2.5
>
>
> It MVCC is enabled most of tests in {{IgniteCacheFullApiSelfTestSuite}} works 
> fine. However, they are really *slow*. So slow, that TC cannot cope with them 
> and kills the build after 1h30m of execution.
> Root cause: iterators return too much values as they do not use any specific 
> version by default ({{null}} is passed). Essentially, we need to add MVCC 
> support to iterators and "global" operations, which use them.



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

[jira] [Commented] (IGNITE-6946) Change Ignite Logger configuration on the fly

[Stanislav Lukyanov (JIRA)]

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

Stanislav Lukyanov commented on IGNITE-6946:


After some research, it seems that we can update logger configurations for JUL, 
log4j, log4j2 (+ SLF4J backed by these loggers) on the fly out of the box.

JUL allows to do that via an MXBean.

Log4j and log4j2 can be configured to watch changes of the log4j.xml or 
log4j2.xml file, picking up new configuration if it has changed.
For Log4j we need a small code update in Ignite to enable this.
For Log4j2 no updates are required per se, but it would be nice to enable 
config changes watches in the default config file (ignite-log4j2.xml).

> Change Ignite Logger configuration on the fly
> -
>
> Key: IGNITE-6946
> URL: https://issues.apache.org/jira/browse/IGNITE-6946
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.3
>Reporter: Alexey Popov
>Assignee: Stanislav Lukyanov
>Priority: Major
>
> It would be great if we can change Ignite Logger configuration on the fly 
> without restarting the cluster node. It will really help to debug an issue 
> while it is reproducible at the current cluster state.
>  It should be done within the configured type of a logger, i.e. it is enough 
> to change logging levels without changing the Logger type itself.
> Such configuration change should be done for all supported logger types (JUL, 
> log4j, log4i2 and others).
> Also it should be done easily, for instance, via Visor, WebConsole or any 
> other user-friendly tool ).



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

[jira] [Commented] (IGNITE-6711) DataRegionMetrics#totalAllocatedPages is not valid after node restart

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6711:


GitHub user andrey-kuznetsov opened a pull request:

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

IGNITE-6711: Squashed ignite-6711 branch.



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

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

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

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

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

This closes #3401


commit d5d9a5af16eaf3cac829443d3c3174470dfdc99d
Author: Andrey Kuznetsov 
Date:   2018-01-18T14:26:47Z

IGNITE-6711: Squashed ignite-6711 branch.




> DataRegionMetrics#totalAllocatedPages is not valid after node restart
> -
>
> Key: IGNITE-6711
> URL: https://issues.apache.org/jira/browse/IGNITE-6711
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.2
>Reporter: Alexey Goncharuk
>Assignee: Andrey Kuznetsov
>Priority: Major
>  Labels: iep-6, newbie
> Fix For: 2.4
>
>
> Currently, data region metric tracks total allocated pages by a callback on 
> page allocation. However, when a node with enabled persistence is started, 
> some of the pages are already allocated, which leads to an incorrect metric 
> value.



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

[jira] [Created] (IGNITE-7469) Update Apache Ignite documentation about RPM-repository usage

[Peter Ivanov (JIRA)]

Peter Ivanov created IGNITE-7469:


 Summary: Update Apache Ignite documentation about RPM-repository 
usage
 Key: IGNITE-7469
 URL: https://issues.apache.org/jira/browse/IGNITE-7469
 Project: Ignite
  Issue Type: Task
  Components: documentation
 Environment: After IGNITE-7107 release in 2.4 version Apache Ignite 
will be available through custom RPM repository packed in RPM package. 
Corresponding documentation (how to add RPM-repository and install from it) 
should be created.
Reporter: Peter Ivanov
 Fix For: 2.4






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

[jira] [Commented] (IGNITE-6711) DataRegionMetrics#totalAllocatedPages is not valid after node restart

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-6711:
--

Task merge delayed due we detected that allocated metric have different nature 
when we have persistence store.
In case cache store used we should accumulate metric at operations inside 
FilePageStore. 
So, now Andrey is working on this refactoring.

> DataRegionMetrics#totalAllocatedPages is not valid after node restart
> -
>
> Key: IGNITE-6711
> URL: https://issues.apache.org/jira/browse/IGNITE-6711
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.2
>Reporter: Alexey Goncharuk
>Assignee: Andrey Kuznetsov
>Priority: Major
>  Labels: iep-6, newbie
> Fix For: 2.4
>
>
> Currently, data region metric tracks total allocated pages by a callback on 
> page allocation. However, when a node with enabled persistence is started, 
> some of the pages are already allocated, which leads to an incorrect metric 
> value.



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

[jira] [Comment Edited] (IGNITE-7465) .NET: SqlDdlExample fails with standalone node

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn edited comment on IGNITE-7465 at 1/18/18 1:44 PM:
-

Changed dummy cache to {{Replicated}} for now.
Merged to master: {{3dc1fcdaf1257a2a63c27dcb0e18d32495734cd3}}.
Cherry-picked to ignite-2.4: {{dd06d0bd7ef266bfbe156e858b312d1ac86e8982}}.


was (Author: ptupitsyn):
Changed dummy cache to {{Replicated}} for now.
Merged to master: {{3dc1fcdaf1257a2a63c27dcb0e18d32495734cd3}}.

> .NET: SqlDdlExample fails with standalone node
> --
>
> Key: IGNITE-7465
> URL: https://issues.apache.org/jira/browse/IGNITE-7465
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
> Fix For: 2.4
>
>
> Exception on query:
> {code}
> Caches have distinct sets of data nodes [cache1=dummy_cache, 
> cache2=SQL_PUBLIC_PERSON]
>   > Apache.Ignite.Core.Common.JavaException : javax.cache.CacheException: 
> Caches have distinct sets of data nodes [cache1=dummy_cache, 
> cache2=SQL_PUBLIC_PERSON]
>   at 
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.stableDataNodes(GridReduceQueryExecutor.java:499)
>   at 
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.nodesForPartitions(GridReduceQueryExecutor.java:1486)
>   at 
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:591)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$8.iterator(IgniteH2Indexing.java:1283)
>   at 
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:95)
>   at 
> org.apache.ignite.internal.processors.platform.cache.query.PlatformAbstractQueryCursor.processInLongOutLong(PlatformAbstractQueryCursor.java:147)
>   at 
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inLongOutLong(PlatformTargetProxyImpl.java:55)
>at Apache.Ignite.Core.Impl.PlatformJniTarget.InLongOutLong(Int32 type, 
> Int64 val) in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core\Impl\PlatformJniTarget.cs:line
>  379
>at 
> Apache.Ignite.Core.Impl.Cache.Query.PlatformQueryQursorBase`1.InitIterator() 
> in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core\Impl\Cache\Query\PlatformQueryQursorBase.cs:line
>  74
>at Apache.Ignite.Core.Impl.Cache.Query.QueryCursorBase`1.GetEnumerator() 
> in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core\Impl\Cache\Query\QueryCursorBase.cs:line
>  125
>at Apache.Ignite.Examples.Sql.SqlDdlExample.Main() in 
> C:\w\incubator-ignite\modules\platforms\dotnet\examples\Apache.Ignite.Examples\Sql\SqlDdlExample.cs:line
>  95
>at Apache.Ignite.Core.Tests.Examples.Example.Run() in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Examples\Example.cs:line
>  52
>at Apache.Ignite.Core.Tests.Examples.ExamplesTest.TestRemoteNodes(Example 
> example, Boolean clientMode) in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Examples\ExamplesTest.cs:line
>  131
>at Apache.Ignite.Core.Tests.Examples.ExamplesTest.TestRemoteNodes(Example 
> example) in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Examples\ExamplesTest.cs:line
>  99
> {code}



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

[jira] [Updated] (IGNITE-7464) Add property to configure time between node connection attempts

[Stanislav Lukyanov (JIRA)]

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

Stanislav Lukyanov updated IGNITE-7464:
---
Description: 
Currently when a node attempts to join the cluster, the connection algorithm 
will be repeated until successful or timed out. The time between the attempts 
is hardcoded - 2 seconds.
It might be useful to adjust that time via a property (say, in SPI config) 
based on the network quality, application constraints, etc.

  was:It is 


> Add property to configure time between node connection attempts
> ---
>
> Key: IGNITE-7464
> URL: https://issues.apache.org/jira/browse/IGNITE-7464
> Project: Ignite
>  Issue Type: Bug
>Reporter: Stanislav Lukyanov
>Priority: Major
>
> Currently when a node attempts to join the cluster, the connection algorithm 
> will be repeated until successful or timed out. The time between the attempts 
> is hardcoded - 2 seconds.
> It might be useful to adjust that time via a property (say, in SPI config) 
> based on the network quality, application constraints, etc.



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

[jira] [Updated] (IGNITE-7464) Add property to configure time between node connection attempts

[Stanislav Lukyanov (JIRA)]

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

Stanislav Lukyanov updated IGNITE-7464:
---
Environment: (was: Currently when a node attempts to join the cluster, 
the connection algorithm will be repeated until successful or timed out. The 
time between the attempts is hardcoded - 2 seconds.
It might be useful to adjust that time via a property (say, in SPI config) 
based on the network quality, application constraints, etc.)

> Add property to configure time between node connection attempts
> ---
>
> Key: IGNITE-7464
> URL: https://issues.apache.org/jira/browse/IGNITE-7464
> Project: Ignite
>  Issue Type: Bug
>Reporter: Stanislav Lukyanov
>Priority: Major
>
> It is 



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

[jira] [Updated] (IGNITE-7464) Add property to configure time between node connection attempts

[Stanislav Lukyanov (JIRA)]

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

Stanislav Lukyanov updated IGNITE-7464:
---
Description: It is 

> Add property to configure time between node connection attempts
> ---
>
> Key: IGNITE-7464
> URL: https://issues.apache.org/jira/browse/IGNITE-7464
> Project: Ignite
>  Issue Type: Bug
> Environment: Currently when a node attempts to join the cluster, the 
> connection algorithm will be repeated until successful or timed out. The time 
> between the attempts is hardcoded - 2 seconds.
> It might be useful to adjust that time via a property (say, in SPI config) 
> based on the network quality, application constraints, etc.
>Reporter: Stanislav Lukyanov
>Priority: Major
>
> It is 



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

[jira] [Resolved] (IGNITE-7465) .NET: SqlDdlExample fails with standalone node

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn resolved IGNITE-7465.

Resolution: Fixed

> .NET: SqlDdlExample fails with standalone node
> --
>
> Key: IGNITE-7465
> URL: https://issues.apache.org/jira/browse/IGNITE-7465
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
> Fix For: 2.4
>
>
> Exception on query:
> {code}
> Caches have distinct sets of data nodes [cache1=dummy_cache, 
> cache2=SQL_PUBLIC_PERSON]
>   > Apache.Ignite.Core.Common.JavaException : javax.cache.CacheException: 
> Caches have distinct sets of data nodes [cache1=dummy_cache, 
> cache2=SQL_PUBLIC_PERSON]
>   at 
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.stableDataNodes(GridReduceQueryExecutor.java:499)
>   at 
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.nodesForPartitions(GridReduceQueryExecutor.java:1486)
>   at 
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:591)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$8.iterator(IgniteH2Indexing.java:1283)
>   at 
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:95)
>   at 
> org.apache.ignite.internal.processors.platform.cache.query.PlatformAbstractQueryCursor.processInLongOutLong(PlatformAbstractQueryCursor.java:147)
>   at 
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inLongOutLong(PlatformTargetProxyImpl.java:55)
>at Apache.Ignite.Core.Impl.PlatformJniTarget.InLongOutLong(Int32 type, 
> Int64 val) in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core\Impl\PlatformJniTarget.cs:line
>  379
>at 
> Apache.Ignite.Core.Impl.Cache.Query.PlatformQueryQursorBase`1.InitIterator() 
> in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core\Impl\Cache\Query\PlatformQueryQursorBase.cs:line
>  74
>at Apache.Ignite.Core.Impl.Cache.Query.QueryCursorBase`1.GetEnumerator() 
> in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core\Impl\Cache\Query\QueryCursorBase.cs:line
>  125
>at Apache.Ignite.Examples.Sql.SqlDdlExample.Main() in 
> C:\w\incubator-ignite\modules\platforms\dotnet\examples\Apache.Ignite.Examples\Sql\SqlDdlExample.cs:line
>  95
>at Apache.Ignite.Core.Tests.Examples.Example.Run() in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Examples\Example.cs:line
>  52
>at Apache.Ignite.Core.Tests.Examples.ExamplesTest.TestRemoteNodes(Example 
> example, Boolean clientMode) in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Examples\ExamplesTest.cs:line
>  131
>at Apache.Ignite.Core.Tests.Examples.ExamplesTest.TestRemoteNodes(Example 
> example) in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Examples\ExamplesTest.cs:line
>  99
> {code}



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

[jira] [Commented] (IGNITE-7465) .NET: SqlDdlExample fails with standalone node

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-7465:


Filed IGNITE-7468.

> .NET: SqlDdlExample fails with standalone node
> --
>
> Key: IGNITE-7465
> URL: https://issues.apache.org/jira/browse/IGNITE-7465
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
> Fix For: 2.4
>
>
> Exception on query:
> {code}
> Caches have distinct sets of data nodes [cache1=dummy_cache, 
> cache2=SQL_PUBLIC_PERSON]
>   > Apache.Ignite.Core.Common.JavaException : javax.cache.CacheException: 
> Caches have distinct sets of data nodes [cache1=dummy_cache, 
> cache2=SQL_PUBLIC_PERSON]
>   at 
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.stableDataNodes(GridReduceQueryExecutor.java:499)
>   at 
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.nodesForPartitions(GridReduceQueryExecutor.java:1486)
>   at 
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:591)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$8.iterator(IgniteH2Indexing.java:1283)
>   at 
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:95)
>   at 
> org.apache.ignite.internal.processors.platform.cache.query.PlatformAbstractQueryCursor.processInLongOutLong(PlatformAbstractQueryCursor.java:147)
>   at 
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inLongOutLong(PlatformTargetProxyImpl.java:55)
>at Apache.Ignite.Core.Impl.PlatformJniTarget.InLongOutLong(Int32 type, 
> Int64 val) in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core\Impl\PlatformJniTarget.cs:line
>  379
>at 
> Apache.Ignite.Core.Impl.Cache.Query.PlatformQueryQursorBase`1.InitIterator() 
> in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core\Impl\Cache\Query\PlatformQueryQursorBase.cs:line
>  74
>at Apache.Ignite.Core.Impl.Cache.Query.QueryCursorBase`1.GetEnumerator() 
> in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core\Impl\Cache\Query\QueryCursorBase.cs:line
>  125
>at Apache.Ignite.Examples.Sql.SqlDdlExample.Main() in 
> C:\w\incubator-ignite\modules\platforms\dotnet\examples\Apache.Ignite.Examples\Sql\SqlDdlExample.cs:line
>  95
>at Apache.Ignite.Core.Tests.Examples.Example.Run() in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Examples\Example.cs:line
>  52
>at Apache.Ignite.Core.Tests.Examples.ExamplesTest.TestRemoteNodes(Example 
> example, Boolean clientMode) in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Examples\ExamplesTest.cs:line
>  131
>at Apache.Ignite.Core.Tests.Examples.ExamplesTest.TestRemoteNodes(Example 
> example) in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Examples\ExamplesTest.cs:line
>  99
> {code}



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

[jira] [Created] (IGNITE-7468) Irrelevant "Caches have distinct sets of data nodes" error

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-7468:
--

 Summary: Irrelevant "Caches have distinct sets of data nodes" error
 Key: IGNITE-7468
 URL: https://issues.apache.org/jira/browse/IGNITE-7468
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.4
Reporter: Pavel Tupitsyn
 Fix For: 2.5


The following error is possible when doing PUBLIC schema queries with joins 
through a "dummy" cache:

{code}
Apache.Ignite.Core.Cache.CacheException : Caches have distinct sets of data 
nodes [cache1=dummy_cache, cache2=SQL_PUBLIC_PERSON]
  > Apache.Ignite.Core.Common.JavaException : javax.cache.CacheException: 
Caches have distinct sets of data nodes [cache1=dummy_cache, 
cache2=SQL_PUBLIC_PERSON]
at 
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.stableDataNodes(GridReduceQueryExecutor.java:499)
at 
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.nodesForPartitions(GridReduceQueryExecutor.java:1486)
at 
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:591)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$8.iterator(IgniteH2Indexing.java:1286)
at 
org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:95)
at 
org.apache.ignite.internal.processors.platform.cache.query.PlatformAbstractQueryCursor.processInLongOutLong(PlatformAbstractQueryCursor.java:147)
at 
org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inLongOutLong(PlatformTargetProxyImpl.java:55)

   at Apache.Ignite.Core.Impl.PlatformJniTarget.InLongOutLong(Int32 type, Int64 
val) in 
c:\BuildAgent\work\bd85361428dcdb1\modules\platforms\dotnet\Apache.Ignite.Core\Impl\PlatformJniTarget.cs:line
 379
   at 
Apache.Ignite.Core.Impl.Cache.Query.PlatformQueryQursorBase`1.InitIterator() in 
c:\BuildAgent\work\bd85361428dcdb1\modules\platforms\dotnet\Apache.Ignite.Core\Impl\Cache\Query\PlatformQueryQursorBase.cs:line
 74
   at Apache.Ignite.Core.Impl.Cache.Query.QueryCursorBase`1.GetEnumerator() in 
c:\BuildAgent\work\bd85361428dcdb1\modules\platforms\dotnet\Apache.Ignite.Core\Impl\Cache\Query\QueryCursorBase.cs:line
 125
   at Apache.Ignite.Examples.Sql.SqlDdlExample.Main() in 
c:\BuildAgent\work\bd85361428dcdb1\modules\platforms\dotnet\examples\Apache.Ignite.Examples\Sql\SqlDdlExample.cs:line
 95
   at Apache.Ignite.Core.Tests.Examples.Example.Run() in 
c:\BuildAgent\work\bd85361428dcdb1\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Examples\Example.cs:line
 52
   at Apache.Ignite.Core.Tests.Examples.ExamplesTest.TestRemoteNodes(Example 
example, Boolean clientMode) in 
c:\BuildAgent\work\bd85361428dcdb1\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Examples\ExamplesTest.cs:line
 131
   at Apache.Ignite.Core.Tests.Examples.ExamplesTest.TestRemoteNodes(Example 
example) in 
c:\BuildAgent\work\bd85361428dcdb1\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Examples\ExamplesTest.cs:line
 99
--JavaException
   at Apache.Ignite.Core.Impl.Unmanaged.Jni.Env.ExceptionCheck() in 
c:\BuildAgent\work\bd85361428dcdb1\modules\platforms\dotnet\Apache.Ignite.Core\Impl\Unmanaged\Jni\Env.cs:line
 490
   at Apache.Ignite.Core.Impl.Unmanaged.Jni.Env.CallLongMethod(GlobalRef obj, 
IntPtr methodId, Int64* argsPtr) in 
c:\BuildAgent\work\bd85361428dcdb1\modules\platforms\dotnet\Apache.Ignite.Core\Impl\Unmanaged\Jni\Env.cs:line
 203
   at 
Apache.Ignite.Core.Impl.Unmanaged.UnmanagedUtils.TargetInLongOutLong(GlobalRef 
target, Int32 opType, Int64 memPtr) in 
c:\BuildAgent\work\bd85361428dcdb1\modules\platforms\dotnet\Apache.Ignite.Core\Impl\Unmanaged\UnmanagedUtils.cs:line
 83
   at Apache.Ignite.Core.Impl.PlatformJniTarget.InLongOutLong(Int32 type, Int64 
val) in 
c:\BuildAgent\work\bd85361428dcdb1\modules\platforms\dotnet\Apache.Ignite.Core\Impl\PlatformJniTarget.cs:line
 375
{code}

* This reproduces in .NET {{SqlDdlExample}}. It is the same as Java example, 
but in Java it does not reproduce.
* Adding sleep(3000) before the query fixes the issue.
* Making dummy cache {{replicated}} fixes the issue

See IGNITE-7465.



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

[jira] [Updated] (IGNITE-7467) Verify partition update counters and sizes on partition map exchange

[Pavel Kovalenko (JIRA)]

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

Pavel Kovalenko updated IGNITE-7467:

Description: 
In Ignite we heavily rely on an invariant that under no load owning partitions 
will have equal sizes and, more importantly, equal partition counters. This 
invariant becomes even more important when persistence is enabled.

However, due to a possible bug in the code, this invariant can be violated 
which in a long run may lead to an undetected data loss. We need to take best 
effort to detect such a situation as soon as possible.

Currently, we already send partition update counters during partition map 
exchange. We can also send partition sizes and verify that corresponding 
partitions in OWNING state have equal partition update counters and sizes.

If a divergence detected, we can:
1) Always print out an error message to the log
2) Move the corresponding caches to the read-only state to prevent further 
corruption or operating on invalid data

Also, we can introduce a ./control.sh command which will trigger an empty 
exchange to verify the partition states.

> Verify partition update counters and sizes on partition map exchange
> 
>
> Key: IGNITE-7467
> URL: https://issues.apache.org/jira/browse/IGNITE-7467
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 2.1
> Environment: In Ignite we heavily rely on an invariant that under no 
> load owning partitions will have equal sizes and, more importantly, equal 
> partition counters. This invariant becomes even more important when 
> persistence is enabled.
> However, due to a possible bug in the code, this invariant can be violated 
> which in a long run may lead to an undetected data loss. We need to take best 
> effort to detect such a situation as soon as possible.
> Currently, we already send partition update counters during partition map 
> exchange. We can also send partition sizes and verify that corresponding 
> partitions in OWNING state have equal partition update counters and sizes.
> If a divergence detected, we can:
> 1) Always print out an error message to the log
> 2) Move the corresponding caches to the read-only state to prevent further 
> corruption or operating on invalid data
> Also, we can introduce a ./control.sh command which will trigger an empty 
> exchange to verify the partition states.
>Reporter: Alexey Goncharuk
>Assignee: Pavel Kovalenko
>Priority: Major
>
> In Ignite we heavily rely on an invariant that under no load owning 
> partitions will have equal sizes and, more importantly, equal partition 
> counters. This invariant becomes even more important when persistence is 
> enabled.
> However, due to a possible bug in the code, this invariant can be violated 
> which in a long run may lead to an undetected data loss. We need to take best 
> effort to detect such a situation as soon as possible.
> Currently, we already send partition update counters during partition map 
> exchange. We can also send partition sizes and verify that corresponding 
> partitions in OWNING state have equal partition update counters and sizes.
> If a divergence detected, we can:
> 1) Always print out an error message to the log
> 2) Move the corresponding caches to the read-only state to prevent further 
> corruption or operating on invalid data
> Also, we can introduce a ./control.sh command which will trigger an empty 
> exchange to verify the partition states.



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

[jira] [Updated] (IGNITE-7467) Verify partition update counters and sizes on partition map exchange

[Pavel Kovalenko (JIRA)]

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

Pavel Kovalenko updated IGNITE-7467:

Environment: (was: In Ignite we heavily rely on an invariant that under 
no load owning partitions will have equal sizes and, more importantly, equal 
partition counters. This invariant becomes even more important when persistence 
is enabled.

However, due to a possible bug in the code, this invariant can be violated 
which in a long run may lead to an undetected data loss. We need to take best 
effort to detect such a situation as soon as possible.

Currently, we already send partition update counters during partition map 
exchange. We can also send partition sizes and verify that corresponding 
partitions in OWNING state have equal partition update counters and sizes.

If a divergence detected, we can:
1) Always print out an error message to the log
2) Move the corresponding caches to the read-only state to prevent further 
corruption or operating on invalid data

Also, we can introduce a ./control.sh command which will trigger an empty 
exchange to verify the partition states.)

> Verify partition update counters and sizes on partition map exchange
> 
>
> Key: IGNITE-7467
> URL: https://issues.apache.org/jira/browse/IGNITE-7467
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Assignee: Pavel Kovalenko
>Priority: Major
>
> In Ignite we heavily rely on an invariant that under no load owning 
> partitions will have equal sizes and, more importantly, equal partition 
> counters. This invariant becomes even more important when persistence is 
> enabled.
> However, due to a possible bug in the code, this invariant can be violated 
> which in a long run may lead to an undetected data loss. We need to take best 
> effort to detect such a situation as soon as possible.
> Currently, we already send partition update counters during partition map 
> exchange. We can also send partition sizes and verify that corresponding 
> partitions in OWNING state have equal partition update counters and sizes.
> If a divergence detected, we can:
> 1) Always print out an error message to the log
> 2) Move the corresponding caches to the read-only state to prevent further 
> corruption or operating on invalid data
> Also, we can introduce a ./control.sh command which will trigger an empty 
> exchange to verify the partition states.



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

[jira] [Assigned] (IGNITE-7467) Verify partition update counters and sizes on partition map exchange

[Pavel Kovalenko (JIRA)]

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

Pavel Kovalenko reassigned IGNITE-7467:
---

Assignee: Pavel Kovalenko

> Verify partition update counters and sizes on partition map exchange
> 
>
> Key: IGNITE-7467
> URL: https://issues.apache.org/jira/browse/IGNITE-7467
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 2.1
> Environment: In Ignite we heavily rely on an invariant that under no 
> load owning partitions will have equal sizes and, more importantly, equal 
> partition counters. This invariant becomes even more important when 
> persistence is enabled.
> However, due to a possible bug in the code, this invariant can be violated 
> which in a long run may lead to an undetected data loss. We need to take best 
> effort to detect such a situation as soon as possible.
> Currently, we already send partition update counters during partition map 
> exchange. We can also send partition sizes and verify that corresponding 
> partitions in OWNING state have equal partition update counters and sizes.
> If a divergence detected, we can:
> 1) Always print out an error message to the log
> 2) Move the corresponding caches to the read-only state to prevent further 
> corruption or operating on invalid data
> Also, we can introduce a ./control.sh command which will trigger an empty 
> exchange to verify the partition states.
>Reporter: Alexey Goncharuk
>Assignee: Pavel Kovalenko
>Priority: Major
>




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

[jira] [Created] (IGNITE-7467) Verify partition update counters and sizes on partition map exchange

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-7467:


 Summary: Verify partition update counters and sizes on partition 
map exchange
 Key: IGNITE-7467
 URL: https://issues.apache.org/jira/browse/IGNITE-7467
 Project: Ignite
  Issue Type: Improvement
  Components: persistence
Affects Versions: 2.1
 Environment: In Ignite we heavily rely on an invariant that under no 
load owning partitions will have equal sizes and, more importantly, equal 
partition counters. This invariant becomes even more important when persistence 
is enabled.

However, due to a possible bug in the code, this invariant can be violated 
which in a long run may lead to an undetected data loss. We need to take best 
effort to detect such a situation as soon as possible.

Currently, we already send partition update counters during partition map 
exchange. We can also send partition sizes and verify that corresponding 
partitions in OWNING state have equal partition update counters and sizes.

If a divergence detected, we can:
1) Always print out an error message to the log
2) Move the corresponding caches to the read-only state to prevent further 
corruption or operating on invalid data

Also, we can introduce a ./control.sh command which will trigger an empty 
exchange to verify the partition states.
Reporter: Alexey Goncharuk






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

[jira] [Commented] (IGNITE-7465) .NET: SqlDdlExample fails with standalone node

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-7465:


Changed dummy cache to {{Replicated}} for now.
Merged to master: {{3dc1fcdaf1257a2a63c27dcb0e18d32495734cd3}}.

> .NET: SqlDdlExample fails with standalone node
> --
>
> Key: IGNITE-7465
> URL: https://issues.apache.org/jira/browse/IGNITE-7465
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
> Fix For: 2.4
>
>
> Exception on query:
> {code}
> Caches have distinct sets of data nodes [cache1=dummy_cache, 
> cache2=SQL_PUBLIC_PERSON]
>   > Apache.Ignite.Core.Common.JavaException : javax.cache.CacheException: 
> Caches have distinct sets of data nodes [cache1=dummy_cache, 
> cache2=SQL_PUBLIC_PERSON]
>   at 
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.stableDataNodes(GridReduceQueryExecutor.java:499)
>   at 
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.nodesForPartitions(GridReduceQueryExecutor.java:1486)
>   at 
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:591)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$8.iterator(IgniteH2Indexing.java:1283)
>   at 
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:95)
>   at 
> org.apache.ignite.internal.processors.platform.cache.query.PlatformAbstractQueryCursor.processInLongOutLong(PlatformAbstractQueryCursor.java:147)
>   at 
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inLongOutLong(PlatformTargetProxyImpl.java:55)
>at Apache.Ignite.Core.Impl.PlatformJniTarget.InLongOutLong(Int32 type, 
> Int64 val) in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core\Impl\PlatformJniTarget.cs:line
>  379
>at 
> Apache.Ignite.Core.Impl.Cache.Query.PlatformQueryQursorBase`1.InitIterator() 
> in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core\Impl\Cache\Query\PlatformQueryQursorBase.cs:line
>  74
>at Apache.Ignite.Core.Impl.Cache.Query.QueryCursorBase`1.GetEnumerator() 
> in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core\Impl\Cache\Query\QueryCursorBase.cs:line
>  125
>at Apache.Ignite.Examples.Sql.SqlDdlExample.Main() in 
> C:\w\incubator-ignite\modules\platforms\dotnet\examples\Apache.Ignite.Examples\Sql\SqlDdlExample.cs:line
>  95
>at Apache.Ignite.Core.Tests.Examples.Example.Run() in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Examples\Example.cs:line
>  52
>at Apache.Ignite.Core.Tests.Examples.ExamplesTest.TestRemoteNodes(Example 
> example, Boolean clientMode) in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Examples\ExamplesTest.cs:line
>  131
>at Apache.Ignite.Core.Tests.Examples.ExamplesTest.TestRemoteNodes(Example 
> example) in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Examples\ExamplesTest.cs:line
>  99
> {code}



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

[jira] [Updated] (IGNITE-7465) .NET: SqlDdlExample fails with standalone node

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-7465:
---
Summary: .NET: SqlDdlExample fails with standalone node  (was: .NET: 
SqlDllExample fails with standalone nodв)

> .NET: SqlDdlExample fails with standalone node
> --
>
> Key: IGNITE-7465
> URL: https://issues.apache.org/jira/browse/IGNITE-7465
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
> Fix For: 2.4
>
>
> Exception on query:
> {code}
> Caches have distinct sets of data nodes [cache1=dummy_cache, 
> cache2=SQL_PUBLIC_PERSON]
>   > Apache.Ignite.Core.Common.JavaException : javax.cache.CacheException: 
> Caches have distinct sets of data nodes [cache1=dummy_cache, 
> cache2=SQL_PUBLIC_PERSON]
>   at 
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.stableDataNodes(GridReduceQueryExecutor.java:499)
>   at 
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.nodesForPartitions(GridReduceQueryExecutor.java:1486)
>   at 
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:591)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$8.iterator(IgniteH2Indexing.java:1283)
>   at 
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:95)
>   at 
> org.apache.ignite.internal.processors.platform.cache.query.PlatformAbstractQueryCursor.processInLongOutLong(PlatformAbstractQueryCursor.java:147)
>   at 
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inLongOutLong(PlatformTargetProxyImpl.java:55)
>at Apache.Ignite.Core.Impl.PlatformJniTarget.InLongOutLong(Int32 type, 
> Int64 val) in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core\Impl\PlatformJniTarget.cs:line
>  379
>at 
> Apache.Ignite.Core.Impl.Cache.Query.PlatformQueryQursorBase`1.InitIterator() 
> in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core\Impl\Cache\Query\PlatformQueryQursorBase.cs:line
>  74
>at Apache.Ignite.Core.Impl.Cache.Query.QueryCursorBase`1.GetEnumerator() 
> in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core\Impl\Cache\Query\QueryCursorBase.cs:line
>  125
>at Apache.Ignite.Examples.Sql.SqlDdlExample.Main() in 
> C:\w\incubator-ignite\modules\platforms\dotnet\examples\Apache.Ignite.Examples\Sql\SqlDdlExample.cs:line
>  95
>at Apache.Ignite.Core.Tests.Examples.Example.Run() in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Examples\Example.cs:line
>  52
>at Apache.Ignite.Core.Tests.Examples.ExamplesTest.TestRemoteNodes(Example 
> example, Boolean clientMode) in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Examples\ExamplesTest.cs:line
>  131
>at Apache.Ignite.Core.Tests.Examples.ExamplesTest.TestRemoteNodes(Example 
> example) in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Examples\ExamplesTest.cs:line
>  99
> {code}



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

[jira] [Updated] (IGNITE-7465) .NET: SqlDllExample fails with standalone nodв

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-7465:
---
Summary: .NET: SqlDllExample fails with standalone nodв  (was: .NET: 
SqlDllExample fails with standalone node)

> .NET: SqlDllExample fails with standalone nodв
> --
>
> Key: IGNITE-7465
> URL: https://issues.apache.org/jira/browse/IGNITE-7465
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
> Fix For: 2.4
>
>
> Exception on query:
> {code}
> Caches have distinct sets of data nodes [cache1=dummy_cache, 
> cache2=SQL_PUBLIC_PERSON]
>   > Apache.Ignite.Core.Common.JavaException : javax.cache.CacheException: 
> Caches have distinct sets of data nodes [cache1=dummy_cache, 
> cache2=SQL_PUBLIC_PERSON]
>   at 
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.stableDataNodes(GridReduceQueryExecutor.java:499)
>   at 
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.nodesForPartitions(GridReduceQueryExecutor.java:1486)
>   at 
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:591)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$8.iterator(IgniteH2Indexing.java:1283)
>   at 
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:95)
>   at 
> org.apache.ignite.internal.processors.platform.cache.query.PlatformAbstractQueryCursor.processInLongOutLong(PlatformAbstractQueryCursor.java:147)
>   at 
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inLongOutLong(PlatformTargetProxyImpl.java:55)
>at Apache.Ignite.Core.Impl.PlatformJniTarget.InLongOutLong(Int32 type, 
> Int64 val) in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core\Impl\PlatformJniTarget.cs:line
>  379
>at 
> Apache.Ignite.Core.Impl.Cache.Query.PlatformQueryQursorBase`1.InitIterator() 
> in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core\Impl\Cache\Query\PlatformQueryQursorBase.cs:line
>  74
>at Apache.Ignite.Core.Impl.Cache.Query.QueryCursorBase`1.GetEnumerator() 
> in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core\Impl\Cache\Query\QueryCursorBase.cs:line
>  125
>at Apache.Ignite.Examples.Sql.SqlDdlExample.Main() in 
> C:\w\incubator-ignite\modules\platforms\dotnet\examples\Apache.Ignite.Examples\Sql\SqlDdlExample.cs:line
>  95
>at Apache.Ignite.Core.Tests.Examples.Example.Run() in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Examples\Example.cs:line
>  52
>at Apache.Ignite.Core.Tests.Examples.ExamplesTest.TestRemoteNodes(Example 
> example, Boolean clientMode) in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Examples\ExamplesTest.cs:line
>  131
>at Apache.Ignite.Core.Tests.Examples.ExamplesTest.TestRemoteNodes(Example 
> example) in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Examples\ExamplesTest.cs:line
>  99
> {code}



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

[jira] [Comment Edited] (IGNITE-7465) .NET: SqlDllExample fails with standalone node

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn edited comment on IGNITE-7465 at 1/18/18 12:28 PM:
--

* .NET {{TestRemoteNodes}} runs the example twice, and it fails only on the 
second run.
* Java {{SqlDdlExample}} is exactly the same, but the issue does not occur 
there (even if we run it multiple times with the same standalone nodes).
* Adding sleep(3000) before the problematic query fixes the issue.


was (Author: ptupitsyn):
* .NET {{TestRemoteNodes}} runs the example twice, and it fails only on the 
second run.
* Java {{SqlDdlExample}} is exactly the same, but the issue does not occur 
there (even if we run it multiple times with the same standalone nodes).

> .NET: SqlDllExample fails with standalone node
> --
>
> Key: IGNITE-7465
> URL: https://issues.apache.org/jira/browse/IGNITE-7465
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
> Fix For: 2.4
>
>
> Exception on query:
> {code}
> Caches have distinct sets of data nodes [cache1=dummy_cache, 
> cache2=SQL_PUBLIC_PERSON]
>   > Apache.Ignite.Core.Common.JavaException : javax.cache.CacheException: 
> Caches have distinct sets of data nodes [cache1=dummy_cache, 
> cache2=SQL_PUBLIC_PERSON]
>   at 
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.stableDataNodes(GridReduceQueryExecutor.java:499)
>   at 
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.nodesForPartitions(GridReduceQueryExecutor.java:1486)
>   at 
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:591)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$8.iterator(IgniteH2Indexing.java:1283)
>   at 
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:95)
>   at 
> org.apache.ignite.internal.processors.platform.cache.query.PlatformAbstractQueryCursor.processInLongOutLong(PlatformAbstractQueryCursor.java:147)
>   at 
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inLongOutLong(PlatformTargetProxyImpl.java:55)
>at Apache.Ignite.Core.Impl.PlatformJniTarget.InLongOutLong(Int32 type, 
> Int64 val) in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core\Impl\PlatformJniTarget.cs:line
>  379
>at 
> Apache.Ignite.Core.Impl.Cache.Query.PlatformQueryQursorBase`1.InitIterator() 
> in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core\Impl\Cache\Query\PlatformQueryQursorBase.cs:line
>  74
>at Apache.Ignite.Core.Impl.Cache.Query.QueryCursorBase`1.GetEnumerator() 
> in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core\Impl\Cache\Query\QueryCursorBase.cs:line
>  125
>at Apache.Ignite.Examples.Sql.SqlDdlExample.Main() in 
> C:\w\incubator-ignite\modules\platforms\dotnet\examples\Apache.Ignite.Examples\Sql\SqlDdlExample.cs:line
>  95
>at Apache.Ignite.Core.Tests.Examples.Example.Run() in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Examples\Example.cs:line
>  52
>at Apache.Ignite.Core.Tests.Examples.ExamplesTest.TestRemoteNodes(Example 
> example, Boolean clientMode) in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Examples\ExamplesTest.cs:line
>  131
>at Apache.Ignite.Core.Tests.Examples.ExamplesTest.TestRemoteNodes(Example 
> example) in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Examples\ExamplesTest.cs:line
>  99
> {code}



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

[jira] [Commented] (IGNITE-7465) .NET: SqlDllExample fails with standalone node

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-7465:


* .NET {{TestRemoteNodes}} runs the example twice, and it fails only on the 
second run.
* Java {{SqlDdlExample}} is exactly the same, but the issue does not occur 
there (even if we run it multiple times with the same standalone nodes).

> .NET: SqlDllExample fails with standalone node
> --
>
> Key: IGNITE-7465
> URL: https://issues.apache.org/jira/browse/IGNITE-7465
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
> Fix For: 2.4
>
>
> Exception on query:
> {code}
> Caches have distinct sets of data nodes [cache1=dummy_cache, 
> cache2=SQL_PUBLIC_PERSON]
>   > Apache.Ignite.Core.Common.JavaException : javax.cache.CacheException: 
> Caches have distinct sets of data nodes [cache1=dummy_cache, 
> cache2=SQL_PUBLIC_PERSON]
>   at 
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.stableDataNodes(GridReduceQueryExecutor.java:499)
>   at 
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.nodesForPartitions(GridReduceQueryExecutor.java:1486)
>   at 
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:591)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$8.iterator(IgniteH2Indexing.java:1283)
>   at 
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:95)
>   at 
> org.apache.ignite.internal.processors.platform.cache.query.PlatformAbstractQueryCursor.processInLongOutLong(PlatformAbstractQueryCursor.java:147)
>   at 
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inLongOutLong(PlatformTargetProxyImpl.java:55)
>at Apache.Ignite.Core.Impl.PlatformJniTarget.InLongOutLong(Int32 type, 
> Int64 val) in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core\Impl\PlatformJniTarget.cs:line
>  379
>at 
> Apache.Ignite.Core.Impl.Cache.Query.PlatformQueryQursorBase`1.InitIterator() 
> in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core\Impl\Cache\Query\PlatformQueryQursorBase.cs:line
>  74
>at Apache.Ignite.Core.Impl.Cache.Query.QueryCursorBase`1.GetEnumerator() 
> in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core\Impl\Cache\Query\QueryCursorBase.cs:line
>  125
>at Apache.Ignite.Examples.Sql.SqlDdlExample.Main() in 
> C:\w\incubator-ignite\modules\platforms\dotnet\examples\Apache.Ignite.Examples\Sql\SqlDdlExample.cs:line
>  95
>at Apache.Ignite.Core.Tests.Examples.Example.Run() in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Examples\Example.cs:line
>  52
>at Apache.Ignite.Core.Tests.Examples.ExamplesTest.TestRemoteNodes(Example 
> example, Boolean clientMode) in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Examples\ExamplesTest.cs:line
>  131
>at Apache.Ignite.Core.Tests.Examples.ExamplesTest.TestRemoteNodes(Example 
> example) in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Examples\ExamplesTest.cs:line
>  99
> {code}



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

[jira] [Commented] (IGNITE-7465) .NET: SqlDllExample fails with standalone node

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-7465:


Making dummy cache {code}replicated{code} (same as SQL cache) solves the 
problem.
But dummy cache does not participate in the query at all, looks like a bug.

> .NET: SqlDllExample fails with standalone node
> --
>
> Key: IGNITE-7465
> URL: https://issues.apache.org/jira/browse/IGNITE-7465
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
> Fix For: 2.4
>
>
> Exception on query:
> {code}
> Caches have distinct sets of data nodes [cache1=dummy_cache, 
> cache2=SQL_PUBLIC_PERSON]
>   > Apache.Ignite.Core.Common.JavaException : javax.cache.CacheException: 
> Caches have distinct sets of data nodes [cache1=dummy_cache, 
> cache2=SQL_PUBLIC_PERSON]
>   at 
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.stableDataNodes(GridReduceQueryExecutor.java:499)
>   at 
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.nodesForPartitions(GridReduceQueryExecutor.java:1486)
>   at 
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:591)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$8.iterator(IgniteH2Indexing.java:1283)
>   at 
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:95)
>   at 
> org.apache.ignite.internal.processors.platform.cache.query.PlatformAbstractQueryCursor.processInLongOutLong(PlatformAbstractQueryCursor.java:147)
>   at 
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inLongOutLong(PlatformTargetProxyImpl.java:55)
>at Apache.Ignite.Core.Impl.PlatformJniTarget.InLongOutLong(Int32 type, 
> Int64 val) in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core\Impl\PlatformJniTarget.cs:line
>  379
>at 
> Apache.Ignite.Core.Impl.Cache.Query.PlatformQueryQursorBase`1.InitIterator() 
> in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core\Impl\Cache\Query\PlatformQueryQursorBase.cs:line
>  74
>at Apache.Ignite.Core.Impl.Cache.Query.QueryCursorBase`1.GetEnumerator() 
> in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core\Impl\Cache\Query\QueryCursorBase.cs:line
>  125
>at Apache.Ignite.Examples.Sql.SqlDdlExample.Main() in 
> C:\w\incubator-ignite\modules\platforms\dotnet\examples\Apache.Ignite.Examples\Sql\SqlDdlExample.cs:line
>  95
>at Apache.Ignite.Core.Tests.Examples.Example.Run() in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Examples\Example.cs:line
>  52
>at Apache.Ignite.Core.Tests.Examples.ExamplesTest.TestRemoteNodes(Example 
> example, Boolean clientMode) in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Examples\ExamplesTest.cs:line
>  131
>at Apache.Ignite.Core.Tests.Examples.ExamplesTest.TestRemoteNodes(Example 
> example) in 
> C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Examples\ExamplesTest.cs:line
>  99
> {code}



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

[jira] [Comment Edited] (IGNITE-7456) Fix wrong batch logic in distributed MLP training.

[Oleg Ignatenko (JIRA)]

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

Oleg Ignatenko edited comment on IGNITE-7456 at 1/18/18 12:06 PM:
--

As of now it looks good to go to master and to 2.4 branch: code changes are OK, 
unit tests pass and examples run correctly. One thing worth doing prior to 
merge is to get rid of double-whitespace in the text of the message in 
MLPGroupTrainerExample: {{">>> Distributed  multilayer perceptron example 
started."}} (it's between words Distributed and multilayer).

Another interesting thing I noticed when I tried MLP group example with number 
of steps larger that set in code (100 instead of 20): there were confusing 
exceptions in example log. Note I only managed to get it on my machine; when 
Artem tried it on his machine example run without exceptions. Because of that I 
attached my execution log here: 
[^IGNITE-7456.NPE.MLPGroupTrainerExample.tweaked.log]. This issue is out of 
scope of this ticket since it was with settings that aren't there but after 
this change is merged to masted we better open a separate ticket to investigate 
what could go wrong in my trial change.

*Update* as of now both issues mentioned above have been fixed.


was (Author: oignatenko):
As of now it looks good to go to master and to 2.4 branch: code changes are OK, 
unit tests pass and examples run correctly. One thing worth doing prior to 
merge is to get rid of double-whitespace in the text of the message in 
MLPGroupTrainerExample: {{">>> Distributed  multilayer perceptron example 
started."}} (it's between words Distributed and multilayer).

 

Another interesting thing I noticed when I tried MLP group example with number 
of steps larger that set in code (100 instead of 20): there were confusing 
exceptions in example log. Note I only managed to get it on my machine; when 
Artem tried it on his machine example run without exceptions. Because of that I 
attached my execution log here: 
[^IGNITE-7456.NPE.MLPGroupTrainerExample.tweaked.log]. This issue is out of 
scope of this ticket since it was with settings that aren't there but after 
this change is merged to masted we better open a separate ticket to investigate 
what could go wrong in my trial change.

> Fix wrong batch logic in distributed MLP training.
> --
>
> Key: IGNITE-7456
> URL: https://issues.apache.org/jira/browse/IGNITE-7456
> Project: Ignite
>  Issue Type: Bug
>  Components: ml
>Affects Versions: 2.4
>Reporter: Artem Malykh
>Assignee: Artem Malykh
>Priority: Major
> Fix For: 2.4
>
> Attachments: IGNITE-7456.NPE.MLPGroupTrainerExample.tweaked.log
>
>
> Batch for training is created outside of training loop, therefore in each 
> local step we work with the same batch.



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

[jira] [Resolved] (IGNITE-7448) destroy*() API for datastructures

[Alexander Belyak (JIRA)]

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

Alexander Belyak resolved IGNITE-7448.
--
Resolution: Invalid

Didn't find .close() methods.

> destroy*() API for datastructures
> -
>
> Key: IGNITE-7448
> URL: https://issues.apache.org/jira/browse/IGNITE-7448
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6, 1.7, 1.8, 1.9, 2.0, 2.1, 2.2, 2.3
> Environment: In public API we have ignite.destroyCache(String) and 
> ingite.destroyCaches(Collection) methods to destroy cache by name(s) 
> and ignite.services().cancel(String) to undeploy services, but no method for 
> data structures like:
>  * destroyAtomicSequence()
>  * destroyAtomicLong()
>  * destroyAtomicReference()
>  * destroyAtomicStamped()
>  * destroyQueue()
>  * destroySet()
>  * destroySemaphore()
>  * destroyCountDownLatch()
>Reporter: Alexander Belyak
>Priority: Major
>




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

[jira] [Assigned] (IGNITE-6832) handle IO errors while checkpointing

[Pavel Kovalenko (JIRA)]

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

Pavel Kovalenko reassigned IGNITE-6832:
---

Assignee: Alexey Goncharuk  (was: Pavel Kovalenko)

Ready to review

TeamCity results: 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8_IgniteTests24Java8=pull%2F3394%2Fhead


> handle IO errors while checkpointing
> 
>
> Key: IGNITE-6832
> URL: https://issues.apache.org/jira/browse/IGNITE-6832
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Alexander Belyak
>Assignee: Alexey Goncharuk
>Priority: Major
>
> If we get some IO error (like "No spece left on device") during checkpointing 
> (GridCacheDatabaseSharedManager$WriteCheckpointPages:2509) node didn't stop 
> as when get same error while writting WAL log and clients will get some "Long 
> running cache futures". We must stop node in this case! Better - add some 
> internal healthcheck and stop node anyway if  it won't pass for few times (do 
> it with different issue).



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

[jira] [Updated] (IGNITE-7466) Document Direct IO optional plugin: purpose, setup, effect to persitent data store

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-7466:
---
Summary: Document Direct IO optional plugin: purpose, setup, effect to 
persitent data store  (was: Document Direct IO optional plugin: purpose, setup,)

> Document Direct IO optional plugin: purpose, setup, effect to persitent data 
> store
> --
>
> Key: IGNITE-7466
> URL: https://issues.apache.org/jira/browse/IGNITE-7466
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, persistence
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Major
>
> Direct IO was supported in Apache Ignite under task 
> https://issues.apache.org/jira/browse/IGNITE-6341
> Small description can be found in original ticket 
> https://issues.apache.org/jira/browse/IGNITE-6341?focusedCommentId=16330305=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16330305
> It is necessary to document this feature at least in wiki, at most at 
> readme.io
>  



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

[jira] [Commented] (IGNITE-6341) Use direct IO or libaio for file page store where applicable

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-6341:


Documentation issue https://issues.apache.org/jira/browse/IGNITE-7466

> Use direct IO or libaio for file page store where applicable
> 
>
> Key: IGNITE-6341
> URL: https://issues.apache.org/jira/browse/IGNITE-6341
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Reporter: Andrey Gura
>Assignee: Dmitriy Pavlov
>Priority: Major
> Fix For: 2.4
>
>
> Need try to use direct IO or libaio for page store because once data buffer 
> is serialized, we can write it as disk pages (this will also make it easier 
> if we decide to open file as a block device).



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

[jira] [Created] (IGNITE-7466) Document Direct IO optional plugin: purpose, setup,

[Dmitriy Pavlov (JIRA)]

Dmitriy Pavlov created IGNITE-7466:
--

 Summary: Document Direct IO optional plugin: purpose, setup,
 Key: IGNITE-7466
 URL: https://issues.apache.org/jira/browse/IGNITE-7466
 Project: Ignite
  Issue Type: Task
  Components: documentation, persistence
Reporter: Dmitriy Pavlov
Assignee: Dmitriy Pavlov


Direct IO was supported in Apache Ignite under task 
https://issues.apache.org/jira/browse/IGNITE-6341

Small description can be found in original ticket 
https://issues.apache.org/jira/browse/IGNITE-6341?focusedCommentId=16330305=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16330305

It is necessary to document this feature at least in wiki, at most at readme.io

 



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

[jira] [Commented] (IGNITE-6341) Use direct IO or libaio for file page store where applicable

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6341:


Github user asfgit closed the pull request at:

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


> Use direct IO or libaio for file page store where applicable
> 
>
> Key: IGNITE-6341
> URL: https://issues.apache.org/jira/browse/IGNITE-6341
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Reporter: Andrey Gura
>Assignee: Dmitriy Pavlov
>Priority: Major
> Fix For: 2.4
>
>
> Need try to use direct IO or libaio for page store because once data buffer 
> is serialized, we can write it as disk pages (this will also make it easier 
> if we decide to open file as a block device).



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

[jira] [Created] (IGNITE-7465) .NET: SqlDllExample fails with standalone node

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-7465:
--

 Summary: .NET: SqlDllExample fails with standalone node
 Key: IGNITE-7465
 URL: https://issues.apache.org/jira/browse/IGNITE-7465
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Affects Versions: 2.4
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 2.4


Exception on query:

{code}
Caches have distinct sets of data nodes [cache1=dummy_cache, 
cache2=SQL_PUBLIC_PERSON]
  > Apache.Ignite.Core.Common.JavaException : javax.cache.CacheException: 
Caches have distinct sets of data nodes [cache1=dummy_cache, 
cache2=SQL_PUBLIC_PERSON]
at 
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.stableDataNodes(GridReduceQueryExecutor.java:499)
at 
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.nodesForPartitions(GridReduceQueryExecutor.java:1486)
at 
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:591)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$8.iterator(IgniteH2Indexing.java:1283)
at 
org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:95)
at 
org.apache.ignite.internal.processors.platform.cache.query.PlatformAbstractQueryCursor.processInLongOutLong(PlatformAbstractQueryCursor.java:147)
at 
org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inLongOutLong(PlatformTargetProxyImpl.java:55)


   at Apache.Ignite.Core.Impl.PlatformJniTarget.InLongOutLong(Int32 type, Int64 
val) in 
C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core\Impl\PlatformJniTarget.cs:line
 379
   at 
Apache.Ignite.Core.Impl.Cache.Query.PlatformQueryQursorBase`1.InitIterator() in 
C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core\Impl\Cache\Query\PlatformQueryQursorBase.cs:line
 74
   at Apache.Ignite.Core.Impl.Cache.Query.QueryCursorBase`1.GetEnumerator() in 
C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core\Impl\Cache\Query\QueryCursorBase.cs:line
 125
   at Apache.Ignite.Examples.Sql.SqlDdlExample.Main() in 
C:\w\incubator-ignite\modules\platforms\dotnet\examples\Apache.Ignite.Examples\Sql\SqlDdlExample.cs:line
 95
   at Apache.Ignite.Core.Tests.Examples.Example.Run() in 
C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Examples\Example.cs:line
 52
   at Apache.Ignite.Core.Tests.Examples.ExamplesTest.TestRemoteNodes(Example 
example, Boolean clientMode) in 
C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Examples\ExamplesTest.cs:line
 131
   at Apache.Ignite.Core.Tests.Examples.ExamplesTest.TestRemoteNodes(Example 
example) in 
C:\w\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Examples\ExamplesTest.cs:line
 99
{code}



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

[jira] [Commented] (IGNITE-7316) Make Linear SVM for binary classification

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7316:


GitHub user zaleslaw opened a pull request:

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

IGNITE-7316: Make Linear SVM for binary classification

1. Fixed bugs in LabeledDatasets
2. Added SVM Model
3. Added SVM Trainer based on SDCA algorithm
4. Added tests for distributed and local versions


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

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

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

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

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

This closes #3399


commit 7d22bcd33fcea3a7588c46368b5289d5b306db7f
Author: Zinoviev Alexey 
Date:   2017-12-07T11:01:43Z

Merge from master

commit 84cbd8b380772ce773790b18066c86b663b1af27
Author: Zinoviev Alexey 
Date:   2017-12-13T10:36:56Z

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

commit b58db6a44be3c625174c1d89c577240771d1bfb4
Author: Zinoviev Alexey 
Date:   2017-12-26T16:37:24Z

Merged from master

commit c050cf6e9ad052ca2d5d15b035da9536eab5ba80
Author: Zinoviev Alexey 
Date:   2017-12-26T19:06:24Z

IGNITE-7205: Added draft

commit 6506cf1d0e3bdf50125004494d075d81b863a0a2
Author: Zinoviev Alexey 
Date:   2017-12-27T08:06:30Z

IGNITE-7205: Fixed classes

commit 427743e0ad8ab1cbbc2a45d3e2b032a6b66c5632
Author: Zinoviev Alexey 
Date:   2017-12-27T14:19:10Z

IGNITE-7205: Refactored Labeled Dataset

commit 1f4792fe2a4cfddbee5390b4e79d74f1cf74585e
Author: Zinoviev Alexey 
Date:   2017-12-27T14:57:49Z

IGNITE-7205: Fixed serialization issue

commit de3996fabe7d77795517c07d43ec1a631494209a
Author: Zinoviev Alexey 
Date:   2017-12-27T17:20:24Z

IGNITE-7205: Added Labelling Machine for group prediction

commit 7ad09a115105ab31ef7caecf83b6466df9f102bb
Author: Yury Babak 
Date:   2017-12-28T11:49:10Z

IGNITE-7205: Dataset API

codestyle fixes

commit 26f878d13f16e07b8e0b939545e504700e581f6a
Author: zaleslaw 
Date:   2017-12-28T12:24:41Z

IGNITE-7205: Fixed externalization

commit 9e0d060f0a2d4b86c473a6e48817be8693ad0465
Author: zaleslaw 
Date:   2017-12-28T12:50:13Z

IGNITE-7205: Fixed bugs

commit 0acd8f82df090da5c5216bdb400d09fc77b25c79
Author: zaleslaw 
Date:   2017-12-28T16:47:32Z

Initial commit

commit f68785c2296ba414a89e4399c8fbece544cd18e2
Author: Zinoviev Alexey 
Date:   2018-01-10T13:59:30Z

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

commit 612d713283b1e96274b3ec73a71310bb72da9cab
Author: Zinoviev Alexey 
Date:   2018-01-10T14:35:20Z

Merge from master

commit 731dfc5c2c8b0f11fca68088661e62d53ae92ea4
Author: Zinoviev Alexey 
Date:   2018-01-10T20:51:31Z

Added naive implementation

commit ed459bf97d25a9ec4276f4303724f760cf34d67e
Author: zaleslaw 
Date:   2018-01-11T16:09:50Z

Worked version

commit 35e54a086b10cdcb6f1e86fe07dc3b3ae66058e2
Author: Zinoviev Alexey 
Date:   2018-01-12T16:25:44Z

Refactored code

commit a82ab9a2abebe49df3eaba71599bcb769afe3ecd
Author: Zinoviev Alexey 
Date:   2018-01-16T18:39:06Z

Refactored code

commit fa633750e24f76914c0632803facbb16513520de
Author: Zinoviev Alexey 
Date:   2018-01-16T18:53:00Z

Refactored code

commit 84e476ff4fc05347b2b58424218e136eec8190de
Author: Zinoviev Alexey 
Date:   2018-01-16T19:13:45Z

Fixed tests

commit 2618a04d7f95ef4be0b3951f4bc4b242de4d1940
Author: Zinoviev Alexey 
Date:   2018-01-17T12:10:03Z

Fixed style

commit 116b887cb5f8109418b1a22ffda50280654bd02b
Author: Zinoviev Alexey 
Date:   2018-01-18T09:20:57Z

Fixed style

commit 7be3c489c44c2305d96771d5a972f820e56af0e8
Author: Zinoviev Alexey 
Date:   2018-01-18T09:31:20Z

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

commit 3c79b70cbb62df733a8ca1374ebe36fb7c1a175c
Author: Zinoviev Alexey 
Date:   2018-01-18T09:32:20Z

Merge branch 'master' into ignite-7316

commit a2da58b2e7e8089ec36c6fe9f5c607496079f67e
Author: Zinoviev Alexey 
Date:   2018-01-18T10:26:42Z

Fixed bug in parsing from file

commit 072eb41b8e362b3b6c0f9b8de4ead719e02c3d92
Author: Zinoviev Alexey 
Date:   2018-01-18T10:31:47Z

Removed incorrect data




> Make Linear 

[jira] [Assigned] (IGNITE-7461) Web console: incorrect code generation

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-7461:


Resolution: Fixed
  Assignee: Pavel Konstantinov  (was: Alexey Kuznetsov)

Merged to master.

> Web console: incorrect code generation
> --
>
> Key: IGNITE-7461
> URL: https://issues.apache.org/jira/browse/IGNITE-7461
> Project: Ignite
>  Issue Type: Bug
> Environment: Error:(81, 23) java: cannot find symbol
>   symbol:   method setCheckpointPageBufferSize(long)
>   location: variable dataStorageCfg of type 
> org.apache.ignite.configuration.DataStorageConfiguration
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.4
>
>
> Do not forget to change generation of XML configuration



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

[jira] [Updated] (IGNITE-7316) Make Linear SVM for binary classification

[Aleksey Zinoviev (JIRA)]

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

Aleksey Zinoviev updated IGNITE-7316:
-
Description: (was: It should contain
# dataset for tests
# loss function
# binary classification metric (ROC AUC, for example)
# Common SVM model
# SVM Linear BInary Trainer)

> Make Linear SVM for binary classification
> -
>
> Key: IGNITE-7316
> URL: https://issues.apache.org/jira/browse/IGNITE-7316
> Project: Ignite
>  Issue Type: Sub-task
>  Components: ml
>Reporter: Aleksey Zinoviev
>Assignee: Aleksey Zinoviev
>Priority: Major
>




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

[jira] [Comment Edited] (IGNITE-6341) Use direct IO or libaio for file page store where applicable

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov edited comment on IGNITE-6341 at 1/18/18 9:50 AM:
-

Ignite Direct IO plugin will be added to optional lib automatically to 
Apache-ignite-fabric-2.x.x-bin\libs\optional\ignite-direct-io\direct-io-2.x.x.jar
 

To enable Direct IO it is sufficient to place lib to ignite classpath on Linux 
system.

When plugin is applied following messages will be produced
{noformat}
Configured plugins:
^-- Ignite Native I/O Plugin [Direct I/O]
^-- Copyright(C) Apache Software Foundation
{noformat}
 
Following message will be produced for successful setup:
{noformat}
Page size configuration for storage path 
[/data/teamcity/tmpfs/work/db/node00-3a1415b8-aa54-4a63-a40a-c75ad48dd6b8]: 
4096; Linux memory page size: 4096; Selected FS block size : 4096.
Selected FS block size : 4096
Direct IO is enabled for block IO operations on aligned memory structures. 
[block size = 4096, durable memory page size = 4096]
{noformat}
 
Following test suites were added for checking Direct IO functionality using 
existing PDS tests:
[IgnitePds1DirectIo|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgnitePds1DirectIo]
[IgnitePds2DirectIo|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgnitePds2DirectIo]

Runs may be triggered by 
[RunAllPds|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_RunAllPds]

Example of run of PR code:
[https://ci.ignite.apache.org/viewLog.html?buildId=1044741]

[~agoncharuk], could you please review and merge changes from PR 
[https://github.com/apache/ignite/pull/3226] ?


was (Author: dpavlov):
Ignite Direct IO plugin will be added to optional lib automatically to 
Apache-ignite-fabric-2.x.x-bin\libs\optional\ignite-direct-io\direct-io-2.x.x.jar
 

To enable Direct IO it is sufficient to place lib to ignite classpath on Linux 
system.

 

When plugin is applied following messages will be produced
{noformat}
Configured plugins:

^-- Ignite Native I/O Plugin [Direct I/O]

^-- Copyright(C) Apache Software Foundation{noformat}
 

 

Following message will be produced for successful setup:
{noformat}
Page size configuration for storage path 
[/data/teamcity/tmpfs/work/db/node00-3a1415b8-aa54-4a63-a40a-c75ad48dd6b8]: 
4096; Linux memory page size: 4096; Selected FS block size : 4096.

Selected FS block size : 4096

Direct IO is enabled for block IO operations on aligned memory structures. 
[block size = 4096, durable memory page size = 4096]{noformat}
 

 

 

Following test suites were added for checking Direct IO functionality using 
existing PDS tests:

[https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgnitePds1DirectIo]

[https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgnitePds2DirectIo]

 

Runs may be triggered by 
[https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_RunAllPds]

 

Example of run of PR code:

[https://ci.ignite.apache.org/viewLog.html?buildId=1044741]

 

[~agoncharuk], could you please review and merge changes from PR 
[https://github.com/apache/ignite/pull/3226] ?

> Use direct IO or libaio for file page store where applicable
> 
>
> Key: IGNITE-6341
> URL: https://issues.apache.org/jira/browse/IGNITE-6341
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Reporter: Andrey Gura
>Assignee: Dmitriy Pavlov
>Priority: Major
> Fix For: 2.4
>
>
> Need try to use direct IO or libaio for page store because once data buffer 
> is serialized, we can write it as disk pages (this will also make it easier 
> if we decide to open file as a block device).



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

[jira] [Commented] (IGNITE-6341) Use direct IO or libaio for file page store where applicable

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-6341:


Ignite Direct IO plugin will be added to optional lib automatically to 
Apache-ignite-fabric-2.x.x-bin\libs\optional\ignite-direct-io\direct-io-2.x.x.jar
 

To enable Direct IO it is sufficient to place lib to ignite classpath on Linux 
system.

 

When plugin is applied following messages will be produced
{noformat}
Configured plugins:

^-- Ignite Native I/O Plugin [Direct I/O]

^-- Copyright(C) Apache Software Foundation{noformat}
 

 

Following message will be produced for successful setup:
{noformat}
Page size configuration for storage path 
[/data/teamcity/tmpfs/work/db/node00-3a1415b8-aa54-4a63-a40a-c75ad48dd6b8]: 
4096; Linux memory page size: 4096; Selected FS block size : 4096.

Selected FS block size : 4096

Direct IO is enabled for block IO operations on aligned memory structures. 
[block size = 4096, durable memory page size = 4096]{noformat}
 

 

 

Following test suites were added for checking Direct IO functionality using 
existing PDS tests:

[https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgnitePds1DirectIo]

[https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgnitePds2DirectIo]

 

Runs may be triggered by 
[https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_RunAllPds]

 

Example of run of PR code:

[https://ci.ignite.apache.org/viewLog.html?buildId=1044741]

 

[~agoncharuk], could you please review and merge changes from PR 
[https://github.com/apache/ignite/pull/3226] ?

> Use direct IO or libaio for file page store where applicable
> 
>
> Key: IGNITE-6341
> URL: https://issues.apache.org/jira/browse/IGNITE-6341
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Reporter: Andrey Gura
>Assignee: Dmitriy Pavlov
>Priority: Major
> Fix For: 2.4
>
>
> Need try to use direct IO or libaio for page store because once data buffer 
> is serialized, we can write it as disk pages (this will also make it easier 
> if we decide to open file as a block device).



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

[jira] [Comment Edited] (IGNITE-7389) DataStreamer hangs if exception was thrown during addData which isn't IgniteException

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov edited comment on IGNITE-7389 at 1/18/18 9:42 AM:
---

[~ilantukh]

I see no reason to check cache on each addData. 

Let's check it once on DataStreamer creation.


was (Author: avinogradov):
[~ilantukh]

I see no reason to check cache each addData. 

Let's check it once on DataStreamer creation.

> DataStreamer hangs if exception was thrown during addData which isn't 
> IgniteException
> -
>
> Key: IGNITE-7389
> URL: https://issues.apache.org/jira/browse/IGNITE-7389
> Project: Ignite
>  Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Ilya Lantukh
>Priority: Major
>
> I have written test which starts cache on one node and right after that 
> starts dataStreamer on another node. Which hangs on close method because 
> {{resFut}} will never be done. 
> {code}
> java.lang.IllegalStateException: Getting affinity for topology version 
> earlier than affinity is calculated [locNode=TcpDiscoveryNode 
> [id=ad14d7f6-5895-4038-ba5e-cc487ab0, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47501], discPort=47501, order=2, intOrder=2, 
> lastExchangeTime=1515672065430, loc=true, ver=2.4.0#19700101-sha1:, 
> isClient=false], grp=PART-G2, topVer=AffinityTopologyVersion [topVer=4, 
> minorTopVer=3], head=AffinityTopologyVersion [topVer=4, minorTopVer=4], 
> history=[AffinityTopologyVersion [topVer=4, minorTopVer=4]]]
>   at 
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:603)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.assignment(GridCacheAffinityManager.java:243)
>   at 
> org.apache.ignite.internal.processors.affinity.GridAffinityProcessor.affinityCache(GridAffinityProcessor.java:375)
>   at 
> org.apache.ignite.internal.processors.affinity.GridAffinityProcessor.partition0(GridAffinityProcessor.java:187)
>   at 
> org.apache.ignite.internal.processors.cacheobject.IgniteCacheObjectProcessorImpl.partition(IgniteCacheObjectProcessorImpl.java:267)
>   at 
> org.apache.ignite.internal.processors.cacheobject.IgniteCacheObjectProcessorImpl.toCacheKeyObject0(IgniteCacheObjectProcessorImpl.java:135)
>   at 
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.toCacheKeyObject(CacheObjectBinaryProcessorImpl.java:805)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.addData(DataStreamerImpl.java:581)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.addData(DataStreamerImpl.java:555)
>   at 
> org.gridgain.grid.internal.processors.cache.database.AbstractSnapshotTest$2.run(AbstractSnapshotTest.java:404)
>   at 
> org.apache.ignite.testframework.GridTestUtils$6.run(GridTestUtils.java:933)
>   at 
> org.apache.ignite.testframework.GridTestUtils$9.call(GridTestUtils.java:1278)
>   at 
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
> {code}
> The best solution is waiting for topology on which cache should be started.



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

[jira] [Commented] (IGNITE-7389) DataStreamer hangs if exception was thrown during addData which isn't IgniteException

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-7389:
--

[~ilantukh]

I see no reason to check cache each addData. 

Let's check it once on DataStreamer creation.

> DataStreamer hangs if exception was thrown during addData which isn't 
> IgniteException
> -
>
> Key: IGNITE-7389
> URL: https://issues.apache.org/jira/browse/IGNITE-7389
> Project: Ignite
>  Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Ilya Lantukh
>Priority: Major
>
> I have written test which starts cache on one node and right after that 
> starts dataStreamer on another node. Which hangs on close method because 
> {{resFut}} will never be done. 
> {code}
> java.lang.IllegalStateException: Getting affinity for topology version 
> earlier than affinity is calculated [locNode=TcpDiscoveryNode 
> [id=ad14d7f6-5895-4038-ba5e-cc487ab0, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47501], discPort=47501, order=2, intOrder=2, 
> lastExchangeTime=1515672065430, loc=true, ver=2.4.0#19700101-sha1:, 
> isClient=false], grp=PART-G2, topVer=AffinityTopologyVersion [topVer=4, 
> minorTopVer=3], head=AffinityTopologyVersion [topVer=4, minorTopVer=4], 
> history=[AffinityTopologyVersion [topVer=4, minorTopVer=4]]]
>   at 
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:603)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.assignment(GridCacheAffinityManager.java:243)
>   at 
> org.apache.ignite.internal.processors.affinity.GridAffinityProcessor.affinityCache(GridAffinityProcessor.java:375)
>   at 
> org.apache.ignite.internal.processors.affinity.GridAffinityProcessor.partition0(GridAffinityProcessor.java:187)
>   at 
> org.apache.ignite.internal.processors.cacheobject.IgniteCacheObjectProcessorImpl.partition(IgniteCacheObjectProcessorImpl.java:267)
>   at 
> org.apache.ignite.internal.processors.cacheobject.IgniteCacheObjectProcessorImpl.toCacheKeyObject0(IgniteCacheObjectProcessorImpl.java:135)
>   at 
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.toCacheKeyObject(CacheObjectBinaryProcessorImpl.java:805)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.addData(DataStreamerImpl.java:581)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.addData(DataStreamerImpl.java:555)
>   at 
> org.gridgain.grid.internal.processors.cache.database.AbstractSnapshotTest$2.run(AbstractSnapshotTest.java:404)
>   at 
> org.apache.ignite.testframework.GridTestUtils$6.run(GridTestUtils.java:933)
>   at 
> org.apache.ignite.testframework.GridTestUtils$9.call(GridTestUtils.java:1278)
>   at 
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
> {code}
> The best solution is waiting for topology on which cache should be started.



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

[jira] [Created] (IGNITE-7464) Add property to configure time between node connection attempts

[Stanislav Lukyanov (JIRA)]

Stanislav Lukyanov created IGNITE-7464:
--

 Summary: Add property to configure time between node connection 
attempts
 Key: IGNITE-7464
 URL: https://issues.apache.org/jira/browse/IGNITE-7464
 Project: Ignite
  Issue Type: Bug
 Environment: Currently when a node attempts to join the cluster, the 
connection algorithm will be repeated until successful or timed out. The time 
between the attempts is hardcoded - 2 seconds.
It might be useful to adjust that time via a property (say, in SPI config) 
based on the network quality, application constraints, etc.
Reporter: Stanislav Lukyanov






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

[jira] [Commented] (IGNITE-7461) Web console: incorrect code generation

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-7461:


Tested on branch

> Web console: incorrect code generation
> --
>
> Key: IGNITE-7461
> URL: https://issues.apache.org/jira/browse/IGNITE-7461
> Project: Ignite
>  Issue Type: Bug
> Environment: Error:(81, 23) java: cannot find symbol
>   symbol:   method setCheckpointPageBufferSize(long)
>   location: variable dataStorageCfg of type 
> org.apache.ignite.configuration.DataStorageConfiguration
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.4
>
>
> Do not forget to change generation of XML configuration



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

[jira] [Assigned] (IGNITE-7461) Web console: incorrect code generation

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov reassigned IGNITE-7461:
--

Assignee: Alexey Kuznetsov  (was: Pavel Konstantinov)

> Web console: incorrect code generation
> --
>
> Key: IGNITE-7461
> URL: https://issues.apache.org/jira/browse/IGNITE-7461
> Project: Ignite
>  Issue Type: Bug
> Environment: Error:(81, 23) java: cannot find symbol
>   symbol:   method setCheckpointPageBufferSize(long)
>   location: variable dataStorageCfg of type 
> org.apache.ignite.configuration.DataStorageConfiguration
>Reporter: Pavel Konstantinov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.4
>
>
> Do not forget to change generation of XML configuration



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

[jira] [Comment Edited] (IGNITE-6217) Add benchmark to compare JDBC drivers and native SQL execution

[Pavel Kuznetsov (JIRA)]

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

Pavel Kuznetsov edited comment on IGNITE-6217 at 1/18/18 9:26 AM:
--

1) Renamed

2) Cleaned up

3) To have more stable results. Since table size affects performance of query 
execution, we want `test` method to be executed with the same table size. 
[~vozerov] , correct me if I'm wrong

4) I don't mind, [~vozerov] , should we remove this?

5) -If I got it right, the most interesting results are native vs thin driver.- 
[~vozerov] -do we need v2 configurations ?- 

Yes we need this

 


was (Author: pkouznet):
1) Renamed

2) Cleaned up

3) To have more stable results. Since table size affects performance of query 
execution, we want `test` method to be executed with the same table size. 
[~vozerov] , correct me if I'm wrong

4) I don't mind, [~vozerov] , should we remove this?

5) If I got it right, the most interesting results are native vs thin driver. 
[~vozerov] do we need v2 configurations ?

> Add benchmark to compare JDBC drivers and native SQL execution
> --
>
> Key: IGNITE-6217
> URL: https://issues.apache.org/jira/browse/IGNITE-6217
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc, sql, yardstick
>Affects Versions: 2.1
>Reporter: Taras Ledkov
>Assignee: Pavel Kuznetsov
>Priority: Major
>
> We have to compare performance of the native SQL execution (via Ignite SQL 
> API), JDBC v2 driver, that uses Ignite client to connect to grid and JDBC 
> thin client.



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

[jira] [Commented] (IGNITE-7413) SqlDmlExample: Incorrect result for Delete if run with standalone nodes (Java & .NET)

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-7413:


Merged to master: {{35ce5b1e0971525c665aa19cec7fe63662ccba86}}.
Cherry-picked to ignite-2.4: {{f3f9f2a24b23027cf0c835140322e41a788932ae}}.

> SqlDmlExample: Incorrect result for Delete if run with standalone nodes (Java 
> & .NET)
> -
>
> Key: IGNITE-7413
> URL: https://issues.apache.org/jira/browse/IGNITE-7413
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.3
>Reporter: Irina Zaporozhtseva
>Assignee: Pavel Tupitsyn
>Priority: Minor
>  Labels: .NET
> Fix For: 2.4
>
>
> Datagrid.QueryDmlExample: Incorrect result for Delete if run with standalone 
> nodes
>  
> without standalone nodes:
> {code}
> >>> Delete non-ASF employees 
> >>> 1: John Doe, ASF, 4400 
> >>> 2: Jane Roe, ASF, 5500
> {code}
>  
> with standalone nodes:
> {code}
> >>> Delete non-ASF employees 
> >>> 1: John Doe, ASF, 4400
> >>> 4: Richard Miles, Eclipse, 3000 
> >>> 2: Jane Roe, ASF, 5500
> {code}



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

[jira] [Commented] (IGNITE-7413) SqlDmlExample: Incorrect result for Delete if run with standalone nodes (Java & .NET)

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7413:


Github user asfgit closed the pull request at:

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


> SqlDmlExample: Incorrect result for Delete if run with standalone nodes (Java 
> & .NET)
> -
>
> Key: IGNITE-7413
> URL: https://issues.apache.org/jira/browse/IGNITE-7413
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.3
>Reporter: Irina Zaporozhtseva
>Assignee: Pavel Tupitsyn
>Priority: Minor
>  Labels: .NET
> Fix For: 2.4
>
>
> Datagrid.QueryDmlExample: Incorrect result for Delete if run with standalone 
> nodes
>  
> without standalone nodes:
> {code}
> >>> Delete non-ASF employees 
> >>> 1: John Doe, ASF, 4400 
> >>> 2: Jane Roe, ASF, 5500
> {code}
>  
> with standalone nodes:
> {code}
> >>> Delete non-ASF employees 
> >>> 1: John Doe, ASF, 4400
> >>> 4: Richard Miles, Eclipse, 3000 
> >>> 2: Jane Roe, ASF, 5500
> {code}



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

[jira] [Commented] (IGNITE-7454) Wrong package in IgniteExamplesMLTestSuite after it was moved per IGNITE-7203

[Peter Ivanov (JIRA)]

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

Peter Ivanov commented on IGNITE-7454:
--

As much as I see, Java specification does not force classes to be in certain 
directories. And *Package name does not correspond to the file path* error is 
strictly IntelliJ IDEA's one.

> Wrong package in IgniteExamplesMLTestSuite after it was moved per IGNITE-7203
> -
>
> Key: IGNITE-7454
> URL: https://issues.apache.org/jira/browse/IGNITE-7454
> Project: Ignite
>  Issue Type: Bug
>  Components: examples, ml, yardstick
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Fix For: 2.4
>
>
> Wrong package in IgniteExamplesMLTestSuite after it was moved per 
> IGNITE-7203: \{{org.apache.ignite.ml.testsuites}}. Also, it is not added to 
> the list in {{IgniteExamplesSelfTestSuite{{ which is supposed to run all 
> examples self-tests.
> Change to correct package: \{{org.apache.ignite.testsuites}} and add to main 
> testsuite.
> For the sake of completeness, a bunch of newer ml benchmarks (done per 
> IGNITE-7214 and IGNITE-7097) were forgotten to be moved in yardstick module 
> when merging to master. These should be fixed (moved to proper folder).



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

[jira] [Commented] (IGNITE-7454) Wrong package in IgniteExamplesMLTestSuite after it was moved per IGNITE-7203

[Peter Ivanov (JIRA)]

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

Peter Ivanov commented on IGNITE-7454:
--

As much as I see, Java specification does not force classes to be in certain 
directories. And *Package name does not correspond to the file path* error is 
strictly IntelliJ IDEA's one.

> Wrong package in IgniteExamplesMLTestSuite after it was moved per IGNITE-7203
> -
>
> Key: IGNITE-7454
> URL: https://issues.apache.org/jira/browse/IGNITE-7454
> Project: Ignite
>  Issue Type: Bug
>  Components: examples, ml, yardstick
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Fix For: 2.4
>
>
> Wrong package in IgniteExamplesMLTestSuite after it was moved per 
> IGNITE-7203: \{{org.apache.ignite.ml.testsuites}}. Also, it is not added to 
> the list in {{IgniteExamplesSelfTestSuite{{ which is supposed to run all 
> examples self-tests.
> Change to correct package: \{{org.apache.ignite.testsuites}} and add to main 
> testsuite.
> For the sake of completeness, a bunch of newer ml benchmarks (done per 
> IGNITE-7214 and IGNITE-7097) were forgotten to be moved in yardstick module 
> when merging to master. These should be fixed (moved to proper folder).



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

[jira] [Issue Comment Deleted] (IGNITE-7454) Wrong package in IgniteExamplesMLTestSuite after it was moved per IGNITE-7203

[Peter Ivanov (JIRA)]

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

Peter Ivanov updated IGNITE-7454:
-
Comment: was deleted

(was: As much as I see, Java specification does not force classes to be in 
certain directories. And *Package name does not correspond to the file path* 
error is strictly IntelliJ IDEA's one.)

> Wrong package in IgniteExamplesMLTestSuite after it was moved per IGNITE-7203
> -
>
> Key: IGNITE-7454
> URL: https://issues.apache.org/jira/browse/IGNITE-7454
> Project: Ignite
>  Issue Type: Bug
>  Components: examples, ml, yardstick
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Fix For: 2.4
>
>
> Wrong package in IgniteExamplesMLTestSuite after it was moved per 
> IGNITE-7203: \{{org.apache.ignite.ml.testsuites}}. Also, it is not added to 
> the list in {{IgniteExamplesSelfTestSuite{{ which is supposed to run all 
> examples self-tests.
> Change to correct package: \{{org.apache.ignite.testsuites}} and add to main 
> testsuite.
> For the sake of completeness, a bunch of newer ml benchmarks (done per 
> IGNITE-7214 and IGNITE-7097) were forgotten to be moved in yardstick module 
> when merging to master. These should be fixed (moved to proper folder).



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

[jira] [Commented] (IGNITE-3935) ClassLoaders are not switched during object deserialization

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-3935:


Github user asfgit closed the pull request at:

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


> ClassLoaders are not switched during object deserialization
> ---
>
> Key: IGNITE-3935
> URL: https://issues.apache.org/jira/browse/IGNITE-3935
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Affects Versions: 1.6
>Reporter: Denis Magda
>Assignee: Denis Mekhanikov
>Priority: Major
> Fix For: 2.4
>
>
> If an object is being deserialized with ClassLoader A then this ClassLoader A 
> will be used for the deserialization of the whole object's state, i.e., 
> including all its fields that can be custom objects loaded by ClassLoader B. 
> In a basic scenario we can have an object of some Ignite class that is 
> presented in the classpath. That Ignite class may enclose an object that is 
> loaded by peer-class-loading class loader. The deserialization will fail 
> because Ignite won't switch to the peer-class-loading loader when it's needed.
> To reproduce the issue do the following:
> 1. Start a remote ignite node using {{./ignite.sh 
> ../examples/config/example-ignite.xml}}
> 2. Run the code below
> {code}
> public class StreamingExample {`
> public static class StreamingExampleCacheEntryProcessor implements 
> CacheEntryProcessor {
> @Override
> public Object process(MutableEntry e, Object... arg) throws 
> EntryProcessorException {
> Long val = e.getValue();
> e.setValue(val == null ? 1L : val + 1);
> return null;
> }
> }
> public static void main(String[] args) throws IgniteException, IOException {
> Ignition.setClientMode(true);
> try (Ignite ignite = 
> Ignition.start("examples/config/example-ignite.xml")) {
> IgniteCache stmCache = 
> ignite.getOrCreateCache("mycache");
> try (IgniteDataStreamer stmr = 
> ignite.dataStreamer(stmCache.getName())) {
> stmr.allowOverwrite(true);
> stmr.receiver(StreamTransformer.from(new 
> StreamingExampleCacheEntryProcessor()));
> stmr.addData("word", 1L);
> System.out.println("Finished");
> }
> }
> }
> {code}
> However if to modify this code to the following everything will work fine 
> {code}
> public class StreamingExample {
> public static class StreamingExampleCacheEntryProcessor extends 
> StreamTransformer {
> @Override
> public Object process(MutableEntry e, Object... arg) 
> throws EntryProcessorException {
> System.out.println("Executed!");
> Long val = e.getValue();
> e.setValue(val == null ? 1L : val + 1);
> return null;
> }
> }
> public static void main(String[] args) throws IgniteException, 
> IOException {
> Ignition.setClientMode(true);
> try (Ignite ignite = 
> Ignition.start("examples/config/example-ignite.xml")) {
> IgniteCache stmCache = 
> ignite.getOrCreateCache("mycache");
> try (IgniteDataStreamer stmr = 
> ignite.dataStreamer(stmCache.getName())) {
> stmr.allowOverwrite(true);
> stmr.receiver(new StreamingExampleCacheEntryProcessor());
> stmr.addData("word", 1L);
> System.out.println("Finished");
> }
> }
> }
> }
> {code}



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

[jira] [Commented] (IGNITE-3935) ClassLoaders are not switched during object deserialization

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-3935:
--

Thanks, Denis, merged your changes to master and ignite-2.4

> ClassLoaders are not switched during object deserialization
> ---
>
> Key: IGNITE-3935
> URL: https://issues.apache.org/jira/browse/IGNITE-3935
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Affects Versions: 1.6
>Reporter: Denis Magda
>Assignee: Denis Mekhanikov
>Priority: Major
> Fix For: 2.4
>
>
> If an object is being deserialized with ClassLoader A then this ClassLoader A 
> will be used for the deserialization of the whole object's state, i.e., 
> including all its fields that can be custom objects loaded by ClassLoader B. 
> In a basic scenario we can have an object of some Ignite class that is 
> presented in the classpath. That Ignite class may enclose an object that is 
> loaded by peer-class-loading class loader. The deserialization will fail 
> because Ignite won't switch to the peer-class-loading loader when it's needed.
> To reproduce the issue do the following:
> 1. Start a remote ignite node using {{./ignite.sh 
> ../examples/config/example-ignite.xml}}
> 2. Run the code below
> {code}
> public class StreamingExample {`
> public static class StreamingExampleCacheEntryProcessor implements 
> CacheEntryProcessor {
> @Override
> public Object process(MutableEntry e, Object... arg) throws 
> EntryProcessorException {
> Long val = e.getValue();
> e.setValue(val == null ? 1L : val + 1);
> return null;
> }
> }
> public static void main(String[] args) throws IgniteException, IOException {
> Ignition.setClientMode(true);
> try (Ignite ignite = 
> Ignition.start("examples/config/example-ignite.xml")) {
> IgniteCache stmCache = 
> ignite.getOrCreateCache("mycache");
> try (IgniteDataStreamer stmr = 
> ignite.dataStreamer(stmCache.getName())) {
> stmr.allowOverwrite(true);
> stmr.receiver(StreamTransformer.from(new 
> StreamingExampleCacheEntryProcessor()));
> stmr.addData("word", 1L);
> System.out.println("Finished");
> }
> }
> }
> {code}
> However if to modify this code to the following everything will work fine 
> {code}
> public class StreamingExample {
> public static class StreamingExampleCacheEntryProcessor extends 
> StreamTransformer {
> @Override
> public Object process(MutableEntry e, Object... arg) 
> throws EntryProcessorException {
> System.out.println("Executed!");
> Long val = e.getValue();
> e.setValue(val == null ? 1L : val + 1);
> return null;
> }
> }
> public static void main(String[] args) throws IgniteException, 
> IOException {
> Ignition.setClientMode(true);
> try (Ignite ignite = 
> Ignition.start("examples/config/example-ignite.xml")) {
> IgniteCache stmCache = 
> ignite.getOrCreateCache("mycache");
> try (IgniteDataStreamer stmr = 
> ignite.dataStreamer(stmCache.getName())) {
> stmr.allowOverwrite(true);
> stmr.receiver(new StreamingExampleCacheEntryProcessor());
> stmr.addData("word", 1L);
> System.out.println("Finished");
> }
> }
> }
> }
> {code}



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