date:20160523

[jira] [Commented] (IGNITE-3183) ScanQuery and localEntries are ignored keepBinary flag in OFFHEAP_TIERED mode

2016-05-23 Thread Denis Magda (JIRA)


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

Denis Magda commented on IGNITE-3183:
-

The issue is only related to keys. Everything works fine for values. If not to 
use custom objects as the keys then the tests would pass.

> ScanQuery and localEntries are ignored keepBinary flag in OFFHEAP_TIERED mode
> -
>
> Key: IGNITE-3183
> URL: https://issues.apache.org/jira/browse/IGNITE-3183
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, important
>Affects Versions: 1.6
>Reporter: Nikolay Tikhonov
>Assignee: Anton Vinogradov
> Attachments: CacheKeepBinaryIterationTest.java
>
>
> {{ScanQuery}} and {{localEntries}} method returns iterator which contains 
> deserialized entries but they have been called with withKeepBinary flag. 
> Reproducible test attached.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IGNITE-3183) ScanQuery and localEntries are ignored keepBinary flag in OFFHEAP_TIERED mode

2016-05-23 Thread Denis Magda (JIRA)


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

Denis Magda updated IGNITE-3183:

Assignee: Anton Vinogradov

> ScanQuery and localEntries are ignored keepBinary flag in OFFHEAP_TIERED mode
> -
>
> Key: IGNITE-3183
> URL: https://issues.apache.org/jira/browse/IGNITE-3183
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, important
>Affects Versions: 1.6
>Reporter: Nikolay Tikhonov
>Assignee: Anton Vinogradov
> Attachments: CacheKeepBinaryIterationTest.java
>
>
> {{ScanQuery}} and {{localEntries}} method returns iterator which contains 
> deserialized entries but they have been called with withKeepBinary flag. 
> Reproducible test attached.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-2969) Optimistic transactions support in deadlock detection

2016-05-23 Thread Andrey Gura (JIRA)


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

Andrey Gura commented on IGNITE-2969:
-

I was wrong about {{checkValid}} method behavior. Actually this checking is 
redundant for cases when transaction on finish stage with {{COMMITING}} state 
and on prepare stage with {{PREPARING}} state. I fixed this behavior and no 
more unfinished transactions during tests. Waiting for TC results.

> Optimistic transactions support in deadlock detection
> -
>
> Key: IGNITE-2969
> URL: https://issues.apache.org/jira/browse/IGNITE-2969
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Reporter: Andrey Gura
>Assignee: Andrey Gura
> Fix For: 1.7
>
>
> Deadlock detection doesn't support optimistic transactions now. It should be 
> implemented.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (IGNITE-2620) Extra 'entry expired' events

2016-05-23 Thread Semen Boikov (JIRA)


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

Semen Boikov closed IGNITE-2620.


> Extra 'entry expired' events
> 
>
> Key: IGNITE-2620
> URL: https://issues.apache.org/jira/browse/IGNITE-2620
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Semen Boikov
>
> Added test reproducing issue: IgniteCacheEntryListenerExpiredEventsTest (more 
> then 1 event can be fired for single entry expiration).
> Very suspicious place is GridCacheMapEntry.onTtlExpired: even when entry is 
> obsolete it calls 'clearIndex' and 'releaseSwap' (these calls should be 
> prohibited for obsolete entry).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-2899) BinaryObject is deserialized before getting passed to CacheInterceptor

2016-05-23 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on IGNITE-2899:


Github user asfgit closed the pull request at:

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


> BinaryObject is deserialized before getting passed to CacheInterceptor
> --
>
> Key: IGNITE-2899
> URL: https://issues.apache.org/jira/browse/IGNITE-2899
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
> Fix For: 1.7
>
> Attachments: BinaryInterceptorIssue.java, 
> BinaryInterceptorNoTypeIssue.java
>
>
> If {{CacheInterceptor}} is configured for a cache that stores 
> {{BinaryObjects}} then the objects are always deserialized before being 
> passed to the interceptor body.
> Refer to BinaryInterceptorIssue test attached to the ticket to reproduce the 
> following stack trace
> {noformat}
> java.lang.ClassCastException: 
> org.apache.ignite.examples.tests.BinaryInterceptorIssue$ValidObject cannot be 
> cast to org.apache.ignite.binary.BinaryObject
>   at 
> org.apache.ignite.examples.tests.BinaryInterceptorIssue$ValidationInterceptor.onBeforePut(BinaryInterceptorIssue.java:49)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2309)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2044)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1439)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1314)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.mapSingle(GridNearAtomicUpdateFuture.java:457)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.access$1400(GridNearAtomicUpdateFuture.java:72)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture$UpdateState.map(GridNearAtomicUpdateFuture.java:931)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.mapOnTopology(GridNearAtomicUpdateFuture.java:417)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.map(GridNearAtomicUpdateFuture.java:283)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$21.apply(GridDhtAtomicCache.java:1006)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$21.apply(GridDhtAtomicCache.java:1004)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.asyncOp(GridDhtAtomicCache.java:737)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsync0(GridDhtAtomicCache.java:1004)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.putAsync0(GridDhtAtomicCache.java:465)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.putAsync(GridCacheAdapter.java:2491)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put(GridDhtAtomicCache.java:440)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2170)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.put(IgniteCacheProxy.java:1127)
>   at 
> org.apache.ignite.examples.tests.BinaryInterceptorIssue.main(BinaryInterceptorIssue.java:37)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
> Exception in thread "main" 
> org.apache.ignite.cache.CachePartialUpdateException: Failed to update keys 
> (retry update if possible).: [1]
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1577)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.cacheException(IgniteCacheProxy.java:1931)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.put(IgniteCacheProxy.java:1134)
>   at 
>

[jira] [Closed] (IGNITE-2899) BinaryObject is deserialized before getting passed to CacheInterceptor

2016-05-23 Thread Semen Boikov (JIRA)


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

Semen Boikov closed IGNITE-2899.


> BinaryObject is deserialized before getting passed to CacheInterceptor
> --
>
> Key: IGNITE-2899
> URL: https://issues.apache.org/jira/browse/IGNITE-2899
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
> Fix For: 1.7
>
> Attachments: BinaryInterceptorIssue.java, 
> BinaryInterceptorNoTypeIssue.java
>
>
> If {{CacheInterceptor}} is configured for a cache that stores 
> {{BinaryObjects}} then the objects are always deserialized before being 
> passed to the interceptor body.
> Refer to BinaryInterceptorIssue test attached to the ticket to reproduce the 
> following stack trace
> {noformat}
> java.lang.ClassCastException: 
> org.apache.ignite.examples.tests.BinaryInterceptorIssue$ValidObject cannot be 
> cast to org.apache.ignite.binary.BinaryObject
>   at 
> org.apache.ignite.examples.tests.BinaryInterceptorIssue$ValidationInterceptor.onBeforePut(BinaryInterceptorIssue.java:49)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2309)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2044)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1439)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1314)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.mapSingle(GridNearAtomicUpdateFuture.java:457)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.access$1400(GridNearAtomicUpdateFuture.java:72)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture$UpdateState.map(GridNearAtomicUpdateFuture.java:931)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.mapOnTopology(GridNearAtomicUpdateFuture.java:417)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.map(GridNearAtomicUpdateFuture.java:283)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$21.apply(GridDhtAtomicCache.java:1006)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$21.apply(GridDhtAtomicCache.java:1004)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.asyncOp(GridDhtAtomicCache.java:737)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsync0(GridDhtAtomicCache.java:1004)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.putAsync0(GridDhtAtomicCache.java:465)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.putAsync(GridCacheAdapter.java:2491)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put(GridDhtAtomicCache.java:440)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2170)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.put(IgniteCacheProxy.java:1127)
>   at 
> org.apache.ignite.examples.tests.BinaryInterceptorIssue.main(BinaryInterceptorIssue.java:37)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
> Exception in thread "main" 
> org.apache.ignite.cache.CachePartialUpdateException: Failed to update keys 
> (retry update if possible).: [1]
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1577)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.cacheException(IgniteCacheProxy.java:1931)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.put(IgniteCacheProxy.java:1134)
>   at 
> org.apache.ignite.examples.tests.BinaryInterceptorIssue.main(BinaryInterceptorIssue.java:37)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
>

[jira] [Resolved] (IGNITE-2899) BinaryObject is deserialized before getting passed to CacheInterceptor

2016-05-23 Thread Semen Boikov (JIRA)


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

Semen Boikov resolved IGNITE-2899.
--
Resolution: Fixed
  Assignee: (was: Artem Shutak)

Merged fixes into master (commit ee7e2c7).

> BinaryObject is deserialized before getting passed to CacheInterceptor
> --
>
> Key: IGNITE-2899
> URL: https://issues.apache.org/jira/browse/IGNITE-2899
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
> Fix For: 1.7
>
> Attachments: BinaryInterceptorIssue.java, 
> BinaryInterceptorNoTypeIssue.java
>
>
> If {{CacheInterceptor}} is configured for a cache that stores 
> {{BinaryObjects}} then the objects are always deserialized before being 
> passed to the interceptor body.
> Refer to BinaryInterceptorIssue test attached to the ticket to reproduce the 
> following stack trace
> {noformat}
> java.lang.ClassCastException: 
> org.apache.ignite.examples.tests.BinaryInterceptorIssue$ValidObject cannot be 
> cast to org.apache.ignite.binary.BinaryObject
>   at 
> org.apache.ignite.examples.tests.BinaryInterceptorIssue$ValidationInterceptor.onBeforePut(BinaryInterceptorIssue.java:49)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2309)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2044)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1439)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1314)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.mapSingle(GridNearAtomicUpdateFuture.java:457)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.access$1400(GridNearAtomicUpdateFuture.java:72)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture$UpdateState.map(GridNearAtomicUpdateFuture.java:931)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.mapOnTopology(GridNearAtomicUpdateFuture.java:417)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.map(GridNearAtomicUpdateFuture.java:283)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$21.apply(GridDhtAtomicCache.java:1006)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$21.apply(GridDhtAtomicCache.java:1004)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.asyncOp(GridDhtAtomicCache.java:737)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsync0(GridDhtAtomicCache.java:1004)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.putAsync0(GridDhtAtomicCache.java:465)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.putAsync(GridCacheAdapter.java:2491)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put(GridDhtAtomicCache.java:440)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2170)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.put(IgniteCacheProxy.java:1127)
>   at 
> org.apache.ignite.examples.tests.BinaryInterceptorIssue.main(BinaryInterceptorIssue.java:37)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
> Exception in thread "main" 
> org.apache.ignite.cache.CachePartialUpdateException: Failed to update keys 
> (retry update if possible).: [1]
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1577)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.cacheException(IgniteCacheProxy.java:1931)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.put(IgniteCacheProxy.java:1134)
>   at 
>

[jira] [Commented] (IGNITE-3182) Compute jobs execute on client nodes

2016-05-23 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on IGNITE-3182:


GitHub user ptupitsyn opened a pull request:

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

IGNITE-3182 Compute jobs execute on client nodes



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

$ git pull https://github.com/ptupitsyn/ignite ignite-3182

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

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


commit 25ae4aa997e2dc68f16b1cf236ce7c8d5939f87f
Author: Pavel Tupitsyn 
Date:   2016-05-23T15:14:43Z

IGNITE-3182 Compute jobs execute on client nodes

commit add05af2e33cf48d7e5963ef9643f011bcd155e6
Author: Pavel Tupitsyn 
Date:   2016-05-23T15:21:15Z

wip

commit 349c6f102bcb51aee1714077120142b326f5f87b
Author: Pavel Tupitsyn 
Date:   2016-05-23T15:26:28Z

Refactor default prj check




> Compute jobs execute on client nodes
> 
>
> Key: IGNITE-3182
> URL: https://issues.apache.org/jira/browse/IGNITE-3182
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Fix For: 1.7
>
>
> * One server node, one client node, Broadcast from client node results in 
> both nodes executing the closure
> * Need to check the behavior with 2 servers, 2 clients, broadcast from server 
> and client



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IGNITE-3186) [Test] org.apache.ignite.internal.processors.igfs.IgfsProcessorValidationSelfTest#testInvalidEndpointTcpPort fails on master

2016-05-23 Thread Ivan Veselovsky (JIRA)


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

Ivan Veselovsky updated IGNITE-3186:

Attachment: ignite-3186.patch

> [Test] 
> org.apache.ignite.internal.processors.igfs.IgfsProcessorValidationSelfTest#testInvalidEndpointTcpPort
>  fails on master
> 
>
> Key: IGNITE-3186
> URL: https://issues.apache.org/jira/browse/IGNITE-3186
> Project: Ignite
>  Issue Type: Bug
>  Components: IGFS
>Affects Versions: 1.7
>Reporter: Ivan Veselovsky
>Assignee: Vladimir Ozerov
> Fix For: 1.7
>
> Attachments: ignite-3186.patch
>
>
> There is no such problem in 1.6 release, test only fails on master branch .
> Root cause is that an SPI now does not allow to start one instance more than 
> once.
> Test does 3 checks, but uses one configuration instance for all them. First 
> check passes, than the 2nd attempts to start the node, but unexpected error 
> happens when an already started Spi is attempted to start.
> Caused by: class org.apache.ignite.IgniteCheckedException: SPI has already 
> been started (always create new configuration instance for each starting 
> Ignite instances) [spi=TcpCommunicationSpi 
> [connectGate=org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$ConnectGateway@ceb47b,
>  
> srvLsnr=org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$2@2aaf7a7,
>  locAddr=127.0.0.1, locHost=localhost/127.0.0.1, locPort=45050, 
> locPortRange=100, shmemPort=48100, directBuf=true, directSndBuf=false, 
> idleConnTimeout=3, connTimeout=5000, maxConnTimeout=60, reconCnt=10, 
> sockSndBuf=32768, sockRcvBuf=32768, msgQueueLimit=1024, 
> slowClientQueueLimit=0, nioSrvr=null, shmemSrv=IpcSharedMemoryServerEndpoint 
> [port=48100, tokDirPath=ipc/shmem, size=262144, 
> tokDir=/mnt/tc_disk/temp/buildTmp/ignite/work/ipc/shmem/10fe89ee-1969-4aab-b91c-bb415b45c001-15910,
>  locNodeId=10fe89ee-1969-4aab-b91c-bb415b45c001, gridName=g1, 
> omitOutOfResourcesWarn=true, pid=15910, closed=true], tcpNoDelay=true, 
> ackSndThreshold=16, unackedMsgsBufSize=0, sockWriteTimeout=2000, lsnr=null, 
> boundTcpPort=-1, boundTcpShmemPort=48100, selectorsCnt=4, addrRslvr=null, 
> rcvdMsgsCnt=0, sentMsgsCnt=0, rcvdBytesCnt=0, sentBytesCnt=0, 
> ctxInitLatch=java.util.concurrent.CountDownLatch@2668f64f[Count = 0], 
> stopping=true, 
> metricsLsnr=org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$3@3502d03c]]
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:956)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1736)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1589)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1042)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:569)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:516)
> at org.apache.ignite.Ignition.start(Ignition.java:322)
> ... 11 more



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-3164) Add an option to send resulting value instead of entry processor in transactional cache

2016-05-23 Thread Andrey Kornev (JIRA)


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

Andrey Kornev commented on IGNITE-3164:
---

How about naming the flag {{withExcludeBackups()}}? This way the current 
behavior will be preserved if the user doesn't specify the flag, thus making 
the change backward compatible.

Having said that, I do not think this is a good approach in general: a flag 
that only affects behavior of a single method - namely Cache.invoke() - is 
applied to the entire IgniteCache interface.

An alternative approach might be as follows (just a suggestion):
- introduce an {{EntryProcessorInvokeOption}} enum with two values: 
{{EXCLUDE_BACKUPS}}, {{INCLUDE_BACKUPS}}.
- allow users to optionally pass the enum as the first element of the 
{{arguments}} parameter of the {{Cache.invoke()}} or {{Cache.invokeAll()}} 
methods.

I believe such approach would achieve the same goal, but without polluting the 
API.

Regards
Andrey

> Add an option to send resulting value instead of entry processor in 
> transactional cache
> ---
>
> Key: IGNITE-3164
> URL: https://issues.apache.org/jira/browse/IGNITE-3164
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Nikolay Tikhonov
>  Labels: important
> Fix For: 1.7
>
>
> In some cases user can't guarantee that EP behaves consistently on all nodes. 
> In transactional cache this can lead to inconsistent cache, because we invoke 
> EP on both primary and backup nodes.
> We can add {{withSendValueToBackup()}} flag (naming is arguable) which will 
> override current default behavior.
> We also need to update documentation, especially provide the explanation of 
> EP behavior in atomic and transactional caches.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-3186) [Test] org.apache.ignite.internal.processors.igfs.IgfsProcessorValidationSelfTest#testInvalidEndpointTcpPort fails on master

2016-05-23 Thread Ivan Veselovsky (JIRA)

Ivan Veselovsky created IGNITE-3186:
---

 Summary: [Test] 
org.apache.ignite.internal.processors.igfs.IgfsProcessorValidationSelfTest#testInvalidEndpointTcpPort
 fails on master
 Key: IGNITE-3186
 URL: https://issues.apache.org/jira/browse/IGNITE-3186
 Project: Ignite
  Issue Type: Bug
  Components: IGFS
Reporter: Ivan Veselovsky
Assignee: Ivan Veselovsky


There is no such problem in 1.6 release, test only fails on master branch .

Root cause is that an SPI now does not allow to start one instance more than 
once.
Test does 3 checks, but uses one configuration instance for all them. First 
check passes, than the 2nd attempts to start the node, but unexpected error 
happens when an already started Spi is attempted to start.

Caused by: class org.apache.ignite.IgniteCheckedException: SPI has already been 
started (always create new configuration instance for each starting Ignite 
instances) [spi=TcpCommunicationSpi 
[connectGate=org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$ConnectGateway@ceb47b,
 srvLsnr=org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$2@2aaf7a7, 
locAddr=127.0.0.1, locHost=localhost/127.0.0.1, locPort=45050, 
locPortRange=100, shmemPort=48100, directBuf=true, directSndBuf=false, 
idleConnTimeout=3, connTimeout=5000, maxConnTimeout=60, reconCnt=10, 
sockSndBuf=32768, sockRcvBuf=32768, msgQueueLimit=1024, slowClientQueueLimit=0, 
nioSrvr=null, shmemSrv=IpcSharedMemoryServerEndpoint [port=48100, 
tokDirPath=ipc/shmem, size=262144, 
tokDir=/mnt/tc_disk/temp/buildTmp/ignite/work/ipc/shmem/10fe89ee-1969-4aab-b91c-bb415b45c001-15910,
 locNodeId=10fe89ee-1969-4aab-b91c-bb415b45c001, gridName=g1, 
omitOutOfResourcesWarn=true, pid=15910, closed=true], tcpNoDelay=true, 
ackSndThreshold=16, unackedMsgsBufSize=0, sockWriteTimeout=2000, lsnr=null, 
boundTcpPort=-1, boundTcpShmemPort=48100, selectorsCnt=4, addrRslvr=null, 
rcvdMsgsCnt=0, sentMsgsCnt=0, rcvdBytesCnt=0, sentBytesCnt=0, 
ctxInitLatch=java.util.concurrent.CountDownLatch@2668f64f[Count = 0], 
stopping=true, 
metricsLsnr=org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$3@3502d03c]]
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:956)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1736)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1589)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1042)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:569)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:516)
at org.apache.ignite.Ignition.start(Ignition.java:322)
... 11 more



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-3185) Hadoop: Improve Hadoop JAR search logic.

2016-05-23 Thread Vladimir Ozerov (JIRA)

Vladimir Ozerov created IGNITE-3185:
---

 Summary: Hadoop: Improve Hadoop JAR search logic.
 Key: IGNITE-3185
 URL: https://issues.apache.org/jira/browse/IGNITE-3185
 Project: Ignite
  Issue Type: Bug
  Components: hadoop
Affects Versions: 1.5.0.final
Reporter: Vladimir Ozerov
Assignee: Ivan Veselovsky
 Fix For: 1.7


*Problem*
Currently our {{HadoopClassLoader}} is trying to find common/hdfs/mapred JARs 
automatically if {{HADOOP_HOME}} is set. However, it checks only for standard 
Apache Hadoop distribution paths (/share/hadoop/*). For other distributions 
(CDH, HDP), user has to bother with additional env variables manually.

*Solution*
Try to search for the following folders as well:
$HADOOP_HOME/hadoop
$HADOOP_HOME/hadoop-hdfs
$HADOOP_HOME/hadoop-mapreduce

If all these folders are found, then this is either HDP or CDH deployment and 
we can create the classpath without additional env vars.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-3184) Hadoop: HADOOP_HOME should not be required if all other environment variables are set.

2016-05-23 Thread Vladimir Ozerov (JIRA)

Vladimir Ozerov created IGNITE-3184:
---

 Summary: Hadoop: HADOOP_HOME should not be required if all other 
environment variables are set.
 Key: IGNITE-3184
 URL: https://issues.apache.org/jira/browse/IGNITE-3184
 Project: Ignite
  Issue Type: Bug
  Components: hadoop
Affects Versions: 1.5.0.final
Reporter: Vladimir Ozerov
Assignee: Ivan Veselovsky
 Fix For: 1.7


*Problem*
Ignite internals require three pieces to create correct Hadoop classpath:
1) Path to common JARs;
2) Path to HDFS JARs;
3) Path map-reduce JARs.

These three paths could be set with environment variables HADOOP_COMMON_HOME, 
HADOOP_HDFS_HOME and HADOOP_MAPRED_HOME respectively. 

When all of them are set, HADOOP_HOME is no longer needed, but we will throw an 
exception in this case. We should not do that.

*Solution*
Throw exception only in case we cannot resolve any of these paths.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (IGNITE-2744) Optimize "unwindEvict" call in GridCacheIoManager.processMessage().

2016-05-23 Thread Semen Boikov (JIRA)


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

Semen Boikov closed IGNITE-2744.

Assignee: (was: Semen Boikov)

> Optimize "unwindEvict" call in GridCacheIoManager.processMessage().
> ---
>
> Key: IGNITE-2744
> URL: https://issues.apache.org/jira/browse/IGNITE-2744
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Priority: Critical
>  Labels: performance
> Fix For: 1.7
>
>
> We call this method on every (!!!) received cache message. This call is 
> pretty heavy as it iterates over all caches. 
> We need to optimize it. E.g., check evicts only for the cache to which 
> received message belongs. And iterate over the whole set only if we know for 
> sure that several caches are affected (e.g. due to cross-cache TX).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-2744) Optimize "unwindEvict" call in GridCacheIoManager.processMessage().

2016-05-23 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on IGNITE-2744:


Github user asfgit closed the pull request at:

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


> Optimize "unwindEvict" call in GridCacheIoManager.processMessage().
> ---
>
> Key: IGNITE-2744
> URL: https://issues.apache.org/jira/browse/IGNITE-2744
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Semen Boikov
>Priority: Critical
>  Labels: performance
> Fix For: 1.7
>
>
> We call this method on every (!!!) received cache message. This call is 
> pretty heavy as it iterates over all caches. 
> We need to optimize it. E.g., check evicts only for the cache to which 
> received message belongs. And iterate over the whole set only if we know for 
> sure that several caches are affected (e.g. due to cross-cache TX).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-1690) [Test] IgniteCacheCreateRestartSelfTest.testStopOriginatingNode sometimes fails.

2016-05-23 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on IGNITE-1690:


GitHub user ilantukh opened a pull request:

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

IGNITE-1690 testing.



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

$ git pull https://github.com/ilantukh/ignite ignite-1690

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

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


commit 6ac70e7ad68e19ab870b00c545da325c4c0fb638
Author: Ilya Lantukh 
Date:   2016-05-23T13:16:24Z

ignite-1690 : Prepared for testing.




> [Test] IgniteCacheCreateRestartSelfTest.testStopOriginatingNode sometimes 
> fails.
> 
>
> Key: IGNITE-1690
> URL: https://issues.apache.org/jira/browse/IGNITE-1690
> Project: Ignite
>  Issue Type: Test
>  Components: cache
>Affects Versions: ignite-1.4
>Reporter: Ivan Veselovsky
>Assignee: Ilya Lantukh
>Priority: Blocker
> Fix For: 1.7
>
>
> IgniteCacheCreateRestartSelfTest.testStopOriginatingNode   sometimes 
> fails (~5% probability) due to  inability to register a cache metrics MBean:
> {noformat}
> org.apache.ignite.IgniteCheckedException: Failed to register MBean for 
> component: 
> org.apache.ignite.internal.processors.cache.CacheMetricsMXBeanImpl@3a5e46b6
> at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
> at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
> at 
> org.apache.ignite.internal.util.IgniteUtils.registerCacheMBean(IgniteUtils.java:4355)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.registerMbean(GridCacheProcessor.java:3267)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.createCache(GridCacheProcessor.java:1526)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:813)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:937)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1617)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1484)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:965)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:526)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:725)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:709)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:686)
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheCreateRestartSelfTest.testStopOriginatingNode(IgniteCacheCreateRestartSelfTest.java:104)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (IGNITE-1690) [Test] IgniteCacheCreateRestartSelfTest.testStopOriginatingNode sometimes fails.

2016-05-23 Thread Ilya Lantukh (JIRA)


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

Ilya Lantukh reassigned IGNITE-1690:


Assignee: Ilya Lantukh

> [Test] IgniteCacheCreateRestartSelfTest.testStopOriginatingNode sometimes 
> fails.
> 
>
> Key: IGNITE-1690
> URL: https://issues.apache.org/jira/browse/IGNITE-1690
> Project: Ignite
>  Issue Type: Test
>  Components: cache
>Affects Versions: ignite-1.4
>Reporter: Ivan Veselovsky
>Assignee: Ilya Lantukh
>Priority: Blocker
> Fix For: 1.7
>
>
> IgniteCacheCreateRestartSelfTest.testStopOriginatingNode   sometimes 
> fails (~5% probability) due to  inability to register a cache metrics MBean:
> {noformat}
> org.apache.ignite.IgniteCheckedException: Failed to register MBean for 
> component: 
> org.apache.ignite.internal.processors.cache.CacheMetricsMXBeanImpl@3a5e46b6
> at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
> at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
> at 
> org.apache.ignite.internal.util.IgniteUtils.registerCacheMBean(IgniteUtils.java:4355)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.registerMbean(GridCacheProcessor.java:3267)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.createCache(GridCacheProcessor.java:1526)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:813)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:937)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1617)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1484)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:965)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:526)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:725)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:709)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:686)
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheCreateRestartSelfTest.testStopOriginatingNode(IgniteCacheCreateRestartSelfTest.java:104)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IGNITE-3183) ScanQuery and localEntries are ignored keepBinary flag in OFFHEAP_TIERED mode

2016-05-23 Thread Nikolay Tikhonov (JIRA)


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

Nikolay Tikhonov updated IGNITE-3183:
-
Attachment: CacheKeepBinaryIterationTest.java

> ScanQuery and localEntries are ignored keepBinary flag in OFFHEAP_TIERED mode
> -
>
> Key: IGNITE-3183
> URL: https://issues.apache.org/jira/browse/IGNITE-3183
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, important
>Affects Versions: 1.6
>Reporter: Nikolay Tikhonov
> Attachments: CacheKeepBinaryIterationTest.java
>
>
> {{ScanQuery}} and {{localEntries}} method returns iterator which contains 
> deserialized entries but they have been called with withKeepBinary flag. 
> Reproducible test attached.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-3183) ScanQuery and localEntries are ignored keepBinary flag in OFFHEAP_TIERED mode

2016-05-23 Thread Nikolay Tikhonov (JIRA)

Nikolay Tikhonov created IGNITE-3183:


 Summary: ScanQuery and localEntries are ignored keepBinary flag in 
OFFHEAP_TIERED mode
 Key: IGNITE-3183
 URL: https://issues.apache.org/jira/browse/IGNITE-3183
 Project: Ignite
  Issue Type: Bug
  Components: cache, important
Affects Versions: 1.6
Reporter: Nikolay Tikhonov


{{ScanQuery}} and {{localEntries}} method returns iterator which contains 
deserialized entries but they have been called with withKeepBinary flag. 
Reproducible test attached.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-2888) Eviction policy not called upon cache.remove()

2016-05-23 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on IGNITE-2888:


GitHub user ilantukh opened a pull request:

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

IGNITE-2888



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

$ git pull https://github.com/ilantukh/ignite ignite-2888

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

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


commit a8e48f074c37f1d0ed4c2c9775b658aea7b3c85f
Author: Ilya Lantukh 
Date:   2016-05-23T11:58:59Z

ignite-2888 : Extended ConcurrentEvictionConsistencyTest to test different 
cache configurations.

commit 5311fecea91cba4c2e235356338f23f03c7a2674
Author: Ilya Lantukh 
Date:   2016-05-23T12:14:36Z

ignite-2888 : Disabled skipping of removed entries during unlock.




> Eviction policy not called upon cache.remove()
> --
>
> Key: IGNITE-2888
> URL: https://issues.apache.org/jira/browse/IGNITE-2888
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.5.0.final
> Environment: java version "1.8.0_73"
> Java(TM) SE Runtime Environment (build 1.8.0_73-b02)
> Java HotSpot(TM) 64-Bit Server VM (build 25.73-b02, mixed mode)
> Windows 10 64bit
>Reporter: Avihai Berkovitz
>Assignee: Ilya Lantukh
>
> When I set an eviction policy to a cache it doesn't get called when removing 
> an entry from the cache. This only happens when using a *REPLICATED* or 
> *PARTITIONED* cache, and only in *ATOMIC* mode. This is the reason it never 
> came up in the GridCacheConcurrentEvictionConsistencySelfTest test. If you 
> change the cache parameters in the test you can see the problem easily.
> This causes two problems:
> * Cache entries that were deleted still remain in memory, because the objects 
> are referenced by the policy
> * The eviction policy "thinks" the cache is larger than it really is, so 
> entries might be evicted even if there is no need for it
> Here is a small test case to illustrate the problem:
> {code}
> IgniteConfiguration igniteConfig = new IgniteConfiguration()
> .setGridLogger(new Slf4jLogger())
> .setDeploymentMode(DeploymentMode.CONTINUOUS);
> try (Ignite ignite = Ignition.start(igniteConfig)) {
> LruEvictionPolicy evictionPolicy = new LruEvictionPolicy(30);
> CacheConfiguration cacheConfiguration = new 
> CacheConfiguration()
> .setName("test")
> .setCacheMode(CacheMode.REPLICATED)
> .setAtomicityMode(CacheAtomicityMode.ATOMIC)
> .setEvictionPolicy(evictionPolicy);
> IgniteCache cache = 
> ignite.getOrCreateCache(cacheConfiguration);
> for (int i = 1; i <= 100; i++) {
> cache.put("key" + i, "data");
> System.out.println(String.format("Size: %d, LRU: %d", 
> cache.size(CachePeekMode.ALL), evictionPolicy.getCurrentSize()));
> if (i % 5 == 0) {
> cache.remove("key" + (i-1));
> System.out.println(String.format("Size: %d, LRU: %d", 
> cache.size(CachePeekMode.ALL), evictionPolicy.getCurrentSize()));
> }
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (IGNITE-2888) Eviction policy not called upon cache.remove()

2016-05-23 Thread Ilya Lantukh (JIRA)


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

Ilya Lantukh reassigned IGNITE-2888:


Assignee: Ilya Lantukh

> Eviction policy not called upon cache.remove()
> --
>
> Key: IGNITE-2888
> URL: https://issues.apache.org/jira/browse/IGNITE-2888
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.5.0.final
> Environment: java version "1.8.0_73"
> Java(TM) SE Runtime Environment (build 1.8.0_73-b02)
> Java HotSpot(TM) 64-Bit Server VM (build 25.73-b02, mixed mode)
> Windows 10 64bit
>Reporter: Avihai Berkovitz
>Assignee: Ilya Lantukh
>
> When I set an eviction policy to a cache it doesn't get called when removing 
> an entry from the cache. This only happens when using a *REPLICATED* or 
> *PARTITIONED* cache, and only in *ATOMIC* mode. This is the reason it never 
> came up in the GridCacheConcurrentEvictionConsistencySelfTest test. If you 
> change the cache parameters in the test you can see the problem easily.
> This causes two problems:
> * Cache entries that were deleted still remain in memory, because the objects 
> are referenced by the policy
> * The eviction policy "thinks" the cache is larger than it really is, so 
> entries might be evicted even if there is no need for it
> Here is a small test case to illustrate the problem:
> {code}
> IgniteConfiguration igniteConfig = new IgniteConfiguration()
> .setGridLogger(new Slf4jLogger())
> .setDeploymentMode(DeploymentMode.CONTINUOUS);
> try (Ignite ignite = Ignition.start(igniteConfig)) {
> LruEvictionPolicy evictionPolicy = new LruEvictionPolicy(30);
> CacheConfiguration cacheConfiguration = new 
> CacheConfiguration()
> .setName("test")
> .setCacheMode(CacheMode.REPLICATED)
> .setAtomicityMode(CacheAtomicityMode.ATOMIC)
> .setEvictionPolicy(evictionPolicy);
> IgniteCache cache = 
> ignite.getOrCreateCache(cacheConfiguration);
> for (int i = 1; i <= 100; i++) {
> cache.put("key" + i, "data");
> System.out.println(String.format("Size: %d, LRU: %d", 
> cache.size(CachePeekMode.ALL), evictionPolicy.getCurrentSize()));
> if (i % 5 == 0) {
> cache.remove("key" + (i-1));
> System.out.println(String.format("Size: %d, LRU: %d", 
> cache.size(CachePeekMode.ALL), evictionPolicy.getCurrentSize()));
> }
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (IGNITE-2583) Investigate CHM8 allocations in GridDhtTxLocalAdapter.

2016-05-23 Thread Ilya Lantukh (JIRA)


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

Ilya Lantukh reassigned IGNITE-2583:


Assignee: (was: Ilya Lantukh)

> Investigate CHM8 allocations in GridDhtTxLocalAdapter.
> --
>
> Key: IGNITE-2583
> URL: https://issues.apache.org/jira/browse/IGNITE-2583
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>  Labels: performance
> Fix For: 1.7
>
>
> *Problem*
> Whenever GridDhtTxLocalAdapter is allocated, two CHM8-s are created 
> immediately: "nearMap" and "dhtMap". 
> This is visible as a memory hotspot, which is responsible for >2% of overall 
> allocations during single PUT.
> *Proposed solution*
> 1) Investigate whether we really need concurrent semantics here. Can these 
> maps be replaced with HashMap-s or (HashMap + synchronzied)?
> 2) Investigate whether we can optimize for single-mapping scenario.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (IGNITE-2654) Protocol optimization for GridNearLockRequest/Response

2016-05-23 Thread Ilya Lantukh (JIRA)


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

Ilya Lantukh reassigned IGNITE-2654:


Assignee: (was: Ilya Lantukh)

> Protocol optimization for GridNearLockRequest/Response
> --
>
> Key: IGNITE-2654
> URL: https://issues.apache.org/jira/browse/IGNITE-2654
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Reporter: Ilya Lantukh
>  Labels: performance
> Fix For: 1.7
>
>
> Create new, more lightweight versions of GridNearLockRequest/Response:
> - Make miniId integer.
> - Store boolean flags in a single byte field.
> - Remove unused fields.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-3177) [Test] IgfsSizeSelfTest.testReplicated sometimes fails with a timeout.

2016-05-23 Thread Ivan Veselovsky (JIRA)


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

Ivan Veselovsky commented on IGNITE-3177:
-

Similar situation with long time between the 1st log message and the 1st debug 
info happens in all builds where this teat hanged up.

> [Test] IgfsSizeSelfTest.testReplicated sometimes fails with a timeout. 
> ---
>
> Key: IGNITE-3177
> URL: https://issues.apache.org/jira/browse/IGNITE-3177
> Project: Ignite
>  Issue Type: Test
>  Components: IGFS
>Reporter: Ivan Veselovsky
>Assignee: Ivan Veselovsky
>
> In some rare cases test IgfsSizeSelfTest.testReplicated fails with a timeout.
> We have 4 such logs.
> In all known cases a hang up happens on attempt to start the 3rd node.
> I was not able to reproduce the problem locally (test ran ~2200 times without 
> any errors).
> In 1 of 4 cases this is a timeout happening in method  
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest#awaitPartitionMapExchange(boolean,
>  boolean) .
> In other 3 cases this is some hang up happening upon the 3rd node start up.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-3177) [Test] IgfsSizeSelfTest.testReplicated sometimes fails with a timeout.

2016-05-23 Thread Ivan Veselovsky (JIRA)


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

Ivan Veselovsky commented on IGNITE-3177:
-

The following 2 lines of stderr of build #4842 are of interest:
{code}
[13:35:08,617][ERROR][main][root] Test has been timed out and will be 
interrupted (threads dump will be taken before interruption) 
[test=testReplicated, timeout=30]
[13:38:33,207][WARN ][main][IgfsSizeSelfTest0] Dumping debug info for node 
[id=7532609d-88b2-4179-a425-71ae10a0, name=igfs.IgfsSizeSelfTest0, order=1, 
topVer=2, client=false]
{code}

These operations happen on one thread, and there are no blocking operations 
between them (see code below), but the 2nd line logged after 3.5 minutes after 
the 1st. 
{code}
if (runner.isAlive()) {
U.error(log,
"Test has been timed out and will be interrupted (threads dump 
will be taken before interruption) [" +
"test=" + getName() + ", timeout=" + getTestTimeout() + ']');

List nodes = IgnitionEx.allGridsx();

for (Ignite node : nodes)
((IgniteKernal)node).dumpDebugInfo();
{code}

IgnitionEx.allGridsx() is designed to be non-blocking , it gets Ignite nodes 
with 'wait' parameter being 'false'.

So, one of possible explanations of the hang up is that some operating system 
conditions cause the test java process to execute extremely slowly 
(insufficient memory in the system, for example).

> [Test] IgfsSizeSelfTest.testReplicated sometimes fails with a timeout. 
> ---
>
> Key: IGNITE-3177
> URL: https://issues.apache.org/jira/browse/IGNITE-3177
> Project: Ignite
>  Issue Type: Test
>  Components: IGFS
>Reporter: Ivan Veselovsky
>Assignee: Ivan Veselovsky
>
> In some rare cases test IgfsSizeSelfTest.testReplicated fails with a timeout.
> We have 4 such logs.
> In all known cases a hang up happens on attempt to start the 3rd node.
> I was not able to reproduce the problem locally (test ran ~2200 times without 
> any errors).
> In 1 of 4 cases this is a timeout happening in method  
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest#awaitPartitionMapExchange(boolean,
>  boolean) .
> In other 3 cases this is some hang up happening upon the 3rd node start up.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (IGNITE-2744) Optimize "unwindEvict" call in GridCacheIoManager.processMessage().

2016-05-23 Thread Ilya Lantukh (JIRA)


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

Ilya Lantukh reassigned IGNITE-2744:


Assignee: Semen Boikov  (was: Ilya Lantukh)

> Optimize "unwindEvict" call in GridCacheIoManager.processMessage().
> ---
>
> Key: IGNITE-2744
> URL: https://issues.apache.org/jira/browse/IGNITE-2744
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Semen Boikov
>Priority: Critical
>  Labels: performance
> Fix For: 1.7
>
>
> We call this method on every (!!!) received cache message. This call is 
> pretty heavy as it iterates over all caches. 
> We need to optimize it. E.g., check evicts only for the cache to which 
> received message belongs. And iterate over the whole set only if we know for 
> sure that several caches are affected (e.g. due to cross-cache TX).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (IGNITE-3014) Optimize GridDhtPartitionTopologyImpl#localPartition()

2016-05-23 Thread Ilya Lantukh (JIRA)


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

Ilya Lantukh reassigned IGNITE-3014:


Assignee: Semen Boikov  (was: Yakov Zhdanov)

> Optimize GridDhtPartitionTopologyImpl#localPartition()
> --
>
> Key: IGNITE-3014
> URL: https://issues.apache.org/jira/browse/IGNITE-3014
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ilya Lantukh
>Assignee: Semen Boikov
>  Labels: performance
>
> This method is called at least once for every cache operation on each node.
> It was partially optimized in 
> https://issues.apache.org/jira/browse/IGNITE-2948.
> It seems that we can reduce time spent in that method even further by 
> removing excessive RW locks and using volatile read/write instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-2865) Continuous query event passed to filter should be immutable for users.

2016-05-23 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on IGNITE-2865:


GitHub user tledkov-gridgain opened a pull request:

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

IGNITE-2865 Continuous query event passed to filter should be immutale for 
users.



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

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

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

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


commit b9feb2900ee2660685710b17503b774765e7bdae
Author: tledkov-gridgain 
Date:   2016-05-20T14:10:13Z

IGNITE-2865 Continuous query event passed to filter should be immutable for 
users.




> Continuous query event passed to filter should be immutable for users.
> --
>
> Key: IGNITE-2865
> URL: https://issues.apache.org/jira/browse/IGNITE-2865
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>Priority: Critical
>  Labels: community, important
> Fix For: 1.7
>
>
> *Problem*
> When event is passed to continuous query filter, it can be used only in scope 
> of this method. The reason is that if filter returns {{false}}, the method 
> {{CacheContinuousQueryEntry.markFiltered()}} is called. This method *clears* 
> key and values.
> *Solution*
> We should not clear key and values. Instead, we should properly check for 
> {{FILTERED_ENTRY}} flag in all methods where {{key/newVal/oldVal/depInfo}} 
> are used. This includes generated {{readFrom()/writeTo()}} methods as well - 
> their manual change will be required.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-2865) Continuous query event passed to filter should be immutable for users.

2016-05-23 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on IGNITE-2865:


Github user tledkov-gridgain closed the pull request at:

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


> Continuous query event passed to filter should be immutable for users.
> --
>
> Key: IGNITE-2865
> URL: https://issues.apache.org/jira/browse/IGNITE-2865
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>Priority: Critical
>  Labels: community, important
> Fix For: 1.7
>
>
> *Problem*
> When event is passed to continuous query filter, it can be used only in scope 
> of this method. The reason is that if filter returns {{false}}, the method 
> {{CacheContinuousQueryEntry.markFiltered()}} is called. This method *clears* 
> key and values.
> *Solution*
> We should not clear key and values. Instead, we should properly check for 
> {{FILTERED_ENTRY}} flag in all methods where {{key/newVal/oldVal/depInfo}} 
> are used. This includes generated {{readFrom()/writeTo()}} methods as well - 
> their manual change will be required.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-3182) Compute jobs execute on client nodes

2016-05-23 Thread Pavel Tupitsyn (JIRA)

Pavel Tupitsyn created IGNITE-3182:
--

 Summary: Compute jobs execute on client nodes
 Key: IGNITE-3182
 URL: https://issues.apache.org/jira/browse/IGNITE-3182
 Project: Ignite
  Issue Type: Bug
Affects Versions: 1.6
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 1.7


* One server node, one client node, Broadcast from client node results in both 
nodes executing the closure
* Need to check the behavior with 2 servers, 2 clients, broadcast from server 
and client



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-3164) Add an option to send resulting value instead of entry processor in transactional cache

2016-05-23 Thread Nikolay Tikhonov (JIRA)


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

Nikolay Tikhonov commented on IGNITE-3164:
--

Implemented `IgniteCache.withSendValueToBackup()` behaviour. In this case entry 
processor creates values to cache only on primary node and  sends they to 
backup nodes. But we have one more invocation on client node (where {{invoke}} 
method was called) for value which will be returned from {{invoke}} method. 
Should we rid the invocation and send resulting value from primary node to 
client node?

> Add an option to send resulting value instead of entry processor in 
> transactional cache
> ---
>
> Key: IGNITE-3164
> URL: https://issues.apache.org/jira/browse/IGNITE-3164
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Nikolay Tikhonov
>  Labels: important
> Fix For: 1.7
>
>
> In some cases user can't guarantee that EP behaves consistently on all nodes. 
> In transactional cache this can lead to inconsistent cache, because we invoke 
> EP on both primary and backup nodes.
> We can add {{withSendValueToBackup()}} flag (naming is arguable) which will 
> override current default behavior.
> We also need to update documentation, especially provide the explanation of 
> EP behavior in atomic and transactional caches.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (IGNITE-1922) Add auth support to YARN module

2016-05-23 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov closed IGNITE-1922.
---

> Add auth support to YARN module
> ---
>
> Key: IGNITE-1922
> URL: https://issues.apache.org/jira/browse/IGNITE-1922
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: ignite-1.4
>Reporter: Nikolay Tikhonov
>Assignee: Ivan Veselovsky
> Fix For: 1.6
>
>
> User list discussion:
> http://apache-ignite-users.70518.x6.nabble.com/Exception-in-Kerberos-Yarn-cluster-td1950.html#a1965



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IGNITE-3113) CPP: Improve documentation.

2016-05-23 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov updated IGNITE-3113:

Fix Version/s: (was: 1.6)
   1.7

> CPP: Improve documentation.
> ---
>
> Key: IGNITE-3113
> URL: https://issues.apache.org/jira/browse/IGNITE-3113
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, platforms
>Affects Versions: 1.5.0.final
>Reporter: Igor Sapego
>Assignee: Vladimir Ozerov
> Fix For: 1.7
>
>
> Current C++ documentation is poor and does not give much of information about 
> the classes and methods. Improve documentation adding more detailed 
> information about the classes and methods usage, fail cases and maybe provide 
> some simple guidelines/explanations of the methods usage.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (IGNITE-2963) .NET: Document mixed-cluster behavior

2016-05-23 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov closed IGNITE-2963.
---

> .NET: Document mixed-cluster behavior
> -
>
> Key: IGNITE-2963
> URL: https://issues.apache.org/jira/browse/IGNITE-2963
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> * Create a page on https://apacheignite-net.readme.io/ that describes 
> Ignite.NET behavior when used in mixed clusters (with Java-only and CPP 
> nodes).
> * Test what happens when .NET predicates are deployed to Java-only nodes



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (IGNITE-3150) Update C++ documentation on readme.io

2016-05-23 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov closed IGNITE-3150.
---

> Update C++ documentation on readme.io
> -
>
> Key: IGNITE-3150
> URL: https://issues.apache.org/jira/browse/IGNITE-3150
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, platforms
>Affects Versions: 1.5.0.final
>Reporter: Igor Sapego
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> C++ documentation should be updated for 1.6. We need to add new version, 
> update building information and add section with Transaction API.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-2865) Continuous query event passed to filter should be immutable for users.

2016-05-23 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on IGNITE-2865:


GitHub user tledkov-gridgain opened a pull request:

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

IGNITE-2865 Continuous query event passed to filter should be immutable for 
users.



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

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

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

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


commit 171b82901f1b25c62f998e5b9b0d0480f7c8079f
Author: tledkov-gridgain 
Date:   2016-05-20T14:10:13Z

IGNITE-2865 Continuous query event passed to filter should be immutable for 
users.

commit cd130bc91715cddcc28605be184557a25992ed9b
Author: tledkov-gridgain 
Date:   2016-05-20T14:30:43Z

IGNITE-2865 - fix javadoc




> Continuous query event passed to filter should be immutable for users.
> --
>
> Key: IGNITE-2865
> URL: https://issues.apache.org/jira/browse/IGNITE-2865
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>Priority: Critical
>  Labels: community, important
> Fix For: 1.7
>
>
> *Problem*
> When event is passed to continuous query filter, it can be used only in scope 
> of this method. The reason is that if filter returns {{false}}, the method 
> {{CacheContinuousQueryEntry.markFiltered()}} is called. This method *clears* 
> key and values.
> *Solution*
> We should not clear key and values. Instead, we should properly check for 
> {{FILTERED_ENTRY}} flag in all methods where {{key/newVal/oldVal/depInfo}} 
> are used. This includes generated {{readFrom()/writeTo()}} methods as well - 
> their manual change will be required.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-3175) BigDecimal fields are not supported if query is executed from IgniteRDD

2016-05-23 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on IGNITE-3175:


Github user tledkov-gridgain closed the pull request at:

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


> BigDecimal fields are not supported if query is executed from IgniteRDD
> ---
>
> Key: IGNITE-3175
> URL: https://issues.apache.org/jira/browse/IGNITE-3175
> Project: Ignite
>  Issue Type: Bug
>  Components: Ignite RDD
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
> Fix For: 1.7
>
>
> If one of the fields participating in the query is {{BigDecimal}}, the query 
> will fail when executed from {{IgniteRDD}} with the following error:
> {noformat}
> scala.MatchError: 1124757 (of class java.math.BigDecimal)
>   at 
> org.apache.spark.sql.catalyst.CatalystTypeConverters$StructConverter.toCatalystImpl(CatalystTypeConverters.scala:255)
>   at 
> org.apache.spark.sql.catalyst.CatalystTypeConverters$StructConverter.toCatalystImpl(CatalystTypeConverters.scala:250)
>   at 
> org.apache.spark.sql.catalyst.CatalystTypeConverters$CatalystTypeConverter.toCatalyst(CatalystTypeConverters.scala:102)
>   at 
> org.apache.spark.sql.catalyst.CatalystTypeConverters$StructConverter.toCatalystImpl(CatalystTypeConverters.scala:260)
>   at 
> org.apache.spark.sql.catalyst.CatalystTypeConverters$StructConverter.toCatalystImpl(CatalystTypeConverters.scala:250)
>   at 
> org.apache.spark.sql.catalyst.CatalystTypeConverters$CatalystTypeConverter.toCatalyst(CatalystTypeConverters.scala:102)
>   at 
> org.apache.spark.sql.catalyst.CatalystTypeConverters$$anonfun$createToCatalystConverter$2.apply(CatalystTypeConverters.scala:401)
>   at 
> org.apache.spark.sql.SQLContext$$anonfun$6.apply(SQLContext.scala:492)
>   at 
> org.apache.spark.sql.SQLContext$$anonfun$6.apply(SQLContext.scala:492)
>   at scala.collection.Iterator$$anon$11.next(Iterator.scala:328)
>   at scala.collection.Iterator$$anon$11.next(Iterator.scala:328)
>   at 
> org.apache.spark.sql.execution.aggregate.TungstenAggregationIterator.processInputs(TungstenAggregationIterator.scala:505)
>   at 
> org.apache.spark.sql.execution.aggregate.TungstenAggregationIterator.(TungstenAggregationIterator.scala:686)
>   at 
> org.apache.spark.sql.execution.aggregate.TungstenAggregate$$anonfun$doExecute$1$$anonfun$2.apply(TungstenAggregate.scala:95)
>   at 
> org.apache.spark.sql.execution.aggregate.TungstenAggregate$$anonfun$doExecute$1$$anonfun$2.apply(TungstenAggregate.scala:86)
>   at 
> org.apache.spark.rdd.RDD$$anonfun$mapPartitions$1$$anonfun$apply$20.apply(RDD.scala:710)
>   at 
> org.apache.spark.rdd.RDD$$anonfun$mapPartitions$1$$anonfun$apply$20.apply(RDD.scala:710)
>   at 
> org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:38)
>   at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:306)
>   at org.apache.spark.rdd.RDD.iterator(RDD.scala:270)
>   at 
> org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:38)
>   at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:306)
>   at org.apache.spark.rdd.RDD.iterator(RDD.scala:270)
>   at 
> org.apache.spark.scheduler.ShuffleMapTask.runTask(ShuffleMapTask.scala:73)
>   at 
> org.apache.spark.scheduler.ShuffleMapTask.runTask(ShuffleMapTask.scala:41)
>   at org.apache.spark.scheduler.Task.run(Task.scala:89)
>   at org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:213)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> Most likely this is caused by the fact that {{IgniteRDD.dataType()}} method 
> doesn't honor {{BigDecimal}} and returns {{StructType}} by default. We should 
> fix this and check other possible types as well.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (IGNITE-2744) Optimize "unwindEvict" call in GridCacheIoManager.processMessage().

2016-05-23 Thread Semen Boikov (JIRA)


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

Semen Boikov reassigned IGNITE-2744:


Assignee: Ilya Lantukh  (was: Semen Boikov)

Reviewed, good to merge.

> Optimize "unwindEvict" call in GridCacheIoManager.processMessage().
> ---
>
> Key: IGNITE-2744
> URL: https://issues.apache.org/jira/browse/IGNITE-2744
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Ilya Lantukh
>Priority: Critical
>  Labels: performance
> Fix For: 1.7
>
>
> We call this method on every (!!!) received cache message. This call is 
> pretty heavy as it iterates over all caches. 
> We need to optimize it. E.g., check evicts only for the cache to which 
> received message belongs. And iterate over the whole set only if we know for 
> sure that several caches are affected (e.g. due to cross-cache TX).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IGNITE-2832) CacheJdbcPojoStoreFactory.dataSource property should be replaced with Factory

2016-05-23 Thread Pavel Konstantinov (JIRA)


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

Pavel Konstantinov updated IGNITE-2832:
---
Assignee: (was: Pavel Konstantinov)

> CacheJdbcPojoStoreFactory.dataSource property should be replaced with Factory
> -
>
> Key: IGNITE-2832
> URL: https://issues.apache.org/jira/browse/IGNITE-2832
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache, community
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
> Fix For: 1.6
>
>
> {{CacheJdbcPojoStoreFactory.dataSource}} property seems to be useless and 
> confusing, because it's transient and therefore data source is lost when 
> configuration is serialized.
> This property should be deprecated and replaced with {{Factory}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (IGNITE-2832) CacheJdbcPojoStoreFactory.dataSource property should be replaced with Factory

2016-05-23 Thread Pavel Konstantinov (JIRA)


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

Pavel Konstantinov closed IGNITE-2832.
--

> CacheJdbcPojoStoreFactory.dataSource property should be replaced with Factory
> -
>
> Key: IGNITE-2832
> URL: https://issues.apache.org/jira/browse/IGNITE-2832
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache, community
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Pavel Konstantinov
> Fix For: 1.6
>
>
> {{CacheJdbcPojoStoreFactory.dataSource}} property seems to be useless and 
> confusing, because it's transient and therefore data source is lost when 
> configuration is serialized.
> This property should be deprecated and replaced with {{Factory}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-2832) CacheJdbcPojoStoreFactory.dataSource property should be replaced with Factory

2016-05-23 Thread Pavel Konstantinov (JIRA)


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

Pavel Konstantinov commented on IGNITE-2832:


Successfully tested with grid version 1.6

> CacheJdbcPojoStoreFactory.dataSource property should be replaced with Factory
> -
>
> Key: IGNITE-2832
> URL: https://issues.apache.org/jira/browse/IGNITE-2832
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache, community
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Pavel Konstantinov
> Fix For: 1.6
>
>
> {{CacheJdbcPojoStoreFactory.dataSource}} property seems to be useless and 
> confusing, because it's transient and therefore data source is lost when 
> configuration is serialized.
> This property should be deprecated and replaced with {{Factory}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

41 matches

Mail list logo