[jira] [Created] (IGNITE-7698) Page read during replacement should be outside of segment write lock

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-7698:


 Summary: Page read during replacement should be outside of segment 
write lock
 Key: IGNITE-7698
 URL: https://issues.apache.org/jira/browse/IGNITE-7698
 Project: Ignite
  Issue Type: Improvement
  Components: persistence
Affects Versions: 2.1
Reporter: Alexey Goncharuk
 Fix For: 2.5


When a page is acquired, if it needs to be read from disk, we read it inside 
the segment write lock which blocks other threads from acquiring pages that are 
already in memory.

This can be easily avoided: once we initialized the page's being loaded RW 
lock, we can immediately acquire the write lock - no deadlocks can happen here. 
Afterwards, we can release the segment write lock and read the page.

The change seems to be very local.



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

[jira] [Assigned] (IGNITE-7698) Page read during replacement should be outside of segment write lock

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov reassigned IGNITE-7698:
--

Assignee: Dmitriy Pavlov

> Page read during replacement should be outside of segment write lock
> 
>
> Key: IGNITE-7698
> URL: https://issues.apache.org/jira/browse/IGNITE-7698
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Assignee: Dmitriy Pavlov
>Priority: Major
> Fix For: 2.5
>
>
> When a page is acquired, if it needs to be read from disk, we read it inside 
> the segment write lock which blocks other threads from acquiring pages that 
> are already in memory.
> This can be easily avoided: once we initialized the page's being loaded RW 
> lock, we can immediately acquire the write lock - no deadlocks can happen 
> here. Afterwards, we can release the segment write lock and read the page.
> The change seems to be very local.



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

[jira] [Updated] (IGNITE-7690) Move shared memory suite (IpcSharedMemoryCrashDetectionSelfTest) to Ignite Basic 2

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-7690:
---
Fix Version/s: 2.5

> Move shared memory suite (IpcSharedMemoryCrashDetectionSelfTest) to Ignite 
> Basic 2
> --
>
> Key: IGNITE-7690
> URL: https://issues.apache.org/jira/browse/IGNITE-7690
> Project: Ignite
>  Issue Type: Task
>Reporter: Dmitriy Pavlov
>Assignee: Ivan Rakov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> Test is flaky but included into basic (stable) suite
>Ignite Basic [ tests 1 ] i 
>  org.apache.ignite.testsuites.IgniteBasicTestSuite: 
> org.apache.ignite.internal.util.ipc.shmem.IpcSharedMemoryCrashDetectionSelfTest.testIgfsServerClientInteractionsUponClientKilling
>  (fail rate 2%) 
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-2464527718752484555=%3Cdefault%3E=testDetails
> It is better to move this test to basic 2 suite - place for flaky and long 
> running tests.
> It is also desired to introduce IgniteBasic2 suite in code with correct 
> comments on purpose



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

[jira] [Commented] (IGNITE-7690) Move shared memory suite (IpcSharedMemoryCrashDetectionSelfTest) to Ignite Basic 2

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7690:


Looks good to me, [~agoncharuk] could you please merge?

> Move shared memory suite (IpcSharedMemoryCrashDetectionSelfTest) to Ignite 
> Basic 2
> --
>
> Key: IGNITE-7690
> URL: https://issues.apache.org/jira/browse/IGNITE-7690
> Project: Ignite
>  Issue Type: Task
>Reporter: Dmitriy Pavlov
>Assignee: Ivan Rakov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> Test is flaky but included into basic (stable) suite
>Ignite Basic [ tests 1 ] i 
>  org.apache.ignite.testsuites.IgniteBasicTestSuite: 
> org.apache.ignite.internal.util.ipc.shmem.IpcSharedMemoryCrashDetectionSelfTest.testIgfsServerClientInteractionsUponClientKilling
>  (fail rate 2%) 
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-2464527718752484555=%3Cdefault%3E=testDetails
> It is better to move this test to basic 2 suite - place for flaky and long 
> running tests.
> It is also desired to introduce IgniteBasic2 suite in code with correct 
> comments on purpose



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

[jira] [Updated] (IGNITE-7697) Update maven-javadoc-plugin version

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-7697:
---
Labels: MakeTeamcityGreenAgain  (was: )

> Update maven-javadoc-plugin version
> ---
>
> Key: IGNITE-7697
> URL: https://issues.apache.org/jira/browse/IGNITE-7697
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.4
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> Update version of {{maven-javadoc-plugin}} in order to try to overcome 
> following error:
> {code}
> javadoc: warning - Error fetching URL: 
> http://hadoop.apache.org/docs/current/api/
> {code}



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

[jira] [Created] (IGNITE-7697) Update maven-javadoc-plugin version

[Peter Ivanov (JIRA)]

Peter Ivanov created IGNITE-7697:


 Summary: Update maven-javadoc-plugin version
 Key: IGNITE-7697
 URL: https://issues.apache.org/jira/browse/IGNITE-7697
 Project: Ignite
  Issue Type: Improvement
Affects Versions: 2.4
Reporter: Peter Ivanov
Assignee: Peter Ivanov
 Fix For: 2.5


Update version of {{maven-javadoc-plugin}} in order to try to overcome 
following error:
{code}
javadoc: warning - Error fetching URL: 
http://hadoop.apache.org/docs/current/api/
{code}



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

[jira] [Commented] (IGNITE-7320) Multilevel header in admin panel looks wierd in Safari and Edge

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin commented on IGNITE-7320:
---

!Lk1YqS (1).jpg!

> Multilevel header in admin panel looks wierd in Safari and Edge
> ---
>
> Key: IGNITE-7320
> URL: https://issues.apache.org/jira/browse/IGNITE-7320
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Alexander Kalinin
>Assignee: Alexander Kalinin
>Priority: Minor
> Attachments: Lk1YqS (1).jpg
>
>




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

[jira] [Updated] (IGNITE-7320) Multilevel header in admin panel looks wierd in Safari and Edge

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin updated IGNITE-7320:
--
Attachment: Lk1YqS (1).jpg

> Multilevel header in admin panel looks wierd in Safari and Edge
> ---
>
> Key: IGNITE-7320
> URL: https://issues.apache.org/jira/browse/IGNITE-7320
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Alexander Kalinin
>Assignee: Alexander Kalinin
>Priority: Minor
> Attachments: Lk1YqS (1).jpg
>
>




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

[jira] [Commented] (IGNITE-7320) Multilevel header in admin panel looks wierd in Safari and Edge

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin commented on IGNITE-7320:
---

!Lk1YqS.jpg!

> Multilevel header in admin panel looks wierd in Safari and Edge
> ---
>
> Key: IGNITE-7320
> URL: https://issues.apache.org/jira/browse/IGNITE-7320
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Alexander Kalinin
>Assignee: Alexander Kalinin
>Priority: Minor
> Attachments: Lk1YqS.jpg
>
>




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

[jira] [Updated] (IGNITE-7320) Multilevel header in admin panel looks wierd in Safari and Edge

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin updated IGNITE-7320:
--
Attachment: Lk1YqS.jpg

> Multilevel header in admin panel looks wierd in Safari and Edge
> ---
>
> Key: IGNITE-7320
> URL: https://issues.apache.org/jira/browse/IGNITE-7320
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Alexander Kalinin
>Assignee: Alexander Kalinin
>Priority: Minor
>




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

[jira] [Issue Comment Deleted] (IGNITE-7320) Multilevel header in admin panel looks wierd in Safari and Edge

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin updated IGNITE-7320:
--
Comment: was deleted

(was: !Lk1YqS.jpg!)

> Multilevel header in admin panel looks wierd in Safari and Edge
> ---
>
> Key: IGNITE-7320
> URL: https://issues.apache.org/jira/browse/IGNITE-7320
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Alexander Kalinin
>Assignee: Alexander Kalinin
>Priority: Minor
>




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

[jira] [Updated] (IGNITE-7320) Multilevel header in admin panel looks wierd in Safari and Edge

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin updated IGNITE-7320:
--
Attachment: (was: Lk1YqS.jpg)

> Multilevel header in admin panel looks wierd in Safari and Edge
> ---
>
> Key: IGNITE-7320
> URL: https://issues.apache.org/jira/browse/IGNITE-7320
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Alexander Kalinin
>Assignee: Alexander Kalinin
>Priority: Minor
>




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

[jira] [Updated] (IGNITE-7696) Deadlock at GridDhtAtomicCache.lockEntries called through GridDhtAtomicCache.updateAllAsyncInternal

[Sadayuki Furuhashi (JIRA)]

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

Sadayuki Furuhashi updated IGNITE-7696:
---
Description: 
We observed that all nodes in a cluster completely stalls and put/get/remove 
operations to a cache block for ever. When it happens, we can see following log 
in thread dump:

{code}
2018-02-14_04:21:33.84410 Found one Java-level deadlock:
2018-02-14_04:21:33.84410 =
2018-02-14_04:21:33.84411 "sys-#41%IgniteManager%":
2018-02-14_04:21:33.84411   waiting to lock monitor 0x7f6d5e41a558 (object 
0x000781083ef0, a 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry),
2018-02-14_04:21:33.84411   which is held by "sys-stripe-5-#6%IgniteManager%"
2018-02-14_04:21:33.84412 "sys-stripe-5-#6%IgniteManager%":
2018-02-14_04:21:33.84412   waiting to lock monitor 0x7f6d5e41de68 (object 
0x000781083e70, a 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry)
2018-02-14_04:21:33.84412   in JNI, which is held by 
"sys-stripe-2-#3%IgniteManager%"
2018-02-14_04:21:33.84412 "sys-stripe-2-#3%IgniteManager%":
2018-02-14_04:21:33.84413   waiting to lock monitor 0x7f6d5e41a558 (object 
0x000781083ef0, a 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry)
2018-02-14_04:21:33.84413   in JNI, which is held by 
"sys-stripe-5-#6%IgniteManager%"
2018-02-14_04:21:33.84413
2018-02-14_04:21:33.84414 Java stack information for the threads listed above:
2018-02-14_04:21:33.84414 ===
2018-02-14_04:21:33.84416 "sys-#41%IgniteManager%":
2018-02-14_04:21:33.84416   at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.markObsoleteVersion(GridCacheMapEntry.java:2153)
2018-02-14_04:21:33.84417   - waiting to lock <0x000781083ef0> (a 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry)
2018-02-14_04:21:33.84417   at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.removeVersionedEntry(GridDhtLocalPartition.java:368)
2018-02-14_04:21:33.84418   at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.cleanupRemoveQueue(GridDhtLocalPartition.java:392)
2018-02-14_04:21:33.84418   at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor$RemovedItemsCleanupTask$1.run(GridCacheProcessor.java:4051)
2018-02-14_04:21:33.84418   at 
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6687)
2018-02-14_04:21:33.84419   at 
org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
2018-02-14_04:21:33.84419   at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
2018-02-14_04:21:33.84419   at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
2018-02-14_04:21:33.84420   at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
2018-02-14_04:21:33.84421   at java.lang.Thread.run(Thread.java:748)
2018-02-14_04:21:33.84421 "sys-stripe-5-#6%IgniteManager%":
2018-02-14_04:21:33.84421   at sun.misc.Unsafe.monitorEnter(Native Method)
2018-02-14_04:21:33.84421   at 
org.apache.ignite.internal.util.GridUnsafe.monitorEnter(GridUnsafe.java:1207)
2018-02-14_04:21:33.84422   at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.lockEntries(GridDhtAtomicCache.java:2848)
2018-02-14_04:21:33.84422   at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1707)
2018-02-14_04:21:33.84423   at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1629)
2018-02-14_04:21:33.84423   at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:3056)
2018-02-14_04:21:33.84424   at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$400(GridDhtAtomicCache.java:131)
2018-02-14_04:21:33.84424   at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:267)
2018-02-14_04:21:33.84425   at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:262)
2018-02-14_04:21:33.84425   at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1060)
2018-02-14_04:21:33.84425   at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
2018-02-14_04:21:33.84426   at 

[jira] [Created] (IGNITE-7696) Deadlock at GridDhtAtomicCache.lockEntries called through GridDhtAtomicCache.updateAllAsyncInternal

[Sadayuki Furuhashi (JIRA)]

Sadayuki Furuhashi created IGNITE-7696:
--

 Summary: Deadlock at GridDhtAtomicCache.lockEntries called through 
GridDhtAtomicCache.updateAllAsyncInternal
 Key: IGNITE-7696
 URL: https://issues.apache.org/jira/browse/IGNITE-7696
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.3
 Environment: * Ignite 2.3
 * OpenJDK version "1.8.0_151"
 * Linux 4.4.0
Reporter: Sadayuki Furuhashi


We observed that all nodes in a cluster completely stalls and put/get/remove 
operations to a cache blocks for ever. When it happens, we can see following 
log in thread dump:
{code:java}
2018-02-14_04:21:33.84410 Found one Java-level deadlock:
2018-02-14_04:21:33.84410 =
2018-02-14_04:21:33.84411 "sys-#41%IgniteManager%":
2018-02-14_04:21:33.84411 waiting to lock monitor 0x7f6d5e41a558 (object 
0x000781083ef0, a 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry),
2018-02-14_04:21:33.84411 which is held by "sys-stripe-5-#6%IgniteManager%"
2018-02-14_04:21:33.84412 "sys-stripe-5-#6%IgniteManager%":
2018-02-14_04:21:33.84412 waiting to lock monitor 0x7f6d5e41de68 (object 
0x000781083e70, a 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry)
2018-02-14_04:21:33.84412 in JNI, which is held by 
"sys-stripe-2-#3%IgniteManager%"
2018-02-14_04:21:33.84412 "sys-stripe-2-#3%IgniteManager%":
2018-02-14_04:21:33.84413 waiting to lock monitor 0x7f6d5e41a558 (object 
0x000781083ef0, a 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry)
2018-02-14_04:21:33.84413 in JNI, which is held by 
"sys-stripe-5-#6%IgniteManager%"
2018-02-14_04:21:33.84413
2018-02-14_04:21:33.84414 Java stack information for the threads listed above:
2018-02-14_04:21:33.84414 ===
2018-02-14_04:21:33.84416 "sys-#41%IgniteManager%":
2018-02-14_04:21:33.84416 at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.markObsoleteVersion(GridCacheMapEntry.java:2153)
2018-02-14_04:21:33.84417 - waiting to lock <0x000781083ef0> (a 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry)
2018-02-14_04:21:33.84417 at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.removeVersionedEntry(GridDhtLocalPartition.java:368)
2018-02-14_04:21:33.84418 at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.cleanupRemoveQueue(GridDhtLocalPartition.java:392)
2018-02-14_04:21:33.84418 at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor$RemovedItemsCleanupTask$1.run(GridCacheProcessor.java:4051)
2018-02-14_04:21:33.84418 at 
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6687)
2018-02-14_04:21:33.84419 at 
org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
2018-02-14_04:21:33.84419 at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
2018-02-14_04:21:33.84419 at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
2018-02-14_04:21:33.84420 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
2018-02-14_04:21:33.84421 at java.lang.Thread.run(Thread.java:748)
2018-02-14_04:21:33.84421 "sys-stripe-5-#6%IgniteManager%":
2018-02-14_04:21:33.84421 at sun.misc.Unsafe.monitorEnter(Native Method)
2018-02-14_04:21:33.84421 at 
org.apache.ignite.internal.util.GridUnsafe.monitorEnter(GridUnsafe.java:1207)
2018-02-14_04:21:33.84422 at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.lockEntries(GridDhtAtomicCache.java:2848)
2018-02-14_04:21:33.84422 at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1707)
2018-02-14_04:21:33.84423 at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1629)
2018-02-14_04:21:33.84423 at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:3056)
2018-02-14_04:21:33.84424 at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$400(GridDhtAtomicCache.java:131)
2018-02-14_04:21:33.84424 at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:267)
2018-02-14_04:21:33.84425 at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:262)
2018-02-14_04:21:33.84425 at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1060)
2018-02-14_04:21:33.84425 at 

[jira] [Resolved] (IGNITE-7684) Ignore IGNITE_USE_ASYNC_FILE_IO_FACTORY in FileWriteAheadLogManager

[Alexander Belyak (JIRA)]

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

Alexander Belyak resolved IGNITE-7684.
--
Resolution: Duplicate

> Ignore IGNITE_USE_ASYNC_FILE_IO_FACTORY in FileWriteAheadLogManager
> ---
>
> Key: IGNITE-7684
> URL: https://issues.apache.org/jira/browse/IGNITE-7684
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.4
>Reporter: Alexander Belyak
>Priority: Major
>
> If IGNITE_USE_ASYNC_FILE_IO_FACTORY specified and no IGNITE_WAL_MMAP we get:
> {noformat}
> java.lang.UnsupportedOperationException: AsynchronousFileChannel doesn't 
> support mmap. 
> at 
> org.apache.ignite.internal.processors.cache.persistence.file.AsyncFileIO.map(AsyncFileIO.java:173)
>  
> at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.restoreWriteHandle(FileWriteAheadLogManager.java:1068)
>  
> at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.resumeLogging(FileWriteAheadLogManager.java:552)
> at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readCheckpointAndRestoreMemory(GridCacheDatabaseSharedManager.java:714)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest(GridDhtPartitionsExchangeFuture.java:841)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:595)
> at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2329)
> at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) 
> at java.lang.Thread.run(Thread.java:748)
> {noformat}



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

[jira] [Commented] (IGNITE-7693) New node joining via ZookeeperDiscoverySpi should print out its ZooKeeper sessionId

[Roman Shtykh (JIRA)]

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

Roman Shtykh commented on IGNITE-7693:
--

[~sergey-chugunov] Please have a look. Probably still not the best way to see 
session id in the logs, but at least now you can have these lines in your node 
logs.
{noformat}
[TcpDiscoveryZookeeperIpFinder] Connected with session id: 0x2619230f8d0
...
[TcpDiscoveryZookeeperIpFinder] Registering addresses with ZooKeeper IP Finder: 
[/127.0.0.1:47500]{noformat}

> New node joining via ZookeeperDiscoverySpi should print out its ZooKeeper 
> sessionId
> ---
>
> Key: IGNITE-7693
> URL: https://issues.apache.org/jira/browse/IGNITE-7693
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Sergey Chugunov
>Priority: Major
> Fix For: 2.5
>
>
> For now there is no way to match Ignite nodes joining to Ignite cluster with 
> log entries in ZooKeeper nodes' logs.
> In ZooKeeper logs there are entries like this:
> {noformat}
> myid:1] - INFO  [CommitProcessor:1:ZooKeeperServer@687] - Established session 
> 0x161575d88530007 with negotiated timeout 1 for client 
> /:{noformat}
> but it is hard to match them with Ignite nodes when there are several started 
> on the same host.
> If Ignite node prints out its session on join it makes correlating them with 
> particular ZooKeeper instance much easier.



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

[jira] [Commented] (IGNITE-7693) New node joining via ZookeeperDiscoverySpi should print out its ZooKeeper sessionId

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7693:


GitHub user shroman opened a pull request:

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

IGNITE-7693: Printing out session ids on joining via ZookeeperDiscove…

…rySpi.

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

$ git pull https://github.com/shroman/ignite IGNITE-7693

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

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


commit fce93839db7ddc303ca5ced3cb71e6603d4b1adc
Author: shroman 
Date:   2018-02-14T02:50:29Z

IGNITE-7693: Printing out session ids on joining via ZookeeperDiscoverySpi.




> New node joining via ZookeeperDiscoverySpi should print out its ZooKeeper 
> sessionId
> ---
>
> Key: IGNITE-7693
> URL: https://issues.apache.org/jira/browse/IGNITE-7693
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Sergey Chugunov
>Priority: Major
> Fix For: 2.5
>
>
> For now there is no way to match Ignite nodes joining to Ignite cluster with 
> log entries in ZooKeeper nodes' logs.
> In ZooKeeper logs there are entries like this:
> {noformat}
> myid:1] - INFO  [CommitProcessor:1:ZooKeeperServer@687] - Established session 
> 0x161575d88530007 with negotiated timeout 1 for client 
> /:{noformat}
> but it is hard to match them with Ignite nodes when there are several started 
> on the same host.
> If Ignite node prints out its session on join it makes correlating them with 
> particular ZooKeeper instance much easier.



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

[jira] [Commented] (IGNITE-7652) ContinuousQueryWithTransformer example

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-7652:
-

[~NIzhikov] , please find my comments in the pull-request. In general, it would 
be better to use 'Organization' model instead of 'Employees' that have a 
complex key. That complex key (EmployeeKey) is not needed in this example.

> ContinuousQueryWithTransformer example
> --
>
> Key: IGNITE-7652
> URL: https://issues.apache.org/jira/browse/IGNITE-7652
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.5
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Fix For: 2.5
>
>
> Need to create example for a ContinuousQueryWithTransformer.



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

[jira] [Updated] (IGNITE-6564) Incorrect calculation size and keySize for cluster cache metrics

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-6564:

Labels: iep-6  (was: )

> Incorrect calculation size and keySize for cluster cache metrics
> 
>
> Key: IGNITE-6564
> URL: https://issues.apache.org/jira/browse/IGNITE-6564
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Ilya Kasnacheev
>Priority: Minor
>  Labels: iep-6
>
> They are currently not passed by ring and therefore only taken from current 
> node, which returns incorrect (local) value.
> See CacheMetricsSnapshot class.



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

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

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-5539:

Labels: iep-6  (was: )

> 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
>Priority: Major
>  Labels: iep-6
> Fix For: 2.5
>
>
> In memory only mode metrics show some not zero values.
> With persistence it shows zero.



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

[jira] [Updated] (IGNITE-5490) Implement replacement for obsolete CacheMetrics#getOffHeapAllocatedSize

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-5490:

Labels: iep-6  (was: )

> Implement replacement for obsolete CacheMetrics#getOffHeapAllocatedSize
> ---
>
> Key: IGNITE-5490
> URL: https://issues.apache.org/jira/browse/IGNITE-5490
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.0
>Reporter: Ivan Rakov
>Priority: Major
>  Labels: iep-6
>
> With new 2.0 architecture, many caches can share one memory policy. Memory 
> metrics allows to measure memory usage (loaded pages) for the whole policy. 
> However, there's also a need to measure how much memory (or pages) is used by 
> each cache.
> Before 2.0 such information was accessible with 
> CacheMetrics#getOffHeapAllocatedSize, but current implemetation returns 0.
> We should either implement it or provide alternative metrics (e. g. 
> approximate number of loaded pages per cache). Please note that if 
> persistence is *disabled*, precise number of loaded pages per cache is not 
> defined - one page can contain entries of different caches.



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

[jira] [Updated] (IGNITE-4867) CacheMetricsSnapshot ignores 'size' and 'keySize' fields

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-4867:

Labels: iep-6 newbie  (was: newbie)

> CacheMetricsSnapshot ignores 'size' and 'keySize' fields
> 
>
> Key: IGNITE-4867
> URL: https://issues.apache.org/jira/browse/IGNITE-4867
> Project: Ignite
>  Issue Type: Bug
>Reporter: Dmitry Karachentsev
>Assignee: Ritesh Modi
>Priority: Major
>  Labels: iep-6, newbie
>
> 'size' and 'keySize' fields in CacheMetricsSnapshot must be serialized and 
> properly processed to show correct values in CacheClusterMetricsMXBeanImpl.



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

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

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-5539:

Fix Version/s: 2.5

> 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
>Priority: Major
>  Labels: iep-6
> Fix For: 2.5
>
>
> In memory only mode metrics show some not zero values.
> With persistence it shows zero.



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

[jira] [Updated] (IGNITE-3495) CacheMetrics.getAverage###Time is not calculated properly

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-3495:

Labels: iep-6  (was: )

> CacheMetrics.getAverage###Time is not calculated properly
> -
>
> Key: IGNITE-3495
> URL: https://issues.apache.org/jira/browse/IGNITE-3495
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Denis Magda
>Priority: Major
>  Labels: iep-6
> Attachments: ExampleNodeStartupClient.java, IGNITE_3495.patch, 
> example-default.xml
>
>
> {{CacheMetrics.getAverageGetTime}}, {{CacheMetrics.getAveragePutTime}} and 
> {{CacheMetrics.getAverageRemoveTime}} are not calculated properly in the 
> following scenario:
> - start a server node;
> - start a client node that will perform gets and puts;
> - {{CacheMetrics.getAverage###Time}} will always be 0 for the server node's 
> cluster group.
> The issue happens because {{CacheMetricsImpl.add###TimeNanos}} method is not 
> called on the server side when a metric related event happens.
> In the attache you can find source that showcases the bug.
> - start basic {{ExampleNodeStartup}} using attached configuration 
> {{example-default.xml}} conjuration;
> - start {{ExampleNodeStartupClient}}. You will see that average metrics are 
> not incremented.



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

[jira] [Updated] (IGNITE-2483) Cache metrics functionality for client nodes should be developed.

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-2483:

Labels: community iep-6  (was: community)

> Cache metrics functionality for client nodes should be developed.
> -
>
> Key: IGNITE-2483
> URL: https://issues.apache.org/jira/browse/IGNITE-2483
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Valentin Kulichenko
>Priority: Major
>  Labels: community, iep-6
>
> User list discussion: 
> http://apache-ignite-users.70518.x6.nabble.com/Is-there-a-way-to-get-cache-metrics-for-all-the-nodes-in-cluster-combined-td2674.html
> Currently there are at least three issues with cache metrics:
> # When metrics are acquired on client, average put times are always zero. 
> This happens because timings are calculated on the client, but puts are 
> counted on servers.
> # Size and keySize are always zero even if cache is not empty.
> # Default metrics() method that doesn't take a cluster group provides metrics 
> for local node only. So if it's called on client, they are always empty. It 
> should calculate metrics for the whole cluster instead.
> Also looks like this code is very undertested. Coverage should be 
> significantly improved.



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

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

[Denis Magda (JIRA)]

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

Denis Magda reassigned IGNITE-6994:
---

Assignee: Prachi Garg  (was: Denis Magda)

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



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

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

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-6994:
-

[~pgarg] , I've improved this section of the documentation. Please help with 
the review and complete the TODOs there:

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

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



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

[jira] [Resolved] (IGNITE-7574) Ignite Getting Started confuses developers

[Prachi Garg (JIRA)]

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

Prachi Garg resolved IGNITE-7574.
-
Resolution: Fixed

Reviewed and made minor edits.

> Ignite Getting Started confuses developers
> --
>
> Key: IGNITE-7574
> URL: https://issues.apache.org/jira/browse/IGNITE-7574
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Prachi Garg
>Priority: Blocker
> Fix For: 2.4
>
>
> By some reason, we suggest to build Ignite from sources at the very beginning 
> of the getting started guide:
> [https://apacheignite.readme.io/docs/getting-started]
> I got a feedback that this confuses a lot especially because it's 100% 
> optional! The reporter wasted much of his time trying to build Ignite with 
> JDK 9 and could succeed only after a private conversation with me.
>  
> Revisit and rework the guide.



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

[jira] [Closed] (IGNITE-7574) Ignite Getting Started confuses developers

[Prachi Garg (JIRA)]

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

Prachi Garg closed IGNITE-7574.
---

> Ignite Getting Started confuses developers
> --
>
> Key: IGNITE-7574
> URL: https://issues.apache.org/jira/browse/IGNITE-7574
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Prachi Garg
>Priority: Blocker
> Fix For: 2.4
>
>
> By some reason, we suggest to build Ignite from sources at the very beginning 
> of the getting started guide:
> [https://apacheignite.readme.io/docs/getting-started]
> I got a feedback that this confuses a lot especially because it's 100% 
> optional! The reporter wasted much of his time trying to build Ignite with 
> JDK 9 and could succeed only after a private conversation with me.
>  
> Revisit and rework the guide.



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

[jira] [Commented] (IGNITE-7588) Deprecate CacheLocalStore annotation

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7588:


Github user asfgit closed the pull request at:

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


> Deprecate CacheLocalStore annotation
> 
>
> Key: IGNITE-7588
> URL: https://issues.apache.org/jira/browse/IGNITE-7588
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 2.3, 2.4
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
>Priority: Major
>  Labels: deprecation
> Fix For: 2.5
>
>
> We should annotate @CacheLocalStore as @Depricated, because of using 
> CacheLocalStore annotation has the hidden issues like rebalancing and 
> possible data consistency issues.
> See [dev-list 
> discussion|http://apache-ignite-developers.2346864.n4.nabble.com/Should-we-annotate-CacheLocalStore-as-Depricated-tt26490.html]
>  for details.



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

[jira] [Closed] (IGNITE-7588) Deprecate CacheLocalStore annotation

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko closed IGNITE-7588.
---

> Deprecate CacheLocalStore annotation
> 
>
> Key: IGNITE-7588
> URL: https://issues.apache.org/jira/browse/IGNITE-7588
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 2.3, 2.4
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
>Priority: Major
>  Labels: deprecation
> Fix For: 2.5
>
>
> We should annotate @CacheLocalStore as @Depricated, because of using 
> CacheLocalStore annotation has the hidden issues like rebalancing and 
> possible data consistency issues.
> See [dev-list 
> discussion|http://apache-ignite-developers.2346864.n4.nabble.com/Should-we-annotate-CacheLocalStore-as-Depricated-tt26490.html]
>  for details.



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

[jira] [Commented] (IGNITE-7690) Move shared memory suite (IpcSharedMemoryCrashDetectionSelfTest) to Ignite Basic 2

[Ivan Rakov (JIRA)]

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

Ivan Rakov commented on IGNITE-7690:


Please take a look. I've also updated Basic 2 suite on public TC.

Regarding separate class for Basic 2 suite - we can't do it as most of Basic 2 
subsuites reside in different modules.

> Move shared memory suite (IpcSharedMemoryCrashDetectionSelfTest) to Ignite 
> Basic 2
> --
>
> Key: IGNITE-7690
> URL: https://issues.apache.org/jira/browse/IGNITE-7690
> Project: Ignite
>  Issue Type: Task
>Reporter: Dmitriy Pavlov
>Assignee: Ivan Rakov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> Test is flaky but included into basic (stable) suite
>Ignite Basic [ tests 1 ] i 
>  org.apache.ignite.testsuites.IgniteBasicTestSuite: 
> org.apache.ignite.internal.util.ipc.shmem.IpcSharedMemoryCrashDetectionSelfTest.testIgfsServerClientInteractionsUponClientKilling
>  (fail rate 2%) 
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-2464527718752484555=%3Cdefault%3E=testDetails
> It is better to move this test to basic 2 suite - place for flaky and long 
> running tests.
> It is also desired to introduce IgniteBasic2 suite in code with correct 
> comments on purpose



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

[jira] [Commented] (IGNITE-7690) Move shared memory suite (IpcSharedMemoryCrashDetectionSelfTest) to Ignite Basic 2

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7690:


GitHub user glukos opened a pull request:

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

IGNITE-7690 Move shared memory suite to Ignite Basic 2



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

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

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

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


commit b60356a440e929800da6fd654a179a1dfb69
Author: Ivan Rakov 
Date:   2018-02-13T20:02:04Z

IGNITE-7690 Move shared memory suite 
(IpcSharedMemoryCrashDetectionSelfTest) to Ignite Basic 2




> Move shared memory suite (IpcSharedMemoryCrashDetectionSelfTest) to Ignite 
> Basic 2
> --
>
> Key: IGNITE-7690
> URL: https://issues.apache.org/jira/browse/IGNITE-7690
> Project: Ignite
>  Issue Type: Task
>Reporter: Dmitriy Pavlov
>Assignee: Ivan Rakov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> Test is flaky but included into basic (stable) suite
>Ignite Basic [ tests 1 ] i 
>  org.apache.ignite.testsuites.IgniteBasicTestSuite: 
> org.apache.ignite.internal.util.ipc.shmem.IpcSharedMemoryCrashDetectionSelfTest.testIgfsServerClientInteractionsUponClientKilling
>  (fail rate 2%) 
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-2464527718752484555=%3Cdefault%3E=testDetails
> It is better to move this test to basic 2 suite - place for flaky and long 
> running tests.
> It is also desired to introduce IgniteBasic2 suite in code with correct 
> comments on purpose



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

[jira] [Commented] (IGNITE-7588) Deprecate CacheLocalStore annotation

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7588:


GitHub user daradurvs opened a pull request:

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

IGNITE-7588 Deprecate CacheLocalStore annotation



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

$ git pull https://github.com/daradurvs/ignite ignite-7588

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

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


commit ff3caa20e6ed7106002e59573067b18965bab3cf
Author: Vyacheslav Daradur 
Date:   2018-02-13T18:44:32Z

ignite-7588: @CacheLocaleStore was annotated as deprecated




> Deprecate CacheLocalStore annotation
> 
>
> Key: IGNITE-7588
> URL: https://issues.apache.org/jira/browse/IGNITE-7588
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 2.3, 2.4
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
>Priority: Major
>  Labels: deprecation
> Fix For: 2.5
>
>
> We should annotate @CacheLocalStore as @Depricated, because of using 
> CacheLocalStore annotation has the hidden issues like rebalancing and 
> possible data consistency issues.
> See [dev-list 
> discussion|http://apache-ignite-developers.2346864.n4.nabble.com/Should-we-annotate-CacheLocalStore-as-Depricated-tt26490.html]
>  for details.



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

[jira] [Comment Edited] (IGNITE-7660) Refactor LSQR algorithm

[Anton Dmitriev (JIRA)]

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

Anton Dmitriev edited comment on IGNITE-7660 at 2/13/18 6:39 PM:
-

I've updated the description, please take a look.


was (Author: dmitrievanthony):
I've updated description, please take a look.

> Refactor LSQR algorithm
> ---
>
> Key: IGNITE-7660
> URL: https://issues.apache.org/jira/browse/IGNITE-7660
> Project: Ignite
>  Issue Type: Improvement
>  Components: ml
>Reporter: Anton Dmitriev
>Priority: Minor
>
> This issues is the nest step of the IGNITE-7438 task.
> In the IGNITE-7438 the AbstractLSQR implementation has been copied from the 
> SciPy implementation which has been copies from another old implementation. 
> As result the code in the 
> [AbstractLSQR|https://github.com/apache/ignite/blob/master/modules/ml/src/main/java/org/apache/ignite/ml/math/isolve/lsqr/AbstractLSQR.java]
>  looks a bit weird. All variables have meaningless names and the whole 
> algorithm written as the one method.
> The goal of this task is to refactor the LSQR code and:
>  * Make variable names more meaningful.
>  * Add comments to the variables and result (see 
> [LSQRResult|https://github.com/apache/ignite/blob/master/modules/ml/src/main/java/org/apache/ignite/ml/math/isolve/lsqr/LSQRResult.java]).
>  * Move parts of the algorithm into separate methods where it's appropriate.



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

[jira] [Resolved] (IGNITE-7167) Optimize 'select count(*) from Table'

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko resolved IGNITE-7167.
-
Resolution: Won't Fix  (was: Duplicate)

> Optimize 'select count(*) from Table'
> -
>
> Key: IGNITE-7167
> URL: https://issues.apache.org/jira/browse/IGNITE-7167
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Priority: Major
>
> Currently query like {{select count(*) from Table}} effectively scans the 
> cache and take a lot of time for large datasets. Probably makes sense to 
> optimize it to use {{IgniteCache#size}} directly when possible.



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

[jira] [Closed] (IGNITE-7167) Optimize 'select count(*) from Table'

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko closed IGNITE-7167.
---

> Optimize 'select count(*) from Table'
> -
>
> Key: IGNITE-7167
> URL: https://issues.apache.org/jira/browse/IGNITE-7167
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Priority: Major
>
> Currently query like {{select count(*) from Table}} effectively scans the 
> cache and take a lot of time for large datasets. Probably makes sense to 
> optimize it to use {{IgniteCache#size}} directly when possible.



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

[jira] [Commented] (IGNITE-7660) Refactor LSQR algorithm

[Anton Dmitriev (JIRA)]

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

Anton Dmitriev commented on IGNITE-7660:


I've updated description, please take a look.

> Refactor LSQR algorithm
> ---
>
> Key: IGNITE-7660
> URL: https://issues.apache.org/jira/browse/IGNITE-7660
> Project: Ignite
>  Issue Type: Improvement
>  Components: ml
>Reporter: Anton Dmitriev
>Priority: Minor
>
> This issues is the nest step of the IGNITE-7438 task.
> In the IGNITE-7438 the AbstractLSQR implementation has been copied from the 
> SciPy implementation which has been copies from another old implementation. 
> As result the code in the 
> [AbstractLSQR|https://github.com/apache/ignite/blob/master/modules/ml/src/main/java/org/apache/ignite/ml/math/isolve/lsqr/AbstractLSQR.java]
>  looks a bit weird. All variables have meaningless names and the whole 
> algorithm written as the one method.
> The goal of this task is to refactor the LSQR code and:
>  * Make variable names more meaningful.
>  * Add comments to the variables and result (see 
> [LSQRResult|https://github.com/apache/ignite/blob/master/modules/ml/src/main/java/org/apache/ignite/ml/math/isolve/lsqr/LSQRResult.java]).
>  * Move parts of the algorithm into separate methods where it's appropriate.



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

[jira] [Updated] (IGNITE-7660) Refactor LSQR algorithm

[Anton Dmitriev (JIRA)]

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

Anton Dmitriev updated IGNITE-7660:
---
Description: 
This issues is the nest step of the IGNITE-7438 task.

In the IGNITE-7438 the AbstractLSQR implementation has been copied from the 
SciPy implementation which has been copies from another old implementation. As 
result the code in the 
[AbstractLSQR|https://github.com/apache/ignite/blob/master/modules/ml/src/main/java/org/apache/ignite/ml/math/isolve/lsqr/AbstractLSQR.java]
 looks a bit weird. All variables have meaningless names and the whole 
algorithm written as the one method.

The goal of this task is to refactor the LSQR code and:
 * Make variable names more meaningful.
 * Add comments to the variables and result (see 
[LSQRResult|https://github.com/apache/ignite/blob/master/modules/ml/src/main/java/org/apache/ignite/ml/math/isolve/lsqr/LSQRResult.java]).
 * Move parts of the algorithm into separate methods where it's appropriate.

  was:We need to refactor LSQR algorithm 
(`org.apache.ignite.ml.math.isolve.lsqr.AbstractLSQR`) to be more "Java". 
Currently it's adopted Python/Fortran code.


> Refactor LSQR algorithm
> ---
>
> Key: IGNITE-7660
> URL: https://issues.apache.org/jira/browse/IGNITE-7660
> Project: Ignite
>  Issue Type: Improvement
>  Components: ml
>Reporter: Anton Dmitriev
>Priority: Minor
>
> This issues is the nest step of the IGNITE-7438 task.
> In the IGNITE-7438 the AbstractLSQR implementation has been copied from the 
> SciPy implementation which has been copies from another old implementation. 
> As result the code in the 
> [AbstractLSQR|https://github.com/apache/ignite/blob/master/modules/ml/src/main/java/org/apache/ignite/ml/math/isolve/lsqr/AbstractLSQR.java]
>  looks a bit weird. All variables have meaningless names and the whole 
> algorithm written as the one method.
> The goal of this task is to refactor the LSQR code and:
>  * Make variable names more meaningful.
>  * Add comments to the variables and result (see 
> [LSQRResult|https://github.com/apache/ignite/blob/master/modules/ml/src/main/java/org/apache/ignite/ml/math/isolve/lsqr/LSQRResult.java]).
>  * Move parts of the algorithm into separate methods where it's appropriate.



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

[jira] [Commented] (IGNITE-7660) Refactor LSQR algorithm

[Boran Sahindal (JIRA)]

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

Boran Sahindal commented on IGNITE-7660:


We are starting right away. We would also appriciate a little more detailed 
description of the issue. We generally understand the concept and the task but 
we would like to hear your opinions about what parts in the code should be more 
"Java" - whenever you have time

> Refactor LSQR algorithm
> ---
>
> Key: IGNITE-7660
> URL: https://issues.apache.org/jira/browse/IGNITE-7660
> Project: Ignite
>  Issue Type: Improvement
>  Components: ml
>Reporter: Anton Dmitriev
>Priority: Minor
>
> We need to refactor LSQR algorithm 
> (`org.apache.ignite.ml.math.isolve.lsqr.AbstractLSQR`) to be more "Java". 
> Currently it's adopted Python/Fortran code.



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

[jira] [Commented] (IGNITE-7574) Ignite Getting Started confuses developers

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-7574:
-

[~pgarg] , please review the whole page and close the ticket:

https://apacheignite.readme.io/v2.3/docs/getting-started-24

> Ignite Getting Started confuses developers
> --
>
> Key: IGNITE-7574
> URL: https://issues.apache.org/jira/browse/IGNITE-7574
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Blocker
> Fix For: 2.4
>
>
> By some reason, we suggest to build Ignite from sources at the very beginning 
> of the getting started guide:
> [https://apacheignite.readme.io/docs/getting-started]
> I got a feedback that this confuses a lot especially because it's 100% 
> optional! The reporter wasted much of his time trying to build Ignite with 
> JDK 9 and could succeed only after a private conversation with me.
>  
> Revisit and rework the guide.



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

[jira] [Assigned] (IGNITE-7574) Ignite Getting Started confuses developers

[Denis Magda (JIRA)]

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

Denis Magda reassigned IGNITE-7574:
---

Assignee: Prachi Garg  (was: Denis Magda)

> Ignite Getting Started confuses developers
> --
>
> Key: IGNITE-7574
> URL: https://issues.apache.org/jira/browse/IGNITE-7574
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Prachi Garg
>Priority: Blocker
> Fix For: 2.4
>
>
> By some reason, we suggest to build Ignite from sources at the very beginning 
> of the getting started guide:
> [https://apacheignite.readme.io/docs/getting-started]
> I got a feedback that this confuses a lot especially because it's 100% 
> optional! The reporter wasted much of his time trying to build Ignite with 
> JDK 9 and could succeed only after a private conversation with me.
>  
> Revisit and rework the guide.



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

[jira] [Commented] (IGNITE-7695) Enable Ignite Update Notifier tests

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7695:


Github user asfgit closed the pull request at:

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


> Enable Ignite Update Notifier tests
> ---
>
> Key: IGNITE-7695
> URL: https://issues.apache.org/jira/browse/IGNITE-7695
> Project: Ignite
>  Issue Type: Task
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> org.apache.ignite.internal.GridVersionSelfTest#testVersions
> org.apache.ignite.internal.IgniteUpdateNotifierPerClusterSettingSelfTest#testNotifierEnabledForCluster
> and unmute on TC



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

[jira] [Updated] (IGNITE-7695) Enable Ignite Update Notifier tests

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-7695:
---
Labels: MakeTeamcityGreenAgain  (was: )

> Enable Ignite Update Notifier tests
> ---
>
> Key: IGNITE-7695
> URL: https://issues.apache.org/jira/browse/IGNITE-7695
> Project: Ignite
>  Issue Type: Task
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> org.apache.ignite.internal.GridVersionSelfTest#testVersions
> org.apache.ignite.internal.IgniteUpdateNotifierPerClusterSettingSelfTest#testNotifierEnabledForCluster
> and unmute on TC



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

[jira] [Updated] (IGNITE-7695) Enable Ignite Update Notifier tests

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-7695:
---
Fix Version/s: 2.5

> Enable Ignite Update Notifier tests
> ---
>
> Key: IGNITE-7695
> URL: https://issues.apache.org/jira/browse/IGNITE-7695
> Project: Ignite
>  Issue Type: Task
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> org.apache.ignite.internal.GridVersionSelfTest#testVersions
> org.apache.ignite.internal.IgniteUpdateNotifierPerClusterSettingSelfTest#testNotifierEnabledForCluster
> and unmute on TC



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

[jira] [Commented] (IGNITE-7695) Enable Ignite Update Notifier tests

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7695:


GitHub user dspavlov opened a pull request:

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

IGNITE-7695: Enable Ignite Update Notifier tests



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

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

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

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


commit e2850e2d6116ccdea809bb925aa90cf530e817ee
Author: dpavlov 
Date:   2018-02-13T17:16:51Z

IGNITE-7695: Enable Ignite Update Notifier tests




> Enable Ignite Update Notifier tests
> ---
>
> Key: IGNITE-7695
> URL: https://issues.apache.org/jira/browse/IGNITE-7695
> Project: Ignite
>  Issue Type: Task
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Major
>
> org.apache.ignite.internal.GridVersionSelfTest#testVersions
> org.apache.ignite.internal.IgniteUpdateNotifierPerClusterSettingSelfTest#testNotifierEnabledForCluster
> and unmute on TC



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

[jira] [Created] (IGNITE-7695) Enable Ignite Update Notifier tests

[Dmitriy Pavlov (JIRA)]

Dmitriy Pavlov created IGNITE-7695:
--

 Summary: Enable Ignite Update Notifier tests
 Key: IGNITE-7695
 URL: https://issues.apache.org/jira/browse/IGNITE-7695
 Project: Ignite
  Issue Type: Task
Reporter: Dmitriy Pavlov
Assignee: Dmitriy Pavlov


org.apache.ignite.internal.GridVersionSelfTest#testVersions
org.apache.ignite.internal.IgniteUpdateNotifierPerClusterSettingSelfTest#testNotifierEnabledForCluster

and unmute on TC



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

[jira] [Commented] (IGNITE-7640) Refactor DiscoveryDataClusterState to be immutable

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7640:


GitHub user SharplEr opened a pull request:

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

IGNITE-7640: make DiscoveryDataClusterState immutable

for CI testing

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

$ git pull https://github.com/SharplEr/ignite ignite-7640

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

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


commit 9a52c8a851006bea1c647f694df8ea398da50595
Author: Alexander Menshikov 
Date:   2018-02-13T16:15:36Z

make DiscoveryDataClusterState immutable




> Refactor DiscoveryDataClusterState to be immutable
> --
>
> Key: IGNITE-7640
> URL: https://issues.apache.org/jira/browse/IGNITE-7640
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.4
>Reporter: Alexey Goncharuk
>Assignee: Alexander Menshikov
>Priority: Major
> Fix For: 2.5
>
>




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

[jira] [Updated] (IGNITE-7694) testActiveClientReconnectToInactiveCluster hangs because of an assertion

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-7694:
---
Labels: MakeTeamcityGreenAgain  (was: )

> testActiveClientReconnectToInactiveCluster hangs because of an assertion
> 
>
> Key: IGNITE-7694
> URL: https://issues.apache.org/jira/browse/IGNITE-7694
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.5
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> This is a regression from
> The test hangs because there is an assertion happened after the client 
> reconnects to the cluster:
> {code}
> [2018-02-13 
> 19:36:33,559][ERROR][tcp-client-disco-msg-worker-#18%nodeClient%][TcpDiscoverySpi]
>  Failed to unmarshal discovery custom message.
> java.lang.AssertionError: lastAffVer=AffinityTopologyVersion [topVer=4, 
> minorTopVer=0], topVer=AffinityTopologyVersion [topVer=3, minorTopVer=1]
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onDiscoveryEvent(CacheAffinitySharedManager.java:185)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onDiscoveryEvent(GridCacheProcessor.java:3231)
>   at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:681)
>   at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:576)
>   at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2414)
>   at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processCustomMessage(ClientImpl.java:2320)
>   at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1897)
>   at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1781)
>   at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {code}
> The reason for the assertion is that the client does not clear {{lastAffVer}} 
> field when disconnected, and cluster is restarted when the client is in the 
> disconnected state.



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

[jira] [Updated] (IGNITE-7694) testActiveClientReconnectToInactiveCluster hangs because of an assertion

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk updated IGNITE-7694:
-
Description: 
This is a regression from

The test hangs because there is an assertion happened after the client 
reconnects to the cluster:
{code}
[2018-02-13 
19:36:33,559][ERROR][tcp-client-disco-msg-worker-#18%nodeClient%][TcpDiscoverySpi]
 Failed to unmarshal discovery custom message.
java.lang.AssertionError: lastAffVer=AffinityTopologyVersion [topVer=4, 
minorTopVer=0], topVer=AffinityTopologyVersion [topVer=3, minorTopVer=1]
at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onDiscoveryEvent(CacheAffinitySharedManager.java:185)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.onDiscoveryEvent(GridCacheProcessor.java:3231)
at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:681)
at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:576)
at 
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2414)
at 
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processCustomMessage(ClientImpl.java:2320)
at 
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1897)
at 
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1781)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
{code}

The reason for the assertion is that the client does not clear {{lastAffVer}} 
field when disconnected, and cluster is restarted when the client is in the 
disconnected state.

> testActiveClientReconnectToInactiveCluster hangs because of an assertion
> 
>
> Key: IGNITE-7694
> URL: https://issues.apache.org/jira/browse/IGNITE-7694
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.5
>Reporter: Alexey Goncharuk
>Priority: Major
> Fix For: 2.5
>
>
> This is a regression from
> The test hangs because there is an assertion happened after the client 
> reconnects to the cluster:
> {code}
> [2018-02-13 
> 19:36:33,559][ERROR][tcp-client-disco-msg-worker-#18%nodeClient%][TcpDiscoverySpi]
>  Failed to unmarshal discovery custom message.
> java.lang.AssertionError: lastAffVer=AffinityTopologyVersion [topVer=4, 
> minorTopVer=0], topVer=AffinityTopologyVersion [topVer=3, minorTopVer=1]
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onDiscoveryEvent(CacheAffinitySharedManager.java:185)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onDiscoveryEvent(GridCacheProcessor.java:3231)
>   at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:681)
>   at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:576)
>   at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2414)
>   at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processCustomMessage(ClientImpl.java:2320)
>   at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1897)
>   at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1781)
>   at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {code}
> The reason for the assertion is that the client does not clear {{lastAffVer}} 
> field when disconnected, and cluster is restarted when the client is in the 
> disconnected state.



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

[jira] [Commented] (IGNITE-7694) testActiveClientReconnectToInactiveCluster hangs because of an assertion

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-7694:
--

At the first glance, setting lastAffVer to null in the onDisconnected callback 
fixes the issue.

> testActiveClientReconnectToInactiveCluster hangs because of an assertion
> 
>
> Key: IGNITE-7694
> URL: https://issues.apache.org/jira/browse/IGNITE-7694
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.5
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.5
>
>
> This is a regression from
> The test hangs because there is an assertion happened after the client 
> reconnects to the cluster:
> {code}
> [2018-02-13 
> 19:36:33,559][ERROR][tcp-client-disco-msg-worker-#18%nodeClient%][TcpDiscoverySpi]
>  Failed to unmarshal discovery custom message.
> java.lang.AssertionError: lastAffVer=AffinityTopologyVersion [topVer=4, 
> minorTopVer=0], topVer=AffinityTopologyVersion [topVer=3, minorTopVer=1]
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onDiscoveryEvent(CacheAffinitySharedManager.java:185)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onDiscoveryEvent(GridCacheProcessor.java:3231)
>   at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:681)
>   at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:576)
>   at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2414)
>   at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processCustomMessage(ClientImpl.java:2320)
>   at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1897)
>   at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1781)
>   at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {code}
> The reason for the assertion is that the client does not clear {{lastAffVer}} 
> field when disconnected, and cluster is restarted when the client is in the 
> disconnected state.



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

[jira] [Assigned] (IGNITE-7694) testActiveClientReconnectToInactiveCluster hangs because of an assertion

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk reassigned IGNITE-7694:


Assignee: Alexey Goncharuk

> testActiveClientReconnectToInactiveCluster hangs because of an assertion
> 
>
> Key: IGNITE-7694
> URL: https://issues.apache.org/jira/browse/IGNITE-7694
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.5
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.5
>
>
> This is a regression from
> The test hangs because there is an assertion happened after the client 
> reconnects to the cluster:
> {code}
> [2018-02-13 
> 19:36:33,559][ERROR][tcp-client-disco-msg-worker-#18%nodeClient%][TcpDiscoverySpi]
>  Failed to unmarshal discovery custom message.
> java.lang.AssertionError: lastAffVer=AffinityTopologyVersion [topVer=4, 
> minorTopVer=0], topVer=AffinityTopologyVersion [topVer=3, minorTopVer=1]
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onDiscoveryEvent(CacheAffinitySharedManager.java:185)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onDiscoveryEvent(GridCacheProcessor.java:3231)
>   at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:681)
>   at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:576)
>   at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2414)
>   at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processCustomMessage(ClientImpl.java:2320)
>   at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1897)
>   at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1781)
>   at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {code}
> The reason for the assertion is that the client does not clear {{lastAffVer}} 
> field when disconnected, and cluster is restarted when the client is in the 
> disconnected state.



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

[jira] [Updated] (IGNITE-7694) testActiveClientReconnectToInactiveCluster hangs because of an assertion

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk updated IGNITE-7694:
-
Fix Version/s: 2.5

> testActiveClientReconnectToInactiveCluster hangs because of an assertion
> 
>
> Key: IGNITE-7694
> URL: https://issues.apache.org/jira/browse/IGNITE-7694
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.5
>Reporter: Alexey Goncharuk
>Priority: Major
> Fix For: 2.5
>
>




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

[jira] [Updated] (IGNITE-7694) testActiveClientReconnectToInactiveCluster hangs because of an assertion

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk updated IGNITE-7694:
-
Affects Version/s: 2.5

> testActiveClientReconnectToInactiveCluster hangs because of an assertion
> 
>
> Key: IGNITE-7694
> URL: https://issues.apache.org/jira/browse/IGNITE-7694
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.5
>Reporter: Alexey Goncharuk
>Priority: Major
> Fix For: 2.5
>
>




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

[jira] [Updated] (IGNITE-7694) testActiveClientReconnectToInactiveCluster hangs because of an assertion

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk updated IGNITE-7694:
-
Component/s: persistence

> testActiveClientReconnectToInactiveCluster hangs because of an assertion
> 
>
> Key: IGNITE-7694
> URL: https://issues.apache.org/jira/browse/IGNITE-7694
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.5
>Reporter: Alexey Goncharuk
>Priority: Major
> Fix For: 2.5
>
>




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

[jira] [Created] (IGNITE-7694) testActiveClientReconnectToInactiveCluster hangs because of an assertion

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-7694:


 Summary: testActiveClientReconnectToInactiveCluster hangs because 
of an assertion
 Key: IGNITE-7694
 URL: https://issues.apache.org/jira/browse/IGNITE-7694
 Project: Ignite
  Issue Type: Bug
Reporter: Alexey Goncharuk






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

[jira] [Commented] (IGNITE-7660) Refactor LSQR algorithm

[Anton Dmitriev (JIRA)]

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

Anton Dmitriev commented on IGNITE-7660:


Hello. As far as I know nothing has been done regarding this issue and it will 
be great if you start working on it.

> Refactor LSQR algorithm
> ---
>
> Key: IGNITE-7660
> URL: https://issues.apache.org/jira/browse/IGNITE-7660
> Project: Ignite
>  Issue Type: Improvement
>  Components: ml
>Reporter: Anton Dmitriev
>Priority: Minor
>
> We need to refactor LSQR algorithm 
> (`org.apache.ignite.ml.math.isolve.lsqr.AbstractLSQR`) to be more "Java". 
> Currently it's adopted Python/Fortran code.



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

[jira] [Commented] (IGNITE-7686) PDS Direct IO failure: IgnitePdsEvictionTest.testPageEviction

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7686:


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

> PDS Direct IO failure: IgnitePdsEvictionTest.testPageEviction 
> --
>
> Key: IGNITE-7686
> URL: https://issues.apache.org/jira/browse/IGNITE-7686
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> java.util.concurrent.TimeoutException: Test has been timed out 
> [test=testPageEviction, timeout=30] 
> Reproduced only on TC agent
> https://ci.ignite.apache.org/viewLog.html?buildId=1090347=buildResultsDiv=IgniteTests24Java8_IgnitePds1DirectIo#testNameId3144891032708936796



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

[jira] [Commented] (IGNITE-6890) General way for handling Ignite failures

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-6890:
--

[~cyberdemon],

We should not map
   case NOOP:
 return NOOP;

Instead of doing this onSegmentation  should call 
IgniteFailureProcessor -> restartJvm or stopNode directly with correct reason 
(IgniteFailureType)

> General way for handling Ignite failures
> 
>
> Key: IGNITE-6890
> URL: https://issues.apache.org/jira/browse/IGNITE-6890
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Anton Vinogradov
>Assignee: Dmitriy Sorokin
>Priority: Major
>  Labels: iep-7
> Fix For: 2.5
>
>
> Ignite failures which should be handled are:
>  # Topology segmentation;
>  # Exchange worker stop;
>  # Persistence errors.
> Proper behavior should be selected according to result of calling 
> IgniteFailureHandler instance, custom implementation of which can be provided 
> in IgniteConfiguration. It can be node stop, restart or nothing.



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

[jira] [Created] (IGNITE-7693) New node joining via ZookeeperDiscoverySpi should print out its ZooKeeper sessionId

[Sergey Chugunov (JIRA)]

Sergey Chugunov created IGNITE-7693:
---

 Summary: New node joining via ZookeeperDiscoverySpi should print 
out its ZooKeeper sessionId
 Key: IGNITE-7693
 URL: https://issues.apache.org/jira/browse/IGNITE-7693
 Project: Ignite
  Issue Type: Improvement
Reporter: Sergey Chugunov


For now there is no way to match Ignite nodes joining to Ignite cluster with 
log entries in ZooKeeper nodes' logs.

In ZooKeeper logs there are entries like this:
{noformat}
myid:1] - INFO  [CommitProcessor:1:ZooKeeperServer@687] - Established session 
0x161575d88530007 with negotiated timeout 1 for client 
/:{noformat}
but it is hard to match them with Ignite nodes when there are several started 
on the same host.

If Ignite node prints out its session on join it makes correlating them with 
particular ZooKeeper instance much easier.



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

[jira] [Updated] (IGNITE-7693) New node joining via ZookeeperDiscoverySpi should print out its ZooKeeper sessionId

[Sergey Chugunov (JIRA)]

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

Sergey Chugunov updated IGNITE-7693:

Fix Version/s: 2.5

> New node joining via ZookeeperDiscoverySpi should print out its ZooKeeper 
> sessionId
> ---
>
> Key: IGNITE-7693
> URL: https://issues.apache.org/jira/browse/IGNITE-7693
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Sergey Chugunov
>Priority: Major
> Fix For: 2.5
>
>
> For now there is no way to match Ignite nodes joining to Ignite cluster with 
> log entries in ZooKeeper nodes' logs.
> In ZooKeeper logs there are entries like this:
> {noformat}
> myid:1] - INFO  [CommitProcessor:1:ZooKeeperServer@687] - Established session 
> 0x161575d88530007 with negotiated timeout 1 for client 
> /:{noformat}
> but it is hard to match them with Ignite nodes when there are several started 
> on the same host.
> If Ignite node prints out its session on join it makes correlating them with 
> particular ZooKeeper instance much easier.



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

[jira] [Commented] (IGNITE-7090) Semaphore Stuck when no acquirers to assign permit

[Tim Onyschak (JIRA)]

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

Tim Onyschak commented on IGNITE-7090:
--

[~vladisav] code has been updated, sorry for so many iteration. Let me know if 
i finally have it right. 

Thanks

> Semaphore Stuck when no acquirers to assign permit
> --
>
> Key: IGNITE-7090
> URL: https://issues.apache.org/jira/browse/IGNITE-7090
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, data structures
>Affects Versions: 2.1, 2.4
>Reporter: Tim Onyschak
>Assignee: Tim Onyschak
>Priority: Major
> Fix For: 2.5
>
> Attachments: SemaphoreFailoverNoWaitingAcquirerTest.java
>
>
> If no acquirers are available to take permit of semaphore, the permit never 
> gets release and any further acquirerers will wait forever. 
> On node shut down DataStructuresProcessor.dsMap gets cleared out prior to 
> event listener being able to execute onNodeRemoved, hence owner is never 
> cleared out if it was unable to pass to a different acquirer. 
>  



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

[jira] [Updated] (IGNITE-7692) affinityCall and affinityRun may execute code on backup partitions

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk updated IGNITE-7692:
-
Component/s: sql

> affinityCall and affinityRun may execute code on backup partitions
> --
>
> Key: IGNITE-7692
> URL: https://issues.apache.org/jira/browse/IGNITE-7692
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Priority: Major
>  Labels: usability
> Fix For: 2.5
>
>
> Apparently, the affinityCall and affinityRun methods reserve partitions and 
> check their state to be OWNING, however, if topology changes and partition 
> role is changed to backup from primary, the code is still executed.
> This can be an issue if a user executes a local SQL query inside the 
> affinityCall runnable. In this case, the query result may return null.
> This can be observed in the 
> IgniteCacheLockPartitionOnAffinityRunTest#getPersonsCountSingleCache - note 
> an additional check I've added to make the test pass.
> I think it is ok to have an old semantics for the API, because in some cases 
> (scan query, local gets) a backup OWNER is enough. However, it looks like we 
> need to add another API method to enforce that affinity run be executed on 
> primary nodes and forbid primary role change.
> Another option is to detect a topology version of the affinity run and use 
> that version for local SQL queries.



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

[jira] [Updated] (IGNITE-7692) affinityCall and affinityRun may execute code on backup partitions

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk updated IGNITE-7692:
-
Labels: usability  (was: )

> affinityCall and affinityRun may execute code on backup partitions
> --
>
> Key: IGNITE-7692
> URL: https://issues.apache.org/jira/browse/IGNITE-7692
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Priority: Major
>  Labels: usability
> Fix For: 2.5
>
>
> Apparently, the affinityCall and affinityRun methods reserve partitions and 
> check their state to be OWNING, however, if topology changes and partition 
> role is changed to backup from primary, the code is still executed.
> This can be an issue if a user executes a local SQL query inside the 
> affinityCall runnable. In this case, the query result may return null.
> This can be observed in the 
> IgniteCacheLockPartitionOnAffinityRunTest#getPersonsCountSingleCache - note 
> an additional check I've added to make the test pass.
> I think it is ok to have an old semantics for the API, because in some cases 
> (scan query, local gets) a backup OWNER is enough. However, it looks like we 
> need to add another API method to enforce that affinity run be executed on 
> primary nodes and forbid primary role change.
> Another option is to detect a topology version of the affinity run and use 
> that version for local SQL queries.



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

[jira] [Created] (IGNITE-7692) affinityCall and affinityRun may execute code on backup partitions

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-7692:


 Summary: affinityCall and affinityRun may execute code on backup 
partitions
 Key: IGNITE-7692
 URL: https://issues.apache.org/jira/browse/IGNITE-7692
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.1
Reporter: Alexey Goncharuk
 Fix For: 2.5


Apparently, the affinityCall and affinityRun methods reserve partitions and 
check their state to be OWNING, however, if topology changes and partition role 
is changed to backup from primary, the code is still executed.

This can be an issue if a user executes a local SQL query inside the 
affinityCall runnable. In this case, the query result may return null.

This can be observed in the 
IgniteCacheLockPartitionOnAffinityRunTest#getPersonsCountSingleCache - note an 
additional check I've added to make the test pass.

I think it is ok to have an old semantics for the API, because in some cases 
(scan query, local gets) a backup OWNER is enough. However, it looks like we 
need to add another API method to enforce that affinity run be executed on 
primary nodes and forbid primary role change.
Another option is to detect a topology version of the affinity run and use that 
version for local SQL queries.



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

[jira] [Created] (IGNITE-7691) Provide info about DECIMAL column scale and precision

[Nikolay Izhikov (JIRA)]

Nikolay Izhikov created IGNITE-7691:
---

 Summary: Provide info about DECIMAL column scale and precision
 Key: IGNITE-7691
 URL: https://issues.apache.org/jira/browse/IGNITE-7691
 Project: Ignite
  Issue Type: Improvement
  Components: sql
Affects Versions: 2.4
Reporter: Nikolay Izhikov
Assignee: Nikolay Izhikov
 Fix For: 2.5


Currently, it impossible to obtain scale and precision of DECIMAL column from 
sql table metadata.
Ignite should provide those type of meta information.



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

[jira] [Created] (IGNITE-7690) Move shared memory suite (IpcSharedMemoryCrashDetectionSelfTest) to Ignite Basic 2

[Dmitriy Pavlov (JIRA)]

Dmitriy Pavlov created IGNITE-7690:
--

 Summary: Move shared memory suite 
(IpcSharedMemoryCrashDetectionSelfTest) to Ignite Basic 2
 Key: IGNITE-7690
 URL: https://issues.apache.org/jira/browse/IGNITE-7690
 Project: Ignite
  Issue Type: Task
Reporter: Dmitriy Pavlov
Assignee: Ivan Rakov


Test is flaky but included into basic (stable) suite
   Ignite Basic [ tests 1 ] i 
 org.apache.ignite.testsuites.IgniteBasicTestSuite: 
org.apache.ignite.internal.util.ipc.shmem.IpcSharedMemoryCrashDetectionSelfTest.testIgfsServerClientInteractionsUponClientKilling
 (fail rate 2%) 

https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-2464527718752484555=%3Cdefault%3E=testDetails


It is better to move this test to basic 2 suite - place for flaky and long 
running tests.

It is also desired to introduce IgniteBasic2 suite in code with correct 
comments on purpose



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

[jira] [Commented] (IGNITE-7481) Suspended transaction rollbacs incorrectly

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7481:


GitHub user voipp opened a pull request:

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

IGNITE-7481 suspended tx timeout rollback fix



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

$ git pull https://github.com/voipp/ignite IGNITE-7481

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

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


commit ef84639e627b3a7060da960dd61c21a6ffebdbf1
Author: voipp 
Date:   2018-02-13T15:15:00Z

IGNITE-7481 suspended tx timeout rollback fix




> Suspended transaction rollbacs incorrectly  
> 
>
> Key: IGNITE-7481
> URL: https://issues.apache.org/jira/browse/IGNITE-7481
> Project: Ignite
>  Issue Type: Bug
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Major
>
> When we suspend transaction, and then timeout occures , transaction would be 
> rollbacked incorrectly.
> One of incorrect behaviors : rollback\end tx metrics are not incremented.
> Thre reason is that transactionMap is cleared when we suspend transaction.
> We need not clear transactionMap.



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

[jira] [Assigned] (IGNITE-7640) Refactor DiscoveryDataClusterState to be immutable

[Alexander Menshikov (JIRA)]

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

Alexander Menshikov reassigned IGNITE-7640:
---

Assignee: Alexander Menshikov

> Refactor DiscoveryDataClusterState to be immutable
> --
>
> Key: IGNITE-7640
> URL: https://issues.apache.org/jira/browse/IGNITE-7640
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.4
>Reporter: Alexey Goncharuk
>Assignee: Alexander Menshikov
>Priority: Major
> Fix For: 2.5
>
>




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

[jira] [Commented] (IGNITE-7632) NPE in IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.updateIgfsMetrics()

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7632:


Hi [~pvinokurov], why did you use basic tests subset? It is required to run-all 
tests, basic do not cover this code.

> NPE in IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.updateIgfsMetrics()
> ---
>
> Key: IGNITE-7632
> URL: https://issues.apache.org/jira/browse/IGNITE-7632
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.3
>Reporter: Alexandr Kuramshin
>Assignee: Pavel Vinokurov
>Priority: Major
>
> Occurs on destroying cache while rebuilding indices in progress
> {noformat}
> Partition eviction failed, this can cause grid hang.
> java.lang.NullPointerException: null
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.updateIgfsMetrics(IgniteCacheOffheapManagerImpl.java:1576)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishRemove(IgniteCacheOffheapManagerImpl.java:1403)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:1368)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.remove(GridCacheOffheapManager.java:1312)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:368)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:3224)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.clearInternal(GridDhtCacheEntry.java:588)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.clearAll(GridDhtLocalPartition.java:895)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.tryEvict(GridDhtLocalPartition.java:753)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader$3.call(GridDhtPreloader.java:593)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader$3.call(GridDhtPreloader.java:580)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6639)
>   at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$2.body(GridClosureProcessor.java:967)
> ...
> {noformat}



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

[jira] [Commented] (IGNITE-7660) Refactor LSQR algorithm

[Boran Sahindal (JIRA)]

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

Boran Sahindal commented on IGNITE-7660:


We, 5 students, as a part of our software engineering course, are planning to 
work on this issue. I would like to know if any work has been done since the 
issues creation that is not mentioned here.

> Refactor LSQR algorithm
> ---
>
> Key: IGNITE-7660
> URL: https://issues.apache.org/jira/browse/IGNITE-7660
> Project: Ignite
>  Issue Type: Improvement
>  Components: ml
>Reporter: Anton Dmitriev
>Priority: Minor
>
> We need to refactor LSQR algorithm 
> (`org.apache.ignite.ml.math.isolve.lsqr.AbstractLSQR`) to be more "Java". 
> Currently it's adopted Python/Fortran code.



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

[jira] [Created] (IGNITE-7689) IgnitePdsBinaryMetadataOnClusterRestartTest flaky fails on TC

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-7689:


 Summary: IgnitePdsBinaryMetadataOnClusterRestartTest flaky fails 
on TC
 Key: IGNITE-7689
 URL: https://issues.apache.org/jira/browse/IGNITE-7689
 Project: Ignite
  Issue Type: Test
Reporter: Alexey Goncharuk






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

[jira] [Assigned] (IGNITE-7689) IgnitePdsBinaryMetadataOnClusterRestartTest flaky fails on TC

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk reassigned IGNITE-7689:


Assignee: Alexey Goncharuk

> IgnitePdsBinaryMetadataOnClusterRestartTest flaky fails on TC
> -
>
> Key: IGNITE-7689
> URL: https://issues.apache.org/jira/browse/IGNITE-7689
> Project: Ignite
>  Issue Type: Test
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>




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

[jira] [Created] (IGNITE-7688) DDL does not working properly on sql queries.

[Muratcan TUKSAL (JIRA)]

Muratcan TUKSAL created IGNITE-7688:
---

 Summary: DDL does not working properly on sql queries.
 Key: IGNITE-7688
 URL: https://issues.apache.org/jira/browse/IGNITE-7688
 Project: Ignite
  Issue Type: Bug
  Components: 2.3
Affects Versions: 2.3
 Environment: we have 5 node running on Ubuntu 16.04(VM). we donwloaded 
binary dist. from download page. 
Reporter: Muratcan TUKSAL
 Attachments: buggy-config.xml

* start ignite cluster persistent enabled mode (tried on 5 node)
 * activate cluster via ignitevisor
 * Create a table through jdbc 
 * kill all nodes
 * start all nodes again
 * activate cluster via ignitevisor
 * drop that specific table
 * deactivate cluster(doesnt matter via top -deactivate or kill all nodes)
 * activate cluster
 * dropped table still there with no data



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

[jira] [Assigned] (IGNITE-603) [Test] GridP2PMissedResourceCacheSizeSelfTest has commented tests

[Alexander Menshikov (JIRA)]

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

Alexander Menshikov reassigned IGNITE-603:
--

Assignee: (was: Alexander Menshikov)

> [Test] GridP2PMissedResourceCacheSizeSelfTest has commented tests
> -
>
> Key: IGNITE-603
> URL: https://issues.apache.org/jira/browse/IGNITE-603
> Project: Ignite
>  Issue Type: Bug
>Reporter: Artem Shutak
>Priority: Major
>  Labels: Muted_test
> Attachments: testSize2ContinuousMode.txt, testSize2IsolatedMode.txt, 
> testSize2PrivateMode.txt, testSize2SharedMode.txt
>
>
> Test have to be uncommented and fixed or the commented code have to be 
> removed.
> See comments at GG-3804.
> Update at 2/3/17.
> API has changed. So if we add initialization of "ignite" field to 
> GridP2PEventFilterExternalPath1 and GridP2PEventFilterExternalPath2 and 
> uncomments tests you can get result like in attached file.
> testSize2IsolatedMode and testSize2PrivateMode tests don't fail.



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

[jira] [Assigned] (IGNITE-4501) Improvement of connection in a cluster of new node

[Alexander Menshikov (JIRA)]

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

Alexander Menshikov reassigned IGNITE-4501:
---

Assignee: (was: Alexander Menshikov)

> Improvement of connection in a cluster of new node
> --
>
> Key: IGNITE-4501
> URL: https://issues.apache.org/jira/browse/IGNITE-4501
> Project: Ignite
>  Issue Type: Improvement
>  Components: messaging
>Affects Versions: 1.8
>Reporter: Vyacheslav Daradur
>Priority: Major
>  Labels: important
>
> h3. Main description:
> Cluster nodes connect a ring.
> For example: we have 6 nodes: A, B, C, D, E, F. 
> They can connect a ring in any possible way: A-B-C-D-E-F-A, or A-F-B-E-C-D-A, 
> etc.
> If some node leaves topology, adjacent nodes must reconnect. 
> If nodes A, B, C are in same physical place, nodes D, E, F are in other 
> place, and places lost connect each other, we will have many ways of 
> reconnections.
> At best case, if we had a ring: A-B-CxD-E-FxA ('x' means disconnect) -- then 
> we have only one reconnect (C
> will be connected to A or F will be connected to D -- depends on what part of 
> the cluster was alive.
> Also, if we had a not ring: AxFxBxExCxDxA -- then we have a lot of 
> reconnections (A to B, B to C, C to A -- in general n/2 reconnections, where 
> n -- number of nodes). 
> h3. Approach:
> It is necessary to develop approach of node insertion to the correct place 
> for creation of the correct ring-topology.
> h3. Solutions:
> Main idea is a sorting according to latency.
> * group nodes in arcs on an ARC_ID. (manualy?)
> * implement NodeComparator (nodes on the same host : nodes on the same subnet 
> : other nodes). We will use it when we connect a new node.
> * [dev list 
> thread|http://mail-archives.apache.org/mod_mbox/ignite-dev/201612.mbox/%3CCAN+WSNyWYXSXEBpGErVt72zTgi2pTQzUWLv8JY=ke83-5-r...@mail.gmail.com%3E]
> Update Dec, 29 Yakov Zhdanov:
> # introduce CLUSTER_REGION_ID node attribute. This can be done by adding 
> public static final constant to TcpDiscoverySpi.
> # Alter 
> org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing#nextNode(java.util.Collection)
>  to order basing on per node attribute value
> # Node comparison should be stable and consistent. E.g. if CLUSTER_REGION_IDs 
> are equal then we should compare nodes' IDs. This way we have consistent 
> order on all nodes in topology.
> # Also nextNode() has to group nodes on same host and in same subnet. This 
> can be postponed and implemented after we have other points done.



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

[jira] [Assigned] (IGNITE-4365) Data grid in deadlock on stop

[Alexander Menshikov (JIRA)]

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

Alexander Menshikov reassigned IGNITE-4365:
---

Assignee: (was: Alexander Menshikov)

> Data grid in deadlock on stop
> -
>
> Key: IGNITE-4365
> URL: https://issues.apache.org/jira/browse/IGNITE-4365
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Yakov Zhdanov
>Priority: Major
>  Labels: busylock, gateway, performance
> Attachments: thread-dump.txt
>
>
> Attached is the threaddump describing the problem.
> # several public threads wait for new cache topology version
> # onExchangeFinish() tries to stop the gateway, but cannot do it due to 
> public threads waiting inside the GW.
> # grid stopping thread waits for job requests to complete



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

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

[Alexander Menshikov (JIRA)]

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

Alexander Menshikov commented on IGNITE-1948:
-

I guess some one else can try to fix it in future.

> 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
>Priority: Major
>
> 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
(v7.6.3#76005)

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

[Alexander Menshikov (JIRA)]

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

Alexander Menshikov reassigned IGNITE-1948:
---

Assignee: (was: Alexander Menshikov)

> 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
>Priority: Major
>
> 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
(v7.6.3#76005)

[jira] [Created] (IGNITE-7687) SQL SELECT doesn't update TTL for Touched/AccessedExpiryPolicy

[Stanislav Lukyanov (JIRA)]

Stanislav Lukyanov created IGNITE-7687:
--

 Summary: SQL SELECT doesn't update TTL for 
Touched/AccessedExpiryPolicy
 Key: IGNITE-7687
 URL: https://issues.apache.org/jira/browse/IGNITE-7687
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.5
Reporter: Stanislav Lukyanov


SQL SELECT queries don't update TTLs when TouchedExpiryPolicy or 
AccessedExpiryPolicy is used (unlike IgniteCache::get which does update the 
TTLs).

Example (modified SqlDmlExample):

CacheConfiguration orgCacheCfg = new 
CacheConfiguration(ORG_CACHE)
.setIndexedTypes(Long.class, Organization.class)
.setExpiryPolicyFactory(TouchedExpiryPolicy.factoryOf(new 
Duration(TimeUnit.SECONDS, 10)));

IgniteCache orgCache = 
ignite.getOrCreateCache(orgCacheCfg);

SqlFieldsQuery qry = new SqlFieldsQuery("insert into Organization (_key, 
id, name) values (?, ?, ?)");
orgCache.query(qry.setArgs(1L, 1L, "ASF"));
orgCache.query(qry.setArgs(2L, 2L, "Eclipse"));

SqlFieldsQuery qry1 = new SqlFieldsQuery("select id, name from Organization 
as o");
for (int i = 0; ;i++) {
List res = orgCache.query(qry1).getAll();
print("i = " + i);
for (Object next : res)
System.out.println(">>> " + next);
U.sleep(5000);
}

Output:
>>> i = 0
>>> [1, ASF]
>>> [2, Eclipse]

>>> i = 1
>>> [1, ASF]
>>> [2, Eclipse]

>>> i = 2

>>> i = 3
...



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

[jira] [Commented] (IGNITE-7682) C++: LocalSize cache functions

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-7682:
-

[~Roman_BRR], what about Java API? Does it behave the same?

> C++: LocalSize cache functions
> --
>
> Key: IGNITE-7682
> URL: https://issues.apache.org/jira/browse/IGNITE-7682
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
> Environment: Ignite builded by jdk1.8.0_152 with sources 
> tag:ignite-2.3
> cpp libs builded by Microsoft Visual Studio Enterprise 2015 Version 
> 14.0.25431.01 Update 3
> all x64
>Reporter: Roman Bastanov
>Priority: Major
>
> LocalSize functions with all variations of CachePeekMode returns same results.
> They always returns all cache size, the sum of all node caches.
> {code}
> auto cache = IgniteNode.GetCache<...>(cache_name);
> cache.LocalSize(ignite::cache::CachePeekMode::BACKUP)
> cache.LocalSize(ignite::cache::CachePeekMode::NEAR_CACHE)
> cache.LocalSize(ignite::cache::CachePeekMode::OFFHEAP)
> cache.LocalSize(ignite::cache::CachePeekMode::ONHEAP)
> cache.LocalSize(ignite::cache::CachePeekMode::PRIMARY)
> cache.LocalSize(ignite::cache::CachePeekMode::SWAP)
> {code}
> Despite this, manually calculations are correct, and returns local size(cache 
> on this node).
> {code}
> auto query = cache::query::ScanQuery();
> query.SetLocal(true);
> auto cursor = cache.Query(query);
> while (cursor.HasNext()) {
> cache_size++;
> }{code}



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

[jira] [Commented] (IGNITE-7653) Merge test suites into SQL tests or delete

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7653:


Probably we need also remove IgniteTests24Java8_IgniteIgfsExamples. Suite is 
failed with no examples,
{noformat}
AssertionFailedError: No tests found in 
org.apache.ignite.examples.IgfsExamplesSelfTest
{noformat}

but this suite seems to be included into Examples suite.

Probably need additional approve from [~vozerov]


> Merge test suites into SQL tests or delete
> --
>
> Key: IGNITE-7653
> URL: https://issues.apache.org/jira/browse/IGNITE-7653
> Project: Ignite
>  Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Peter Ivanov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> JSR-310 Java 8 Date and Time API Queries & Ignite Spring3
> does not execute any tests



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

[jira] [Commented] (IGNITE-5804) ScanQuery transformer applies to first results page only.

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-5804:


Hi [~slava.koptilin], I've found everal suspicious tests, which never failed in 
master but failed in PR:

Could you check if they are related to current PR changes
{noformat}
   Ignite Cache 4 [ tests 3 ] 
 org.apache.ignite.testsuites.IgniteCacheTestSuite4: 
org.apache.ignite.internal.processors.cache.CacheGetEntryPessimisticReadCommittedSeltTest.testReplicatedTransactional
 (fail rate 0%) 
 org.apache.ignite.testsuites.IgniteCacheTestSuite4: 
org.apache.ignite.internal.processors.cache.CacheGetEntryPessimisticRepeatableReadSeltTest.testNearTransactional
 (fail rate 0%) 
 org.apache.ignite.testsuites.IgniteCacheTestSuite4: 
org.apache.ignite.internal.processors.cache.CacheGetEntryPessimisticRepeatableReadSeltTest.testReplicatedTransactional
 (fail rate 0%)

   Ignite Cache 2 [ tests 2 ] 
 org.apache.ignite.testsuites.IgniteCacheTestSuite2: 
org.apache.ignite.internal.processors.cache.distributed.near.GridCachePartitionedTxSingleThreadedSelfTest.testOptimisticReadCommittedCommit
 (fail rate 0%) 
 org.apache.ignite.testsuites.IgniteCacheTestSuite2: 
org.apache.ignite.internal.processors.cache.distributed.near.GridCachePartitionedTxSingleThreadedSelfTest.testOptimisticRepeatableReadRollback
 (fail rate 0%) 

 
   Ignite Cache Tx Recovery [ tests 1 ]  
 org.apache.ignite.testsuites.IgniteCacheTxRecoverySelfTestSuite: 
org.apache.ignite.internal.processors.cache.distributed.dht.TxRecoveryStoreEnabledTest.testPessimistic
 (fail rate 0%) 
{noformat}

> ScanQuery transformer applies to first results page only.
> -
>
> Key: IGNITE-5804
> URL: https://issues.apache.org/jira/browse/IGNITE-5804
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.9
>Reporter: Andrew Mashenkov
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.5
>
>
> Issue is successfully reproduces on GridCacheQueryTransformerSelfTest if 
> set ScanQuery.pageSize much lower then cache size.
> We should rework GridCacheQueryTransformerSelfTest to run test on larger 
> dataset 
> to make pagination used as well.
> http://apache-ignite-users.70518.x6.nabble.com/Transformer-not-called-on-every-ScanQuery-td15171.html



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

[jira] [Commented] (IGNITE-7684) Ignore IGNITE_USE_ASYNC_FILE_IO_FACTORY in FileWriteAheadLogManager

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7684:


It seems it was already fixed for master. WAL ignores factory now.

> Ignore IGNITE_USE_ASYNC_FILE_IO_FACTORY in FileWriteAheadLogManager
> ---
>
> Key: IGNITE-7684
> URL: https://issues.apache.org/jira/browse/IGNITE-7684
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.4
>Reporter: Alexander Belyak
>Priority: Major
>
> If IGNITE_USE_ASYNC_FILE_IO_FACTORY specified and no IGNITE_WAL_MMAP we get:
> {noformat}
> java.lang.UnsupportedOperationException: AsynchronousFileChannel doesn't 
> support mmap. 
> at 
> org.apache.ignite.internal.processors.cache.persistence.file.AsyncFileIO.map(AsyncFileIO.java:173)
>  
> at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.restoreWriteHandle(FileWriteAheadLogManager.java:1068)
>  
> at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.resumeLogging(FileWriteAheadLogManager.java:552)
> at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readCheckpointAndRestoreMemory(GridCacheDatabaseSharedManager.java:714)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest(GridDhtPartitionsExchangeFuture.java:841)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:595)
> at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2329)
> at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) 
> at java.lang.Thread.run(Thread.java:748)
> {noformat}



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

[jira] [Updated] (IGNITE-7686) PDS Direct IO failure: IgnitePdsEvictionTest.testPageEviction

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-7686:
---
Description: 
java.util.concurrent.TimeoutException: Test has been timed out 
[test=testPageEviction, timeout=30] 

Reproduced only on TC agent

https://ci.ignite.apache.org/viewLog.html?buildId=1090347=buildResultsDiv=IgniteTests24Java8_IgnitePds1DirectIo#testNameId3144891032708936796

  was:
java.util.concurrent.TimeoutException: Test has been timed out 
[test=testPageEviction, timeout=30] 

Reproduced only on TC agent


> PDS Direct IO failure: IgnitePdsEvictionTest.testPageEviction 
> --
>
> Key: IGNITE-7686
> URL: https://issues.apache.org/jira/browse/IGNITE-7686
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> java.util.concurrent.TimeoutException: Test has been timed out 
> [test=testPageEviction, timeout=30] 
> Reproduced only on TC agent
> https://ci.ignite.apache.org/viewLog.html?buildId=1090347=buildResultsDiv=IgniteTests24Java8_IgnitePds1DirectIo#testNameId3144891032708936796



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

[jira] [Updated] (IGNITE-7686) PDS Direct IO failure: IgnitePdsEvictionTest.testPageEviction

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-7686:
---
Summary: PDS Direct IO failure: IgnitePdsEvictionTest.testPageEviction   
(was: PDS Direct IO failue: IgnitePdsEvictionTest.testPageEviction )

> PDS Direct IO failure: IgnitePdsEvictionTest.testPageEviction 
> --
>
> Key: IGNITE-7686
> URL: https://issues.apache.org/jira/browse/IGNITE-7686
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> java.util.concurrent.TimeoutException: Test has been timed out 
> [test=testPageEviction, timeout=30] 
> Reproduced only on TC agent



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

[jira] [Commented] (IGNITE-7652) ContinuousQueryWithTransformer example

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov commented on IGNITE-7652:
-

[~dmagda] Can you, please, review my changes created in this ticket?
It a relatively small(100 loc) example of usage of new CQWT API.



> ContinuousQueryWithTransformer example
> --
>
> Key: IGNITE-7652
> URL: https://issues.apache.org/jira/browse/IGNITE-7652
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.5
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Fix For: 2.5
>
>
> Need to create example for a ContinuousQueryWithTransformer.



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

[jira] [Comment Edited] (IGNITE-7652) ContinuousQueryWithTransformer example

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov edited comment on IGNITE-7652 at 2/13/18 1:07 PM:
--

[~dmagda] Can you, please, review my changes created in this ticket?
It a relatively small(100 loc) example of usage of new CQWT API.

TC looks good - 
https://ci.ignite.apache.org/viewLog.html?buildId=1089937=queuedBuildOverviewTab


was (Author: nizhikov):
[~dmagda] Can you, please, review my changes created in this ticket?
It a relatively small(100 loc) example of usage of new CQWT API.



> ContinuousQueryWithTransformer example
> --
>
> Key: IGNITE-7652
> URL: https://issues.apache.org/jira/browse/IGNITE-7652
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.5
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Fix For: 2.5
>
>
> Need to create example for a ContinuousQueryWithTransformer.



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

[jira] [Created] (IGNITE-7686) PDS Direct IO failue: IgnitePdsEvictionTest.testPageEviction

[Dmitriy Pavlov (JIRA)]

Dmitriy Pavlov created IGNITE-7686:
--

 Summary: PDS Direct IO failue: 
IgnitePdsEvictionTest.testPageEviction 
 Key: IGNITE-7686
 URL: https://issues.apache.org/jira/browse/IGNITE-7686
 Project: Ignite
  Issue Type: Bug
  Components: persistence
Reporter: Dmitriy Pavlov
Assignee: Dmitriy Pavlov
 Fix For: 2.5


java.util.concurrent.TimeoutException: Test has been timed out 
[test=testPageEviction, timeout=30] 

Reproduced only on TC agent



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

[jira] [Commented] (IGNITE-7513) Get rid of org.jsr166.ConcurrentHashMap8

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-7513:
--

[~andrey-kuznetsov], 
I'll check is there any performance prop using our bench lab and let you know 
about results.

> Get rid of org.jsr166.ConcurrentHashMap8
> 
>
> Key: IGNITE-7513
> URL: https://issues.apache.org/jira/browse/IGNITE-7513
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Major
> Fix For: 2.5
>
>
> This class was made of ConcurrentHashMapV8, an intermediate implementation of 
> Java8's ConcurrentHashMap. Now we should switch to standard CHM. Possibly, 
> we'll have to check for performance implications.



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

[jira] [Comment Edited] (IGNITE-7513) Get rid of org.jsr166.ConcurrentHashMap8

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov edited comment on IGNITE-7513 at 2/13/18 12:22 PM:


[~andrey-kuznetsov], 
I'll check is there any performance drop using our bench lab and let you know 
about results.


was (Author: avinogradov):
[~andrey-kuznetsov], 
I'll check is there any performance prop using our bench lab and let you know 
about results.

> Get rid of org.jsr166.ConcurrentHashMap8
> 
>
> Key: IGNITE-7513
> URL: https://issues.apache.org/jira/browse/IGNITE-7513
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Major
> Fix For: 2.5
>
>
> This class was made of ConcurrentHashMapV8, an intermediate implementation of 
> Java8's ConcurrentHashMap. Now we should switch to standard CHM. Possibly, 
> we'll have to check for performance implications.



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

[jira] [Created] (IGNITE-7685) Incorrect AllocationRate counting

[Anton Vinogradov (JIRA)]

Anton Vinogradov created IGNITE-7685:


 Summary: Incorrect AllocationRate counting
 Key: IGNITE-7685
 URL: https://issues.apache.org/jira/browse/IGNITE-7685
 Project: Ignite
  Issue Type: Task
Reporter: Anton Vinogradov
Assignee: Andrey Kuznetsov


Each call of 
{{org.apache.ignite.internal.processors.cache.persistence.DataRegionMetricsImpl#updateTotalAllocatedPages}}
 performs {{allocRate.onHit()}} call which is not correct since delta can be 
negative or bigger that 1.

Need to fix allocationRate counting



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

[jira] [Updated] (IGNITE-7685) Incorrect AllocationRate counting

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov updated IGNITE-7685:
-
Fix Version/s: 2.5

> Incorrect AllocationRate counting
> -
>
> Key: IGNITE-7685
> URL: https://issues.apache.org/jira/browse/IGNITE-7685
> Project: Ignite
>  Issue Type: Task
>Affects Versions: 2.4
>Reporter: Anton Vinogradov
>Assignee: Andrey Kuznetsov
>Priority: Major
> Fix For: 2.5
>
>
> Each call of 
> {{org.apache.ignite.internal.processors.cache.persistence.DataRegionMetricsImpl#updateTotalAllocatedPages}}
>  performs {{allocRate.onHit()}} call which is not correct since delta can be 
> negative or bigger that 1.
> Need to fix allocationRate counting



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

[jira] [Updated] (IGNITE-7685) Incorrect AllocationRate counting

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov updated IGNITE-7685:
-
Affects Version/s: 2.4

> Incorrect AllocationRate counting
> -
>
> Key: IGNITE-7685
> URL: https://issues.apache.org/jira/browse/IGNITE-7685
> Project: Ignite
>  Issue Type: Task
>Affects Versions: 2.4
>Reporter: Anton Vinogradov
>Assignee: Andrey Kuznetsov
>Priority: Major
> Fix For: 2.5
>
>
> Each call of 
> {{org.apache.ignite.internal.processors.cache.persistence.DataRegionMetricsImpl#updateTotalAllocatedPages}}
>  performs {{allocRate.onHit()}} call which is not correct since delta can be 
> negative or bigger that 1.
> Need to fix allocationRate counting



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

[jira] [Created] (IGNITE-7684) Ignore IGNITE_USE_ASYNC_FILE_IO_FACTORY in FileWriteAheadLogManager

[Alexander Belyak (JIRA)]

Alexander Belyak created IGNITE-7684:


 Summary: Ignore IGNITE_USE_ASYNC_FILE_IO_FACTORY in 
FileWriteAheadLogManager
 Key: IGNITE-7684
 URL: https://issues.apache.org/jira/browse/IGNITE-7684
 Project: Ignite
  Issue Type: Improvement
  Components: general
Affects Versions: 2.4
Reporter: Alexander Belyak


If IGNITE_USE_ASYNC_FILE_IO_FACTORY specified and no IGNITE_WAL_MMAP we get:

{noformat}

java.lang.UnsupportedOperationException: AsynchronousFileChannel doesn't 
support mmap. 
at 
org.apache.ignite.internal.processors.cache.persistence.file.AsyncFileIO.map(AsyncFileIO.java:173)
 
at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.restoreWriteHandle(FileWriteAheadLogManager.java:1068)
 

at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.resumeLogging(FileWriteAheadLogManager.java:552)

at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readCheckpointAndRestoreMemory(GridCacheDatabaseSharedManager.java:714)

at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest(GridDhtPartitionsExchangeFuture.java:841)

at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:595)

at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2329)

at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) 
at java.lang.Thread.run(Thread.java:748)

{noformat}



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

[jira] [Comment Edited] (IGNITE-3111) .NET: Configure SSL without Spring

[Alexey Popov (JIRA)]

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

Alexey Popov edited comment on IGNITE-3111 at 2/13/18 10:54 AM:


[~isapego] , fixed. Now we have only ISslContextFactory interface

https://reviews.ignite.apache.org/ignite/review/IGNT-CR-489


was (Author: alexey.tank2):
[~isapego] , fixed. Now we have only ISslContextFactory interface

> .NET: Configure SSL without Spring
> --
>
> Key: IGNITE-3111
> URL: https://issues.apache.org/jira/browse/IGNITE-3111
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Pavel Tupitsyn
>Assignee: Alexey Popov
>Priority: Major
>  Labels: .net
> Fix For: 2.5
>
>
> User should be able to configure SLL in .NET terms without Spring and Java 
> KeyStore.
> See https://apacheignite.readme.io/docs/ssltls.



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

[jira] [Commented] (IGNITE-5265) Eviction Rate memory metric to be implemented

[Ivan Rakov (JIRA)]

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

Ivan Rakov commented on IGNITE-5265:


[~alex_pl], I've looked through your pull request.
Changes look good, please merge.

> Eviction Rate memory metric to be implemented
> -
>
> Key: IGNITE-5265
> URL: https://issues.apache.org/jira/browse/IGNITE-5265
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Reporter: Sergey Chugunov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Fix For: 2.5
>
>
> Eviction rate metric is declared on *MemoryMetrics* interface but isn't 
> implemented in *MemoryMetricsImpl* (current implementation returns 0 right 
> away).
> This metric must be implemented identically to *allocationRate* metric from 
> the same interface (algorithm for *allocationRate* can be reused with minor 
> refactoring).



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

[jira] [Commented] (IGNITE-3111) .NET: Configure SSL without Spring

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-3111:


Github user asfgit closed the pull request at:

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


> .NET: Configure SSL without Spring
> --
>
> Key: IGNITE-3111
> URL: https://issues.apache.org/jira/browse/IGNITE-3111
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Pavel Tupitsyn
>Assignee: Alexey Popov
>Priority: Major
>  Labels: .net
> Fix For: 2.5
>
>
> User should be able to configure SLL in .NET terms without Spring and Java 
> KeyStore.
> See https://apacheignite.readme.io/docs/ssltls.



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

[jira] [Commented] (IGNITE-3111) .NET: Configure SSL without Spring

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-3111:
-

Everything looks good to me. 

> .NET: Configure SSL without Spring
> --
>
> Key: IGNITE-3111
> URL: https://issues.apache.org/jira/browse/IGNITE-3111
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Pavel Tupitsyn
>Assignee: Alexey Popov
>Priority: Major
>  Labels: .net
> Fix For: 2.5
>
>
> User should be able to configure SLL in .NET terms without Spring and Java 
> KeyStore.
> See https://apacheignite.readme.io/docs/ssltls.



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

[jira] [Commented] (IGNITE-7652) ContinuousQueryWithTransformer example

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov commented on IGNITE-7652:
-

I keep this ticket for an CQWT example.
IGNITE-7683 is for documentation.

> ContinuousQueryWithTransformer example
> --
>
> Key: IGNITE-7652
> URL: https://issues.apache.org/jira/browse/IGNITE-7652
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.5
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Fix For: 2.5
>
>
> Need to create example for a ContinuousQueryWithTransformer.



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