[GitHub] ignite pull request #4998: Javadoc broken, test

[Mmuzaf]

GitHub user Mmuzaf opened a pull request:

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

Javadoc broken, test



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

$ git pull https://github.com/Mmuzaf/ignite javadoc_test

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

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


commit 17abc0a1b01d22f02fdff5db0f8bac64442dffb4
Author: Maxim Muzafarov 
Date:   2018-10-16T08:12:00Z

Revert "IGNITE-9863 Refactored VisorDataTransferObject to 
IgniteDataTransferObject.  Deprecated VisorDataTransferObject class.  Minor 
code cleanup."

This reverts commit 789046b




---

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

[Alexey Goncharuk]

This is a flaky failure, can be ignored.

вт, 16 окт. 2018 г. в 8:40, :

> Hi Igniters,
>
>  I've detected some new issue on TeamCity to be handled. You are more than
> welcomed to help.
>
>  If your changes can lead to this failure(s): We're grateful that you were
> a volunteer to make the contribution to this project, but things change and
> you may no longer be able to finalize your contribution.
>  Could you respond to this email and indicate if you wish to continue and
> fix test failures or step down and some committer may revert you commit.
>
>  *New stable failure of a flaky test in master
> TcpDiscoverySslTrustedSelfTest.testNodeShutdownOnRingMessageWorkerStartNotFinished
>
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=4205209624038097982&branch=%3Cdefault%3E&tab=testDetails
>  No changes in the build
>
>  - Here's a reminder of what contributors were agreed to do
> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
>  - Should you have any questions please contact
> dev@ignite.apache.org
>
> Best Regards,
> Apache Ignite TeamCity Bot
> https://github.com/apache/ignite-teamcity-bot
> Notification generated at 08:40:43 16-10-2018
>

[jira] [Created] (IGNITE-9894) [TC Bot] Change link name in JIRA comment from "Run All" to "TeamCity RunAll Results"

[PetrovMikhail (JIRA)]

PetrovMikhail created IGNITE-9894:
-

 Summary: [TC Bot] Change link name in JIRA comment from "Run All" 
to "TeamCity RunAll Results"
 Key: IGNITE-9894
 URL: https://issues.apache.org/jira/browse/IGNITE-9894
 Project: Ignite
  Issue Type: Task
Reporter: PetrovMikhail
Assignee: PetrovMikhail


Change link name in JIRA comment from "Run All" to "TeamCity RunAll Results"



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

[GitHub] ignite pull request #4999: IGNITE-9887

[devozerov]

GitHub user devozerov opened a pull request:

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

IGNITE-9887



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

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

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

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


commit cebb89bbfe0575f01854a11fd848887ae99ac172
Author: devozerov 
Date:   2018-10-16T08:48:08Z

Fixed.




---

[jira] [Created] (IGNITE-9895) DiscoveryMessageNotifierWorker must be instanceof IgniteDiscoveryThread

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-9895:


 Summary: DiscoveryMessageNotifierWorker must be instanceof 
IgniteDiscoveryThread
 Key: IGNITE-9895
 URL: https://issues.apache.org/jira/browse/IGNITE-9895
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.7
Reporter: Alexey Goncharuk
 Fix For: 2.7


This is a regression from IGNITE-9398. The newly added thread must implement 
the marker interface, otherwise it is possible for a blocking future get inside 
of discovery worker, which leads to a cluster-wide deadlock:

{code}
"disco-notyfier-worker-#625%internal.IgniteClientReconnectApiExceptionTest0%" 
#770 prio=5 os_prio=0 tid=0x7f479c263800 nid=0x209b waiting on condition 
[0x7f49287ec000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
at 
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.metadata(CacheObjectBinaryProcessorImpl.java:579)
at 
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$2.metadata(CacheObjectBinaryProcessorImpl.java:197)
at 
org.apache.ignite.internal.binary.BinaryContext.metadata(BinaryContext.java:1283)
at 
org.apache.ignite.internal.binary.BinaryReaderExImpl.getOrCreateSchema(BinaryReaderExImpl.java:2007)
at 
org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:286)
at 
org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:185)
at 
org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1984)
at 
org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:698)
at 
org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:183)
at 
org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:870)
at 
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1764)
at 
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716)
at 
org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1984)
at 
org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:698)
at 
org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:183)
at 
org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:870)
at 
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1764)
at 
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716)
at 
org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:310)
at 
org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:99)
at 
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:82)
at 
org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10014)
at 
org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10043)
at 
org.apache.ignite.internal.GridMessageListenHandler.p2pUnmarshal(GridMessageListenHandler.java:194)
at 
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.processStartRequest(GridContinuousProcessor.java:1331)
at 
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.access$400(GridContinuousProcessor.java:108)
at 
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:200)
at 
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:191)
at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:721)
at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:600)
- locked <0x0007860b5c70> (a java.lang.Object)
at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4$$Lambda$10/346299427.run(Unknown
 Source)
at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifyerWorker.body0(GridDiscoveryManager.java:2681)
at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifyerWorker.body(GridDiscoveryManager.java:2719)
at 
org.apache.ignite.internal.util.worker.G

[GitHub] ignite pull request #5000: IGNITE-9895 DiscoveryMessageNotifierWorker must b...

[agoncharuk]

GitHub user agoncharuk opened a pull request:

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

IGNITE-9895 DiscoveryMessageNotifierWorker must be instanceof 
IgniteDiscoveryThread



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

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

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

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


commit 3bf874620c590d7fba4f5019e1427e8838c725a0
Author: Alexey Goncharuk 
Date:   2018-10-16T09:04:59Z

IGNITE-9895 DiscoveryMessageNotifierWorker must be instanceof 
IgniteDiscoveryThread




---

[jira] [Created] (IGNITE-9896) TxRollbackOnTimeoutNoDeadlockDetectionTest fails in master for many tests

[Alexei Scherbakov (JIRA)]

Alexei Scherbakov created IGNITE-9896:
-

 Summary: TxRollbackOnTimeoutNoDeadlockDetectionTest fails in 
master for many tests
 Key: IGNITE-9896
 URL: https://issues.apache.org/jira/browse/IGNITE-9896
 Project: Ignite
  Issue Type: Bug
Reporter: Alexei Scherbakov
 Fix For: 2.8


Example of 100% failing test:

org.apache.ignite.internal.processors.cache.transactions.TxRollbackOnTimeoutNoDeadlockDetectionTest#testRollbackOnTimeoutTxServerRemapPessimisticReadCommitted



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

[jira] [Created] (IGNITE-9897) PDO returns null for column values of string type

[Roman Shtykh (JIRA)]

Roman Shtykh created IGNITE-9897:


 Summary: PDO returns null for column values of string type
 Key: IGNITE-9897
 URL: https://issues.apache.org/jira/browse/IGNITE-9897
 Project: Ignite
  Issue Type: Bug
  Components: odbc
 Environment: CentOS
Reporter: Roman Shtykh


Using _odbc_connect_ returns all column values, but with _PDO_ string and 
double type values are null.
Reproduced on CentOS.
 # Start a server node with Ignite CPP
 # Run odbc-example (which will create two tables)
 # Run a simple PHP script

{{setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);}}

{{    $sql = 'SELECT * FROM "Person".Person';}}
{{    $data = $dbh->query($sql);}}

{{    foreach($data as $row) {}}
{{    var_export($row);}}
{{    }}}

{{    echo PHP_EOL,PHP_EOL,"# Using odbc_*( ) Functions",PHP_EOL;}}
{{    $conn = odbc_connect('ApacheIgnite','','');}}
{{    $rs = odbc_exec($conn, $sql);}}
{{  while($row = odbc_fetch_array($rs)){}}
{{  var_export($row);}}
{{  }}}
{{} catch (PDOException $e) {}}
{{    print "Error!: " . $e->getMessage() . "\n";}}
{{    die();}}
{{}}}
{{?>}}

 



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

[jira] [Created] (IGNITE-9898) Checkpointer thread hangs on await async task complete

[Dmitriy Govorukhin (JIRA)]

Dmitriy Govorukhin created IGNITE-9898:
--

 Summary: Checkpointer thread hangs on await async task complete
 Key: IGNITE-9898
 URL: https://issues.apache.org/jira/browse/IGNITE-9898
 Project: Ignite
  Issue Type: Bug
Reporter: Dmitriy Govorukhin


In some cases, we can reset thread pool counters during execution async task, 
and then we can get hangs on await

{code}
[19:36:01] : [Step 4/5] [2018-10-15 16:36:01,435][INFO 
][db-checkpoint-thread-#21691%db.IgnitePdsPageEvictionDuringPartitionClearTest0%][GridCacheDatabaseSharedManager]
 Await checkpoint pool tasks comleted, pendingTaskCnt=2, completedTaskCnt=3, 
initialized=true, err=null, activeCnt=0
[19:36:03] : [Step 4/5] [2018-10-15 16:36:03,435][INFO 
][db-checkpoint-thread-#21691%db.IgnitePdsPageEvictionDuringPartitionClearTest0%][GridCacheDatabaseSharedManager]
 Await checkpoint pool tasks comleted, pendingTaskCnt=2, completedTaskCnt=3, 
initialized=true, err=null, activeCnt=0
[19:36:05] : [Step 4/5] [2018-10-15 16:36:05,436][INFO 
][db-checkpoint-thread-#21691%db.IgnitePdsPageEvictionDuringPartitionClearTest0%][GridCacheDatabaseSharedManager]
 Await checkpoint pool tasks comleted, pendingTaskCnt=2, completedTaskCnt=3, 
initialized=true, err=null, activeCnt=0
[19:36:07] : [Step 4/5] [2018-10-15 16:36:07,436][INFO 
][db-checkpoint-thread-#21691%db.IgnitePdsPageEvictionDuringPartitionClearTest0%][GridCacheDatabaseSharedManager]
 Await checkpoint pool tasks comleted, pendingTaskCnt=2, completedTaskCnt=3, 
initialized=true, err=null, activeCnt=0
[19:36:09] : [Step 4/5] [2018-10-15 16:36:09,437][INFO 
][db-checkpoint-thread-#21691%db.IgnitePdsPageEvictionDuringPartitionClearTest0%][GridCacheDatabaseSharedManager]
 Await checkpoint pool tasks comleted, pendingTaskCnt=2, completedTaskCnt=3, 
initialized=true, err=null, activeCnt=0
[19:36:11] : [Step 4/5] [2018-10-15 16:36:11,437][INFO 
][db-checkpoint-thread-#21691%db.IgnitePdsPageEvictionDuringPartitionClearTest0%][GridCacheDatabaseSharedManager]
 Await checkpoint pool tasks comleted, pendingTaskCnt=2, completedTaskCnt=3, 
initialized=true, err=null, activeCnt=0
[19:36:13] : [Step 4/5] [2018-10-15 16:36:13,438][INFO 
][db-checkpoint-thread-#21691%db.IgnitePdsPageEvictionDuringPartitionClearTest0%][GridCacheDatabaseSharedManager]
 Await checkpoint pool tasks comleted, pendingTaskCnt=2, completedTaskCnt=3, 
initialized=true, err=null, activeCnt=0
[19:36:15] : [Step 4/5] [2018-10-15 16:36:15,439][INFO 
][db-checkpoint-thread-#21691%db.IgnitePdsPageEvictionDuringPartitionClearTest0%][GridCacheDatabaseSharedManager]
 Await checkpoint pool tasks comleted, pendingTaskCnt=2, completedTaskCnt=3, 
initialized=true, err=null, activeCnt=0
[19:36:17] : [Step 4/5] [2018-10-15 16:36:17,440][INFO 
][db-checkpoint-thread-#21691%db.IgnitePdsPageEvictionDuringPartitionClearTest0%][GridCacheDatabaseSharedManager]
 Await checkpoint pool tasks comleted, pendingTaskCnt=2, completedTaskCnt=3, 
initialized=true, err=null, activeCnt=0
[19:36:19] : [Step 4/5] [2018-10-15 16:36:19,441][INFO 
][db-checkpoint-thread-#21691%db.IgnitePdsPageEvictionDuringPartitionClearTest0%][GridCacheDatabaseSharedManager]
 Await checkpoint pool tasks comleted, pendingTaskCnt=2, completedTaskCnt=3, 
initialized=true, err=null, activeCnt=0
[19:36:21] : [Step 4/5] [2018-10-15 16:36:21,442][INFO 
][db-checkpoint-thread-#21691%db.IgnitePdsPageEvictionDuringPartitionClearTest0%][GridCacheDatabaseSharedManager]
 Await checkpoint pool tasks comleted, pendingTaskCnt=2, completedTaskCnt=3, 
initialized=true, err=null, activeCnt=0

{code}



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

[GitHub] ignite pull request #4992: IGNITE-9884 Some tests are incorrectly muted

[oignatenko]

Github user oignatenko closed the pull request at:

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


---

[GitHub] ignite pull request #5001: IGNITE-9884 Some tests are incorrectly muted

[oignatenko]

GitHub user oignatenko opened a pull request:

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

IGNITE-9884 Some tests are incorrectly muted



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

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

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

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


commit 1eeca908a8076a8317947dac8a46845964d1d7ea
Author: Oleg Ignatenko 
Date:   2018-08-23T13:13:28Z

IGNITE-9348 ML examples improvements
- wip (logging improved)
-- verified with diffs overview, executing the examples and studying 
execution logs

commit e50b89c392568ba9b93935c4fa6c7f7f93f5ec6f
Author: Oleg Ignatenko 
Date:   2018-08-23T14:45:57Z

Revert "IGNITE-9348 ML examples improvements"

This reverts commit 1eeca908a8076a8317947dac8a46845964d1d7ea.

commit 474024b4c5bbdb3c0a4ed2f0a66238c8054c6674
Author: Oleg Ignatenko 
Date:   2018-08-23T14:57:34Z

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

commit 9642b233b5701bdad47ebea163079160227c582a
Author: Oleg Ignatenko 
Date:   2018-08-28T14:01:11Z

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

commit 7fc16d013ab725d2ff2e1a1b042c983f11d0c4d4
Author: Oleg Ignatenko 
Date:   2018-08-28T15:13:02Z

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

commit d2caba67b156674f051f50faebeafe0871bf0914
Author: Oleg Ignatenko 
Date:   2018-08-29T13:14:07Z

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

commit 16775dff51d71ea68b4a3dea98be552130c493ed
Author: Oleg Ignatenko 
Date:   2018-08-30T09:00:56Z

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

commit aedb59929974fe205b949225c1a338c68c60cfc8
Author: Oleg Ignatenko 
Date:   2018-08-30T09:42:38Z

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

commit 39c6482fcdca506aa33011ed21c98060b4a8c68b
Author: Oleg Ignatenko 
Date:   2018-08-30T11:28:05Z

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

commit 33b32a2760a6559c78283b927e3191180d8ed9e1
Author: Oleg Ignatenko 
Date:   2018-08-30T12:31:16Z

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

commit 9531028ddd1aef9e95f7e8c8b528086739bbb1b0
Author: Oleg Ignatenko 
Date:   2018-08-30T14:06:34Z

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

commit 28f22c6e2fffcb82717ba5da7be2cfd39715c4e3
Author: Oleg Ignatenko 
Date:   2018-08-30T16:41:51Z

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

commit aacac88db519187413b0fc5ff9d0e55b8f8cff22
Author: Oleg Ignatenko 
Date:   2018-08-31T10:12:32Z

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

commit 897f920dde46022849b13f9fb86dba8e54119a56
Author: Oleg Ignatenko 
Date:   2018-08-31T13:57:14Z

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

commit 114c79e54c1b316006ccc3ff22d20d902f9313df
Author: Oleg Ignatenko 
Date:   2018-08-31T17:39:16Z

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

commit fd6b659bb8be1992618ce4ce91f568a0988b3afa
Author: Oleg Ignatenko 
Date:   2018-09-02T06:11:42Z

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

commit 6ae6d1d3cf9743d8d466be0330511ddc8589e944
Author: Oleg Ignatenko 
Date:   2018-09-03T10:27:35Z

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

commit e8b27dbd3d0c1cbdb7a7659175f5c7bb447482bf
Author: Oleg Ignatenko 
Date:   2018-09-04T09:49:44Z

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

commit 622c82efdd0aa182fadea6b7ffa5d4615521a3f5
Author: Oleg Ignatenko 
Date:   2018-09-05T10:50:28Z

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

commit fb844fe3751e2e8ae87e6b8030b0e4bd659df9c2
Author: Oleg Ignatenko 
Date:   2018-09-05T11:45:58Z

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

commit 480ed78869277d7e32f725ab71bec9621f1ac03a
Author: Oleg Ignatenko 
Date:   2018-09-06T07:52:55Z

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

commit c99762498f617c0e98ea3062a43c0b30092166ef
Author: Oleg Ignatenko 
Date:   2018-09-06T14:45:04Z

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

commit 2e17175225c72f747d370b5fee96f8be69d6d2cb
Author: Oleg Ignatenko 
Date:   2018-09-06T17:33:54Z

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

commit 9ebcd9a2fe5966b0bf42a95484395867c15d863f
Author: Oleg Ignatenko 
Date:   2018-09-07T13:38:51Z

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

[GitHub] ignite pull request #5002: IGNITE-9898 fix checkpoint thread hangs on await ...

[dgovorukhin]

GitHub user dgovorukhin opened a pull request:

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

IGNITE-9898 fix checkpoint thread hangs on await async task completion



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

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

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

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


commit 7719b0bdbc405fa462230b0758e87356ce3615fe
Author: Dmitriy Govorukhin 
Date:   2018-10-16T10:18:39Z

IGNITE-9898 fix checkpoint thread hangs on await async task completion

Signed-off-by: Dmitriy Govorukhin 




---

[GitHub] ignite pull request #4994: IGNITE-9889: Add JavaDoc group for TensorFlow.

[asfgit]

Github user asfgit closed the pull request at:

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


---

[jira] [Created] (IGNITE-9899) Continuous query handlers are not called on backups when one-phase commit is used

[Denis Mekhanikov (JIRA)]

Denis Mekhanikov created IGNITE-9899:


 Summary: Continuous query handlers are not called on backups when 
one-phase commit is used
 Key: IGNITE-9899
 URL: https://issues.apache.org/jira/browse/IGNITE-9899
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.6
Reporter: Denis Mekhanikov
Assignee: Denis Mekhanikov
 Attachments: CacheContinuousQueryTxBackupTest.java

Consider the following cache configuration:
 * Atomicity mode: Transactional
 * Cache mode: Partitioned
 * Backups: 1

If a continuous query is registered for such cache, then it's not processed on 
backup copies. It results in remote filters not being called on backups and 
lost events on changing topology.

Test case is attached: [^CacheContinuousQueryTxBackupTest.java]



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

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

[Alexey Goncharuk]

Last two runs are green, let's keep monitoring.

пн, 15 окт. 2018 г. в 3:25, :

> Hi Igniters,
>
>  I've detected some new issue on TeamCity to be handled. You are more than
> welcomed to help.
>
>  If your changes can lead to this failure(s): We're grateful that you were
> a volunteer to make the contribution to this project, but things change and
> you may no longer be able to finalize your contribution.
>  Could you respond to this email and indicate if you wish to continue and
> fix test failures or step down and some committer may revert you commit.
>
>  *New stable failure of a flaky test in master
> HadoopMapReduceErrorResilienceTest.testRecoveryAfterAnError0_Error
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=2414028243453692891&branch=%3Cdefault%3E&tab=testDetails
>  Changes may lead to failure were done by
>  - jokserfn
> http://ci.ignite.apache.org/viewModification.html?modId=834843&personal=false
>  - aplatonovv
> http://ci.ignite.apache.org/viewModification.html?modId=834837&personal=false
>  - kondakov87
> http://ci.ignite.apache.org/viewModification.html?modId=834798&personal=false
>  - mr.weider
> http://ci.ignite.apache.org/viewModification.html?modId=834773&personal=false
>  - tledkov
> http://ci.ignite.apache.org/viewModification.html?modId=834768&personal=false
>
>  - Here's a reminder of what contributors were agreed to do
> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
>  - Should you have any questions please contact
> dev@ignite.apache.org
>
> Best Regards,
> Apache Ignite TeamCity Bot
> https://github.com/apache/ignite-teamcity-bot
> Notification generated at 03:25:42 15-10-2018
>

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

[Alexey Goncharuk]

The test is flaky.

сб, 13 окт. 2018 г. в 23:10, :

> Hi Igniters,
>
>  I've detected some new issue on TeamCity to be handled. You are more than
> welcomed to help.
>
>  If your changes can lead to this failure(s): We're grateful that you were
> a volunteer to make the contribution to this project, but things change and
> you may no longer be able to finalize your contribution.
>  Could you respond to this email and indicate if you wish to continue and
> fix test failures or step down and some committer may revert you commit.
>
>  *New stable failure of a flaky test in master
> TcpDiscoverySslTrustedSelfTest.testNodeShutdownOnRingMessageWorkerStartNotFinished
>
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=4205209624038097982&branch=%3Cdefault%3E&tab=testDetails
>  No changes in the build
>
>  - Here's a reminder of what contributors were agreed to do
> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
>  - Should you have any questions please contact
> dev@ignite.apache.org
>
> Best Regards,
> Apache Ignite TeamCity Bot
> https://github.com/apache/ignite-teamcity-bot
> Notification generated at 23:10:37 13-10-2018
>

Re: Apache Ignite 2.7. Last Mile

[Nikolay Izhikov]

Hello, Igniters.

We have 13 tickets mapped to 2.7.
All tickets assigned to some contributor.

Alexey Gonchruk - IGNITE-9784, IGNITE-9895
Vladimir Ozerov - IGNITE-9887
Dmitriy Govorukhin - IGNITE-9898
Andrey Kuznetsov   - IGNITE-9737, IGNITE-9710
Petr Ivanov - IGNITE-9852
Ivan Pavlukhin - IGNITE-5935
Alexey Stelmak - IGNITE-9776
Roman Kondakov - IGNITE-9663
Taras Ledkov - IGNITE-9864
Igor Seliverstov   - IGNITE-9292

В Пн, 15/10/2018 в 17:49 +0300, Andrey Gura пишет:
> Nikolay,
> 
> I'm looking at IGNITE-9737 and IGNITE-9710 which are critical issues
> from my point of view.
> I need some time for review, possible fixes and merge.
> I will keep you informed.
> On Mon, Oct 15, 2018 at 1:46 PM Igor Sapego  wrote:
> > 
> > Guys, Python client is in the master and ignite-2.7 already.
> > 
> > Best Regards,
> > Igor
> > 
> > 
> > On Mon, Oct 15, 2018 at 11:33 AM Vladimir Ozerov 
> > wrote:
> > 
> > > Nikolay,
> > > 
> > > AI 2.7 will include Python thin client. TC suite is crucial part of this
> > > feature, so we should keep the ticket in AI 2.7 scope.
> > > 
> > > On Mon, Oct 15, 2018 at 10:57 AM Nikolay Izhikov 
> > > wrote:
> > > 
> > > > Hello, Igniters.
> > > > 
> > > > There is no progress till Friday.
> > > > We have 14 tickets mapped to 2.7.
> > > > 
> > > > В Пт, 12/10/2018 в 08:29 +0300, Nikolay Izhikov пишет:
> > > > > Hello, Igniters.
> > > > > 
> > > > > We made some progress yesterday.
> > > > > 
> > > > > Please, note, we have 1 new ticket mapped to 2.7 "IGNITE-9852: Create
> > > > 
> > > > TeamCity suite for Python thin client"
> > > > > 
> > > > > This ticket doesn't sound like a blocker to me. Let's exclude it from
> > > > 
> > > > release scope.
> > > > > Thoughts?
> > > > > 
> > > > > Here is the list of remaining tickets(14) mapped to 2.7.
> > > > > 
> > > > > Peter Ivanov - IGNITE-9852, IGNITE-9685,
> > > > > Alexey Goncharuk   - IGNITE-9784
> > > > > Andrey Kuznetsov   - IGNITE-9737, IGNITE-9710
> > > > > Igor Seliverstov   - IGNITE-9749, IGNITE-9292
> > > > > Dmitry Melnichuk   - IGNITE-7782
> > > > > Ivan Pavlukhin - IGNITE-5935
> > > > > Yury Babak - IGNITE-8670
> > > > > Roman Kondakov - IGNITE-7953
> > > > > Igor Sapego  - IGNITE-9620
> > > > > Alexey Stelmak - IGNITE-9776
> > > > > 
> > > > > Unassigned:
> > > > > 
> > > > > IGNITE-9663 - MVCC: Data node failure can cause TX hanging.
> > > > > 
> > > > > 
> > > > > В Чт, 11/10/2018 в 13:50 +0300, Nikolay Izhikov пишет:
> > > > > > Alexey, we all agreed to merge in 2.7 blockers only.
> > > > > > 
> > > > > > Is this a blocker?
> > > > > > 
> > > > > > Anyway, you are more experienced Igniter that I am.
> > > > > > If you think we should include this ticket to 2.7 - please, do it.
> > > > > > 
> > > > > > В Чт, 11/10/2018 в 13:08 +0300, Alexey Goncharuk пишет:
> > > > > > > Nikolay,
> > > > > > > 
> > > > > > > I am waiting for final benchmark results for 9784, after that I
> > > 
> > > will
> > > > merge
> > > > > > > the change.
> > > > > > > 
> > > > > > > On the subject of Ignite 2.7 scope, our fellow Igniter Alexey
> > > > 
> > > > Platonov have
> > > > > > > found another case when a failure handler is incorrectly called on
> > > > 
> > > > node
> > > > > > > stop: https://issues.apache.org/jira/browse/IGNITE-9834. The case
> > > > 
> > > > is rare,
> > > > > > > but it is quite an unpleasant UX. Should we include it to 2.7 as
> > > > 
> > > > well?
> > > > > > > 
> > > > > > > чт, 11 окт. 2018 г. в 11:22, Nikolay Izhikov  > > > 
> > > > :
> > > > > > > 
> > > > > > > > Hello, Igniters.
> > > > > > > > 
> > > > > > > > We made a good progress yesterday.
> > > > > > > > 
> > > > > > > > Here is the list of remaining tickets(17) mapped to 2.7:
> > > > > > > > 
> > > > > > > > Alexey Goncharuk   - IGNITE-9784
> > > > > > > > Taras Ledkov   - IGNITE-9171
> > > > > > > > Andrey Kuznetsov   - IGNITE-9737, IGNITE-9710
> > > > > > > > Peter Ivanov   - IGNITE-9583, IGNITE-9823, IGNITE-9685
> > > > > > > > Igor Seliverstov   - IGNITE-9749, IGNITE-9292
> > > > > > > > Dmitry Melnichuk   - IGNITE-7782
> > > > > > > > Ivan Pavlukhin - IGNITE-5935
> > > > > > > > Yury Babak - IGNITE-8670
> > > > > > > > Roman Kondakov - IGNITE-7953, IGNITE-9446
> > > > > > > > Alexey Stelmak - IGNITE-9776
> > > > > > > > 
> > > > > > > > Unassigned:
> > > > > > > > 
> > > > > > > > IGNITE-9620 - MVCC: select throwing `Transaction is already
> > > > 
> > > > completed`> >
> > > > > > > > > exception after mvcc missmatch
> > > > > > > > 
> > > > > > > > IGNITE-9663 - MVCC: Data node failure can cause TX hanging.
> > > > > > > > 
> > > > > > > > 
> > > > > > > > В Чт, 11/10/2018 в 10:40 +0300, Vladimir Ozerov пишет:
> > > > > > > > > What kind of help is needed?
> > > > > > > > > 
> > > > > > > > > On Wed, Oct 10, 2018 at 11:51 PM Dmitriy Setrakyan <
> > > > > > > > 
> > > > > > > > dsetrak...@apache.org>
> > > > > > > > > wrote:
> > > > > > > > > 
> > > > > > > > > > Vladimir Ozerov,
> > > > > > >

[GitHub] ignite pull request #4999: IGNITE-9887

[devozerov]

Github user devozerov closed the pull request at:

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


---

[GitHub] ignite pull request #5003: IGNITE-9882: investigation progress 1

[tledkov-gridgain]

GitHub user tledkov-gridgain opened a pull request:

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

IGNITE-9882: investigation progress 1



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

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

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

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


commit bf50cc64b535dd79b2c0c1754aa6d82cde49f8b9
Author: tledkov-gridgain 
Date:   2018-10-16T11:46:28Z

IGNITE-9882: investigation progress 1




---

[GitHub] ignite pull request #4973: IGNITE-9864: fix .net query SQL tests

[asfgit]

Github user asfgit closed the pull request at:

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


---

[jira] [Created] (IGNITE-9900) Upgrade annotations.jar to a new version

[Stanislav Lukyanov (JIRA)]

Stanislav Lukyanov created IGNITE-9900:
--

 Summary: Upgrade annotations.jar to a new version
 Key: IGNITE-9900
 URL: https://issues.apache.org/jira/browse/IGNITE-9900
 Project: Ignite
  Issue Type: Improvement
Reporter: Stanislav Lukyanov
Assignee: Stanislav Lukyanov


OWASP Dependency Check reports that annotations.jar of version 13.0 is affected 
by vulnerability CVE-2017-8316,
while it obviously isn't (the CVE is about XXE attack, and annotations.jar is, 
well, annotations).

The issue is that NVD database only says that "intellij_idea" is affected, and 
OWASP doesn't know better than to map annotations.jar to the intellij_idea 
product.

While the problem could be (and perhaps will be, see 
https://youtrack.jetbrains.com/issue/IDEA-200601) sorted out on the level of 
OWASP and NVD, the easiest way to workaround this is to upgrade annotations.jar 
to a new version (currently 16.0.3). It will help Ignite users to avoid 
annoying false-positive warnings from OWASP.



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

[GitHub] ignite pull request #4984: IGNITE-9292 MVCC SQL: Unexpected state exception ...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] ignite pull request #4548: IGNITE-9234 fixed javadocs

[asfgit]

Github user asfgit closed the pull request at:

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


---

RE: Applicability of term 'cache' to Apache Ignite

[Stanislav Lukyanov]

How about separating our JCache implementation from the core of the probuct.

Currently IgniteCache is the heart of Ignite. It is the basic storage unit.
At the same time, it is the direct implementation of the JCache API,
and some of the JCache features align somewhat awkwardly with Ignite concepts.

Would be nice to have something like IgniteSpace as our core component,
and have other components built on top of it as wrappers providing various APIs.
For example
- IgniteSpace itself is a distributed storage unit, that is partitioned, that 
has affinity, etc;
note that it doesn’t have to have ANY particular API to add data, even key-value
- IgniteCache is a wrapper around IgniteSpace that allows to store key-value 
pairs and implements JCache API
- IgniteSql (we’re doing it eventually, right?) is a wrapper around IgniteSpace 
that allows to store SQL tables and implements ANSI SQL
- IgniteQueue is a wrapper that implements Queue
and so on.

WDYT?

Stan

From: Ilya Lantukh
Sent: 15 октября 2018 г. 14:49
To: dev@ignite.apache.org
Subject: Applicability of term 'cache' to Apache Ignite

Hi Igniters,

I would like to rise a question how we use the term *'cache'* in Ignite and
how it corresponds to terminology in IT industry in general.

>From wikipedia:
In computing , a *cache* /kæʃ/
 *kash*
, is a
hardware or software component that stores data so that future requests for
that data can be served faster; the data stored in a cache might be the
result of an earlier computation or a copy of data stored elsewhere. [1]

When the first version of Ignite was released, this term was correct. We
positioned Ignite mostly as an intermediate storage layer between
application and a database, designed to make data access faster.

However, since addition of native persistence we started to call Ignite a
"memory-centric database", and as far as I know, some organizations now use
it as a primary data storage, without underlying database. In this case,
calling our storage unit a *'cache'* causes unnecessary confusion.

Thus, I suggest to rename IgniteCache in Ignite 3.0 to something that would
fit both use-cases.
Personally I like the term IgniteSpace.

[1] https://en.wikipedia.org/wiki/Cache_(computing)
-- 
Best regards,
Ilya

[jira] [Created] (IGNITE-9901) [TC Bot] Exclude losses of visa requests while TC Bot server reloading

[PetrovMikhail (JIRA)]

PetrovMikhail created IGNITE-9901:
-

 Summary: [TC Bot] Exclude losses of visa requests while TC Bot 
server reloading
 Key: IGNITE-9901
 URL: https://issues.apache.org/jira/browse/IGNITE-9901
 Project: Ignite
  Issue Type: Task
Reporter: PetrovMikhail
Assignee: PetrovMikhail


Exclude losses of visa requests while TC Bot server reloading



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

[GitHub] ignite pull request #5004: IGNITE-9900: Upgrade annotations.jar to a new ver...

[slukyano]

GitHub user slukyano opened a pull request:

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

IGNITE-9900: Upgrade annotations.jar to a new version.



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

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

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

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


commit 2e9e6a3a21a117ca9a9ef2864f9e7e1541746388
Author: Stanislav Lukyanov 
Date:   2018-10-16T12:29:38Z

IGNITE-9900: Upgrade annotations.jar to a new version.




---

Re: Applicability of term 'cache' to Apache Ignite

[Vladimir Ozerov]

What is the ultimate goal of all these changes? While I agree that term
"cache" might be a bit outdated at the moment, there is nothing
fundamentally wrong with - data is still being cached in memory with an
option to persist it on disk. We should remember, that legacy and previous
user experience is of great importance for users. And disruptive changes
such as rename of a basic concept may make adoption of a new versions
harder for users, with very questionable benefits on the other side.

As far as wrappers, personally I do not support this idea. Both "cache" and
"sql" are access methods to some information ("space"), rather than
wrappers around it. Moreover, it is hard to say whether we will have SQL
API at all, because this is big effort with not very clear value, provided
that there are industrial interfaces (JDBC, ODBC).

On Tue, Oct 16, 2018 at 3:23 PM Stanislav Lukyanov 
wrote:

> How about separating our JCache implementation from the core of the
> probuct.
>
> Currently IgniteCache is the heart of Ignite. It is the basic storage unit.
> At the same time, it is the direct implementation of the JCache API,
> and some of the JCache features align somewhat awkwardly with Ignite
> concepts.
>
> Would be nice to have something like IgniteSpace as our core component,
> and have other components built on top of it as wrappers providing various
> APIs.
> For example
> - IgniteSpace itself is a distributed storage unit, that is partitioned,
> that has affinity, etc;
> note that it doesn’t have to have ANY particular API to add data, even
> key-value
> - IgniteCache is a wrapper around IgniteSpace that allows to store
> key-value pairs and implements JCache API
> - IgniteSql (we’re doing it eventually, right?) is a wrapper around
> IgniteSpace that allows to store SQL tables and implements ANSI SQL
> - IgniteQueue is a wrapper that implements Queue
> and so on.
>
> WDYT?
>
> Stan
>
> From: Ilya Lantukh
> Sent: 15 октября 2018 г. 14:49
> To: dev@ignite.apache.org
> Subject: Applicability of term 'cache' to Apache Ignite
>
> Hi Igniters,
>
> I would like to rise a question how we use the term *'cache'* in Ignite and
> how it corresponds to terminology in IT industry in general.
>
> From wikipedia:
> In computing , a *cache* /kæʃ/
>  *kash*
> , is a
> hardware or software component that stores data so that future requests for
> that data can be served faster; the data stored in a cache might be the
> result of an earlier computation or a copy of data stored elsewhere. [1]
>
> When the first version of Ignite was released, this term was correct. We
> positioned Ignite mostly as an intermediate storage layer between
> application and a database, designed to make data access faster.
>
> However, since addition of native persistence we started to call Ignite a
> "memory-centric database", and as far as I know, some organizations now use
> it as a primary data storage, without underlying database. In this case,
> calling our storage unit a *'cache'* causes unnecessary confusion.
>
> Thus, I suggest to rename IgniteCache in Ignite 3.0 to something that would
> fit both use-cases.
> Personally I like the term IgniteSpace.
>
> [1] https://en.wikipedia.org/wiki/Cache_(computing)
> --
> Best regards,
> Ilya
>
>

[jira] [Created] (IGNITE-9902) ScanQuery doesn't take lost partitions into account when persistence is enabled

[Stanislav Lukyanov (JIRA)]

Stanislav Lukyanov created IGNITE-9902:
--

 Summary: ScanQuery doesn't take lost partitions into account when 
persistence is enabled
 Key: IGNITE-9902
 URL: https://issues.apache.org/jira/browse/IGNITE-9902
 Project: Ignite
  Issue Type: Bug
Reporter: Stanislav Lukyanov


Same as IGNITE-9841, but about scan queries.



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

Re: Apache Ignite 2.7. Last Mile

[Andrey Gura]

Hi,

I've found that IGNITE-9723 was resolved but didn't cherry picked to
ignite-2.7 branch. So I'll do it.
On Tue, Oct 16, 2018 at 2:30 PM Nikolay Izhikov  wrote:
>
> Hello, Igniters.
>
> We have 13 tickets mapped to 2.7.
> All tickets assigned to some contributor.
>
> Alexey Gonchruk - IGNITE-9784, IGNITE-9895
> Vladimir Ozerov - IGNITE-9887
> Dmitriy Govorukhin - IGNITE-9898
> Andrey Kuznetsov   - IGNITE-9737, IGNITE-9710
> Petr Ivanov - IGNITE-9852
> Ivan Pavlukhin - IGNITE-5935
> Alexey Stelmak - IGNITE-9776
> Roman Kondakov - IGNITE-9663
> Taras Ledkov - IGNITE-9864
> Igor Seliverstov   - IGNITE-9292
>
> В Пн, 15/10/2018 в 17:49 +0300, Andrey Gura пишет:
> > Nikolay,
> >
> > I'm looking at IGNITE-9737 and IGNITE-9710 which are critical issues
> > from my point of view.
> > I need some time for review, possible fixes and merge.
> > I will keep you informed.
> > On Mon, Oct 15, 2018 at 1:46 PM Igor Sapego  wrote:
> > >
> > > Guys, Python client is in the master and ignite-2.7 already.
> > >
> > > Best Regards,
> > > Igor
> > >
> > >
> > > On Mon, Oct 15, 2018 at 11:33 AM Vladimir Ozerov 
> > > wrote:
> > >
> > > > Nikolay,
> > > >
> > > > AI 2.7 will include Python thin client. TC suite is crucial part of this
> > > > feature, so we should keep the ticket in AI 2.7 scope.
> > > >
> > > > On Mon, Oct 15, 2018 at 10:57 AM Nikolay Izhikov 
> > > > wrote:
> > > >
> > > > > Hello, Igniters.
> > > > >
> > > > > There is no progress till Friday.
> > > > > We have 14 tickets mapped to 2.7.
> > > > >
> > > > > В Пт, 12/10/2018 в 08:29 +0300, Nikolay Izhikov пишет:
> > > > > > Hello, Igniters.
> > > > > >
> > > > > > We made some progress yesterday.
> > > > > >
> > > > > > Please, note, we have 1 new ticket mapped to 2.7 "IGNITE-9852: 
> > > > > > Create
> > > > >
> > > > > TeamCity suite for Python thin client"
> > > > > >
> > > > > > This ticket doesn't sound like a blocker to me. Let's exclude it 
> > > > > > from
> > > > >
> > > > > release scope.
> > > > > > Thoughts?
> > > > > >
> > > > > > Here is the list of remaining tickets(14) mapped to 2.7.
> > > > > >
> > > > > > Peter Ivanov - IGNITE-9852, IGNITE-9685,
> > > > > > Alexey Goncharuk   - IGNITE-9784
> > > > > > Andrey Kuznetsov   - IGNITE-9737, IGNITE-9710
> > > > > > Igor Seliverstov   - IGNITE-9749, IGNITE-9292
> > > > > > Dmitry Melnichuk   - IGNITE-7782
> > > > > > Ivan Pavlukhin - IGNITE-5935
> > > > > > Yury Babak - IGNITE-8670
> > > > > > Roman Kondakov - IGNITE-7953
> > > > > > Igor Sapego  - IGNITE-9620
> > > > > > Alexey Stelmak - IGNITE-9776
> > > > > >
> > > > > > Unassigned:
> > > > > >
> > > > > > IGNITE-9663 - MVCC: Data node failure can cause TX hanging.
> > > > > >
> > > > > >
> > > > > > В Чт, 11/10/2018 в 13:50 +0300, Nikolay Izhikov пишет:
> > > > > > > Alexey, we all agreed to merge in 2.7 blockers only.
> > > > > > >
> > > > > > > Is this a blocker?
> > > > > > >
> > > > > > > Anyway, you are more experienced Igniter that I am.
> > > > > > > If you think we should include this ticket to 2.7 - please, do it.
> > > > > > >
> > > > > > > В Чт, 11/10/2018 в 13:08 +0300, Alexey Goncharuk пишет:
> > > > > > > > Nikolay,
> > > > > > > >
> > > > > > > > I am waiting for final benchmark results for 9784, after that I
> > > >
> > > > will
> > > > > merge
> > > > > > > > the change.
> > > > > > > >
> > > > > > > > On the subject of Ignite 2.7 scope, our fellow Igniter Alexey
> > > > >
> > > > > Platonov have
> > > > > > > > found another case when a failure handler is incorrectly called 
> > > > > > > > on
> > > > >
> > > > > node
> > > > > > > > stop: https://issues.apache.org/jira/browse/IGNITE-9834. The 
> > > > > > > > case
> > > > >
> > > > > is rare,
> > > > > > > > but it is quite an unpleasant UX. Should we include it to 2.7 as
> > > > >
> > > > > well?
> > > > > > > >
> > > > > > > > чт, 11 окт. 2018 г. в 11:22, Nikolay Izhikov 
> > > > > > > >  > > > >
> > > > > :
> > > > > > > >
> > > > > > > > > Hello, Igniters.
> > > > > > > > >
> > > > > > > > > We made a good progress yesterday.
> > > > > > > > >
> > > > > > > > > Here is the list of remaining tickets(17) mapped to 2.7:
> > > > > > > > >
> > > > > > > > > Alexey Goncharuk   - IGNITE-9784
> > > > > > > > > Taras Ledkov   - IGNITE-9171
> > > > > > > > > Andrey Kuznetsov   - IGNITE-9737, IGNITE-9710
> > > > > > > > > Peter Ivanov   - IGNITE-9583, IGNITE-9823, IGNITE-9685
> > > > > > > > > Igor Seliverstov   - IGNITE-9749, IGNITE-9292
> > > > > > > > > Dmitry Melnichuk   - IGNITE-7782
> > > > > > > > > Ivan Pavlukhin - IGNITE-5935
> > > > > > > > > Yury Babak - IGNITE-8670
> > > > > > > > > Roman Kondakov - IGNITE-7953, IGNITE-9446
> > > > > > > > > Alexey Stelmak - IGNITE-9776
> > > > > > > > >
> > > > > > > > > Unassigned:
> > > > > > > > >
> > > > > > > > > IGNITE-9620 - MVCC: select throwing `Transaction is already
> > > > >
> > > > > completed`> >
> > > > > > > > > > exception after mvcc missmatch
> > > > > > > 

Re: Applicability of term 'cache' to Apache Ignite

[Ilya Lantukh]

To me it seems that usage of term *"cache" *restricts adoption of Apache
Ignite as a primary data storage. If I didn't know anything about internal
implementation, storing critical data in IgniteCache would make me feel
that I'm doing something wrong. Of course it's just my point of view, and
things might look different for other Ignite users - so I'd like to ask
community members to share their opinion.


On Tue, Oct 16, 2018 at 3:54 PM Vladimir Ozerov 
wrote:

> What is the ultimate goal of all these changes? While I agree that term
> "cache" might be a bit outdated at the moment, there is nothing
> fundamentally wrong with - data is still being cached in memory with an
> option to persist it on disk. We should remember, that legacy and previous
> user experience is of great importance for users. And disruptive changes
> such as rename of a basic concept may make adoption of a new versions
> harder for users, with very questionable benefits on the other side.
>
> As far as wrappers, personally I do not support this idea. Both "cache" and
> "sql" are access methods to some information ("space"), rather than
> wrappers around it. Moreover, it is hard to say whether we will have SQL
> API at all, because this is big effort with not very clear value, provided
> that there are industrial interfaces (JDBC, ODBC).
>
> On Tue, Oct 16, 2018 at 3:23 PM Stanislav Lukyanov  >
> wrote:
>
> > How about separating our JCache implementation from the core of the
> > probuct.
> >
> > Currently IgniteCache is the heart of Ignite. It is the basic storage
> unit.
> > At the same time, it is the direct implementation of the JCache API,
> > and some of the JCache features align somewhat awkwardly with Ignite
> > concepts.
> >
> > Would be nice to have something like IgniteSpace as our core component,
> > and have other components built on top of it as wrappers providing
> various
> > APIs.
> > For example
> > - IgniteSpace itself is a distributed storage unit, that is partitioned,
> > that has affinity, etc;
> > note that it doesn’t have to have ANY particular API to add data, even
> > key-value
> > - IgniteCache is a wrapper around IgniteSpace that allows to store
> > key-value pairs and implements JCache API
> > - IgniteSql (we’re doing it eventually, right?) is a wrapper around
> > IgniteSpace that allows to store SQL tables and implements ANSI SQL
> > - IgniteQueue is a wrapper that implements Queue
> > and so on.
> >
> > WDYT?
> >
> > Stan
> >
> > From: Ilya Lantukh
> > Sent: 15 октября 2018 г. 14:49
> > To: dev@ignite.apache.org
> > Subject: Applicability of term 'cache' to Apache Ignite
> >
> > Hi Igniters,
> >
> > I would like to rise a question how we use the term *'cache'* in Ignite
> and
> > how it corresponds to terminology in IT industry in general.
> >
> > From wikipedia:
> > In computing , a *cache* /kæʃ/
> >  *kash*
> > , is a
> > hardware or software component that stores data so that future requests
> for
> > that data can be served faster; the data stored in a cache might be the
> > result of an earlier computation or a copy of data stored elsewhere. [1]
> >
> > When the first version of Ignite was released, this term was correct. We
> > positioned Ignite mostly as an intermediate storage layer between
> > application and a database, designed to make data access faster.
> >
> > However, since addition of native persistence we started to call Ignite a
> > "memory-centric database", and as far as I know, some organizations now
> use
> > it as a primary data storage, without underlying database. In this case,
> > calling our storage unit a *'cache'* causes unnecessary confusion.
> >
> > Thus, I suggest to rename IgniteCache in Ignite 3.0 to something that
> would
> > fit both use-cases.
> > Personally I like the term IgniteSpace.
> >
> > [1] https://en.wikipedia.org/wiki/Cache_(computing)
> > --
> > Best regards,
> > Ilya
> >
> >
>


-- 
Best regards,
Ilya

Re: Applicability of term 'cache' to Apache Ignite

[Ivan Rakov]

Agree with Vladimir here.

Let's stick to the "principle of least astonishment" - all current users 
will be surprised if we'll rename IgniteCache, new users won't be 
greatly surprised due to compliance with JCache.


Best Regards,
Ivan Rakov

On 16.10.2018 15:53, Vladimir Ozerov wrote:

What is the ultimate goal of all these changes? While I agree that term
"cache" might be a bit outdated at the moment, there is nothing
fundamentally wrong with - data is still being cached in memory with an
option to persist it on disk. We should remember, that legacy and previous
user experience is of great importance for users. And disruptive changes
such as rename of a basic concept may make adoption of a new versions
harder for users, with very questionable benefits on the other side.

As far as wrappers, personally I do not support this idea. Both "cache" and
"sql" are access methods to some information ("space"), rather than
wrappers around it. Moreover, it is hard to say whether we will have SQL
API at all, because this is big effort with not very clear value, provided
that there are industrial interfaces (JDBC, ODBC).

On Tue, Oct 16, 2018 at 3:23 PM Stanislav Lukyanov 
wrote:


How about separating our JCache implementation from the core of the
probuct.

Currently IgniteCache is the heart of Ignite. It is the basic storage unit.
At the same time, it is the direct implementation of the JCache API,
and some of the JCache features align somewhat awkwardly with Ignite
concepts.

Would be nice to have something like IgniteSpace as our core component,
and have other components built on top of it as wrappers providing various
APIs.
For example
- IgniteSpace itself is a distributed storage unit, that is partitioned,
that has affinity, etc;
note that it doesn’t have to have ANY particular API to add data, even
key-value
- IgniteCache is a wrapper around IgniteSpace that allows to store
key-value pairs and implements JCache API
- IgniteSql (we’re doing it eventually, right?) is a wrapper around
IgniteSpace that allows to store SQL tables and implements ANSI SQL
- IgniteQueue is a wrapper that implements Queue
and so on.

WDYT?

Stan

From: Ilya Lantukh
Sent: 15 октября 2018 г. 14:49
To: dev@ignite.apache.org
Subject: Applicability of term 'cache' to Apache Ignite

Hi Igniters,

I would like to rise a question how we use the term *'cache'* in Ignite and
how it corresponds to terminology in IT industry in general.

 From wikipedia:
In computing , a *cache* /kæʃ/
 *kash*
, is a
hardware or software component that stores data so that future requests for
that data can be served faster; the data stored in a cache might be the
result of an earlier computation or a copy of data stored elsewhere. [1]

When the first version of Ignite was released, this term was correct. We
positioned Ignite mostly as an intermediate storage layer between
application and a database, designed to make data access faster.

However, since addition of native persistence we started to call Ignite a
"memory-centric database", and as far as I know, some organizations now use
it as a primary data storage, without underlying database. In this case,
calling our storage unit a *'cache'* causes unnecessary confusion.

Thus, I suggest to rename IgniteCache in Ignite 3.0 to something that would
fit both use-cases.
Personally I like the term IgniteSpace.

[1] https://en.wikipedia.org/wiki/Cache_(computing)
--
Best regards,
Ilya

[GitHub] ignite pull request #5005: IGNITE-9659

[NSAmelchev]

GitHub user NSAmelchev opened a pull request:

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

IGNITE-9659

Fix the _NonCollocatedRetryMessageSelfTest.testNonCollocatedRetryMessage_ 
test.

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

$ git pull https://github.com/NSAmelchev/ignite ignite-9659

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

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


commit dc5a776ea3d1634533bcae3f09931d0beb23cfab
Author: NSAmelchev 
Date:   2018-10-16T13:54:06Z

Fix the testNonCollocatedRetryMessage test.

commit dfa7d661d14899d3a31f71fd70c589bc9d254272
Author: NSAmelchev 
Date:   2018-10-16T14:34:16Z

Code style fix.




---

[GitHub] ignite pull request #4995: IGNITE-9891: SQLTables fix for ODBC

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] ignite pull request #5000: IGNITE-9895 DiscoveryMessageNotifierWorker must b...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] ignite pull request #5006: Ignite 9881

[aealeksandrov]

GitHub user aealeksandrov opened a pull request:

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

Ignite 9881

New events for the handling of the tasks that were started on web console 
or visor could be helpful for tracking the user activities.

At the moment all events will be handled as data node events. So it could 
be difficult to understand why they were fired in case if it was done on web 
console or visor.

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

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

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

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


commit ba7a28f103df80c2dde91a3badf30d9b14ed021c
Author: Andrei Aleksandrov 
Date:   2018-10-16T15:08:28Z

IGNITE-9881 EVT_VISOR_TASK_STARTED event was added for handling of the 
tasks that were started on web console or visor

commit ff21ca8f5c9c04ac0b7bd54dcf9678e1564a07d4
Author: Andrei Aleksandrov 
Date:   2018-10-16T15:16:43Z

IGNITE-9881 EVT_VISOR_TASK_STARTED remain part of implementation

commit d3b5e2f52b1b445d42f344e6883864929466e67a
Author: Andrei Aleksandrov 
Date:   2018-10-16T15:21:02Z

IGNITE-9881 removed extra imports




---

[GitHub] ignite pull request #4944: IGNITE-9430 Introduce IGNITE_REBALANCE_THROTTLE_O...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[jira] [Created] (IGNITE-9903) Copy only actual amount of data during archiving of WAL segment

[Andrey Gura (JIRA)]

Andrey Gura created IGNITE-9903:
---

 Summary: Copy only actual amount of data during archiving of WAL 
segment
 Key: IGNITE-9903
 URL: https://issues.apache.org/jira/browse/IGNITE-9903
 Project: Ignite
  Issue Type: Improvement
Reporter: Andrey Gura
Assignee: Andrey Gura
 Fix For: 2.8


Current WAL archiver implementation copies full WAL segment to the archive 
while actual size of the segment can be significantly less then 
{{maxWalSegmentSize}} (segment files are preallocated for max possible segment 
size). 

In order to reduce disk space consuming we need copy only actual data of 
segment using {{SWITCH_SEGMENT_RECORD}} as marker. It will require some kind of 
WAL iterator implementation that will just copy WAL records using information 
about record size without records deserialization.



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

Abbreviation code-style requirement.

[Eduard Shangareev]

Igniters,

I want to discuss the appendix of our code-style:
https://cwiki.apache.org/confluence/display/IGNITE/Abbreviation+Rules.

First of all, there is no any mention that it is a mandatory part.

Secondly, some of them are very unintuitive and even misleading. For
example, cp. In current realization, it could mean not only copy but
checkpoint. Other example, proto... Would you get that it is protocol?

Thirdly, the recommended plugin highlights even parts of multiword names.
It provokes to used creepy names as
locCpPartitionsInProgress, needCpPartitions and so on.

So, I want to start a discussion for
1. revising the list of abbreviations,
2. stop using them for multi-word names,
3. and make them not mandatory at all (what it is actually already true,
because of no any mention in the main code-style article).

[jira] [Created] (IGNITE-9904) CPP Thin: Implement atomic part of Cache API for C++ thin client

[Igor Sapego (JIRA)]

Igor Sapego created IGNITE-9904:
---

 Summary: CPP Thin: Implement atomic part of Cache API for C++ thin 
client
 Key: IGNITE-9904
 URL: https://issues.apache.org/jira/browse/IGNITE-9904
 Project: Ignite
  Issue Type: New Feature
  Components: thin client
Reporter: Igor Sapego
 Fix For: 2.8






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

Re: Abbreviation code-style requirement.

[Denis Mekhanikov]

+1

I'm for long and descriptive names over short and counterintuitive.
I think, abbreviations shouldn't be mandatory, as they often obscure the
meaning of used names.

One-letter abbreviations should be removed from the list at all.
When I see a variable *c*, I can't tell, whether it's a char, collection,
callable or a closure, even if I remember the rules by heart.

Denis

вт, 16 окт. 2018 г. в 19:01, Eduard Shangareev :

> Igniters,
>
> I want to discuss the appendix of our code-style:
> https://cwiki.apache.org/confluence/display/IGNITE/Abbreviation+Rules.
>
> First of all, there is no any mention that it is a mandatory part.
>
> Secondly, some of them are very unintuitive and even misleading. For
> example, cp. In current realization, it could mean not only copy but
> checkpoint. Other example, proto... Would you get that it is protocol?
>
> Thirdly, the recommended plugin highlights even parts of multiword names.
> It provokes to used creepy names as
> locCpPartitionsInProgress, needCpPartitions and so on.
>
> So, I want to start a discussion for
> 1. revising the list of abbreviations,
> 2. stop using them for multi-word names,
> 3. and make them not mandatory at all (what it is actually already true,
> because of no any mention in the main code-style article).
>

Re: Abbreviation code-style requirement.

[Pavel Kovalenko]

Eduard,

+1 for that topic.

I don't see any reasons to use these abbreviations at all and vote to
deprecate them.
If anybody can explain why we still need them (less number of letters in
variable names is not an argument) we can discuss and revisit the current
list.
>From my side of view, these abbreviations just worsen readability of code
and don't give any major benefits.

вт, 16 окт. 2018 г. в 19:01, Eduard Shangareev :

> Igniters,
>
> I want to discuss the appendix of our code-style:
> https://cwiki.apache.org/confluence/display/IGNITE/Abbreviation+Rules.
>
> First of all, there is no any mention that it is a mandatory part.
>
> Secondly, some of them are very unintuitive and even misleading. For
> example, cp. In current realization, it could mean not only copy but
> checkpoint. Other example, proto... Would you get that it is protocol?
>
> Thirdly, the recommended plugin highlights even parts of multiword names.
> It provokes to used creepy names as
> locCpPartitionsInProgress, needCpPartitions and so on.
>
> So, I want to start a discussion for
> 1. revising the list of abbreviations,
> 2. stop using them for multi-word names,
> 3. and make them not mandatory at all (what it is actually already true,
> because of no any mention in the main code-style article).
>

Re: Abbreviation code-style requirement.

[Anton Kalashnikov]

+1

Eduard, I totally agree with you that it is misleading. I believe 
developer/reviewer able to choose convenient name in each particular case by 
themself. In my opinion abbreviation should be not mandatory.

-- 
Best regards,
Anton Kalashnikov


16.10.2018, 19:01, "Eduard Shangareev" :
> Igniters,
>
> I want to discuss the appendix of our code-style:
> https://cwiki.apache.org/confluence/display/IGNITE/Abbreviation+Rules.
>
> First of all, there is no any mention that it is a mandatory part.
>
> Secondly, some of them are very unintuitive and even misleading. For
> example, cp. In current realization, it could mean not only copy but
> checkpoint. Other example, proto... Would you get that it is protocol?
>
> Thirdly, the recommended plugin highlights even parts of multiword names.
> It provokes to used creepy names as
> locCpPartitionsInProgress, needCpPartitions and so on.
>
> So, I want to start a discussion for
> 1. revising the list of abbreviations,
> 2. stop using them for multi-word names,
> 3. and make them not mandatory at all (what it is actually already true,
> because of no any mention in the main code-style article).

RE: Abbreviation code-style requirement.

[Stanislav Lukyanov]

+ for all three.

I got used to seeing `cctx` and `ccfg` all over the place, but I remember the 
sorrow of seeing all of that the first time.
I guess it’s nothing but a Stockholm syndrome now and I’m willing to cure 
myself :)

Stan

From: Eduard Shangareev
Sent: 16 октября 2018 г. 19:01
To: dev@ignite.apache.org
Subject: Abbreviation code-style requirement.

Igniters,

I want to discuss the appendix of our code-style:
https://cwiki.apache.org/confluence/display/IGNITE/Abbreviation+Rules.

First of all, there is no any mention that it is a mandatory part.

Secondly, some of them are very unintuitive and even misleading. For
example, cp. In current realization, it could mean not only copy but
checkpoint. Other example, proto... Would you get that it is protocol?

Thirdly, the recommended plugin highlights even parts of multiword names.
It provokes to used creepy names as
locCpPartitionsInProgress, needCpPartitions and so on.

So, I want to start a discussion for
1. revising the list of abbreviations,
2. stop using them for multi-word names,
3. and make them not mandatory at all (what it is actually already true,
because of no any mention in the main code-style article).

Re: Abbreviation code-style requirement.

[Alexey Kuznetsov]

Ed, and All.

I'm "+1" for "revising the list of abbreviations,"

How about to have only 5-10 nice (proven) abbreviations and let developers
to name variables using common sense?

So, I want to start a discussion for
> 1. revising the list of abbreviations,
> 2. stop using them for multi-word names,
> 3. and make them not mandatory at all (what it is actually already true,
> because of no any mention in the main code-style article).
>
>

-- 
Alexey Kuznetsov

Re: Applicability of term 'cache' to Apache Ignite

[Dmitriy Setrakyan]

Although I agree that this change is disruptive, can we just entertain
Ilya's idea for a bit? What if we were designing Ignite from scratch, what
different name would we give to the IgniteCache abstraction? Ilya suggested
"IgniteSpace", but I do not like it as it sounds too similar to JavaSpaces
[1], which is an obsolete technology at this point.

Any other ideas?

[1] https://www.oracle.com/technetwork/articles/java/javaspaces-140665.html

D.

On Tue, Oct 16, 2018 at 6:27 AM Ivan Rakov  wrote:

> Agree with Vladimir here.
>
> Let's stick to the "principle of least astonishment" - all current users
> will be surprised if we'll rename IgniteCache, new users won't be
> greatly surprised due to compliance with JCache.
>
> Best Regards,
> Ivan Rakov
>
> On 16.10.2018 15:53, Vladimir Ozerov wrote:
> > What is the ultimate goal of all these changes? While I agree that term
> > "cache" might be a bit outdated at the moment, there is nothing
> > fundamentally wrong with - data is still being cached in memory with an
> > option to persist it on disk. We should remember, that legacy and
> previous
> > user experience is of great importance for users. And disruptive changes
> > such as rename of a basic concept may make adoption of a new versions
> > harder for users, with very questionable benefits on the other side.
> >
> > As far as wrappers, personally I do not support this idea. Both "cache"
> and
> > "sql" are access methods to some information ("space"), rather than
> > wrappers around it. Moreover, it is hard to say whether we will have SQL
> > API at all, because this is big effort with not very clear value,
> provided
> > that there are industrial interfaces (JDBC, ODBC).
> >
> > On Tue, Oct 16, 2018 at 3:23 PM Stanislav Lukyanov <
> stanlukya...@gmail.com>
> > wrote:
> >
> >> How about separating our JCache implementation from the core of the
> >> probuct.
> >>
> >> Currently IgniteCache is the heart of Ignite. It is the basic storage
> unit.
> >> At the same time, it is the direct implementation of the JCache API,
> >> and some of the JCache features align somewhat awkwardly with Ignite
> >> concepts.
> >>
> >> Would be nice to have something like IgniteSpace as our core component,
> >> and have other components built on top of it as wrappers providing
> various
> >> APIs.
> >> For example
> >> - IgniteSpace itself is a distributed storage unit, that is partitioned,
> >> that has affinity, etc;
> >> note that it doesn’t have to have ANY particular API to add data, even
> >> key-value
> >> - IgniteCache is a wrapper around IgniteSpace that allows to store
> >> key-value pairs and implements JCache API
> >> - IgniteSql (we’re doing it eventually, right?) is a wrapper around
> >> IgniteSpace that allows to store SQL tables and implements ANSI SQL
> >> - IgniteQueue is a wrapper that implements Queue
> >> and so on.
> >>
> >> WDYT?
> >>
> >> Stan
> >>
> >> From: Ilya Lantukh
> >> Sent: 15 октября 2018 г. 14:49
> >> To: dev@ignite.apache.org
> >> Subject: Applicability of term 'cache' to Apache Ignite
> >>
> >> Hi Igniters,
> >>
> >> I would like to rise a question how we use the term *'cache'* in Ignite
> and
> >> how it corresponds to terminology in IT industry in general.
> >>
> >>  From wikipedia:
> >> In computing , a *cache* /kæʃ/
> >>  *kash*
> >> , is a
> >> hardware or software component that stores data so that future requests
> for
> >> that data can be served faster; the data stored in a cache might be the
> >> result of an earlier computation or a copy of data stored elsewhere. [1]
> >>
> >> When the first version of Ignite was released, this term was correct. We
> >> positioned Ignite mostly as an intermediate storage layer between
> >> application and a database, designed to make data access faster.
> >>
> >> However, since addition of native persistence we started to call Ignite
> a
> >> "memory-centric database", and as far as I know, some organizations now
> use
> >> it as a primary data storage, without underlying database. In this case,
> >> calling our storage unit a *'cache'* causes unnecessary confusion.
> >>
> >> Thus, I suggest to rename IgniteCache in Ignite 3.0 to something that
> would
> >> fit both use-cases.
> >> Personally I like the term IgniteSpace.
> >>
> >> [1] https://en.wikipedia.org/wiki/Cache_(computing)
> >> --
> >> Best regards,
> >> Ilya
> >>
> >>
>
>

RE: Applicability of term 'cache' to Apache Ignite

[Stanislav Lukyanov]

I had an idea of “IgniteBucket” as in “a place to put things in”. 

But I think I like “space” since it sounds like and conceptually very close (if 
not identical) to “tablespace”.

I have to say I never heard of JavaSpaces :) Don’t think many people will 
recall that.

Stan

From: Dmitriy Setrakyan
Sent: 16 октября 2018 г. 20:21
To: dev
Subject: Re: Applicability of term 'cache' to Apache Ignite

Although I agree that this change is disruptive, can we just entertain
Ilya's idea for a bit? What if we were designing Ignite from scratch, what
different name would we give to the IgniteCache abstraction? Ilya suggested
"IgniteSpace", but I do not like it as it sounds too similar to JavaSpaces
[1], which is an obsolete technology at this point.

Any other ideas?

[1] https://www.oracle.com/technetwork/articles/java/javaspaces-140665.html

D.

On Tue, Oct 16, 2018 at 6:27 AM Ivan Rakov  wrote:

> Agree with Vladimir here.
>
> Let's stick to the "principle of least astonishment" - all current users
> will be surprised if we'll rename IgniteCache, new users won't be
> greatly surprised due to compliance with JCache.
>
> Best Regards,
> Ivan Rakov
>
> On 16.10.2018 15:53, Vladimir Ozerov wrote:
> > What is the ultimate goal of all these changes? While I agree that term
> > "cache" might be a bit outdated at the moment, there is nothing
> > fundamentally wrong with - data is still being cached in memory with an
> > option to persist it on disk. We should remember, that legacy and
> previous
> > user experience is of great importance for users. And disruptive changes
> > such as rename of a basic concept may make adoption of a new versions
> > harder for users, with very questionable benefits on the other side.
> >
> > As far as wrappers, personally I do not support this idea. Both "cache"
> and
> > "sql" are access methods to some information ("space"), rather than
> > wrappers around it. Moreover, it is hard to say whether we will have SQL
> > API at all, because this is big effort with not very clear value,
> provided
> > that there are industrial interfaces (JDBC, ODBC).
> >
> > On Tue, Oct 16, 2018 at 3:23 PM Stanislav Lukyanov <
> stanlukya...@gmail.com>
> > wrote:
> >
> >> How about separating our JCache implementation from the core of the
> >> probuct.
> >>
> >> Currently IgniteCache is the heart of Ignite. It is the basic storage
> unit.
> >> At the same time, it is the direct implementation of the JCache API,
> >> and some of the JCache features align somewhat awkwardly with Ignite
> >> concepts.
> >>
> >> Would be nice to have something like IgniteSpace as our core component,
> >> and have other components built on top of it as wrappers providing
> various
> >> APIs.
> >> For example
> >> - IgniteSpace itself is a distributed storage unit, that is partitioned,
> >> that has affinity, etc;
> >> note that it doesn’t have to have ANY particular API to add data, even
> >> key-value
> >> - IgniteCache is a wrapper around IgniteSpace that allows to store
> >> key-value pairs and implements JCache API
> >> - IgniteSql (we’re doing it eventually, right?) is a wrapper around
> >> IgniteSpace that allows to store SQL tables and implements ANSI SQL
> >> - IgniteQueue is a wrapper that implements Queue
> >> and so on.
> >>
> >> WDYT?
> >>
> >> Stan
> >>
> >> From: Ilya Lantukh
> >> Sent: 15 октября 2018 г. 14:49
> >> To: dev@ignite.apache.org
> >> Subject: Applicability of term 'cache' to Apache Ignite
> >>
> >> Hi Igniters,
> >>
> >> I would like to rise a question how we use the term *'cache'* in Ignite
> and
> >> how it corresponds to terminology in IT industry in general.
> >>
> >>  From wikipedia:
> >> In computing , a *cache* /kæʃ/
> >>  *kash*
> >> , is a
> >> hardware or software component that stores data so that future requests
> for
> >> that data can be served faster; the data stored in a cache might be the
> >> result of an earlier computation or a copy of data stored elsewhere. [1]
> >>
> >> When the first version of Ignite was released, this term was correct. We
> >> positioned Ignite mostly as an intermediate storage layer between
> >> application and a database, designed to make data access faster.
> >>
> >> However, since addition of native persistence we started to call Ignite
> a
> >> "memory-centric database", and as far as I know, some organizations now
> use
> >> it as a primary data storage, without underlying database. In this case,
> >> calling our storage unit a *'cache'* causes unnecessary confusion.
> >>
> >> Thus, I suggest to rename IgniteCache in Ignite 3.0 to something that
> would
> >> fit both use-cases.
> >> Personally I like the term IgniteSpace.
> >>
> >> [1] https://en.wikipedia.org/wiki/Cache_(computing)
> >> --
> >> Best regards,
> >> Ilya
> >>
> >>
>
>

Re: Applicability of term 'cache' to Apache Ignite

[Dmitriy Setrakyan]

Hm... How about IgniteData or IgniteDataset?

D.

On Tue, Oct 16, 2018 at 11:52 AM Stanislav Lukyanov 
wrote:

> I had an idea of “IgniteBucket” as in “a place to put things in”.
>
> But I think I like “space” since it sounds like and conceptually very
> close (if not identical) to “tablespace”.
>
> I have to say I never heard of JavaSpaces :) Don’t think many people will
> recall that.
>
> Stan
>
> From: Dmitriy Setrakyan
> Sent: 16 октября 2018 г. 20:21
> To: dev
> Subject: Re: Applicability of term 'cache' to Apache Ignite
>
> Although I agree that this change is disruptive, can we just entertain
> Ilya's idea for a bit? What if we were designing Ignite from scratch, what
> different name would we give to the IgniteCache abstraction? Ilya suggested
> "IgniteSpace", but I do not like it as it sounds too similar to JavaSpaces
> [1], which is an obsolete technology at this point.
>
> Any other ideas?
>
> [1]
> https://www.oracle.com/technetwork/articles/java/javaspaces-140665.html
>
> D.
>
> On Tue, Oct 16, 2018 at 6:27 AM Ivan Rakov  wrote:
>
> > Agree with Vladimir here.
> >
> > Let's stick to the "principle of least astonishment" - all current users
> > will be surprised if we'll rename IgniteCache, new users won't be
> > greatly surprised due to compliance with JCache.
> >
> > Best Regards,
> > Ivan Rakov
> >
> > On 16.10.2018 15:53, Vladimir Ozerov wrote:
> > > What is the ultimate goal of all these changes? While I agree that term
> > > "cache" might be a bit outdated at the moment, there is nothing
> > > fundamentally wrong with - data is still being cached in memory with an
> > > option to persist it on disk. We should remember, that legacy and
> > previous
> > > user experience is of great importance for users. And disruptive
> changes
> > > such as rename of a basic concept may make adoption of a new versions
> > > harder for users, with very questionable benefits on the other side.
> > >
> > > As far as wrappers, personally I do not support this idea. Both "cache"
> > and
> > > "sql" are access methods to some information ("space"), rather than
> > > wrappers around it. Moreover, it is hard to say whether we will have
> SQL
> > > API at all, because this is big effort with not very clear value,
> > provided
> > > that there are industrial interfaces (JDBC, ODBC).
> > >
> > > On Tue, Oct 16, 2018 at 3:23 PM Stanislav Lukyanov <
> > stanlukya...@gmail.com>
> > > wrote:
> > >
> > >> How about separating our JCache implementation from the core of the
> > >> probuct.
> > >>
> > >> Currently IgniteCache is the heart of Ignite. It is the basic storage
> > unit.
> > >> At the same time, it is the direct implementation of the JCache API,
> > >> and some of the JCache features align somewhat awkwardly with Ignite
> > >> concepts.
> > >>
> > >> Would be nice to have something like IgniteSpace as our core
> component,
> > >> and have other components built on top of it as wrappers providing
> > various
> > >> APIs.
> > >> For example
> > >> - IgniteSpace itself is a distributed storage unit, that is
> partitioned,
> > >> that has affinity, etc;
> > >> note that it doesn’t have to have ANY particular API to add data, even
> > >> key-value
> > >> - IgniteCache is a wrapper around IgniteSpace that allows to store
> > >> key-value pairs and implements JCache API
> > >> - IgniteSql (we’re doing it eventually, right?) is a wrapper around
> > >> IgniteSpace that allows to store SQL tables and implements ANSI SQL
> > >> - IgniteQueue is a wrapper that implements Queue
> > >> and so on.
> > >>
> > >> WDYT?
> > >>
> > >> Stan
> > >>
> > >> From: Ilya Lantukh
> > >> Sent: 15 октября 2018 г. 14:49
> > >> To: dev@ignite.apache.org
> > >> Subject: Applicability of term 'cache' to Apache Ignite
> > >>
> > >> Hi Igniters,
> > >>
> > >> I would like to rise a question how we use the term *'cache'* in
> Ignite
> > and
> > >> how it corresponds to terminology in IT industry in general.
> > >>
> > >>  From wikipedia:
> > >> In computing , a *cache*
> /kæʃ/
> > >>  *kash*
> > >> ,
> is a
> > >> hardware or software component that stores data so that future
> requests
> > for
> > >> that data can be served faster; the data stored in a cache might be
> the
> > >> result of an earlier computation or a copy of data stored elsewhere.
> [1]
> > >>
> > >> When the first version of Ignite was released, this term was correct.
> We
> > >> positioned Ignite mostly as an intermediate storage layer between
> > >> application and a database, designed to make data access faster.
> > >>
> > >> However, since addition of native persistence we started to call
> Ignite
> > a
> > >> "memory-centric database", and as far as I know, some organizations
> now
> > use
> > >> it as a primary data storage, without underlying database. In this
> case,
> > >> calling our storage unit a *'cache'* causes un

[GitHub] ignite pull request #5007: Ignite 2.4.8 p6

[aealeksandrov]

GitHub user aealeksandrov opened a pull request:

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

Ignite 2.4.8 p6

Created for TS run.

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

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

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

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


commit 699561265ae616b5eb75897343be84d8c83be804
Author: Anton Kalashnikov 
Date:   2018-03-21T15:53:15Z

GG-13631 fix GridDhtPartitionDemandLegacyMessage

(cherry picked from commit ffbc56e)

commit 37c8033c72ac4fd1ec1e419ba68142c4fe11ad8b
Author: tledkov-gridgain 
Date:   2018-03-13T09:37:29Z

IGNITE-7860: JDBC thin: changed default socket buffer size to 64Kb. This 
closes #3600.

commit 130adcf29ddb61f8e9baa784b81454d3ed7c3b75
Author: Pavel Tupitsyn 
Date:   2018-01-26T08:48:14Z

IGNITE-7530 .NET: Fix GetAll memory usage and performance in binary mode

This closes #3436

commit 824004909b23a9a7d599500967af34103acb8c47
Author: Igor Sapego 
Date:   2018-01-30T12:56:17Z

IGNITE-6810: Implemented SSL support for ODBC.

This closes #3361

commit 82da0b5e9dc2ee2339c3fb1023e35d415bf1b647
Author: Pavel Kuznetsov 
Date:   2018-02-07T12:37:52Z

IGNITE-6217: Added benchmark to compare JDBC vs native SQL

This closes #2558

commit 701c6f141f6812ad7bc050a86266e696cf5863ed
Author: tledkov-gridgain 
Date:   2018-02-08T12:29:42Z

IGNITE-6625: JDBC thin: support SSL connection to Ignite node

This closes #3233

commit 2d729bf5c6f6fca9d07be2d57850642ba4b55004
Author: tledkov-gridgain 
Date:   2018-02-09T11:08:15Z

IGNITE-6625: SSL support for thin JDBC: additional fix test; change error 
message

commit 8994f847d7f5f15db73706d9210cdccb1cf3fb26
Author: devozerov 
Date:   2018-02-12T13:34:24Z

IGNITE-7003: Fixed faulty test 
WalModeChangeAdvancedSelfTest.testJoinCoordinator.

commit b142712264007d7397d1594541681a4a7e3d4b93
Author: Igor Sapego 
Date:   2018-02-26T12:02:07Z

IGNITE-7362: Fixed PDO ODBC integration issue

commit a2b2aee52cc65d01f2ecaf9462adc4bd368438ea
Author: Igor Sapego 
Date:   2018-02-28T10:23:12Z

IGNITE-7763: Fixed 32bit tests configurations to prevent OOM

This closes #3557

commit 652f3c4cdbaad40f5de25b06f0c13710aa7f2fd9
Author: Pavel Kuznetsov 
Date:   2018-03-13T12:46:36Z

IGNITE-7531: Data load benchmarks. This closes #3571.

commit 9337a53d9fcd62af87f6760080d350b43e275105
Author: tledkov-gridgain 
Date:   2018-03-16T11:38:38Z

IGNITE-7879: Fixed splitter logic for DISTINCT with subqueries. This closes 
#3634.

commit 7bec8b13cb373002d2a6b1b268d410338259bac2
Author: Igor Sapego 
Date:   2018-03-19T11:17:33Z

IGNITE-7811: Implemented connection failover for ODBC

This closes #3643

commit e512e5e0a2602df0ecfb69b2b5efabce836b04db
Author: Igor Sapego 
Date:   2018-03-20T10:37:02Z

IGNITE-7888: Implemented login timeout for ODBC.

This closes #3657

commit 211fca3a55e84b78ff0c1af04d91e25d6fc846c4
Author: devozerov 
Date:   2018-03-20T11:13:46Z

IGNITE-7984: SQL: improved deadlock handling in DML. This closes #3655.

commit bcd2888d27afe65f1a060e35b99a05ea420979c7
Author: Roman Guseinov 
Date:   2018-02-16T09:57:26Z

IGNITE-7192: Implemented JDBC support FQDN to multiple IPs

This closes #3439

commit d2659d0ec9f6e1a0b905fc7bf23b65fd5522c80a
Author: Alexander Paschenko 
Date:   2018-03-14T09:23:37Z

IGNITE-7253: JDBC thin driver: implemented streaming. This closes #3499. 
This closes #3591.

commit bc9018ef8b116f81b8e06d2ff7651ba2b6c7beae
Author: tledkov-gridgain 
Date:   2018-03-19T08:01:26Z

IGNITE-7029: JDBC thin driver now supports multiple IP addresses with 
transparent failover. This closes #3585.

commit 587022862fd5bdbb076ab6207ae6fd9bc7583c13
Author: Sergey Chugunov 
Date:   2018-03-16T16:24:17Z

IGNITE-7964 rmvId is stored to MetaStorage metapage during operations - 
Fixes #3645.

commit 006ef4d15e4faedb6dfce6ce9637602055b97293
Author: tledkov-gridgain 
Date:   2018-03-22T11:47:06Z

IGNITE-7436: Simple username/password authentication. This closes #3483.

commit 1c7f59c90514670e802d9d07544b00b7562fe6d2
Author: Pavel Tupitsyn 
Date:   2018-01-30T09:48:16Z

.NET: Fix build status icon in README

commit 162df61b305fccfc55e186d07351727f35b55179
Author: Pavel Tupitsyn 
Date:   2018-02-01T11:53:16Z

IGNITE-7561 .NET: Add IServices.GetDynamicServiceProxy

This closes #3457

commit 9a0328ebbc9d52f8e96898a384fa45743d2efa5b
Author: Pavel Tupitsyn 
Date:   2018-02-02T12:01:27Z

.NET: Update README regarding C++ interop and thin client

commit b804cfea51c87724b45b40de4fd58d300c049be1
Author: Pavel Tupitsyn 
Date:   2018-01-31T09:39:19Z

.NET: Suppress API parity check for SSL in

[jira] [Created] (IGNITE-9906) Added new method to get or wait for cache

[Mikhail Cherkasov (JIRA)]

Mikhail Cherkasov created IGNITE-9906:
-

 Summary: Added new method to get or wait for cache
 Key: IGNITE-9906
 URL: https://issues.apache.org/jira/browse/IGNITE-9906
 Project: Ignite
  Issue Type: Improvement
Reporter: Mikhail Cherkasov
Assignee: Mikhail Cherkasov
 Attachments: Client.java, Server.java

Due async nature of Ignite, ignite client might get cache creation event later 
then the rest of cluster and if server node created cache and pass it name to 
client, client might fail to get this cache, client.cache(name) will return 
null:
 # server creates cache server.getOrCreateCache() and return from 
getOrCreateCache method
 # server sends the cache name to client
 # client does client.cache(cacheName) and get null.

It can be workaround by adding retirees, but it's a boilerplate code that we 
can add to our API.

we can overload existing method ignite.cache() and add timeout for waiting.

 



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

[DISCUSS] Dropping hadoop-accelerator download

[Dmitriy Setrakyan]

Igniters,

I would like to suggest dropping the hadoop accelerator distribution of
Apache Ignite. Note, that it does not mean dropping any features. We are
still going to support IGFS, in-memory map reduce, spark integration, etc.
However, the hadoop-accelerator downloadable is putting extra pressure on
the community to test and document, which can be avoided. All the features
will still be supported through regular Ignite distribution.

Any objections?

D.

Re: [DISCUSS] Dropping hadoop-accelerator download

[Valentin Kulichenko]

+1 from me. Hadoop Accelerator build is confusing and doesn't provide any
value.

We already had a similar discussion couple of years back where I shared
some of my thoughts regarding this:
http://apache-ignite-developers.2346864.n4.nabble.com/ignite-spark-module-in-Hadoop-Accelerator-td12343.html

-Val

On Tue, Oct 16, 2018 at 4:45 PM Dmitriy Setrakyan 
wrote:

> Igniters,
>
> I would like to suggest dropping the hadoop accelerator distribution of
> Apache Ignite. Note, that it does not mean dropping any features. We are
> still going to support IGFS, in-memory map reduce, spark integration, etc.
> However, the hadoop-accelerator downloadable is putting extra pressure on
> the community to test and document, which can be avoided. All the features
> will still be supported through regular Ignite distribution.
>
> Any objections?
>
> D.
>

[GitHub] ignite pull request #5008: adding hibernate-5.2 module

[scottmf]

GitHub user scottmf opened a pull request:

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

adding hibernate-5.2 module

all tests pass except 
CacheHibernateBlobStoreSelfTest.testSimpleMultithreading which
is carryover from the hibernate-5.1 implementation.  There is a bug already 
associated
with the failure: https://issues.apache.org/jira/browse/IGNITE-1757

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

$ git pull https://github.com/scottmf/ignite-1 master

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

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


commit d24953a70cd752547d85d4fa40d58bade9d18da1
Author: scottmf 
Date:   2018-10-15T18:55:00Z

adding hibernate-5.2 module

all tests pass except 
CacheHibernateBlobStoreSelfTest.testSimpleMultithreading which
is carryover from the hibernate-5.1 implementation.  There is a bug already 
associated
with the failure: https://issues.apache.org/jira/browse/IGNITE-1757




---

[jira] [Created] (IGNITE-9907) Wrong index field name makes the whole cluster to fail

[Mikhail Cherkasov (JIRA)]

Mikhail Cherkasov created IGNITE-9907:
-

 Summary: Wrong index field name makes the whole cluster to fail
 Key: IGNITE-9907
 URL: https://issues.apache.org/jira/browse/IGNITE-9907
 Project: Ignite
  Issue Type: Bug
Reporter: Mikhail Cherkasov
Assignee: Mikhail Cherkasov
 Attachments: WrongFields.java

Wrong index field name makes the whole cluster to fail and there's now reliable 
way to restore from this state, exchange fails with the exception:

 

2018-10-16 
14:42:56,842][ERROR][exchange-worker-#42%server_0%][GridCachePartitionExchangeManager]
 Failed to wait for completion of partition map exchange (preloading will not 
start): GridDhtPartitionsExchangeFuture [firstDiscoEvt=DiscoveryCustomEvent 
[customMsg=null, affTopVer=AffinityTopologyVersion [topVer=2, minorTopVer=1], 
super=DiscoveryEvent [evtNode=TcpDiscoveryNode 
[id=6859ef9c-cceb-4d8a-8d5b-c1cd2cd192b7, addrs=[0:0:0:0:0:0:0:1%lo0, 
127.0.0.1, 192.168.75.84], sockAddrs=[/192.168.75.84:0, /0:0:0:0:0:0:0:1%lo0:0, 
/127.0.0.1:0], discPort=0, order=2, intOrder=2, lastExchangeTime=1539726176458, 
loc=false, ver=2.4.3#19691231-sha1:, isClient=true], topVer=2, 
nodeId8=0d8b289d, msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1539726176684]], 
crd=TcpDiscoveryNode [id=0d8b289d-32aa-402e-8e71-137977559979, 
addrs=[0:0:0:0:0:0:0:1%lo0, 127.0.0.1, 192.168.75.84], 
sockAddrs=[/192.168.75.84:47500, /0:0:0:0:0:0:0:1%lo0:47500, /127.0.0.1:47500], 
discPort=47500, order=1, intOrder=1, lastExchangeTime=1539726176493, loc=true, 
ver=2.4.3#19691231-sha1:, isClient=false], 
exchId=GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=2, 
minorTopVer=1], discoEvt=DiscoveryCustomEvent [customMsg=null, 
affTopVer=AffinityTopologyVersion [topVer=2, minorTopVer=1], 
super=DiscoveryEvent [evtNode=TcpDiscoveryNode 
[id=6859ef9c-cceb-4d8a-8d5b-c1cd2cd192b7, addrs=[0:0:0:0:0:0:0:1%lo0, 
127.0.0.1, 192.168.75.84], sockAddrs=[/192.168.75.84:0, /0:0:0:0:0:0:0:1%lo0:0, 
/127.0.0.1:0], discPort=0, order=2, intOrder=2, lastExchangeTime=1539726176458, 
loc=false, ver=2.4.3#19691231-sha1:, isClient=true], topVer=2, 
nodeId8=0d8b289d, msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1539726176684]], 
nodeId=6859ef9c, evt=DISCOVERY_CUSTOM_EVT], added=true, 
initFut=GridFutureAdapter [ignoreInterrupts=false, state=DONE, res=false, 
hash=1240595188], init=false, lastVer=null, 
partReleaseFut=PartitionReleaseFuture [topVer=AffinityTopologyVersion 
[topVer=2, minorTopVer=1], futures=[ExplicitLockReleaseFuture 
[topVer=AffinityTopologyVersion [topVer=2, minorTopVer=1], futures=[]], 
TxReleaseFuture [topVer=AffinityTopologyVersion [topVer=2, minorTopVer=1], 
futures=[]], AtomicUpdateReleaseFuture [topVer=AffinityTopologyVersion 
[topVer=2, minorTopVer=1], futures=[]], DataStreamerReleaseFuture 
[topVer=AffinityTopologyVersion [topVer=2, minorTopVer=1], futures=[, 
exchActions=null, affChangeMsg=null, initTs=1539726176695, 
centralizedAff=false, forceAffReassignment=false, changeGlobalStateE=null, 
done=true, state=CRD, evtLatch=0, remaining=[], super=GridFutureAdapter 
[ignoreInterrupts=false, state=DONE, res=java.lang.IndexOutOfBoundsException: 
Index: 0, Size: 0, hash=1559339235]]
class org.apache.ignite.IgniteCheckedException: Index: 0, Size: 0
 at org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7332)
 at 
org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:259)
 at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:207)
 at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:159)
 at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2374)
 at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
 at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
 at java.util.ArrayList.rangeCheck(ArrayList.java:657)
 at java.util.ArrayList.get(ArrayList.java:433)
 at 
org.apache.ignite.internal.processors.cache.CacheGroupContext.singleCacheContext(CacheGroupContext.java:374)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.(GridDhtLocalPartition.java:194)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.getOrCreatePartition(GridDhtPartitionTopologyImpl.java:816)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.initPartitions(GridDhtPartitionTopologyImpl.java:381)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.beforeExchange(GridDhtPartitionTopologyImpl.java:554)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedEx