[jira] [Resolved] (IGNITE-2997) Failed to get field because type ID of passed object differs from type ID this BinaryField

[Stanilovsky Evgeny (JIRA)]

 [ 
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 
> 

[jira] [Assigned] (IGNITE-2997) Failed to get field because type ID of passed object differs from type ID this BinaryField

[Stanilovsky Evgeny (JIRA)]

 [ 
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 
> 

[jira] [Created] (IGNITE-4856) .NET: StopAll on AppDomain unload

[Pavel Tupitsyn (JIRA)]

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

[Denis Magda (JIRA)]

 [ 
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.

[Denis Magda (JIRA)]

 [ 
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

[Denis Magda (JIRA)]

 [ 
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

[Denis Magda (JIRA)]

 [ 
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

[Denis Magda (JIRA)]

 [ 
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

[Denis Magda (JIRA)]

 [ 
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

[Denis Magda (JIRA)]

 [ 
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

[Denis Magda (JIRA)]

 [ 
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

[Denis Magda (JIRA)]

 [ 
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

[Denis Magda (JIRA)]

 [ 
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

[Denis Magda (JIRA)]

 [ 
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

[Denis Magda (JIRA)]

 [ 
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

[Denis Magda (JIRA)]

 [ 
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

[Denis Magda (JIRA)]

 [ 
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

[Denis Magda (JIRA)]

 [ 
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

[Denis Magda (JIRA)]

 [ 
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

[Denis Magda (JIRA)]

 [ 
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 
> 

[jira] [Updated] (IGNITE-3386) Reentrant lock is lost when lock owner leaves topology

[Denis Magda (JIRA)]

 [ 
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

[Denis Magda (JIRA)]

 [ 
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-4475) Simplify async API

[Denis Magda (JIRA)]

 [ 
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

[Denis Magda (JIRA)]

 [ 
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

[Denis Magda (JIRA)]

 [ 
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

[Denis Magda (JIRA)]

 [ 
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

[Denis Magda (JIRA)]

 [ 
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

[Denis Magda (JIRA)]

 [ 
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

[Denis Magda (JIRA)]

 [ 
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

[Denis Magda (JIRA)]

 [ 
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.

[Denis Magda (JIRA)]

 [ 
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

[Denis Magda (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-4523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Denis Magda (JIRA)]

 [ 
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

[Denis Magda (JIRA)]

 [ 
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

[Denis Magda (JIRA)]

 [ 
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

[Denis Magda (JIRA)]

 [ 
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

[Denis Magda (JIRA)]

 [ 
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

[Denis Magda (JIRA)]

 [ 
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

[Denis Magda (JIRA)]

 [ 
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

[Denis Magda (JIRA)]

 [ 
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

[Denis Magda (JIRA)]

 [ 
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

[Denis Magda (JIRA)]

 [ 
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

[Denis Magda (JIRA)]

 [ 
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

[Andrey Novikov (JIRA)]

 [ 
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

[Andrey Novikov (JIRA)]

 [ 
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

[Igor Sapego (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-4617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-4617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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-4475) Simplify async API

[Taras Ledkov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-4475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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=projectOverview_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=projectOverview_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] [Comment Edited] (IGNITE-4827) Remove deprecated code related to backward compatibility

[Taras Ledkov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-4827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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=projectOverview_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=projectOverview_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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-2703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-4761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Pavel Tupitsyn (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-2703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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.

[Taras Ledkov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-3579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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.

[Ksenia Rybakova (JIRA)]

 [ 
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.

[Taras Ledkov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-3579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Maksim Kozlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-4587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Maksim Kozlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-4587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Commented] (IGNITE-3575) CPP: Support continuous queries remote filters.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-3575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Andrey Gura (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-4829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Commented] (IGNITE-4760) Hibernate L2 cache stores value in wrong cache

[Vadim Opolski (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-4760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-4052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Konstantin Dudkov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-4844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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=projectOverview_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] [Assigned] (IGNITE-4777) Web Console: Add notification on 'Download project' button

[Dmitriy Shabalin (JIRA)]

 [ 
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

[Dmitriy Shabalin (JIRA)]

 [ 
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

[Dmitriy Shabalin (JIRA)]

 [ 
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

[Ksenia Rybakova (JIRA)]

 [ 
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)

[jira] [Commented] (IGNITE-4691) ODBC: Support java.sql.Time

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-4691:


[~isapego] looks good to me.

> ODBC: Support java.sql.Time
> ---
>
> Key: IGNITE-4691
> URL: https://issues.apache.org/jira/browse/IGNITE-4691
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Reporter: Vladimir Ozerov
>Assignee: Igor Sapego
> Fix For: 2.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)