[jira] [Commented] (IGNITE-4498) .NET: Remove legacy BinaryObject.Equals
[
https://issues.apache.org/jira/browse/IGNITE-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15937827#comment-15937827
]
Pavel Tupitsyn commented on IGNITE-4498:
After IGNITE-4351 is done, we can simply remove legacy code part and rely on
comparer.
> .NET: Remove legacy BinaryObject.Equals
> ---
>
> Key: IGNITE-4498
> URL: https://issues.apache.org/jira/browse/IGNITE-4498
> Project: Ignite
> Issue Type: Task
> Components: platforms
>Reporter: Pavel Tupitsyn
>Priority: Critical
> Labels: .NET, breaking
> Fix For: 2.0
>
>
> Remove legacy field-by-field comparison from {{BinaryObject.Equals}}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (IGNITE-4351) .NET: Use BinaryArrayIdentityResolver by default
[ https://issues.apache.org/jira/browse/IGNITE-4351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-4351: -- Assignee: Pavel Tupitsyn > .NET: Use BinaryArrayIdentityResolver by default > > > Key: IGNITE-4351 > URL: https://issues.apache.org/jira/browse/IGNITE-4351 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Critical > Labels: .NET, breaking-api > Fix For: 2.0 > > > Current legacy behavior calculates hash codes by calling > Object.GetHashCode(), but equality comparison is performed by comparing byte > arrays in binary form, which is inconsistent and can lead to unexpected > behavior with user-defined keys. > In 2.0 we should replace default behavior with ArrayResolver so that Equals > and GetHashCode are consistent. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-4669) .NET: Sort binary object fields
[
https://issues.apache.org/jira/browse/IGNITE-4669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-4669:
---
Priority: Critical (was: Major)
> .NET: Sort binary object fields
> ---
>
> Key: IGNITE-4669
> URL: https://issues.apache.org/jira/browse/IGNITE-4669
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
>Priority: Critical
> Labels: .NET
> Fix For: 2.0
>
>
> Make sure that fields are sorted by name in all cases:
> * Reflective serializer
> * {{IBinarizable}} serialization
> * {{[Serializable]}} serialization
> * Custom serializer
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (IGNITE-4856) .NET: StopAll on AppDomain unload
[
https://issues.apache.org/jira/browse/IGNITE-4856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn reassigned IGNITE-4856:
--
Assignee: (was: Pavel Tupitsyn)
> .NET: StopAll on AppDomain unload
> -
>
> Key: IGNITE-4856
> URL: https://issues.apache.org/jira/browse/IGNITE-4856
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Affects Versions: 1.6
>Reporter: Pavel Tupitsyn
> Labels: .NET
> Fix For: 2.1
>
>
> In certain scenarios .NET {{AppDomain}} can be unloaded and started again.
> Java part of Ignite continues to run, but .NET part (including Ignite
> instances) is lost. User can no longer work with started nodes, .NET callback
> pointers are lost, etc.
> We should track AppDomain unload and stop all Ignite instances.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (IGNITE-4211) Update Spring dependency to latest stable version
[ https://issues.apache.org/jira/browse/IGNITE-4211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15937782#comment-15937782 ] Vyacheslav Daradur edited comment on IGNITE-4211 at 3/23/17 6:18 AM: - [~avinogradov] I knew about spring-aop-methods before, but I couldn't understand what you want. (applies to the your comment on the Upsource) bq. What? As I've written here before, I think we have to cover the all new code with unit tests (if possible and where necessary). I've added the new get-method. public T get(Object key, Callable valueLoader) And I think we have to tests the following cases: - valueLoader parameter was called only once per same key; - if a cache contains nothing for a key, a result of valueLoader parameter will added to the cache correctly; - if valueLoader parameter throws some exceptions, the new get-method rethrows the excepted type of exception; These are main cases wich described in the java-docs on the new method. All cases above were checked in the unit-tests which you don't like. bq. Why? Just make that the any get-methods returned "null". What happens? - Nothing. Green light in the GridSpringCacheManagerSelfTest. Tests in the GridSpringCacheManagerSelfTest don't check correct behavior of get-methods. Maybe I'm wrong and returned value are checked in the other tests. (other cases of behavior?) (upd.I found the bug IGNITE-4823, when SpringCache was covered with unit-tests) If you don't agree with my approach, and if the test of @Cachenable(sync=true) is enough for you: Just write it, I will change the test and then it's done. Such simple task was delayed for a long time. was (Author: daradurvs): [~avinogradov] I knew about spring-aop-methods before, but I couldn't understand what you want. (applies to the your comment on the Upsource) bq. What? As I've written here before, I think we have to cover the all new code with unit tests (if possible and where necessary). I've added the new get-method. public T get(Object key, Callable valueLoader) And I think we have to tests the following cases: - valueLoader parameter was called only once per same key; - if a cache contains nothing for a key, a result of valueLoader parameter will added to the cache correctly; - if valueLoader parameter throws some exceptions, the new get-method rethrows the excepted type of exception; These are main cases wich described in the java-docs on the new method. All cases above were checked in the unit-tests which you don't like. bq. Why? Just make that the any get-methods returned "null". What happens? - Nothing. Green light in the GridSpringCacheManagerSelfTest. Tests in the GridSpringCacheManagerSelfTest don't check correct behavior of get-methods. Maybe I'm wrong and returned value are checked in the other tests. (other cases of behavior?) If you don't agree with my approach, and if the test of @Cachenable(sync=true) is enough for you: Just write it, I will change the test and then it's done. Such simple task was delayed for a long time. > Update Spring dependency to latest stable version > - > > Key: IGNITE-4211 > URL: https://issues.apache.org/jira/browse/IGNITE-4211 > Project: Ignite > Issue Type: Improvement > Components: build >Affects Versions: 1.7 >Reporter: Sergey Kozlov >Assignee: Vyacheslav Daradur > Fix For: 2.0 > > > It seems the Spring dependency looks outdated for now. Apache Ignite still > uses 4.1.0 released two years ago. Could we to update to latest stable > version (4.3.4 at the moment)? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-4498) .NET: Remove legacy BinaryObject.Equals
[
https://issues.apache.org/jira/browse/IGNITE-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-4498:
---
Priority: Critical (was: Major)
> .NET: Remove legacy BinaryObject.Equals
> ---
>
> Key: IGNITE-4498
> URL: https://issues.apache.org/jira/browse/IGNITE-4498
> Project: Ignite
> Issue Type: Task
> Components: platforms
>Reporter: Pavel Tupitsyn
>Priority: Critical
> Labels: .NET, breaking
> Fix For: 2.0
>
>
> Remove legacy field-by-field comparison from {{BinaryObject.Equals}}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-4351) .NET: Use BinaryArrayIdentityResolver by default
[ https://issues.apache.org/jira/browse/IGNITE-4351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-4351: --- Priority: Critical (was: Major) > .NET: Use BinaryArrayIdentityResolver by default > > > Key: IGNITE-4351 > URL: https://issues.apache.org/jira/browse/IGNITE-4351 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Pavel Tupitsyn >Priority: Critical > Labels: .NET, breaking-api > Fix For: 2.0 > > > Current legacy behavior calculates hash codes by calling > Object.GetHashCode(), but equality comparison is performed by comparing byte > arrays in binary form, which is inconsistent and can lead to unexpected > behavior with user-defined keys. > In 2.0 we should replace default behavior with ArrayResolver so that Equals > and GetHashCode are consistent. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-3508) .NET: Make ICache implement IDictionary
[ https://issues.apache.org/jira/browse/IGNITE-3508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-3508: --- Priority: Minor (was: Major) > .NET: Make ICache implement IDictionary > --- > > Key: IGNITE-3508 > URL: https://issues.apache.org/jira/browse/IGNITE-3508 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Pavel Tupitsyn >Priority: Minor > Labels: .net, breaking-api > Fix For: 2.0 > > > ICache is essentially a dictionary. Implementing IDictionary will > provide a familiar interface to the users. > However, this may require us to remove ICacheEntry interface and switch to > KeyValuePair, since this is what IDictionary operates on. KeyValuePair is > also a struct, so this may improve performance in certain cases. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (IGNITE-4211) Update Spring dependency to latest stable version
[ https://issues.apache.org/jira/browse/IGNITE-4211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15937782#comment-15937782 ] Vyacheslav Daradur edited comment on IGNITE-4211 at 3/23/17 6:07 AM: - [~avinogradov] I knew about spring-aop-methods before, but I couldn't understand what you want. (applies to the your comment on the Upsource) bq. What? As I've written here before, I think we have to cover the all new code with unit tests (if possible and where necessary). I've added the new get-method. public T get(Object key, Callable valueLoader) And I think we have to tests the following cases: - valueLoader parameter was called only once per same key; - if a cache contains nothing for a key, a result of valueLoader parameter will added to the cache correctly; - if valueLoader parameter throws some exceptions, the new get-method rethrows the excepted type of exception; These are main cases wich described in the java-docs on the new method. All cases above were checked in the unit-tests which you don't like. bq. Why? Just make that the any get-methods returned "null". What happens? - Nothing. Green light in the GridSpringCacheManagerSelfTest. Tests in the GridSpringCacheManagerSelfTest don't check correct behavior of get-methods. Maybe I'm wrong and returned value are checked in the other tests. (other cases of behavior?) If you don't agree with my approach, and if the test of @Cachenable(sync=true) is enough for you: Just write it, I will change the test and then it's done. Such simple task was delayed for a long time. was (Author: daradurvs): [~avinogradov] I knew about spring-aop-methods before, but I couldn't understand what you want. bq. What? As I've written here before, I think we have to cover the all new code with unit tests (if possible and where necessary). I've added the new get-method. public T get(Object key, Callable valueLoader) And I think we have to tests the following cases: - valueLoader parameter was called only once per same key; - if a cache contains nothing for a key, a result of valueLoader parameter will added to the cache correctly; - if valueLoader parameter throws some exceptions, the new get-method rethrows the excepted type of exception; These are main cases wich described in the java-docs on the new method. All cases above were checked in the unit-tests which you don't like. bq. Why? Just make that the any get-methods returned "null". What happens? - Nothing. Green light in the GridSpringCacheManagerSelfTest. Tests in the GridSpringCacheManagerSelfTest don't check correct behavior of get-methods. Maybe I'm wrong and returned value are checked in the other tests. (other cases of behavior?) If you don't agree with my approach, and if the test of @Cachenable(sync=true) is enough for you: Just write it, I will change the test and then it's done. Such simple task was delayed for a long time. > Update Spring dependency to latest stable version > - > > Key: IGNITE-4211 > URL: https://issues.apache.org/jira/browse/IGNITE-4211 > Project: Ignite > Issue Type: Improvement > Components: build >Affects Versions: 1.7 >Reporter: Sergey Kozlov >Assignee: Vyacheslav Daradur > Fix For: 2.0 > > > It seems the Spring dependency looks outdated for now. Apache Ignite still > uses 4.1.0 released two years ago. Could we to update to latest stable > version (4.3.4 at the moment)? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (IGNITE-4211) Update Spring dependency to latest stable version
[ https://issues.apache.org/jira/browse/IGNITE-4211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15937782#comment-15937782 ] Vyacheslav Daradur edited comment on IGNITE-4211 at 3/23/17 6:04 AM: - [~avinogradov] I knew about spring-aop-methods before, but I couldn't understand what you want. bq. What? As I've written here before, I think we have to cover the all new code with unit tests (if possible and where necessary). I've added the new get-method. public T get(Object key, Callable valueLoader) And I think we have to tests the following cases: - valueLoader parameter was called only once per same key; - if a cache contains nothing for a key, a result of valueLoader parameter will added to the cache correctly; - if valueLoader parameter throws some exceptions, the new get-method rethrows the excepted type of exception; These are main cases wich described in the java-docs on the new method. All cases above were checked in the unit-tests which you don't like. bq. Why? Just make that the any get-methods returned "null". What happens? - Nothing. Green light in the GridSpringCacheManagerSelfTest. Tests in the GridSpringCacheManagerSelfTest don't check correct behavior of get-methods. Maybe I'm wrong and returned value are checked in the other tests. (other cases of behavior?) If you don't agree with my approach, and if the test of @Cachenable(sync=true) is enough for you: Just write it, I will change the test and then it's done. Such simple task was delayed for a long time. was (Author: daradurvs): [~avinogradov] I knew about spring-aop-methods before, but I couldn't understand what you want. bq. What? As I've written here before, I think we have to cover with the all new code unit tests, if possible and where necessary. I've added the new get-method. public T get(Object key, Callable valueLoader) And I think we have to tests the following cases: - valueLoader parameter calls only once per same key; - if cache contain nothing for key, result of valueLoader parameter will added to cache correctly; - if valueLoader parameter throws some exceptions, new get-method rethrow the excepted type of exception; These are main cases wich described in the java-docs on the new method. All cases above were checked in the unit-tests which you don't like. bq. Why? Just make that the any get-methods returned "null". What happens? - Nothing. Green light in the GridSpringCacheManagerSelfTest. Tests in the GridSpringCacheManagerSelfTest don't check correct behavior of get-methods. Maybe I'm wrong and returned value are checked in the other tests. (other cases of behavior?) If you don't agree with my approach, and if the test of @Cachenable(sync=true) is enough for you: Just write it, I will change the test and then it's done. Such simple task was delayed for a long time. > Update Spring dependency to latest stable version > - > > Key: IGNITE-4211 > URL: https://issues.apache.org/jira/browse/IGNITE-4211 > Project: Ignite > Issue Type: Improvement > Components: build >Affects Versions: 1.7 >Reporter: Sergey Kozlov >Assignee: Vyacheslav Daradur > Fix For: 2.0 > > > It seems the Spring dependency looks outdated for now. Apache Ignite still > uses 4.1.0 released two years ago. Could we to update to latest stable > version (4.3.4 at the moment)? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4211) Update Spring dependency to latest stable version
[ https://issues.apache.org/jira/browse/IGNITE-4211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15937782#comment-15937782 ] Vyacheslav Daradur commented on IGNITE-4211: [~avinogradov] I knew about spring-aop-methods before, but I couldn't understand what you want. bq. What? As I've written here before, I think we have to cover with the all new code unit tests, if possible and where necessary. I've added the new get-method. public T get(Object key, Callable valueLoader) And I think we have to tests the following cases: - valueLoader parameter calls only once per same key; - if cache contain nothing for key, result of valueLoader parameter will added to cache correctly; - if valueLoader parameter throws some exceptions, new get-method rethrow the excepted type of exception; These are main cases wich described in the java-docs on the new method. All cases above were checked in the unit-tests which you don't like. bq. Why? Just make that the any get-methods returned "null". What happens? - Nothing. Green light in the GridSpringCacheManagerSelfTest. Tests in the GridSpringCacheManagerSelfTest don't check correct behavior of get-methods. Maybe I'm wrong and returned value are checked in the other tests. (other cases of behavior?) If you don't agree with my approach, and if the test of @Cachenable(sync=true) is enough for you: Just write it, I will change the test and then it's done. Such simple task was delayed for a long time. > Update Spring dependency to latest stable version > - > > Key: IGNITE-4211 > URL: https://issues.apache.org/jira/browse/IGNITE-4211 > Project: Ignite > Issue Type: Improvement > Components: build >Affects Versions: 1.7 >Reporter: Sergey Kozlov >Assignee: Vyacheslav Daradur > Fix For: 2.0 > > > It seems the Spring dependency looks outdated for now. Apache Ignite still > uses 4.1.0 released two years ago. Could we to update to latest stable > version (4.3.4 at the moment)? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (IGNITE-2997) Failed to get field because type ID of passed object differs from type ID this BinaryField
[
https://issues.apache.org/jira/browse/IGNITE-2997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stanilovsky Evgeny resolved IGNITE-2997.
Resolution: Cannot Reproduce
i close this ticket, can`t reproduce.
> Failed to get field because type ID of passed object differs from type ID
> this BinaryField
> --
>
> Key: IGNITE-2997
> URL: https://issues.apache.org/jira/browse/IGNITE-2997
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Vladislav Pyatkov
>Assignee: Stanilovsky Evgeny
> Attachments: Main2.java
>
>
> I have got this exception when had been developing cache load benchmark.
> This exception reproduced in configuration of cache:
> {code}
>
>
>
>
>
>
>
>
> java.lang.Integer
> org.apache.ignite.yardstick.cache.model.Organization
> java.lang.Integer
> org.apache.ignite.yardstick.cache.model.Person
>
>
>
> {code}
> {noformat}
> [18:00:39,708][ERROR][benchmark-worker-43][GridDhtAtomicCache]
> Unexpected exception during cache update
> class org.apache.ignite.binary.BinaryObjectException: Failed to get field
> because type ID of passed object differs from type ID this BinaryField
> belongs to [expected=-865473396, actual=1199651114]
> at
> org.apache.ignite.internal.binary.BinaryFieldImpl.fieldOrder(BinaryFieldImpl.java:92)
> at
> org.apache.ignite.internal.binary.BinaryFieldImpl.value(BinaryFieldImpl.java:79)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$BinaryProperty.fieldValue(GridQueryProcessor.java:2051)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$BinaryProperty.value(GridQueryProcessor.java:2011)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$RowDescriptor.columnValue(IgniteH2Indexing.java:2498)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2AbstractKeyValueRow.getValue(GridH2AbstractKeyValueRow.java:289)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2IndexBase.compareRows(GridH2IndexBase.java:116)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2TreeIndex.compare(GridH2TreeIndex.java:248)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2TreeIndex.compare(GridH2TreeIndex.java:49)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap$2.compareTo(GridOffHeapSnapTreeMap.java:1350)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap$2.compareTo(GridOffHeapSnapTreeMap.java:1346)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2102)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2217)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2217)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2217)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2217)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2217)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2217)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2217)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2217)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2217)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2217)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2217)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2217)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2217)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2217)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2217)
> at
> org.apache.ignite.inter
[jira] [Assigned] (IGNITE-2997) Failed to get field because type ID of passed object differs from type ID this BinaryField
[
https://issues.apache.org/jira/browse/IGNITE-2997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stanilovsky Evgeny reassigned IGNITE-2997:
--
Assignee: Stanilovsky Evgeny
> Failed to get field because type ID of passed object differs from type ID
> this BinaryField
> --
>
> Key: IGNITE-2997
> URL: https://issues.apache.org/jira/browse/IGNITE-2997
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Vladislav Pyatkov
>Assignee: Stanilovsky Evgeny
> Attachments: Main2.java
>
>
> I have got this exception when had been developing cache load benchmark.
> This exception reproduced in configuration of cache:
> {code}
>
>
>
>
>
>
>
>
> java.lang.Integer
> org.apache.ignite.yardstick.cache.model.Organization
> java.lang.Integer
> org.apache.ignite.yardstick.cache.model.Person
>
>
>
> {code}
> {noformat}
> [18:00:39,708][ERROR][benchmark-worker-43][GridDhtAtomicCache]
> Unexpected exception during cache update
> class org.apache.ignite.binary.BinaryObjectException: Failed to get field
> because type ID of passed object differs from type ID this BinaryField
> belongs to [expected=-865473396, actual=1199651114]
> at
> org.apache.ignite.internal.binary.BinaryFieldImpl.fieldOrder(BinaryFieldImpl.java:92)
> at
> org.apache.ignite.internal.binary.BinaryFieldImpl.value(BinaryFieldImpl.java:79)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$BinaryProperty.fieldValue(GridQueryProcessor.java:2051)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$BinaryProperty.value(GridQueryProcessor.java:2011)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$RowDescriptor.columnValue(IgniteH2Indexing.java:2498)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2AbstractKeyValueRow.getValue(GridH2AbstractKeyValueRow.java:289)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2IndexBase.compareRows(GridH2IndexBase.java:116)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2TreeIndex.compare(GridH2TreeIndex.java:248)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2TreeIndex.compare(GridH2TreeIndex.java:49)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap$2.compareTo(GridOffHeapSnapTreeMap.java:1350)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap$2.compareTo(GridOffHeapSnapTreeMap.java:1346)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2102)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2217)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2217)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2217)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2217)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2217)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2217)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2217)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2217)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2217)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2217)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2217)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2217)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2217)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2217)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2217)
> at
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHea
[jira] [Created] (IGNITE-4856) .NET: StopAll on AppDomain unload
Pavel Tupitsyn created IGNITE-4856:
--
Summary: .NET: StopAll on AppDomain unload
Key: IGNITE-4856
URL: https://issues.apache.org/jira/browse/IGNITE-4856
Project: Ignite
Issue Type: Improvement
Components: platforms
Affects Versions: 1.6
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
Fix For: 2.1
In certain scenarios .NET {{AppDomain}} can be unloaded and started again. Java
part of Ignite continues to run, but .NET part (including Ignite instances) is
lost. User can no longer work with started nodes, .NET callback pointers are
lost, etc.
We should track AppDomain unload and stop all Ignite instances.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (IGNITE-4594) Implement index hints for SQL
[ https://issues.apache.org/jira/browse/IGNITE-4594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda reassigned IGNITE-4594: --- Assignee: Sergi Vladykin > Implement index hints for SQL > - > > Key: IGNITE-4594 > URL: https://issues.apache.org/jira/browse/IGNITE-4594 > Project: Ignite > Issue Type: New Feature > Components: SQL >Reporter: Denis Magda >Assignee: Sergi Vladykin > Fix For: 2.0 > > > Recently in H2 we've merged a very important feature: index hints. It is an > additional MySQL-like syntax: > SELECT * FROM my_table USE INDEX (index_a) WHERE A = 1 > It will be very easy to support this in Ignite. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-2779) BinaryMarshaller caches must be cleaned during client reconnect.
[
https://issues.apache.org/jira/browse/IGNITE-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-2779:
Labels: community (was: community important)
> BinaryMarshaller caches must be cleaned during client reconnect.
>
>
> Key: IGNITE-2779
> URL: https://issues.apache.org/jira/browse/IGNITE-2779
> Project: Ignite
> Issue Type: Task
> Components: cache, general
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
> Labels: community
> Fix For: 2.0
>
> Attachments: IgniteProblemTest.java
>
>
> The problem is originally reported by Vinay Sharma here:
> http://apache-ignite-users.70518.x6.nabble.com/changed-cache-configuration-and-restarted-server-nodes-Getting-exception-td3064.html#none
> *Root cause*:
> When client is reconnected to topology after full topology restart (i.e. all
> server nodes were down), it doesn't re-send binary metadata to topology. As a
> result, {{BinaryMarshaller}} exception occurs.
> *Steps to reproduce*
> Run attached code.
> *Proposed solution*
> Clean cached binary metadata during re-connect.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-3484) MVCC for cache data structures
[ https://issues.apache.org/jira/browse/IGNITE-3484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-3484: Labels: (was: important) > MVCC for cache data structures > -- > > Key: IGNITE-3484 > URL: https://issues.apache.org/jira/browse/IGNITE-3484 > Project: Ignite > Issue Type: Sub-task > Components: cache >Reporter: Alexey Goncharuk > Fix For: 2.0 > > > We need to make sure that SQL queries are executed on a certain in-memory > timestamp or version. This will require having as many versions of data in > memory as needed by the ongoing SQL queries. Once the queries complete, the > older versions should be discarded. > TBD: design requirements for MVCC. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-2422) Unable to deserialize BinaryObjectBuilder
[
https://issues.apache.org/jira/browse/IGNITE-2422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-2422:
Labels: (was: important)
> Unable to deserialize BinaryObjectBuilder
> -
>
> Key: IGNITE-2422
> URL: https://issues.apache.org/jira/browse/IGNITE-2422
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Maksim Kozlov
> Fix For: 2.0
>
> Attachments: ExampleNodeStartup.java
>
>
> Presently it's possible to serialize {{BinaryObjectBuilder}} but it will lead
> to the errors at deserialization stage.
> After a brief investigation I see that this happens because neither
> {{org.apache.ignite.binary.BinaryObjectBuilder}} nor
> {{org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl}}
> presents in {{META-INF/classnames.properties}} file.
> If you try to update
> {{ignite/modules/core/src/main/resources/META-INF/classnames.properties}} by
> building the project from scratch and copying-pasting generated content from
> built {{classnames.properties}}, then you will still see that there are still
> no entries for {{org.apache.ignite.binary.BinaryObjectBuilder}} nor
> {org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl}}.
> Looks like that {{ClassesGenerator}} misses these and other possible classes
> by some reason.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-2212) Transactional put triggers several deserializations on server of there are recordable events
[ https://issues.apache.org/jira/browse/IGNITE-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-2212: Labels: (was: important) > Transactional put triggers several deserializations on server of there are > recordable events > > > Key: IGNITE-2212 > URL: https://issues.apache.org/jira/browse/IGNITE-2212 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Valentin Kulichenko > Fix For: 2.0 > > Attachments: TxTest.java > > > Test attached. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-2231) 'Put' cache event treats entry created at lock acquisition time as old value
[
https://issues.apache.org/jira/browse/IGNITE-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-2231:
Labels: (was: important)
> 'Put' cache event treats entry created at lock acquisition time as old value
>
>
> Key: IGNITE-2231
> URL: https://issues.apache.org/jira/browse/IGNITE-2231
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
> Fix For: 2.0
>
> Attachments: EventsProcessingTest.java
>
>
> Subscribe for EVT_CACHE_OBJECT_PUT event on one node and perform 'put'
> operations from the other to an empty transnational cache.
> The subscriber will receive a notification saying that there was an old value
> for a key at the time the new was being inserted. In fact the was no an old
> value, the entry with a {{null}} as a value was generated as a part of
> implicit lock acquisition.
> This snippet of the code in {{GridCacheMapEntry}} generates a wrong event
> (innerSet function)
> {noformat}
> if (evt && newVer != null &&
> cctx.events().isRecordable(EVT_CACHE_OBJECT_PUT)) {
> CacheObject evtOld = cctx.unwrapTemporary(old);
> cctx.events().addEvent(partition(),
> key,
> evtNodeId,
> tx == null ? null : tx.xid(),
> newVer,
> EVT_CACHE_OBJECT_PUT,
> val,
> val != null,
> evtOld,
> evtOld != null || hasValueUnlocked(),
> subjId, null, taskName,
> keepBinary);
> }
> {noformat}
> Attached the test that lets reproduce the issue.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-2909) Checking cache object type in runtime
[ https://issues.apache.org/jira/browse/IGNITE-2909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-2909: Labels: community (was: community important) > Checking cache object type in runtime > - > > Key: IGNITE-2909 > URL: https://issues.apache.org/jira/browse/IGNITE-2909 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 1.5.0.final >Reporter: Denis Magda >Assignee: Vladislav Pyatkov > Labels: community > Fix For: 2.0 > > > In some cases there is necessity to control a type of object that is being > inserted into a cache. > Presently this kind of check is accomplished at compile time only relying > on Java Generics. However it doesn't prevent us from connecting to a > cluster using a non-generic instance of a cache and put any kind of data in > it. This may be not a harmful intention but rather a silly developer mistake. > It's preferable to rely on the cache interceptor based solution: > - user will create a generic interceptor that will accept "typeName" in its > constructor; > - class of this interceptor will be placed in the classpath of all the nodes; > - when a new cache is started statically (Spring cfg) or dynamically this > interceptor can be set with a particular allowed "typeName"; > - when interceptor is invoked allowed typeId (taken from allowed "typeName") > will be compared with a typeID of a key/value being inserted; > - exception has to be thrown if allowed typeId is not equal to a key/value > typeId being inserted. > We need to allow to throw exceptions from interceptor and provide an example > on how perform type validation using interceptors based approach. > Refer to the discussion on the dev list: > http://apache-ignite-developers.2346864.n4.nabble.com/Controlling-type-of-object-inserted-in-IgniteCache-td8128.html -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-3164) Add an option to send resulting value instead of entry processor in transactional cache
[
https://issues.apache.org/jira/browse/IGNITE-3164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-3164:
Labels: (was: important)
> Add an option to send resulting value instead of entry processor in
> transactional cache
> ---
>
> Key: IGNITE-3164
> URL: https://issues.apache.org/jira/browse/IGNITE-3164
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Alexandr Fedotov
> Fix For: 2.0
>
>
> In some cases user can't guarantee that EP behaves consistently on all nodes.
> In transactional cache this can lead to inconsistent cache, because we invoke
> EP on both primary and backup nodes.
> We can add {{withSendValueToBackup()}} flag (naming is arguable) which will
> override current default behavior.
> We also need to update documentation, especially provide the explanation of
> EP behavior in atomic and transactional caches.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-1403) forOldest() cluster group returns predicate that is not updated when topology changes
[
https://issues.apache.org/jira/browse/IGNITE-1403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-1403:
Labels: (was: important)
> forOldest() cluster group returns predicate that is not updated when topology
> changes
> -
>
> Key: IGNITE-1403
> URL: https://issues.apache.org/jira/browse/IGNITE-1403
> Project: Ignite
> Issue Type: Bug
> Components: general
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
> Fix For: 2.0
>
>
> {{AgeClusterGroup}} that implements {{forOldest()}} and {{forYoungest}}
> cluster groups is dynamically updated when topology changes. But the
> predicate that can be acquired from this group via {{predicate()}} method is
> static, which is incorrect.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-2750) REST connection is closed on the server side ignoring unfinished client requests
[
https://issues.apache.org/jira/browse/IGNITE-2750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-2750:
Labels: community (was: community important)
> REST connection is closed on the server side ignoring unfinished client
> requests
>
>
> Key: IGNITE-2750
> URL: https://issues.apache.org/jira/browse/IGNITE-2750
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Saikat Maitra
> Labels: community
> Fix For: 2.0
>
>
> Client can send long running request (i.e., compute tasks) to the cluster
> over REST connection. If a task execution takes more time than
> {{ConnectorConfiguration.idleTimeout}} then the connection will be closed by
> server automatically.
> The server mustn't close the connection in cases if there are unfinished
> requests received from clients. This approach already works on the client
> side.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-3164) Add an option to send resulting value instead of entry processor in transactional cache
[
https://issues.apache.org/jira/browse/IGNITE-3164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-3164:
Flags: (was: Important)
> Add an option to send resulting value instead of entry processor in
> transactional cache
> ---
>
> Key: IGNITE-3164
> URL: https://issues.apache.org/jira/browse/IGNITE-3164
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Alexandr Fedotov
> Fix For: 2.0
>
>
> In some cases user can't guarantee that EP behaves consistently on all nodes.
> In transactional cache this can lead to inconsistent cache, because we invoke
> EP on both primary and backup nodes.
> We can add {{withSendValueToBackup()}} flag (naming is arguable) which will
> override current default behavior.
> We also need to update documentation, especially provide the explanation of
> EP behavior in atomic and transactional caches.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-2425) BinaryObject.readField() called for an object Java array field reads objects class
[
https://issues.apache.org/jira/browse/IGNITE-2425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-2425:
Labels: (was: important)
> BinaryObject.readField() called for an object Java array field reads objects
> class
> ---
>
> Key: IGNITE-2425
> URL: https://issues.apache.org/jira/browse/IGNITE-2425
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
> Fix For: 2.0
>
> Attachments: ExampleNodeStartup.java
>
>
> If there is a {{BinaryObject}} that has a field that refers to an array of
> some custom user objects then during the time {{BinaryObject.field()}} is
> called the class of this custom will be read. This can lead to
> {{ClassNotFoundException}} on a server side or another ones related.
> In the attach example the following issue is demonstrated using
> {{BinaryObjectBuilder}} which class is not listed in classnames.properties.
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-2421) EventTypes are badly documented
[
https://issues.apache.org/jira/browse/IGNITE-2421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-2421:
Labels: (was: important)
> EventTypes are badly documented
> ---
>
> Key: IGNITE-2421
> URL: https://issues.apache.org/jira/browse/IGNITE-2421
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
> Fix For: 2.0
>
>
> We have to go through all the {{EventTypes}} and document them well:
> - in which conditions they are fired;
> - what kind of nodes (primary, backups or both) will receive and update;
> - etc.
> As an example.
> From {{EVT_CACHE_ENTRY_CREATED}} is not clear when it's fired at all. However
> it's fired when an entry is loaded from a storage, or when it's initially
> created due to a cache put.
> The same situation is around {{EVT_CACHE_OBJECT_PUT}}. There is no info
> saying that it's fired on both primary and backup nodes. That it's not fired
> due to a loading from a cache, etc.
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-3479) Global transaction ordering
[ https://issues.apache.org/jira/browse/IGNITE-3479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-3479: Labels: (was: important) > Global transaction ordering > --- > > Key: IGNITE-3479 > URL: https://issues.apache.org/jira/browse/IGNITE-3479 > Project: Ignite > Issue Type: Sub-task > Components: cache >Reporter: Alexey Goncharuk > Fix For: 2.0 > > > Current transaction ID will not work for SQL MVCC ordering because two > transaction IDs are not in total order across the cluster. > One of the approaches is to have a dedicated coordinator which will assign a > continuously growing transaction ID for each committed transaction. This ID > must be acquired by each transaction at the last step of PREPARE stage. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-3085) Hadoop module cannot load native libraries when running inside HDP 2.3.4
[
https://issues.apache.org/jira/browse/IGNITE-3085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-3085:
Labels: bigdata (was: bigdata important)
> Hadoop module cannot load native libraries when running inside HDP 2.3.4
>
>
> Key: IGNITE-3085
> URL: https://issues.apache.org/jira/browse/IGNITE-3085
> Project: Ignite
> Issue Type: Bug
> Components: hadoop
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Ivan Veselovsky
>Priority: Critical
> Labels: bigdata
> Fix For: 2.0
>
>
> 1) Run some load with Hadoop Accelerator in HDP 2.2 - all is fine.
> 2) Run the same load with HDP 2.3.4, exception is thorwn:
> {code}
> java.lang.NoClassDefFoundError: org/apache/hadoop/util/NativeCodeLoader
> at
> org.apache.ignite.internal.processors.hadoop.HadoopClassLoader.initializeNativeLibraries(HadoopClassLoader.java:145)
> at
> org.apache.ignite.internal.processors.hadoop.HadoopClassLoader.(HadoopClassLoader.java:127)
> at
> org.apache.ignite.internal.processors.hadoop.jobtracker.HadoopJobTracker.start(HadoopJobTracker.java:160)
> at
> org.apache.ignite.internal.processors.hadoop.HadoopProcessor.start(HadoopProcessor.java:103)
> at
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1486)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:859)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1689)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1548)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1004)
> at
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:930)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:816)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:715)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:585)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:555)
> at org.apache.ignite.Ignition.start(Ignition.java:347)
> at
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:302)
> Caused by: java.lang.ClassNotFoundException:
> org.apache.hadoop.util.NativeCodeLoader
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ... 16 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-2894) Binary object inside of Externalizable still serialized with OptimizedMarshaller
[
https://issues.apache.org/jira/browse/IGNITE-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-2894:
Labels: community customer (was: community customer important)
> Binary object inside of Externalizable still serialized with
> OptimizedMarshaller
>
>
> Key: IGNITE-2894
> URL: https://issues.apache.org/jira/browse/IGNITE-2894
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Amelchev Nikita
>Priority: Critical
> Labels: community, customer
> Fix For: 2.0
>
>
> When binary marshaller meets an Externalizable object, it switches to
> optimized marshaller. And if there is a regular object inside, it's still
> serialized with optimized, even if its type is declared in binary
> configuration with custom mapper, etc.
> Essentially, binary marshaller should fully support Java serialization,
> including {{Externalizable}} and {{writeObject}}/{{readObject}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-2190) ScanQuery without a filter triggers object's deserialization on the server side
[
https://issues.apache.org/jira/browse/IGNITE-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-2190:
Labels: (was: important)
> ScanQuery without a filter triggers object's deserialization on the server
> side
> ---
>
> Key: IGNITE-2190
> URL: https://issues.apache.org/jira/browse/IGNITE-2190
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Priority: Critical
> Fix For: 2.0
>
> Attachments: ScanQueryBug.java
>
>
> The issue is reproduced on version 1.4 where legacy PortableMarshaller is
> used. However, I'm quiet sure that the issue happens when BinaryMarshaller is
> used as well in 1.5.
> 1) Start a server using ignite.sh/bat
> 2) Create a simple app, that uses binary or portable marshaller, creates a
> cache dynamically and executes a ScanQuery like below
> {{int size=employees1.query(new ScanQuery()).getAll().size();}}
> 3) As you see the query doesn't use any filters. However on the server side
> some filter is still being checked
> {{org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$5.checkPredicate(GridCacheQueryManager.java:963)}}
> which makes the server to deserialize a value.
> According to the stack trace there is some internal filter that triggered
> checkPredicate function -
> filter=o.a.i.i.processors.cache.IgniteCacheProxy$1@3224ff7b.
> {noformat}
> [11:05:22,725][SEVERE][ignite-#25%sys-null%][GridCacheDistributedQueryManager]
> Failed to run query [qry=GridCacheQueryInfo [loc=false,
> trans=null, rdc=null, qry=GridCacheQueryAdapter [type=SCAN, clsName=null,
> clause=null, filter=o.a.i.i.processors.cache.IgniteCacheProxy$1@3224ff7b,
> part=null, incMeta=false, metrics=null, pageSize=1024, timeout=0,
> keepAll=false, incBackups=false, dedup=false, prj=null, keepPortable=false,
> subjId=c6aeb542-1693-4b5f-89db-96db50e3435f, taskHash=0], locFut=null,
> sndId=c6aeb542-1693-4b5f-89db-96db50e3435f, reqId=14, incMeta=false,
> all=false], node=209c237a-9e33-4d05-abe4-bbc14f93c439]
> class org.apache.ignite.IgniteCheckedException:
> **.SubMessageB
> at org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:6979)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:166)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:115)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$CachedResult.iterator(GridCacheQueryManager.java:2784)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.runQuery(GridCacheQueryManager.java:1376)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager.processQueryRequest(GridCacheDistributedQueryManager.java:226)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$2.apply(GridCacheDistributedQueryManager.java:105)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$2.apply(GridCacheDistributedQueryManager.java:103)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:580)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:280)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:198)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:77)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:160)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:811)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1500(GridIoManager.java:106)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:774)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.ClassNotFoundException:
> **.SubMessageB
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8137)
> at
> org.apache.ig
[jira] [Updated] (IGNITE-3386) Reentrant lock is lost when lock owner leaves topology
[
https://issues.apache.org/jira/browse/IGNITE-3386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-3386:
Labels: (was: important)
> Reentrant lock is lost when lock owner leaves topology
> --
>
> Key: IGNITE-3386
> URL: https://issues.apache.org/jira/browse/IGNITE-3386
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Affects Versions: 1.6
>Reporter: Denis Magda
>Assignee: Evgenii Zhuravlev
>Priority: Critical
> Fix For: 2.0
>
> Attachments: LockIssueVer2.java
>
>
> If to create a lock with the following configuration
> {{IgniteLock lock = ignite.reentrantLock("lock", true, true, true);}}
> and perform the following steps below
> 1) run the first node using {{LockIssue}} that is attached;
> 2) run the second node using {{LockIssue}};
> 3) stop the first node.
> you will get the following exception on the second node side (the lock
> information will be lost and the second node won't recreate it ignore
> "create=true" flag):
> {code}
> SEVERE: Failed to compare and set:
> o.a.i.i.processors.datastructures.GridCacheLockImpl$Sync$1@67aea87d
> class org.apache.ignite.IgniteCheckedException: Failed to find reentrant lock
> with given name: test
> at
> org.apache.ignite.internal.processors.datastructures.GridCacheLockImpl$Sync$1.call(GridCacheLockImpl.java:525)
> at
> org.apache.ignite.internal.processors.datastructures.GridCacheLockImpl$Sync$1.call(GridCacheLockImpl.java:518)
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils$23.call(GridCacheUtils.java:1648)
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.outTx(GridCacheUtils.java:891)
> at
> org.apache.ignite.internal.processors.datastructures.GridCacheLockImpl$Sync.compareAndSetGlobalState(GridCacheLockImpl.java:517)
> at
> org.apache.ignite.internal.processors.datastructures.GridCacheLockImpl$Sync.tryAcquire(GridCacheLockImpl.java:400)
> at
> org.apache.ignite.internal.processors.datastructures.GridCacheLockImpl$Sync.tryAcquire(GridCacheLockImpl.java:437)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:861)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
> at
> org.apache.ignite.internal.processors.datastructures.GridCacheLockImpl$Sync.lock(GridCacheLockImpl.java:432)
> at
> org.apache.ignite.internal.processors.datastructures.GridCacheLockImpl.lock(GridCacheLockImpl.java:1201)
> at
> com.bfm.amc.loaders.server.StartIgniteServer.main(StartIgniteServer.java:15)
> {code}
> However the issue is not 100% reproduced but it should be clear from the logs
> what happens.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-4547) Apache Ignite 2.0 quick and needed tasks
[ https://issues.apache.org/jira/browse/IGNITE-4547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-4547: Labels: important newbie (was: newbie) > Apache Ignite 2.0 quick and needed tasks > > > Key: IGNITE-4547 > URL: https://issues.apache.org/jira/browse/IGNITE-4547 > Project: Ignite > Issue Type: Task >Reporter: Denis Magda >Priority: Critical > Labels: important, newbie > > The ticket contains a list of quick tasks that have to be resolved in Apache > 2.0 release. > All the tickets have to be merged into ignite-2.0 branch. Forks have to be > created from ignite-2.0 as well: > http://apache-ignite-developers.2346864.n4.nabble.com/What-branch-to-use-for-Apache-Ignite-2-0-development-td12800.html > Need more details? Ask Ignite developers: > https://ignite.apache.org/community/resources.html#ask -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-2703) .NET: Dynamically registered classes must use binary serialization if possible
[ https://issues.apache.org/jira/browse/IGNITE-2703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-2703: Labels: .net breaking-api important (was: .net breaking-api) > .NET: Dynamically registered classes must use binary serialization if possible > -- > > Key: IGNITE-2703 > URL: https://issues.apache.org/jira/browse/IGNITE-2703 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 1.5.0.final >Reporter: Vladimir Ozerov >Assignee: Pavel Tupitsyn > Labels: .net, breaking-api, important > Fix For: 2.0 > > > At present we support dynamic class registration in .NET, but they are > written using deafult .NET mechanism. This is counterintuitive for users and > not consistent with Java, where such classes are written in binary form. > Proposed implementation plan: > 1) For each dynamically registered class we must understand whether it could > be serialized through binary or not. If not - print a warning and fallback to > .NET. > 2) Before writing a class we must ensure that it's [typeId -> name] pair is > known to the cluster. If not - write full class name instead of type ID. Java > already do that. > 3) Last, to support backward compatibility we must be able to fallback to > current mode with help of some boolean flag. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-1794) Ignite should support Hibernate 5
[
https://issues.apache.org/jira/browse/IGNITE-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-1794:
Labels: important newbie (was: newbie)
> Ignite should support Hibernate 5
> -
>
> Key: IGNITE-1794
> URL: https://issues.apache.org/jira/browse/IGNITE-1794
> Project: Ignite
> Issue Type: Task
> Components: Hibernate L2 cache
>Reporter: Artem Shutak
>Assignee: Vadim Opolski
> Labels: important, newbie
> Fix For: 2.0
>
> Attachments: HibernateCollectionRegionForIgnite.java,
> HibernateEntityRegionForIgnite.java, HibernateRegionFactoryForIgnite.java,
> HibernateTimestampsRegionForIgnite.java
>
>
> Currently Ignite supports Hibernate 4.
> In Hibernate 5 org.hibernate.cache.spi.RegionFactory.start() method signature
> has been changed from
> {{void start(Settings var1, Properties var2) throws CacheException;}}
> on
> {{void start(SessionFactoryOptions settings, Properties properties) throws
> CacheException;}}
> Original user list:
> http://apache-ignite-users.70518.x6.nabble.com/Hibernate-5-L2-Cache-Compatibility-td1656.html
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-3575) CPP: Support continuous queries remote filters.
[ https://issues.apache.org/jira/browse/IGNITE-3575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-3575: Labels: cpp important (was: cpp) > CPP: Support continuous queries remote filters. > --- > > Key: IGNITE-3575 > URL: https://issues.apache.org/jira/browse/IGNITE-3575 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 1.6 >Reporter: Vladimir Ozerov >Assignee: Igor Sapego > Labels: cpp, important > Fix For: 2.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-4475) Simplify async API
[
https://issues.apache.org/jira/browse/IGNITE-4475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-4475:
Description:
*Problem*
We need to simplify our async API. It is to complex and verbose at the moment:
{code}
IgniteCache asyncCache = cache.withAsync();
asyncCache.get(key);
IgniteFuture fut = asyncCache.future();
{code}
*Proposed solution*
1) Deprecate {{IgniteAsyncSupport}} interface.
2) Make async operations more straightforward:
{code}
IgniteFuture fut = cache.getAsync(key);
{code}
*Scope*
~80 async methods in all public interfaces.
Base branch: {{ignite-4475-async}}
Migration guide has to be updated:
https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0+Migration+Guide
was:
*Problem*
We need to simplify our async API. It is to complex and verbose at the moment:
{code}
IgniteCache asyncCache = cache.withAsync();
asyncCache.get(key);
IgniteFuture fut = asyncCache.future();
{code}
*Proposed solution*
1) Deprecate {{IgniteAsyncSupport}} interface.
2) Make async operations more straightforward:
{code}
IgniteFuture fut = cache.getAsync(key);
{code}
*Scope*
~80 async methods in all public interfaces.
Base branch: {{ignite-4475-async}}
> Simplify async API
> --
>
> Key: IGNITE-4475
> URL: https://issues.apache.org/jira/browse/IGNITE-4475
> Project: Ignite
> Issue Type: Task
> Components: general
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Labels: important
> Fix For: 2.0
>
>
> *Problem*
> We need to simplify our async API. It is to complex and verbose at the moment:
> {code}
> IgniteCache asyncCache = cache.withAsync();
> asyncCache.get(key);
> IgniteFuture fut = asyncCache.future();
> {code}
> *Proposed solution*
> 1) Deprecate {{IgniteAsyncSupport}} interface.
> 2) Make async operations more straightforward:
> {code}
> IgniteFuture fut = cache.getAsync(key);
> {code}
> *Scope*
> ~80 async methods in all public interfaces.
> Base branch: {{ignite-4475-async}}
> Migration guide has to be updated:
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0+Migration+Guide
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-2940) .NET: Plugin system
[ https://issues.apache.org/jira/browse/IGNITE-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-2940: Labels: .net important (was: .net) > .NET: Plugin system > --- > > Key: IGNITE-2940 > URL: https://issues.apache.org/jira/browse/IGNITE-2940 > Project: Ignite > Issue Type: New Feature > Components: platforms >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Labels: .net, important > Fix For: 2.0 > > > Implement a plugin system to allow extending Ignite functionality by third > parties. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-4799) Remove TcpDiscoverySpi.heartbeatsFrequency parameter
[
https://issues.apache.org/jira/browse/IGNITE-4799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-4799:
Labels: important (was: )
> Remove TcpDiscoverySpi.heartbeatsFrequency parameter
>
>
> Key: IGNITE-4799
> URL: https://issues.apache.org/jira/browse/IGNITE-4799
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Magda
>Priority: Blocker
> Labels: important
> Fix For: 2.0
>
>
> {{TcpDiscoverySpi.heartbeatsFrequency}} is no longer used to adjust the
> heartbeats frequence. It affects the frequency of metrics messages sent over
> the cluster ring.
> The following has to be done as a part of 2.0 release:
> * Remove {{TcpDiscoverySpi.heartbeatsFrequency}} parameter.
> * Use {{IgniteConfiguraion.getMetricsUpdateFrequency}} to adjust the rate of
> metrics messages.
> * Make sure {{IgniteConfiguraion.getMetricsUpdateFrequency}} and metrics
> messages are not participated in the failure detection process. We have to
> clean up legacy code in {{ServerImpl}}.
> Refer to this discussion for more details:
> http://apache-ignite-developers.2346864.n4.nabble.com/Renaming-TcpDiscoverySpi-heartbeatsFrequency-to-TcpDiscoverySpi-metricsUpdateFrequency-td14941.html
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-4475) Simplify async API
[
https://issues.apache.org/jira/browse/IGNITE-4475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-4475:
Labels: important (was: )
> Simplify async API
> --
>
> Key: IGNITE-4475
> URL: https://issues.apache.org/jira/browse/IGNITE-4475
> Project: Ignite
> Issue Type: Task
> Components: general
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Labels: important
> Fix For: 2.0
>
>
> *Problem*
> We need to simplify our async API. It is to complex and verbose at the moment:
> {code}
> IgniteCache asyncCache = cache.withAsync();
> asyncCache.get(key);
> IgniteFuture fut = asyncCache.future();
> {code}
> *Proposed solution*
> 1) Deprecate {{IgniteAsyncSupport}} interface.
> 2) Make async operations more straightforward:
> {code}
> IgniteFuture fut = cache.getAsync(key);
> {code}
> *Scope*
> ~80 async methods in all public interfaces.
> Base branch: {{ignite-4475-async}}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-4795) Inherit TransactionException and update Javadoc
[
https://issues.apache.org/jira/browse/IGNITE-4795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-4795:
Labels: documentation important (was: documentation)
> Inherit TransactionException and update Javadoc
> ---
>
> Key: IGNITE-4795
> URL: https://issues.apache.org/jira/browse/IGNITE-4795
> Project: Ignite
> Issue Type: Improvement
> Components: cache, SQL, website
>Affects Versions: 1.8
>Reporter: Alexandr Kuramshin
>Assignee: Ryabov Dmitrii
> Labels: documentation, important
> Fix For: 2.0
>
>
> Understanding transactional behaviour is not clear in Javadoc at this point
> of time. Even after reading website some doubt remain.
> Proposal.
> 1. Create {{TransactionException}} as the marker of transactional methods and
> inherit from it all the existed transactional exceptions like
> {{TransactionTimeoutException}}, {{TransactionRollbackException}},
> {{TransactionHeuristicException}}, {{TransactionOptimisticException}}, etc.
> 2. Update all the transactional methods ({{get}}, {{put}}, {{invoke}}, etc)
> as throwing the base {{TransactionException}}. Comment all the
> {{IgniteCache}} methods whether they are transactional or not, add {{@see
> TransactionException}} annotation.
> 3. Make extensive documentation in the header of {{TransactionException}} to
> get understanding of transactional and non-transactional methods behaviour.
> 4. Update website and Javadoc to clarify the fact that {{put}} value is
> cached within the transaction and affects successive {{get}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-4539) RocketMQ data streamer
[ https://issues.apache.org/jira/browse/IGNITE-4539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-4539: Labels: important (was: ) > RocketMQ data streamer > -- > > Key: IGNITE-4539 > URL: https://issues.apache.org/jira/browse/IGNITE-4539 > Project: Ignite > Issue Type: New Feature > Components: streaming >Reporter: Roman Shtykh >Assignee: Roman Shtykh > Labels: important > Fix For: 2.0 > > > Streamer for RocketMQ (https://github.com/rocketmq) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-3869) Reduce number of temporary objects produced by H2
[ https://issues.apache.org/jira/browse/IGNITE-3869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-3869: Labels: important (was: ) > Reduce number of temporary objects produced by H2 > - > > Key: IGNITE-3869 > URL: https://issues.apache.org/jira/browse/IGNITE-3869 > Project: Ignite > Issue Type: Task > Components: SQL >Affects Versions: 1.4 >Reporter: Denis Magda >Assignee: Sergi Vladykin > Labels: important > Fix For: 2.0 > > > Presently during the execution of a query H2 generates significant number of > temporal objects (kind of wrappers) that eventually exhaust the heap and > trigger long GC pauses. > Need to revisit present implementation improving Ignite SQL engine and/or H2. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-1192) Provide integration with Spring Data
[ https://issues.apache.org/jira/browse/IGNITE-1192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-1192: Labels: Newbie important (was: Newbie) > Provide integration with Spring Data > > > Key: IGNITE-1192 > URL: https://issues.apache.org/jira/browse/IGNITE-1192 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 1.1.4 >Reporter: Valentin Kulichenko >Assignee: Denis Magda >Priority: Minor > Labels: Newbie, important > Fix For: 2.0 > > > Spring Data docs: > * http://docs.spring.io/spring-data/data-commons/docs/current/reference/html/ > * http://docs.spring.io/spring-data/data-commons/docs/current/api/ -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-4699) Introduce custom configurable executors.
[
https://issues.apache.org/jira/browse/IGNITE-4699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-4699:
Labels: important (was: )
> Introduce custom configurable executors.
>
>
> Key: IGNITE-4699
> URL: https://issues.apache.org/jira/browse/IGNITE-4699
> Project: Ignite
> Issue Type: Task
> Components: compute
>Reporter: Vladimir Ozerov
>Assignee: Alexander Menshikov
> Labels: important
> Fix For: 2.0
>
>
> We need to provide a way to configure custom thread pools for user compute
> tasks.
> Proposed API:
> 1) Config
> {code}
> class ExecutorConfiguration {
> String name;
> int size;
> }
> {code}
> 2) Choosing executor for compute task:
> {code}
> IgniteCompute compute = Ignite.compute().withExecutor("my_exec");
> {code}
> 3) Accessing raw executor (could be required for proper execution of future
> listeners):
> {code}
> ThreadPoolExecutor exec = ignite.compute().localExecutor("my_exec");
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-4523) Allow distributed SQL query execution over explicit set of partitions
[ https://issues.apache.org/jira/browse/IGNITE-4523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15937600#comment-15937600 ] Denis Magda commented on IGNITE-4523: - [~ascherbakov], the feature is planned for 2.0 release. What are the chances you complete it in time? > Allow distributed SQL query execution over explicit set of partitions > - > > Key: IGNITE-4523 > URL: https://issues.apache.org/jira/browse/IGNITE-4523 > Project: Ignite > Issue Type: Improvement > Components: cache, SQL >Affects Versions: 1.8 >Reporter: Alexei Scherbakov >Assignee: Alexei Scherbakov > Labels: important > Fix For: 2.0 > > > 3Currently distributed SQL query is executed on all nodes containing primary > partitions for a cache, sending map query requests on all nodes in grid. > Sometimes we know in advance which partitions hold a data for query, on > example, in case of custom affinity function. > Therefore it's possible to reduce number of nodes receiving map query request > by providing explicit set of partitions, which will give significant > performance advantage and traffic reduction in case of very large clusters. > Internally we already have such functionality, so the only necessary thing is > to provide public API for what. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-4523) Allow distributed SQL query execution over explicit set of partitions
[ https://issues.apache.org/jira/browse/IGNITE-4523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-4523: Labels: important (was: ) > Allow distributed SQL query execution over explicit set of partitions > - > > Key: IGNITE-4523 > URL: https://issues.apache.org/jira/browse/IGNITE-4523 > Project: Ignite > Issue Type: Improvement > Components: cache, SQL >Affects Versions: 1.8 >Reporter: Alexei Scherbakov >Assignee: Alexei Scherbakov > Labels: important > Fix For: 2.0 > > > 3Currently distributed SQL query is executed on all nodes containing primary > partitions for a cache, sending map query requests on all nodes in grid. > Sometimes we know in advance which partitions hold a data for query, on > example, in case of custom affinity function. > Therefore it's possible to reduce number of nodes receiving map query request > by providing explicit set of partitions, which will give significant > performance advantage and traffic reduction in case of very large clusters. > Internally we already have such functionality, so the only necessary thing is > to provide public API for what. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-4565) Support CREATE INDEX DDL statements
[
https://issues.apache.org/jira/browse/IGNITE-4565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-4565:
Labels: important (was: )
> Support CREATE INDEX DDL statements
> ---
>
> Key: IGNITE-4565
> URL: https://issues.apache.org/jira/browse/IGNITE-4565
> Project: Ignite
> Issue Type: New Feature
> Components: cache, SQL
>Reporter: Alexander Paschenko
> Labels: important
> Fix For: 2.0
>
>
> We need to implement support for dynamic {{CREATE INDEX}} and {{DROP INDEX}}
> invocations.
> Design document:
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=67640367
> Base branch: {{ignite-4565-ddl}}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-4524) Indexes usage in SQL functions like min/max
[
https://issues.apache.org/jira/browse/IGNITE-4524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-4524:
Labels: important (was: )
> Indexes usage in SQL functions like min/max
> ---
>
> Key: IGNITE-4524
> URL: https://issues.apache.org/jira/browse/IGNITE-4524
> Project: Ignite
> Issue Type: Bug
> Components: SQL
>Reporter: Denis Magda
>Assignee: Sergi Vladykin
> Labels: important
> Fix For: 2.0
>
>
> If to execute queries like this
> {code}
> select min(id) from MyValue
> select max(id) from MyValue
> {code}
> assuming that 'id' is an indexed field then the engine will not gain from
> this.
> The SQL engine needs to be improved so that the indexes are used for queries
> like the ones above.
> More details can be found in this discussion:
> http://apache-ignite-developers.2346864.n4.nabble.com/min-max-SQL-and-indexes-td13492.html
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-3013) Support sorted merge index for SQL
[ https://issues.apache.org/jira/browse/IGNITE-3013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-3013: Labels: SQL important (was: SQL) > Support sorted merge index for SQL > -- > > Key: IGNITE-3013 > URL: https://issues.apache.org/jira/browse/IGNITE-3013 > Project: Ignite > Issue Type: Improvement >Reporter: Sergi Vladykin >Assignee: Sergi Vladykin > Labels: SQL, important > Fix For: 2.0 > > > Currently for sorting we have to fetch all the result sets from remote nodes > and sort them on the client side, need to implement sorted merge index which > will do it lazily in streaming fashion. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-4534) Implement offheap eviction policies based on page memory
[ https://issues.apache.org/jira/browse/IGNITE-4534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-4534: Labels: important (was: ) > Implement offheap eviction policies based on page memory > > > Key: IGNITE-4534 > URL: https://issues.apache.org/jira/browse/IGNITE-4534 > Project: Ignite > Issue Type: Sub-task > Components: cache >Reporter: Alexey Goncharuk >Assignee: Ivan Rakov > Labels: important > Fix For: 2.0 > > > Since the internal structure of offheap storage has changed, we need to > re-implement Fifo, Lru and Sorted eviction policies -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-4536) Update metrics for new offheap storage
[ https://issues.apache.org/jira/browse/IGNITE-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-4536: Labels: important (was: ) > Update metrics for new offheap storage > -- > > Key: IGNITE-4536 > URL: https://issues.apache.org/jira/browse/IGNITE-4536 > Project: Ignite > Issue Type: Sub-task > Components: cache >Reporter: Alexey Goncharuk >Assignee: Sergey Chugunov > Labels: important > Fix For: 2.0 > > > Since the new implementation of offheap storage and memory pools, we need to > actualize existing cache metrics > 2.0 migration guide has to be updated if needed: > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0+Migration+Guide -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-4794) Reconsider CachePeekMode.ONHEAP
[
https://issues.apache.org/jira/browse/IGNITE-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-4794:
Labels: important (was: )
> Reconsider CachePeekMode.ONHEAP
> ---
>
> Key: IGNITE-4794
> URL: https://issues.apache.org/jira/browse/IGNITE-4794
> Project: Ignite
> Issue Type: Sub-task
> Components: cache
>Reporter: Denis Magda
> Labels: important
> Fix For: 2.0
>
>
> In Apache Ignite 2.0 we will no longer have {{ONHEAP}} tier in a sense it was
> supported for Apache Ignite 1.x releases. This is why we need to revisit
> {{CachePeekMode}} interface and adjust an implementation based on
> {{CachePeekMode.ONHEAP}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-4535) Add option to store deserialized values on-heap
[ https://issues.apache.org/jira/browse/IGNITE-4535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-4535: Labels: important (was: ) > Add option to store deserialized values on-heap > --- > > Key: IGNITE-4535 > URL: https://issues.apache.org/jira/browse/IGNITE-4535 > Project: Ignite > Issue Type: Sub-task > Components: cache >Reporter: Alexey Goncharuk >Assignee: Ilya Lantukh > Labels: important > Fix For: 2.0 > > > Now cache data is always stored in offheap (pagememory). Need implement > option to also store deserialised values in heap memory, this should be > replacement for existing CacheConfiguration.memoryMode configuration. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-4337) Introduce persistence interface to allow build reliable persistence plugins
[
https://issues.apache.org/jira/browse/IGNITE-4337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-4337:
Labels: important (was: )
> Introduce persistence interface to allow build reliable persistence plugins
> ---
>
> Key: IGNITE-4337
> URL: https://issues.apache.org/jira/browse/IGNITE-4337
> Project: Ignite
> Issue Type: Sub-task
> Components: general
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
> Labels: important
> Fix For: 2.0
>
>
> With page memory interface introduced, it may be possible to build a
> persistence layer around this architecture. I think we should move the
> PageMemory interface itself to {{org.apache.ignite.plugin.storage}} package
> and introduce the following interface to allow other components to log it's
> activity in crash-resistant way:
> {code}
> /**
> *
> */
> public interface IgniteWriteAheadLogManager extends GridCacheSharedManager {
> /**
> * @return {@code true} If we have to always write full pages.
> */
> public boolean isAlwaysWriteFullPages();
> /**
> * @return {@code true} if WAL will perform fair syncs on fsync call.
> */
> public boolean isFullSync();
> /**
> * Resumes logging after start. When WAL manager is started, it will skip
> logging any updates until this
> * method is called to avoid logging changes induced by the state restore
> procedure.
> */
> public void resumeLogging(WALPointer lastWrittenPtr) throws
> IgniteCheckedException;
> /**
> * Appends the given log entry to the write-ahead log.
> *
> * @param entry entry to log.
> * @return WALPointer that may be passed to {@link #fsync(WALPointer)}
> method to make sure the record is
> * written to the log.
> * @throws IgniteCheckedException If failed to construct log entry.
> * @throws StorageException If IO error occurred while writing log entry.
> */
> public WALPointer log(WALRecord entry) throws IgniteCheckedException,
> StorageException;
> /**
> * Makes sure that all log entries written to the log up until the
> specified pointer are actually persisted to
> * the underlying storage.
> *
> * @param ptr Optional pointer to sync. If {@code null}, will sync up to
> the latest record.
> * @throws IgniteCheckedException If
> * @throws StorageException
> */
> public void fsync(WALPointer ptr) throws IgniteCheckedException,
> StorageException;
> /**
> * Invoke this method to iterate over the written log entries.
> *
> * @param start Optional WAL pointer from which to start iteration.
> * @return Records iterator.
> * @throws IgniteException If failed to start iteration.
> * @throws StorageException If IO error occurred while reading WAL
> entries.
> */
> public WALIterator replay(WALPointer start) throws
> IgniteCheckedException, StorageException;
> /**
> * Gives a hint to WAL manager to clear entries logged before the given
> pointer. Some entries before the
> * the given pointer will be kept because there is a configurable WAL
> history size. Those entries may be used
> * for partial partition rebalancing.
> *
> * @param ptr Pointer for which it is safe to clear the log.
> * @return Number of deleted WAL segments.
> */
> public int truncate(WALPointer ptr);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-4349) Discontinue the schema-import utility
[ https://issues.apache.org/jira/browse/IGNITE-4349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-4349: Labels: important (was: ) > Discontinue the schema-import utility > - > > Key: IGNITE-4349 > URL: https://issues.apache.org/jira/browse/IGNITE-4349 > Project: Ignite > Issue Type: Task >Reporter: Denis Magda >Assignee: Alexey Kuznetsov > Labels: important > Fix For: 2.0 > > > Let's discontinue the maintenance of the schema-import utility in favor of > Web Console that has the same capability. > The schema-import utility should be removed from sources once the following > Web Console documentation is added > https://issues.apache.org/jira/browse/IGNITE-4348 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-2949) Replace JCache API dependency with Geronimo
[ https://issues.apache.org/jira/browse/IGNITE-2949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-2949: Labels: (was: important) > Replace JCache API dependency with Geronimo > --- > > Key: IGNITE-2949 > URL: https://issues.apache.org/jira/browse/IGNITE-2949 > Project: Ignite > Issue Type: Task > Components: build >Affects Versions: 1.5.0.final >Reporter: Valentin Kulichenko >Assignee: Valentin Kulichenko >Priority: Critical > Fix For: 2.0 > > > All JCache dependencies should be replaced with this one: > http://search.maven.org/#artifactdetails%7Corg.apache.geronimo.specs%7Cgeronimo-jcache_1.0_spec%7C1.0-alpha-1%7Cbundle -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (IGNITE-4855) Error when switching between notebooks
[
https://issues.apache.org/jira/browse/IGNITE-4855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Novikov reassigned IGNITE-4855:
--
Assignee: Pavel Konstantinov (was: Andrey Novikov)
Fix Version/s: 2.0
Affects Version/s: 1.9
Fixed error on switch between notebooks.
[~pkonstantinov], please check.
> Error when switching between notebooks
> --
>
> Key: IGNITE-4855
> URL: https://issues.apache.org/jira/browse/IGNITE-4855
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.9
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
> Fix For: 2.0
>
>
> {code}
> TypeError: Cannot redefine property: ace
> at Function.defineProperty ()
> at
> https://staging-console.my-host.com/app.9102c5d071fa1be61279.js:13:17181
> at https://staging-console.my-host.com/app.9102c5d071fa1be61279.js:7:22481
> at u
> (https://staging-console.my-host.com/vendor.ceecd70bedaaa641a449.js:1:1909)
> at Function.gs
> (https://staging-console.my-host.com/vendor.ceecd70bedaaa641a449.js:2:11302)
> at r
> (https://staging-console.my-host.com/app.9102c5d071fa1be61279.js:7:22424)
> at y
> (https://staging-console.my-host.com/app.9102c5d071fa1be61279.js:7:23641)
> at Object.link
> (https://staging-console.my-host.com/app.9102c5d071fa1be61279.js:7:23679)
> at
> https://staging-console.my-host.com/vendor.ceecd70bedaaa641a449.js:103:5660
> at we
> (https://staging-console.myhost.com/vendor.ceecd70bedaaa641a449.js:104:11056)
> ng-model="paragraph.query" style="font-family: monospace; font-size: 14px;">
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (IGNITE-4855) Error when switching between notebooks
[
https://issues.apache.org/jira/browse/IGNITE-4855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Novikov reassigned IGNITE-4855:
--
Assignee: Andrey Novikov
> Error when switching between notebooks
> --
>
> Key: IGNITE-4855
> URL: https://issues.apache.org/jira/browse/IGNITE-4855
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Andrey Novikov
>
> {code}
> TypeError: Cannot redefine property: ace
> at Function.defineProperty ()
> at
> https://staging-console.my-host.com/app.9102c5d071fa1be61279.js:13:17181
> at https://staging-console.my-host.com/app.9102c5d071fa1be61279.js:7:22481
> at u
> (https://staging-console.my-host.com/vendor.ceecd70bedaaa641a449.js:1:1909)
> at Function.gs
> (https://staging-console.my-host.com/vendor.ceecd70bedaaa641a449.js:2:11302)
> at r
> (https://staging-console.my-host.com/app.9102c5d071fa1be61279.js:7:22424)
> at y
> (https://staging-console.my-host.com/app.9102c5d071fa1be61279.js:7:23641)
> at Object.link
> (https://staging-console.my-host.com/app.9102c5d071fa1be61279.js:7:23679)
> at
> https://staging-console.my-host.com/vendor.ceecd70bedaaa641a449.js:103:5660
> at we
> (https://staging-console.myhost.com/vendor.ceecd70bedaaa641a449.js:104:11056)
> ng-model="paragraph.query" style="font-family: monospace; font-size: 14px;">
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-4617) CPP: Implement Field-access methods for binary objects
[
https://issues.apache.org/jira/browse/IGNITE-4617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15936685#comment-15936685
]
Igor Sapego commented on IGNITE-4617:
-
[~vozerov],
1) Fixed.
2) Removed from public class for now.
3) Added {{UserTestTypeGetField}} in {{BinaryObjectTestSuite}}.
Also, re-merged with master, created new PR and Upsource review.
> CPP: Implement Field-access methods for binary objects
> --
>
> Key: IGNITE-4617
> URL: https://issues.apache.org/jira/browse/IGNITE-4617
> Project: Ignite
> Issue Type: Task
> Components: platforms
>Affects Versions: 1.8
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Labels: cpp
> Fix For: 2.0
>
>
> Currently we have very limited implementation of binary objects that does not
> provide access to fields of the binary object. At least such methods as
> {{HasField}} and {{GetField}} should be implemented.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-4617) CPP: Implement Field-access methods for binary objects
[
https://issues.apache.org/jira/browse/IGNITE-4617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15936678#comment-15936678
]
ASF GitHub Bot commented on IGNITE-4617:
GitHub user isapego opened a pull request:
https://github.com/apache/ignite/pull/1665
IGNITE-4617: Added field-access methods for BinaryObject
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-4617
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/1665.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #1665
commit 18f6f38056c3e180331021baaf171d7423d0bfea
Author: Igor Sapego
Date: 2017-03-01T17:28:17Z
IGNITE-4617: Reapply on ignite-2.0
commit 60c9e93fe0fdc3d0f18c0aae2f0854ca9b1c2c54
Author: Igor Sapego
Date: 2017-03-01T17:43:35Z
IGNITE-4617: Added force class lookup for the tests.
commit 7a4651783c0fcb7429e84b661026e94a0efa4413
Author: Igor Sapego
Date: 2017-03-01T17:46:07Z
IGNITE-4617: Fix
commit bdd5cd9485da6b10a71f1c803a2824e829e4f23c
Author: Igor Sapego
Date: 2017-03-01T19:20:51Z
IGNITE-4617: Refactored Java part. Added BinaryFieldMetadata class.
commit 317af5ff10f79a8b88ee5818e8673f0303c7453c
Author: Igor Sapego
Date: 2017-03-01T19:38:43Z
IGNITE-4617: Fix for tests
commit 413d8abe46cf99629af7293bba6345c4308431b2
Author: Igor Sapego
Date: 2017-03-01T20:26:22Z
IGNITE-4617: Fixed C++ side.
commit fca84a7352bd9a46bd9997f0439b876b8aa6f154
Author: Igor Sapego
Date: 2017-03-02T14:35:08Z
IGNITE-4617: Fix
commit 53efef65a5c15e6670f01f1dc2d6750e6ccc69b7
Author: Igor Sapego
Date: 2017-03-02T16:08:47Z
IGNITE-4617: Changed Field Metadata writing and reading
commit e7060daca0537c3218dbb8efbd8b1523c1a842a3
Author: Igor Sapego
Date: 2017-03-02T17:12:44Z
IGNITE-4617: Implemented for the .NET
commit 8a5ad507a6fb79ec0c949546be1338a489926537
Author: Igor Sapego
Date: 2017-03-02T17:32:55Z
IGNITE-4617: Added IBinaryField
commit 9d8c2be1a1a31b796200434d3e2324ede7691e6f
Author: Igor Sapego
Date: 2017-03-22T13:54:26Z
IGNITE-4617: Removed wildcard from imports.
commit 63a06491cfddcd476d20350eaa3411fd06381b26
Author: Igor Sapego
Date: 2017-03-22T15:06:52Z
IGNITE-4617: Removed GetEnumValue from public
commit 450c929552ca6ff565e4ba44a771bcb311ada9de
Author: Igor Sapego
Date: 2017-03-22T16:46:04Z
IGNITE-4617: Added test
commit ce13385ee040487ee70e86759e40ee50563a9509
Author: Igor Sapego
Date: 2017-03-22T16:55:08Z
Merge remote-tracking branch 'upstream/master' into ignite-4617
> CPP: Implement Field-access methods for binary objects
> --
>
> Key: IGNITE-4617
> URL: https://issues.apache.org/jira/browse/IGNITE-4617
> Project: Ignite
> Issue Type: Task
> Components: platforms
>Affects Versions: 1.8
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Labels: cpp
> Fix For: 2.0
>
>
> Currently we have very limited implementation of binary objects that does not
> provide access to fields of the binary object. At least such methods as
> {{HasField}} and {{GetField}} should be implemented.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (IGNITE-4827) Remove deprecated code related to backward compatibility
[ https://issues.apache.org/jira/browse/IGNITE-4827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15934581#comment-15934581 ] Taras Ledkov edited comment on IGNITE-4827 at 3/22/17 3:01 PM: --- Tests [results|http://195.239.208.174/project.html?projectId=IgniteTests&tab=projectOverview&branch_IgniteTests=pull%2F1654%2Fhead] are OK with me. I don't see the significant difference of the tests results between the master branch and the patch. was (Author: tledkov-gridgain): Tests [results|http://195.239.208.174/project.html?projectId=IgniteTests&tab=projectOverview&branch_IgniteTests=pull%2F1654%2Fhead] is OK with me. I don't see the significant difference of the tests results between the master branch and the patch. > Remove deprecated code related to backward compatibility > > > Key: IGNITE-4827 > URL: https://issues.apache.org/jira/browse/IGNITE-4827 > Project: Ignite > Issue Type: Sub-task >Reporter: Taras Ledkov >Assignee: Taras Ledkov > Fix For: 2.0 > > > Must be removed / refactored: > - LATE_AFF_ASSIGN_SINCE; > - LOAD_CACHE_JOB_SINCE and the class GridCacheAdapter.LoadKeysCallable; > - PartitionSizeLongTask.SINCE_VER; > - compatibility at the VisorCacheConfiguration; > - GridDhtPartitionMap; > - NEAR_JOB_SINCE; > - CUSTOM_MSG_ALLOW_JOINING_FOR_VERIFIED_SINCE; > - VisorCache compatibility (older version of the VisorCache classes); > - multiple connection compatibility; > - partitions map compression compatibility; > - old rebalance API; > - CacheContinuousQueryBatchAck.SINCE_VER; > - GridQueryRequest > - services compatibility with older version; > - BINARY_CFG_CHECK_SINCE; > - GridQueryRequest; > - SINGLE_GET_MSG_SINCE; > - LOCAL_STORE_KEEPS_PRIMARY_AND_BACKUPS_SINCE; > - compatibility at compute closures; > - continuous query compatibility; > - CLIENT_ACK_SINCE_VERSION -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (IGNITE-4475) Simplify async API
[
https://issues.apache.org/jira/browse/IGNITE-4475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15934521#comment-15934521
]
Taras Ledkov edited comment on IGNITE-4475 at 3/22/17 3:01 PM:
---
Waits
[results|http://195.239.208.174/project.html?projectId=IgniteTests&tab=projectOverview&branch_IgniteTests=pull%2F1648%2Fhead]
are OK with me.
was (Author: tledkov-gridgain):
Waits for TC
[results|http://195.239.208.174/project.html?projectId=IgniteTests&tab=projectOverview&branch_IgniteTests=pull%2F1648%2Fhead]
> Simplify async API
> --
>
> Key: IGNITE-4475
> URL: https://issues.apache.org/jira/browse/IGNITE-4475
> Project: Ignite
> Issue Type: Task
> Components: general
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> *Problem*
> We need to simplify our async API. It is to complex and verbose at the moment:
> {code}
> IgniteCache asyncCache = cache.withAsync();
> asyncCache.get(key);
> IgniteFuture fut = asyncCache.future();
> {code}
> *Proposed solution*
> 1) Deprecate {{IgniteAsyncSupport}} interface.
> 2) Make async operations more straightforward:
> {code}
> IgniteFuture fut = cache.getAsync(key);
> {code}
> *Scope*
> ~80 async methods in all public interfaces.
> Base branch: {{ignite-4475-async}}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (IGNITE-4002) Incorrect errors/warnings while odbc driver installation
[
https://issues.apache.org/jira/browse/IGNITE-4002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ksenia Rybakova reopened IGNITE-4002:
-
Please take a look at "3)" in issue description as well
> Incorrect errors/warnings while odbc driver installation
>
>
> Key: IGNITE-4002
> URL: https://issues.apache.org/jira/browse/IGNITE-4002
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 1.7
> Environment: Windows 2010 (Rus)
>Reporter: Ksenia Rybakova
>Assignee: Igor Sapego
>Priority: Minor
> Labels: cpp
> Fix For: 2.0
>
>
> 1) Build x64 odbc driver according to $IGNITE_HOME\platforms\cpp\DEVNOTES.txt
> 2) Install x64 bit driver according to
> $IGNITE_HOME\platforms\cpp\odbc\README.txt. Don't pass x32 driver as a second
> parameter:
> {noformat}
> D:\ignite\platforms\cpp\odbc\install>install_amd64.cmd
> D:\ignite\platforms\cpp\project\vs\x64\Release\ignite.odbc.dll
> Installing 64-bit driver:
> D:\ignite\platforms\cpp\project\vs\x64\Release\ignite.odbc.dll
> Операция успешно завершена.
> Операция успешно завершена.
> Операция успешно завершена.
> Операция успешно завершена.
> Операция успешно завершена.
> Ошибка в синтаксисе команды.
> {noformat}
> Expected: "warning: 32-bit driver is not specified. If you want to install
> 32-bit driver please specify path to it as a second argument." message
> Actual: "Ошибка в синтаксисе команды".
> 3) Install x64 bit driver according to
> $IGNITE_HOME\platforms\cpp\odbc\README.txt. Pass \ (root directory) as a
> second parameter (x32 driver):
> {noformat}
> D:\ignite\platforms\cpp\odbc\install>install_amd64.cmd
> D:\ignite\platforms\cpp\project\vs\x64\Release\ignite.odbc.dll \
> Installing 64-bit driver:
> D:\ignite\platforms\cpp\project\vs\x64\Release\ignite.odbc.dll
> Операция успешно завершена.
> Операция успешно завершена.
> Операция успешно завершена.
> Операция успешно завершена.
> Операция успешно завершена.
> Installing 32-bit driver: \
> Операция успешно завершена.
> Операция успешно завершена.
> Операция успешно завершена.
> Операция успешно завершена.
> Операция успешно завершена.
> {noformat}
> Expected:
> "warning: The path you have specified seems to be a directory. Note that you
> have to specify path to driver file itself instead." warning before
> "Installing 32-bit driver: \"
> Actual: no such a warning (if exist %ODBC_X86%\ -> if exist \ \ -> false. So
> this check doesn't work in this case).
> Please, consider some changes in error handling.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (IGNITE-4827) Remove deprecated code related to backward compatibility
[ https://issues.apache.org/jira/browse/IGNITE-4827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15934581#comment-15934581 ] Taras Ledkov edited comment on IGNITE-4827 at 3/22/17 2:28 PM: --- Tests [results|http://195.239.208.174/project.html?projectId=IgniteTests&tab=projectOverview&branch_IgniteTests=pull%2F1654%2Fhead] is OK with me. I don't see the significant difference of the tests results between the master branch and the patch. was (Author: tledkov-gridgain): Waits for TC [results|http://195.239.208.174/project.html?projectId=IgniteTests&tab=projectOverview&branch_IgniteTests=pull%2F1654%2Fhead] > Remove deprecated code related to backward compatibility > > > Key: IGNITE-4827 > URL: https://issues.apache.org/jira/browse/IGNITE-4827 > Project: Ignite > Issue Type: Sub-task >Reporter: Taras Ledkov >Assignee: Taras Ledkov > Fix For: 2.0 > > > Must be removed / refactored: > - LATE_AFF_ASSIGN_SINCE; > - LOAD_CACHE_JOB_SINCE and the class GridCacheAdapter.LoadKeysCallable; > - PartitionSizeLongTask.SINCE_VER; > - compatibility at the VisorCacheConfiguration; > - GridDhtPartitionMap; > - NEAR_JOB_SINCE; > - CUSTOM_MSG_ALLOW_JOINING_FOR_VERIFIED_SINCE; > - VisorCache compatibility (older version of the VisorCache classes); > - multiple connection compatibility; > - partitions map compression compatibility; > - old rebalance API; > - CacheContinuousQueryBatchAck.SINCE_VER; > - GridQueryRequest > - services compatibility with older version; > - BINARY_CFG_CHECK_SINCE; > - GridQueryRequest; > - SINGLE_GET_MSG_SINCE; > - LOCAL_STORE_KEEPS_PRIMARY_AND_BACKUPS_SINCE; > - compatibility at compute closures; > - continuous query compatibility; > - CLIENT_ACK_SINCE_VERSION -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-2703) .NET: Dynamically registered classes must use binary serialization if possible
[ https://issues.apache.org/jira/browse/IGNITE-2703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15936364#comment-15936364 ] ASF GitHub Bot commented on IGNITE-2703: GitHub user ptupitsyn opened a pull request: https://github.com/apache/ignite/pull/1664 IGNITE-2703 .NET: Dynamic type registration You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-2703 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/1664.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1664 commit 792506a63572b0b50e47b11c3a6e54065768ac98 Author: Pavel Tupitsyn Date: 2017-02-10T11:56:55Z IGNITE-2703 .NET: Dynamic type registration commit 4588e455889025487bbd1c27ef7fe732cfcb1b4c Author: Pavel Tupitsyn Date: 2017-02-15T13:48:54Z Merge branch 'ignite-2.0' into ignite-2703 # Conflicts: # modules/core/src/main/java/org/apache/ignite/internal/binary/BinaryContext.java commit d7c6a7f2f898b489cdd137e17f2ed5203d39c3d0 Author: Pavel Tupitsyn Date: 2017-02-15T15:31:39Z Fix ExecutableTest commit 8d6e9963a8fdd846fa64c5db1f431a609e0e7d5d Author: Pavel Tupitsyn Date: 2017-02-15T15:33:27Z Remove unused imports commit 4ee6e26710cd3d95827eeb60042dde384a56e4bd Author: Pavel Tupitsyn Date: 2017-02-15T15:38:38Z Fix typos commit 32a01d20412608dce29190a9ed5e80d077ea9dcf Author: Pavel Tupitsyn Date: 2017-02-16T12:49:53Z Merge branch 'ignite-2.0' into ignite-2703 commit 88e844b25c5595ad5b7f98fbce142e6e8f77a9dd Author: Pavel Tupitsyn Date: 2017-02-16T12:56:01Z Fix TestEchoTaskBinarizableNoClass commit 827887fac0dc75fbed3a583b8ae690256fe6eca7 Author: Pavel Tupitsyn Date: 2017-02-16T13:01:02Z Fix TestDelegate commit 72ad8a585d8d40b0edc0fbb23f6c410d0b7682ae Author: Pavel Tupitsyn Date: 2017-02-16T13:06:45Z Disable type registration in system marshaller to avoid unexpected conflicts commit 706bba2cc05b8ece689dab3d398815fc826d41a0 Author: Pavel Tupitsyn Date: 2017-02-16T13:08:47Z Remove unused BinaryStreamAdapter commit c205e6d518a2147592b23bccb141072cf682f248 Author: Pavel Tupitsyn Date: 2017-03-22T14:00:08Z Merge branch 'master' into ignite-2703 # Conflicts: # modules/platforms/dotnet/Apache.Ignite.Core.Tests/Binary/Serializable/AdvancedSerializationTest.cs # modules/platforms/dotnet/Apache.Ignite.Core/Common/IgniteGuid.cs # modules/platforms/dotnet/Apache.Ignite.Core/Impl/Binary/Marshaller.cs commit 949f8ec9e06665ff35312e799b20bf5b1736ee13 Author: Pavel Tupitsyn Date: 2017-03-22T14:05:42Z Fix merge > .NET: Dynamically registered classes must use binary serialization if possible > -- > > Key: IGNITE-2703 > URL: https://issues.apache.org/jira/browse/IGNITE-2703 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 1.5.0.final >Reporter: Vladimir Ozerov >Assignee: Pavel Tupitsyn > Labels: .net, breaking-api > Fix For: 2.0 > > > At present we support dynamic class registration in .NET, but they are > written using deafult .NET mechanism. This is counterintuitive for users and > not consistent with Java, where such classes are written in binary form. > Proposed implementation plan: > 1) For each dynamically registered class we must understand whether it could > be serialized through binary or not. If not - print a warning and fallback to > .NET. > 2) Before writing a class we must ensure that it's [typeId -> name] pair is > known to the cluster. If not - write full class name instead of type ID. Java > already do that. > 3) Last, to support backward compatibility we must be able to fallback to > current mode with help of some boolean flag. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4761) ServiceProcessor hangs while stopping on unstable topology.
[ https://issues.apache.org/jira/browse/IGNITE-4761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15936366#comment-15936366 ] ASF GitHub Bot commented on IGNITE-4761: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/1602 > ServiceProcessor hangs while stopping on unstable topology. > --- > > Key: IGNITE-4761 > URL: https://issues.apache.org/jira/browse/IGNITE-4761 > Project: Ignite > Issue Type: Bug > Components: cache, managed services >Affects Versions: 1.7 >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Critical > Fix For: 2.0 > > > GridServiceProcessor.onKernalStop can be blocked on taking busyLock when > the lock is being held by TopologyListener while infinite waiting for > readyAffinityFuture. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-2703) .NET: Dynamically registered classes must use binary serialization if possible
[ https://issues.apache.org/jira/browse/IGNITE-2703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15936367#comment-15936367 ] Pavel Tupitsyn commented on IGNITE-2703: ignite-2.0 got merged to master, so previous PR got closed. Merged from master into ignite-2703, created new PR: https://github.com/apache/ignite/pull/1664 > .NET: Dynamically registered classes must use binary serialization if possible > -- > > Key: IGNITE-2703 > URL: https://issues.apache.org/jira/browse/IGNITE-2703 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 1.5.0.final >Reporter: Vladimir Ozerov >Assignee: Pavel Tupitsyn > Labels: .net, breaking-api > Fix For: 2.0 > > > At present we support dynamic class registration in .NET, but they are > written using deafult .NET mechanism. This is counterintuitive for users and > not consistent with Java, where such classes are written in binary form. > Proposed implementation plan: > 1) For each dynamically registered class we must understand whether it could > be serialized through binary or not. If not - print a warning and fallback to > .NET. > 2) Before writing a class we must ensure that it's [typeId -> name] pair is > known to the cluster. If not - write full class name instead of type ID. Java > already do that. > 3) Last, to support backward compatibility we must be able to fallback to > current mode with help of some boolean flag. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (IGNITE-3579) Message type should be short.
[
https://issues.apache.org/jira/browse/IGNITE-3579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15936296#comment-15936296
]
Taras Ledkov edited comment on IGNITE-3579 at 3/22/17 2:09 PM:
---
[~vozerov], agreed.
Also i fixed serialization of the internal messages: nodeId, handshake and
recovery last received.
Waits for TC results
was (Author: tledkov-gridgain):
[~vozerov], agreed.
Also i fixed serialization of the internal messages: nodeId, handshake and
recovery last received.
> Message type should be short.
> -
>
> Key: IGNITE-3579
> URL: https://issues.apache.org/jira/browse/IGNITE-3579
> Project: Ignite
> Issue Type: Task
> Components: general
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>Priority: Critical
> Labels: important
> Fix For: 2.0
>
>
> Currently we encode internal messages with {{byte}}. It turns out that we
> almost exhausted possible IDs.
> We should change {{byte}} to {{short}} for message ID.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (IGNITE-4710) Better optimistic tx lock conflict client information.
[ https://issues.apache.org/jira/browse/IGNITE-4710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ksenia Rybakova closed IGNITE-4710. --- > Better optimistic tx lock conflict client information. > -- > > Key: IGNITE-4710 > URL: https://issues.apache.org/jira/browse/IGNITE-4710 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 1.8 >Reporter: Stanilovsky Evgeny >Assignee: Semen Boikov >Priority: Minor > Fix For: 2.0 > > > On tx optimistic exception we should provide information about key causing > conflict for easier debugging of conflict source. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-3579) Message type should be short.
[
https://issues.apache.org/jira/browse/IGNITE-3579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15936296#comment-15936296
]
Taras Ledkov commented on IGNITE-3579:
--
[~vozerov], agreed.
Also i fixed serialization of the internal messages: nodeId, handshake and
recovery last received.
> Message type should be short.
> -
>
> Key: IGNITE-3579
> URL: https://issues.apache.org/jira/browse/IGNITE-3579
> Project: Ignite
> Issue Type: Task
> Components: general
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>Priority: Critical
> Labels: important
> Fix For: 2.0
>
>
> Currently we encode internal messages with {{byte}}. It turns out that we
> almost exhausted possible IDs.
> We should change {{byte}} to {{short}} for message ID.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (IGNITE-4587) Discontinue and remove CacheAtomicWriteOrderMode.CLOCK mode
[
https://issues.apache.org/jira/browse/IGNITE-4587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15936278#comment-15936278
]
Maksim Kozlov edited comment on IGNITE-4587 at 3/22/17 1:18 PM:
[~agura] Are these your internal tests?
Can you find out more in which cases is it {{CLOCK}} mode more preferable?
was (Author: dreamx):
[~agura] Are these your internal tests?
Can you find out more in which cases is it {CLOCK} mode more preferable?
> Discontinue and remove CacheAtomicWriteOrderMode.CLOCK mode
> ---
>
> Key: IGNITE-4587
> URL: https://issues.apache.org/jira/browse/IGNITE-4587
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Denis Magda
>Assignee: Maksim Kozlov
> Fix For: 2.0
>
>
> {{CacheAtomicWriteOrderMode.CLOCK}} proved to be harmful in production due to
> timing issues.
> It makes sense to remove it completely in 2.0 release. Migration guide has be
> updated:
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0+Migration+Guide
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-4587) Discontinue and remove CacheAtomicWriteOrderMode.CLOCK mode
[
https://issues.apache.org/jira/browse/IGNITE-4587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15936278#comment-15936278
]
Maksim Kozlov commented on IGNITE-4587:
---
[~agura] Are these your internal tests?
Can you find out more in which cases is it {CLOCK} mode more preferable?
> Discontinue and remove CacheAtomicWriteOrderMode.CLOCK mode
> ---
>
> Key: IGNITE-4587
> URL: https://issues.apache.org/jira/browse/IGNITE-4587
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Denis Magda
>Assignee: Maksim Kozlov
> Fix For: 2.0
>
>
> {{CacheAtomicWriteOrderMode.CLOCK}} proved to be harmful in production due to
> timing issues.
> It makes sense to remove it completely in 2.0 release. Migration guide has be
> updated:
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0+Migration+Guide
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (IGNITE-4587) Discontinue and remove CacheAtomicWriteOrderMode.CLOCK mode
[
https://issues.apache.org/jira/browse/IGNITE-4587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15936248#comment-15936248
]
Andrey Gura edited comment on IGNITE-4587 at 3/22/17 12:57 PM:
---
[~dreamx], thank you very much for your contribution. But performance tests
showed performance drop for some configuration, so {{CLOCK}} mode is still
preferable for some cases.
It's possible that your PR will be useful in the future when workaround without
performance penalty will be found.
Thanks a lot again :)
was (Author: agura):
[~dreamx], thank you very much for your contribution. But performance tests
showed performance drop for some configuration, so {{CLOCK}} mode is still
preferable for some cases.
It's possible that your PR will be useful in the future.
Thanks a lot again :)
> Discontinue and remove CacheAtomicWriteOrderMode.CLOCK mode
> ---
>
> Key: IGNITE-4587
> URL: https://issues.apache.org/jira/browse/IGNITE-4587
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Denis Magda
>Assignee: Maksim Kozlov
> Fix For: 2.0
>
>
> {{CacheAtomicWriteOrderMode.CLOCK}} proved to be harmful in production due to
> timing issues.
> It makes sense to remove it completely in 2.0 release. Migration guide has be
> updated:
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0+Migration+Guide
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-4587) Discontinue and remove CacheAtomicWriteOrderMode.CLOCK mode
[
https://issues.apache.org/jira/browse/IGNITE-4587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15936248#comment-15936248
]
Andrey Gura commented on IGNITE-4587:
-
[~dreamx], thank you very much for your contribution. But performance tests
showed performance drop for some configuration, so {{CLOCK}} mode is still
preferable for some cases.
It's possible that your PR will be useful in the future.
Thanks a lot again :)
> Discontinue and remove CacheAtomicWriteOrderMode.CLOCK mode
> ---
>
> Key: IGNITE-4587
> URL: https://issues.apache.org/jira/browse/IGNITE-4587
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Denis Magda
>Assignee: Maksim Kozlov
> Fix For: 2.0
>
>
> {{CacheAtomicWriteOrderMode.CLOCK}} proved to be harmful in production due to
> timing issues.
> It makes sense to remove it completely in 2.0 release. Migration guide has be
> updated:
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0+Migration+Guide
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-3575) CPP: Support continuous queries remote filters.
[ https://issues.apache.org/jira/browse/IGNITE-3575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15936234#comment-15936234 ] Igor Sapego commented on IGNITE-3575: - [~vozerov], re-merged. Added new Upsource review and PR. > CPP: Support continuous queries remote filters. > --- > > Key: IGNITE-3575 > URL: https://issues.apache.org/jira/browse/IGNITE-3575 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 1.6 >Reporter: Vladimir Ozerov >Assignee: Igor Sapego > Labels: cpp > Fix For: 2.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-3575) CPP: Support continuous queries remote filters.
[ https://issues.apache.org/jira/browse/IGNITE-3575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15936231#comment-15936231 ] ASF GitHub Bot commented on IGNITE-3575: GitHub user isapego opened a pull request: https://github.com/apache/ignite/pull/1663 IGNITE-3575: CPP: Implemented remote filters for continuous queries You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-3575 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/1663.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1663 commit 3c7e6a1d09dce8330de1fb27205c7e19c4588eb8 Author: Igor Sapego Date: 2017-03-07T12:51:21Z IGNITE-3575: Added CacheEntryEventFilter commit decf08ef4789e76a22cbf67b474141d0fbd8066d Author: Igor Sapego Date: 2017-03-10T17:38:12Z IGNITE-3575: Added CacheEntryEventFilterHolder commit 33263d9f0f8b61612630fc102b99137236b79836 Author: Igor Sapego Date: 2017-03-13T14:21:27Z IGNITE-3575: Added test commit 8ad02351697266da287adfe678a4de15aaeb5049 Author: Igor Sapego Date: 2017-03-13T17:01:55Z IGNITE-3575: Refactored IgniteBindingImpl commit a00dff47cffd3d35bf198e2d775178b05d6b0837 Author: Igor Sapego Date: 2017-03-14T11:47:01Z IGNITE-3575: Implemented filter creation. commit 04c57b373706d8afe59a07413509207dd8d8c228 Author: Igor Sapego Date: 2017-03-14T13:26:22Z IGNITE-3575: Fully implemented. Not tested. Refactoring required. commit 3da327e437fe0bf893ed7da3ba3f9522708898f8 Author: Igor Sapego Date: 2017-03-14T15:12:34Z IGNITE-3575: Implemented for local case commit b67b6d89af30c5d6702a9e1e5e7d4e979ab23b95 Author: Igor Sapego Date: 2017-03-14T15:53:20Z IGNITE-3575: implemented for remote nodes. commit 62b45757f4b0ca9bebb71b5b4add1a6f1c3a5e86 Author: Igor Sapego Date: 2017-03-14T16:41:32Z IGNITE-3575: Refactoring commit 10b9bdf4ee2198912341336b8ddbddb299829e6b Author: Igor Sapego Date: 2017-03-14T17:03:25Z IGNITE-3575: Redactoring. commit 931b3ef38a48708383537101264bb05a32117efe Author: Igor Sapego Date: 2017-03-14T17:12:10Z Merge remote-tracking branch 'upstream/ignite-2.0' into ignite-3575 commit b3934ce4560737048bdad3bf9142a5228f32b88c Author: Igor Sapego Date: 2017-03-14T17:20:14Z IGNITE-3575: Fix for Linux commit 98235066392eeb23e4a53856f9d89cb8bf606ef5 Author: Igor Sapego Date: 2017-03-14T17:54:01Z IGNITE-3575: Fixes for Linux commit 4176324d9cf32827540f61538d1e6a48f3cc1e40 Author: Igor Sapego Date: 2017-03-15T13:43:51Z IGNITE-3575: Fix for tests commit 8d4e54e6a27dd72b2b31b37d98ad2936bdb691cb Author: Igor Sapego Date: 2017-03-22T12:42:21Z Merge remote-tracking branch 'upstream/master' into ignite-3575 > CPP: Support continuous queries remote filters. > --- > > Key: IGNITE-3575 > URL: https://issues.apache.org/jira/browse/IGNITE-3575 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 1.6 >Reporter: Vladimir Ozerov >Assignee: Igor Sapego > Labels: cpp > Fix For: 2.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4829) Spring context is not injected into POJO store when JDBC driver is utilized
[
https://issues.apache.org/jira/browse/IGNITE-4829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15936227#comment-15936227
]
Andrey Gura commented on IGNITE-4829:
-
Thanks [~kuaw26]! I've added a few comments to review. But in general looks
good for me.
> Spring context is not injected into POJO store when JDBC driver is utilized
> ---
>
> Key: IGNITE-4829
> URL: https://issues.apache.org/jira/browse/IGNITE-4829
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.9
>Reporter: Denis Magda
>Assignee: Andrey Gura
>Priority: Critical
> Fix For: 2.0
>
> Attachments: SampleJdbcApp.zip
>
>
> Faced with the exception reported in the discussion initiated a long time ago:
> http://apache-ignite-users.70518.x6.nabble.com/ignite-Spring-application-context-resource-is-not-injected-problem-td6377.html
> Basically, I get the same exception:
> {code}
> class org.apache.ignite.IgniteException: Spring application context resource
> is not injected.
> at
> org.apache.ignite.cache.store.jdbc.CacheJdbcPojoStoreFactory.create(CacheJdbcPojoStoreFactory.java:171)
> at
> org.apache.ignite.cache.store.jdbc.CacheJdbcPojoStoreFactory.create(CacheJdbcPojoStoreFactory.java:100)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.createCache(GridCacheProcessor.java:1261)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:791)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:950)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1799)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1602)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1042)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:569)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:516)
> at org.apache.ignite.Ignition.start(Ignition.java:322)
> at
> org.apache.ignite.internal.jdbc2.JdbcConnection.getIgnite(JdbcConnection.java:191)
> at
> org.apache.ignite.internal.jdbc2.JdbcConnection.(JdbcConnection.java:152)
> at org.apache.ignite.IgniteJdbcDriver.connect(IgniteJdbcDriver.java:361)
> at java.sql.DriverManager.getConnection(DriverManager.java:664)
> at java.sql.DriverManager.getConnection(DriverManager.java:270)
> at Main.initIgniteConnection(Main.java:260)
> at Main.main(Main.java:29)
> 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:498)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
> {code}
> The exception occurs when my application uses Ignite JDBC driver to connect
> to a cluster. The cluster persists data to a relation database (Postrgers),
> so I have the POJO store defined in the application configuration. The latter
> was generated for by Apache Ignite Web Console and the POJO store is set by
> {{CacheJdbcPojoStoreFactory.dataSourceBean}} which causes the error.
> If I set the POJO store using {{CacheJdbcPojoStoreFactory.dataSource}} method
> then the issue disappears.
> To reproduce the issue do the following:
> - Unzip the attached project and start {{ServerNode}} class.
> - Start the sample application that uses Ignite JDBC driver and you'll get
> the reported exception.
> Change the configuration from {{ignite-jdbc-bad}} to {{ignite-jdbc}} and the
> exception dissappears because the latter sets the store using
> {{CacheJdbcPojoStoreFactory.dataSource}}.
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Issue Comment Deleted] (IGNITE-4760) Hibernate L2 cache stores value in wrong cache
[ https://issues.apache.org/jira/browse/IGNITE-4760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vadim Opolski updated IGNITE-4760: -- Comment: was deleted (was: https://github.com/apache/ignite/pull/1662) > Hibernate L2 cache stores value in wrong cache > -- > > Key: IGNITE-4760 > URL: https://issues.apache.org/jira/browse/IGNITE-4760 > Project: Ignite > Issue Type: Bug > Components: Hibernate L2 cache >Reporter: Semen Boikov >Assignee: Vadim Opolski > Fix For: 2.0 > > > Issue is reported here: > http://apache-ignite-developers.2346864.n4.nabble.com/issue-with-Hibernate-2L-cache-region-factory-ignite-1-8-td14912.html > First it is necessary add JUnit test reproducing issue (see existing tests in > IgniteHibernateTestSuite). > Currently Hibernate access strategies track updates using thread locals, and > it looks like updates for different caches can be mixed. I think per-cache > thread local can fix issue for HibernateNonStrictAccessStrategy, but > per-cache thread local can not be used for HibernateReadWriteAccessStrategy, > since it is assumed that all updates should be part of the same cross-cache > ignite transaction. > So possible fix: > - use per-cache thread local for HibernateNonStrictAccessStrategy (or somehow > track target cache in HibernateNonStrictAccessStrategy) > - use single thread local for HibernateReadWriteAccessStrategy -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4760) Hibernate L2 cache stores value in wrong cache
[ https://issues.apache.org/jira/browse/IGNITE-4760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15936214#comment-15936214 ] Vadim Opolski commented on IGNITE-4760: --- https://github.com/apache/ignite/pull/1662 > Hibernate L2 cache stores value in wrong cache > -- > > Key: IGNITE-4760 > URL: https://issues.apache.org/jira/browse/IGNITE-4760 > Project: Ignite > Issue Type: Bug > Components: Hibernate L2 cache >Reporter: Semen Boikov >Assignee: Vadim Opolski > Fix For: 2.0 > > > Issue is reported here: > http://apache-ignite-developers.2346864.n4.nabble.com/issue-with-Hibernate-2L-cache-region-factory-ignite-1-8-td14912.html > First it is necessary add JUnit test reproducing issue (see existing tests in > IgniteHibernateTestSuite). > Currently Hibernate access strategies track updates using thread locals, and > it looks like updates for different caches can be mixed. I think per-cache > thread local can fix issue for HibernateNonStrictAccessStrategy, but > per-cache thread local can not be used for HibernateReadWriteAccessStrategy, > since it is assumed that all updates should be part of the same cross-cache > ignite transaction. > So possible fix: > - use per-cache thread local for HibernateNonStrictAccessStrategy (or somehow > track target cache in HibernateNonStrictAccessStrategy) > - use single thread local for HibernateReadWriteAccessStrategy -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4052) Add ability to set up users for MESOS
[ https://issues.apache.org/jira/browse/IGNITE-4052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15936205#comment-15936205 ] ASF GitHub Bot commented on IGNITE-4052: GitHub user vadopolski opened a pull request: https://github.com/apache/ignite/pull/1662 IGNITE-4052 Protos.FrameworkInfoSetup.SetUser added getting MESOS_USER option. You can merge this pull request into a Git repository by running: $ git pull https://github.com/vadopolski/ignite IGNITE-4052 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/1662.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1662 commit f137d15a21b5432b9886899dfaa90c8ba47ca604 Author: vopolski <2w3e4r5t> Date: 2017-03-22T12:16:38Z IGNITE-4052 Protos.FrameworkInfoSetup.SetUser added getting MESOS_USER option. > Add ability to set up users for MESOS > - > > Key: IGNITE-4052 > URL: https://issues.apache.org/jira/browse/IGNITE-4052 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 1.7 >Reporter: Nikolay Tikhonov >Assignee: Vadim Opolski >Priority: Trivial > > In current implementation Ignite Mesos Framework connects to MESOS cluster > via current user. Need to add ability to configure this parameters via system > env properties. Also need to add properties for mesos role. > See org/apache/ignite/mesos/IgniteFramework.java:537 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4844) Get rid of cache async operations queue
[ https://issues.apache.org/jira/browse/IGNITE-4844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15936185#comment-15936185 ] Konstantin Dudkov commented on IGNITE-4844: --- I got rid of queue in atomics, [PR1657|https://github.com/apache/ignite/pull/1657] [TC tests|http://ci.ignite.apache.org/project.html?projectId=IgniteTests&tab=projectOverview&branch_IgniteTests=pull%2F1657%2Fhead] > Get rid of cache async operations queue > --- > > Key: IGNITE-4844 > URL: https://issues.apache.org/jira/browse/IGNITE-4844 > Project: Ignite > Issue Type: Task > Components: cache >Reporter: Semen Boikov >Assignee: Konstantin Dudkov > Fix For: 2.0 > > > Now all async cache operations are internally queued and executed > sequentially one by one (see for example GridDhtAtomicCache.asyncOp). Need > get rid of this queue. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-653) Add cache name to exception message
[
https://issues.apache.org/jira/browse/IGNITE-653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15936174#comment-15936174
]
ASF GitHub Bot commented on IGNITE-653:
---
GitHub user jeyhunkarimov opened a pull request:
https://github.com/apache/ignite/pull/1661
IGNITE-653: Add cache name to exception message
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/jeyhunkarimov/ignite IGNITE-653
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/1661.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #1661
commit 02868c4484198d55684dc14152cac8cd630b57b2
Author: Jeyhun Karimov
Date: 2017-03-22T11:54:07Z
IGNITE-653 issue
> Add cache name to exception message
> ---
>
> Key: IGNITE-653
> URL: https://issues.apache.org/jira/browse/IGNITE-653
> Project: Ignite
> Issue Type: Task
> Components: cache, UI
>Affects Versions: sprint-3
>Reporter: Pavel Konstantinov
>Assignee: Jeyhun Karimov
>Priority: Trivial
>
> {code}
> CacheServerNotFoundException: Failed to map keys for cache (all partition
> nodes left the grid)
> {code}
> {code}
> ClusterTopologyServerNotFoundException: Failed to map keys for cache (all
> partition nodes left the grid).
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (IGNITE-4855) Error when switching between notebooks
Pavel Konstantinov created IGNITE-4855:
--
Summary: Error when switching between notebooks
Key: IGNITE-4855
URL: https://issues.apache.org/jira/browse/IGNITE-4855
Project: Ignite
Issue Type: Bug
Reporter: Pavel Konstantinov
{code}
TypeError: Cannot redefine property: ace
at Function.defineProperty ()
at https://staging-console.my-host.com/app.9102c5d071fa1be61279.js:13:17181
at https://staging-console.my-host.com/app.9102c5d071fa1be61279.js:7:22481
at u
(https://staging-console.my-host.com/vendor.ceecd70bedaaa641a449.js:1:1909)
at Function.gs
(https://staging-console.my-host.com/vendor.ceecd70bedaaa641a449.js:2:11302)
at r
(https://staging-console.my-host.com/app.9102c5d071fa1be61279.js:7:22424)
at y
(https://staging-console.my-host.com/app.9102c5d071fa1be61279.js:7:23641)
at Object.link
(https://staging-console.my-host.com/app.9102c5d071fa1be61279.js:7:23679)
at
https://staging-console.my-host.com/vendor.ceecd70bedaaa641a449.js:103:5660
at we
(https://staging-console.myhost.com/vendor.ceecd70bedaaa641a449.js:104:11056)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (IGNITE-4760) Hibernate L2 cache stores value in wrong cache
[ https://issues.apache.org/jira/browse/IGNITE-4760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vadim Opolski reassigned IGNITE-4760: - Assignee: Vadim Opolski > Hibernate L2 cache stores value in wrong cache > -- > > Key: IGNITE-4760 > URL: https://issues.apache.org/jira/browse/IGNITE-4760 > Project: Ignite > Issue Type: Bug > Components: Hibernate L2 cache >Reporter: Semen Boikov >Assignee: Vadim Opolski > Fix For: 2.0 > > > Issue is reported here: > http://apache-ignite-developers.2346864.n4.nabble.com/issue-with-Hibernate-2L-cache-region-factory-ignite-1-8-td14912.html > First it is necessary add JUnit test reproducing issue (see existing tests in > IgniteHibernateTestSuite). > Currently Hibernate access strategies track updates using thread locals, and > it looks like updates for different caches can be mixed. I think per-cache > thread local can fix issue for HibernateNonStrictAccessStrategy, but > per-cache thread local can not be used for HibernateReadWriteAccessStrategy, > since it is assumed that all updates should be part of the same cross-cache > ignite transaction. > So possible fix: > - use per-cache thread local for HibernateNonStrictAccessStrategy (or somehow > track target cache in HibernateNonStrictAccessStrategy) > - use single thread local for HibernateReadWriteAccessStrategy -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (IGNITE-4777) Web Console: Add notification on 'Download project' button
[ https://issues.apache.org/jira/browse/IGNITE-4777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Shabalin reassigned IGNITE-4777: Assignee: Dmitriy Shabalin > Web Console: Add notification on 'Download project' button > -- > > Key: IGNITE-4777 > URL: https://issues.apache.org/jira/browse/IGNITE-4777 > Project: Ignite > Issue Type: Task > Components: UI, wizards >Reporter: Vica Abramova >Assignee: Dmitriy Shabalin > > After the configuration user need to download project and run it to get the > result. Let's notify about this! > Also in this task we need to revise tips. And improve instructions for new > users. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (IGNITE-4727) Web Console: Fix the position of tooltips in modal windows
[ https://issues.apache.org/jira/browse/IGNITE-4727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Shabalin reassigned IGNITE-4727: Assignee: Andrey Novikov (was: Dmitriy Shabalin) Added common solution to show and set up tooltip for fields > Web Console: Fix the position of tooltips in modal windows > -- > > Key: IGNITE-4727 > URL: https://issues.apache.org/jira/browse/IGNITE-4727 > Project: Ignite > Issue Type: Bug > Components: UI, wizards >Reporter: Vica Abramova >Assignee: Andrey Novikov >Priority: Minor > Attachments: tooltips.png > > > Tooltips (in modal windows) should not go beyond the modal windows. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (IGNITE-4727) Web Console: Fix the position of tooltips in modal windows
[ https://issues.apache.org/jira/browse/IGNITE-4727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Shabalin reassigned IGNITE-4727: Assignee: Dmitriy Shabalin > Web Console: Fix the position of tooltips in modal windows > -- > > Key: IGNITE-4727 > URL: https://issues.apache.org/jira/browse/IGNITE-4727 > Project: Ignite > Issue Type: Bug > Components: UI, wizards >Reporter: Vica Abramova >Assignee: Dmitriy Shabalin >Priority: Minor > Attachments: tooltips.png > > > Tooltips (in modal windows) should not go beyond the modal windows. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (IGNITE-4810) Remove unused "removeIndex" methods
[
https://issues.apache.org/jira/browse/IGNITE-4810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ksenia Rybakova closed IGNITE-4810.
---
> Remove unused "removeIndex" methods
> ---
>
> Key: IGNITE-4810
> URL: https://issues.apache.org/jira/browse/IGNITE-4810
> Project: Ignite
> Issue Type: Task
> Components: SQL
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Minor
> Fix For: 2.0
>
>
> We have a number of {{rebuildIndex}} methods which are used only in test and
> work only for {{ONHEAP}} mode.
> Let's remove them for now and implement correctly in future, if needed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
