[jira] [Assigned] (IGNITE-6502) Need to output warning if -Djava.net.preferIPv4Stack=true is not set

[vk (JIRA)]

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

vk reassigned IGNITE-6502:
--

Assignee: vk

> Need to output warning if -Djava.net.preferIPv4Stack=true is not set
> 
>
> Key: IGNITE-6502
> URL: https://issues.apache.org/jira/browse/IGNITE-6502
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Yakov Zhdanov
>Assignee: vk
>  Labels: usability
> Fix For: 2.3
>
>
> Some issues were reported on dev/user list that may be caused by ipv6 usage. 
> I am not sure if Ignite can properly work with ipv6 networks. This needs to 
> be tested.
> For now it seems to be pretty handy just to have warning on node start:
> {{noformat}}
> Please set system property '-Djava.net.preferIPv4Stack=true' to avoid 
> possible problems in mixed environments.
> {{noformat}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5813) Inconsistent cache store state when originating node fails on commit.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5813:

Fix Version/s: (was: 2.3)

> Inconsistent cache store state when originating node fails on commit.
> -
>
> Key: IGNITE-5813
> URL: https://issues.apache.org/jira/browse/IGNITE-5813
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Andrew Mashenkov
> Attachments: IgniteTxRecoveryAfterStoreCommitSelfTest.java
>
>
> Same tx can be rolled back by cache and commited by CacheStore.
> It is possible when originating tx node commit tx successfully, but fails to 
> notify other nodes. 
> PFA reproducer.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6163) Upgrade to Spark 2.2.0

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6163:

Fix Version/s: (was: 2.3)

> Upgrade to Spark 2.2.0
> --
>
> Key: IGNITE-6163
> URL: https://issues.apache.org/jira/browse/IGNITE-6163
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Denis Magda
>Priority: Blocker
>  Labels: usability
>
> Apache Ignite's Spark integration module has to be updated to Spark 2.2.0 to 
> avoid issues like this:
> https://github.com/dmagda/IgniteSparkIoT/issues/1
> In short, Spark 2.1.0 and Spark 2.2.0 modules can't be mixed together, 
> otherwise, the exceptions like this will pop up:
> {code}
> Exception in thread "main" java.lang.NoSuchMethodError: 
> org.apache.spark.ui.SparkUI.setStreamingJobProgressListener(Lorg/apache/spark/scheduler/SparkListener;)V
>   at 
> org.apache.spark.streaming.ui.StreamingTab.(StreamingTab.scala:41)
>   at 
> org.apache.spark.streaming.StreamingContext.(StreamingContext.scala:192)
>   at 
> org.apache.spark.streaming.StreamingContext.(StreamingContext.scala:85)
>   at 
> org.apache.spark.streaming.api.java.JavaStreamingContext.(JavaStreamingContext.scala:138)
>   at 
> org.apache.ignite.iot.SparkStreamerStartup.main(SparkStreamerStartup.java:71)
> 17/08/22 18:27:25 INFO SparkContext: Invoking stop() from shutdown hook
> 17/08/22 18:27:25 INFO SparkUI: Stopped Spark web UI at http://10.0.1.6:4040
> {code} 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-4890) Unable to create tables automatically because 'unconfigured columnfamily' error is not handled for older Cassandra versions

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4890:

Fix Version/s: (was: 2.3)

> Unable to create tables automatically because 'unconfigured columnfamily' 
> error is not handled for older Cassandra versions
> ---
>
> Key: IGNITE-4890
> URL: https://issues.apache.org/jira/browse/IGNITE-4890
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.9
>Reporter: Venky Kandaswamy
>  Labels: patch
>
> PROBLEM:
> When running Ignite with older Cassandra versions (i.e DSE 4.8.10, Cassandra 
> 2.1.6 or older), we noticed that only the first tabel in an Ignite config is 
> created and the others fail with 'unconfigured columnfamily' exception.
> SUGGESTED FIX:
> It appears that the error from Cassandra is changed in newer versions to 
> 'unconfigured table ...' and this is handled.  The conditions checked in 
> org.apache.ignite.cache.store.cassandra.common.CassandraHelper needs to be 
> modified to handle the older Cassandra errors. 
> We are submitting a patch to do that. 
> 13:44:28,753 ERROR com.walmartlabs.qarth.ignite.tests.utils.CacheStoreHelper 
> [main] - Failed to execute Cassandra CQL statement: insert into 
> "test1"."blob_test2" ("key", "value") values (?,?);
> class org.apache.ignite.IgniteException: Failed to execute Cassandra CQL 
> statement: insert into "test1"."blob_test2" ("key", "value") values (?,?);
>   at 
> org.apache.ignite.cache.store.cassandra.session.CassandraSessionImpl.execute(CassandraSessionImpl.java:163)
>   at 
> org.apache.ignite.cache.store.cassandra.CassandraCacheStore.write(CassandraCacheStore.java:276)
>   at 
> com.walmartlabs.qarth.ignite.tests.cassandra.CassandraDirectPersistenceTest.blobStrategyTest(CassandraDirectPersistenceTest.java:233)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>   at 
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
>   at 
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: class org.apache.ignite.IgniteException: Failed to prepare 
> Cassandra CQL statement: insert into "test1"."blob_test2" ("key", "value") 
> values (?,?);
>   at 
> org.apache.ignite.cache.store.cassandra.session.CassandraSessionImpl.prepareStatement(CassandraSessionImpl.java:615)
>   at 
> org.apache.ignite.cache.store.cassandra.session.CassandraSessionImpl.execute(CassandraSessionImpl.java:133)
>   ... 27 more
> Caused by: com.datastax.driver.core.exceptions.InvalidQueryException: 
> unconfigured columnfamily blob_test2
>   at 
> com.datastax.driver.core.exceptions.InvalidQueryException.copy(InvalidQueryException.java:50)
>   at 
> 

[jira] [Updated] (IGNITE-2377) Docker image hangs on Mac OS

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2377:

Fix Version/s: (was: 2.3)

> Docker image hangs on Mac OS
> 
>
> Key: IGNITE-2377
> URL: https://issues.apache.org/jira/browse/IGNITE-2377
> Project: Ignite
>  Issue Type: Wish
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Chandresh Pancholi
>  Labels: newbie
>
> Docker hangs at the point when {{CommandLineRandomNumberGenerator}} is being 
> executed. The reason is that the current and previous Docker version has some 
> bug that can be overcame if to put {{System.exit(0)}} at the end of 
> {{main(...)}} function.
> More investigation details and steps to reproduce can be found here:
> http://stackoverflow.com/questions/34661934/ignite-running-in-docker-is-general-java-docker-issue
> It makes sense to add {{System.exit(0)}} to all our classes that are executed 
> by {{ignite.bat}} or {{ignite.sh}} because it's not harmful in any case.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5496) Externalizable classes get registered twice

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5496:

Fix Version/s: (was: 2.3)

> Externalizable classes get registered twice
> ---
>
> Key: IGNITE-5496
> URL: https://issues.apache.org/jira/browse/IGNITE-5496
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.7
>Reporter: Alexey Goncharuk
>Assignee: Amelchev Nikita
>  Labels: important
>
> I observed a strange behavior on ignite-1.7. If I have an externalizable 
> class inside of a serializable class and BinaryMarshaller is used, the 
> externalizable class gets registered twice with different typeIds.
> Looks like this happens because in BinaryWriterExImpl#marshal0 we first call 
> ctx.descriptorForClass(cls, false) which will calculate and register type 
> with one typeId. Then we figure out that the class is externalizable and 
> switch to optimized marshaller (U.marshal(ctx.optimizedMarsh(), obj)) which 
> will register another type ID.
> Need to check if this is still reproducible in 2.1-2.2 as it may be a 
> performance issue.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6503) Need to test Ignite in IPv6 environment

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6503:

Fix Version/s: (was: 2.3)

> Need to test Ignite in IPv6 environment
> ---
>
> Key: IGNITE-6503
> URL: https://issues.apache.org/jira/browse/IGNITE-6503
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Yakov Zhdanov
>Priority: Minor
>  Labels: usability
>
> It seems that Ignite may have problems with IPv6. Need to test it and fix if 
> necessary.
> Areas to check:
> # build cluster on local node with different IP finders on different OSes.
> # build distributed cluster with different IP finders on different OSes.
> # check communication by running some yardstick benchmark (e.g. atomic put). 
> 1 client vs 2-3 servers will be fine.
> # kill some node while benchmark is running
> # add new node while benchmark is running
> http://apache-ignite-developers.2346864.n4.nabble.com/Issues-if-Djava-net-preferIPv4Stack-true-is-not-set-td22372.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-1948) ClusterTopologyCheckedException can return null for retryReadyFuture()

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-1948:

Fix Version/s: (was: 2.3)

> ClusterTopologyCheckedException can return null for retryReadyFuture()
> --
>
> Key: IGNITE-1948
> URL: https://issues.apache.org/jira/browse/IGNITE-1948
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Denis Magda
>Assignee: Alexander Menshikov
>
> It was noted that {{ClusterTopologyCheckedException}} ready future can be 
> null.
> Go though all the places where this kind of exception is being initialized 
> and check why the ready future is not set in some cases.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-4448) Implement correct affinity validation on joining topology.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4448:

Fix Version/s: (was: 2.3)

> Implement correct affinity validation on joining topology.
> --
>
> Key: IGNITE-4448
> URL: https://issues.apache.org/jira/browse/IGNITE-4448
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
>
> Currently on joining a topology only affinity class name and partition number 
> are checked between configurations of local and remote nodes.
> This is not enough in case of configured backup filter and possible extension 
> with primary filter and can lead to disastrous situations due to node 
> misconfiguration.
> We should implement something like {{AffinityValidator}} having signature as 
> follows:
> {noformat}
> boolean validate(Affinity affinity)
> {noformat}
> Maybe it'll be useful for other grid objects as well, like 
> {{CacheStore}},{{NodeFilter}}, etc.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6506) Cluster activation hangs if a node was stopped during persistent storage checkpoint

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6506:

Fix Version/s: 2.3

> Cluster activation hangs if a node was stopped during persistent storage 
> checkpoint
> ---
>
> Key: IGNITE-6506
> URL: https://issues.apache.org/jira/browse/IGNITE-6506
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.2
>Reporter: Joel Lang
>Priority: Critical
> Fix For: 2.3
>
>
> I have a cluster with two nodes: A and B.
> On startup, node A and B wait for each other to be connected and then node A 
> will attempt to activate the cluster.
> While testing high availability we find that if a node is stopped during the 
> persistent store checkpoint, we cannot activate the cluster on startup 
> without deleting the persistent storage directory. Specifically in the case 
> where node A is stopped during checkpointing, upon the next startup it will 
> encounter several exceptions during activation and then hang without 
> completing activation.
> Here is the log.
> {noformat}
> 2017-09-26 12:11:24 [tcp-disco-msg-worker-#2%mbe%] INFO  
> o.a.i.i.p.c.GridClusterStateProcessor - Start state transition: true
> 2017-09-26 12:11:24 [exchange-worker-#34%mbe%] INFO  
> o.a.ignite.internal.exchange.time - Started exchange init 
> [topVer=AffinityTopologyVersion [topVer=2, minorTopVer=1], crd=true, evt=18, 
> node=TcpDiscoveryNode [id=62cf0ccb-e376-4b80-8d2d-98115c3a2990, 
> addrs=[10.5.17.19, 127.0.0.1], 
> sockAddrs=[shouvdevmbe02.petrolink.net/10.5.17.19:47510, /127.0.0.1:47510], 
> discPort=47510, order=1, intOrder=1, lastExchangeTime=1506445884063, 
> loc=true, ver=2.2.0#20170915-sha1:5747ce6b, isClient=false], 
> evtNode=TcpDiscoveryNode [id=62cf0ccb-e376-4b80-8d2d-98115c3a2990, 
> addrs=[10.5.17.19, 127.0.0.1], 
> sockAddrs=[shouvdevmbe02.petrolink.net/10.5.17.19:47510, /127.0.0.1:47510], 
> discPort=47510, order=1, intOrder=1, lastExchangeTime=1506445884063, 
> loc=true, ver=2.2.0#20170915-sha1:5747ce6b, isClient=false], 
> customEvt=ChangeGlobalStateMessage 
> [id=1d0cb2fbe51-7967bd11-40aa-40fe-b0a6-c43302cd4ee7, 
> reqId=f7155dea-fede-4340-b244-7a3b65f167a8, 
> initiatingNodeId=62cf0ccb-e376-4b80-8d2d-98115c3a2990, activate=true]]
> 2017-09-26 12:11:24 [exchange-worker-#34%mbe%] INFO  
> o.a.i.i.p.c.d.d.p.GridDhtPartitionsExchangeFuture - Start activation process 
> [nodeId=62cf0ccb-e376-4b80-8d2d-98115c3a2990, client=false, 
> topVer=AffinityTopologyVersion [topVer=2, minorTopVer=1]]
> 2017-09-26 12:11:24 [exchange-worker-#34%mbe%] INFO  
> o.a.i.i.p.c.p.f.FilePageStoreManager - Resolved page store work directory: 
> /opt/mbe1/ignite/db/mbe_MBE1
> 2017-09-26 12:11:24 [exchange-worker-#34%mbe%] INFO  
> o.a.i.i.p.c.p.w.FileWriteAheadLogManager - Resolved write ahead log work 
> directory: /opt/mbe1/ignite/db/wal/mbe_MBE1
> 2017-09-26 12:11:24 [exchange-worker-#34%mbe%] INFO  
> o.a.i.i.p.c.p.w.FileWriteAheadLogManager - Resolved write ahead log archive 
> directory: /opt/mbe1/ignite/db/wal/archive/mbe_MBE1
> 2017-09-26 12:11:24 [exchange-worker-#34%mbe%] WARN  
> o.a.i.i.p.c.p.GridCacheDatabaseSharedManager - No user-defined default 
> MemoryPolicy found; system default of 1GB size will be used.
> 2017-09-26 12:11:24 [exchange-worker-#34%mbe%] INFO  
> o.a.i.i.p.c.p.pagemem.PageMemoryImpl - Started page memory 
> [memoryAllocated=100.0 MiB, pages=48592, tableSize=2.9 MiB, 
> checkpointBuffer=819.4 MiB]
> 2017-09-26 12:11:24 [exchange-worker-#34%mbe%] INFO  
> o.a.i.i.p.c.p.pagemem.PageMemoryImpl - Started page memory 
> [memoryAllocated=3.1 GiB, pages=1544064, tableSize=91.0 MiB, 
> checkpointBuffer=819.4 MiB]
> 2017-09-26 12:11:24 [exchange-worker-#34%mbe%] INFO  
> o.a.i.i.p.c.p.GridCacheDatabaseSharedManager - Read checkpoint status: start 
> marker = 
> /opt/mbe1/ignite/db/mbe_MBE1/cp/1506444061104-38b80aaa-8c3d-4572-a42e-5b7a3b472505-START.bin,
>  end marker = 
> /opt/mbe1/ignite/db/mbe_MBE1/cp/1506442980839-ff65a0dc-3d83-436a-8329-7b3a31fe5ffc-END.bin
> 2017-09-26 12:11:24 [exchange-worker-#34%mbe%] INFO  
> o.a.i.i.p.c.p.GridCacheDatabaseSharedManager - Checking memory state 
> [lastValidPos=FileWALPointer [idx=139, fileOffset=31406805, len=20731, 
> forceFlush=false], lastMarked=FileWALPointer [idx=0, fileOffset=0, len=0, 
> forceFlush=false], lastCheckpointId=38b80aaa-8c3d-4572-a42e-5b7a3b472505]
> 2017-09-26 12:11:24 [exchange-worker-#34%mbe%] WARN  
> o.a.i.i.p.c.p.GridCacheDatabaseSharedManager - Ignite node stopped in the 
> middle of checkpoint. Will restore memory state and finish checkpoint on node 
> start.
> 2017-09-26 12:11:24 [exchange-worker-#34%mbe%] ERROR 
> o.a.i.i.p.c.d.d.p.GridDhtPartitionsExchangeFuture - Failed to activate node 
> components 

[jira] [Updated] (IGNITE-2421) EventTypes are badly documented

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2421:

Fix Version/s: (was: 2.3)

> EventTypes are badly documented
> ---
>
> Key: IGNITE-2421
> URL: https://issues.apache.org/jira/browse/IGNITE-2421
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>
> We have to go through all the {{EventTypes}} and document them well:
> - in which conditions they are fired;
> - what kind of nodes (primary, backups or both) will receive and update;
> - etc.
> As an example.
> From {{EVT_CACHE_ENTRY_CREATED}} is not clear when it's fired at all. However 
> it's fired when an entry is loaded from a storage, or when it's initially 
> created due to a cache put.
> The same situation is around {{EVT_CACHE_OBJECT_PUT}}. There is no info 
> saying that it's fired on both primary and backup nodes. That it's not fired 
> due to a loading from a cache, etc.
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-435) Visor should use smart format for time values

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-435:
---
Fix Version/s: (was: 2.3)

> Visor should use smart format for time values
> -
>
> Key: IGNITE-435
> URL: https://issues.apache.org/jira/browse/IGNITE-435
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: sprint-2
>Reporter: Pavel Konstantinov
>Assignee: YoungGyu Chun
>Priority: Minor
>  Labels: visor
>
> {code}
>  Maximum job execute time| 60009ms  - should show 1m
>  Curent job execute time | 120ms
>  Average job execute time| 1126.57ms - should show 1s
>  Total busy time | 70769ms - should show 1m 10s
> {code}
> Also please fix the typo 'Curent' - should be 'Current'



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6518) Smarter analysis of INSERT and MERGE statements at parsing stage

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6518:

Fix Version/s: (was: 2.3)

> Smarter analysis of INSERT and MERGE statements at parsing stage
> 
>
> Key: IGNITE-6518
> URL: https://issues.apache.org/jira/browse/IGNITE-6518
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Alexander Paschenko
>
> We could analyze INSERT and MERGE statements to detect that they don't 
> specify data for key and/or value to notify users early that their query 
> can't be executed within Ignite - prior to building plans and attempting to 
> actually do anything.
> (Note how we check that CREATE TABLE doesn't declare columns for key - logic 
> here would be similar.)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5580) Improve node failure cause information

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5580:

Fix Version/s: (was: 2.3)

> Improve node failure cause information
> --
>
> Key: IGNITE-5580
> URL: https://issues.apache.org/jira/browse/IGNITE-5580
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.7
>Reporter: Alexey Goncharuk
>Assignee: Vadim Opolski
>  Labels: observability
>
> When a node fails, we do not print out any information about the root cause 
> of this failure. This makes it extremely hard to investigate the failure 
> causes - I need to find a previous node for the failed node and check the 
> logs on the previous node.
> I suggest that we add extensive information about the reason of the node 
> failure and the sequence of events that led to this, e.g.:
> [time] [NODE] Sending a message to next node - failed _because_ - write 
> timeout, read timeout, ...?
> [time] [NODE] Connection check - failed - why? Connection refused, handshake 
> timed out, ...?
> ...
> [time] [NODE] Decided to drop the node because of the sequence above
> Maybe we do not need to print out this information always, but we do need 
> this when troubleshooting logger is enabled.
> Also, DiscoverySpi should collect a set of latest important events and dump 
> these events in case of local node segmentation. This will allow users to 
> match the events in the cluster and events on local node and get to the 
> bottom of the failure.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5561) Warn about long-running cache store operations

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5561:

Fix Version/s: (was: 2.3)

> Warn about long-running cache store operations
> --
>
> Key: IGNITE-5561
> URL: https://issues.apache.org/jira/browse/IGNITE-5561
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 1.7
>Reporter: Alexey Goncharuk
>Assignee: Vadim Opolski
>  Labels: observability
>
> When a cache store is used, it may become very confusing if a cache store 
> performs a very long-running operation, because in this case, Ignite would 
> output a warning about long-running cache operations. I think, in addition to 
> that, we should measure and output a warning if a specific cache store 
> operation took too long.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5823) Need to remove CacheAtomicUpdateTimeoutException

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5823:

Fix Version/s: (was: 2.3)

> Need to remove CacheAtomicUpdateTimeoutException
> 
>
> Key: IGNITE-5823
> URL: https://issues.apache.org/jira/browse/IGNITE-5823
> Project: Ignite
>  Issue Type: Task
>Reporter: Yakov Zhdanov
>Assignee: Sergey Dorozhkin
>Priority: Minor
>  Labels: newbie
>
> And releated - CacheAtomicUpdateTimeoutCheckedException
> These exceptions are not used any more and can be removed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-2313) Need to add a mode to fail atomic operations within a transaction

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2313:

Fix Version/s: (was: 2.3)

> Need to add a mode to fail atomic operations within a transaction
> -
>
> Key: IGNITE-2313
> URL: https://issues.apache.org/jira/browse/IGNITE-2313
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Dmitriy Setrakyan
>Assignee: Ryabov Dmitrii
>
> Currently atomic operations within a transaction succeed without alarming a 
> user that no transaction really occurs. We should add a mode to fail such 
> operations (such mode should be turned off by default).
> New transaction configuration flag (default is {{false}}):
> {code}TransactionConfiguration.isAllowAtomicUpdatesInTransaction(){code}
> If the flag is violated, we should throw an exception with the following 
> error message: {{Transaction spans operations on atomic cache (consider 
> setting TransactionConfiguration.isAllowAttomicUpdatesInTransaction() flag to 
> true)}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6361) Add Meta descriptions on Ignite website pages

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6361:

Fix Version/s: 2.3

> Add Meta descriptions on Ignite website pages
> -
>
> Key: IGNITE-6361
> URL: https://issues.apache.org/jira/browse/IGNITE-6361
> Project: Ignite
>  Issue Type: Task
>Reporter: Prachi Garg
>Assignee: Prachi Garg
>
> Determine which pages need meta descriptions and create them. Meta 
> descriptions should be unique and created to draw users in from the SERPs.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6361) Add Meta descriptions on Ignite website pages

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6361:

Fix Version/s: (was: 2.3)

> Add Meta descriptions on Ignite website pages
> -
>
> Key: IGNITE-6361
> URL: https://issues.apache.org/jira/browse/IGNITE-6361
> Project: Ignite
>  Issue Type: Task
>Reporter: Prachi Garg
>Assignee: Prachi Garg
>
> Determine which pages need meta descriptions and create them. Meta 
> descriptions should be unique and created to draw users in from the SERPs.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6361) Add Meta descriptions on Ignite website pages

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6361:

Fix Version/s: (was: 2.3)

> Add Meta descriptions on Ignite website pages
> -
>
> Key: IGNITE-6361
> URL: https://issues.apache.org/jira/browse/IGNITE-6361
> Project: Ignite
>  Issue Type: Task
>Reporter: Prachi Garg
>Assignee: Prachi Garg
>
> Determine which pages need meta descriptions and create them. Meta 
> descriptions should be unique and created to draw users in from the SERPs.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6518) Smarter analysis of INSERT and MERGE statements at parsing stage

[Alexander Paschenko (JIRA)]

Alexander Paschenko created IGNITE-6518:
---

 Summary: Smarter analysis of INSERT and MERGE statements at 
parsing stage
 Key: IGNITE-6518
 URL: https://issues.apache.org/jira/browse/IGNITE-6518
 Project: Ignite
  Issue Type: Improvement
  Components: sql
Reporter: Alexander Paschenko
 Fix For: 2.3


We could analyze INSERT and MERGE statements to detect that they don't specify 
data for key and/or value to notify users early that their query can't be 
executed within Ignite - prior to building plans and attempting to actually do 
anything.
(Note how we check that CREATE TABLE doesn't declare columns for key - logic 
here would be similar.)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-4358) Better error reporting in case of unmarshallable classes.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4358:

Fix Version/s: (was: 2.3)

> Better error reporting in case of unmarshallable classes.
> -
>
> Key: IGNITE-4358
> URL: https://issues.apache.org/jira/browse/IGNITE-4358
> Project: Ignite
>  Issue Type: Improvement
>  Components: compute, messaging
>Affects Versions: 1.6
>Reporter: Alexei Scherbakov
>Assignee: Rohit Mohta
>Priority: Trivial
>  Labels: newbie
> Attachments: IGNITE-4358-Exceptionlog-05Dec2016.txt, 
> IGNITE-4358-GridClosureProcessor-05Dec2016.patch, PureIgniteRunTest.java
>
>
> When trying to execute Thread's derived class implementing IgniteRunnable 
> using compute API, it silently serializes to null because Thread 
> serialization is prohibited in MarshallerExclusions and throws NPE on 
> executing node.
> We need to throw more informative exception for such case.
> Reproducer in the attachment.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6042) Update KafkaStreamer dependencies to Kafka 0.11.x

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6042:

Fix Version/s: (was: 2.3)

> Update KafkaStreamer dependencies to Kafka 0.11.x
> -
>
> Key: IGNITE-6042
> URL: https://issues.apache.org/jira/browse/IGNITE-6042
> Project: Ignite
>  Issue Type: Task
>  Components: streaming
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-3878) Add isPrimary() and isBackup() methods on CacheQUeryEntryEvent

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-3878:

Fix Version/s: (was: 2.3)

> Add isPrimary() and isBackup() methods on CacheQUeryEntryEvent
> --
>
> Key: IGNITE-3878
> URL: https://issues.apache.org/jira/browse/IGNITE-3878
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 1.7
>Reporter: Nikolay Tikhonov
>Assignee: Maksim Kozlov
>Priority: Minor
>
> In some cases useful know where (on primary or backup nodes) was invoked  a 
> continuous query filter.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5037) Fix broken @AffinityKeyMapped annotation for compute jobs.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5037:

Fix Version/s: (was: 2.3)

> Fix broken @AffinityKeyMapped annotation for compute jobs.
> --
>
> Key: IGNITE-5037
> URL: https://issues.apache.org/jira/browse/IGNITE-5037
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 1.7
>Reporter: Alexei Scherbakov
>Assignee: Maksim Kozlov
>  Labels: newbie
>
> See related discussion on dev list entitled Proper collocation of 
> computations and data 
> (http://apache-ignite-developers.2346864.n4.nabble.com/Proper-collocation-of-computations-and-data-td16945.html).
> We must repair data affinity routing for compute jobs. It should work same as 
> for affinityCall/Run with partition.
> Currently, ComputeTask map method returns Map ClusterNode>,
> but we have to provide some API allows to map ComputeJobs to partitions or 
> keys. 
> This can be done using AffinityKeyMapped annotation or any other way.
> Since that's a publiс API any fixes should be discussed on dev list prior to 
> implementation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-4910) Add copyOnRead property for near cache.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4910:

Fix Version/s: (was: 2.3)

> Add copyOnRead property for near cache.
> ---
>
> Key: IGNITE-4910
> URL: https://issues.apache.org/jira/browse/IGNITE-4910
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.1
>Reporter: Maksim Kozlov
>Assignee: Maksim Kozlov
>
> Add {{setCopyOnRead}} to {{NearCacheConfiguration}} class.
> Continuation of the task from the ticket 
> [https://issues.apache.org/jira/browse/IGNITE-2558].



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5046) TcpDiscoverySpi.toString() method miss some fields.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5046:

Fix Version/s: (was: 2.3)

> TcpDiscoverySpi.toString() method miss some fields.
> ---
>
> Key: IGNITE-5046
> URL: https://issues.apache.org/jira/browse/IGNITE-5046
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.9
>Reporter: Andrew Mashenkov
>Assignee: neeraj
>Priority: Minor
>  Labels: newbie
>
> We have a number of protected fields that is missed by toString method.
> Looks like we should annotate these fields with @GridToStringInclude.
> locAddr, locPort, locPortRange, netTimeout and others.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5227) StackOverflowError in GridCacheMapEntry#checkOwnerChanged()

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5227:

Fix Version/s: (was: 2.3)

> StackOverflowError in GridCacheMapEntry#checkOwnerChanged()
> ---
>
> Key: IGNITE-5227
> URL: https://issues.apache.org/jira/browse/IGNITE-5227
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Alexey Goncharuk
>Assignee: Mikhail Cherkasov
>Priority: Critical
>
> A simple test reproducing this error:
> {code}
> /**
>  * @throws Exception if failed.
>  */
> public void testBatchUnlock() throws Exception {
>startGrid(0);
>grid(0).createCache(new CacheConfiguration Integer>(DEFAULT_CACHE_NAME)
> .setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL));
> try {
> final CountDownLatch releaseLatch = new CountDownLatch(1);
> IgniteInternalFuture fut = GridTestUtils.runAsync(new 
> Callable() {
> @Override public Object call() throws Exception {
> IgniteCache cache = grid(0).cache(null);
> Lock lock = cache.lock("key");
> try {
> lock.lock();
> releaseLatch.await();
> }
> finally {
> lock.unlock();
> }
> return null;
> }
> });
> Map putMap = new LinkedHashMap<>();
> putMap.put("key", "trigger");
> for (int i = 0; i < 10_000; i++)
> putMap.put("key-" + i, "value");
> IgniteCache asyncCache = 
> grid(0).cache(null).withAsync();
> asyncCache.putAll(putMap);
> IgniteFuture resFut = asyncCache.future();
> Thread.sleep(1000);
> releaseLatch.countDown();
> fut.get();
> resFut.get();
> }
> finally {
> stopAllGrids();
> }
> {code}
> We should replace a recursive call with a simple iteration over the linked 
> list.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5947) ClassCastException when two-dimensional array is fetched from cache

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5947:

Fix Version/s: (was: 2.3)

> ClassCastException when two-dimensional array is fetched from cache
> ---
>
> Key: IGNITE-5947
> URL: https://issues.apache.org/jira/browse/IGNITE-5947
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.1
>Reporter: Valentin Kulichenko
>Assignee: Nikolay Tikhonov
>Priority: Critical
> Attachments: TestMain.java
>
>
> When an instance of {{Object[][]}} is put into cache, and then read from 
> there, the following exception is thrown:
> {noformat}
> Exception in thread "main" java.lang.ClassCastException: [Ljava.lang.Object; 
> cannot be cast to [[Ljava.lang.Object;
> {noformat}
> Reproducer attached.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5833) Change maven goal from "install" to "package" for building from sour

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5833:

Fix Version/s: (was: 2.3)

> Change maven goal from "install" to "package" for building from sour
> 
>
> Key: IGNITE-5833
> URL: https://issues.apache.org/jira/browse/IGNITE-5833
> Project: Ignite
>  Issue Type: Bug
>Reporter: Oleg Ostanin
>Assignee: Oleg Ostanin
>
> Currently we need to run 'mvn clean install' to build Apache Ignite from 
> sources, otherwise we can not perform javadoc generation in the next build 
> step in DEVNOTES.txt. We need to fix this issue before next release.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5270) Cassandra store should support binary objects with POJO strategy

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5270:

Fix Version/s: (was: 2.3)

> Cassandra store should support binary objects with POJO strategy
> 
>
> Key: IGNITE-5270
> URL: https://issues.apache.org/jira/browse/IGNITE-5270
> Project: Ignite
>  Issue Type: Improvement
>  Components: cassandra
>Affects Versions: 2.0
>Reporter: Valentin Kulichenko
>Assignee: Igor Rudyak
>
> Currently Cassandra store requires to have POJO classes on server nodes when 
> POJO strategy is used. We should improve it and allow to support binary 
> objects directly.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-4645) Best effort to avoid extra copying in binary marshaller

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4645:

Fix Version/s: (was: 2.3)

> Best effort to avoid extra copying in binary marshaller
> ---
>
> Key: IGNITE-4645
> URL: https://issues.apache.org/jira/browse/IGNITE-4645
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Reporter: Yakov Zhdanov
>Assignee: Igor Seliverstov
>
> If we marshal a class that contain only primitives then we can predict the 
> final byte array size and avoid copies to grow array and final trimming.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (IGNITE-6212) Assertion error: Invalid node2part

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-6212.
---

> Assertion error: Invalid node2part
> --
>
> Key: IGNITE-6212
> URL: https://issues.apache.org/jira/browse/IGNITE-6212
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Ilya Lantukh
>Assignee: Ilya Lantukh
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.3
>
>
> Reproduced by IgniteServiceDynamicCachesSelfTest with ~10% probability. Leads 
> to hang-up.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-3610) Implements RAMP transactions on top of Cassandra

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-3610:

Fix Version/s: (was: 2.3)

> Implements RAMP transactions on top of Cassandra
> 
>
> Key: IGNITE-3610
> URL: https://issues.apache.org/jira/browse/IGNITE-3610
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache
>Reporter: Igor Rudyak
>Assignee: Igor Rudyak
>
> Implement RAMP transaction (http://www.bailis.org/papers/ramp-sigmod2014.pdf) 
> to provide atomic read isolation for cache data modified withing transaction.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-2037) Update javadocs and documentation about LOCAL cache could be created on client node

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2037:

Fix Version/s: (was: 2.3)

> Update javadocs and documentation about LOCAL cache could be created on 
> client node
> ---
>
> Key: IGNITE-2037
> URL: https://issues.apache.org/jira/browse/IGNITE-2037
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: ignite-1.4
>Reporter: Alexey Kuznetsov
>Assignee: kcheng.mvp
>Priority: Trivial
>  Labels: newbie
>
> Code that show local cache on client node:
> {code}
> public class LocalCacheOnClient {
> public static void main(String[] args) throws IgniteException {
> IgniteConfiguration cfgSrv = new IgniteConfiguration();
> cfgSrv.setGridName("srv");
> Ignite n1 = Ignition.start(cfgSrv);
> IgniteConfiguration cfgClm = new IgniteConfiguration();
> cfgClm.setGridName("cln");
> cfgClm.setClientMode(true);
> Ignite n2 = Ignition.start(cfgClm);
> CacheConfiguration ccfg = new 
> CacheConfiguration<>("local");
> ccfg.setCacheMode(CacheMode.LOCAL);
> IgniteCache c = n2.getOrCreateCache(ccfg);
> c.put(1, 100);
> n1.close(); // stop server node
> c.put(2, 200); // local cache works fine.
> System.out.println(c.get(1));
> System.out.println(c.get(2));
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-4626) GridDhtPartitionTopologyImpl refactoring

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4626:

Fix Version/s: (was: 2.3)

> GridDhtPartitionTopologyImpl refactoring
> 
>
> Key: IGNITE-4626
> URL: https://issues.apache.org/jira/browse/IGNITE-4626
> Project: Ignite
>  Issue Type: Task
>Reporter: Konstantin Dudkov
>Assignee: Konstantin Dudkov
>
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl#nodes(int,
>  org.apache.ignite.internal.processors.affinity.AffinityTopologyVersion)
> Need to refactor this method to use Object[] - partId->List



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6248) Check Java 7 builds for compatibility with Ignite and update documentation

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6248:

Fix Version/s: (was: 2.3)

> Check Java 7 builds for compatibility with Ignite and update documentation
> --
>
> Key: IGNITE-6248
> URL: https://issues.apache.org/jira/browse/IGNITE-6248
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Evgenii Zhuravlev
>Assignee: Dmitry Karachentsev
>  Labels: usability
>
> According to these threads on SO and user list, some old Java 7 versions 
> doesn't compatible with Ignite since version 2.1 anymore:
> http://apache-ignite-users.70518.x6.nabble.com/Caused-by-org-h2-jdbc-JdbcSQLException-General-error-quot-java-lang-IllegalMonitorStateException-Attt-td15684.html
> https://stackoverflow.com/questions/45911616/datastreamer-does-not-work-well/45972341#45972341



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5564) Race between read-through and topology version update

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5564:

Fix Version/s: (was: 2.3)

> Race between read-through and topology version update
> -
>
> Key: IGNITE-5564
> URL: https://issues.apache.org/jira/browse/IGNITE-5564
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.7
>Reporter: Alexey Goncharuk
>Assignee: Dmitry Karachentsev
> Attachments: GridCachePartitionEvictionDuringReadThroughSelfTest.java
>
>
> I occasionally observe the following assertions when working with ATOMIC 
> cache with cache store on changing topology:
> {code}
> java.lang.AssertionError: Invalid version for inner update [isNew=false, 
> entry=GridDhtAtomicCacheEntry [super=GridDhtCacheEntry [rdrs=[], 
> locPart=GridDhtLocalPartition [id=157, 
> map=org.apache.ignite.internal.processors.cache.GridCacheConcurrentMapImpl@7a99d0af,
>  rmvQueue=GridCircularBuffer [sizeMask=31, idxGen=0], cntr=8, 
> shouldBeRenting=false, state=OWNING, reservations=0, empty=false, 
> createTime=06/21/2017 09:59:03], super=GridDistributedCacheEntry 
> [super=GridCacheMapEntry [key=KeyCacheObjectImpl [val=1181, 
> hasValBytes=true], val=CacheObjectImpl [val=1181, hasValBytes=true], 
> startVer=1498028394357, ver=GridCacheVersion [topVer=109508344, 
> time=1498028344708, order=1498028394358, nodeOrder=1], hash=1181, 
> extras=GridCacheTtlEntryExtras [ttl=6, expireTime=1498028404707], 
> flags=0, newVer=GridCacheVersion [topVer=109508343, time=1498028344709, 
> order=1498028394369, nodeOrder=1]]
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2311)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2485)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1887)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1727)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.mapSingle(GridNearAtomicAbstractUpdateFuture.java:264)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:494)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:436)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:209)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1242)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:675)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2294)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearAtomicCache.put(GridNearAtomicCache.java:437)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2271)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.put(IgniteCacheProxy.java:1379)
> {code}
> The assertion happens because there is a race between these events:
> 1) An update is mapped on topology version N
> 2) Topology version changes and discovery updates the version to N+1, but the 
> event is not yet processed by the exchange future
> 3) A read-through request comes in and performs the read. Inside 
> {{versionedValue()}} call a new entry version is generated. Since the 
> discovery version is already updated, the new entry version is based on 
> topVer=N+1
> 4) Update request proceeds and read-locks the topology. Since the exchange 
> future is not yet initialized, the request does not attempt to remap and 
> proceeds with version N
> 5) The next entry version is generated using request topology version = N
> 6) Inside the entry update method, we assert that new version is greater than 
> old version, but it's not the case in this scenario, and assertion fails
> Attached is a test reproducing the issue (see 
> testConcurrentReadThroughUpdate())



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6447) Web console: the panel with text 'Demo mode' hides buttons on Query screen

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6447:

Fix Version/s: (was: 2.3)

> Web console: the panel with text 'Demo mode' hides buttons on Query screen
> --
>
> Key: IGNITE-6447
> URL: https://issues.apache.org/jira/browse/IGNITE-6447
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Dmitriy Shabalin
> Attachments: screenshot-1.png
>
>
> !screenshot-1.png!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5518) Rework test on join active/inactive node

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5518:

Fix Version/s: (was: 2.3)

> Rework test on join active/inactive node 
> -
>
> Key: IGNITE-5518
> URL: https://issues.apache.org/jira/browse/IGNITE-5518
> Project: Ignite
>  Issue Type: Task
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-4159) Cloud Native Deployment of Apache Ignite using Kubernetes

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4159:

Fix Version/s: (was: 2.3)

> Cloud Native Deployment of Apache Ignite using Kubernetes
> -
>
> Key: IGNITE-4159
> URL: https://issues.apache.org/jira/browse/IGNITE-4159
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Denis Magda
>Assignee: Denis Magda
>
> Kubernetes is an open-source system for automating deployment, scaling, and 
> management of containerized applications.
> http://kubernetes.io
> Apache Ignite perfectly fits the concepts implemented in Kubernetes which may 
> greatly simplify and automate the maintenance and scaling of Apache Ignite 
> clusters running under the supervision of Kubernetes.
> Ignite won't be the first distributed storage that supports Kubernetes. There 
> are already a number of existed ones that being used:
> https://github.com/kubernetes/kubernetes/tree/master/examples/storage/cassandra
> https://github.com/pires/hazelcast-kubernetes
> https://www.mongodb.com/blog/post/running-mongodb-as-a-microservice-with-docker-and-kubernetes
> This is an umbrella ticket that incorporates all the works that have to be 
> done before Ignite officially claims that it can be launched under Kubernetes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6339) WAL: Avoid closed by interruption exception when user thread is interrupted

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6339:

Fix Version/s: (was: 2.3)

> WAL: Avoid closed by interruption exception when user thread is interrupted
> ---
>
> Key: IGNITE-6339
> URL: https://issues.apache.org/jira/browse/IGNITE-6339
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Andrey Gura
>Assignee: Andrey Gura
>
> We should have a separate writer thread for WAL that will write completed 
> serialized chunks of data. This will allow us avoid closed by interruption 
> exception when user thread is interrupted.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5539) MemoryMetrics.getTotalAllocatedPages return 0 when persistence is enabled

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5539:

Fix Version/s: (was: 2.3)

> MemoryMetrics.getTotalAllocatedPages return 0 when persistence is enabled
> -
>
> Key: IGNITE-5539
> URL: https://issues.apache.org/jira/browse/IGNITE-5539
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Alexey Kuznetsov
>Assignee: Sergey Chugunov
>
> In memory only mode metrics show some not zero values.
> With persistence it shows zero.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6234) [Test failure] GridCacheClientModesTcpClientDiscoveryAbstractTest$CaseNearReplicatedTransactional.testGetFromClientNode

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6234:

Fix Version/s: (was: 2.3)

> [Test failure] 
> GridCacheClientModesTcpClientDiscoveryAbstractTest$CaseNearReplicatedTransactional.testGetFromClientNode
> ---
>
> Key: IGNITE-6234
> URL: https://issues.apache.org/jira/browse/IGNITE-6234
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>  Labels: MakeTeamcityGreenAgain
>
> Test reproducible locally although with a very low probability. 
> I wasn't able to reproduce it starting test in isolation but managed to do it 
> starting *GridCacheClientModesTcpClientDiscoveryAbstractTest* 50 times in a 
> row observing from 1 to 3 failures.
> Test run with failed test is available 
> [here|https://ci.ignite.apache.org/viewLog.html?buildId=798538=buildResultsDiv=Ignite20Tests_IgniteCache].
> It seems that when client requests value of custom class from near cache it 
> may see BinaryMetadata for this class with no schema.
> Test fails with the following exception:
> {noformat}
> java.lang.NullPointerException: null
> at 
> org.apache.ignite.internal.binary.BinaryMetadata.hasSchema(BinaryMetadata.java:189)
> at 
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.metadata(CacheObjectBinaryProcessorImpl.java:517)
> at 
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$2.metadata(CacheObjectBinaryProcessorImpl.java:185)
> at 
> org.apache.ignite.internal.binary.BinaryContext.metadata(BinaryContext.java:1237)
> at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.getOrCreateSchema(BinaryReaderExImpl.java:2005)
> at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:284)
> at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:183)
> at 
> org.apache.ignite.internal.binary.BinaryObjectImpl.reader(BinaryObjectImpl.java:830)
> at 
> org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:794)
> at 
> org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:143)
> at 
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinary(CacheObjectUtils.java:161)
> at 
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinaryIfNeeded(CacheObjectUtils.java:41)
> at 
> org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:125)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1734)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheContext.addResult(GridCacheContext.java:1889)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheContext.addResult(GridCacheContext.java:1828)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearGetFuture.loadEntries(GridNearGetFuture.java:752)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearGetFuture.access$000(GridNearGetFuture.java:68)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearGetFuture$MiniFuture.onResult(GridNearGetFuture.java:1012)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearGetFuture.onResult(GridNearGetFuture.java:215)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearCacheAdapter.processGetResponse(GridNearCacheAdapter.java:294)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTransactionalCache$1.apply(GridNearTransactionalCache.java:92)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTransactionalCache$1.apply(GridNearTransactionalCache.java:90)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1060)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
> at 
> 

[jira] [Updated] (IGNITE-4378) Affinity function should support assigning partition to subset of cluster nodes

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4378:

Fix Version/s: (was: 2.3)

> Affinity function should support assigning partition to subset of cluster 
> nodes
> ---
>
> Key: IGNITE-4378
> URL: https://issues.apache.org/jira/browse/IGNITE-4378
> Project: Ignite
>  Issue Type: New Feature
>  Components: cache
>Reporter: Dmitriy Setrakyan
>Assignee: Alexei Scherbakov
>
> Currently both default affinity function(AF) implementations randomly choose 
> primary node among all topology nodes.
> This may not be enough to handle complex data placement scenarios without 
> implementing own AF.
> On example, some partitions can be assigned to more powerful hardware, or 
> limited to subset of cluster nodes due to ease of management or fault 
> tolerance scenarios.
> We should implement node filter, which will allow to choose subset of cluster 
> nodes to place primary and backup partitions.
> With already existing ability to filter backup nodes (using 
> {{AffinityBackupFilter}}) it will allow to implement different approaches to 
> data placement with Ignite without resorting to custom AF.
> It's also desirable to include a practical example of both topology filters 
> based on node attribute values.
> Proposed primary filter interface is below.
> {noformat}
> /**
>  * Allows partition placement to subset of cluster node.
>  *
>  * Backup nodes also will be assigned from the subset.
>  */
> public interface AffinityPrimaryFilter extends IgniteBiClosure List, List> {
> /**
>  * Return nodes allowed to contain given partition.
>  * @param partition Partition.
>  * @param currentTopologyNodes All nodes from current topology.
>  * @return Subset of nodes.
>  */
> @Override public List apply(Integer partition, 
> List currentTopologyNodes);
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-2656) Documentation on debugging and fixing the reasons of node disconnection from the cluster

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2656:

Labels:   (was: documentation)

> Documentation on debugging and fixing the reasons of node disconnection from 
> the cluster
> 
>
> Key: IGNITE-2656
> URL: https://issues.apache.org/jira/browse/IGNITE-2656
> Project: Ignite
>  Issue Type: Bug
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Minor
> Fix For: 2.3
>
>
> Sometimes a node can be abruptly kicked off from the cluster buy some reason.
> The documentation must contain information on how to get to the root of the 
> issue by looking at logs files. Usually the node that was kicked off contains 
> "Local node segmented" message and the node that failed its next neighbor 
> contains a message with more details "Failed to send message to next node".
> Next the article must list possible reasons of the disconnection:
> - long GC pauses. Give recommendations on how to check;
> - high node utilization so that it responds with a delay;
> - low network configuration parameters that are not suited for an environment;
> There should be a section about 
> {{IgniteConfiguration.failureDetectionTimeout}} describing its behavior and 
> showing all its pros and cons.
> The article must say when it makes sense to 'disable' this timeout by 
> switching to explicit configuration of TcpDiscoverySpi.socketTimeout, 
> TcpDiscoverySpi.ackTimeout, TcpDiscoverySpi.maxAckTimeout, 
> TcpDiscoverySpi.reconnectCount. Pros and cons of manual configuration has to 
> be mentioned as well.
>   
> Also I would list the usage of TcpDiscoverySpi.joinTimeout,
> TcpDiscoverySpi.networkTimeout (used on client reconnect, servers waits for 
> join result, node stop, socket reader first message.) there as well.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-4554) Optimize integer sets.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4554:

Fix Version/s: (was: 2.3)

> Optimize integer sets.
> --
>
> Key: IGNITE-4554
> URL: https://issues.apache.org/jira/browse/IGNITE-4554
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.6
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
>
> Ignite has many uses of data structures like Set, IntArray etc.
> This is not most efficient way to represent integer sets. The best way is to 
> use compressed bit sets. This should save a lot of heap space.
> We should optimize integer sets whenever possible.
> The most obvious place to start is GridAffinityAssignment.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-2656) Documentation on debugging and fixing the reasons of node disconnection from the cluster

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2656:

Labels: documentation  (was: )

> Documentation on debugging and fixing the reasons of node disconnection from 
> the cluster
> 
>
> Key: IGNITE-2656
> URL: https://issues.apache.org/jira/browse/IGNITE-2656
> Project: Ignite
>  Issue Type: Bug
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Minor
> Fix For: 2.3
>
>
> Sometimes a node can be abruptly kicked off from the cluster buy some reason.
> The documentation must contain information on how to get to the root of the 
> issue by looking at logs files. Usually the node that was kicked off contains 
> "Local node segmented" message and the node that failed its next neighbor 
> contains a message with more details "Failed to send message to next node".
> Next the article must list possible reasons of the disconnection:
> - long GC pauses. Give recommendations on how to check;
> - high node utilization so that it responds with a delay;
> - low network configuration parameters that are not suited for an environment;
> There should be a section about 
> {{IgniteConfiguration.failureDetectionTimeout}} describing its behavior and 
> showing all its pros and cons.
> The article must say when it makes sense to 'disable' this timeout by 
> switching to explicit configuration of TcpDiscoverySpi.socketTimeout, 
> TcpDiscoverySpi.ackTimeout, TcpDiscoverySpi.maxAckTimeout, 
> TcpDiscoverySpi.reconnectCount. Pros and cons of manual configuration has to 
> be mentioned as well.
>   
> Also I would list the usage of TcpDiscoverySpi.joinTimeout,
> TcpDiscoverySpi.networkTimeout (used on client reconnect, servers waits for 
> join result, node stop, socket reader first message.) there as well.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-2656) Documentation on debugging and fixing the reasons of node disconnection from the cluster

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2656:

Component/s: documentation

> Documentation on debugging and fixing the reasons of node disconnection from 
> the cluster
> 
>
> Key: IGNITE-2656
> URL: https://issues.apache.org/jira/browse/IGNITE-2656
> Project: Ignite
>  Issue Type: Bug
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Minor
> Fix For: 2.3
>
>
> Sometimes a node can be abruptly kicked off from the cluster buy some reason.
> The documentation must contain information on how to get to the root of the 
> issue by looking at logs files. Usually the node that was kicked off contains 
> "Local node segmented" message and the node that failed its next neighbor 
> contains a message with more details "Failed to send message to next node".
> Next the article must list possible reasons of the disconnection:
> - long GC pauses. Give recommendations on how to check;
> - high node utilization so that it responds with a delay;
> - low network configuration parameters that are not suited for an environment;
> There should be a section about 
> {{IgniteConfiguration.failureDetectionTimeout}} describing its behavior and 
> showing all its pros and cons.
> The article must say when it makes sense to 'disable' this timeout by 
> switching to explicit configuration of TcpDiscoverySpi.socketTimeout, 
> TcpDiscoverySpi.ackTimeout, TcpDiscoverySpi.maxAckTimeout, 
> TcpDiscoverySpi.reconnectCount. Pros and cons of manual configuration has to 
> be mentioned as well.
>   
> Also I would list the usage of TcpDiscoverySpi.joinTimeout,
> TcpDiscoverySpi.networkTimeout (used on client reconnect, servers waits for 
> join result, node stop, socket reader first message.) there as well.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-4773) Web Console: Create New Design Concept

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4773:

Fix Version/s: (was: 2.3)
   2.4

> Web Console: Create New Design Concept
> --
>
> Key: IGNITE-4773
> URL: https://issues.apache.org/jira/browse/IGNITE-4773
> Project: Ignite
>  Issue Type: Improvement
>  Components: UI, wizards
>Reporter: Vica Abramova
>Assignee: Vica Abramova
> Fix For: 2.4
>
>
> Don't forget to support multi-clustering.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5038) BinaryMarshaller might need to use context class loader for deserialization

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5038:

Fix Version/s: (was: 2.3)

> BinaryMarshaller might need to use context class loader for deserialization
> ---
>
> Key: IGNITE-5038
> URL: https://issues.apache.org/jira/browse/IGNITE-5038
> Project: Ignite
>  Issue Type: Improvement
>  Components: binary
>Affects Versions: 2.0
>Reporter: Dmitry Karachentsev
>Assignee: Vladimir Ozerov
>  Labels: features
> Attachments: results-compound-20170802.zip, 
> results-compound-20170808.zip
>
>
> There is a special use case discussed on the dev list:
> http://apache-ignite-developers.2346864.n4.nabble.com/Re-BinaryObjectImpl-deserializeValue-with-specific-ClassLoader-td17126.html#a17224
> According to the use case, BinaryMarshaller might need to try to deserialize 
> an object using a context class loader if it failed to do so with a custom 
> classloader (`IgniteConfiguration.getClassLoader()`) or the system one.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6343) Index is not used properly if changing sort order.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6343:

Fix Version/s: (was: 2.3)

> Index is not used properly if changing sort order.
> --
>
> Key: IGNITE-6343
> URL: https://issues.apache.org/jira/browse/IGNITE-6343
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.0
>Reporter: Alexei Scherbakov
>  Labels: performance
>
> Unit test reproducer:
> {noformat}
> /*
>  * Licensed to the Apache Software Foundation (ASF) under one or more
>  * contributor license agreements.  See the NOTICE file distributed with
>  * this work for additional information regarding copyright ownership.
>  * The ASF licenses this file to You under the Apache License, Version 2.0
>  * (the "License"); you may not use this file except in compliance with
>  * the License.  You may obtain a copy of the License at
>  *
>  *  http://www.apache.org/licenses/LICENSE-2.0
>  *
>  * Unless required by applicable law or agreed to in writing, software
>  * distributed under the License is distributed on an "AS IS" BASIS,
>  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
>  * See the License for the specific language governing permissions and
>  * limitations under the License.
>  */
> package org.apache.ignite.internal.processors.cache;
> import java.util.Calendar;
> import java.util.Collections;
> import java.util.Date;
> import java.util.LinkedHashMap;
> import java.util.List;
> import org.apache.ignite.IgniteCache;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.cache.QueryEntity;
> import org.apache.ignite.cache.QueryIndex;
> import org.apache.ignite.cache.QueryIndexType;
> import org.apache.ignite.cache.query.SqlFieldsQuery;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.configuration.MemoryConfiguration;
> import org.apache.ignite.configuration.MemoryPolicyConfiguration;
> import org.apache.ignite.internal.util.typedef.internal.U;
> import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.TcpDiscoveryIpFinder;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
> import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
> import static org.apache.ignite.cache.CacheMode.PARTITIONED;
> import static org.apache.ignite.cache.CacheWriteSynchronizationMode.FULL_SYNC;
> import static java.util.Calendar.*;
> /**
>  * Tests for cache query results serialization.
>  */
> public class GridCacheQueryIndexUsageSelfTest extends GridCommonAbstractTest {
> /** */
> private static final int GRID_CNT = 1;
> /** */
> private static final String CACHE_NAME = "A";
> /** */
> private static final CacheMode CACHE_MODE = PARTITIONED;
> /** */
> private static TcpDiscoveryIpFinder ipFinder = new 
> TcpDiscoveryVmIpFinder(true);
> /** {@inheritDoc} */
> @Override protected void beforeTest() throws Exception {
> startGridsMultiThreaded(GRID_CNT);
> }
> /** {@inheritDoc} */
> @Override protected void afterTest() throws Exception {
> stopAllGrids();
> }
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String 
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> MemoryPolicyConfiguration mpcfg = new MemoryPolicyConfiguration();
> //mpcfg.setMaxSize(2 * 1024 * 1024 * 1024L);
> mpcfg.setName("def");
> MemoryConfiguration mcfg = new MemoryConfiguration();
> mcfg.setDefaultMemoryPolicyName("def");
> mcfg.setMemoryPolicies(mpcfg);
> cfg.setMemoryConfiguration(mcfg);
> TcpDiscoverySpi disco = new TcpDiscoverySpi();
> disco.setIpFinder(ipFinder);
> cfg.setDiscoverySpi(disco);
> CacheConfiguration cacheCfg = defaultCacheConfiguration();
> cacheCfg.setName(CACHE_NAME);
> cacheCfg.setCacheMode(CACHE_MODE);
> cacheCfg.setWriteSynchronizationMode(FULL_SYNC);
> QueryEntity qe = new QueryEntity();
> qe.setKeyType(Long.class.getName());
> qe.setValueType(IndexedValue.class.getName());
> LinkedHashMap fields = U.newLinkedHashMap(3);
> fields.put("id", Long.class.getName());
> fields.put("startDate", Date.class.getName());
> qe.setFields(fields);
> QueryIndex idx = new QueryIndex();
> idx.setIndexType(QueryIndexType.SORTED);
> LinkedHashMap idxFields = U.newLinkedHashMap(3);
> 

[jira] [Updated] (IGNITE-4490) Optimize DML for fast INSERT and MERGE

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4490:

Fix Version/s: (was: 2.3)
   2.4

> Optimize DML for fast INSERT and MERGE
> --
>
> Key: IGNITE-4490
> URL: https://issues.apache.org/jira/browse/IGNITE-4490
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 1.8
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
>  Labels: performance
> Fix For: 2.4
>
>
> It's possible to avoid any SQL querying and map some INSERT and MERGE 
> statements to cache operations in a way similar to that of UPDATE and DELETE 
> - i.e. don't make queries when there are no expressions to evaluate in the 
> query and enhance update plans to perform direct cache operations when INSERT 
> and MERGE affect columns {{_key}} and {{_val}} only.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-4489) Maintain correct MERGE semantic in DML

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4489:

Fix Version/s: (was: 2.3)
   2.4

> Maintain correct MERGE semantic in DML
> --
>
> Key: IGNITE-4489
> URL: https://issues.apache.org/jira/browse/IGNITE-4489
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 1.8
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Fix For: 2.4
>
>
> Currently it's impossible to MERGE object in UPDATE style - i.e. when key is 
> present in cache, unaffected field values should be retained, and instead of 
> building new object we should base it on previous one for given key.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6092) Bulk Inserts are not Supported

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6092:

Fix Version/s: (was: 2.3)
   2.4

> Bulk Inserts are not Supported 
> ---
>
> Key: IGNITE-6092
> URL: https://issues.apache.org/jira/browse/IGNITE-6092
> Project: Ignite
>  Issue Type: New Feature
>Affects Versions: 2.1
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
>Priority: Critical
> Fix For: 2.4
>
>
> Presently the bulk inserts like these are not supported by Ignite's SQL 
> engine:
> {code}
> INSERT INTO City (id, name)
> VALUES (1, 'Forest Hill'),
>(2, "Denver"),
>(3, "St. Petersburg")
> INSERT INTO Person (id, name, city_id)
> VALUES (1, 'John Doe', 3),
>(2, "Jane Roe", 2),
>(3, "Mary Major", 1),
>(4, "Richard Miles", 2)
> {code}
> Let's plan to support them for the nearest release. I've used DBeaver tool to 
> validate the statements above:
> https://apacheignite-tools.readme.io/docs/dbeaver



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6059) Use any distributed matrix in K-Means

[Mikhail Lipkovich (JIRA)]

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

Mikhail Lipkovich commented on IGNITE-6059:
---

Thanks both of you for your comments. I will dive into it after my vacation

> Use any distributed matrix in K-Means
> -
>
> Key: IGNITE-6059
> URL: https://issues.apache.org/jira/browse/IGNITE-6059
> Project: Ignite
>  Issue Type: Improvement
>  Components: ml
>Reporter: Yury Babak
>
> Currently k-means work only with row/col matrix.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-5784) .NET: QueryIndex.InlineSize

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn reassigned IGNITE-5784:
--

Assignee: Pavel Tupitsyn

> .NET: QueryIndex.InlineSize
> ---
>
> Key: IGNITE-5784
> URL: https://issues.apache.org/jira/browse/IGNITE-5784
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> {{QueryIndex.InlineSize}} controls index payload when it is stored in Ignite 
> page memory.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6515) .NET: Enable persistence on per-cache basis

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-6515:
--

 Summary: .NET: Enable persistence on per-cache basis
 Key: IGNITE-6515
 URL: https://issues.apache.org/jira/browse/IGNITE-6515
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Affects Versions: 2.3
Reporter: Pavel Tupitsyn
 Fix For: 2.3


Propagate new configuration to .NET: IGNITE-6030



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5615) .NET: IgniteConfiguration.LocalEventListeners

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5615:


Github user asfgit closed the pull request at:

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


> .NET: IgniteConfiguration.LocalEventListeners
> -
>
> Key: IGNITE-5615
> URL: https://issues.apache.org/jira/browse/IGNITE-5615
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> Propagate {{IgniteConfiguration.LocalEventListeners}} to .NET. This allows 
> catching all events right from the node start.
> * Can we unsubscribe from these events later? Does Java support this?
> * What about GetEvents for a cluster group, how do we handle local listeners 
> in this case?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5615) .NET: IgniteConfiguration.LocalEventListeners

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-5615:


Merged to master: {{b364589dffcb57aa2297fd1f2862f16065d44701}}.

> .NET: IgniteConfiguration.LocalEventListeners
> -
>
> Key: IGNITE-5615
> URL: https://issues.apache.org/jira/browse/IGNITE-5615
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> Propagate {{IgniteConfiguration.LocalEventListeners}} to .NET. This allows 
> catching all events right from the node start.
> * Can we unsubscribe from these events later? Does Java support this?
> * What about GetEvents for a cluster group, how do we handle local listeners 
> in this case?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6422) In visorcmd "cache on nodes" statistics mixes together primary and backup entries

[Ilya Kasnacheev (JIRA)]

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

Ilya Kasnacheev commented on IGNITE-6422:
-

Looks OK to me!

> In visorcmd "cache on nodes" statistics mixes together primary and backup 
> entries
> -
>
> Key: IGNITE-6422
> URL: https://issues.apache.org/jira/browse/IGNITE-6422
> Project: Ignite
>  Issue Type: Bug
>  Components: visor
>Affects Versions: 2.3
>Reporter: Ilya Kasnacheev
>Assignee: Alexey Kuznetsov
>
> Suppose we have a cache, with 1000 entries, one backup and eviction after 500 
> entries. Then, off-heap entries are doubled in visorcmd, while on-heap 
> entries are not:
> {code}
> +-+
> | Name(@) | EmployeesCache(@c0)   |
> | Nodes   | 2 |
> | Total size Min/Avg/Max  | 1500 / 1500.00 / 1500 |
> |   Heap size Min/Avg/Max | 500 / 500.00 / 500|
> |   Off-heap size Min/Avg/Max | 1000 / 1000.00 / 1000 |
> +-+
> Nodes for: EmployeesCache(@c0)
> +=+
> |  Node ID8(@), IP  | CPUs | Heap Used | CPU Load |   Up Time|
>  Size | Hi/Mi/Rd/Wr |
> +=+
> | 37333BC6(@n0), 172.16.9.1 | 8| 4.47 %| 0.40 %   | 00:00:47:154 | 
> Total: 1500  | Hi: 0   |
> |   |  |   |  |  |   
> Heap: 500  | Mi: 0   |
> |   |  |   |  |  |   
> Off-Heap: 1000 | Rd: 0   |
> |   |  |   |  |  |   
> Off-Heap Memory: 0 | Wr: 0   |
> +---+--+---+--+--+--+-+
> | 26FD4343(@n1), 172.16.9.1 | 8| 3.09 %| 0.23 %   | 00:00:41:602 | 
> Total: 1500  | Hi: 0   |
> |   |  |   |  |  |   
> Heap: 500  | Mi: 0   |
> |   |  |   |  |  |   
> Off-Heap: 1000 | Rd: 0   |
> |   |  |   |  |  |   
> Off-Heap Memory: 0 | Wr: 0   |
> +-+
> 'Hi' - Number of cache hits.
> {code}
> By contrast, on 1.9 it looks like this:
> {code}
> Cache 'EmployeesCache(@c0)':
> +-+
> | Name(@) | EmployeesCache(@c0)   |
> | Nodes   | 2 |
> | Total size Min/Avg/Max  | 1000 / 1000.00 / 1000 |
> |   Heap size Min/Avg/Max | 500 / 500.00 / 500|
> |   Off-heap size Min/Avg/Max | 500 / 500.00 / 500|
> +-+
> Nodes for: EmployeesCache(@c0)
> ++
> |  Node ID8(@), IP  | CPUs | Heap Used | CPU Load |   Up Time|
>   Size   | Hi/Mi/Rd/Wr |
> ++
> | 3229FABE(@n0), 172.16.9.1 | 8| 1.25 %| 0.23 %   | 00:00:43:111 | 
> Total: 1000 | Hi: 0   |
> |   |  |   |  |  |   
> Heap: 500 | Mi: 0   |
> |   |  |   |  |  |   
> Off-Heap: 500 | Rd: 0   |
> |   |  |   |  |  |   
> Off-Heap Memory: 88kb | Wr: 0   |
> +---+--+---+--+--+-+-+
> | 58FA742B(@n1), 172.16.9.1 | 8| 1.15 %| 0.47 %   | 00:00:38:828 | 
> Total: 1000 | Hi: 0   |
> |   |  |   |  |  |   
> Heap: 500 | Mi: 0   |
> |   |  |   |  |  |   
> Off-Heap: 500 | Rd: 0   |
> |   |  |   |  |  |   
> Off-Heap Memory: 88kb | Wr: 0   |
> ++
> {code}
> NB: It 

[jira] [Resolved] (IGNITE-6514) Hide QueryEntity.notNullFields from public API

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk resolved IGNITE-6514.
--
Resolution: Fixed

> Hide QueryEntity.notNullFields from public API
> --
>
> Key: IGNITE-6514
> URL: https://issues.apache.org/jira/browse/IGNITE-6514
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
> Fix For: 2.3
>
>
> The QueryEntity class already became too overloaded, so we need to hide this 
> from public API for now until a better approach is developed



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6514) Hide QueryEntity.notNullFields from public API

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-6514:


 Summary: Hide QueryEntity.notNullFields from public API
 Key: IGNITE-6514
 URL: https://issues.apache.org/jira/browse/IGNITE-6514
 Project: Ignite
  Issue Type: Improvement
  Components: cache
Reporter: Alexey Goncharuk
Assignee: Alexey Goncharuk
 Fix For: 2.3


The QueryEntity class already became too overloaded, so we need to hide this 
from public API for now until a better approach is developed



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6513) Add ability manage version of WAL serializer via system properties

[Dmitriy Govorukhin (JIRA)]

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

Dmitriy Govorukhin updated IGNITE-6513:
---
Summary: Add ability manage version of WAL serializer via system properties 
 (was: Add ability manage version for WAL serializer via system properties)

> Add ability manage version of WAL serializer via system properties
> --
>
> Key: IGNITE-6513
> URL: https://issues.apache.org/jira/browse/IGNITE-6513
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.0, 2.1, 2.2, 2.3
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
> Fix For: 2.4
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-5439) JDBC thin: support query cancel

[Taras Ledkov (JIRA)]

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

Taras Ledkov edited comment on IGNITE-5439 at 9/27/17 2:46 PM:
---

[~vozerov], 
*1-3*. Are fixed.
4. I guess if we use vendor error code for a specific case it is better than 
generic error usage. I cannot see the SQLSTATE corresponds to query 
cancellation at the SQL-99. But e.g.: mysql use {{70100}} SQLSTATE code for 
this case.

[Tests|https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=projectOverview_Ignite20Tests=pull%2F2436%2Fhead]
 are OK. Please review the changes.


was (Author: tledkov-gridgain):
[~vozerov], 
*1-3*. Are fixed.
4. I guess if we use vendor error code for a specific case it is better than 
generic error usage. I cannot see the SQLSTATE corresponds to query 
cancellation at the SQL-99. But e.g.: mysql use {{70100}} SQLSTATE code for 
this case.

> JDBC thin: support query cancel
> ---
>
> Key: IGNITE-5439
> URL: https://issues.apache.org/jira/browse/IGNITE-5439
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc
>Affects Versions: 2.0
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.3
>
>
> The JDBC {{Statement.cancel}} method must be supported.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6069) Service versioning

[Michael Griggs (JIRA)]

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

Michael Griggs commented on IGNITE-6069:


>all service instances with the same name must have the same version

I think this ticket is a good opportunity to have multiple versions of a 
service available in the cluster at the same time.  By default requests would 
go to the latest version, but earlier versions could be requested by adding a 
parameter to the `serviceProxy()` method.  The service version could be better 
indicated using an attribute on the service implementation, rather than using 
serialVersionUuid.

> Service versioning
> --
>
> Key: IGNITE-6069
> URL: https://issues.apache.org/jira/browse/IGNITE-6069
> Project: Ignite
>  Issue Type: New Feature
>  Components: general
>Affects Versions: 2.1
>Reporter: Ilya Lantukh
>Assignee: Ilya Lantukh
>
> Make services upgradable -again-. 
> Main points:
> - compute binary type ID by (classname + version)
> - use serialVersionUuid as version ( ?)
> - all service instances with the same name must have the same version
> - make ServiceProxy aware of versions and upgrade process, pause requests 
> while service is being upgraded
> - extend Service interface (UpgradableService?) - add ability to collect 
> state of previous version before start.
> Once the feature is implemented, it has to be documented extensively. The 
> ticket must not be closed until this happens.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-5439) JDBC thin: support query cancel

[Taras Ledkov (JIRA)]

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

Taras Ledkov edited comment on IGNITE-5439 at 9/27/17 1:39 PM:
---

[~vozerov], 
*1-3*. Are fixed.
4. I guess if we use vendor error code for a specific case it is better than 
generic error usage. I cannot see the SQLSTATE corresponds to query 
cancellation at the SQL-99. But e.g.: mysql use {{70100}} SQLSTATE code for 
this case.


was (Author: tledkov-gridgain):
[~vozerov], 
*1-3*. Are fixed.
4. I guess if we use vendor error code for a specific case it is better than 
use generic error. I cannot see the SQLSTATE corresponds to query cancellation 
at the SQL-99. But e.g.: mysql use {{70100}} SQLSTATE code for this case.

> JDBC thin: support query cancel
> ---
>
> Key: IGNITE-5439
> URL: https://issues.apache.org/jira/browse/IGNITE-5439
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc
>Affects Versions: 2.0
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.3
>
>
> The JDBC {{Statement.cancel}} method must be supported.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-5439) JDBC thin: support query cancel

[Taras Ledkov (JIRA)]

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

Taras Ledkov edited comment on IGNITE-5439 at 9/27/17 1:39 PM:
---

[~vozerov], 
*1-3*. Are fixed.
4. I guess if we use vendor error code for a specific case it is better than 
use generic error. I cannot see the SQLSTATE corresponds to query cancellation 
at the SQL-99. But e.g.: mysql use {{70100}} SQLSTATE code for this case.


was (Author: tledkov-gridgain):
[~vozerov], 
*1-3*. Are fixed.
4. I guess if we use vendor error code for a specific case better than use 
generic error. I cannot see the SQLSTATE corresponds to query cancellation at 
the SQL-99. But e.g.: mysql use {{70100}} SQLSTATE code for this case.

> JDBC thin: support query cancel
> ---
>
> Key: IGNITE-5439
> URL: https://issues.apache.org/jira/browse/IGNITE-5439
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc
>Affects Versions: 2.0
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.3
>
>
> The JDBC {{Statement.cancel}} method must be supported.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5439) JDBC thin: support query cancel

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-5439:
--

[~vozerov], 
*1-3*. Are fixed.
4. I guess if we use vendor error code for a specific case better than use 
generic error. I cannot see the SQLSTATE corresponds to query cancellation at 
the SQL-99. But e.g.: mysql use {{70100}} SQLSTATE code for this case.

> JDBC thin: support query cancel
> ---
>
> Key: IGNITE-5439
> URL: https://issues.apache.org/jira/browse/IGNITE-5439
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc
>Affects Versions: 2.0
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.3
>
>
> The JDBC {{Statement.cancel}} method must be supported.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6512) Need a possibility to start caches without discarding their 'restarting' state

[Eduard Shangareev (JIRA)]

Eduard Shangareev created IGNITE-6512:
-

 Summary: Need a possibility to start caches without discarding 
their 'restarting' state
 Key: IGNITE-6512
 URL: https://issues.apache.org/jira/browse/IGNITE-6512
 Project: Ignite
  Issue Type: Improvement
Reporter: Eduard Shangareev


Now we always discard restarting state on cache while it is starting.
But sometimes we need extra steps before making caches available from public 
API.

So, I suggest adding a new method which would be called when we want to make 
caches available for public API clients.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5713) The ignite-spring module should not rely on the ignite-indexing module.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5713:


GitHub user devozerov opened a pull request:

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

IGNITE-5713



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

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

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

https://github.com/apache/ignite/pull/2763.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 #2763


commit 34ec1d24d67f7429693477d96fa9293393b8ed97
Author: devozerov 
Date:   2017-09-27T12:41:48Z

IGNITE-5713: Removed dependency in ignite-indexing.




> The ignite-spring module should not rely on the ignite-indexing module.
> ---
>
> Key: IGNITE-5713
> URL: https://issues.apache.org/jira/browse/IGNITE-5713
> Project: Ignite
>  Issue Type: Improvement
>  Components: spring
>Affects Versions: 2.0
>Reporter: Yujue Li
>Assignee: Vladimir Ozerov
>Priority: Minor
> Fix For: 2.3
>
>
> In version 2.0, the ignite-spring module has increased reliance on the 
> ignite-indexing module, which is not appropriate.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-5713) The ignite-spring module should not rely on the ignite-indexing module.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-5713:
---

Assignee: Vladimir Ozerov

> The ignite-spring module should not rely on the ignite-indexing module.
> ---
>
> Key: IGNITE-5713
> URL: https://issues.apache.org/jira/browse/IGNITE-5713
> Project: Ignite
>  Issue Type: Improvement
>  Components: spring
>Affects Versions: 2.0
>Reporter: Yujue Li
>Assignee: Vladimir Ozerov
>Priority: Minor
> Fix For: 2.3
>
>
> In version 2.0, the ignite-spring module has increased reliance on the 
> ignite-indexing module, which is not appropriate.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5713) The ignite-spring module should not rely on the ignite-indexing module.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-5713:
-

Added as a part of {{03183a9abd830d9d15a26e773a4d95b841f6d8c3}} commit. No 
apparent reason for this.

> The ignite-spring module should not rely on the ignite-indexing module.
> ---
>
> Key: IGNITE-5713
> URL: https://issues.apache.org/jira/browse/IGNITE-5713
> Project: Ignite
>  Issue Type: Improvement
>  Components: spring
>Affects Versions: 2.0
>Reporter: Yujue Li
>Priority: Minor
> Fix For: 2.3
>
>
> In version 2.0, the ignite-spring module has increased reliance on the 
> ignite-indexing module, which is not appropriate.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5347) Document enums usage in SQL queries

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5347:

Fix Version/s: (was: 2.3)

> Document enums usage in SQL queries
> ---
>
> Key: IGNITE-5347
> URL: https://issues.apache.org/jira/browse/IGNITE-5347
> Project: Ignite
>  Issue Type: Task
>Reporter: Denis Magda
>Assignee: Denis Magda
>
> Here is a documentation to be added to this page 
> (https://apacheignite.readme.io/v2.0/docs/distributed-queries-21):
> If a field is of a Java enum type, then you can pass the field's value as a 
> parameter via standard `?` keyword or use enum's literal or ordinal value 
> directly, as shown in the example below:
> // SQL query with the field of Java enum type.
> SqlFieldsQuery sql = new SqlFieldsQuery(
> "SELECT name FROM Person WHERE role = 'DEVELOPER' or role = 2");



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-3939) Compact NULL values binary representation

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-3939:

Fix Version/s: (was: 2.3)

> Compact NULL values binary representation
> -
>
> Key: IGNITE-3939
> URL: https://issues.apache.org/jira/browse/IGNITE-3939
> Project: Ignite
>  Issue Type: Improvement
>  Components: binary
>Affects Versions: 1.7
>Reporter: Andrew Mashenkov
>Assignee: Taras Ledkov
>  Labels: iep-2, performance
>
> We can use separate type for Long zero values and exclude 8-byte value from 
> binary representation. This will reduce memory footprint and network load.
> Compatibility with previous versions MUST be preserved.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6511) ODBC: SQLGetDiagRec doesn't follow specification when buffer size is too small

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov commented on IGNITE-6511:


Workaround: check resulting error message length (reallen > 0) before 
manipulation with the error message pointer.

Reproducer:

{quote}
BOOST_AUTO_TEST_CASE(TestLongErrorMessage)
{
StartAdditionalNode("Node1");

Connect("DRIVER={Apache Ignite};ADDRESS=127.0.0.1:0;SCHEMA=PUBLIC");

SQLCHAR req[] = "DROP INDEX Nonexisting";

SQLRETURN ret;

ret = SQLExecDirect(stmt, req, SQL_NTS);

BOOST_REQUIRE_EQUAL(ret, SQL_ERROR);

SQLCHAR sqlstate[7] = {};
SQLINTEGER nativeCode;

SQLCHAR message[10];
SQLSMALLINT reallen = 0;

SQLGetDiagRec(SQL_HANDLE_STMT, stmt, 1, sqlstate, , message, 
sizeof(message), );

BOOST_CHECK_EQUAL(reallen, sizeof(message));
}
{quote}

> ODBC: SQLGetDiagRec doesn't follow specification when buffer size is too small
> --
>
> Key: IGNITE-6511
> URL: https://issues.apache.org/jira/browse/IGNITE-6511
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Reporter: Sergey Kalashnikov
>  Labels: usability
>
> When buffer size provided for error message is not big enough to hold the 
> entire error message, the function {{SqlGetDiagRec()}} returns wrong 
> resulting string length (-4) and wrong result code ({{SQL_SUCCESS}} instead 
> of {{SQL_SUCCESS_WITH_INFO}}).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6511) ODBC: SQLGetDiagRec doesn't follow specification when buffer size is too small

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6511:

Fix Version/s: (was: 2.3)

> ODBC: SQLGetDiagRec doesn't follow specification when buffer size is too small
> --
>
> Key: IGNITE-6511
> URL: https://issues.apache.org/jira/browse/IGNITE-6511
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Reporter: Sergey Kalashnikov
>  Labels: usability
>
> When buffer size provided for error message is not big enough to hold the 
> entire error message, the function {{SqlGetDiagRec()}} returns wrong 
> resulting string length (-4) and wrong result code ({{SQL_SUCCESS}} instead 
> of {{SQL_SUCCESS_WITH_INFO}}).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6511) ODBC: SQLGetDiagRec doesn't follow specification when buffer size is too small

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-6511:

Fix Version/s: 2.3

> ODBC: SQLGetDiagRec doesn't follow specification when buffer size is too small
> --
>
> Key: IGNITE-6511
> URL: https://issues.apache.org/jira/browse/IGNITE-6511
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Reporter: Sergey Kalashnikov
>  Labels: usability
> Fix For: 2.3
>
>
> When buffer size provided for error message is not big enough to hold the 
> entire error message, the function {{SqlGetDiagRec()}} returns wrong 
> resulting string length (-4) and wrong result code ({{SQL_SUCCESS}} instead 
> of {{SQL_SUCCESS_WITH_INFO}}).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-5439) JDBC thin: support query cancel

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov edited comment on IGNITE-5439 at 9/27/17 12:14 PM:
---

[~tledkov-gridgain],
1) JdbcThinConnection.sendRequestThroughNewConnection - do we close new IO?
2) Using (connection ID + query ID) might be not very good idea, because 
malicious client might start closing cursors of other clients - they are very 
easy to guess. May be we should think on adding a kind of UUID to connection ID.
3) JdbcThinConnection.QRY_ID_GEN - you cannot rely on {{currentQUeryId}}, as it 
might be advanced by other opened statements. You should generate ID only once 
and then pass it to statement.
4) New {{IgniteQueryErrorCode.QUERY_CANCELED}} is added, but I do not see if it 
mapped to any SQLSTATE. So what is the point of this vendor-specific code?


was (Author: vozerov):
1) JdbcThinConnection.sendRequestThroughNewConnection - do we close new IO?
2) Using (connection ID + query ID) might be not very good idea, because 
malicious client might start closing cursors of other clients - they are very 
easy to guess. May be we should think on adding a kind of UUID to connection ID.
3) JdbcThinConnection.QRY_ID_GEN - you cannot rely on {{currentQUeryId}}, as it 
might be advanced by other opened statements. You should generate ID only once 
and then pass it to statement.
4) New {{IgniteQueryErrorCode.QUERY_CANCELED}} is added, but I do not see if it 
mapped to any SQLSTATE. So what is the point of this vendor-specific code?

> JDBC thin: support query cancel
> ---
>
> Key: IGNITE-5439
> URL: https://issues.apache.org/jira/browse/IGNITE-5439
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc
>Affects Versions: 2.0
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.3
>
>
> The JDBC {{Statement.cancel}} method must be supported.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6511) ODBC: SQLGetDiagRec doesn't follow specification when buffer size is too small

[Sergey Kalashnikov (JIRA)]

Sergey Kalashnikov created IGNITE-6511:
--

 Summary: ODBC: SQLGetDiagRec doesn't follow specification when 
buffer size is too small
 Key: IGNITE-6511
 URL: https://issues.apache.org/jira/browse/IGNITE-6511
 Project: Ignite
  Issue Type: Bug
  Components: odbc
Reporter: Sergey Kalashnikov


When buffer size provided for error message is not big enough to hold the 
entire error message, the function {noformat}SqlGetDiagRec{noformat} returns 
wrong resulting string length (-4) and wrong result code 
({noformat}SQL_SUCCESS{noformat} instead of 
{noformat}SQL_SUCCESS_WITH_INFO{noformat}).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6511) ODBC: SQLGetDiagRec doesn't follow specification when buffer size is too small

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov updated IGNITE-6511:
---
Description: When buffer size provided for error message is not big enough 
to hold the entire error message, the function {{SqlGetDiagRec()}} returns 
wrong resulting string length (-4) and wrong result code ({{SQL_SUCCESS}} 
instead of {{SQL_SUCCESS_WITH_INFO}}).  (was: When buffer size provided for 
error message is not big enough to hold the entire error message, the function 
{{SqlGetDiagRec}} returns wrong resulting string length (-4) and wrong result 
code ({{SQL_SUCCESS}} instead of {{SQL_SUCCESS_WITH_INFO}}).)

> ODBC: SQLGetDiagRec doesn't follow specification when buffer size is too small
> --
>
> Key: IGNITE-6511
> URL: https://issues.apache.org/jira/browse/IGNITE-6511
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Reporter: Sergey Kalashnikov
>  Labels: usability
>
> When buffer size provided for error message is not big enough to hold the 
> entire error message, the function {{SqlGetDiagRec()}} returns wrong 
> resulting string length (-4) and wrong result code ({{SQL_SUCCESS}} instead 
> of {{SQL_SUCCESS_WITH_INFO}}).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6511) ODBC: SQLGetDiagRec doesn't follow specification when buffer size is too small

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov updated IGNITE-6511:
---
Description: When buffer size provided for error message is not big enough 
to hold the entire error message, the function {{SqlGetDiagRec}} returns wrong 
resulting string length (-4) and wrong result code ({{SQL_SUCCESS}} instead of 
{{SQL_SUCCESS_WITH_INFO}}).  (was: When buffer size provided for error message 
is not big enough to hold the entire error message, the function 
{noformat}SqlGetDiagRec{noformat} returns wrong resulting string length (-4) 
and wrong result code ({{SQL_SUCCESS}} instead of {{SQL_SUCCESS_WITH_INFO}}).)

> ODBC: SQLGetDiagRec doesn't follow specification when buffer size is too small
> --
>
> Key: IGNITE-6511
> URL: https://issues.apache.org/jira/browse/IGNITE-6511
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Reporter: Sergey Kalashnikov
>  Labels: usability
>
> When buffer size provided for error message is not big enough to hold the 
> entire error message, the function {{SqlGetDiagRec}} returns wrong resulting 
> string length (-4) and wrong result code ({{SQL_SUCCESS}} instead of 
> {{SQL_SUCCESS_WITH_INFO}}).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6511) ODBC: SQLGetDiagRec doesn't follow specification when buffer size is too small

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov updated IGNITE-6511:
---
Description: When buffer size provided for error message is not big enough 
to hold the entire error message, the function 
{noformat}SqlGetDiagRec{noformat} returns wrong resulting string length (-4) 
and wrong result code ({{SQL_SUCCESS}} instead of {{SQL_SUCCESS_WITH_INFO}}).  
(was: When buffer size provided for error message is not big enough to hold the 
entire error message, the function {noformat}SqlGetDiagRec{noformat} returns 
wrong resulting string length (-4) and wrong result code 
({noformat}SQL_SUCCESS{noformat} instead of 
{noformat}SQL_SUCCESS_WITH_INFO{noformat}).)

> ODBC: SQLGetDiagRec doesn't follow specification when buffer size is too small
> --
>
> Key: IGNITE-6511
> URL: https://issues.apache.org/jira/browse/IGNITE-6511
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Reporter: Sergey Kalashnikov
>  Labels: usability
>
> When buffer size provided for error message is not big enough to hold the 
> entire error message, the function {noformat}SqlGetDiagRec{noformat} returns 
> wrong resulting string length (-4) and wrong result code ({{SQL_SUCCESS}} 
> instead of {{SQL_SUCCESS_WITH_INFO}}).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6005) [Test failed] GridCachePartitionedDataStructuresFailoverSelfTest.testSemaphoreNonFailoverSafe

[Pavel Pereslegin (JIRA)]

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

Pavel Pereslegin commented on IGNITE-6005:
--

Hello.

Here in this case, it is obvious, that sometimes the thread that invokes 
GridCacheSemaphoreImpl#close may be interrupted and therefore he can’t release 
the resources (fails in GridCacheAdapter#asyncOpAcquire on 
java.util.Semaphore#acquire).

Should GridCacheSemaphoreImpl#close succeed if executed by interrupted thread?


> [Test failed] 
> GridCachePartitionedDataStructuresFailoverSelfTest.testSemaphoreNonFailoverSafe
> -
>
> Key: IGNITE-6005
> URL: https://issues.apache.org/jira/browse/IGNITE-6005
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Assignee: Pavel Pereslegin
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.3
>
>
> Example of fail
> https://ci.ignite.apache.org/viewLog.html?buildId=762788=buildResultsDiv=Ignite20Tests_IgniteDataStrucutures
> Typical problem is 
> {code}
> org.apache.ignite.IgniteInterruptedException: Failed to wait for asynchronous 
> operation permit (thread got interrupted).
> at 
> org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:805)
> at 
> org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:803)
> at 
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:961)
> at 
> org.apache.ignite.internal.processors.datastructures.GridCacheSemaphoreImpl.close(GridCacheSemaphoreImpl.java:1026)
> at 
> org.apache.ignite.internal.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest.testSemaphoreNonFailoverSafe(GridCacheAbstractDataStructuresFailoverSelfTest.java:458)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.InterruptedException: null
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1301)
> at java.util.concurrent.Semaphore.acquire(Semaphore.java:317)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.asyncOpAcquire(GridCacheAdapter.java:4314)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.asyncOp(GridCacheAdapter.java:4177)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.getAsync(GridDhtColocatedCache.java:196)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get0(GridCacheAdapter.java:4509)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4490)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1324)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProxyImpl.get(GridCacheProxyImpl.java:329)
> at 
> org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor$5.applyx(DataStructuresProcessor.java:635)
> at 
> org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.retryTopologySafe(DataStructuresProcessor.java:1519)
> at 
> org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.removeDataStructure(DataStructuresProcessor.java:629)
> at 
> org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.removeSemaphore(DataStructuresProcessor.java:1188)
> at 
> org.apache.ignite.internal.processors.datastructures.GridCacheSemaphoreImpl.close(GridCacheSemaphoreImpl.java:1023)
> at 
> org.apache.ignite.internal.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest.testSemaphoreNonFailoverSafe(GridCacheAbstractDataStructuresFailoverSelfTest.java:458)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at 

[jira] [Commented] (IGNITE-5730) .NET: Failed to load ignite.jni.dll when starting up multiple nodes

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-5730:


Commit {{7f82340189bebac7bfd5f935eb3531035a6f9acb}} has been reverted (wrong 
branch merged): {{690694cad1f00c796631f6288b58248a0cb409b1}}

Proper branch merged to master: {{fca47345fae7adf80a1d40cc6c4c711924df2de2}}.

> .NET: Failed to load ignite.jni.dll when starting up multiple nodes
> ---
>
> Key: IGNITE-5730
> URL: https://issues.apache.org/jira/browse/IGNITE-5730
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> When starting multiple nodes at once (with a script of some kind), failure to 
> load unmanaged dll can occur:
> {code}
> set IGNITE_NATIVE_TEST_CLASSPATH=true
> FOR /L %%A IN (1,1,20) DO (
>   start Apache.Ignite.exe
> )
> {code}
> Exception:
> {code}
> ERROR: System.TypeInitializationException: The type initializer for 
> 'Apache.Ignite.Core.Impl.Unmanaged.UnmanagedUtils' threw an exception. ---> 
> Apache.Ignite.Core.Common.IgniteException: Failed to load ignite.jni.dll: 126
>at Apache.Ignite.Core.Impl.Unmanaged.UnmanagedUtils..cctor()
>--- End of inner exception stack trace ---
>at Apache.Ignite.Core.Impl.Unmanaged.UnmanagedUtils.Initialize()
>at Apache.Ignite.Core.Impl.IgniteUtils.LoadDlls(String configJvmDllPath, 
> ILogger log)
>at Apache.Ignite.Core.Ignition.Start(IgniteConfiguration cfg)
>at Apache.Ignite.IgniteRunner.Main(String[] args)
> {code}
> Error codes may be 5 (ERROR_ACCESS_DENIED) or 126 (ERROR_MOD_NOT_FOUND).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6510) SQL: document CACHE_NAME, KEY_TYPE and VALUE_TABLE options for CREATE TABLE

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-6510:
---

 Summary: SQL: document CACHE_NAME, KEY_TYPE and VALUE_TABLE 
options for CREATE TABLE
 Key: IGNITE-6510
 URL: https://issues.apache.org/jira/browse/IGNITE-6510
 Project: Ignite
  Issue Type: Task
  Components: documentation
Reporter: Vladimir Ozerov
Assignee: Alexander Paschenko
 Fix For: 2.3






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6242) Passing custom cache and type names to CREATE TABLE

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6242:


Github user asfgit closed the pull request at:

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


> Passing custom cache and type names to CREATE TABLE
> ---
>
> Key: IGNITE-6242
> URL: https://issues.apache.org/jira/browse/IGNITE-6242
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.1
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
>Priority: Critical
>  Labels: usability
> Fix For: 2.3
>
>
> Once CREATE TABLE is executed Ignite:
> * will create an IgniteCache naming it SQL_PUBLIC_\{TABLE\}. So, if a Person 
> table is created you’ll have SQL_PUBLIC_PERSON cache in the cluster.
> * will use autogenerated names for the key and value types. For instance, 
> this is how the type name might look like 
> SQL_PUBLIC_CITY_3f4e9fbf_3464_4598_8394_1307b86dc4e7_KEY.
> The goal of the ticket is to give a way to pass a custom cache name, key's 
> type name, value's type name into WITH clause.
> Refer to this discussion for more details:
> http://apache-ignite-developers.2346864.n4.nabble.com/Key-value-access-to-caches-created-with-DDL-td21622.html
> http://apache-ignite-developers.2346864.n4.nabble.com/Override-cache-name-created-with-CREATE-TABLE-td21456.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-6305) Need to add update checker to Ignite

[Andrey Gura (JIRA)]

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

Andrey Gura edited comment on IGNITE-6305 at 9/27/17 11:52 AM:
---

Implemented in the following way:

- Update checker periodically checking URL for latest updates using HTTP GET 
method. 
- For first request current Ignite version passed as HTTP URL parameter 
{{?ver=}} in order to support HTTP analytics tools (e.g. Google 
Analytics). All consequent requests don't use this parameter.
- If first request was failed (e.g. due to connection error) then all 
consequent requests behave like first request until success.

Update checker requests URL {{https://ignite.apache.org/latest?ver=}} 
and expects that returned result will be plain text and contains at least one 
line of text: {{version=}}. Also result can contain optional 
attribute: {{downloadUrl=}}.



See branch {{ignite-6305}}.


was (Author: agura):
Implemented in the following way:

- Update checker periodically checking URL for latest updates using HTTP GET 
method. 
- For first request current Ignite version passed as HTTP URL parameter 
{{?ver=}} in order to support HTTP analytics tools (e.g. Google 
Analytics). All consequent requests don't use this parameter.
- If first request was failed (e.g. due to connection error) then all 
consequent requests behave like first request until success.

Update checker expect that return result will be plain text and contains at 
least one line of text: {{version=}}. Also result can contain optional 
attribute: {{downloadUrl=}}.

See branch {{ignite-6305}}.

> Need to add update checker to Ignite
> 
>
> Key: IGNITE-6305
> URL: https://issues.apache.org/jira/browse/IGNITE-6305
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Reporter: Dmitriy Setrakyan
>Assignee: Andrey Gura
>Priority: Critical
> Fix For: 2.3
>
>
> # Ignite should provide an update check on node startup, which will report to 
> users if there is a new version available. 
> # We can also use the update-checker to count Ignite starts, which will allow 
> the community to monitor the health of the project.
> The design is specified in this dev@ thread (make sure to read all the way to 
> the end):
> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Ignite-Update-Checker-td21150.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6509) SQL: Add NOT NULL support to QueryEntity API

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-6509:
---

 Summary: SQL: Add NOT NULL support to QueryEntity API
 Key: IGNITE-6509
 URL: https://issues.apache.org/jira/browse/IGNITE-6509
 Project: Ignite
  Issue Type: Task
Affects Versions: 2.1
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 2.3






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6509) SQL: Add NOT NULL support to QueryEntity API

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-6509:
-

Originally this field was added to internal class {{QueryEntityEx}}, so it is 
only accessible from JDBC/ODBC drivers. Let's add it to public API as well.

> SQL: Add NOT NULL support to QueryEntity API
> 
>
> Key: IGNITE-6509
> URL: https://issues.apache.org/jira/browse/IGNITE-6509
> Project: Ignite
>  Issue Type: Task
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 2.3
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6305) Need to add update checker to Ignite

[Andrey Gura (JIRA)]

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

Andrey Gura commented on IGNITE-6305:
-

Implemented in the following way:

- Update checker periodically checking URL for latest updates using HTTP GET 
method. 
- For first request current Ignite version passed as HTTP URL parameter 
{{?ver=}} in order to support HTTP analytics tools (e.g. Google 
Analytics). All consequent requests don't use this parameter.
- If first request was failed (e.g. due to connection error) then all 
consequent requests behave like first request until success.

Update checker expect that return result will be plain text and contains at 
least one line of text: {{version=}}. Also result can contain optional 
attribute: {{downloadUrl=}}.


> Need to add update checker to Ignite
> 
>
> Key: IGNITE-6305
> URL: https://issues.apache.org/jira/browse/IGNITE-6305
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Reporter: Dmitriy Setrakyan
>Assignee: Andrey Gura
>Priority: Critical
> Fix For: 2.3
>
>
> # Ignite should provide an update check on node startup, which will report to 
> users if there is a new version available. 
> # We can also use the update-checker to count Ignite starts, which will allow 
> the community to monitor the health of the project.
> The design is specified in this dev@ thread (make sure to read all the way to 
> the end):
> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Ignite-Update-Checker-td21150.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-6305) Need to add update checker to Ignite

[Andrey Gura (JIRA)]

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

Andrey Gura edited comment on IGNITE-6305 at 9/27/17 11:06 AM:
---

Implemented in the following way:

- Update checker periodically checking URL for latest updates using HTTP GET 
method. 
- For first request current Ignite version passed as HTTP URL parameter 
{{?ver=}} in order to support HTTP analytics tools (e.g. Google 
Analytics). All consequent requests don't use this parameter.
- If first request was failed (e.g. due to connection error) then all 
consequent requests behave like first request until success.

Update checker expect that return result will be plain text and contains at 
least one line of text: {{version=}}. Also result can contain optional 
attribute: {{downloadUrl=}}.

See branch {{ignite-6305}}.


was (Author: agura):
Implemented in the following way:

- Update checker periodically checking URL for latest updates using HTTP GET 
method. 
- For first request current Ignite version passed as HTTP URL parameter 
{{?ver=}} in order to support HTTP analytics tools (e.g. Google 
Analytics). All consequent requests don't use this parameter.
- If first request was failed (e.g. due to connection error) then all 
consequent requests behave like first request until success.

Update checker expect that return result will be plain text and contains at 
least one line of text: {{version=}}. Also result can contain optional 
attribute: {{downloadUrl=}}.


> Need to add update checker to Ignite
> 
>
> Key: IGNITE-6305
> URL: https://issues.apache.org/jira/browse/IGNITE-6305
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Reporter: Dmitriy Setrakyan
>Assignee: Andrey Gura
>Priority: Critical
> Fix For: 2.3
>
>
> # Ignite should provide an update check on node startup, which will report to 
> users if there is a new version available. 
> # We can also use the update-checker to count Ignite starts, which will allow 
> the community to monitor the health of the project.
> The design is specified in this dev@ thread (make sure to read all the way to 
> the end):
> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Ignite-Update-Checker-td21150.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5615) .NET: IgniteConfiguration.LocalEventListeners

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-5615:
-

[~ptupitsyn], LGTM

> .NET: IgniteConfiguration.LocalEventListeners
> -
>
> Key: IGNITE-5615
> URL: https://issues.apache.org/jira/browse/IGNITE-5615
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> Propagate {{IgniteConfiguration.LocalEventListeners}} to .NET. This allows 
> catching all events right from the node start.
> * Can we unsubscribe from these events later? Does Java support this?
> * What about GetEvents for a cluster group, how do we handle local listeners 
> in this case?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6242) Passing custom cache and type names to CREATE TABLE

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-6242:
-

New test run: 
https://ci.ignite.apache.org/viewQueued.html?itemId=856429=queuedBuildOverviewTab

> Passing custom cache and type names to CREATE TABLE
> ---
>
> Key: IGNITE-6242
> URL: https://issues.apache.org/jira/browse/IGNITE-6242
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.1
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
>Priority: Critical
>  Labels: usability
> Fix For: 2.3
>
>
> Once CREATE TABLE is executed Ignite:
> * will create an IgniteCache naming it SQL_PUBLIC_\{TABLE\}. So, if a Person 
> table is created you’ll have SQL_PUBLIC_PERSON cache in the cluster.
> * will use autogenerated names for the key and value types. For instance, 
> this is how the type name might look like 
> SQL_PUBLIC_CITY_3f4e9fbf_3464_4598_8394_1307b86dc4e7_KEY.
> The goal of the ticket is to give a way to pass a custom cache name, key's 
> type name, value's type name into WITH clause.
> Refer to this discussion for more details:
> http://apache-ignite-developers.2346864.n4.nabble.com/Key-value-access-to-caches-created-with-DDL-td21622.html
> http://apache-ignite-developers.2346864.n4.nabble.com/Override-cache-name-created-with-CREATE-TABLE-td21456.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6184) No checkClusterState() in IgniteKernal.getOrCreateCaches()

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6184:


Github user asfgit closed the pull request at:

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


> No checkClusterState() in IgniteKernal.getOrCreateCaches()
> --
>
> Key: IGNITE-6184
> URL: https://issues.apache.org/jira/browse/IGNITE-6184
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
> Fix For: 2.3
>
>
> Check if anything else is off, too.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6360) NPE occurs if object with null indexed field is added

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6360:


Github user asfgit closed the pull request at:

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


> NPE occurs if object with null indexed field is added
> -
>
> Key: IGNITE-6360
> URL: https://issues.apache.org/jira/browse/IGNITE-6360
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.3
> Environment: NPE occurs if object with null indexed field is added
>Reporter: Mikhail Cherkasov
>Assignee: Mikhail Cherkasov
> Fix For: 2.3
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (IGNITE-6216) .NET: Add CheckpointWriteOrder enum in persistent store configuration

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn resolved IGNITE-6216.

Resolution: Fixed

> .NET: Add CheckpointWriteOrder enum in persistent store configuration
> -
>
> Key: IGNITE-6216
> URL: https://issues.apache.org/jira/browse/IGNITE-6216
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Ivan Rakov
>Assignee: Pavel Tupitsyn
>  Labels: .NET, usability
> Fix For: 2.3
>
>
> Since 2.2 we have {{CheckpointWriteOrder}} property in 
> {{PersistentStoreConfiguration}}. It should be possible to set through .NET 
> configuration classes.
> Default value should be {{CheckpointWriteOrder#SEQUENTIAL}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-6216) .NET: Add CheckpointWriteOrder enum in persistent store configuration

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn edited comment on IGNITE-6216 at 9/27/17 10:37 AM:
--

Merged to master: {{12cbf75bb70615cf31ac059e89dabac1dabce77e}}.


was (Author: ptupitsyn):
Merged to master: {[12cbf75bb70615cf31ac059e89dabac1dabce77e}}.

> .NET: Add CheckpointWriteOrder enum in persistent store configuration
> -
>
> Key: IGNITE-6216
> URL: https://issues.apache.org/jira/browse/IGNITE-6216
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Ivan Rakov
>Assignee: Pavel Tupitsyn
>  Labels: .NET, usability
> Fix For: 2.3
>
>
> Since 2.2 we have {{CheckpointWriteOrder}} property in 
> {{PersistentStoreConfiguration}}. It should be possible to set through .NET 
> configuration classes.
> Default value should be {{CheckpointWriteOrder#SEQUENTIAL}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6216) .NET: Add CheckpointWriteOrder enum in persistent store configuration

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-6216:


Merged to master: {[12cbf75bb70615cf31ac059e89dabac1dabce77e}}.

> .NET: Add CheckpointWriteOrder enum in persistent store configuration
> -
>
> Key: IGNITE-6216
> URL: https://issues.apache.org/jira/browse/IGNITE-6216
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Ivan Rakov
>Assignee: Pavel Tupitsyn
>  Labels: .NET, usability
> Fix For: 2.3
>
>
> Since 2.2 we have {{CheckpointWriteOrder}} property in 
> {{PersistentStoreConfiguration}}. It should be possible to set through .NET 
> configuration classes.
> Default value should be {{CheckpointWriteOrder#SEQUENTIAL}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6331) SQL: GridH2KeyValueRowOffheap is not used

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6331:


Github user devozerov closed the pull request at:

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


> SQL: GridH2KeyValueRowOffheap is not used
> -
>
> Key: IGNITE-6331
> URL: https://issues.apache.org/jira/browse/IGNITE-6331
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 2.3
>
>
> Looks like this is a dead code from Ignite 1.x days. Let's remove it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)