[jira] [Commented] (IGNITE-2899) BinaryObject is deserialized before getting passed to CacheInterceptor
[
https://issues.apache.org/jira/browse/IGNITE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15293090#comment-15293090
]
Artem Shutak commented on IGNITE-2899:
--
Semen,
Thanks for pointing this out! Fixed the second point for both getEntry and
getEntryAsync.
Run TC.
> 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
>Assignee: Artem Shutak
> 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-2899) BinaryObject is deserialized before getting passed to CacheInterceptor
[
https://issues.apache.org/jira/browse/IGNITE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15289430#comment-15289430
]
Artem Shutak commented on IGNITE-2899:
--
Fixed p1 in a more right way.
Waiting for TC results.
> 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
>Assignee: Artem Shutak
> 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] [Resolved] (IGNITE-3148) No description for package org.apache.ignite.cache.jta.websphere in javadoc
[
https://issues.apache.org/jira/browse/IGNITE-3148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Artem Shutak resolved IGNITE-3148.
--
Resolution: Fixed
Assignee: Ilya Suntsov (was: Artem Shutak)
> No description for package org.apache.ignite.cache.jta.websphere in javadoc
> ---
>
> Key: IGNITE-3148
> URL: https://issues.apache.org/jira/browse/IGNITE-3148
> Project: Ignite
> Issue Type: Bug
> Components: documentation
>Affects Versions: 1.6
>Reporter: Ilya Suntsov
>Assignee: Ilya Suntsov
>Priority: Minor
> Fix For: 1.6
>
>
> Need to add description for package
> {noformat} org.apache.ignite.cache.jta.websphere {noformat}
> in javadoc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (IGNITE-3148) No description for package org.apache.ignite.cache.jta.websphere in javadoc
[
https://issues.apache.org/jira/browse/IGNITE-3148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Artem Shutak reassigned IGNITE-3148:
Assignee: Artem Shutak
> No description for package org.apache.ignite.cache.jta.websphere in javadoc
> ---
>
> Key: IGNITE-3148
> URL: https://issues.apache.org/jira/browse/IGNITE-3148
> Project: Ignite
> Issue Type: Bug
> Components: documentation
>Affects Versions: 1.6
>Reporter: Ilya Suntsov
>Assignee: Artem Shutak
>Priority: Minor
> Fix For: 1.6
>
>
> Need to add description for package
> {noformat} org.apache.ignite.cache.jta.websphere {noformat}
> in javadoc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (IGNITE-2921) ScanQueries over local partitions are not optimal
[
https://issues.apache.org/jira/browse/IGNITE-2921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Artem Shutak closed IGNITE-2921.
> ScanQueries over local partitions are not optimal
> -
>
> Key: IGNITE-2921
> URL: https://issues.apache.org/jira/browse/IGNITE-2921
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Artem Shutak
>Priority: Blocker
> Labels: community, important, performance
> Fix For: 1.6
>
> Attachments: LocalIteratorStuff.java, ScanQueryStuff.java
>
>
> Presently scan queries over local partitions are not executed optimally.
> If to run a scan query over a specific partition (by setting
> {{query.setPartition(...)}} parameter and or {{query.setLocal(true)}}) and
> start iterating over entries we will see that the Thread, that iterates over
> the data, waits for some event to happen.
> In fact the Thread waits while a system pool's thread prepares an iterator
> with entries for it and only after that iterates over the returned result
> set. The flow looks this way:
> - {{GridCacheLocalQueryFuture}} is created;
> - when {{QueryCursor.iterator().next}} is called from the app thread (the
> Thread above), {{GridCacheLocalQueryFuture.execute()}} methods puts closure
> that will prepare content for the iterator in the system pool.
> - a system Thread execute {{GridCacheQueryManager.runQuery()}} reading all
> the entries from partition and passing them back to the Thread at line 1553
> by calling {{onPageReady(...)}} method.
> The other bottleneck is that a system thread gets all the entries and passes
> them to the Thread which will lead to more garbaged Java heap especially if
> cache is {{OFFHEAP_TIRED}}.
> Run attached test ({{ScanQueryStuff}}) and you will see with Visual VM that
> most of the time the test spends executing the code from system threads.
> Finally, what have to be done:
> - if ScanQuery is supposed to be executed locally (setPartition() refers to
> local partition or setLocal is set to true) then the calling application
> thread has to iterate over the data avoiding usage of the system pool;
> - internal code mustn't read all entries from a partition initially. The
> iterator has to get one entry next after another. This will be a memory
> backpressure mechanism especially for {{OFFHEAP_TIRED}}.
> My assumption is that the fixed version has to work in a similar way to
> iteration over local entries -
> {{cache.localEntries(CachePeekMode.PRIMARY);}}. Run attached
> {{LocalIteratorStuff}} to see with Visual VM that the application thread is
> fully utilized and system threads are idle.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2921) ScanQueries over local partitions are not optimal
[
https://issues.apache.org/jira/browse/IGNITE-2921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15282676#comment-15282676
]
Artem Shutak commented on IGNITE-2921:
--
TC looks good. Ready for review.
> ScanQueries over local partitions are not optimal
> -
>
> Key: IGNITE-2921
> URL: https://issues.apache.org/jira/browse/IGNITE-2921
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Artem Shutak
>Priority: Blocker
> Labels: community, important, performance
> Fix For: 1.6
>
> Attachments: LocalIteratorStuff.java, ScanQueryStuff.java
>
>
> Presently scan queries over local partitions are not executed optimally.
> If to run a scan query over a specific partition (by setting
> {{query.setPartition(...)}} parameter and or {{query.setLocal(true)}}) and
> start iterating over entries we will see that the Thread, that iterates over
> the data, waits for some event to happen.
> In fact the Thread waits while a system pool's thread prepares an iterator
> with entries for it and only after that iterates over the returned result
> set. The flow looks this way:
> - {{GridCacheLocalQueryFuture}} is created;
> - when {{QueryCursor.iterator().next}} is called from the app thread (the
> Thread above), {{GridCacheLocalQueryFuture.execute()}} methods puts closure
> that will prepare content for the iterator in the system pool.
> - a system Thread execute {{GridCacheQueryManager.runQuery()}} reading all
> the entries from partition and passing them back to the Thread at line 1553
> by calling {{onPageReady(...)}} method.
> The other bottleneck is that a system thread gets all the entries and passes
> them to the Thread which will lead to more garbaged Java heap especially if
> cache is {{OFFHEAP_TIRED}}.
> Run attached test ({{ScanQueryStuff}}) and you will see with Visual VM that
> most of the time the test spends executing the code from system threads.
> Finally, what have to be done:
> - if ScanQuery is supposed to be executed locally (setPartition() refers to
> local partition or setLocal is set to true) then the calling application
> thread has to iterate over the data avoiding usage of the system pool;
> - internal code mustn't read all entries from a partition initially. The
> iterator has to get one entry next after another. This will be a memory
> backpressure mechanism especially for {{OFFHEAP_TIRED}}.
> My assumption is that the fixed version has to work in a similar way to
> iteration over local entries -
> {{cache.localEntries(CachePeekMode.PRIMARY);}}. Run attached
> {{LocalIteratorStuff}} to see with Visual VM that the application thread is
> fully utilized and system threads are idle.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2959) Ignite JTA and WebSphere Application Server 8.5.5
[
https://issues.apache.org/jira/browse/IGNITE-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15282650#comment-15282650
]
Artem Shutak commented on IGNITE-2959:
--
Merged at 1.6 (fd0714e) and master.
> Ignite JTA and WebSphere Application Server 8.5.5
> -
>
> Key: IGNITE-2959
> URL: https://issues.apache.org/jira/browse/IGNITE-2959
> Project: Ignite
> Issue Type: Task
>Reporter: Artem Shutak
>Assignee: Semen Boikov
> Labels: community, important
> Fix For: 1.6
>
>
> Need to support of working Ignite transactions inside WebSphere Application
> Server (8.5.5).
> The issue only about poor (ordinary) WebSphere Application Server.
> There is *no* issue with WebSphere Liberty. To enable JTA on WS Liberty it is
> enough to do the following.
> 1. add the following class in own libs:
> {code}
> public class WebSphereTmFactory implements Factory {
> /** {@inheritDoc} */
> @Override public TransactionManager create() {
> return
> com.ibm.tx.jta.TransactionManagerFactory.getTransactionManager();
> }
> }
> {code}
> 2. It's required the following maven dependencies:
> {code}
>
> com.ibm.websphere.appserver.api
>
> com.ibm.websphere.appserver.api.transaction
> 1.1.10
>
> {code}
> 3. And Ignite's TransactionConfiguration has to be properly configured with
> WebSphereTmFactory:
> {code}
> TransactionConfiguration tcfg = new TransactionConfiguration();
> TransactionConfiguration.setTxManagerFactory(new WebSphereTmFactory());
> igniteCfg.setTransactionConfiguration(tcfg)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2899) BinaryObject is deserialized before getting passed to CacheInterceptor
[
https://issues.apache.org/jira/browse/IGNITE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15281582#comment-15281582
]
Artem Shutak commented on IGNITE-2899:
--
1. Removed isLocal check and run TC. As I remember, some local cache test fails
without it.
2. Reviewed and did minor changes.
> 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
>Assignee: Artem Shutak
> Fix For: 1.6
>
> 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
>
[jira] [Commented] (IGNITE-3056) Service implementation class is required even if it's not expected to be deployed on current node
[
https://issues.apache.org/jira/browse/IGNITE-3056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15281574#comment-15281574
]
Artem Shutak commented on IGNITE-3056:
--
TC looks good (after fix at one assertion).
> Service implementation class is required even if it's not expected to be
> deployed on current node
> -
>
> Key: IGNITE-3056
> URL: https://issues.apache.org/jira/browse/IGNITE-3056
> Project: Ignite
> Issue Type: Bug
> Components: managed services
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Artem Shutak
> Labels: community, customer, important
> Fix For: 1.6
>
>
> Currently the service instance is deserialized as part of
> {{GridServiceDeployment}} and {{GridServiceAssignment}} classes. Need to
> check if it's possible to deserialize only node filter first, and then
> deserialize the service itself only if needed. This will allow to use cluster
> groups with services and deploy the classes accordingly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3056) Service implementation class is required even if it's not expected to be deployed on current node
[
https://issues.apache.org/jira/browse/IGNITE-3056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15280354#comment-15280354
]
Artem Shutak commented on IGNITE-3056:
--
Added SERVICE_COMPATIBILITY_ENABLED system property in suggested way.
Added consistency tests on the property.
Fixed a bug with injection to lazy configuration.
Waiting for TC.
> Service implementation class is required even if it's not expected to be
> deployed on current node
> -
>
> Key: IGNITE-3056
> URL: https://issues.apache.org/jira/browse/IGNITE-3056
> Project: Ignite
> Issue Type: Bug
> Components: managed services
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Artem Shutak
> Labels: community, customer, important
> Fix For: 1.6
>
>
> Currently the service instance is deserialized as part of
> {{GridServiceDeployment}} and {{GridServiceAssignment}} classes. Need to
> check if it's possible to deserialize only node filter first, and then
> deserialize the service itself only if needed. This will allow to use cluster
> groups with services and deploy the classes accordingly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2959) Ignite JTA and WebSphere Application Server 8.5.5
[
https://issues.apache.org/jira/browse/IGNITE-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15280306#comment-15280306
]
Artem Shutak commented on IGNITE-2959:
--
Moved WebSphereTMFactory at jta module. Added JavaDoc.
Created CacheReflectionTMFactory to be used with WS Liberty (for example).
Added new module ignite-webspehre-test to test WS features.
Ready for review.
> Ignite JTA and WebSphere Application Server 8.5.5
> -
>
> Key: IGNITE-2959
> URL: https://issues.apache.org/jira/browse/IGNITE-2959
> Project: Ignite
> Issue Type: Task
>Reporter: Artem Shutak
>Assignee: Artem Shutak
> Labels: community, important
> Fix For: 1.6
>
>
> Need to support of working Ignite transactions inside WebSphere Application
> Server (8.5.5).
> The issue only about poor (ordinary) WebSphere Application Server.
> There is *no* issue with WebSphere Liberty. To enable JTA on WS Liberty it is
> enough to do the following.
> 1. add the following class in own libs:
> {code}
> public class WebSphereTmFactory implements Factory {
> /** {@inheritDoc} */
> @Override public TransactionManager create() {
> return
> com.ibm.tx.jta.TransactionManagerFactory.getTransactionManager();
> }
> }
> {code}
> 2. It's required the following maven dependencies:
> {code}
>
> com.ibm.websphere.appserver.api
>
> com.ibm.websphere.appserver.api.transaction
> 1.1.10
>
> {code}
> 3. And Ignite's TransactionConfiguration has to be properly configured with
> WebSphereTmFactory:
> {code}
> TransactionConfiguration tcfg = new TransactionConfiguration();
> TransactionConfiguration.setTxManagerFactory(new WebSphereTmFactory());
> igniteCfg.setTransactionConfiguration(tcfg)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2959) Ignite JTA and WebSphere Application Server 8.5.5
[
https://issues.apache.org/jira/browse/IGNITE-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15280303#comment-15280303
]
Artem Shutak commented on IGNITE-2959:
--
PR: https://github.com/apache/ignite/pull/704
> Ignite JTA and WebSphere Application Server 8.5.5
> -
>
> Key: IGNITE-2959
> URL: https://issues.apache.org/jira/browse/IGNITE-2959
> Project: Ignite
> Issue Type: Task
>Reporter: Artem Shutak
>Assignee: Artem Shutak
> Labels: community, important
> Fix For: 1.6
>
>
> Need to support of working Ignite transactions inside WebSphere Application
> Server (8.5.5).
> The issue only about poor (ordinary) WebSphere Application Server.
> There is *no* issue with WebSphere Liberty. To enable JTA on WS Liberty it is
> enough to do the following.
> 1. add the following class in own libs:
> {code}
> public class WebSphereTmFactory implements Factory {
> /** {@inheritDoc} */
> @Override public TransactionManager create() {
> return
> com.ibm.tx.jta.TransactionManagerFactory.getTransactionManager();
> }
> }
> {code}
> 2. It's required the following maven dependencies:
> {code}
>
> com.ibm.websphere.appserver.api
>
> com.ibm.websphere.appserver.api.transaction
> 1.1.10
>
> {code}
> 3. And Ignite's TransactionConfiguration has to be properly configured with
> WebSphereTmFactory:
> {code}
> TransactionConfiguration tcfg = new TransactionConfiguration();
> TransactionConfiguration.setTxManagerFactory(new WebSphereTmFactory());
> igniteCfg.setTransactionConfiguration(tcfg)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1678) IgniteAtomicSequence: make following reservations in advance
[
https://issues.apache.org/jira/browse/IGNITE-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Artem Shutak updated IGNITE-1678:
-
Fix Version/s: (was: 1.6)
1.7
> IgniteAtomicSequence: make following reservations in advance
>
>
> Key: IGNITE-1678
> URL: https://issues.apache.org/jira/browse/IGNITE-1678
> Project: Ignite
> Issue Type: Improvement
> Components: data structures
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Artem Shutak
> Fix For: 1.7
>
>
> In current implementation a new reservation is made when the current local
> sequence boundary is exceeded.
> In cases when there are many nodes that use the same atomic sequence there
> can be a situation when all the nodes start doing a new reservation at the
> same time. This can lead to performance drops.
> As a performance optimization it makes sense to start reserving new sequence
> slot in advance (in background), like when around 80% of current reservation
> has already been used. Probably we should add a special parameter to
> {{AtomicConfiguration}} that will manage such behavior.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1099) Need to cleanup git
[ https://issues.apache.org/jira/browse/IGNITE-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artem Shutak updated IGNITE-1099: - Fix Version/s: (was: 1.6) 1.7 > Need to cleanup git > --- > > Key: IGNITE-1099 > URL: https://issues.apache.org/jira/browse/IGNITE-1099 > Project: Ignite > Issue Type: Bug >Reporter: Yakov Zhdanov >Assignee: Artem Shutak > Fix For: 1.7 > > > * Need to resurrect tool (formerly named JiraBranchesToHtml) that shows up > branches for closed tickets in JIRA > * Need to go through the branches and determine what branches are useless: > ** ignite-sprint-* > ** branches with no activity for recent months -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1185) Locate configuration in class path
[
https://issues.apache.org/jira/browse/IGNITE-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Artem Shutak updated IGNITE-1185:
-
Fix Version/s: (was: 1.6)
1.7
> Locate configuration in class path
> --
>
> Key: IGNITE-1185
> URL: https://issues.apache.org/jira/browse/IGNITE-1185
> Project: Ignite
> Issue Type: Improvement
> Components: newbie
>Reporter: Yakov Zhdanov
>Assignee: Artem Shutak
> Labels: newbie
> Fix For: 1.7
>
> Attachments: master_ignite-1185_3.patch
>
>
> Need ability to locate configuration in classpath, so nodes can be started
> like this:
> {{ignite.sh classpath:config/mycfg.xml}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3056) Service implementation class is required even if it's not expected to be deployed on current node
[
https://issues.apache.org/jira/browse/IGNITE-3056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15274336#comment-15274336
]
Artem Shutak commented on IGNITE-3056:
--
Added to new method on Ignite interface {{deployLazy(ServiceCfg)}}. Is should
be used to solve the issue and if cluster does not have old nodes.
> Service implementation class is required even if it's not expected to be
> deployed on current node
> -
>
> Key: IGNITE-3056
> URL: https://issues.apache.org/jira/browse/IGNITE-3056
> Project: Ignite
> Issue Type: Bug
> Components: managed services
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Artem Shutak
> Labels: community, customer, important
> Fix For: 1.6
>
>
> Currently the service instance is deserialized as part of
> {{GridServiceDeployment}} and {{GridServiceAssignment}} classes. Need to
> check if it's possible to deserialize only node filter first, and then
> deserialize the service itself only if needed. This will allow to use cluster
> groups with services and deploy the classes accordingly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3056) Service implementation class is required even if it's not expected to be deployed on current node
[
https://issues.apache.org/jira/browse/IGNITE-3056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15272785#comment-15272785
]
Artem Shutak commented on IGNITE-3056:
--
A simple fix is to create {{LazyServiceConfiguration}} (before putting inside
{{GridServiceDeployment}}) that has user provided {{Service}} as bytes and has
{{Service}} field as transient. As a result, it's not required to have service
class on all nodes and service deserialization happens only on nodes according
to filter. I've tried the fix and all works as well.
But the simple fix is not backward compatible.
Also we cannot modify old (create new) classes {{GridServiceDeploymentKey}} and
{{GridServiceDeployment}} (cannot put new keys/values in sys-cache).
Algorithm do the following:
- node that do deploy put to sys-cache {{GridServiceDeploymentKey}} and
{{GridServiceDeployment}} pair.
- {{DeploymentListener}} listen for updates and if it finds
{{GridServiceDeploymentKey}} and we are on oldest node then it creates and puts
at sys-cache {{GridServiceAssignmentsKey}} and {{GridServiceAssignments}} pair.
- {{AssignmentListener}} listen for updates and if it finds
{{GridServiceAssignmentsKey}} then it deploys service on local node according
to information at {{GridServiceAssignments}}. Also, if node that initiated the
deployment see proper assignment, then the node completes future.
The problem is that the oldest node can know nothing about user's Service
class. As a result {{Ignite.deploy()}} method on user's node hangs forever
(because the future will be never completed).
To keep backward compatibility, we have to process {{GridServiceDeployment}} on
oldest node if it has information about service class (as it work now) or
process on oldest node according to {{nodeFilter}} (that have to know about
user's service). The problems is how to understand whether the oldest node have
processed successfully assignment or not.
> Service implementation class is required even if it's not expected to be
> deployed on current node
> -
>
> Key: IGNITE-3056
> URL: https://issues.apache.org/jira/browse/IGNITE-3056
> Project: Ignite
> Issue Type: Bug
> Components: managed services
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Artem Shutak
> Labels: community, customer, important
> Fix For: 1.6
>
>
> Currently the service instance is deserialized as part of
> {{GridServiceDeployment}} and {{GridServiceAssignment}} classes. Need to
> check if it's possible to deserialize only node filter first, and then
> deserialize the service itself only if needed. This will allow to use cluster
> groups with services and deploy the classes accordingly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2921) ScanQueries over local partitions are not optimal
[
https://issues.apache.org/jira/browse/IGNITE-2921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15270660#comment-15270660
]
Artem Shutak commented on IGNITE-2921:
--
Fixed review comments. Rerun TC.
> ScanQueries over local partitions are not optimal
> -
>
> Key: IGNITE-2921
> URL: https://issues.apache.org/jira/browse/IGNITE-2921
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Artem Shutak
>Priority: Blocker
> Labels: community, important, performance
> Fix For: 1.6
>
> Attachments: LocalIteratorStuff.java, ScanQueryStuff.java
>
>
> Presently scan queries over local partitions are not executed optimally.
> If to run a scan query over a specific partition (by setting
> {{query.setPartition(...)}} parameter and or {{query.setLocal(true)}}) and
> start iterating over entries we will see that the Thread, that iterates over
> the data, waits for some event to happen.
> In fact the Thread waits while a system pool's thread prepares an iterator
> with entries for it and only after that iterates over the returned result
> set. The flow looks this way:
> - {{GridCacheLocalQueryFuture}} is created;
> - when {{QueryCursor.iterator().next}} is called from the app thread (the
> Thread above), {{GridCacheLocalQueryFuture.execute()}} methods puts closure
> that will prepare content for the iterator in the system pool.
> - a system Thread execute {{GridCacheQueryManager.runQuery()}} reading all
> the entries from partition and passing them back to the Thread at line 1553
> by calling {{onPageReady(...)}} method.
> The other bottleneck is that a system thread gets all the entries and passes
> them to the Thread which will lead to more garbaged Java heap especially if
> cache is {{OFFHEAP_TIRED}}.
> Run attached test ({{ScanQueryStuff}}) and you will see with Visual VM that
> most of the time the test spends executing the code from system threads.
> Finally, what have to be done:
> - if ScanQuery is supposed to be executed locally (setPartition() refers to
> local partition or setLocal is set to true) then the calling application
> thread has to iterate over the data avoiding usage of the system pool;
> - internal code mustn't read all entries from a partition initially. The
> iterator has to get one entry next after another. This will be a memory
> backpressure mechanism especially for {{OFFHEAP_TIRED}}.
> My assumption is that the fixed version has to work in a similar way to
> iteration over local entries -
> {{cache.localEntries(CachePeekMode.PRIMARY);}}. Run attached
> {{LocalIteratorStuff}} to see with Visual VM that the application thread is
> fully utilized and system threads are idle.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3056) Service implementation class is required even if it's not expected to be deployed on current node
[
https://issues.apache.org/jira/browse/IGNITE-3056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262142#comment-15262142
]
Artem Shutak commented on IGNITE-3056:
--
[~vkulichenko] I've assigned ticket to yourself. Let me know if you have any
objections.
I already created tests to reproduce the issue and started investigating the
problem.
> Service implementation class is required even if it's not expected to be
> deployed on current node
> -
>
> Key: IGNITE-3056
> URL: https://issues.apache.org/jira/browse/IGNITE-3056
> Project: Ignite
> Issue Type: Bug
> Components: managed services
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Artem Shutak
> Labels: community, customer, important
> Fix For: 1.6
>
>
> Currently the service instance is deserialized as part of
> {{GridServiceDeployment}} and {{GridServiceAssignment}} classes. Need to
> check if it's possible to deserialize only node filter first, and then
> deserialize the service itself only if needed. This will allow to use cluster
> groups with services and deploy the classes accordingly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (IGNITE-3056) Service implementation class is required even if it's not expected to be deployed on current node
[
https://issues.apache.org/jira/browse/IGNITE-3056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Artem Shutak reassigned IGNITE-3056:
Assignee: Artem Shutak (was: Valentin Kulichenko)
> Service implementation class is required even if it's not expected to be
> deployed on current node
> -
>
> Key: IGNITE-3056
> URL: https://issues.apache.org/jira/browse/IGNITE-3056
> Project: Ignite
> Issue Type: Bug
> Components: managed services
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Artem Shutak
> Labels: community, customer, important
> Fix For: 1.6
>
>
> Currently the service instance is deserialized as part of
> {{GridServiceDeployment}} and {{GridServiceAssignment}} classes. Need to
> check if it's possible to deserialize only node filter first, and then
> deserialize the service itself only if needed. This will allow to use cluster
> groups with services and deploy the classes accordingly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2899) BinaryObject is deserialized before getting passed to CacheInterceptor
[
https://issues.apache.org/jira/browse/IGNITE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15260346#comment-15260346
]
Artem Shutak commented on IGNITE-2899:
--
Fixed .Net and another issues founded on TC. Run all TC build one more time.
Will be ready for review if all will be ok.
> 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
>Assignee: Artem Shutak
> Fix For: 1.6
>
> 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)
[jira] [Commented] (IGNITE-2921) ScanQueries over local partitions are not optimal
[
https://issues.apache.org/jira/browse/IGNITE-2921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15258143#comment-15258143
]
Artem Shutak commented on IGNITE-2921:
--
Fixed Scan query with partition and fail-tolerance case.
Waiting for TC and it will be ready for review.
> ScanQueries over local partitions are not optimal
> -
>
> Key: IGNITE-2921
> URL: https://issues.apache.org/jira/browse/IGNITE-2921
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Artem Shutak
>Priority: Blocker
> Labels: community, important, performance
> Fix For: 1.6
>
> Attachments: LocalIteratorStuff.java, ScanQueryStuff.java
>
>
> Presently scan queries over local partitions are not executed optimally.
> If to run a scan query over a specific partition (by setting
> {{query.setPartition(...)}} parameter and or {{query.setLocal(true)}}) and
> start iterating over entries we will see that the Thread, that iterates over
> the data, waits for some event to happen.
> In fact the Thread waits while a system pool's thread prepares an iterator
> with entries for it and only after that iterates over the returned result
> set. The flow looks this way:
> - {{GridCacheLocalQueryFuture}} is created;
> - when {{QueryCursor.iterator().next}} is called from the app thread (the
> Thread above), {{GridCacheLocalQueryFuture.execute()}} methods puts closure
> that will prepare content for the iterator in the system pool.
> - a system Thread execute {{GridCacheQueryManager.runQuery()}} reading all
> the entries from partition and passing them back to the Thread at line 1553
> by calling {{onPageReady(...)}} method.
> The other bottleneck is that a system thread gets all the entries and passes
> them to the Thread which will lead to more garbaged Java heap especially if
> cache is {{OFFHEAP_TIRED}}.
> Run attached test ({{ScanQueryStuff}}) and you will see with Visual VM that
> most of the time the test spends executing the code from system threads.
> Finally, what have to be done:
> - if ScanQuery is supposed to be executed locally (setPartition() refers to
> local partition or setLocal is set to true) then the calling application
> thread has to iterate over the data avoiding usage of the system pool;
> - internal code mustn't read all entries from a partition initially. The
> iterator has to get one entry next after another. This will be a memory
> backpressure mechanism especially for {{OFFHEAP_TIRED}}.
> My assumption is that the fixed version has to work in a similar way to
> iteration over local entries -
> {{cache.localEntries(CachePeekMode.PRIMARY);}}. Run attached
> {{LocalIteratorStuff}} to see with Visual VM that the application thread is
> fully utilized and system threads are idle.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2899) BinaryObject is deserialized before getting passed to CacheInterceptor
[
https://issues.apache.org/jira/browse/IGNITE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15255696#comment-15255696
]
Artem Shutak commented on IGNITE-2899:
--
Fixed issues founded on TC. Now I have issue with .Net and invoke
(investigating).
> 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
>Assignee: Artem Shutak
> Fix For: 1.6
>
> 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-2899) BinaryObject is deserialized before getting passed to CacheInterceptor
[
https://issues.apache.org/jira/browse/IGNITE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15252516#comment-15252516
]
Artem Shutak commented on IGNITE-2899:
--
Fixed swap.removeOffheap for all mentioned 3 methods (waiting for TC).
Fixed/reverted a couple of cases which has been reverted on review.
Have new failed case with near cache and invokeAll that leads to an assertion
error. Looks like I got it after merge with master.
> 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
>Assignee: Artem Shutak
> Fix For: 1.6
>
> 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
>
[jira] [Commented] (IGNITE-2921) ScanQueries over local partitions are not optimal
[
https://issues.apache.org/jira/browse/IGNITE-2921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15250765#comment-15250765
]
Artem Shutak commented on IGNITE-2921:
--
Finished with tests. Fixed all found issues (including non-related to issue).
Currently, I have a little bit tricky bug with Scan query over partition and
fall-tolerance.
> ScanQueries over local partitions are not optimal
> -
>
> Key: IGNITE-2921
> URL: https://issues.apache.org/jira/browse/IGNITE-2921
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Artem Shutak
>Priority: Blocker
> Labels: community, important, performance
> Fix For: 1.6
>
> Attachments: LocalIteratorStuff.java, ScanQueryStuff.java
>
>
> Presently scan queries over local partitions are not executed optimally.
> If to run a scan query over a specific partition (by setting
> {{query.setPartition(...)}} parameter and or {{query.setLocal(true)}}) and
> start iterating over entries we will see that the Thread, that iterates over
> the data, waits for some event to happen.
> In fact the Thread waits while a system pool's thread prepares an iterator
> with entries for it and only after that iterates over the returned result
> set. The flow looks this way:
> - {{GridCacheLocalQueryFuture}} is created;
> - when {{QueryCursor.iterator().next}} is called from the app thread (the
> Thread above), {{GridCacheLocalQueryFuture.execute()}} methods puts closure
> that will prepare content for the iterator in the system pool.
> - a system Thread execute {{GridCacheQueryManager.runQuery()}} reading all
> the entries from partition and passing them back to the Thread at line 1553
> by calling {{onPageReady(...)}} method.
> The other bottleneck is that a system thread gets all the entries and passes
> them to the Thread which will lead to more garbaged Java heap especially if
> cache is {{OFFHEAP_TIRED}}.
> Run attached test ({{ScanQueryStuff}}) and you will see with Visual VM that
> most of the time the test spends executing the code from system threads.
> Finally, what have to be done:
> - if ScanQuery is supposed to be executed locally (setPartition() refers to
> local partition or setLocal is set to true) then the calling application
> thread has to iterate over the data avoiding usage of the system pool;
> - internal code mustn't read all entries from a partition initially. The
> iterator has to get one entry next after another. This will be a memory
> backpressure mechanism especially for {{OFFHEAP_TIRED}}.
> My assumption is that the fixed version has to work in a similar way to
> iteration over local entries -
> {{cache.localEntries(CachePeekMode.PRIMARY);}}. Run attached
> {{LocalIteratorStuff}} to see with Visual VM that the application thread is
> fully utilized and system threads are idle.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2921) ScanQueries over local partitions are not optimal
[
https://issues.apache.org/jira/browse/IGNITE-2921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15246247#comment-15246247
]
Artem Shutak commented on IGNITE-2921:
--
Performance issue - resolved. Ignite in OFFHEAP_TIRED mode has optimization for
cases when expire policy disabled. Do the same for ONHEAP_TIRED and got
expected performance.
Need to review current flow for case with expire policy do we actually should
the following algorithm:
- get key iterator
- get entry by key
- extract value from entry and check expiration.
I think we can iterate throw entries and do a check on expire policy on lower
level.
Added more tests and fixed bugs (including not changes related bugs).
Left:
- add more tests + fix found issues
- self-review
> ScanQueries over local partitions are not optimal
> -
>
> Key: IGNITE-2921
> URL: https://issues.apache.org/jira/browse/IGNITE-2921
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Artem Shutak
>Priority: Blocker
> Labels: community, important, performance
> Fix For: 1.6
>
> Attachments: LocalIteratorStuff.java, ScanQueryStuff.java
>
>
> Presently scan queries over local partitions are not executed optimally.
> If to run a scan query over a specific partition (by setting
> {{query.setPartition(...)}} parameter and or {{query.setLocal(true)}}) and
> start iterating over entries we will see that the Thread, that iterates over
> the data, waits for some event to happen.
> In fact the Thread waits while a system pool's thread prepares an iterator
> with entries for it and only after that iterates over the returned result
> set. The flow looks this way:
> - {{GridCacheLocalQueryFuture}} is created;
> - when {{QueryCursor.iterator().next}} is called from the app thread (the
> Thread above), {{GridCacheLocalQueryFuture.execute()}} methods puts closure
> that will prepare content for the iterator in the system pool.
> - a system Thread execute {{GridCacheQueryManager.runQuery()}} reading all
> the entries from partition and passing them back to the Thread at line 1553
> by calling {{onPageReady(...)}} method.
> The other bottleneck is that a system thread gets all the entries and passes
> them to the Thread which will lead to more garbaged Java heap especially if
> cache is {{OFFHEAP_TIRED}}.
> Run attached test ({{ScanQueryStuff}}) and you will see with Visual VM that
> most of the time the test spends executing the code from system threads.
> Finally, what have to be done:
> - if ScanQuery is supposed to be executed locally (setPartition() refers to
> local partition or setLocal is set to true) then the calling application
> thread has to iterate over the data avoiding usage of the system pool;
> - internal code mustn't read all entries from a partition initially. The
> iterator has to get one entry next after another. This will be a memory
> backpressure mechanism especially for {{OFFHEAP_TIRED}}.
> My assumption is that the fixed version has to work in a similar way to
> iteration over local entries -
> {{cache.localEntries(CachePeekMode.PRIMARY);}}. Run attached
> {{LocalIteratorStuff}} to see with Visual VM that the application thread is
> fully utilized and system threads are idle.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2921) ScanQueries over local partitions are not optimal
[
https://issues.apache.org/jira/browse/IGNITE-2921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15245346#comment-15245346
]
Artem Shutak commented on IGNITE-2921:
--
Reviewed with Sam.
Fixed review comments (using closeable iterators instead of legacy
{{CacheQueryFuture}} where it is possible).
Added a couple of config variations tests and fixed several bugs (related to
unwrapBinary).
Performans status.
- In OFFHEAP_TIRED mode {{localEntries}} and local {{ScanQuery}} take the same.
- In ONHEAP_TIRED mode local {{ScanQuery}} 2 times slower than
{{localEntries}}. Actually, it's even slower than {{ScnaQuery}} in
OFFHEAP_MODE. The reason is that Ignite does extra operations with
wrapping/unwrapping keys to/from {{KeyCacheObject}} (and we got extra
{{unwrapBinary}} operations).
> ScanQueries over local partitions are not optimal
> -
>
> Key: IGNITE-2921
> URL: https://issues.apache.org/jira/browse/IGNITE-2921
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Artem Shutak
>Priority: Blocker
> Labels: community, important, performance
> Fix For: 1.6
>
> Attachments: LocalIteratorStuff.java, ScanQueryStuff.java
>
>
> Presently scan queries over local partitions are not executed optimally.
> If to run a scan query over a specific partition (by setting
> {{query.setPartition(...)}} parameter and or {{query.setLocal(true)}}) and
> start iterating over entries we will see that the Thread, that iterates over
> the data, waits for some event to happen.
> In fact the Thread waits while a system pool's thread prepares an iterator
> with entries for it and only after that iterates over the returned result
> set. The flow looks this way:
> - {{GridCacheLocalQueryFuture}} is created;
> - when {{QueryCursor.iterator().next}} is called from the app thread (the
> Thread above), {{GridCacheLocalQueryFuture.execute()}} methods puts closure
> that will prepare content for the iterator in the system pool.
> - a system Thread execute {{GridCacheQueryManager.runQuery()}} reading all
> the entries from partition and passing them back to the Thread at line 1553
> by calling {{onPageReady(...)}} method.
> The other bottleneck is that a system thread gets all the entries and passes
> them to the Thread which will lead to more garbaged Java heap especially if
> cache is {{OFFHEAP_TIRED}}.
> Run attached test ({{ScanQueryStuff}}) and you will see with Visual VM that
> most of the time the test spends executing the code from system threads.
> Finally, what have to be done:
> - if ScanQuery is supposed to be executed locally (setPartition() refers to
> local partition or setLocal is set to true) then the calling application
> thread has to iterate over the data avoiding usage of the system pool;
> - internal code mustn't read all entries from a partition initially. The
> iterator has to get one entry next after another. This will be a memory
> backpressure mechanism especially for {{OFFHEAP_TIRED}}.
> My assumption is that the fixed version has to work in a similar way to
> iteration over local entries -
> {{cache.localEntries(CachePeekMode.PRIMARY);}}. Run attached
> {{LocalIteratorStuff}} to see with Visual VM that the application thread is
> fully utilized and system threads are idle.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2921) ScanQueries over local partitions are not optimal
[
https://issues.apache.org/jira/browse/IGNITE-2921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15239850#comment-15239850
]
Artem Shutak commented on IGNITE-2921:
--
Rewrote the first version of the fix in more consistent way, added events and
statistics support. Will check TC results and adding new tests. Still have
{{localEntries()}} performance better than scan query (will continue an
investigation).
> ScanQueries over local partitions are not optimal
> -
>
> Key: IGNITE-2921
> URL: https://issues.apache.org/jira/browse/IGNITE-2921
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Artem Shutak
>Priority: Blocker
> Labels: community, important, performance
> Fix For: 1.6
>
> Attachments: LocalIteratorStuff.java, ScanQueryStuff.java
>
>
> Presently scan queries over local partitions are not executed optimally.
> If to run a scan query over a specific partition (by setting
> {{query.setPartition(...)}} parameter and or {{query.setLocal(true)}}) and
> start iterating over entries we will see that the Thread, that iterates over
> the data, waits for some event to happen.
> In fact the Thread waits while a system pool's thread prepares an iterator
> with entries for it and only after that iterates over the returned result
> set. The flow looks this way:
> - {{GridCacheLocalQueryFuture}} is created;
> - when {{QueryCursor.iterator().next}} is called from the app thread (the
> Thread above), {{GridCacheLocalQueryFuture.execute()}} methods puts closure
> that will prepare content for the iterator in the system pool.
> - a system Thread execute {{GridCacheQueryManager.runQuery()}} reading all
> the entries from partition and passing them back to the Thread at line 1553
> by calling {{onPageReady(...)}} method.
> The other bottleneck is that a system thread gets all the entries and passes
> them to the Thread which will lead to more garbaged Java heap especially if
> cache is {{OFFHEAP_TIRED}}.
> Run attached test ({{ScanQueryStuff}}) and you will see with Visual VM that
> most of the time the test spends executing the code from system threads.
> Finally, what have to be done:
> - if ScanQuery is supposed to be executed locally (setPartition() refers to
> local partition or setLocal is set to true) then the calling application
> thread has to iterate over the data avoiding usage of the system pool;
> - internal code mustn't read all entries from a partition initially. The
> iterator has to get one entry next after another. This will be a memory
> backpressure mechanism especially for {{OFFHEAP_TIRED}}.
> My assumption is that the fixed version has to work in a similar way to
> iteration over local entries -
> {{cache.localEntries(CachePeekMode.PRIMARY);}}. Run attached
> {{LocalIteratorStuff}} to see with Visual VM that the application thread is
> fully utilized and system threads are idle.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2921) ScanQueries over local partitions are not optimal
[
https://issues.apache.org/jira/browse/IGNITE-2921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15239840#comment-15239840
]
Artem Shutak commented on IGNITE-2921:
--
PR: https://github.com/apache/ignite/pull/643
> ScanQueries over local partitions are not optimal
> -
>
> Key: IGNITE-2921
> URL: https://issues.apache.org/jira/browse/IGNITE-2921
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Artem Shutak
>Priority: Blocker
> Labels: community, important, performance
> Fix For: 1.6
>
> Attachments: LocalIteratorStuff.java, ScanQueryStuff.java
>
>
> Presently scan queries over local partitions are not executed optimally.
> If to run a scan query over a specific partition (by setting
> {{query.setPartition(...)}} parameter and or {{query.setLocal(true)}}) and
> start iterating over entries we will see that the Thread, that iterates over
> the data, waits for some event to happen.
> In fact the Thread waits while a system pool's thread prepares an iterator
> with entries for it and only after that iterates over the returned result
> set. The flow looks this way:
> - {{GridCacheLocalQueryFuture}} is created;
> - when {{QueryCursor.iterator().next}} is called from the app thread (the
> Thread above), {{GridCacheLocalQueryFuture.execute()}} methods puts closure
> that will prepare content for the iterator in the system pool.
> - a system Thread execute {{GridCacheQueryManager.runQuery()}} reading all
> the entries from partition and passing them back to the Thread at line 1553
> by calling {{onPageReady(...)}} method.
> The other bottleneck is that a system thread gets all the entries and passes
> them to the Thread which will lead to more garbaged Java heap especially if
> cache is {{OFFHEAP_TIRED}}.
> Run attached test ({{ScanQueryStuff}}) and you will see with Visual VM that
> most of the time the test spends executing the code from system threads.
> Finally, what have to be done:
> - if ScanQuery is supposed to be executed locally (setPartition() refers to
> local partition or setLocal is set to true) then the calling application
> thread has to iterate over the data avoiding usage of the system pool;
> - internal code mustn't read all entries from a partition initially. The
> iterator has to get one entry next after another. This will be a memory
> backpressure mechanism especially for {{OFFHEAP_TIRED}}.
> My assumption is that the fixed version has to work in a similar way to
> iteration over local entries -
> {{cache.localEntries(CachePeekMode.PRIMARY);}}. Run attached
> {{LocalIteratorStuff}} to see with Visual VM that the application thread is
> fully utilized and system threads are idle.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2921) ScanQueries over local partitions are not optimal
[
https://issues.apache.org/jira/browse/IGNITE-2921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15237723#comment-15237723
]
Artem Shutak commented on IGNITE-2921:
--
Did experimental fix (executing local query at user thread). Got performance
increase (about 2 times), but still worse than iteration through local entries
(about 2 times). Will investigate.
> ScanQueries over local partitions are not optimal
> -
>
> Key: IGNITE-2921
> URL: https://issues.apache.org/jira/browse/IGNITE-2921
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Artem Shutak
>Priority: Blocker
> Labels: community, important, performance
> Fix For: 1.6
>
> Attachments: LocalIteratorStuff.java, ScanQueryStuff.java
>
>
> Presently scan queries over local partitions are not executed optimally.
> If to run a scan query over a specific partition (by setting
> {{query.setPartition(...)}} parameter and or {{query.setLocal(true)}}) and
> start iterating over entries we will see that the Thread, that iterates over
> the data, waits for some event to happen.
> In fact the Thread waits while a system pool's thread prepares an iterator
> with entries for it and only after that iterates over the returned result
> set. The flow looks this way:
> - {{GridCacheLocalQueryFuture}} is created;
> - when {{QueryCursor.iterator().next}} is called from the app thread (the
> Thread above), {{GridCacheLocalQueryFuture.execute()}} methods puts closure
> that will prepare content for the iterator in the system pool.
> - a system Thread execute {{GridCacheQueryManager.runQuery()}} reading all
> the entries from partition and passing them back to the Thread at line 1553
> by calling {{onPageReady(...)}} method.
> The other bottleneck is that a system thread gets all the entries and passes
> them to the Thread which will lead to more garbaged Java heap especially if
> cache is {{OFFHEAP_TIRED}}.
> Run attached test ({{ScanQueryStuff}}) and you will see with Visual VM that
> most of the time the test spends executing the code from system threads.
> Finally, what have to be done:
> - if ScanQuery is supposed to be executed locally (setPartition() refers to
> local partition or setLocal is set to true) then the calling application
> thread has to iterate over the data avoiding usage of the system pool;
> - internal code mustn't read all entries from a partition initially. The
> iterator has to get one entry next after another. This will be a memory
> backpressure mechanism especially for {{OFFHEAP_TIRED}}.
> My assumption is that the fixed version has to work in a similar way to
> iteration over local entries -
> {{cache.localEntries(CachePeekMode.PRIMARY);}}. Run attached
> {{LocalIteratorStuff}} to see with Visual VM that the application thread is
> fully utilized and system threads are idle.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2921) ScanQueries over local partitions are not optimal
[
https://issues.apache.org/jira/browse/IGNITE-2921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15235726#comment-15235726
]
Artem Shutak commented on IGNITE-2921:
--
Started working on it.
Via VisualVM I see described in description behavior (with attached tests).
Going deep at code to say is it the root cause or not.
> ScanQueries over local partitions are not optimal
> -
>
> Key: IGNITE-2921
> URL: https://issues.apache.org/jira/browse/IGNITE-2921
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Artem Shutak
>Priority: Blocker
> Labels: community, important, performance
> Fix For: 1.6
>
> Attachments: LocalIteratorStuff.java, ScanQueryStuff.java
>
>
> Presently scan queries over local partitions are not executed optimally.
> If to run a scan query over a specific partition (by setting
> {{query.setPartition(...)}} parameter and or {{query.setLocal(true)}}) and
> start iterating over entries we will see that the Thread, that iterates over
> the data, waits for some event to happen.
> In fact the Thread waits while a system pool's thread prepares an iterator
> with entries for it and only after that iterates over the returned result
> set. The flow looks this way:
> - {{GridCacheLocalQueryFuture}} is created;
> - when {{QueryCursor.iterator().next}} is called from the app thread (the
> Thread above), {{GridCacheLocalQueryFuture.execute()}} methods puts closure
> that will prepare content for the iterator in the system pool.
> - a system Thread execute {{GridCacheQueryManager.runQuery()}} reading all
> the entries from partition and passing them back to the Thread at line 1553
> by calling {{onPageReady(...)}} method.
> The other bottleneck is that a system thread gets all the entries and passes
> them to the Thread which will lead to more garbaged Java heap especially if
> cache is {{OFFHEAP_TIRED}}.
> Run attached test ({{ScanQueryStuff}}) and you will see with Visual VM that
> most of the time the test spends executing the code from system threads.
> Finally, what have to be done:
> - if ScanQuery is supposed to be executed locally (setPartition() refers to
> local partition or setLocal is set to true) then the calling application
> thread has to iterate over the data avoiding usage of the system pool;
> - internal code mustn't read all entries from a partition initially. The
> iterator has to get one entry next after another. This will be a memory
> backpressure mechanism especially for {{OFFHEAP_TIRED}}.
> My assumption is that the fixed version has to work in a similar way to
> iteration over local entries -
> {{cache.localEntries(CachePeekMode.PRIMARY);}}. Run attached
> {{LocalIteratorStuff}} to see with Visual VM that the application thread is
> fully utilized and system threads are idle.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (IGNITE-2645) Assertion error in ATOMIC cachce for invokeAll and cache store
[ https://issues.apache.org/jira/browse/IGNITE-2645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artem Shutak closed IGNITE-2645. > Assertion error in ATOMIC cachce for invokeAll and cache store > -- > > Key: IGNITE-2645 > URL: https://issues.apache.org/jira/browse/IGNITE-2645 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: ignite-1.4 >Reporter: Alexey Goncharuk >Assignee: Artem Shutak > Labels: community > Fix For: 1.6 > > Attachments: EntryProcessorFails.java > > > Assertion happens under the following conditions: > * Cache is empty > * Cache store contains non-null values for some keys > * invokeAll is invoked for those keys > Update version is generated when update request reaches the primary node. > Then, we need to read-through stored values (the cache is empty) and pass > them to transformers. Since read-through changes entry version, subsequent > update fails with an assertion because read-through version is generated > later than update version. > The scenario when a read-through is implemented via a separate loop with > innerGet() is possible only with invokeAll() because this is the only > multi-key cache operation that requires the previous entry value. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-2645) Assertion error in ATOMIC cachce for invokeAll and cache store
[ https://issues.apache.org/jira/browse/IGNITE-2645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artem Shutak resolved IGNITE-2645. -- Resolution: Fixed Merged at master. > Assertion error in ATOMIC cachce for invokeAll and cache store > -- > > Key: IGNITE-2645 > URL: https://issues.apache.org/jira/browse/IGNITE-2645 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: ignite-1.4 >Reporter: Alexey Goncharuk >Assignee: Artem Shutak > Labels: community > Fix For: 1.6 > > Attachments: EntryProcessorFails.java > > > Assertion happens under the following conditions: > * Cache is empty > * Cache store contains non-null values for some keys > * invokeAll is invoked for those keys > Update version is generated when update request reaches the primary node. > Then, we need to read-through stored values (the cache is empty) and pass > them to transformers. Since read-through changes entry version, subsequent > update fails with an assertion because read-through version is generated > later than update version. > The scenario when a read-through is implemented via a separate loop with > innerGet() is possible only with invokeAll() because this is the only > multi-key cache operation that requires the previous entry value. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2645) Assertion error in ATOMIC cachce for invokeAll and cache store
[ https://issues.apache.org/jira/browse/IGNITE-2645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15235487#comment-15235487 ] Artem Shutak commented on IGNITE-2645: -- No, the situation described above can happen in many cases, for example after eviction of entry from cache (entry expired for example). But, honestly, I cannot imagine the case, when this inconsistency can broke something. Lets postpone a fix for it. > Assertion error in ATOMIC cachce for invokeAll and cache store > -- > > Key: IGNITE-2645 > URL: https://issues.apache.org/jira/browse/IGNITE-2645 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: ignite-1.4 >Reporter: Alexey Goncharuk >Assignee: Artem Shutak > Labels: community > Fix For: 1.6 > > Attachments: EntryProcessorFails.java > > > Assertion happens under the following conditions: > * Cache is empty > * Cache store contains non-null values for some keys > * invokeAll is invoked for those keys > Update version is generated when update request reaches the primary node. > Then, we need to read-through stored values (the cache is empty) and pass > them to transformers. Since read-through changes entry version, subsequent > update fails with an assertion because read-through version is generated > later than update version. > The scenario when a read-through is implemented via a separate loop with > innerGet() is possible only with invokeAll() because this is the only > multi-key cache operation that requires the previous entry value. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2899) BinaryObject is deserialized before getting passed to CacheInterceptor
[
https://issues.apache.org/jira/browse/IGNITE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15235134#comment-15235134
]
Artem Shutak commented on IGNITE-2899:
--
Filed an issue IGNITE-2973 for 1.3.
> 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
>Assignee: Artem Shutak
> Fix For: 1.6
>
> 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] [Created] (IGNITE-2973) CacheInterceptor gets mixed user and binary objects in case of 'withKeepBinary' cache and EntryProcessor which sets user object as a value
Artem Shutak created IGNITE-2973:
Summary: CacheInterceptor gets mixed user and binary objects in
case of 'withKeepBinary' cache and EntryProcessor which sets user object as a
value
Key: IGNITE-2973
URL: https://issues.apache.org/jira/browse/IGNITE-2973
Project: Ignite
Issue Type: Bug
Affects Versions: 1.5.0.final
Reporter: Artem Shutak
Methods of {{CacheInterceptor}} gets mixed user and binary objects as params in
case of {{withKeepBinary}} cache and if {{EntryProcessor}} sets user object as
a value.
{{Cache.withKeepBinary().invoke(..)}} and {{EntryProcessor}} which sets user
object as value (not {{BinaryObject}}). Then method
{{Interceptor.onBeforePut(Entry e, Object newVal)}} gets {{e.getKey()}} and
{{e.getValue()}} as {{BinaryObject}}, {{newVal}} as userObject (for ATOMIC
cache) or {{BinaryObject}} (for TRANSACTIONAL cache), but
{{Interceptor.onAfterPut(Entry e)}} gets {{e.getKey()}} as {{BinaryObject}} and
{{e.getValue}} as user object sometimes, but should be {{BinaryObject}}. The
issue can be reproduced only with Atomic cache.
I think it a little bit tricky to use such inconsistent API and not obvious for
user where they can get {{BinaryObject}} and where user object.
The same issue can be reproduces for {{invokeAll()}}.
Tests on these cases can be found at {{InterceptorWithKeepBinaryCacheTest}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (IGNITE-2191) Binary marshaller: support user classes with the same simple name
[ https://issues.apache.org/jira/browse/IGNITE-2191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artem Shutak closed IGNITE-2191. > Binary marshaller: support user classes with the same simple name > - > > Key: IGNITE-2191 > URL: https://issues.apache.org/jira/browse/IGNITE-2191 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: ignite-1.4 >Reporter: Denis Magda >Assignee: Artem Shutak >Priority: Critical > Labels: important > Fix For: 1.6 > > > Presently the user won't be able to use across the cluster object that have a > single simple name. > As an example if the user has 'org.comp.MyObject' and > 'org.apache.comp.MyObject' then he won't be able to have them both in a > cluster because marshalling mechanism supports uniqueness at simple name > level only. > There are several reasons for that: > - interoperability with other platforms; > - queries that use simple name is their 'where' clause. > In general according to the API as a workaround the user can implement its > own BinaryIdMapper returning a precise id for every class. However there is a > bug in BinaryContext that passes simple name rather than a full name to a > BinaryIdMapper implementation. BinaryIdMapper must be fixed as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2971) Assertion error inside OPTIMISTIC SERIALIZABLE tx on 'get'
[
https://issues.apache.org/jira/browse/IGNITE-2971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15235061#comment-15235061
]
Artem Shutak commented on IGNITE-2971:
--
Reproducible test can be found at InterceptorWithKeepBinaryCacheTestSuite
(looking for "TODO IGNITE-2971" at InterceptorWithKeepBinaryCacheTest).
> Assertion error inside OPTIMISTIC SERIALIZABLE tx on 'get'
> --
>
> Key: IGNITE-2971
> URL: https://issues.apache.org/jira/browse/IGNITE-2971
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Artem Shutak
> Fix For: 1.6
>
>
> The following code leads to assertion below:
> {code}
> final IgniteCache cache = jcache().withKeepBinary();
> Set keys = new LinkedHashSet() {{
> for (int i = 0; i < CNT; i++)
> add(key(i));
> }};
> try (Transaction tx =
> testedGrid().transactions().txStart(conc, isolation)) {
> for (final Object key : keys) {
> Object res = cache.invoke(key, NOOP_ENTRY_PROC);
> assertNull(res);
> assertNull(cache.get(key));
> }
> tx.commit();
> }
> {code}
> Assertion:
> {noformat}
> java.lang.AssertionError: Wrong version [serReadVer=GridCacheVersion
> [topVer=71859233, time=1460379235380, order=1460379231642, nodeOrder=5],
> ver=GridCacheVersion [topVer=71859233, time=1460379235380,
> order=1460379231642, nodeOrder=5]]
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxEntry.entryReadVersion(IgniteTxEntry.java:936)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter$3.apply(IgniteTxLocalAdapter.java:1750)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter$3.apply(IgniteTxLocalAdapter.java:1698)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.processLoaded(GridNearTxLocal.java:485)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.access$100(GridNearTxLocal.java:84)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$2.apply(GridNearTxLocal.java:380)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$2.apply(GridNearTxLocal.java:375)
> at
> org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:54)
> at
> org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:28)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:263)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListeners(GridFutureAdapter.java:251)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:381)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:347)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.onDone(GridPartitionedSingleGetFuture.java:727)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:324)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.setResult(GridPartitionedSingleGetFuture.java:634)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.onResult(GridPartitionedSingleGetFuture.java:478)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.processNearSingleGetResponse(GridDhtCacheAdapter.java:154)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.access$100(GridDhtColocatedCache.java:85)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache$3.apply(GridDhtColocatedCache.java:149)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache$3.apply(GridDhtColocatedCache.java:147)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:622)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:320)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:244)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:81)
> at
>
[jira] [Comment Edited] (IGNITE-2899) BinaryObject is deserialized before getting passed to CacheInterceptor
[
https://issues.apache.org/jira/browse/IGNITE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15234914#comment-15234914
]
Artem Shutak edited comment on IGNITE-2899 at 4/11/16 1:06 PM:
---
1. Investigated point 1. The issue happens under following conditions:
- User calls {{cache.withKeepBinary().invokeAll(...)}} inside explicite
transaction.
- {{EntryProcessor}} DOES NOT call entry.getKey() and returns non-null result.
- At this case Ignite will return map with keys as user objects instead of
{{BinaryObjects}}.
It happens because {{GridCacheReturn.addEntryProcessResult(...)}} deserializes
cache object before put to result map (in loc=true case). See
org/apache/ignite/internal/processors/cache/GridCacheReturn.java:246
2. Filed the separate issue for internal assert: IGNITE-2971.
was (Author: ashutak):
Investigated point 1. The issue happens under following conditions:
- User calls {{cache.withKeepBinary().invokeAll(...)}} inside explicite
transaction.
- {{EntryProcessor}} DOES NOT call entry.getKey() and returns non-null result.
- At this case Ignite will return map with keys as user objects instead of
{{BinaryObjects}}.
It happens because {{GridCacheReturn.addEntryProcessResult(...)}} deserializes
cache object before put to result map (in loc=true case). See
org/apache/ignite/internal/processors/cache/GridCacheReturn.java:246
> 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
>Assignee: Artem Shutak
> Fix For: 1.6
>
> 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)
>
[jira] [Created] (IGNITE-2971) Assertion error inside OPTIMISTIC SERIALIZABLE tx on 'get'
Artem Shutak created IGNITE-2971:
Summary: Assertion error inside OPTIMISTIC SERIALIZABLE tx on 'get'
Key: IGNITE-2971
URL: https://issues.apache.org/jira/browse/IGNITE-2971
Project: Ignite
Issue Type: Bug
Affects Versions: 1.5.0.final
Reporter: Artem Shutak
Fix For: 1.6
The following code leads to assertion below:
{code}
final IgniteCache cache = jcache().withKeepBinary();
Set keys = new LinkedHashSet() {{
for (int i = 0; i < CNT; i++)
add(key(i));
}};
try (Transaction tx = testedGrid().transactions().txStart(conc,
isolation)) {
for (final Object key : keys) {
Object res = cache.invoke(key, NOOP_ENTRY_PROC);
assertNull(res);
assertNull(cache.get(key));
}
tx.commit();
}
{code}
Assertion:
{noformat}
java.lang.AssertionError: Wrong version [serReadVer=GridCacheVersion
[topVer=71859233, time=1460379235380, order=1460379231642, nodeOrder=5],
ver=GridCacheVersion [topVer=71859233, time=1460379235380, order=1460379231642,
nodeOrder=5]]
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxEntry.entryReadVersion(IgniteTxEntry.java:936)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter$3.apply(IgniteTxLocalAdapter.java:1750)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter$3.apply(IgniteTxLocalAdapter.java:1698)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.processLoaded(GridNearTxLocal.java:485)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.access$100(GridNearTxLocal.java:84)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$2.apply(GridNearTxLocal.java:380)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$2.apply(GridNearTxLocal.java:375)
at
org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:54)
at
org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:28)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:263)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListeners(GridFutureAdapter.java:251)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:381)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:347)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.onDone(GridPartitionedSingleGetFuture.java:727)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:324)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.setResult(GridPartitionedSingleGetFuture.java:634)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.onResult(GridPartitionedSingleGetFuture.java:478)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.processNearSingleGetResponse(GridDhtCacheAdapter.java:154)
at
org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.access$100(GridDhtColocatedCache.java:85)
at
org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache$3.apply(GridDhtColocatedCache.java:149)
at
org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache$3.apply(GridDhtColocatedCache.java:147)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:622)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:320)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:244)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:81)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:203)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1219)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:847)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$1700(GridIoManager.java:105)
at
[jira] [Comment Edited] (IGNITE-2899) BinaryObject is deserialized before getting passed to CacheInterceptor
[
https://issues.apache.org/jira/browse/IGNITE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15234914#comment-15234914
]
Artem Shutak edited comment on IGNITE-2899 at 4/11/16 11:40 AM:
Investigated point 1. The issue happens under following conditions:
- User calls {{cache.withKeepBinary().invokeAll(...)}} inside explicite
transaction.
- {{EntryProcessor}} DOES NOT call entry.getKey() and returns non-null result.
- At this case Ignite will return map with keys as user objects instead of
{{BinaryObjects}}.
It happens because {{GridCacheReturn.addEntryProcessResult(...)}} deserializes
cache object before put to result map (in loc=true case). See
org/apache/ignite/internal/processors/cache/GridCacheReturn.java:246
was (Author: ashutak):
Investigated point 1. The issue happens under following conditions:
- User calls {{cache.withKeepBinary().invokeAll(...)}} inside explicite
transaction.
- {{EntryProcessor}} DOES NOT call entry.getKey() and returns non-null result.
- At this case Ignite will return map with keys as user objects instead of
{{BinaryObjects}}.
> 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
>Assignee: Artem Shutak
> Fix For: 1.6
>
> 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)
[jira] [Commented] (IGNITE-2899) BinaryObject is deserialized before getting passed to CacheInterceptor
[
https://issues.apache.org/jira/browse/IGNITE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15234914#comment-15234914
]
Artem Shutak commented on IGNITE-2899:
--
Investigated point 1. The issue happens under following conditions:
- User calls {{cache.withKeepBinary().invokeAll(...)}} inside explicite
transaction.
- {{EntryProcessor}} DOES NOT call entry.getKey() and returns non-null result.
- At this case Ignite will return map with keys as user objects instead of
{{BinaryObjects}}.
> 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
>Assignee: Artem Shutak
> Fix For: 1.6
>
> 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
>
[jira] [Commented] (IGNITE-2899) BinaryObject is deserialized before getting passed to CacheInterceptor
[
https://issues.apache.org/jira/browse/IGNITE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15232727#comment-15232727
]
Artem Shutak commented on IGNITE-2899:
--
Fixed new tx tests. Currently have 2 different failures.
# {{InvokeAll}} sometimes return keys as user objects instead of BinaryObjects
# {{Invoke}} fails on internal assert
> 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
>Assignee: Artem Shutak
> Fix For: 1.6
>
> 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
>
[jira] [Commented] (IGNITE-2645) Assertion error in ATOMIC cachce for invokeAll and cache store
[ https://issues.apache.org/jira/browse/IGNITE-2645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15232473#comment-15232473 ] Artem Shutak commented on IGNITE-2645: -- I discussed the Alexey's comment with him today and now I see the problem. 'putIfAbsent' will has the same issue. The following steps can be used to verify that the issue exists: 1. Put key-value pair at cache. 2. Clear the value for the key from primary node (backup node should still has the value). 3. Execute invoke operation, which doesn't change a value, just return something. 4. Check that entry version equals no primary and backup. Expected that now it fails here. At point 3, Ignite will read value from store (on innerGet), new entry version will be genarated, but as long as entry processor does not change the value, value will not be updated on backup node. I think, we should fix the issue in bounds of new jira. Thoughts? > Assertion error in ATOMIC cachce for invokeAll and cache store > -- > > Key: IGNITE-2645 > URL: https://issues.apache.org/jira/browse/IGNITE-2645 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: ignite-1.4 >Reporter: Alexey Goncharuk >Assignee: Artem Shutak > Labels: community > Fix For: 1.6 > > Attachments: EntryProcessorFails.java > > > Assertion happens under the following conditions: > * Cache is empty > * Cache store contains non-null values for some keys > * invokeAll is invoked for those keys > Update version is generated when update request reaches the primary node. > Then, we need to read-through stored values (the cache is empty) and pass > them to transformers. Since read-through changes entry version, subsequent > update fails with an assertion because read-through version is generated > later than update version. > The scenario when a read-through is implemented via a separate loop with > innerGet() is possible only with invokeAll() because this is the only > multi-key cache operation that requires the previous entry value. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2899) BinaryObject is deserialized before getting passed to CacheInterceptor
[
https://issues.apache.org/jira/browse/IGNITE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15230886#comment-15230886
]
Artem Shutak commented on IGNITE-2899:
--
Added tests on explicit transactions and got new failures.
> 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
>Assignee: Artem Shutak
> Fix For: 1.6
>
> 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-2899) BinaryObject is deserialized before getting passed to CacheInterceptor
[
https://issues.apache.org/jira/browse/IGNITE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15230611#comment-15230611
]
Artem Shutak commented on IGNITE-2899:
--
1.5 Fixed
2.1 Found a root cause.Did potential fix, but not sure that it's the best
solution. Need a review.
> 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
>Assignee: Artem Shutak
> Fix For: 1.6
>
> 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] [Comment Edited] (IGNITE-2959) Ignite JTA and WebSphere Application Server 8.5.5
[
https://issues.apache.org/jira/browse/IGNITE-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15230086#comment-15230086
]
Artem Shutak edited comment on IGNITE-2959 at 4/7/16 10:57 AM:
---
Under "poor WebSphere Application Server" I mean "ordinary" WS AS. The issue is
exactly about "ordinary" WS AS.
There is no issue with liberty profile and it works now. See issue description
to configure it properly.
was (Author: ashutak):
Under "poor WebSphere Application Server" I mean "ordinary" WS AS. The issue
exactly about "ordinary" WS AS.
There is no issue with liberty profile and it works now. See issue description
to configure it properly.
> Ignite JTA and WebSphere Application Server 8.5.5
> -
>
> Key: IGNITE-2959
> URL: https://issues.apache.org/jira/browse/IGNITE-2959
> Project: Ignite
> Issue Type: Task
>Reporter: Artem Shutak
>Assignee: Artem Shutak
> Labels: community, important
> Fix For: 1.6
>
>
> Need to support of working Ignite transactions inside WebSphere Application
> Server (8.5.5).
> The issue only about poor (ordinary) WebSphere Application Server.
> There is *no* issue with WebSphere Liberty. To enable JTA on WS Liberty it is
> enough to do the following.
> 1. add the following class in own libs:
> {code}
> public class WebSphereTmFactory implements Factory {
> /** {@inheritDoc} */
> @Override public TransactionManager create() {
> return
> com.ibm.tx.jta.TransactionManagerFactory.getTransactionManager();
> }
> }
> {code}
> 2. It's required the following maven dependencies:
> {code}
>
> com.ibm.websphere.appserver.api
>
> com.ibm.websphere.appserver.api.transaction
> 1.1.10
>
> {code}
> 3. And Ignite's TransactionConfiguration has to be properly configured with
> WebSphereTmFactory:
> {code}
> TransactionConfiguration tcfg = new TransactionConfiguration();
> TransactionConfiguration.setTxManagerFactory(new WebSphereTmFactory());
> igniteCfg.setTransactionConfiguration(tcfg)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-2959) Ignite JTA and WebSphere Application Server 8.5.5
[
https://issues.apache.org/jira/browse/IGNITE-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15230086#comment-15230086
]
Artem Shutak edited comment on IGNITE-2959 at 4/7/16 10:58 AM:
---
Under "poor WebSphere Application Server" I mean "ordinary" WS AS. The issue is
exactly about "ordinary" WS AS.
There is no issue with liberty profile and it already works. See issue
description to configure it properly.
was (Author: ashutak):
Under "poor WebSphere Application Server" I mean "ordinary" WS AS. The issue is
exactly about "ordinary" WS AS.
There is no issue with liberty profile and it works now. See issue description
to configure it properly.
> Ignite JTA and WebSphere Application Server 8.5.5
> -
>
> Key: IGNITE-2959
> URL: https://issues.apache.org/jira/browse/IGNITE-2959
> Project: Ignite
> Issue Type: Task
>Reporter: Artem Shutak
>Assignee: Artem Shutak
> Labels: community, important
> Fix For: 1.6
>
>
> Need to support of working Ignite transactions inside WebSphere Application
> Server (8.5.5).
> The issue only about poor (ordinary) WebSphere Application Server.
> There is *no* issue with WebSphere Liberty. To enable JTA on WS Liberty it is
> enough to do the following.
> 1. add the following class in own libs:
> {code}
> public class WebSphereTmFactory implements Factory {
> /** {@inheritDoc} */
> @Override public TransactionManager create() {
> return
> com.ibm.tx.jta.TransactionManagerFactory.getTransactionManager();
> }
> }
> {code}
> 2. It's required the following maven dependencies:
> {code}
>
> com.ibm.websphere.appserver.api
>
> com.ibm.websphere.appserver.api.transaction
> 1.1.10
>
> {code}
> 3. And Ignite's TransactionConfiguration has to be properly configured with
> WebSphereTmFactory:
> {code}
> TransactionConfiguration tcfg = new TransactionConfiguration();
> TransactionConfiguration.setTxManagerFactory(new WebSphereTmFactory());
> igniteCfg.setTransactionConfiguration(tcfg)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2959) Ignite JTA and WebSphere Application Server 8.5.5
[
https://issues.apache.org/jira/browse/IGNITE-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Artem Shutak updated IGNITE-2959:
-
Description:
Need to support of working Ignite transactions inside WebSphere Application
Server (8.5.5).
The issue only about poor (ordinary) WebSphere Application Server.
There is *no* issue with WebSphere Liberty. To enable JTA on WS Liberty it is
enough to do the following.
1. add the following class in own libs:
{code}
public class WebSphereTmFactory implements Factory {
/** {@inheritDoc} */
@Override public TransactionManager create() {
return com.ibm.tx.jta.TransactionManagerFactory.getTransactionManager();
}
}
{code}
2. It's required the following maven dependencies:
{code}
com.ibm.websphere.appserver.api
com.ibm.websphere.appserver.api.transaction
1.1.10
{code}
3. And Ignite's TransactionConfiguration has to be properly configured with
WebSphereTmFactory:
{code}
TransactionConfiguration tcfg = new TransactionConfiguration();
TransactionConfiguration.setTxManagerFactory(new WebSphereTmFactory());
igniteCfg.setTransactionConfiguration(tcfg)
{code}
was:
Need to support of working Ignite transactions inside WebSphere Application
Server (8.5.5).
The issue only about poor (ordinary) WebSphere Application Server.
To enable JTA on WS Liberty it is enough to do the following.
1. add the following class in own libs:
{code}
public class WebSphereTmFactory implements Factory {
/** {@inheritDoc} */
@Override public TransactionManager create() {
return com.ibm.tx.jta.TransactionManagerFactory.getTransactionManager();
}
}
{code}
2. It's required the following maven dependencies:
com.ibm.websphere.appserver.api
com.ibm.websphere.appserver.api.transaction
1.1.10
3. And Ignite's TransactionConfiguration has to be properly configured with
WebSphereTmFactory:
{code}
TransactionConfiguration tcfg = new TransactionConfiguration();
TransactionConfiguration.setTxManagerFactory(new WebSphereTmFactory());
igniteCfg.setTransactionConfiguration(tcfg)
{code}
> Ignite JTA and WebSphere Application Server 8.5.5
> -
>
> Key: IGNITE-2959
> URL: https://issues.apache.org/jira/browse/IGNITE-2959
> Project: Ignite
> Issue Type: Task
>Reporter: Artem Shutak
>Assignee: Artem Shutak
> Labels: community, important
> Fix For: 1.6
>
>
> Need to support of working Ignite transactions inside WebSphere Application
> Server (8.5.5).
> The issue only about poor (ordinary) WebSphere Application Server.
> There is *no* issue with WebSphere Liberty. To enable JTA on WS Liberty it is
> enough to do the following.
> 1. add the following class in own libs:
> {code}
> public class WebSphereTmFactory implements Factory {
> /** {@inheritDoc} */
> @Override public TransactionManager create() {
> return
> com.ibm.tx.jta.TransactionManagerFactory.getTransactionManager();
> }
> }
> {code}
> 2. It's required the following maven dependencies:
> {code}
>
> com.ibm.websphere.appserver.api
>
> com.ibm.websphere.appserver.api.transaction
> 1.1.10
>
> {code}
> 3. And Ignite's TransactionConfiguration has to be properly configured with
> WebSphereTmFactory:
> {code}
> TransactionConfiguration tcfg = new TransactionConfiguration();
> TransactionConfiguration.setTxManagerFactory(new WebSphereTmFactory());
> igniteCfg.setTransactionConfiguration(tcfg)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2959) Ignite JTA and WebSphere Application Server 8.5.5
[
https://issues.apache.org/jira/browse/IGNITE-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15230086#comment-15230086
]
Artem Shutak commented on IGNITE-2959:
--
Under "poor WebSphere Application Server" I mean "ordinary" WS AS. The issue
exactly about "ordinary" WS AS.
There is no issue with liberty profile and it works now. See issue description
to configure it properly.
> Ignite JTA and WebSphere Application Server 8.5.5
> -
>
> Key: IGNITE-2959
> URL: https://issues.apache.org/jira/browse/IGNITE-2959
> Project: Ignite
> Issue Type: Task
>Reporter: Artem Shutak
>Assignee: Artem Shutak
> Labels: community, important
> Fix For: 1.6
>
>
> Need to support of working Ignite transactions inside WebSphere Application
> Server (8.5.5).
> The issue only about poor (ordinary) WebSphere Application Server.
> To enable JTA on WS Liberty it is enough to do the following.
> 1. add the following class in own libs:
> {code}
> public class WebSphereTmFactory implements Factory {
> /** {@inheritDoc} */
> @Override public TransactionManager create() {
> return
> com.ibm.tx.jta.TransactionManagerFactory.getTransactionManager();
> }
> }
> {code}
> 2. It's required the following maven dependencies:
>
> com.ibm.websphere.appserver.api
>
> com.ibm.websphere.appserver.api.transaction
> 1.1.10
>
> 3. And Ignite's TransactionConfiguration has to be properly configured with
> WebSphereTmFactory:
> {code}
> TransactionConfiguration tcfg = new TransactionConfiguration();
> TransactionConfiguration.setTxManagerFactory(new WebSphereTmFactory());
> igniteCfg.setTransactionConfiguration(tcfg)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2959) Ignite JTA and WebSphere Application Server 8.5.5
[
https://issues.apache.org/jira/browse/IGNITE-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Artem Shutak updated IGNITE-2959:
-
Description:
Need to support of working Ignite transactions inside WebSphere Application
Server (8.5.5).
The issue only about poor (ordinary) WebSphere Application Server.
To enable JTA on WS Liberty it is enough to do the following.
1. add the following class in own libs:
{code}
public class WebSphereTmFactory implements Factory {
/** {@inheritDoc} */
@Override public TransactionManager create() {
return com.ibm.tx.jta.TransactionManagerFactory.getTransactionManager();
}
}
{code}
2. It's required the following maven dependencies:
com.ibm.websphere.appserver.api
com.ibm.websphere.appserver.api.transaction
1.1.10
3. And Ignite's TransactionConfiguration has to be properly configured with
WebSphereTmFactory:
{code}
TransactionConfiguration tcfg = new TransactionConfiguration();
TransactionConfiguration.setTxManagerFactory(new WebSphereTmFactory());
igniteCfg.setTransactionConfiguration(tcfg)
{code}
was:
Need to support of working Ignite transactions inside WebSphere Application
Server (8.5.5).
The issue only about poor WS AS.
To enable JTA on WS Liberty it is enough to do the following.
1. add the following class in own libs:
{code}
public class WebSphereTmFactory implements Factory {
/** {@inheritDoc} */
@Override public TransactionManager create() {
return com.ibm.tx.jta.TransactionManagerFactory.getTransactionManager();
}
}
{code}
2. It's required the following maven dependencies:
com.ibm.websphere.appserver.api
com.ibm.websphere.appserver.api.transaction
1.1.10
3. And Ignite's TransactionConfiguration has to be properly configured with
WebSphereTmFactory:
{code}
TransactionConfiguration tcfg = new TransactionConfiguration();
TransactionConfiguration.setTxManagerFactory(new WebSphereTmFactory());
igniteCfg.setTransactionConfiguration(tcfg)
{code}
> Ignite JTA and WebSphere Application Server 8.5.5
> -
>
> Key: IGNITE-2959
> URL: https://issues.apache.org/jira/browse/IGNITE-2959
> Project: Ignite
> Issue Type: Task
>Reporter: Artem Shutak
>Assignee: Artem Shutak
> Labels: community, important
> Fix For: 1.6
>
>
> Need to support of working Ignite transactions inside WebSphere Application
> Server (8.5.5).
> The issue only about poor (ordinary) WebSphere Application Server.
> To enable JTA on WS Liberty it is enough to do the following.
> 1. add the following class in own libs:
> {code}
> public class WebSphereTmFactory implements Factory {
> /** {@inheritDoc} */
> @Override public TransactionManager create() {
> return
> com.ibm.tx.jta.TransactionManagerFactory.getTransactionManager();
> }
> }
> {code}
> 2. It's required the following maven dependencies:
>
> com.ibm.websphere.appserver.api
>
> com.ibm.websphere.appserver.api.transaction
> 1.1.10
>
> 3. And Ignite's TransactionConfiguration has to be properly configured with
> WebSphereTmFactory:
> {code}
> TransactionConfiguration tcfg = new TransactionConfiguration();
> TransactionConfiguration.setTxManagerFactory(new WebSphereTmFactory());
> igniteCfg.setTransactionConfiguration(tcfg)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (IGNITE-2959) Ignite JTA and WebSphere Application Server 8.5.5
[
https://issues.apache.org/jira/browse/IGNITE-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Artem Shutak reassigned IGNITE-2959:
Assignee: Artem Shutak
> Ignite JTA and WebSphere Application Server 8.5.5
> -
>
> Key: IGNITE-2959
> URL: https://issues.apache.org/jira/browse/IGNITE-2959
> Project: Ignite
> Issue Type: Task
>Reporter: Artem Shutak
>Assignee: Artem Shutak
> Fix For: 1.6
>
>
> Need to support of working Ignite transactions inside WebSphere Application
> Server (8.5.5).
> The issue only about poor WS AS.
> To enable JTA on WS Liberty it is enough to do the following.
> 1. add the following class in own libs:
> {code}
> public class WebSphereTmFactory implements Factory {
> /** {@inheritDoc} */
> @Override public TransactionManager create() {
> return
> com.ibm.tx.jta.TransactionManagerFactory.getTransactionManager();
> }
> }
> {code}
> 2. It's required the following maven dependencies:
>
> com.ibm.websphere.appserver.api
>
> com.ibm.websphere.appserver.api.transaction
> 1.1.10
>
> 3. And Ignite's TransactionConfiguration has to be properly configured with
> WebSphereTmFactory:
> {code}
> TransactionConfiguration tcfg = new TransactionConfiguration();
> TransactionConfiguration.setTxManagerFactory(new WebSphereTmFactory());
> igniteCfg.setTransactionConfiguration(tcfg)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2959) Ignite JTA and WebSphere Application Server 8.5.5
[
https://issues.apache.org/jira/browse/IGNITE-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Artem Shutak updated IGNITE-2959:
-
Fix Version/s: 1.6
> Ignite JTA and WebSphere Application Server 8.5.5
> -
>
> Key: IGNITE-2959
> URL: https://issues.apache.org/jira/browse/IGNITE-2959
> Project: Ignite
> Issue Type: Bug
>Reporter: Artem Shutak
> Fix For: 1.6
>
>
> Need to support of working Ignite transactions inside WebSphere Application
> Server (8.5.5).
> The issue only about poor WS AS.
> To enable JTA on WS Liberty it is enough to do the following.
> 1. add the following class in own libs:
> {code}
> public class WebSphereTmFactory implements Factory {
> /** {@inheritDoc} */
> @Override public TransactionManager create() {
> return
> com.ibm.tx.jta.TransactionManagerFactory.getTransactionManager();
> }
> }
> {code}
> 2. It's required the following maven dependencies:
>
> com.ibm.websphere.appserver.api
>
> com.ibm.websphere.appserver.api.transaction
> 1.1.10
>
> 3. And Ignite's TransactionConfiguration has to be properly configured with
> WebSphereTmFactory:
> {code}
> TransactionConfiguration tcfg = new TransactionConfiguration();
> TransactionConfiguration.setTxManagerFactory(new WebSphereTmFactory());
> igniteCfg.setTransactionConfiguration(tcfg)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-2959) Ignite JTA and WebSphere Application Server 8.5.5
Artem Shutak created IGNITE-2959:
Summary: Ignite JTA and WebSphere Application Server 8.5.5
Key: IGNITE-2959
URL: https://issues.apache.org/jira/browse/IGNITE-2959
Project: Ignite
Issue Type: Bug
Reporter: Artem Shutak
Need to support of working Ignite transactions inside WebSphere Application
Server (8.5.5).
The issue only about poor WS AS.
To enable JTA on WS Liberty it is enough to do the following.
1. add the following class in own libs:
{code}
public class WebSphereTmFactory implements Factory {
/** {@inheritDoc} */
@Override public TransactionManager create() {
return com.ibm.tx.jta.TransactionManagerFactory.getTransactionManager();
}
}
{code}
2. It's required the following maven dependencies:
com.ibm.websphere.appserver.api
com.ibm.websphere.appserver.api.transaction
1.1.10
3. And Ignite's TransactionConfiguration has to be properly configured with
WebSphereTmFactory:
{code}
TransactionConfiguration tcfg = new TransactionConfiguration();
TransactionConfiguration.setTxManagerFactory(new WebSphereTmFactory());
igniteCfg.setTransactionConfiguration(tcfg)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2953) Wrong marshalling and unmarshalling of invoke result with BinaryMarshaller
[
https://issues.apache.org/jira/browse/IGNITE-2953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Artem Shutak updated IGNITE-2953:
-
Description:
When {{CacheEntryProcessor.process()}} method called on remote node, then
Ignite will serialize result of {{CacheEntryProcessor.process()}} to
{{BinaryObject}} and then the {{BinaryObject}} will be deserialized or not on
local node (which called invoke/invokeAll) depending on {{keepBinary}} flag of
current operation ({{cache.withKeepBinary()}} or not).
It's wrong behaviour for both withKeepBinary cache and not.
Lets look at the following use cases with invoke/invokeAll and BinaryMarshaller:
# Cache.withKeepBinary
#- {{CacheEntryProcessor.process()}} returns any user object (not BinaryObject)
#- at this case user will get mixed user objects and {{BinaryObjects}}
depending on what node processing was done (local and remote)
# Cache without withKeepBinary
#- {{CacheEntryProcessor.process()}} returns {{BinaryObject}} builded like
{{ignite.binary().builder("MyObj").build()}}
#- at this case user will get exception because Ignite will try deseriallize
{{BinaryObject}}.
Looks like we need to add one more flag at {{GridCacheReturn}} message to
detect whether result should be converted from binary object or not (see
org/apache/ignite/internal/processors/cache/GridCacheReturn.java:334,
org/apache/ignite/internal/processors/cache/CacheInvokeDirectResult.java:91).
was:
When {{CacheEntryProcessor.process()}} method called on remote node, then
Ignite will serialize result of {{CacheEntryProcessor.process()}} to
{{BinaryObject}} and then the {{BinaryObject}} will be deserialized or not on
local node (which called invoke/invokeAll) depending on {{keepBinary}} flag of
current operation ({{cache.withKeepBinary()}} or not).
It's wrong behaviour for both withKeepBinary cache and not.
Lets look at the following use caseы with invoke/invokeAll and BinaryMarshaller:
# Cache.withKeepBinary
#- {{CacheEntryProcessor.process()}} returns any user object (not BinaryObject)
#- at this case user will get mixed user objects and {{BinaryObjects}}
depending on what node processing was done (local and remote)
# Cache without withKeepBinary
#- {{CacheEntryProcessor.process()}} returns {{BinaryObject}} builded like
{{ignite.binary().builder("MyObj").build()}}
#- at this case user will get exception because Ignite will try deseriallize
{{BinaryObject}}.
Looks like we need to add one more flag at {{GridCacheReturn}} message to
detect whether result should be converted from binary object or not (see
org/apache/ignite/internal/processors/cache/GridCacheReturn.java:334,
org/apache/ignite/internal/processors/cache/CacheInvokeDirectResult.java:91).
> Wrong marshalling and unmarshalling of invoke result with BinaryMarshaller
> --
>
> Key: IGNITE-2953
> URL: https://issues.apache.org/jira/browse/IGNITE-2953
> Project: Ignite
> Issue Type: Bug
>Reporter: Artem Shutak
>
> When {{CacheEntryProcessor.process()}} method called on remote node, then
> Ignite will serialize result of {{CacheEntryProcessor.process()}} to
> {{BinaryObject}} and then the {{BinaryObject}} will be deserialized or not on
> local node (which called invoke/invokeAll) depending on {{keepBinary}} flag
> of current operation ({{cache.withKeepBinary()}} or not).
> It's wrong behaviour for both withKeepBinary cache and not.
> Lets look at the following use cases with invoke/invokeAll and
> BinaryMarshaller:
> # Cache.withKeepBinary
> #- {{CacheEntryProcessor.process()}} returns any user object (not
> BinaryObject)
> #- at this case user will get mixed user objects and {{BinaryObjects}}
> depending on what node processing was done (local and remote)
> # Cache without withKeepBinary
> #- {{CacheEntryProcessor.process()}} returns {{BinaryObject}} builded like
> {{ignite.binary().builder("MyObj").build()}}
> #- at this case user will get exception because Ignite will try deseriallize
> {{BinaryObject}}.
> Looks like we need to add one more flag at {{GridCacheReturn}} message to
> detect whether result should be converted from binary object or not (see
> org/apache/ignite/internal/processors/cache/GridCacheReturn.java:334,
> org/apache/ignite/internal/processors/cache/CacheInvokeDirectResult.java:91).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2953) Wrong marshalling and unmarshalling of invoke result with BinaryMarshaller
[
https://issues.apache.org/jira/browse/IGNITE-2953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15228022#comment-15228022
]
Artem Shutak commented on IGNITE-2953:
--
Tests on withKeepBinary case already exist. See
InterceptorWithKeepBinaryCacheTestSuite or looking for IGNITE-2953 at project.
> Wrong marshalling and unmarshalling of invoke result with BinaryMarshaller
> --
>
> Key: IGNITE-2953
> URL: https://issues.apache.org/jira/browse/IGNITE-2953
> Project: Ignite
> Issue Type: Bug
>Reporter: Artem Shutak
>
> When {{CacheEntryProcessor.process()}} method called on remote node, then
> Ignite will serialize result of {{CacheEntryProcessor.process()}} to
> {{BinaryObject}} and then the {{BinaryObject}} will be deserialized or not on
> local node (which called invoke/invokeAll) depending on {{keepBinary}} flag
> of current operation ({{cache.withKeepBinary()}} or not).
> It's wrong behaviour for both withKeepBinary cache and not.
> Lets look at the following use caseы with invoke/invokeAll and
> BinaryMarshaller:
> # Cache.withKeepBinary
> #- {{CacheEntryProcessor.process()}} returns any user object (not
> BinaryObject)
> #- at this case user will get mixed user objects and {{BinaryObjects}}
> depending on what node processing was done (local and remote)
> # Cache without withKeepBinary
> #- {{CacheEntryProcessor.process()}} returns {{BinaryObject}} builded like
> {{ignite.binary().builder("MyObj").build()}}
> #- at this case user will get exception because Ignite will try deseriallize
> {{BinaryObject}}.
> Looks like we need to add one more flag at {{GridCacheReturn}} message to
> detect whether result should be converted from binary object or not (see
> org/apache/ignite/internal/processors/cache/GridCacheReturn.java:334,
> org/apache/ignite/internal/processors/cache/CacheInvokeDirectResult.java:91).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-2899) BinaryObject is deserialized before getting passed to CacheInterceptor
[
https://issues.apache.org/jira/browse/IGNITE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15226700#comment-15226700
]
Artem Shutak edited comment on IGNITE-2899 at 4/6/16 9:27 AM:
--
1.4.1 fixed.
1.4.2 Looks like we need to add one more flag at {{GridCacheReturn}} message to
detect whether result should be converted from binary object or not (see
org/apache/ignite/internal/processors/cache/GridCacheReturn.java:334). Filed an
issue IGNITE-2953.
was (Author: ashutak):
1.4.1 fixed.
1.4.2 Looks like we need to add one more flag at {{GridCacheReturn}} message to
detect whether result should be converted from binary object or not (see
org/apache/ignite/internal/processors/cache/GridCacheReturn.java:334).
> 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
>Assignee: Artem Shutak
> Fix For: 1.6
>
> 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"
>
[jira] [Commented] (IGNITE-2953) Wrong marshalling and unmarshalling of invoke result with BinaryMarshaller
[ https://issues.apache.org/jira/browse/IGNITE-2953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15227976#comment-15227976 ] Artem Shutak commented on IGNITE-2953: -- Found in process of working on IGNITE-2899. > Wrong marshalling and unmarshalling of invoke result with BinaryMarshaller > -- > > Key: IGNITE-2953 > URL: https://issues.apache.org/jira/browse/IGNITE-2953 > Project: Ignite > Issue Type: Bug >Reporter: Artem Shutak > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2953) Wrong marshalling and unmarshalling of invoke result with BinaryMarshaller
[ https://issues.apache.org/jira/browse/IGNITE-2953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artem Shutak updated IGNITE-2953: - Summary: Wrong marshalling and unmarshalling of invoke result with BinaryMarshaller (was: tra marshalling and unmarshalling of invoke result with BinaryMarshaller) > Wrong marshalling and unmarshalling of invoke result with BinaryMarshaller > -- > > Key: IGNITE-2953 > URL: https://issues.apache.org/jira/browse/IGNITE-2953 > Project: Ignite > Issue Type: Bug >Reporter: Artem Shutak > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2953) tra marshalling and unmarshalling of invoke result with BinaryMarshaller
Artem Shutak created IGNITE-2953: Summary: tra marshalling and unmarshalling of invoke result with BinaryMarshaller Key: IGNITE-2953 URL: https://issues.apache.org/jira/browse/IGNITE-2953 Project: Ignite Issue Type: Bug Reporter: Artem Shutak -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2835) BinaryObjectOffHeapImpl leaked to public code
[
https://issues.apache.org/jira/browse/IGNITE-2835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15224617#comment-15224617
]
Artem Shutak commented on IGNITE-2835:
--
Added tests as advised on review. Waiting for TC.
> BinaryObjectOffHeapImpl leaked to public code
> -
>
> Key: IGNITE-2835
> URL: https://issues.apache.org/jira/browse/IGNITE-2835
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Artem Shutak
>Priority: Critical
> Labels: community, important
> Fix For: 1.6
>
> Attachments: BinaryObjectOffHeapIssue.java
>
>
> To my knowledge {{BinaryObjectOffHeapImpl}} is considered to be used under
> some internal lock only to prevent possible offheap pointer movement.
> However seems that we made it available to public code. If to start a
> partitioned cache in {{OFFHEAP_TIRED}} mode, get {{BinaryObject}} from the
> cache inside of a TX and put the same object back we will get exception like
> below
> {noformat}
> [15:00:00,892][WARN ][main][GridNearTxLocal] Set transaction invalidation
> flag to true due to error [tx=GridNearTxLocal [mappings=IgniteTxMappingsImpl
> [], nearLocallyMapped=false, colocatedLocallyMapped=true,
> needCheckBackup=null, hasRemoteLocks=false, mappings=IgniteTxMappingsImpl [],
> super=GridDhtTxLocalAdapter [nearOnOriginatingNode=false, nearNodes=[],
> dhtNodes=[], explicitLock=false, super=IgniteTxLocalAdapter
> [completedBase=null, sndTransformedVals=false, depEnabled=false,
> txState=IgniteTxStateImpl [activeCacheIds=GridLongList [idx=1,
> arr=[-1206548976]], txMap={IgniteTxKey [key=KeyCacheObjectImpl [val=0,
> hasValBytes=true], cacheId=-1206548976]=IgniteTxEntry [key=KeyCacheObjectImpl
> [val=0, hasValBytes=true], cacheId=-1206548976, txKey=IgniteTxKey
> [key=KeyCacheObjectImpl [val=0, hasValBytes=true], cacheId=-1206548976],
> val=[op=UPDATE, val=SomeType [idHash=1337835760, hash=0, field2=name_0,
> field1=0]], prevVal=[op=UPDATE, val=SomeType [idHash=1337835760, hash=0,
> field2=name_0, field1=0]], entryProcessorsCol=null, ttl=-1,
> conflictExpireTime=-1, conflictVer=null, explicitVer=null,
> dhtVer=GridCacheVersion [topVer=69523200, nodeOrderDrId=1,
> globalTime=1458043200871, order=1458043167489], filters=[],
> filtersPassed=false, filtersSet=true, entry=GridDhtColocatedCacheEntry
> [super=GridDhtCacheEntry [rdrs=[], locPart=GridDhtLocalPartition [id=0,
> mapPubSize=0, rmvQueue=GridCircularBuffer [sizeMask=255, idxGen=1], cntr=1,
> state=OWNING, reservations=0, empty=true, createTime=03/15/2016 15:00:00,
> mapPubSize=0], super=GridDistributedCacheEntry [super=GridCacheMapEntry
> [key=KeyCacheObjectImpl [val=0, hasValBytes=true], val=null,
> startVer=1458043167488, ver=GridCacheVersion [topVer=69523200,
> nodeOrderDrId=1, globalTime=1458043200890, order=1458043167490],
> hash=-1484017934, extras=GridCacheObsoleteEntryExtras
> [obsoleteVer=GridCacheVersion [topVer=69523200, nodeOrderDrId=1,
> globalTime=1458043200890, order=1458043167491]], flags=7, prepared=false,
> locked=true, nodeId=993f5733-b014-4a5b-a6d1-934aeec9e9f5, locMapped=false,
> expiryPlc=null, transferExpiryPlc=false, flags=2, partUpdateCntr=0,
> serReadVer=null, xidVer=GridCacheVersion [topVer=69523200, nodeOrderDrId=1,
> globalTime=1458043200852, order=1458043167487]]}], super=IgniteTxAdapter
> [xidVer=GridCacheVersion [topVer=69523200, nodeOrderDrId=1,
> globalTime=1458043200852, order=1458043167487], writeVer=GridCacheVersion
> [topVer=69523200, nodeOrderDrId=1, globalTime=1458043200871,
> order=1458043167489], implicit=false, loc=true, threadId=1,
> startTime=1458043200850, nodeId=993f5733-b014-4a5b-a6d1-934aeec9e9f5,
> startVer=GridCacheVersion [topVer=69523200, nodeOrderDrId=1,
> globalTime=1458043200852, order=1458043167487], endVer=null,
> isolation=REPEATABLE_READ, concurrency=PESSIMISTIC, timeout=0,
> sysInvalidate=true, sys=false, plc=2, commitVer=GridCacheVersion
> [topVer=69523200, nodeOrderDrId=1, globalTime=1458043200852,
> order=1458043167487], finalizing=NONE, preparing=false, invalidParts=null,
> state=UNKNOWN, timedOut=false, topVer=AffinityTopologyVersion [topVer=1,
> minorTopVer=1], duration=40ms, onePhaseCommit=true], size=1]]], err=class
> o.a.i.i.transactions.IgniteTxHeuristicCheckedException: Failed to locally
> write to cache (all transaction entries will be invalidated, however there
> was a window when entries for this transaction were visible to others):
> GridNearTxLocal [mappings=IgniteTxMappingsImpl [], nearLocallyMapped=false,
> colocatedLocallyMapped=true, needCheckBackup=null, hasRemoteLocks=false,
> mappings=IgniteTxMappingsImpl [], super=GridDhtTxLocalAdapter
> [nearOnOriginatingNode=false, nearNodes=[], dhtNodes=[],
[jira] [Comment Edited] (IGNITE-2899) BinaryObject is deserialized before getting passed to CacheInterceptor
[
https://issues.apache.org/jira/browse/IGNITE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15221719#comment-15221719
]
Artem Shutak edited comment on IGNITE-2899 at 4/4/16 1:19 PM:
--
h4. Found more bugs in process of testing. In process of working on the issue I
faces with the following issues *{{withKeepBinary}}* related issues (including
issues described above):
1.1. {{BinaryOffheapValue}} leaks to {{EntryProcessor}}'s user code via
{{entry.getValue()}}. The issue happens under the following conditions:
- invokeAll operation
- ATOMIC cache in OFFHEAP_TIRED data mode
I will fix it for both {{getValue()}} and {{getKey()}}. Actually I cannot
imagine a case when {{getKey()}} can return offheap value, but to be sure I
think we should fix it as well.
1.2.We have inconsistency for {{IgniteCache.getEntry()}} and
{{IgniteCache.getEntries()}}: key of entry returned by first method is the same
entry which user set to method, so it can be user object, but keys of entries
of second method is {{BinaryObject}}.
Will fix {{getEntry().getKey()}} to return {{BinaryObject}}.
1.3. {{invoke}} and {{EntryProcessor}} which sets user object as value (not
{{BinaryObject}}). Then method {{Interceptor.onBeforePut(Entry e, Object
newVal)}} gets {{e.getKey()}} and {{e.getValue()}} as {{BinaryObject}},
{{newVal}} as userObject (for ATOMIC cache) or {{BinaryObject}} (for
TRANSACTIONAL cache), but {{Interceptor.onAfterPut(Entry e)}} gets
{{e.getKey()}} as {{BinaryObject}} and {{e.getValue}} as user object sometimes,
but should be {{BinaryObject}}. The issue can be reproduced only with Atomic
cache.
I think it a little bit tricky to use such inconsistent API and not obvious for
user where they can get {{BinaryObject}} and where user object.
The same issue can be reproduces for {{invokeAll()}}.
1.4 Not-interceptor-related issues with {{invokeAll}}:
1.4.1 {{invokeAll}} returns result map which contains mixed {{BinaryObject}}s
and user objects keys. I guess, that we get user objects keys if that keys
processed on local node.
1.4.2 {{invokeAll}} wraps result of {{CacheEntryProcessor.process()}} in
{{BinaryObject}} (for remote nodes). Why? I think user should get exactly the
same result as {{process}} method returns.
1.5 Not-interceptor-related issues with {{invoke}} on client node with Near
cache. {{Cache.withKeepBinary().get()}} returns {{null}} after successful
{{put}}/{{invoke}} as long as {{get()}} for normal cache gets value as well.
h4. The following issue related to *basic cache* (not keep binary) and
intercepror:
2.1. I was added {{InterceptorCacheConfigVariationsFullApiTestSuite}}, which
runs {{IgniteCacheConfigVariationsFullApiTest}} with enabled interceptor. The
interceptor just checks that keys and values are not {{BinaryObject}}.
Faced that in some cases Ignite cannot unmarshall binary object to get value at
interceptor (issue with enum).
{noformat}
Suppressed: class org.apache.ignite.IgniteCheckedException: Failed to
update keys on primary node.
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateResponse.addFailedKeys(GridNearAtomicUpdateResponse.java:369)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1508)
... 22 more
Suppressed: class org.apache.ignite.binary.BinaryObjectException:
Failed to get enum value for ordinal (do you have correct class version?)
[cls=org.apache.ignite.testframework.junits.IgniteConfigVariationsAbstractTest$TestEnum,
ordinal=9437186, totalValues=3]
at
org.apache.ignite.internal.binary.BinaryEnumCache.get(BinaryEnumCache.java:56)
at
org.apache.ignite.internal.binary.BinaryUtils.doReadEnum(BinaryUtils.java:1516)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.readEnum0(BinaryReaderExImpl.java:1163)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.readEnum(BinaryReaderExImpl.java:1140)
at
org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.readFixedType(BinaryFieldAccessor.java:812)
at
org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read(BinaryFieldAccessor.java:639)
at
org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:735)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1449)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:542)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:117)
at
org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinary(CacheObjectContext.java:257)
at
[jira] [Updated] (IGNITE-967) Internal thread locals are not always cleaned
[
https://issues.apache.org/jira/browse/IGNITE-967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Artem Shutak updated IGNITE-967:
Assignee: (was: Artem Shutak)
> Internal thread locals are not always cleaned
> -
>
> Key: IGNITE-967
> URL: https://issues.apache.org/jira/browse/IGNITE-967
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: sprint-4
>Reporter: Valentin Kulichenko
>Priority: Critical
> Labels: important
> Fix For: 1.6
>
>
> One of our users reported that he sees warnings in Tomcat's log when the
> application that's running Ignite in embedded mode is undeployed:
> {code}
> SEVERE: The web application [/XXX] created a ThreadLocal with key of type
> [org.apache.ignite.internal.util.GridSpinReadWriteLock$1] (value
> [org.apache.ignite.internal.util.GridSpinReadWriteLock$1@2c2858af]) and a
> value of type [java.lang.Integer] (value [0]) but failed to remove it when
> the web application was stopped. Threads are going to be renewed over time to
> try and avoid a probable memory leak.
> {code}
> There is also the similar warning for {{GridToStringBuilder.threadCache}}.
> While it's usually OK not to clean thread locals on standalone node, in app
> server it can cause a memory leak.
> To avoid such issues I suggest to add a special step after all test suites
> that will check thread locals in test runner thread. If we have this check in
> CI, we will fix it once and for always.
> Thread local values can be introspected through {{Thread.threadLocals}}
> variable. It would also be a good idea to check Tomcat's sources on how it's
> done there.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-2899) BinaryObject is deserialized before getting passed to CacheInterceptor
[
https://issues.apache.org/jira/browse/IGNITE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15221719#comment-15221719
]
Artem Shutak edited comment on IGNITE-2899 at 4/1/16 4:55 PM:
--
h4. Found more bugs in process of testing. In process of working on the issue I
faces with the following issues *{{withKeepBinary}}* related issues (including
issues described above):
1.1. {{BinaryOffheapValue}} leaks to {{EntryProcessor}}'s user code via
{{entry.getValue()}}. The issue happens under the following conditions:
- invokeAll operation
- ATOMIC cache in OFFHEAP_TIRED data mode
I will fix it for both {{getValue()}} and {{getKey()}}. Actually I cannot
imagine a case when {{getKey()}} can return offheap value, but to be sure I
think we should fix it as well.
1.2.We have inconsistency for {{IgniteCache.getEntry()}} and
{{IgniteCache.getEntries()}}: key of entry returned by first method is the same
entry which user set to method, so it can be user object, but keys of entries
of second method is {{BinaryObject}}.
Will fix {{getEntry().getKey()}} to return {{BinaryObject}}.
1.3. {{invoke}} and {{EntryProcessor}} which sets user object as value (not
{{BinaryObject}}). Then method {{Interceptor.onBeforePut(Entry e, Object
newVal)}} gets {{e.getKey()}} and {{e.getValue()}} as {{BinaryObject}},
{{newVal}} as userObject (for ATOMIC cache) or {{BinaryObject}} (for
TRANSACTIONAL cache), but {{Interceptor.onAfterPut(Entry e)}} gets
{{e.getKey()}} as {{BinaryObject}} and {{e.getValue}} as user object sometimes,
but should be {{BinaryObject}}. The issue can be reproduced only with Atomic
cache.
I think it a little bit tricky to use such inconsistent API and not obvious for
user where they can get {{BinaryObject}} and where user object.
The same issue can be reproduces for {{invokeAll()}}.
1.4 Not-interceptor-related issues with {{invokeAll}}:
1.4.1 {{invokeAll}} returns result map which contains mixed {{BinaryObject}}s
and user objects keys. I guess, that we get user objects keys if that keys
processed on local node.
1.4.2 {{invokeAll}} wraps result of {{CacheEntryProcessor.process()}} in
{{BinaryObject}} (for remote nodes). Why? I think user should get exactly the
same result as {{process}} method returns.
1.5 Not-interceptor-related issues with {{invoke}} on client node with Near
cache. {{Cache.withKeepBinary().get()}} returns {{null}} after successful
{{invoke}} as long as {{get()}} for normal cache gets value as well.
h4. The following issue related to *basic cache* (not keep binary) and
intercepror:
2.1. I was added {{InterceptorCacheConfigVariationsFullApiTestSuite}}, which
runs {{IgniteCacheConfigVariationsFullApiTest}} with enabled interceptor. The
interceptor just checks that keys and values are not {{BinaryObject}}.
Faced that in some cases Ignite cannot unmarshall binary object to get value at
interceptor (issue with enum).
{noformat}
Suppressed: class org.apache.ignite.IgniteCheckedException: Failed to
update keys on primary node.
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateResponse.addFailedKeys(GridNearAtomicUpdateResponse.java:369)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1508)
... 22 more
Suppressed: class org.apache.ignite.binary.BinaryObjectException:
Failed to get enum value for ordinal (do you have correct class version?)
[cls=org.apache.ignite.testframework.junits.IgniteConfigVariationsAbstractTest$TestEnum,
ordinal=9437186, totalValues=3]
at
org.apache.ignite.internal.binary.BinaryEnumCache.get(BinaryEnumCache.java:56)
at
org.apache.ignite.internal.binary.BinaryUtils.doReadEnum(BinaryUtils.java:1516)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.readEnum0(BinaryReaderExImpl.java:1163)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.readEnum(BinaryReaderExImpl.java:1140)
at
org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.readFixedType(BinaryFieldAccessor.java:812)
at
org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read(BinaryFieldAccessor.java:639)
at
org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:735)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1449)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:542)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:117)
at
org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinary(CacheObjectContext.java:257)
at
[jira] [Comment Edited] (IGNITE-2899) BinaryObject is deserialized before getting passed to CacheInterceptor
[
https://issues.apache.org/jira/browse/IGNITE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15221719#comment-15221719
]
Artem Shutak edited comment on IGNITE-2899 at 4/1/16 4:05 PM:
--
h4. Found more bugs in process of testing. In process of working on the issue I
faces with the following issues *{{withKeepBinary}}* related issues (including
issues described above):
1.1. {{BinaryOffheapValue}} leaks to {{EntryProcessor}}'s user code via
{{entry.getValue()}}. The issue happens under the following conditions:
- invokeAll operation
- ATOMIC cache in OFFHEAP_TIRED data mode
I will fix it for both {{getValue()}} and {{getKey()}}. Actually I cannot
imagine a case when {{getKey()}} can return offheap value, but to be sure I
think we should fix it as well.
1.2.We have inconsistency for {{IgniteCache.getEntry()}} and
{{IgniteCache.getEntries()}}: key of entry returned by first method is the same
entry which user set to method, so it can be user object, but keys of entries
of second method is {{BinaryObject}}.
Will fix {{getEntry().getKey()}} to return {{BinaryObject}}.
1.3. {{invoke}} and {{EntryProcessor}} which sets user object as value (not
{{BinaryObject}}). Then method {{Interceptor.onBeforePut(Entry e, Object
newVal)}} gets {{e.getKey()}} and {{e.getValue()}} as {{BinaryObject}},
{{newVal}} as userObject (for ATOMIC cache) or {{BinaryObject}} (for
TRANSACTIONAL cache), but {{Interceptor.onAfterPut(Entry e)}} gets
{{e.getKey()}} as {{BinaryObject}} and {{e.getValue}} as user object sometimes,
but should be {{BinaryObject}}. The issue can be reproduced only with Atomic
cache.
I think it a little bit tricky to use such inconsistent API and not obvious for
user where they can get {{BinaryObject}} and where user object.
The same issue can be reproduces for {{invokeAll()}}.
1.4 Not-interceptor-related issues with {{invokeAll}}:
1.4.1 {{invokeAll}} returns result map which contains mixed {{BinaryObject}}s
and user objects keys. I guess, that we get user objects keys if that keys
processed on local node.
1.4.2 {{invokeAll}} wraps result of {{CacheEntryProcessor.process()}} in
{{BinaryObject}} (for remote nodes). Why? I think user should get exactly the
same result as {{process}} method returns.
h4. The following issue related to *basic cache* (not keep binary) and
intercepror:
2.1. I was added {{InterceptorCacheConfigVariationsFullApiTestSuite}}, which
runs {{IgniteCacheConfigVariationsFullApiTest}} with enabled interceptor. The
interceptor just checks that keys and values are not {{BinaryObject}}.
Faced that in some cases Ignite cannot unmarshall binary object to get value at
interceptor (issue with enum).
{noformat}
Suppressed: class org.apache.ignite.IgniteCheckedException: Failed to
update keys on primary node.
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateResponse.addFailedKeys(GridNearAtomicUpdateResponse.java:369)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1508)
... 22 more
Suppressed: class org.apache.ignite.binary.BinaryObjectException:
Failed to get enum value for ordinal (do you have correct class version?)
[cls=org.apache.ignite.testframework.junits.IgniteConfigVariationsAbstractTest$TestEnum,
ordinal=9437186, totalValues=3]
at
org.apache.ignite.internal.binary.BinaryEnumCache.get(BinaryEnumCache.java:56)
at
org.apache.ignite.internal.binary.BinaryUtils.doReadEnum(BinaryUtils.java:1516)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.readEnum0(BinaryReaderExImpl.java:1163)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.readEnum(BinaryReaderExImpl.java:1140)
at
org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.readFixedType(BinaryFieldAccessor.java:812)
at
org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read(BinaryFieldAccessor.java:639)
at
org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:735)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1449)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:542)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:117)
at
org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinary(CacheObjectContext.java:257)
at
org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:148)
at
org.apache.ignite.internal.processors.cache.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1769)
at
[jira] [Comment Edited] (IGNITE-2899) BinaryObject is deserialized before getting passed to CacheInterceptor
[
https://issues.apache.org/jira/browse/IGNITE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15221719#comment-15221719
]
Artem Shutak edited comment on IGNITE-2899 at 4/1/16 3:38 PM:
--
h4. Found more bugs in process of testing. In process of working on the issue I
faces with the following issues *{{withKeepBinary}}* related issues (including
issues described above):
1.1. {{BinaryOffheapValue}} leaks to {{EntryProcessor}}'s user code via
{{entry.getValue()}}. The issue happens under the following conditions:
- invokeAll operation
- ATOMIC cache in OFFHEAP_TIRED data mode
I will fix it for both {{getValue()}} and {{getKey()}}. Actually I cannot
imagine a case when {{getKey()}} can return offheap value, but to be sure I
think we should fix it as well.
1.2.We have inconsistency for {{IgniteCache.getEntry()}} and
{{IgniteCache.getEntries()}}: key of entry returned by first method is the same
entry which user set to method, so it can be user object, but keys of entries
of second method is {{BinaryObject}}.
Will fix {{getEntry().getKey()}} to return {{BinaryObject}}.
1.3. {{invoke}} and {{EntryProcessor}} which sets user object as value (not
{{BinaryObject}}). Then method {{Interceptor.onBeforePut(Entry e, Object
newVal)}} gets {{e.getKey()}} and {{e.getValue()}} as {{BinaryObject}},
{{newVal}} as userObject from {{invoke()}}, but {{Interceptor.onAfterPut(Entry
e)}} gets {{e.getKey()}} as {{BinaryObject}} and {{e.getValue}} as user object
sometimes, but should be {{BinaryObject}}. The issue can be reproduced only
with Atomic cache.
I think it a little tricky to use such inconsistent API and not obvious for
user where they can get {{BinaryObject}} and where user object.
The same issue can be reproduces for {{invokeAll()}}.
1.4 Not-interceptor-related issues with {{invokeAll}}:
1.4.1 {{invokeAll}} returns result map which contains mixed {{BinaryObject}}s
and user objects keys. I guess, that we get user objects keys if that keys
processed on local node.
1.4.2 {{invokeAll}} wraps result of {{CacheEntryProcessor.process()}} in
{{BinaryObject}} (for remote nodes). Why? I think user should get exactly the
same result as {{process}} method returns.
h4. The following issue related to *basic cache* (not keep binary) and
intercepror:
2.1. I was added {{InterceptorCacheConfigVariationsFullApiTestSuite}}, which
runs {{IgniteCacheConfigVariationsFullApiTest}} with enabled interceptor. The
interceptor just checks that keys and values are not {{BinaryObject}}.
Faced that in some cases Ignite cannot unmarshall binary object to get value at
interceptor (issue with enum).
{noformat}
Suppressed: class org.apache.ignite.IgniteCheckedException: Failed to
update keys on primary node.
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateResponse.addFailedKeys(GridNearAtomicUpdateResponse.java:369)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1508)
... 22 more
Suppressed: class org.apache.ignite.binary.BinaryObjectException:
Failed to get enum value for ordinal (do you have correct class version?)
[cls=org.apache.ignite.testframework.junits.IgniteConfigVariationsAbstractTest$TestEnum,
ordinal=9437186, totalValues=3]
at
org.apache.ignite.internal.binary.BinaryEnumCache.get(BinaryEnumCache.java:56)
at
org.apache.ignite.internal.binary.BinaryUtils.doReadEnum(BinaryUtils.java:1516)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.readEnum0(BinaryReaderExImpl.java:1163)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.readEnum(BinaryReaderExImpl.java:1140)
at
org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.readFixedType(BinaryFieldAccessor.java:812)
at
org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read(BinaryFieldAccessor.java:639)
at
org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:735)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1449)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:542)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:117)
at
org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinary(CacheObjectContext.java:257)
at
org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:148)
at
org.apache.ignite.internal.processors.cache.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1769)
at
[jira] [Comment Edited] (IGNITE-2899) BinaryObject is deserialized before getting passed to CacheInterceptor
[
https://issues.apache.org/jira/browse/IGNITE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15221719#comment-15221719
]
Artem Shutak edited comment on IGNITE-2899 at 4/1/16 3:15 PM:
--
h4. Found more bugs in process of testing. In process of working on the issue I
faces with the following issues *{{withKeepBinary}}* related issues (including
issues described above):
1.1. {{BinaryOffheapValue}} leaks to {{EntryProcessor}}'s user code via
{{entry.getValue()}}. The issue happens under the following conditions:
- invokeAll operation
- ATOMIC cache in OFFHEAP_TIRED data mode
I will fix it for both {{getValue()}} and {{getKey()}}. Actually I cannot
imagine a case when {{getKey()}} can return offheap value, but to be sure I
think we should fix it as well.
1.2.We have inconsistency for {{IgniteCache.getEntry()}} and
{{IgniteCache.getEntries()}}: key of entry returned by first method is the same
entry which user set to method, so it can be user object, but keys of entries
of second method is {{BinaryObject}}.
Will fix {{getEntry().getKey()}} to return {{BinaryObject}}.
1.3. {{invoke}} and {{EntryProcessor}} which sets user object as value (not
{{BinaryObject}}). Then method {{Interceptor.onBeforePut(Entry e, Object
newVal)}} gets {{e.getKey()}} and {{e.getValue()}} as {{BinaryObject}},
{{newVal}} as userObject from {{invoke()}}, but {{Interceptor.onAfterPut(Entry
e)}} gets {{e.getKey()}} as {{BinaryObject}} and {{e.getValue}} as user object.
I think it a litle tricky to use such inconsistent API and not obvious for user
where they can get {{BinaryObject}} and where user object.
The same issue can be reproduces for {{invokeAll()}}.
1.4 Not-interceptor-related issues with {{invokeAll}}:
1.4.1 {{invokeAll}} returns result map which contains mixed {{BinaryObject}}s
and user objects keys. I guess, that we get user objects keys if that keys
processed on local node.
1.4.2 {{invokeAll}} wraps result of {{CacheEntryProcessor.process()}} in
{{BinaryObject}} (for remote nodes). Why? I think user should get exactly the
same result as {{process}} method returns.
h4. The following issue related to *basic cache* (not keep binary) and
intercepror:
2.1. I was added {{InterceptorCacheConfigVariationsFullApiTestSuite}}, which
runs {{IgniteCacheConfigVariationsFullApiTest}} with enabled interceptor. The
interceptor just checks that keys and values are not {{BinaryObject}}.
Faced that in some cases Ignite cannot unmarshall binary object to get value at
interceptor (issue with enum).
{noformat}
Suppressed: class org.apache.ignite.IgniteCheckedException: Failed to
update keys on primary node.
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateResponse.addFailedKeys(GridNearAtomicUpdateResponse.java:369)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1508)
... 22 more
Suppressed: class org.apache.ignite.binary.BinaryObjectException:
Failed to get enum value for ordinal (do you have correct class version?)
[cls=org.apache.ignite.testframework.junits.IgniteConfigVariationsAbstractTest$TestEnum,
ordinal=9437186, totalValues=3]
at
org.apache.ignite.internal.binary.BinaryEnumCache.get(BinaryEnumCache.java:56)
at
org.apache.ignite.internal.binary.BinaryUtils.doReadEnum(BinaryUtils.java:1516)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.readEnum0(BinaryReaderExImpl.java:1163)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.readEnum(BinaryReaderExImpl.java:1140)
at
org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.readFixedType(BinaryFieldAccessor.java:812)
at
org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read(BinaryFieldAccessor.java:639)
at
org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:735)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1449)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:542)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:117)
at
org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinary(CacheObjectContext.java:257)
at
org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:148)
at
org.apache.ignite.internal.processors.cache.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1769)
at
org.apache.ignite.internal.processors.cache.CacheLazyEntry.getValue(CacheLazyEntry.java:125)
at
[jira] [Comment Edited] (IGNITE-2899) BinaryObject is deserialized before getting passed to CacheInterceptor
[
https://issues.apache.org/jira/browse/IGNITE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15221719#comment-15221719
]
Artem Shutak edited comment on IGNITE-2899 at 4/1/16 2:31 PM:
--
h4. Found more bugs in process of testing. In process of working on the issue I
faces with the following issues *{{withKeepBinary}}* related issues (including
issues described above):
1.1. {{BinaryOffheapValue}} leaks to {{EntryProcessor}}'s user code via
{{entry.getValue()}}. The issue happens under the following conditions:
- invokeAll operation
- ATOMIC cache in OFFHEAP_TIRED data mode
I will fix it for both {{getValue()}} and {{getKey()}}. Actually I cannot
imagine a case when {{getKey()}} can return offheap value, but to be sure I
think we should fix it as well.
1.2.We have inconsistency for {{IgniteCache.getEntry()}} and
{{IgniteCache.getEntries()}}: key of entry returned by first method is the same
entry which user set to method, so it can be user object, but keys of entries
of second method is {{BinaryObject}}.
Will fix {{getEntry().getKey()}} to return {{BinaryObject}}.
1.3. {{invoke}} and {{EntryProcessor}} which sets user object as value (not
{{BinaryObject}}). Then method {{Interceptor.onBeforePut(Entry e, Object
newVal)}} gets {{e.getKey()}} and {{e.getValue()}} as {{BinaryObject}},
{{newVal}} as userObject from {{invoke()}}, but {{Interceptor.onAfterPut(Entry
e)}} gets {{e.getKey()}} as {{BinaryObject}} and {{e.getValue}} as user object.
I think it a litle tricky to use such inconsistent API and not obvious for user
where they can get {{BinaryObject}} and where user object.
The same issue can be reproduces for {{invokeAll()}}.
1.4 {{invokeAll}} returns result map which contains mixed {{BinaryObject}}s and
user objects keys. I guess, that we get user objects keys if that keys
processed on local node.
h4. The following issue related to *basic cache* (not keep binary) and
intercepror:
2.1. I was added {{InterceptorCacheConfigVariationsFullApiTestSuite}}, which
runs {{IgniteCacheConfigVariationsFullApiTest}} with enabled interceptor. The
interceptor just checks that keys and values are not {{BinaryObject}}.
Faced that in some cases Ignite cannot unmarshall binary object to get value at
interceptor (issue with enum).
{noformat}
Suppressed: class org.apache.ignite.IgniteCheckedException: Failed to
update keys on primary node.
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateResponse.addFailedKeys(GridNearAtomicUpdateResponse.java:369)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1508)
... 22 more
Suppressed: class org.apache.ignite.binary.BinaryObjectException:
Failed to get enum value for ordinal (do you have correct class version?)
[cls=org.apache.ignite.testframework.junits.IgniteConfigVariationsAbstractTest$TestEnum,
ordinal=9437186, totalValues=3]
at
org.apache.ignite.internal.binary.BinaryEnumCache.get(BinaryEnumCache.java:56)
at
org.apache.ignite.internal.binary.BinaryUtils.doReadEnum(BinaryUtils.java:1516)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.readEnum0(BinaryReaderExImpl.java:1163)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.readEnum(BinaryReaderExImpl.java:1140)
at
org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.readFixedType(BinaryFieldAccessor.java:812)
at
org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read(BinaryFieldAccessor.java:639)
at
org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:735)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1449)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:542)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:117)
at
org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinary(CacheObjectContext.java:257)
at
org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:148)
at
org.apache.ignite.internal.processors.cache.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1769)
at
org.apache.ignite.internal.processors.cache.CacheLazyEntry.getValue(CacheLazyEntry.java:125)
at
org.apache.ignite.internal.processors.cache.CacheLazyEntry.getValue(CacheLazyEntry.java:111)
at
org.apache.ignite.internal.processors.cache.InterceptorCacheConfigVariationsFullApiTest$TestInterceptor.validateEntry(InterceptorCacheConfigVariationsFullApiTest.java:113)
[jira] [Comment Edited] (IGNITE-2899) BinaryObject is deserialized before getting passed to CacheInterceptor
[
https://issues.apache.org/jira/browse/IGNITE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15221719#comment-15221719
]
Artem Shutak edited comment on IGNITE-2899 at 4/1/16 2:29 PM:
--
Found more bugs in process of testing. In process of working on the issue I
faces with the following issues {{withKeepBinary}} related issues (including
issues described above):
1.1. {{BinaryOffheapValue}} leaks to {{EntryProcessor}}'s user code via
{{entry.getValue()}}. The issue happens under the following conditions:
- invokeAll operation
- ATOMIC cache in OFFHEAP_TIRED data mode
I will fix it for both {{getValue()}} and {{getKey()}}. Actually I cannot
imagine a case when {{getKey()}} can return offheap value, but to be sure I
think we should fix it as well.
1.2.We have inconsistency for {{IgniteCache.getEntry()}} and
{{IgniteCache.getEntries()}}: key of entry returned by first method is the same
entry which user set to method, so it can be user object, but keys of entries
of second method is {{BinaryObject}}.
Will fix {{getEntry().getKey()}} to return {{BinaryObject}}.
1.3. {{invoke}} and {{EntryProcessor}} which sets user object as value (not
{{BinaryObject}}). Then method {{Interceptor.onBeforePut(Entry e, Object
newVal)}} gets {{e.getKey()}} and {{e.getValue()}} as {{BinaryObject}},
{{newVal}} as userObject from {{invoke()}}, but {{Interceptor.onAfterPut(Entry
e)}} gets {{e.getKey()}} as {{BinaryObject}} and {{e.getValue}} as user object.
I think it a litle tricky to use such inconsistent API and not obvious for user
where they can get {{BinaryObject}} and where user object.
The same issue can be reproduces for {{invokeAll()}}.
1.4 {{invokeAll}} returns result map which contains mixed {{BinaryObject}}s and
user objects keys. I guess, that we get user objects keys if that keys
processed on local node.
Also I faced with the following issue related to basic cache (not keep binary)
and intercepror:
2.1. I was added {{InterceptorCacheConfigVariationsFullApiTestSuite}}, which
runs {{IgniteCacheConfigVariationsFullApiTest}} with enabled interceptor. The
interceptor just checks that keys and values are not {{BinaryObject}}.
Faced that in some cases Ignite cannot unmarshall binary object to get value at
interceptor (issue with enum).
{noformat}
Suppressed: class org.apache.ignite.IgniteCheckedException: Failed to
update keys on primary node.
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateResponse.addFailedKeys(GridNearAtomicUpdateResponse.java:369)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1508)
... 22 more
Suppressed: class org.apache.ignite.binary.BinaryObjectException:
Failed to get enum value for ordinal (do you have correct class version?)
[cls=org.apache.ignite.testframework.junits.IgniteConfigVariationsAbstractTest$TestEnum,
ordinal=9437186, totalValues=3]
at
org.apache.ignite.internal.binary.BinaryEnumCache.get(BinaryEnumCache.java:56)
at
org.apache.ignite.internal.binary.BinaryUtils.doReadEnum(BinaryUtils.java:1516)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.readEnum0(BinaryReaderExImpl.java:1163)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.readEnum(BinaryReaderExImpl.java:1140)
at
org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.readFixedType(BinaryFieldAccessor.java:812)
at
org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read(BinaryFieldAccessor.java:639)
at
org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:735)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1449)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:542)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:117)
at
org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinary(CacheObjectContext.java:257)
at
org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:148)
at
org.apache.ignite.internal.processors.cache.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1769)
at
org.apache.ignite.internal.processors.cache.CacheLazyEntry.getValue(CacheLazyEntry.java:125)
at
org.apache.ignite.internal.processors.cache.CacheLazyEntry.getValue(CacheLazyEntry.java:111)
at
org.apache.ignite.internal.processors.cache.InterceptorCacheConfigVariationsFullApiTest$TestInterceptor.validateEntry(InterceptorCacheConfigVariationsFullApiTest.java:113)
[jira] [Commented] (IGNITE-1559) Need to improve tests, javadoc and documentation of UriDeploymentHttpScanner.
[ https://issues.apache.org/jira/browse/IGNITE-1559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15221605#comment-15221605 ] Artem Shutak commented on IGNITE-1559: -- In bounds of the issue javadoc was fixed and classes:// schema description was deleted from UriDeploymentSpi javadoc. file:// schema shold be used instead. > Need to improve tests, javadoc and documentation of UriDeploymentHttpScanner. > - > > Key: IGNITE-1559 > URL: https://issues.apache.org/jira/browse/IGNITE-1559 > Project: Ignite > Issue Type: Task >Reporter: Artem Shutak >Assignee: Valentin Kulichenko >Priority: Critical > Fix For: 1.5.0.final > > > Need to improve tests, javadoc and documentation of UriDeploymentHttpScanner. > It's not possible to understand from current javadoc of > UriDeploymentHttpScanner how it works. > There's only one simple test in GridHttpDeploymentSelfTest. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2899) BinaryObject is deserialized before getting passed to CacheInterceptor
[
https://issues.apache.org/jira/browse/IGNITE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15219996#comment-15219996
]
Artem Shutak commented on IGNITE-2899:
--
Found another {{withKeepBinary}} related issue. We have inconsistency for
{{IgniteCache.getEntry()}} and {{IgniteCache.getEntries()}}: key of entry
returned by first method is the same entry which user set to method, so it can
be user object, but keys of entries of second method is {{BinaryObject}}.
I''m not sure which behavior is true.
> 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
>Assignee: Artem Shutak
> Fix For: 1.6
>
> 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)
>
[jira] [Commented] (IGNITE-2899) BinaryObject is deserialized before getting passed to CacheInterceptor
[
https://issues.apache.org/jira/browse/IGNITE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15219851#comment-15219851
]
Artem Shutak commented on IGNITE-2899:
--
I will fix it for both {{getValue()}} and {{getKey()}}. Actually I cannot
imagine a case when {{getKey()}} can return offheap value, but to be sure I
think we should fix it as well.
> 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
>Assignee: Artem Shutak
> Fix For: 1.6
>
> 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
>
[jira] [Comment Edited] (IGNITE-2899) BinaryObject is deserialized before getting passed to CacheInterceptor
[
https://issues.apache.org/jira/browse/IGNITE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15219846#comment-15219846
]
Artem Shutak edited comment on IGNITE-2899 at 3/31/16 1:12 PM:
---
Found that {{BinaryOffheapValue}} leaks to {{EntryProcessor}}'s user code via
{{entry.getValue()}}. The issue happens under the following conditions:
- User uses {{cache.withKeepBinary()}}
- invokeAll operation
- ATOMIC cache in OFFHEAP_TIRED data mode
I will fix the founded issue in bounds of this task.
was (Author: ashutak):
Found that {{EntryProcessor}}'s user code can achieved {{BinaryOffheapValue}}
via {{entry.getValue()}}. The issue happens under the following conditions:
- User uses {{cache.withKeepBinary()}}
- invokeAll operation
- ATOMIC cache in OFFHEAP_TIRED data mode
I will fix the founded issue in bounds of this task.
> 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
>Assignee: Artem Shutak
> Fix For: 1.6
>
> 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)
[jira] [Commented] (IGNITE-2899) BinaryObject is deserialized before getting passed to CacheInterceptor
[
https://issues.apache.org/jira/browse/IGNITE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15219846#comment-15219846
]
Artem Shutak commented on IGNITE-2899:
--
Found that {{EntryProcessor}}'s user code can achieved {{BinaryOffheapValue}}
via {{entry.getValue()}}. The issue happens under the following conditions:
- User uses {{cache.withKeepBinary()}}
- invokeAll operation
- ATOMIC cache in OFFHEAP_TIRED data mode
I will fix the founded issue in bounds of this task.
> 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
>Assignee: Artem Shutak
> Fix For: 1.6
>
> 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
>
[jira] [Commented] (IGNITE-2899) BinaryObject is deserialized before getting passed to CacheInterceptor
[
https://issues.apache.org/jira/browse/IGNITE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15219434#comment-15219434
]
Artem Shutak commented on IGNITE-2899:
--
The original case has been fixed. Working on tests and fixes for another cases
(get/remove/invoke ops * tx cache).
> 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
>Assignee: Artem Shutak
> Fix For: 1.6
>
> 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)
>
[jira] [Commented] (IGNITE-2899) BinaryObject is deserialized before getting passed to CacheInterceptor
[
https://issues.apache.org/jira/browse/IGNITE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15217881#comment-15217881
]
Artem Shutak commented on IGNITE-2899:
--
I will take care of this issue.
But I need to notice that the attached examples are wrong about using
Interceptor: we cannot throw any exception from intercepror methods (see "This
method should not throw any exception." at {{CacheInterceptor}} javadoc)
> 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
>Assignee: Artem Shutak
> Fix For: 1.6
>
> 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
>
[jira] [Commented] (IGNITE-2645) Assertion error in ATOMIC cachce for invokeAll and cache store
[ https://issues.apache.org/jira/browse/IGNITE-2645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15216333#comment-15216333 ] Artem Shutak commented on IGNITE-2645: -- Fixed in a way suggested by Alexey. Added entry's versions consistency tests. TC look good (waiting for the rest non-cache related tests). > Assertion error in ATOMIC cachce for invokeAll and cache store > -- > > Key: IGNITE-2645 > URL: https://issues.apache.org/jira/browse/IGNITE-2645 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: ignite-1.4 >Reporter: Alexey Goncharuk >Assignee: Artem Shutak > Labels: community > Fix For: 1.6 > > Attachments: EntryProcessorFails.java > > > Assertion happens under the following conditions: > * Cache is empty > * Cache store contains non-null values for some keys > * invokeAll is invoked for those keys > Update version is generated when update request reaches the primary node. > Then, we need to read-through stored values (the cache is empty) and pass > them to transformers. Since read-through changes entry version, subsequent > update fails with an assertion because read-through version is generated > later than update version. > The scenario when a read-through is implemented via a separate loop with > innerGet() is possible only with invokeAll() because this is the only > multi-key cache operation that requires the previous entry value. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2645) Assertion error in ATOMIC cachce for invokeAll and cache store
[ https://issues.apache.org/jira/browse/IGNITE-2645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15209967#comment-15209967 ] Artem Shutak commented on IGNITE-2645: -- Alexey, thanks! It works now. > Assertion error in ATOMIC cachce for invokeAll and cache store > -- > > Key: IGNITE-2645 > URL: https://issues.apache.org/jira/browse/IGNITE-2645 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: ignite-1.4 >Reporter: Alexey Goncharuk >Assignee: Artem Shutak > Labels: community > Fix For: 1.6 > > Attachments: EntryProcessorFails.java > > > Assertion happens under the following conditions: > * Cache is empty > * Cache store contains non-null values for some keys > * invokeAll is invoked for those keys > Update version is generated when update request reaches the primary node. > Then, we need to read-through stored values (the cache is empty) and pass > them to transformers. Since read-through changes entry version, subsequent > update fails with an assertion because read-through version is generated > later than update version. > The scenario when a read-through is implemented via a separate loop with > innerGet() is possible only with invokeAll() because this is the only > multi-key cache operation that requires the previous entry value. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2645) Assertion error in ATOMIC cachce for invokeAll and cache store
[ https://issues.apache.org/jira/browse/IGNITE-2645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15208868#comment-15208868 ] Artem Shutak commented on IGNITE-2645: -- I cannot reproduce the issue with the attached test neither with 1.5.0 and with current master. Do we have stack-trace or any other useful information? > Assertion error in ATOMIC cachce for invokeAll and cache store > -- > > Key: IGNITE-2645 > URL: https://issues.apache.org/jira/browse/IGNITE-2645 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: ignite-1.4 >Reporter: Alexey Goncharuk >Assignee: Artem Shutak > Labels: community > Fix For: 1.6 > > Attachments: EntryProcessorFails.java > > > Assertion happens under the following conditions: > * Cache is empty > * Cache store contains non-null values for some keys > * invokeAll is invoked for those keys > Update version is generated when update request reaches the primary node. > Then, we need to read-through stored values (the cache is empty) and pass > them to transformers. Since read-through changes entry version, subsequent > update fails with an assertion because read-through version is generated > later than update version. > The scenario when a read-through is implemented via a separate loop with > innerGet() is possible only with invokeAll() because this is the only > multi-key cache operation that requires the previous entry value. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-1232) Support distributed SQL JOIN
[
https://issues.apache.org/jira/browse/IGNITE-1232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15206656#comment-15206656
]
Artem Shutak edited comment on IGNITE-1232 at 3/22/16 4:40 PM:
---
I've investigated the failure of the assert and found a minimal query to
reproduce.
{code}
select rootOrderId
from (
select rootOrderId from "part".CustOrder
union all
select rootOrderId from "part".ReplaceOrder
) co
{code}
At the same time, test for union-ubquery works as well.
To properly fix it, I need more understanding in {{GridH2CollocationModel}},
especially what is the right tree of {{GridH2CollocationModel}} objects in case
of inner union?
I see at least 2 possible trees:
1.
{noformat}
GridH2CollocationModel_1(upper=null) - represents
all query
|---GridH2CollocationModel_2-
represents union query (unions list here)
|---GridH2CollocationModel_3-
represents left union query
|---GridH2CollocationModel_4-
represents right union query
{noformat}
2.
{noformat}
GridH2CollocationModel_1(upper=null) - represents
all query (unions list here)
|---GridH2CollocationModel_2-
represents left union query
|---GridH2CollocationModel_3-
represents right union query
{noformat}
>From current implementation I see that we want to achieve the second tree, but
>it looks like wrong and we should have the first one.
was (Author: ashutak):
I've investigated the failure of the assert and found minimal query to
reproduce.
{code}
select rootOrderId
from (
select rootOrderId from "part".CustOrder
union all
select rootOrderId from "part".ReplaceOrder
) co
{code}
At the same time, test for union-ubquery works as well.
To properly fix it, I need more understanding in {{GridH2CollocationModel}},
especially what is the right tree of {{GridH2CollocationModel}} objects in case
of inner union?
I see at least 2 possible trees:
1.
{noformat}
GridH2CollocationModel_1(upper=null) - represents
all query
|---GridH2CollocationModel_2-
represents union query (unions list here)
|---GridH2CollocationModel_3-
represents left union query
|---GridH2CollocationModel_4-
represents right union query
{noformat}
2.
{noformat}
GridH2CollocationModel_1(upper=null) - represents
all query (unions list here)
|---GridH2CollocationModel_2-
represents left union query
|---GridH2CollocationModel_3-
represents right union query
{noformat}
>From current implementation I see that we want to achieve the second tree, but
>it looks like wrong and we should have the first one.
> Support distributed SQL JOIN
> -
>
> Key: IGNITE-1232
> URL: https://issues.apache.org/jira/browse/IGNITE-1232
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergi Vladykin
>Assignee: Sergi Vladykin
> Fix For: 1.6
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-1232) Support distributed SQL JOIN
[
https://issues.apache.org/jira/browse/IGNITE-1232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15206656#comment-15206656
]
Artem Shutak edited comment on IGNITE-1232 at 3/22/16 4:07 PM:
---
I've investigated the failure of the assert and found minimal query to
reproduce.
{code}
select rootOrderId
from (
select rootOrderId from "part".CustOrder
union all
select rootOrderId from "part".ReplaceOrder
) co
{code}
At the same time, test for union-ubquery works as well.
To properly fix it, I need more understanding in {{GridH2CollocationModel}},
especially what is the right tree of {{GridH2CollocationModel}} objects in case
of inner union?
I see at least 2 possible trees:
1.
{noformat}
GridH2CollocationModel_1(upper=null) - represents
all query
|---GridH2CollocationModel_2-
represents union query (unions list here)
|---GridH2CollocationModel_3-
represents left union query
|---GridH2CollocationModel_4-
represents right union query
{noformat}
2.
{noformat}
GridH2CollocationModel_1(upper=null) - represents
all query (unions list here)
|---GridH2CollocationModel_2-
represents left union query
|---GridH2CollocationModel_3-
represents right union query
{noformat}
>From current implementation I see that we want to achieve the second tree, but
>it looks like wrong and we should have the first one.
was (Author: ashutak):
I've investigated the failure of the assert and found minimal query to
reproduce.
{code}
select rootOrderId
from (
select rootOrderId from "part".CustOrder
union all
select rootOrderId from "part".ReplaceOrder
) co
{code}
At the same time, test for union-ubquery works as well.
To properly fix it, I need more understanding in {{GridH2CollocationModel}},
especially what is the right tree of {{GridH2CollocationModel}} objects in case
of inner union?
I see at least 2 possible trees:
1.
GridH2CollocationModel_1(upper=null)-
represents all query
|---GridH2CollocationModel_2(upper=GridH2CollocationModel_1, ) -
represents union query (unions list here)
|---GridH2CollocationModel_3-
represents left union query
|---GridH2CollocationModel_4-
represents right union query
2.
GridH2CollocationModel_1(upper=null)-
represents all query (unions list here)
|---GridH2CollocationModel_2-
represents left union query
|---GridH2CollocationModel_3-
represents right union query
>From current implementation I see that we want to achieve the second tree, but
>it looks like wrong and we should have the first one.
> Support distributed SQL JOIN
> -
>
> Key: IGNITE-1232
> URL: https://issues.apache.org/jira/browse/IGNITE-1232
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergi Vladykin
>Assignee: Sergi Vladykin
> Fix For: 1.6
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1232) Support distributed SQL JOIN
[
https://issues.apache.org/jira/browse/IGNITE-1232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15206656#comment-15206656
]
Artem Shutak commented on IGNITE-1232:
--
I've investigated the failure of the assert and found minimal query to
reproduce.
{code}
select rootOrderId
from (
select rootOrderId from "part".CustOrder
union all
select rootOrderId from "part".ReplaceOrder
) co
{code}
At the same time, test for union-ubquery works as well.
To properly fix it, I need more understanding in {{GridH2CollocationModel}},
especially what is the right tree of {{GridH2CollocationModel}} objects in case
of inner union?
I see at least 2 possible trees:
1.
GridH2CollocationModel_1(upper=null)-
represents all query
|---GridH2CollocationModel_2(upper=GridH2CollocationModel_1, ) -
represents union query (unions list here)
|---GridH2CollocationModel_3-
represents left union query
|---GridH2CollocationModel_4-
represents right union query
2.
GridH2CollocationModel_1(upper=null)-
represents all query (unions list here)
|---GridH2CollocationModel_2-
represents left union query
|---GridH2CollocationModel_3-
represents right union query
>From current implementation I see that we want to achieve the second tree, but
>it looks like wrong and we should have the first one.
> Support distributed SQL JOIN
> -
>
> Key: IGNITE-1232
> URL: https://issues.apache.org/jira/browse/IGNITE-1232
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergi Vladykin
>Assignee: Sergi Vladykin
> Fix For: 1.6
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2835) BinaryObjectOffHeapImpl leaked to public code
[
https://issues.apache.org/jira/browse/IGNITE-2835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15206569#comment-15206569
]
Artem Shutak commented on IGNITE-2835:
--
TC looks good.
Ready for review.
> BinaryObjectOffHeapImpl leaked to public code
> -
>
> Key: IGNITE-2835
> URL: https://issues.apache.org/jira/browse/IGNITE-2835
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Artem Shutak
>Priority: Critical
> Labels: community, important
> Fix For: 1.6
>
> Attachments: BinaryObjectOffHeapIssue.java
>
>
> To my knowledge {{BinaryObjectOffHeapImpl}} is considered to be used under
> some internal lock only to prevent possible offheap pointer movement.
> However seems that we made it available to public code. If to start a
> partitioned cache in {{OFFHEAP_TIRED}} mode, get {{BinaryObject}} from the
> cache inside of a TX and put the same object back we will get exception like
> below
> {noformat}
> [15:00:00,892][WARN ][main][GridNearTxLocal] Set transaction invalidation
> flag to true due to error [tx=GridNearTxLocal [mappings=IgniteTxMappingsImpl
> [], nearLocallyMapped=false, colocatedLocallyMapped=true,
> needCheckBackup=null, hasRemoteLocks=false, mappings=IgniteTxMappingsImpl [],
> super=GridDhtTxLocalAdapter [nearOnOriginatingNode=false, nearNodes=[],
> dhtNodes=[], explicitLock=false, super=IgniteTxLocalAdapter
> [completedBase=null, sndTransformedVals=false, depEnabled=false,
> txState=IgniteTxStateImpl [activeCacheIds=GridLongList [idx=1,
> arr=[-1206548976]], txMap={IgniteTxKey [key=KeyCacheObjectImpl [val=0,
> hasValBytes=true], cacheId=-1206548976]=IgniteTxEntry [key=KeyCacheObjectImpl
> [val=0, hasValBytes=true], cacheId=-1206548976, txKey=IgniteTxKey
> [key=KeyCacheObjectImpl [val=0, hasValBytes=true], cacheId=-1206548976],
> val=[op=UPDATE, val=SomeType [idHash=1337835760, hash=0, field2=name_0,
> field1=0]], prevVal=[op=UPDATE, val=SomeType [idHash=1337835760, hash=0,
> field2=name_0, field1=0]], entryProcessorsCol=null, ttl=-1,
> conflictExpireTime=-1, conflictVer=null, explicitVer=null,
> dhtVer=GridCacheVersion [topVer=69523200, nodeOrderDrId=1,
> globalTime=1458043200871, order=1458043167489], filters=[],
> filtersPassed=false, filtersSet=true, entry=GridDhtColocatedCacheEntry
> [super=GridDhtCacheEntry [rdrs=[], locPart=GridDhtLocalPartition [id=0,
> mapPubSize=0, rmvQueue=GridCircularBuffer [sizeMask=255, idxGen=1], cntr=1,
> state=OWNING, reservations=0, empty=true, createTime=03/15/2016 15:00:00,
> mapPubSize=0], super=GridDistributedCacheEntry [super=GridCacheMapEntry
> [key=KeyCacheObjectImpl [val=0, hasValBytes=true], val=null,
> startVer=1458043167488, ver=GridCacheVersion [topVer=69523200,
> nodeOrderDrId=1, globalTime=1458043200890, order=1458043167490],
> hash=-1484017934, extras=GridCacheObsoleteEntryExtras
> [obsoleteVer=GridCacheVersion [topVer=69523200, nodeOrderDrId=1,
> globalTime=1458043200890, order=1458043167491]], flags=7, prepared=false,
> locked=true, nodeId=993f5733-b014-4a5b-a6d1-934aeec9e9f5, locMapped=false,
> expiryPlc=null, transferExpiryPlc=false, flags=2, partUpdateCntr=0,
> serReadVer=null, xidVer=GridCacheVersion [topVer=69523200, nodeOrderDrId=1,
> globalTime=1458043200852, order=1458043167487]]}], super=IgniteTxAdapter
> [xidVer=GridCacheVersion [topVer=69523200, nodeOrderDrId=1,
> globalTime=1458043200852, order=1458043167487], writeVer=GridCacheVersion
> [topVer=69523200, nodeOrderDrId=1, globalTime=1458043200871,
> order=1458043167489], implicit=false, loc=true, threadId=1,
> startTime=1458043200850, nodeId=993f5733-b014-4a5b-a6d1-934aeec9e9f5,
> startVer=GridCacheVersion [topVer=69523200, nodeOrderDrId=1,
> globalTime=1458043200852, order=1458043167487], endVer=null,
> isolation=REPEATABLE_READ, concurrency=PESSIMISTIC, timeout=0,
> sysInvalidate=true, sys=false, plc=2, commitVer=GridCacheVersion
> [topVer=69523200, nodeOrderDrId=1, globalTime=1458043200852,
> order=1458043167487], finalizing=NONE, preparing=false, invalidParts=null,
> state=UNKNOWN, timedOut=false, topVer=AffinityTopologyVersion [topVer=1,
> minorTopVer=1], duration=40ms, onePhaseCommit=true], size=1]]], err=class
> o.a.i.i.transactions.IgniteTxHeuristicCheckedException: Failed to locally
> write to cache (all transaction entries will be invalidated, however there
> was a window when entries for this transaction were visible to others):
> GridNearTxLocal [mappings=IgniteTxMappingsImpl [], nearLocallyMapped=false,
> colocatedLocallyMapped=true, needCheckBackup=null, hasRemoteLocks=false,
> mappings=IgniteTxMappingsImpl [], super=GridDhtTxLocalAdapter
> [nearOnOriginatingNode=false, nearNodes=[], dhtNodes=[], explicitLock=false,
>
[jira] [Commented] (IGNITE-1232) Support distributed SQL JOIN
[
https://issues.apache.org/jira/browse/IGNITE-1232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15206254#comment-15206254
]
Artem Shutak commented on IGNITE-1232:
--
Added {{H2CompareBigQueryDistributedJoinsTest}} test.
Test fails on assertion.
{noformat}
java.lang.AssertionError
at
org.apache.ignite.internal.processors.query.h2.opt.GridH2CollocationModel.createChildModel(GridH2CollocationModel.java:101)
at
org.apache.ignite.internal.processors.query.h2.opt.GridH2CollocationModel.buildCollocationModel(GridH2CollocationModel.java:611)
at
org.apache.ignite.internal.processors.query.h2.opt.GridH2CollocationModel.buildCollocationModel(GridH2CollocationModel.java:593)
at
org.apache.ignite.internal.processors.query.h2.opt.GridH2CollocationModel.buildCollocationModel(GridH2CollocationModel.java:619)
at
org.apache.ignite.internal.processors.query.h2.opt.GridH2CollocationModel.buildCollocationModel(GridH2CollocationModel.java:619)
at
org.apache.ignite.internal.processors.query.h2.opt.GridH2CollocationModel.isCollocated(GridH2CollocationModel.java:575)
at
org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.split(GridSqlQuerySplitter.java:186)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryTwoStep(IgniteH2Indexing.java:1140)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$2.applyx(GridQueryProcessor.java:729)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$2.applyx(GridQueryProcessor.java:727)
at
org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:1662)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.queryTwoStep(GridQueryProcessor.java:727)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:660)
at
org.apache.ignite.internal.processors.query.h2.sql.AbstractH2CompareQueryTest.compareQueryRes0(AbstractH2CompareQueryTest.java:279)
at
org.apache.ignite.internal.processors.query.h2.sql.H2CompareBigQueryTest.testBigQuery(H2CompareBigQueryTest.java:249)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1758)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:118)
at
org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1696)
at java.lang.Thread.run(Thread.java:745)
{noformat}
> Support distributed SQL JOIN
> -
>
> Key: IGNITE-1232
> URL: https://issues.apache.org/jira/browse/IGNITE-1232
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergi Vladykin
>Assignee: Sergi Vladykin
> Fix For: 1.6
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2835) BinaryObjectOffHeapImpl leaked to public code
[
https://issues.apache.org/jira/browse/IGNITE-2835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15201916#comment-15201916
]
Artem Shutak commented on IGNITE-2835:
--
Made a potential fix. Waiting for TC results.
> BinaryObjectOffHeapImpl leaked to public code
> -
>
> Key: IGNITE-2835
> URL: https://issues.apache.org/jira/browse/IGNITE-2835
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Artem Shutak
>Priority: Critical
> Labels: community, important
> Fix For: 1.6
>
> Attachments: BinaryObjectOffHeapIssue.java
>
>
> To my knowledge {{BinaryObjectOffHeapImpl}} is considered to be used under
> some internal lock only to prevent possible offheap pointer movement.
> However seems that we made it available to public code. If to start a
> partitioned cache in {{OFFHEAP_TIRED}} mode, get {{BinaryObject}} from the
> cache inside of a TX and put the same object back we will get exception like
> below
> {noformat}
> [15:00:00,892][WARN ][main][GridNearTxLocal] Set transaction invalidation
> flag to true due to error [tx=GridNearTxLocal [mappings=IgniteTxMappingsImpl
> [], nearLocallyMapped=false, colocatedLocallyMapped=true,
> needCheckBackup=null, hasRemoteLocks=false, mappings=IgniteTxMappingsImpl [],
> super=GridDhtTxLocalAdapter [nearOnOriginatingNode=false, nearNodes=[],
> dhtNodes=[], explicitLock=false, super=IgniteTxLocalAdapter
> [completedBase=null, sndTransformedVals=false, depEnabled=false,
> txState=IgniteTxStateImpl [activeCacheIds=GridLongList [idx=1,
> arr=[-1206548976]], txMap={IgniteTxKey [key=KeyCacheObjectImpl [val=0,
> hasValBytes=true], cacheId=-1206548976]=IgniteTxEntry [key=KeyCacheObjectImpl
> [val=0, hasValBytes=true], cacheId=-1206548976, txKey=IgniteTxKey
> [key=KeyCacheObjectImpl [val=0, hasValBytes=true], cacheId=-1206548976],
> val=[op=UPDATE, val=SomeType [idHash=1337835760, hash=0, field2=name_0,
> field1=0]], prevVal=[op=UPDATE, val=SomeType [idHash=1337835760, hash=0,
> field2=name_0, field1=0]], entryProcessorsCol=null, ttl=-1,
> conflictExpireTime=-1, conflictVer=null, explicitVer=null,
> dhtVer=GridCacheVersion [topVer=69523200, nodeOrderDrId=1,
> globalTime=1458043200871, order=1458043167489], filters=[],
> filtersPassed=false, filtersSet=true, entry=GridDhtColocatedCacheEntry
> [super=GridDhtCacheEntry [rdrs=[], locPart=GridDhtLocalPartition [id=0,
> mapPubSize=0, rmvQueue=GridCircularBuffer [sizeMask=255, idxGen=1], cntr=1,
> state=OWNING, reservations=0, empty=true, createTime=03/15/2016 15:00:00,
> mapPubSize=0], super=GridDistributedCacheEntry [super=GridCacheMapEntry
> [key=KeyCacheObjectImpl [val=0, hasValBytes=true], val=null,
> startVer=1458043167488, ver=GridCacheVersion [topVer=69523200,
> nodeOrderDrId=1, globalTime=1458043200890, order=1458043167490],
> hash=-1484017934, extras=GridCacheObsoleteEntryExtras
> [obsoleteVer=GridCacheVersion [topVer=69523200, nodeOrderDrId=1,
> globalTime=1458043200890, order=1458043167491]], flags=7, prepared=false,
> locked=true, nodeId=993f5733-b014-4a5b-a6d1-934aeec9e9f5, locMapped=false,
> expiryPlc=null, transferExpiryPlc=false, flags=2, partUpdateCntr=0,
> serReadVer=null, xidVer=GridCacheVersion [topVer=69523200, nodeOrderDrId=1,
> globalTime=1458043200852, order=1458043167487]]}], super=IgniteTxAdapter
> [xidVer=GridCacheVersion [topVer=69523200, nodeOrderDrId=1,
> globalTime=1458043200852, order=1458043167487], writeVer=GridCacheVersion
> [topVer=69523200, nodeOrderDrId=1, globalTime=1458043200871,
> order=1458043167489], implicit=false, loc=true, threadId=1,
> startTime=1458043200850, nodeId=993f5733-b014-4a5b-a6d1-934aeec9e9f5,
> startVer=GridCacheVersion [topVer=69523200, nodeOrderDrId=1,
> globalTime=1458043200852, order=1458043167487], endVer=null,
> isolation=REPEATABLE_READ, concurrency=PESSIMISTIC, timeout=0,
> sysInvalidate=true, sys=false, plc=2, commitVer=GridCacheVersion
> [topVer=69523200, nodeOrderDrId=1, globalTime=1458043200852,
> order=1458043167487], finalizing=NONE, preparing=false, invalidParts=null,
> state=UNKNOWN, timedOut=false, topVer=AffinityTopologyVersion [topVer=1,
> minorTopVer=1], duration=40ms, onePhaseCommit=true], size=1]]], err=class
> o.a.i.i.transactions.IgniteTxHeuristicCheckedException: Failed to locally
> write to cache (all transaction entries will be invalidated, however there
> was a window when entries for this transaction were visible to others):
> GridNearTxLocal [mappings=IgniteTxMappingsImpl [], nearLocallyMapped=false,
> colocatedLocallyMapped=true, needCheckBackup=null, hasRemoteLocks=false,
> mappings=IgniteTxMappingsImpl [], super=GridDhtTxLocalAdapter
> [nearOnOriginatingNode=false, nearNodes=[], dhtNodes=[],
[jira] [Assigned] (IGNITE-2835) BinaryObjectOffHeapImpl leaked to public code
[
https://issues.apache.org/jira/browse/IGNITE-2835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Artem Shutak reassigned IGNITE-2835:
Assignee: Artem Shutak
> BinaryObjectOffHeapImpl leaked to public code
> -
>
> Key: IGNITE-2835
> URL: https://issues.apache.org/jira/browse/IGNITE-2835
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Artem Shutak
>Priority: Critical
> Labels: community, important
> Fix For: 1.6
>
> Attachments: BinaryObjectOffHeapIssue.java
>
>
> To my knowledge {{BinaryObjectOffHeapImpl}} is considered to be used under
> some internal lock only to prevent possible offheap pointer movement.
> However seems that we made it available to public code. If to start a
> partitioned cache in {{OFFHEAP_TIRED}} mode, get {{BinaryObject}} from the
> cache inside of a TX and put the same object back we will get exception like
> below
> {noformat}
> [15:00:00,892][WARN ][main][GridNearTxLocal] Set transaction invalidation
> flag to true due to error [tx=GridNearTxLocal [mappings=IgniteTxMappingsImpl
> [], nearLocallyMapped=false, colocatedLocallyMapped=true,
> needCheckBackup=null, hasRemoteLocks=false, mappings=IgniteTxMappingsImpl [],
> super=GridDhtTxLocalAdapter [nearOnOriginatingNode=false, nearNodes=[],
> dhtNodes=[], explicitLock=false, super=IgniteTxLocalAdapter
> [completedBase=null, sndTransformedVals=false, depEnabled=false,
> txState=IgniteTxStateImpl [activeCacheIds=GridLongList [idx=1,
> arr=[-1206548976]], txMap={IgniteTxKey [key=KeyCacheObjectImpl [val=0,
> hasValBytes=true], cacheId=-1206548976]=IgniteTxEntry [key=KeyCacheObjectImpl
> [val=0, hasValBytes=true], cacheId=-1206548976, txKey=IgniteTxKey
> [key=KeyCacheObjectImpl [val=0, hasValBytes=true], cacheId=-1206548976],
> val=[op=UPDATE, val=SomeType [idHash=1337835760, hash=0, field2=name_0,
> field1=0]], prevVal=[op=UPDATE, val=SomeType [idHash=1337835760, hash=0,
> field2=name_0, field1=0]], entryProcessorsCol=null, ttl=-1,
> conflictExpireTime=-1, conflictVer=null, explicitVer=null,
> dhtVer=GridCacheVersion [topVer=69523200, nodeOrderDrId=1,
> globalTime=1458043200871, order=1458043167489], filters=[],
> filtersPassed=false, filtersSet=true, entry=GridDhtColocatedCacheEntry
> [super=GridDhtCacheEntry [rdrs=[], locPart=GridDhtLocalPartition [id=0,
> mapPubSize=0, rmvQueue=GridCircularBuffer [sizeMask=255, idxGen=1], cntr=1,
> state=OWNING, reservations=0, empty=true, createTime=03/15/2016 15:00:00,
> mapPubSize=0], super=GridDistributedCacheEntry [super=GridCacheMapEntry
> [key=KeyCacheObjectImpl [val=0, hasValBytes=true], val=null,
> startVer=1458043167488, ver=GridCacheVersion [topVer=69523200,
> nodeOrderDrId=1, globalTime=1458043200890, order=1458043167490],
> hash=-1484017934, extras=GridCacheObsoleteEntryExtras
> [obsoleteVer=GridCacheVersion [topVer=69523200, nodeOrderDrId=1,
> globalTime=1458043200890, order=1458043167491]], flags=7, prepared=false,
> locked=true, nodeId=993f5733-b014-4a5b-a6d1-934aeec9e9f5, locMapped=false,
> expiryPlc=null, transferExpiryPlc=false, flags=2, partUpdateCntr=0,
> serReadVer=null, xidVer=GridCacheVersion [topVer=69523200, nodeOrderDrId=1,
> globalTime=1458043200852, order=1458043167487]]}], super=IgniteTxAdapter
> [xidVer=GridCacheVersion [topVer=69523200, nodeOrderDrId=1,
> globalTime=1458043200852, order=1458043167487], writeVer=GridCacheVersion
> [topVer=69523200, nodeOrderDrId=1, globalTime=1458043200871,
> order=1458043167489], implicit=false, loc=true, threadId=1,
> startTime=1458043200850, nodeId=993f5733-b014-4a5b-a6d1-934aeec9e9f5,
> startVer=GridCacheVersion [topVer=69523200, nodeOrderDrId=1,
> globalTime=1458043200852, order=1458043167487], endVer=null,
> isolation=REPEATABLE_READ, concurrency=PESSIMISTIC, timeout=0,
> sysInvalidate=true, sys=false, plc=2, commitVer=GridCacheVersion
> [topVer=69523200, nodeOrderDrId=1, globalTime=1458043200852,
> order=1458043167487], finalizing=NONE, preparing=false, invalidParts=null,
> state=UNKNOWN, timedOut=false, topVer=AffinityTopologyVersion [topVer=1,
> minorTopVer=1], duration=40ms, onePhaseCommit=true], size=1]]], err=class
> o.a.i.i.transactions.IgniteTxHeuristicCheckedException: Failed to locally
> write to cache (all transaction entries will be invalidated, however there
> was a window when entries for this transaction were visible to others):
> GridNearTxLocal [mappings=IgniteTxMappingsImpl [], nearLocallyMapped=false,
> colocatedLocallyMapped=true, needCheckBackup=null, hasRemoteLocks=false,
> mappings=IgniteTxMappingsImpl [], super=GridDhtTxLocalAdapter
> [nearOnOriginatingNode=false, nearNodes=[], dhtNodes=[], explicitLock=false,
> super=IgniteTxLocalAdapter
[jira] [Created] (IGNITE-2848) Ignite OSGI exit code 1 on TC
Artem Shutak created IGNITE-2848:
Summary: Ignite OSGI exit code 1 on TC
Key: IGNITE-2848
URL: https://issues.apache.org/jira/browse/IGNITE-2848
Project: Ignite
Issue Type: Bug
Reporter: Artem Shutak
http://204.14.53.153/viewLog.html?buildId=208978=buildResultsDiv=IgniteTests_IgniteOSGi
{noformat}
[09:20:59]Step 5/6: Build and run tests OSGi (Maven) (7m:17s)
[09:28:14][Step 5/6] org.apache.ignite:ignite-weblogic-test
[09:28:14][org.apache.ignite:ignite-weblogic-test] Failed to execute goal
org.apache.maven.plugins:maven-war-plugin:2.1.1:war (default-war) on project
ignite-weblogic-test: Failed to copy file for artifact
[org.apache.ignite:ignite-core:jar:1.6.0-SNAPSHOT:compile]
[09:28:16][Step 5/6] Step Build and run tests OSGi (Maven) failed
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2847) Failed atomic-offheap-invoke-retry load consistency test
[
https://issues.apache.org/jira/browse/IGNITE-2847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Artem Shutak updated IGNITE-2847:
-
Summary: Failed atomic-offheap-invoke-retry load consistency test (was:
Failed atomic-offheap-invoke-retry load test)
> Failed atomic-offheap-invoke-retry load consistency test
>
>
> Key: IGNITE-2847
> URL: https://issues.apache.org/jira/browse/IGNITE-2847
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.6
> Environment: Yardstick driver's host:
> Ubuntu 14.04.3 LTS
> Yardstick server's hosts: Ubuntu 14.04.3 LTS and CentOS release 6.7 (Final)
>Reporter: Ilya Suntsov
>Assignee: Artem Shutak
>Priority: Critical
> Fix For: 1.6
>
> Attachments: logs_configs.zip
>
>
> I ran load test with 2 backups in client mode (1 client, 4 servers) on 3
> hosts (host1 - client, hosts-2,3 - 2 data nodes on each) and got the
> following exception after 5h of work of test:
> {noformat}
> <13:49:20> Got
> exception:
> org.apache.ignite.yardstick.cache.failover.IgniteConsistencyException: Cache
> and local map are in inconsistent state [badKeys=[key-62687]]
> org.apache.ignite.yardstick.cache.failover.IgniteConsistencyException: Cache
> and local map are in inconsistent state
> [badKeys=[key-62687]]<13:49:20> Full thread
> dump of the current node below.
> {noformat}
> Logs in attachment.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1232) Support distributed SQL JOIN
[
https://issues.apache.org/jira/browse/IGNITE-1232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15195902#comment-15195902
]
Artem Shutak commented on IGNITE-1232:
--
Found that queries like {{select name from (select name from
"repl".Organization)}} fails with NPE (only in distributed joins case).
The issue is about new implementation of
{{GridH2IndexBase.getDistributedMultiplier}} for distributed joins support.
{noformat}
javax.cache.CacheException: class org.apache.ignite.IgniteException: Failed to
parse query: select name from (select name from "PARTITIONED_b1_3".Organization)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:669)
at
org.apache.ignite.internal.processors.query.h2.sql.AbstractH2CompareQueryTest.compareQueryRes0(AbstractH2CompareQueryTest.java:279)
at
org.apache.ignite.internal.processors.cache.IgniteCrossCachesDistributedJoinQueryTest.checkDistributedCrossCacheJoin(IgniteCrossCachesDistributedJoinQueryTest.java:428)
at
org.apache.ignite.internal.processors.cache.IgniteCrossCachesDistributedJoinQueryTest.testCrossCacheDistributedJoin(IgniteCrossCachesDistributedJoinQueryTest.java:313)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at junit.framework.TestCase.runTest(TestCase.java:176)
at
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1758)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:118)
at
org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1696)
at java.lang.Thread.run(Thread.java:745)
Caused by: class org.apache.ignite.IgniteException: Failed to parse query:
select name from (select name from "PARTITIONED_b1_3".Organization)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.queryTwoStep(GridQueryProcessor.java:734)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:660)
... 12 more
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to parse
query: select name from (select name from "PARTITIONED_b1_3".Organization)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:1680)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.queryTwoStep(GridQueryProcessor.java:727)
... 13 more
Caused by: javax.cache.CacheException: Failed to parse query: select name from
(select name from "PARTITIONED_b1_3".Organization)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryTwoStep(IgniteH2Indexing.java:1129)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$2.applyx(GridQueryProcessor.java:729)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$2.applyx(GridQueryProcessor.java:727)
at
org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:1662)
... 14 more
Caused by: org.h2.jdbc.JdbcSQLException: General error:
"java.lang.NullPointerException" [5-191]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
at org.h2.message.DbException.get(DbException.java:168)
at org.h2.message.DbException.convert(DbException.java:295)
at org.h2.message.DbException.toSQLException(DbException.java:268)
at org.h2.message.TraceObject.logAndConvert(TraceObject.java:352)
at org.h2.jdbc.JdbcConnection.prepareStatement(JdbcConnection.java:280)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.prepareStatement(IgniteH2Indexing.java:389)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryTwoStep(IgniteH2Indexing.java:1113)
... 18 more
Caused by: java.lang.NullPointerException
at
org.apache.ignite.internal.processors.query.h2.opt.GridH2CollocationModel.getSubQuery(GridH2CollocationModel.java:485)
at
org.apache.ignite.internal.processors.query.h2.opt.GridH2CollocationModel.child(GridH2CollocationModel.java:467)
at
org.apache.ignite.internal.processors.query.h2.opt.GridH2CollocationModel.buildCollocationModel(GridH2CollocationModel.java:556)
at
org.apache.ignite.internal.processors.query.h2.opt.GridH2CollocationModel.buildCollocationModel(GridH2CollocationModel.java:517)
at
[jira] [Assigned] (IGNITE-2645) Assertion error in ATOMIC cachce for invokeAll and cache store
[ https://issues.apache.org/jira/browse/IGNITE-2645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artem Shutak reassigned IGNITE-2645: Assignee: Artem Shutak > Assertion error in ATOMIC cachce for invokeAll and cache store > -- > > Key: IGNITE-2645 > URL: https://issues.apache.org/jira/browse/IGNITE-2645 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: ignite-1.4 >Reporter: Alexey Goncharuk >Assignee: Artem Shutak > Labels: community > Fix For: 1.6 > > Attachments: EntryProcessorFails.java > > > Assertion happens under the following conditions: > * Cache is empty > * Cache store contains non-null values for some keys > * invokeAll is invoked for those keys > Update version is generated when update request reaches the primary node. > Then, we need to read-through stored values (the cache is empty) and pass > them to transformers. Since read-through changes entry version, subsequent > update fails with an assertion because read-through version is generated > later than update version. > The scenario when a read-through is implemented via a separate loop with > innerGet() is possible only with invokeAll() because this is the only > multi-key cache operation that requires the previous entry value. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1232) Support distributed SQL JOIN
[ https://issues.apache.org/jira/browse/IGNITE-1232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15174171#comment-15174171 ] Artem Shutak commented on IGNITE-1232: -- Added IgniteCrossCachesDistributedJoinQueryTest. Test fails for many configurations of caches. Need to investigate. > Support distributed SQL JOIN > - > > Key: IGNITE-1232 > URL: https://issues.apache.org/jira/browse/IGNITE-1232 > Project: Ignite > Issue Type: Improvement >Reporter: Sergi Vladykin >Assignee: Sergi Vladykin > Fix For: 1.6 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-2554) Affinity.mapKeyToNode() method throw "ArithmeticException: / by zero" for LOCAL dinamically started cache
[
https://issues.apache.org/jira/browse/IGNITE-2554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Artem Shutak resolved IGNITE-2554.
--
Resolution: Fixed
The simple fix was done, reviewed and merged in bounds of IGNITE-2521
(#953b575).
Did issue (IGNITE-2733) to fix it properly.
> Affinity.mapKeyToNode() method throw "ArithmeticException: / by zero" for
> LOCAL dinamically started cache
> -
>
> Key: IGNITE-2554
> URL: https://issues.apache.org/jira/browse/IGNITE-2554
> Project: Ignite
> Issue Type: Bug
>Reporter: Artem Shutak
>Assignee: Artem Shutak
>Priority: Minor
>
> Affinity.mapKeyToNode() method throw "ArithmeticException: / by zero" for
> LOCAL cache.
> The following code
> {code}
> public static void main(String[] args) {
> try (Ignite ignite = Ignition.start(new IgniteConfiguration())) {
> CacheConfiguration cc = new CacheConfiguration();
> cc.setCacheMode(LOCAL);
> cc.setName("myCache");
> ignite.getOrCreateCache(cc);
> ignite.affinity("myCache").mapKeyToNode("myKey");
> }
> }
> {code}
> Produce the following exception.
> {noformat}
> Exception in thread "main" java.lang.ArithmeticException: / by zero
> at
> org.apache.ignite.internal.processors.cache.affinity.GridCacheAffinityImpl.mapKeysToNodes(GridCacheAffinityImpl.java:210)
> at
> org.apache.ignite.internal.processors.cache.affinity.GridCacheAffinityImpl.mapKeyToNode(GridCacheAffinityImpl.java:187)
> at main
> {noformat}
> The issue is {{cctx.discovery().cacheAffinityNodes(cctx.name(), topVer)}}
> returns empty nodes collection.
> If cache started on node start then there is no exception.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2733) Ignite should use actual AffinityTopologyVersion for LOCAL cache
[
https://issues.apache.org/jira/browse/IGNITE-2733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Artem Shutak updated IGNITE-2733:
-
Description:
The issue created to properly fix IGNITE-2554. Also, current behavior can has
another issues with dynamically started LOCAL cache.
Ignite does not store an affinity assignment history for local cache and always
operate with {{AffinityTopologyVersion(1)}}. When cache starts dynamically, an
information about dynamically started cache is available only for
{{AffinityTopologyVersion(1, 1)}}, but Ignite does not store it. Proper fix
should be:
* There is no need to store all history for local cache (as Ignite do it now).
So, we need just update the head topology version (see
GridAffinityAssignmentCache.head field)
* We must return right topology version at all project. See, for example,
{{GridCacheAffinityManager}} and the following code
{code}
if (cctx.isLocal())
topVer = new AffinityTopologyVersion(1);
{code}
was:
The issue created to properly fix IGNITE-2554. Also, current behavior can has
another issues with dynamically started LOCAL cache.
Ignite does not store an affinity assignment history for local cache and always
operate with {{AffinityTopologyVersion(1)}}. When cache starts dynamically, an
information about dynamically started cache is available only for
{{AffinityTopologyVersion(1, 1)}}, but Ignite does not store it. Proper fix
should be:
#* There is no need to store all history for local cache (as Ignite do it now).
So, we need just update the head topology version (see
GridAffinityAssignmentCache.head field)
#* We must return right topology version at all project. See, for example,
{{GridCacheAffinityManager}} and the following code
{code}
if (cctx.isLocal())
topVer = new AffinityTopologyVersion(1);
{code}
> Ignite should use actual AffinityTopologyVersion for LOCAL cache
>
>
> Key: IGNITE-2733
> URL: https://issues.apache.org/jira/browse/IGNITE-2733
> Project: Ignite
> Issue Type: Task
>Reporter: Artem Shutak
>Priority: Minor
>
> The issue created to properly fix IGNITE-2554. Also, current behavior can has
> another issues with dynamically started LOCAL cache.
> Ignite does not store an affinity assignment history for local cache and
> always operate with {{AffinityTopologyVersion(1)}}. When cache starts
> dynamically, an information about dynamically started cache is available only
> for {{AffinityTopologyVersion(1, 1)}}, but Ignite does not store it. Proper
> fix should be:
> * There is no need to store all history for local cache (as Ignite do it
> now). So, we need just update the head topology version (see
> GridAffinityAssignmentCache.head field)
> * We must return right topology version at all project. See, for example,
> {{GridCacheAffinityManager}} and the following code
> {code}
> if (cctx.isLocal())
> topVer = new AffinityTopologyVersion(1);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (IGNITE-2554) Affinity.mapKeyToNode() method throw "ArithmeticException: / by zero" for LOCAL dinamically started cache
[
https://issues.apache.org/jira/browse/IGNITE-2554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Artem Shutak reassigned IGNITE-2554:
Assignee: Artem Shutak
> Affinity.mapKeyToNode() method throw "ArithmeticException: / by zero" for
> LOCAL dinamically started cache
> -
>
> Key: IGNITE-2554
> URL: https://issues.apache.org/jira/browse/IGNITE-2554
> Project: Ignite
> Issue Type: Bug
>Reporter: Artem Shutak
>Assignee: Artem Shutak
>Priority: Minor
>
> Affinity.mapKeyToNode() method throw "ArithmeticException: / by zero" for
> LOCAL cache.
> The following code
> {code}
> public static void main(String[] args) {
> try (Ignite ignite = Ignition.start(new IgniteConfiguration())) {
> CacheConfiguration cc = new CacheConfiguration();
> cc.setCacheMode(LOCAL);
> cc.setName("myCache");
> ignite.getOrCreateCache(cc);
> ignite.affinity("myCache").mapKeyToNode("myKey");
> }
> }
> {code}
> Produce the following exception.
> {noformat}
> Exception in thread "main" java.lang.ArithmeticException: / by zero
> at
> org.apache.ignite.internal.processors.cache.affinity.GridCacheAffinityImpl.mapKeysToNodes(GridCacheAffinityImpl.java:210)
> at
> org.apache.ignite.internal.processors.cache.affinity.GridCacheAffinityImpl.mapKeyToNode(GridCacheAffinityImpl.java:187)
> at main
> {noformat}
> The issue is {{cctx.discovery().cacheAffinityNodes(cctx.name(), topVer)}}
> returns empty nodes collection.
> If cache started on node start then there is no exception.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2733) Ignite should use actual AffinityTopologyVersion for LOCAL cache
[
https://issues.apache.org/jira/browse/IGNITE-2733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Artem Shutak updated IGNITE-2733:
-
Priority: Minor (was: Major)
> Ignite should use actual AffinityTopologyVersion for LOCAL cache
>
>
> Key: IGNITE-2733
> URL: https://issues.apache.org/jira/browse/IGNITE-2733
> Project: Ignite
> Issue Type: Task
>Reporter: Artem Shutak
>Priority: Minor
>
> The issue created to properly fix IGNITE-2554. Also, current behavior can has
> another issues with dynamically started LOCAL cache.
> Ignite does not store an affinity assignment history for local cache and
> always operate with {{AffinityTopologyVersion(1)}}. When cache starts
> dynamically, an information about dynamically started cache is available only
> for {{AffinityTopologyVersion(1, 1)}}, but Ignite does not store it. Proper
> fix should be:
> #* There is no need to store all history for local cache (as Ignite do it
> now). So, we need just update the head topology version (see
> GridAffinityAssignmentCache.head field)
> #* We must return right topology version at all project. See, for example,
> {{GridCacheAffinityManager}} and the following code
> {code}
> if (cctx.isLocal())
> topVer = new AffinityTopologyVersion(1);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2733) Ignite should use actual AffinityTopologyVersion for LOCAL cache
[
https://issues.apache.org/jira/browse/IGNITE-2733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15171802#comment-15171802
]
Artem Shutak commented on IGNITE-2733:
--
Set priority to minor as long as there is no related to the issue bugs.
> Ignite should use actual AffinityTopologyVersion for LOCAL cache
>
>
> Key: IGNITE-2733
> URL: https://issues.apache.org/jira/browse/IGNITE-2733
> Project: Ignite
> Issue Type: Task
>Reporter: Artem Shutak
>
> The issue created to properly fix IGNITE-2554. Also, current behavior can has
> another issues with dynamically started LOCAL cache.
> Ignite does not store an affinity assignment history for local cache and
> always operate with {{AffinityTopologyVersion(1)}}. When cache starts
> dynamically, an information about dynamically started cache is available only
> for {{AffinityTopologyVersion(1, 1)}}, but Ignite does not store it. Proper
> fix should be:
> #* There is no need to store all history for local cache (as Ignite do it
> now). So, we need just update the head topology version (see
> GridAffinityAssignmentCache.head field)
> #* We must return right topology version at all project. See, for example,
> {{GridCacheAffinityManager}} and the following code
> {code}
> if (cctx.isLocal())
> topVer = new AffinityTopologyVersion(1);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-2733) Ignite should use actual AffinityTopologyVersion for LOCAL cache
Artem Shutak created IGNITE-2733:
Summary: Ignite should use actual AffinityTopologyVersion for
LOCAL cache
Key: IGNITE-2733
URL: https://issues.apache.org/jira/browse/IGNITE-2733
Project: Ignite
Issue Type: Task
Reporter: Artem Shutak
The issue created to properly fix IGNITE-2554. Also, current behavior can has
another issues with dynamically started LOCAL cache.
Ignite does not store an affinity assignment history for local cache and always
operate with {{AffinityTopologyVersion(1)}}. When cache starts dynamically, an
information about dynamically started cache is available only for
{{AffinityTopologyVersion(1, 1)}}, but Ignite does not store it. Proper fix
should be:
#* There is no need to store all history for local cache (as Ignite do it now).
So, we need just update the head topology version (see
GridAffinityAssignmentCache.head field)
#* We must return right topology version at all project. See, for example,
{{GridCacheAffinityManager}} and the following code
{code}
if (cctx.isLocal())
topVer = new AffinityTopologyVersion(1);
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2521) Need to increase test coverage (support all configurations combinations)
[ https://issues.apache.org/jira/browse/IGNITE-2521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15171786#comment-15171786 ] Artem Shutak commented on IGNITE-2521: -- Reviewed and merged by Yakov (#953b575). > Need to increase test coverage (support all configurations combinations) > > > Key: IGNITE-2521 > URL: https://issues.apache.org/jira/browse/IGNITE-2521 > Project: Ignite > Issue Type: Task >Reporter: Artem Shutak >Assignee: Artem Shutak > > The purpose of this ticket is to make sure that all cache operations should > work for any config props combination. > New test suite should be created. Cache full API tests should be used as > start point. > The following tests should be added (for functional blocks): > # Interceptor > # Queries: continuous, scan, SQL, fields and text queries. > # cache events > # We should also test with Serializable, Externalizable, and plain Pojos for > keys and values. > # The Pojo in the above test should contain an enum value > # We should also test Enums as keys and Enums as values > # All operations should have single-key and multi-key operations > New tests should cover all combinations for following properties: > # cache modes > # operation from client nodes and server nodes > # store enabled/disabled > # evicts sycn/non-sync > # eviction policies > # near on/off > # marshallers (+ Binary marshaller with different mappers) > # keys and values (data modes) - externalizable, serializable, binaryzable, > enums, proxy, "none of previous" > # classes available on servers: true/false > # Peer loading on/off > # Affinity functions > # expiry policies > One more thing for new tests: I think test should start both server and > client nodes and use Ignite API from all nodes. > Design notes > # New tests should accept cache/grid configuration on creation or via setter > method > # Enclosing suite should have a collection of all configurations prebuilt or > should be able to generate the full set of configurations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1232) Support distributed SQL JOIN
[
https://issues.apache.org/jira/browse/IGNITE-1232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15169573#comment-15169573
]
Artem Shutak commented on IGNITE-1232:
--
Guys,
I've written a simple test on distributed SQL join using cross cache joins and
got SQL parsing exception that a schema does not exist. When I collocate data
(using {{@AffinityKeyMapped}}) then the same query get parsed and executed.
Should cross cache joins work or is it expected behavior?
> Support distributed SQL JOIN
> -
>
> Key: IGNITE-1232
> URL: https://issues.apache.org/jira/browse/IGNITE-1232
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergi Vladykin
>Assignee: Sergi Vladykin
> Fix For: 1.6
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2521) Need to increase test coverage (support all configurations combinations)
[ https://issues.apache.org/jira/browse/IGNITE-2521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artem Shutak updated IGNITE-2521: - Description: The purpose of this ticket is to make sure that all cache operations should work for any config props combination. New test suite should be created. Cache full API tests should be used as start point. The following tests should be added (for functional blocks): # Interceptor # Queries: continuous, scan, SQL, fields and text queries. # cache events # We should also test with Serializable, Externalizable, and plain Pojos for keys and values. # The Pojo in the above test should contain an enum value # We should also test Enums as keys and Enums as values # All operations should have single-key and multi-key operations New tests should cover all combinations for following properties: # cache modes # operation from client nodes and server nodes # store enabled/disabled # evicts sycn/non-sync # eviction policies # near on/off # marshallers (+ Binary marshaller with different mappers) # keys and values (data modes) - externalizable, serializable, binaryzable, enums, proxy, "none of previous" # classes available on servers: true/false # Peer loading on/off # Affinity functions # expiry policies One more thing for new tests: I think test should start both server and client nodes and use Ignite API from all nodes. Design notes # New tests should accept cache/grid configuration on creation or via setter method # Enclosing suite should have a collection of all configurations prebuilt or should be able to generate the full set of configurations. was: The purpose of this ticket is to make sure that all cache operations should work for any config props combination. New test suite should be created. Cache full API tests should be used as start point. The following tests should be added (for functional blocks): # Interceptor # Queries: continuous, scan, SQL, fields and text queries. # cache events # We should also test with Serializable, Externalizable, and plain Pojos for keys and values. # The Pojo in the above test should contain an enum value # We should also test Enums as keys and Enums as values # All operations should have single-key and multi-key operations New tests should cover all combinations for following properties: # cache modes # operation from client nodes and server nodes # store enabled/disabled # evicts sycn/non-sync # eviction policies # near on/off # marshallers (+ Binary marshaller with different mappers) # keys and values - externalizable, serializable, binaryzable, "none of previous" # classes available on servers: true/false # Peer loading on/off # Affinity functions # expiry policies One more thing for new tests: I think test should start both server and client nodes and use Ignite API from all nodes. Design notes # New tests should accept cache/grid configuration on creation or via setter method # Enclosing suite should have a collection of all configurations prebuilt or should be able to generate the full set of configurations. > Need to increase test coverage (support all configurations combinations) > > > Key: IGNITE-2521 > URL: https://issues.apache.org/jira/browse/IGNITE-2521 > Project: Ignite > Issue Type: Task >Reporter: Artem Shutak >Assignee: Artem Shutak > > The purpose of this ticket is to make sure that all cache operations should > work for any config props combination. > New test suite should be created. Cache full API tests should be used as > start point. > The following tests should be added (for functional blocks): > # Interceptor > # Queries: continuous, scan, SQL, fields and text queries. > # cache events > # We should also test with Serializable, Externalizable, and plain Pojos for > keys and values. > # The Pojo in the above test should contain an enum value > # We should also test Enums as keys and Enums as values > # All operations should have single-key and multi-key operations > New tests should cover all combinations for following properties: > # cache modes > # operation from client nodes and server nodes > # store enabled/disabled > # evicts sycn/non-sync > # eviction policies > # near on/off > # marshallers (+ Binary marshaller with different mappers) > # keys and values (data modes) - externalizable, serializable, binaryzable, > enums, proxy, "none of previous" > # classes available on servers: true/false > # Peer loading on/off > # Affinity functions > # expiry policies > One more thing for new tests: I think test should start both server and > client nodes and use Ignite API from all nodes. > Design notes > # New tests should accept cache/grid configuration on creation or via setter > method > # Enclosing suite should have a collection of all configurations prebuilt or >
