[jira] [Created] (IGNITE-4472) Web Console: Implement usage tracing

[Dmitriy Shabalin (JIRA)]

Dmitriy Shabalin created IGNITE-4472:


 Summary: Web Console: Implement usage tracing
 Key: IGNITE-4472
 URL: https://issues.apache.org/jira/browse/IGNITE-4472
 Project: Ignite
  Issue Type: Task
Reporter: Dmitriy Shabalin
Assignee: Dmitriy Shabalin


We need to track some kind of "activity scores" for users.
Activities:
# Configuration
# SQL
# Demo

And show that score on admin panel.

May be this could be implemented by some library.




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

[jira] [Commented] (IGNITE-1943) ignitevisorcmd: wrong behavior for "mclear" command

[Saikat Maitra (JIRA)]

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

Saikat Maitra commented on IGNITE-1943:
---

[~dmagda]

Thank you Denis !!!

> ignitevisorcmd: wrong behavior for "mclear" command
> ---
>
> Key: IGNITE-1943
> URL: https://issues.apache.org/jira/browse/IGNITE-1943
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.5.0.final
>Reporter: Vasilisa  Sidorova
>Assignee: Saikat Maitra
> Fix For: 2.0
>
>
> -
> DESCRIPTION
> -
> "mclear" should clears all Visor console variables before they will be 
> updated during next run of the corresponding command. It OK for all type of 
> shortcut (@cX, @tX, @aX, @eX) exept shortcut for node-id variables. After 
> "mclear" @nX are disappear from any statistics 
> -
> STEPS FOR REPRODUCE
> -
> # Start cluster
> # Start visorcmd ([IGNITE_HOME]/bin/ignitevisorcmd.sh)
> # Connect to the started cluster (visor> open)
> # Execute any tasks in it (for example, run any example from EventsExample, 
> DeploymentExample, ComputeContinuousMapperExample, ComputeTaskMapExample, 
> ComputeTaskSplitExample) 
> # Create several alerts (visor> alert)
> # Run visor "mclear" command
> # Run visor "node" command
> -
> ACTUAL RESULT
> -
> There isn't @nX values in the first table's column:
> {noformat}
> visor> node
> Select node from:
> +==+
> | # |   Node ID8(@), IP   | Up Time  | CPUs | CPU Load | Free Heap |
> +==+
> | 0 | 6B3E4033, 127.0.0.1 | 00:38:41 | 8| 0.20 %   | 97.00 %   |
> | 1 | 0A0D6989, 127.0.0.1 | 00:38:22 | 8| 0.17 %   | 97.00 %   |
> | 2 | 0941E33F, 127.0.0.1 | 00:35:46 | 8| 0.23 %   | 97.00 %   |
> +--+
> {noformat}
> -
> EXPECTED RESULT
> -
> There is @nX values in the first table's column:
> {noformat}
> visor> node
> Select node from:
> +===+
> | # | Node ID8(@), IP  | Up Time  | CPUs | CPU Load | Free Heap |
> +===+
> | 0 | 6B3E4033(@n0), 127.0.0.1 | 00:38:13 | 8| 0.23 %   | 97.00 %   |
> | 1 | 0A0D6989(@n1), 127.0.0.1 | 00:37:54 | 8| 0.27 %   | 97.00 %   |
> | 2 | 0941E33F(@n2), 127.0.0.1 | 00:35:18 | 8| 0.20 %   | 97.00 %   |
> +---+
> {noformat}
> "mclear" should get effect only for "mget @nX" command (with result "Missing 
> variable with name: '@nX'") and @nX variables  should get new values after 
> "node" (or "tasks") command execution. Like in case for all others @ 
> variables (@cX, @tX, @aX, @eX) 



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

[jira] [Commented] (IGNITE-1943) ignitevisorcmd: wrong behavior for "mclear" command

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-1943:
-

Saikat, thanks! Please don't hesitate pushing the community over the dev list 
if you don't get an answer on your questions in JIRA tickets.

> ignitevisorcmd: wrong behavior for "mclear" command
> ---
>
> Key: IGNITE-1943
> URL: https://issues.apache.org/jira/browse/IGNITE-1943
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.5.0.final
>Reporter: Vasilisa  Sidorova
>Assignee: Saikat Maitra
> Fix For: 2.0
>
>
> -
> DESCRIPTION
> -
> "mclear" should clears all Visor console variables before they will be 
> updated during next run of the corresponding command. It OK for all type of 
> shortcut (@cX, @tX, @aX, @eX) exept shortcut for node-id variables. After 
> "mclear" @nX are disappear from any statistics 
> -
> STEPS FOR REPRODUCE
> -
> # Start cluster
> # Start visorcmd ([IGNITE_HOME]/bin/ignitevisorcmd.sh)
> # Connect to the started cluster (visor> open)
> # Execute any tasks in it (for example, run any example from EventsExample, 
> DeploymentExample, ComputeContinuousMapperExample, ComputeTaskMapExample, 
> ComputeTaskSplitExample) 
> # Create several alerts (visor> alert)
> # Run visor "mclear" command
> # Run visor "node" command
> -
> ACTUAL RESULT
> -
> There isn't @nX values in the first table's column:
> {noformat}
> visor> node
> Select node from:
> +==+
> | # |   Node ID8(@), IP   | Up Time  | CPUs | CPU Load | Free Heap |
> +==+
> | 0 | 6B3E4033, 127.0.0.1 | 00:38:41 | 8| 0.20 %   | 97.00 %   |
> | 1 | 0A0D6989, 127.0.0.1 | 00:38:22 | 8| 0.17 %   | 97.00 %   |
> | 2 | 0941E33F, 127.0.0.1 | 00:35:46 | 8| 0.23 %   | 97.00 %   |
> +--+
> {noformat}
> -
> EXPECTED RESULT
> -
> There is @nX values in the first table's column:
> {noformat}
> visor> node
> Select node from:
> +===+
> | # | Node ID8(@), IP  | Up Time  | CPUs | CPU Load | Free Heap |
> +===+
> | 0 | 6B3E4033(@n0), 127.0.0.1 | 00:38:13 | 8| 0.23 %   | 97.00 %   |
> | 1 | 0A0D6989(@n1), 127.0.0.1 | 00:37:54 | 8| 0.27 %   | 97.00 %   |
> | 2 | 0941E33F(@n2), 127.0.0.1 | 00:35:18 | 8| 0.20 %   | 97.00 %   |
> +---+
> {noformat}
> "mclear" should get effect only for "mget @nX" command (with result "Missing 
> variable with name: '@nX'") and @nX variables  should get new values after 
> "node" (or "tasks") command execution. Like in case for all others @ 
> variables (@cX, @tX, @aX, @eX) 



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

[jira] [Commented] (IGNITE-1943) ignitevisorcmd: wrong behavior for "mclear" command

[Saikat Maitra (JIRA)]

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

Saikat Maitra commented on IGNITE-1943:
---

[~dmagda]

Hi Denis,

Yes, I will finalize task and complete this ticket. 

Regards
Saikat

> ignitevisorcmd: wrong behavior for "mclear" command
> ---
>
> Key: IGNITE-1943
> URL: https://issues.apache.org/jira/browse/IGNITE-1943
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.5.0.final
>Reporter: Vasilisa  Sidorova
>Assignee: Saikat Maitra
> Fix For: 2.0
>
>
> -
> DESCRIPTION
> -
> "mclear" should clears all Visor console variables before they will be 
> updated during next run of the corresponding command. It OK for all type of 
> shortcut (@cX, @tX, @aX, @eX) exept shortcut for node-id variables. After 
> "mclear" @nX are disappear from any statistics 
> -
> STEPS FOR REPRODUCE
> -
> # Start cluster
> # Start visorcmd ([IGNITE_HOME]/bin/ignitevisorcmd.sh)
> # Connect to the started cluster (visor> open)
> # Execute any tasks in it (for example, run any example from EventsExample, 
> DeploymentExample, ComputeContinuousMapperExample, ComputeTaskMapExample, 
> ComputeTaskSplitExample) 
> # Create several alerts (visor> alert)
> # Run visor "mclear" command
> # Run visor "node" command
> -
> ACTUAL RESULT
> -
> There isn't @nX values in the first table's column:
> {noformat}
> visor> node
> Select node from:
> +==+
> | # |   Node ID8(@), IP   | Up Time  | CPUs | CPU Load | Free Heap |
> +==+
> | 0 | 6B3E4033, 127.0.0.1 | 00:38:41 | 8| 0.20 %   | 97.00 %   |
> | 1 | 0A0D6989, 127.0.0.1 | 00:38:22 | 8| 0.17 %   | 97.00 %   |
> | 2 | 0941E33F, 127.0.0.1 | 00:35:46 | 8| 0.23 %   | 97.00 %   |
> +--+
> {noformat}
> -
> EXPECTED RESULT
> -
> There is @nX values in the first table's column:
> {noformat}
> visor> node
> Select node from:
> +===+
> | # | Node ID8(@), IP  | Up Time  | CPUs | CPU Load | Free Heap |
> +===+
> | 0 | 6B3E4033(@n0), 127.0.0.1 | 00:38:13 | 8| 0.23 %   | 97.00 %   |
> | 1 | 0A0D6989(@n1), 127.0.0.1 | 00:37:54 | 8| 0.27 %   | 97.00 %   |
> | 2 | 0941E33F(@n2), 127.0.0.1 | 00:35:18 | 8| 0.20 %   | 97.00 %   |
> +---+
> {noformat}
> "mclear" should get effect only for "mget @nX" command (with result "Missing 
> variable with name: '@nX'") and @nX variables  should get new values after 
> "node" (or "tasks") command execution. Like in case for all others @ 
> variables (@cX, @tX, @aX, @eX) 



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

[jira] [Comment Edited] (IGNITE-4157) Use discovery custom messages instead of marshaller cache

[Sergey Chugunov (JIRA)]

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

Sergey Chugunov edited comment on IGNITE-4157 at 12/22/16 4:57 AM:
---

Implemented server node failure safe case for #4, doing more testing of 
implementation.


was (Author: sergey-chugunov):
Implemented server node failure safe case for #4.

> Use discovery custom messages instead of marshaller cache
> -
>
> Key: IGNITE-4157
> URL: https://issues.apache.org/jira/browse/IGNITE-4157
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Reporter: Alexey Goncharuk
>Assignee: Sergey Chugunov
> Fix For: 2.0
>
>
> Currently we use system caches for keeping classname to class ID mapping and 
> for storing binary metadata
> This has several serious disadvantages:
> 1) We need to introduce at least two additional thread pools for each of 
> these caches
> 2) Since cache operations require stable topology, registering a class ID or 
> updating metadata inside a transaction or another cache operation is tricky 
> and deadlock-prone.
> 3) It may be beneficial in some cases to have nodes with no caches at all, 
> currently this is impossible because system caches are always present.
> 4) Reading binary metadata leads to huge local contention, caching metadata 
> values in a local map doubles memory consumption
> I suggest we use discovery custom events for these purposes. Each node will 
> have a corresponding local map (state) which will be updated inside custom 
> event handler. From the first point of view, this should remove all the 
> disadvantages above.



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

[jira] [Commented] (IGNITE-4157) Use discovery custom messages instead of marshaller cache

[Sergey Chugunov (JIRA)]

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

Sergey Chugunov commented on IGNITE-4157:
-

Implemented server node failure safe case for #4.

> Use discovery custom messages instead of marshaller cache
> -
>
> Key: IGNITE-4157
> URL: https://issues.apache.org/jira/browse/IGNITE-4157
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Reporter: Alexey Goncharuk
>Assignee: Sergey Chugunov
> Fix For: 2.0
>
>
> Currently we use system caches for keeping classname to class ID mapping and 
> for storing binary metadata
> This has several serious disadvantages:
> 1) We need to introduce at least two additional thread pools for each of 
> these caches
> 2) Since cache operations require stable topology, registering a class ID or 
> updating metadata inside a transaction or another cache operation is tricky 
> and deadlock-prone.
> 3) It may be beneficial in some cases to have nodes with no caches at all, 
> currently this is impossible because system caches are always present.
> 4) Reading binary metadata leads to huge local contention, caching metadata 
> values in a local map doubles memory consumption
> I suggest we use discovery custom events for these purposes. Each node will 
> have a corresponding local map (state) which will be updated inside custom 
> event handler. From the first point of view, this should remove all the 
> disadvantages above.



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

[jira] [Updated] (IGNITE-4230) Create documentation for the integration with Tableau

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-4230:

Assignee: Igor Sapego  (was: Denis Magda)

> Create documentation for the integration with Tableau
> -
>
> Key: IGNITE-4230
> URL: https://issues.apache.org/jira/browse/IGNITE-4230
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Igor Sapego
> Fix For: 2.0
>
>
> Let's create a simple documentation that will show how to connect from 
> Tableau to Ignite and what steps have to be performed to fulfill this.
> The documentation has to be placed under this section:
> https://apacheignite-mix.readme.io/docs/overview-1
> Refer to this discussion for more details:
> http://apache-ignite-developers.2346864.n4.nabble.com/Connecting-to-Ignite-from-Tableau-td12065.html



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

[jira] [Closed] (IGNITE-4140) KafkaStreamer should use tuple extractor instead of decoders

[Denis Magda (JIRA)]

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

Denis Magda closed IGNITE-4140.
---

> KafkaStreamer should use tuple extractor instead of decoders
> 
>
> Key: IGNITE-4140
> URL: https://issues.apache.org/jira/browse/IGNITE-4140
> Project: Ignite
>  Issue Type: Improvement
>  Components: streaming
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Anil
>  Labels: patch-available
> Fix For: 1.9
>
>
> Current design of {{KafkaStreamer}} looks incorrect to me. In particular, it 
> extends {{StreamAdapter}}, but ignores tuple extractors provided there and 
> uses native Kafka decoders instead. This for example makes impossible to 
> produce several entries from one message, like it can be done via 
> {{StreamMultipleTupleExtractor}} in other streamers.
> To fix this, we should:
> # Declare the {{KafkaStreamer}} like this:
> {code}
> KafkaStreamer extends StreamAdapter, 
> K, V>
> {code}
> # Remove {{keyDecoder}} and {{valDecoder}} in favor of tuple extractors.
> # Instead of doing {{getStreamer().addData(...)}} directly, call 
> {{addMessage(...)}} method providing the raw message consumed from Kafka 
> ({{MessageAndMetadata}}). This method will make sure that 
> configured extractor is invoked and that all entries are added to 
> {{IgniteDataStreamer}}.



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

[jira] [Commented] (IGNITE-4325) Proposing new marshaller mapping should be done in synchronous way

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-4325:
-

[~sergey-chugunov], were the changes reviewed and merged into some specific 
branch? If so, the please close the ticket.

> Proposing new marshaller mapping should be done in synchronous way
> --
>
> Key: IGNITE-4325
> URL: https://issues.apache.org/jira/browse/IGNITE-4325
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
> Fix For: 2.0
>
>
> h3. Notes
> Previous version of DiscoveryCustomEvent-based MarshallerContext 
> implementation returned immediately with "not registered" flag after 
> submitting request for new mapping.
> This may be ineffective in terms of network traffic and not well suited with 
> current implementation of BinaryCache.
> h3. Acceptance Criteria
> # Registration of new mapping should return when the mapping is accepted by 
> grid.
> # Registration of new mapping should throw an exception when the mapping is 
> in conflict with grid.



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

[jira] [Commented] (IGNITE-4140) KafkaStreamer should use tuple extractor instead of decoders

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-4140:
-

[~roman_s], presently the community has no plans for 1.9 release. So these 
changes will be available in the master and 2.0. 

> KafkaStreamer should use tuple extractor instead of decoders
> 
>
> Key: IGNITE-4140
> URL: https://issues.apache.org/jira/browse/IGNITE-4140
> Project: Ignite
>  Issue Type: Improvement
>  Components: streaming
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Anil
>  Labels: patch-available
> Fix For: 1.9
>
>
> Current design of {{KafkaStreamer}} looks incorrect to me. In particular, it 
> extends {{StreamAdapter}}, but ignores tuple extractors provided there and 
> uses native Kafka decoders instead. This for example makes impossible to 
> produce several entries from one message, like it can be done via 
> {{StreamMultipleTupleExtractor}} in other streamers.
> To fix this, we should:
> # Declare the {{KafkaStreamer}} like this:
> {code}
> KafkaStreamer extends StreamAdapter, 
> K, V>
> {code}
> # Remove {{keyDecoder}} and {{valDecoder}} in favor of tuple extractors.
> # Instead of doing {{getStreamer().addData(...)}} directly, call 
> {{addMessage(...)}} method providing the raw message consumed from Kafka 
> ({{MessageAndMetadata}}). This method will make sure that 
> configured extractor is invoked and that all entries are added to 
> {{IgniteDataStreamer}}.



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

[jira] [Closed] (IGNITE-3447) put/get value by AffinityKey

[Denis Magda (JIRA)]

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

Denis Magda closed IGNITE-3447.
---

Duplicate of https://issues.apache.org/jira/browse/IGNITE-3263

> put/get value by AffinityKey
> 
>
> Key: IGNITE-3447
> URL: https://issues.apache.org/jira/browse/IGNITE-3447
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.6
> Environment: jdk1.8 ,mac OS EI
>Reporter: Ranger Tsao
>Assignee: Saikat Maitra
>
> code is :
> IgniteCache ac = ignite.getOrCreateCache("address");
> AffinityKey ak1 = new AffinityKey<>("mok");
> AffinityKey ak2 = new AffinityKey<>("mok", "mok");
> ac.put(ak1, new Address("west"));
> ac.put(ak2, new Address("east"));
> when ac.put(ak1, new Address("west"));
> throw exception:
> Exception in thread "main" java.lang.NullPointerException
>   at 
> org.apache.ignite.cache.affinity.rendezvous.RendezvousAffinityFunction.partition(RendezvousAffinityFunction.java:428)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.partition(GridCacheAffinityManager.java:206)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primary(GridCacheAffinityManager.java:278)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapSingleUpdate(GridNearAtomicSingleUpdateFuture.java:601)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:517)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:433)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:202)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$22.apply(GridDhtAtomicCache.java:1007)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$22.apply(GridDhtAtomicCache.java:1005)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.asyncOp(GridDhtAtomicCache.java:703)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAsync0(GridDhtAtomicCache.java:1005)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.putAsync0(GridDhtAtomicCache.java:475)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.putAsync(GridCacheAdapter.java:2506)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put(GridDhtAtomicCache.java:452)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2180)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.put(IgniteCacheProxy.java:1165)



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

[jira] [Commented] (IGNITE-4244) Redis INCR/DECR to operate on AtomicLong.

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-4244:
-

[~roman_s], were the changes merged into the master branch? If so, please close 
the ticket then.

> Redis INCR/DECR to operate on AtomicLong.
> -
>
> Key: IGNITE-4244
> URL: https://issues.apache.org/jira/browse/IGNITE-4244
> Project: Ignite
>  Issue Type: Sub-task
>Affects Versions: 1.8
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>  Labels: redis
> Fix For: 1.8
>
>
> Making INCR/DECR behave as expected by Redis.



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

[jira] [Commented] (IGNITE-3850) Need to add support WIN for YARN integration

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-3850:
-

[~Shirely], are you planning to finish this ticket in the nearest time?

> Need to add support WIN for YARN integration
> 
>
> Key: IGNITE-3850
> URL: https://issues.apache.org/jira/browse/IGNITE-3850
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 1.7
> Environment: Windows
>Reporter: Nikolay Tikhonov
>Assignee: Shirely Feng
>
> Current YARN integration does not support WIN OS. Need to implement it.



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

[jira] [Commented] (IGNITE-1943) ignitevisorcmd: wrong behavior for "mclear" command

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-1943:
-

[~samaitra], are you planning to finalize the work for this task?

> ignitevisorcmd: wrong behavior for "mclear" command
> ---
>
> Key: IGNITE-1943
> URL: https://issues.apache.org/jira/browse/IGNITE-1943
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.5.0.final
>Reporter: Vasilisa  Sidorova
>Assignee: Saikat Maitra
> Fix For: 2.0
>
>
> -
> DESCRIPTION
> -
> "mclear" should clears all Visor console variables before they will be 
> updated during next run of the corresponding command. It OK for all type of 
> shortcut (@cX, @tX, @aX, @eX) exept shortcut for node-id variables. After 
> "mclear" @nX are disappear from any statistics 
> -
> STEPS FOR REPRODUCE
> -
> # Start cluster
> # Start visorcmd ([IGNITE_HOME]/bin/ignitevisorcmd.sh)
> # Connect to the started cluster (visor> open)
> # Execute any tasks in it (for example, run any example from EventsExample, 
> DeploymentExample, ComputeContinuousMapperExample, ComputeTaskMapExample, 
> ComputeTaskSplitExample) 
> # Create several alerts (visor> alert)
> # Run visor "mclear" command
> # Run visor "node" command
> -
> ACTUAL RESULT
> -
> There isn't @nX values in the first table's column:
> {noformat}
> visor> node
> Select node from:
> +==+
> | # |   Node ID8(@), IP   | Up Time  | CPUs | CPU Load | Free Heap |
> +==+
> | 0 | 6B3E4033, 127.0.0.1 | 00:38:41 | 8| 0.20 %   | 97.00 %   |
> | 1 | 0A0D6989, 127.0.0.1 | 00:38:22 | 8| 0.17 %   | 97.00 %   |
> | 2 | 0941E33F, 127.0.0.1 | 00:35:46 | 8| 0.23 %   | 97.00 %   |
> +--+
> {noformat}
> -
> EXPECTED RESULT
> -
> There is @nX values in the first table's column:
> {noformat}
> visor> node
> Select node from:
> +===+
> | # | Node ID8(@), IP  | Up Time  | CPUs | CPU Load | Free Heap |
> +===+
> | 0 | 6B3E4033(@n0), 127.0.0.1 | 00:38:13 | 8| 0.23 %   | 97.00 %   |
> | 1 | 0A0D6989(@n1), 127.0.0.1 | 00:37:54 | 8| 0.27 %   | 97.00 %   |
> | 2 | 0941E33F(@n2), 127.0.0.1 | 00:35:18 | 8| 0.20 %   | 97.00 %   |
> +---+
> {noformat}
> "mclear" should get effect only for "mget @nX" command (with result "Missing 
> variable with name: '@nX'") and @nX variables  should get new values after 
> "node" (or "tasks") command execution. Like in case for all others @ 
> variables (@cX, @tX, @aX, @eX) 



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

[jira] [Commented] (IGNITE-4230) Create documentation for the integration with Tableau

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-4230:
-

Igor, when are you planning finish working on it? Please assign the ticket on 
me once you're done.

> Create documentation for the integration with Tableau
> -
>
> Key: IGNITE-4230
> URL: https://issues.apache.org/jira/browse/IGNITE-4230
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Denis Magda
> Fix For: 2.0
>
>
> Let's create a simple documentation that will show how to connect from 
> Tableau to Ignite and what steps have to be performed to fulfill this.
> The documentation has to be placed under this section:
> https://apacheignite-mix.readme.io/docs/overview-1
> Refer to this discussion for more details:
> http://apache-ignite-developers.2346864.n4.nabble.com/Connecting-to-Ignite-from-Tableau-td12065.html



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

[jira] [Commented] (IGNITE-4471) ODBC: Can not retrieve table metadata.

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-4471:
-

Seems like there is an regression in {{odbc::utility::ReadString()}} function. 
Going to add tests for this function.

> ODBC: Can not retrieve table metadata.
> --
>
> Key: IGNITE-4471
> URL: https://issues.apache.org/jira/browse/IGNITE-4471
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 1.8
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>  Labels: odbc
> Fix For: 2.0
>
>
> {{SQLTables}} always returns set of empty strings currently.



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

[jira] [Created] (IGNITE-4471) ODBC: Can not retrieve table metadata.

[Igor Sapego (JIRA)]

Igor Sapego created IGNITE-4471:
---

 Summary: ODBC: Can not retrieve table metadata.
 Key: IGNITE-4471
 URL: https://issues.apache.org/jira/browse/IGNITE-4471
 Project: Ignite
  Issue Type: Bug
  Components: odbc
Affects Versions: 1.8
Reporter: Igor Sapego
Assignee: Igor Sapego
 Fix For: 2.0


{{SQLTables}} always returns set of empty strings currently.



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

[jira] [Commented] (IGNITE-2833) High memory utilization when OFFHEAP_TIERED mode and expiry policy are enabled.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-2833:


Github user AMashenkov closed the pull request at:

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


> High memory utilization when OFFHEAP_TIERED mode and expiry policy are 
> enabled.
> ---
>
> Key: IGNITE-2833
> URL: https://issues.apache.org/jira/browse/IGNITE-2833
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Andrew Mashenkov
>Priority: Critical
>  Labels: community, important
> Fix For: 1.8
>
> Attachments: IgniteExpiryIssue.java, config.xml
>
>
> The problem is originally reported by Neil Wightman: 
> http://apache-ignite-users.70518.x6.nabble.com/Off-Heap-cache-using-lots-of-heap-memory-td3414.html
> *Steps to reproduce*
> 1) Run attached code and XML config. Observe that heap size is about 1Gb.
> 2) Comment expiry policy setter in the code, run again. Now only 150Mb is 
> consumed.



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

[jira] [Commented] (IGNITE-4142) Assertion in ClientImpl.updateMetrics()

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov commented on IGNITE-4142:
--

Obviously, there is a bug.
But I've no idea how it can be reproduced, in particular on single JVM.

> Assertion in ClientImpl.updateMetrics()
> ---
>
> Key: IGNITE-4142
> URL: https://issues.apache.org/jira/browse/IGNITE-4142
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Andrew Mashenkov
>Priority: Critical
> Fix For: 2.0
>
>
> The problem was reported here: 
> http://apache-ignite-users.70518.x6.nabble.com/AssertionError-td8321.html
> It looks like the reason is that 
> {{TcpDiscoveryHeartbeatMessage.setCacheMetrics()}} method does not put empty 
> map in the {{cacheMetrics}} collection. As a result, it's possible that there 
> are cluster metrics for a node, but no cache metrics for this node - this 
> leads to the assertion in {{ClientImpl.updateMetrics}} (see below). We should 
> remove the {{if}} in {{TcpDiscoveryHeartbeatMessage.setCacheMetrics()}} or 
> change {{ClientImpl.updateMetrics}} logic so that it does not fail in this 
> case.
> We should also try to reproduce in a unit test to make sure this the only 
> problematic code here.
> {noformat}
> 10:39:38,355 SEVERE [TcpDiscoverySpi] Runtime error caught during grid 
> runnable execution: IgniteSpiThread 
> [name=tcp-client-disco-msg-worker-#4%FooGrid%]: java.lang.AssertionError 
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.updateMetrics(ClientImpl.java:2046)
>  
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processHeartbeatMessage(ClientImpl.java:1926)
>  
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1580)
>  
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1499)
>  
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62) 
> {noformat}



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

[jira] [Commented] (IGNITE-4230) Create documentation for the integration with Tableau

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-4230:
-

Denis, it's not ready yet, it's just a draft :)

> Create documentation for the integration with Tableau
> -
>
> Key: IGNITE-4230
> URL: https://issues.apache.org/jira/browse/IGNITE-4230
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Denis Magda
> Fix For: 2.0
>
>
> Let's create a simple documentation that will show how to connect from 
> Tableau to Ignite and what steps have to be performed to fulfill this.
> The documentation has to be placed under this section:
> https://apacheignite-mix.readme.io/docs/overview-1
> Refer to this discussion for more details:
> http://apache-ignite-developers.2346864.n4.nabble.com/Connecting-to-Ignite-from-Tableau-td12065.html



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

[jira] [Commented] (IGNITE-4142) Assertion in ClientImpl.updateMetrics()

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4142:


Github user AMashenkov closed the pull request at:

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


> Assertion in ClientImpl.updateMetrics()
> ---
>
> Key: IGNITE-4142
> URL: https://issues.apache.org/jira/browse/IGNITE-4142
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Andrew Mashenkov
>Priority: Critical
> Fix For: 2.0
>
>
> The problem was reported here: 
> http://apache-ignite-users.70518.x6.nabble.com/AssertionError-td8321.html
> It looks like the reason is that 
> {{TcpDiscoveryHeartbeatMessage.setCacheMetrics()}} method does not put empty 
> map in the {{cacheMetrics}} collection. As a result, it's possible that there 
> are cluster metrics for a node, but no cache metrics for this node - this 
> leads to the assertion in {{ClientImpl.updateMetrics}} (see below). We should 
> remove the {{if}} in {{TcpDiscoveryHeartbeatMessage.setCacheMetrics()}} or 
> change {{ClientImpl.updateMetrics}} logic so that it does not fail in this 
> case.
> We should also try to reproduce in a unit test to make sure this the only 
> problematic code here.
> {noformat}
> 10:39:38,355 SEVERE [TcpDiscoverySpi] Runtime error caught during grid 
> runnable execution: IgniteSpiThread 
> [name=tcp-client-disco-msg-worker-#4%FooGrid%]: java.lang.AssertionError 
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.updateMetrics(ClientImpl.java:2046)
>  
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processHeartbeatMessage(ClientImpl.java:1926)
>  
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1580)
>  
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1499)
>  
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62) 
> {noformat}



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

[jira] [Commented] (IGNITE-4142) Assertion in ClientImpl.updateMetrics()

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4142:


GitHub user AMashenkov opened a pull request:

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

IGNITE-4142: Assertion in ClientImpl.updateMetrics()



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

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

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

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


commit 6319c3b9e6a187157435ecf848dc0d82717484cb
Author: Andrey V. Mashenkov 
Date:   2016-12-21T16:53:08Z

Fixed.




> Assertion in ClientImpl.updateMetrics()
> ---
>
> Key: IGNITE-4142
> URL: https://issues.apache.org/jira/browse/IGNITE-4142
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Andrew Mashenkov
>Priority: Critical
> Fix For: 2.0
>
>
> The problem was reported here: 
> http://apache-ignite-users.70518.x6.nabble.com/AssertionError-td8321.html
> It looks like the reason is that 
> {{TcpDiscoveryHeartbeatMessage.setCacheMetrics()}} method does not put empty 
> map in the {{cacheMetrics}} collection. As a result, it's possible that there 
> are cluster metrics for a node, but no cache metrics for this node - this 
> leads to the assertion in {{ClientImpl.updateMetrics}} (see below). We should 
> remove the {{if}} in {{TcpDiscoveryHeartbeatMessage.setCacheMetrics()}} or 
> change {{ClientImpl.updateMetrics}} logic so that it does not fail in this 
> case.
> We should also try to reproduce in a unit test to make sure this the only 
> problematic code here.
> {noformat}
> 10:39:38,355 SEVERE [TcpDiscoverySpi] Runtime error caught during grid 
> runnable execution: IgniteSpiThread 
> [name=tcp-client-disco-msg-worker-#4%FooGrid%]: java.lang.AssertionError 
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.updateMetrics(ClientImpl.java:2046)
>  
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processHeartbeatMessage(ClientImpl.java:1926)
>  
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1580)
>  
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1499)
>  
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62) 
> {noformat}



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

[jira] [Commented] (IGNITE-2793) ODBC: Add support for Arrays.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-2793:


GitHub user skalashnikov opened a pull request:

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

IGNITE-2793 Added support for byte arrays to ODBC



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

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

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

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


commit b0a7e0a01f6dafd33137ebd87e7b41d32074ede4
Author: skalashnikov 
Date:   2016-12-20T17:51:46Z

IGNITE-2793 Added SQL_C_BINARY support

commit 787590ef33a523a05b0ea4e40e511ddc7e9993ba
Author: skalashnikov 
Date:   2016-12-21T11:48:39Z

IGNITE-2793 fixed some tabs, added parameter tests

commit d93b7815c2bcd77a43baaa4281c02aa2fe419010
Author: skalashnikov 
Date:   2016-12-21T16:37:33Z

IGNITE-2793 Done




> ODBC: Add support for Arrays.
> -
>
> Key: IGNITE-2793
> URL: https://issues.apache.org/jira/browse/IGNITE-2793
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Affects Versions: 1.5.0.final
>Reporter: Igor Sapego
>Assignee: Sergey Kalashnikov
>  Labels: roadmap
> Fix For: 2.0
>
>
> Support for arrays should be added. We need to at least support byte arrays 
> to match {{SQL_C_BINARY}} type.



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

[jira] [Commented] (IGNITE-4142) Assertion in ClientImpl.updateMetrics()

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4142:


GitHub user AMashenkov opened a pull request:

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

IGNITE-4142: Assertion in ClientImpl.updateMetrics()



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

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

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

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


commit c188c3c4a96eacb85ea8e08f0634288332432c1c
Author: Alexey Kuznetsov 
Date:   2016-09-28T01:46:23Z

IGNITE-3983 Fixed wrong cache load optimization. Test added.

commit 89c30c8b0be6915d2399be508ddcd9eb439a9aaa
Author: Alexey Kuznetsov 
Date:   2016-09-28T01:57:45Z

IGNITE-3965 @GridInternal tasks should run via standart LoadBalancingSpi. 
Added test.

commit a53c399e10926120106379d1c764edd7d3854e6a
Author: Alexey Kuznetsov 
Date:   2016-09-28T02:07:55Z

Merge ignite-1.6.9 into ignite-1.7.2.

commit ec9ddcd3d99d19403bf19e1172ede2afdab6c86f
Author: sboikov 
Date:   2016-09-28T09:05:28Z

Code style fixes.

commit 17c2fc0b69abd023b2a1e5da344e67951fd49408
Author: sboikov 
Date:   2016-09-28T09:56:17Z

ignite-2833 Need call 'touch' for cache entry if it was obtained using 
'entryEx'.

commit daf974d261efa525678d5fabc6191642c07f9ad4
Author: AKuznetsov 
Date:   2016-09-28T10:22:10Z

IGNITE-3965 Fixed issues found on review.

commit 53fbad7ddafdae7b368b0f207d06d16574978d62
Author: AKuznetsov 
Date:   2016-09-28T10:24:56Z

Merge branch ignite-1.6.9 into ignite-1.7.2.

commit 4ff19c20b169e0373eafc8025a838db8bfc61f27
Author: sboikov 
Date:   2016-09-28T10:47:51Z

ignite-3621 Fixed 'testEvictExpired'.

commit bfe4458448a59542713830f57713b3ac2af08e2b
Author: sboikov 
Date:   2016-09-28T11:31:24Z

ignite-3621 Fixed 'testEvictExpired'.

commit d643dcf2dd2caac4c3ff04cb72f31bbfbf97339a
Author: Pavel Tupitsyn 
Date:   2016-09-28T11:34:23Z

IGNITE-3970 .NET: Fix Cyrillic 'C' letters in code - add test

commit 474ade276c4ae3e8f93cce37473d37270b4e7ad9
Author: vozerov-gridgain 
Date:   2016-09-28T11:38:04Z

IGNITE-3988: Moved failing cloud tests to ignore module.

commit ccfaaf8d060ef984678d2376b16b5a17e7c17e9d
Author: vozerov-gridgain 
Date:   2016-09-28T11:38:17Z

Merge remote-tracking branch 'upstream/ignite-1.6.9' into ignite-1.6.9

commit c7fa918c10d771efa91cde1017662c26d0a61085
Author: Pavel Tupitsyn 
Date:   2016-09-28T11:47:17Z

Merge remote-tracking branch 'remotes/community/ignite-1.6.9' into 
ignite-1.7.3

commit b9105df77cc70b532f94899c754fba47e3e05e9a
Author: vozerov-gridgain 
Date:   2016-09-28T11:53:20Z

IGNITE-3989: Moved failing JTA tests to ignore module.

commit d595345765db2151ff432beecd478ce056393593
Author: vozerov-gridgain 
Date:   2016-09-28T12:08:38Z

IGNITE-3990: Moved failing Spring tests to "ignore" module.

commit e3f13455d4273e615727d0410783e3719db98f76
Author: sboikov 
Date:   2016-09-28T09:56:17Z

ignite-2833 Need call 'touch' for cache entry if it was obtained using 
'entryEx'.

(cherry picked from commit 17c2fc0)

commit b2faa339acb2eea24e6dd5e0c21fc3d3d0592ff6
Author: sboikov 
Date:   2016-09-28T10:47:51Z

ignite-3621 Fixed 'testEvictExpired'.

(cherry picked from commit 4ff19c2)

commit 74d2fc2416b8e6bc0598152552021f984a013061
Author: sboikov 
Date:   2016-09-28T11:31:24Z

ignite-3621 Fixed 'testEvictExpired'.

(cherry picked from commit bfe4458)

commit d2563dacceea61b19bb6e083e29ebacc28fdd323
Author: vozerov-gridgain 
Date:   2016-09-28T12:51:55Z

IGNITE-3993: Added failing client tests to "ignored" test suite.

commit 33d34941390c00e8d6a2488e8f2e11e6abba8a01
Author: sboikov 
Date:   2016-09-28T12:54:52Z

Merge remote-tracking branch 'community/ignite-1.6.9' into ignite-1.6.9

commit 78144c4c9d6200ceef8b666a186039685f053381
Author: vozerov-gridgain 
Date:   2016-09-28T13:52:13Z

Fixed incorrect test count calculation leading to afterTestsStopped() not 
being called.

commit e3dfdecc3607b5f3183bfcb1ce36c57543a8965f
Author: Alexander Paschenko 
Date:   2016-09-28T13:46:46Z

[jira] [Updated] (IGNITE-2793) ODBC: Add support for Arrays.

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov updated IGNITE-2793:
---
Fix Version/s: 2.0

> ODBC: Add support for Arrays.
> -
>
> Key: IGNITE-2793
> URL: https://issues.apache.org/jira/browse/IGNITE-2793
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Affects Versions: 1.5.0.final
>Reporter: Igor Sapego
>Assignee: Sergey Kalashnikov
>  Labels: roadmap
> Fix For: 2.0
>
>
> Support for arrays should be added. We need to at least support byte arrays 
> to match {{SQL_C_BINARY}} type.



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

[jira] [Commented] (IGNITE-4457) Define cache plugin API in .NET

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-4457:


{{CachePluginManager.stop0}} uses reverse iterator incorrectly and does not 
actually stop cache plugins. Fixed.

> Define cache plugin API in .NET
> ---
>
> Key: IGNITE-4457
> URL: https://issues.apache.org/jira/browse/IGNITE-4457
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> Define cache plugin API in .NET similar to Java API:
> * {{CacheConfiguration.PluginConfigurations}}
> * {{ICachePluginProvider}}
> * {{ICachePluginContext}}
> Fundamental difference to Ignite plugins (IGNITE-4441), which are local, is 
> that {{CachePluginConfiguration}} is sent to remote nodes and providers are 
> created there. So we'll need {{PlatformCachePluginConfiguration}} and 
> {{PlatformCachePluginProvider}} on Java side.



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

[jira] [Commented] (IGNITE-4109) BinaryType.isEnum() throws an exception if typeId==0

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko commented on IGNITE-4109:
-

Dmitry, we write zero type ID and full class name in case we want to register a 
new class, but there is a ongoing exchange at the time. This is done to avoid 
deadlocks and must happen very rarely indeed. It's OK if it's reproduced only 
in a synthetic test.

> BinaryType.isEnum() throws an exception if typeId==0
> 
>
> Key: IGNITE-4109
> URL: https://issues.apache.org/jira/browse/IGNITE-4109
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Dmitry Karachentsev
> Fix For: 2.0
>
>
> If {{typeId==0}} and full class name is written in the binary format, 
> {{BinaryType.isEnum()}} method fails with the exception:
> {noformat}
> Caused by: org.apache.ignite.binary.BinaryObjectException: Failed to get 
> binary type details [typeId=0]
>   at 
> org.apache.ignite.internal.binary.BinaryTypeProxy.target(BinaryTypeProxy.java:99)
>  ~[ignite-core-1.6.7.jar:1.6.7]
>   at 
> org.apache.ignite.internal.binary.BinaryTypeProxy.isEnum(BinaryTypeProxy.java:86)
>  ~[ignite-core-1.6.7.jar:1.6.7]
> {noformat}
> This happens because {{BinaryTypeProxy.target()}} method ignores this case. 
> If {{typeId==0}}, It should look up full class name from the object and 
> convert it to the actual type ID before trying to fetch metadata.



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

[jira] [Commented] (IGNITE-4212) Ignite Benchmarking Simplification and Automation

[Oleg Ostanin (JIRA)]

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

Oleg Ostanin commented on IGNITE-4212:
--

[~dmagda]
Thank you for your help. I'll place the compiled ignite-yardstick module and 
all the scripts in the new benchmarks folder.

> Ignite Benchmarking Simplification and Automation
> -
>
> Key: IGNITE-4212
> URL: https://issues.apache.org/jira/browse/IGNITE-4212
> Project: Ignite
>  Issue Type: Task
>Reporter: Denis Magda
>Assignee: Oleg Ostanin
> Fix For: 2.0
>
>
> There is a plenty of useful Yardstick benchmarks located in ignite-yardstick 
> module that is used by the community to check Ignite performance across 
> deployments of different configurations.
> However, it's not easy to start with the benchmarking process because the 
> user needs to download Ignite, build and set up benchmarks and only after 
> that run them.
> The goal of this task is to simplify the process in the following way:
> 1) ignite-yardstick benchmarks have to be pre-compiled and available with 
> every Ignite deliverable.
> 2) every deliverable must contain an executable (bat or sh file) with a clear 
> instruction on how to start a specific benchmark from the console.
> 3) the executable has to use some default yardstick configuration. The first 
> configuration should be intented for local execution (multicast IP finder) 
> and the second needs to be AWS oriented.



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

[jira] [Commented] (IGNITE-4247) Table aliases not supported for SqlQuery

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov commented on IGNITE-4247:
--

TC test looks good.
Can be merged after review

> Table aliases not supported for SqlQuery
> 
>
> Key: IGNITE-4247
> URL: https://issues.apache.org/jira/browse/IGNITE-4247
> Project: Ignite
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Andrew Mashenkov
> Fix For: 2.0
>
>
> Here is the example of the query:
> {code}
> from Person p where p.salary > ? and p.salary <= ?
> {code}
> Ignite is not aware of the alias and incorrectly appends the SELECT 
> statement, which causes this exception:
> {noformat}
> Exception in thread "main" javax.cache.CacheException: Failed to parse query: 
> SELECT "CacheQueryExamplePersons".Person._key, 
> "CacheQueryExamplePersons".Person._val from Person p where salary > ? and 
> salary <= ?
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryTwoStep(IgniteH2Indexing.java:1217)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryTwoStep(IgniteH2Indexing.java:1123)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:813)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:811)
>   at 
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:1760)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.queryTwoStep(GridQueryProcessor.java:811)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:733)
>   at 
> org.apache.ignite.examples.datagrid.CacheQueryExample.sqlQuery(CacheQueryExample.java:176)
>   at 
> org.apache.ignite.examples.datagrid.CacheQueryExample.main(CacheQueryExample.java:116)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
> Caused by: org.h2.jdbc.JdbcSQLException: Column 
> "CacheQueryExamplePersons.PERSON._KEY" not found; SQL statement:
> SELECT "CacheQueryExamplePersons".Person._key, 
> "CacheQueryExamplePersons".Person._val from Person p where salary > ? and 
> salary <= ? [42122-191]
>   at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
>   at org.h2.message.DbException.get(DbException.java:179)
>   at org.h2.message.DbException.get(DbException.java:155)
>   at 
> org.h2.expression.ExpressionColumn.optimize(ExpressionColumn.java:147)
>   at org.h2.command.dml.Select.prepare(Select.java:852)
>   at org.h2.command.Parser.prepareCommand(Parser.java:257)
>   at org.h2.engine.Session.prepareLocal(Session.java:560)
>   at org.h2.engine.Session.prepareCommand(Session.java:501)
>   at org.h2.jdbc.JdbcConnection.prepareCommand(JdbcConnection.java:1188)
>   at 
> org.h2.jdbc.JdbcPreparedStatement.(JdbcPreparedStatement.java:73)
>   at org.h2.jdbc.JdbcConnection.prepareStatement(JdbcConnection.java:276)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.prepareStatement(IgniteH2Indexing.java:410)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryTwoStep(IgniteH2Indexing.java:1201)
>   ... 14 more
> {noformat}



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

[jira] [Updated] (IGNITE-4248) Slf4jLogger ignores IGNITE_QUIET system property

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-4248:
-
Description: 
{{Slf4jLogger}} writes in quiet mode into {{System.out}} regardless of the 
value of {{IGNITE_QUEIT}} system property.

Also {{JclLogger}} and {{HadoopIgfsJclLogger}} ignore this property and should 
be fixed.

  was:{{Slf4jLogger}} writes in quiet mode into {{System.out}} regardless of 
the value of {{IGNITE_QUEIT}} system property.


> Slf4jLogger ignores IGNITE_QUIET system property
> 
>
> Key: IGNITE-4248
> URL: https://issues.apache.org/jira/browse/IGNITE-4248
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Andrew Mashenkov
> Fix For: 2.0
>
>
> {{Slf4jLogger}} writes in quiet mode into {{System.out}} regardless of the 
> value of {{IGNITE_QUEIT}} system property.
> Also {{JclLogger}} and {{HadoopIgfsJclLogger}} ignore this property and 
> should be fixed.



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

[jira] [Assigned] (IGNITE-4142) Assertion in ClientImpl.updateMetrics()

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov reassigned IGNITE-4142:


Assignee: Andrew Mashenkov

> Assertion in ClientImpl.updateMetrics()
> ---
>
> Key: IGNITE-4142
> URL: https://issues.apache.org/jira/browse/IGNITE-4142
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Andrew Mashenkov
>Priority: Critical
> Fix For: 2.0
>
>
> The problem was reported here: 
> http://apache-ignite-users.70518.x6.nabble.com/AssertionError-td8321.html
> It looks like the reason is that 
> {{TcpDiscoveryHeartbeatMessage.setCacheMetrics()}} method does not put empty 
> map in the {{cacheMetrics}} collection. As a result, it's possible that there 
> are cluster metrics for a node, but no cache metrics for this node - this 
> leads to the assertion in {{ClientImpl.updateMetrics}} (see below). We should 
> remove the {{if}} in {{TcpDiscoveryHeartbeatMessage.setCacheMetrics()}} or 
> change {{ClientImpl.updateMetrics}} logic so that it does not fail in this 
> case.
> We should also try to reproduce in a unit test to make sure this the only 
> problematic code here.
> {noformat}
> 10:39:38,355 SEVERE [TcpDiscoverySpi] Runtime error caught during grid 
> runnable execution: IgniteSpiThread 
> [name=tcp-client-disco-msg-worker-#4%FooGrid%]: java.lang.AssertionError 
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.updateMetrics(ClientImpl.java:2046)
>  
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processHeartbeatMessage(ClientImpl.java:1926)
>  
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1580)
>  
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1499)
>  
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62) 
> {noformat}



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

[jira] [Resolved] (IGNITE-3886) .NET: Build script

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn resolved IGNITE-3886.

Resolution: Implemented
  Assignee: (was: Pavel Tupitsyn)

> .NET: Build script
> --
>
> Key: IGNITE-3886
> URL: https://issues.apache.org/jira/browse/IGNITE-3886
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> Create a build script with powershell or cake http://cakebuild.net/.
> Currently, we have our build completely automated on TeamCity. However, it 
> should be possible to build everything (jars, dlls, NuGet) locally with a 
> single command.
> As a result, we should have:
> * bin folder with all .NET-related files (DLL, XML, XSD, etc) and Libs folder 
> with jar files
> * nupkg folder with all NuGet packages
> Investigate how to integrate this with Maven: IGNITE-2292



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

[jira] [Comment Edited] (IGNITE-3886) .NET: Build script

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn edited comment on IGNITE-3886 at 12/21/16 1:05 PM:
--

Merged to master, changed Coverage nightly suite to use the script.


was (Author: ptupitsyn):
Merged to master.

> .NET: Build script
> --
>
> Key: IGNITE-3886
> URL: https://issues.apache.org/jira/browse/IGNITE-3886
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> Create a build script with powershell or cake http://cakebuild.net/.
> Currently, we have our build completely automated on TeamCity. However, it 
> should be possible to build everything (jars, dlls, NuGet) locally with a 
> single command.
> As a result, we should have:
> * bin folder with all .NET-related files (DLL, XML, XSD, etc) and Libs folder 
> with jar files
> * nupkg folder with all NuGet packages
> Investigate how to integrate this with Maven: IGNITE-2292



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

[jira] [Commented] (IGNITE-3886) .NET: Build script

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-3886:


Merged to master.

> .NET: Build script
> --
>
> Key: IGNITE-3886
> URL: https://issues.apache.org/jira/browse/IGNITE-3886
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> Create a build script with powershell or cake http://cakebuild.net/.
> Currently, we have our build completely automated on TeamCity. However, it 
> should be possible to build everything (jars, dlls, NuGet) locally with a 
> single command.
> As a result, we should have:
> * bin folder with all .NET-related files (DLL, XML, XSD, etc) and Libs folder 
> with jar files
> * nupkg folder with all NuGet packages
> Investigate how to integrate this with Maven: IGNITE-2292



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

[jira] [Commented] (IGNITE-3886) .NET: Build script

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-3886:


Github user asfgit closed the pull request at:

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


> .NET: Build script
> --
>
> Key: IGNITE-3886
> URL: https://issues.apache.org/jira/browse/IGNITE-3886
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> Create a build script with powershell or cake http://cakebuild.net/.
> Currently, we have our build completely automated on TeamCity. However, it 
> should be possible to build everything (jars, dlls, NuGet) locally with a 
> single command.
> As a result, we should have:
> * bin folder with all .NET-related files (DLL, XML, XSD, etc) and Libs folder 
> with jar files
> * nupkg folder with all NuGet packages
> Investigate how to integrate this with Maven: IGNITE-2292



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

[jira] [Commented] (IGNITE-3625) IGFS: Use common naming for IGFS meta and data caches.

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-3625:
--

In this case we cannot guarantee that IGFS uses the cache with standard name.
Also we should support both configuration: by cache name and by cache 
configuration.

Should the {{getDataCacheName}} and {{getMetaCacheName}} methods be marked as 
deprecated in this case?

Support of the {{getCacheName}} / {{setCacheName}} makes the solution is more 
complicated. In all places of code where we use cache names we must be check 
IGFS configuration: what is used cache name used or cache config.

What about mixed mixed configurations: e.g. data cache is configured by name 
and meta by cache config?

> IGFS: Use common naming for IGFS meta and data caches.
> --
>
> Key: IGNITE-3625
> URL: https://issues.apache.org/jira/browse/IGNITE-3625
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> Currently IGFS is configured by passing names of two caches: meta and data. 
> See {{FileSystemConfiguration.metaCacheName}} and 
> {{FileSystemConfiguration.dataCacheName}}.
> These two caches are considered internal then and are not accessible for the 
> user.
> We need to do the following during node startup:
> 1) If certain cache is configured as meta or data cache for multiple IGFS-es, 
> or if it is configured as both meta and data cache for a single IGFS, then 
> throw an exception.
> Relevant code pieces:
> {{IgfsProcessor.validateLocalIgfsConfigurations}}
> {{IgfsProcessorSelfTest}}.
> 2) During node startup change the name of this cache to 
> {{igfs-IGFS_NAME-meta}} or {{igfs-IGFS_NAME-data}}. Change must be performed 
> both inside IGFS config and cache config.
> Relevant code pieces:
> {{CacheConfiguration.name}}
> {{FileSystemConfiguration.metaCacheName}}
> {{FileSystemConfiguration.dataCacheName}}
> {{IgfsUtils.prepareCacheConfiguration}} - where change will be done.
> 3) If any of new names caches with any other cache name, an exception should 
> be thrown. The most simple way: throw an exception if user-configured cache 
> name starts with {{igfs-}} and ends with {{-meta}} or {{-data}}.
> Relevant code pieces:
> {{IgniteNamedInstance.initializeDefaultCacheConfiguration}}.



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

[jira] [Assigned] (IGNITE-3886) .NET: Build script

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-3886:
---

Assignee: Pavel Tupitsyn  (was: Vladimir Ozerov)

OK, looks good to me then.

> .NET: Build script
> --
>
> Key: IGNITE-3886
> URL: https://issues.apache.org/jira/browse/IGNITE-3886
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> Create a build script with powershell or cake http://cakebuild.net/.
> Currently, we have our build completely automated on TeamCity. However, it 
> should be possible to build everything (jars, dlls, NuGet) locally with a 
> single command.
> As a result, we should have:
> * bin folder with all .NET-related files (DLL, XML, XSD, etc) and Libs folder 
> with jar files
> * nupkg folder with all NuGet packages
> Investigate how to integrate this with Maven: IGNITE-2292



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

[jira] [Updated] (IGNITE-4470) ODBC: Add support for logger configuration

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov updated IGNITE-4470:
---
Description: 
Users of ODBC driver should be able to configure logging without driver 
recompilation.
Logger should be setup via connection string parameter.

  was:
Users of ODBC driver should be able to configure logging without driver 
recompilation.
Logger should be setup with via connection string parameter.


> ODBC: Add support for logger configuration
> --
>
> Key: IGNITE-4470
> URL: https://issues.apache.org/jira/browse/IGNITE-4470
> Project: Ignite
>  Issue Type: Improvement
>  Components: odbc
>Affects Versions: 1.8
>Reporter: Sergey Kalashnikov
>Assignee: Sergey Kalashnikov
> Fix For: 2.0
>
>
> Users of ODBC driver should be able to configure logging without driver 
> recompilation.
> Logger should be setup via connection string parameter.



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

[jira] [Created] (IGNITE-4470) ODBC: Add support for logger configuration

[Sergey Kalashnikov (JIRA)]

Sergey Kalashnikov created IGNITE-4470:
--

 Summary: ODBC: Add support for logger configuration
 Key: IGNITE-4470
 URL: https://issues.apache.org/jira/browse/IGNITE-4470
 Project: Ignite
  Issue Type: Improvement
  Components: odbc
Affects Versions: 1.8
Reporter: Sergey Kalashnikov
Assignee: Sergey Kalashnikov
 Fix For: 2.0


Users of ODBC driver should be able to configure logging without driver 
recompilation.
Logger should be setup with via connection string parameter.



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

[jira] [Commented] (IGNITE-3625) IGFS: Use common naming for IGFS meta and data caches.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-3625:
-

I still do not quite understand why do we need some magic in getters and 
setter. Can we do the following?
1) If cache name is set explicitly, then use it.
2) If not, then pick relevant cache configuration, convert cache name, and add 
this cache to startup list.

> IGFS: Use common naming for IGFS meta and data caches.
> --
>
> Key: IGNITE-3625
> URL: https://issues.apache.org/jira/browse/IGNITE-3625
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> Currently IGFS is configured by passing names of two caches: meta and data. 
> See {{FileSystemConfiguration.metaCacheName}} and 
> {{FileSystemConfiguration.dataCacheName}}.
> These two caches are considered internal then and are not accessible for the 
> user.
> We need to do the following during node startup:
> 1) If certain cache is configured as meta or data cache for multiple IGFS-es, 
> or if it is configured as both meta and data cache for a single IGFS, then 
> throw an exception.
> Relevant code pieces:
> {{IgfsProcessor.validateLocalIgfsConfigurations}}
> {{IgfsProcessorSelfTest}}.
> 2) During node startup change the name of this cache to 
> {{igfs-IGFS_NAME-meta}} or {{igfs-IGFS_NAME-data}}. Change must be performed 
> both inside IGFS config and cache config.
> Relevant code pieces:
> {{CacheConfiguration.name}}
> {{FileSystemConfiguration.metaCacheName}}
> {{FileSystemConfiguration.dataCacheName}}
> {{IgfsUtils.prepareCacheConfiguration}} - where change will be done.
> 3) If any of new names caches with any other cache name, an exception should 
> be thrown. The most simple way: throw an exception if user-configured cache 
> name starts with {{igfs-}} and ends with {{-meta}} or {{-data}}.
> Relevant code pieces:
> {{IgniteNamedInstance.initializeDefaultCacheConfiguration}}.



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

[jira] [Commented] (IGNITE-2793) ODBC: Add support for Arrays.

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov commented on IGNITE-2793:


There is a deserialization error on server side when trying to use query 
parameter with SQL_C_BINARY type.
The exception happens with both insert and select types of query.

{code}
[11:45:12,154][SEVERE][odbc-#35%null%][OdbcRequestHandler] Failed to execute 
SQL query [reqId=2, req=OdbcQueryExecuteRequest [cacheName=cache, sqlQry=INSERT 
INTO TestType(_key, i8ArrayField) VALUES(?, ?), args=[1, [B@166e447a]]]
javax.cache.CacheException: class org.apache.ignite.IgniteException: Failed to 
execute SQL query.
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:761)
at 
org.apache.ignite.internal.processors.odbc.OdbcRequestHandler.executeQuery(OdbcRequestHandler.java:207)
at 
org.apache.ignite.internal.processors.odbc.OdbcRequestHandler.handle(OdbcRequestHandler.java:108)
at 
org.apache.ignite.internal.processors.odbc.OdbcNioListener.onMessage(OdbcNioListener.java:124)
at 
org.apache.ignite.internal.processors.odbc.OdbcNioListener.onMessage(OdbcNioListener.java:33)
at 
org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:274)
at 
org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:107)
at 
org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:95)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at 
org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70)
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: class org.apache.ignite.IgniteException: Failed to execute SQL query.
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.queryTwoStep(GridQueryProcessor.java:817)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:749)
... 12 more
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to execute 
SQL query.
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:1800)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.queryTwoStep(GridQueryProcessor.java:810)
... 13 more
Caused by: class org.apache.ignite.IgniteException: Failed to execute SQL query.
at 
org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor$1.iterator(DmlStatementsProcessor.java:271)
at 
org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:98)
at 
org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.doInsert(DmlStatementsProcessor.java:745)
at 
org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.executeUpdateStatement(DmlStatementsProcessor.java:286)
at 
org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:159)
at 
org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsTwoStep(DmlStatementsProcessor.java:189)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryTwoStep(IgniteH2Indexing.java:1266)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:812)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:810)
at 
org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:1777)
... 14 more
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to execute 
SQL query.
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:958)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer(IgniteH2Indexing.java:1010)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.access$1000(IgniteH2Indexing.java:200)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$3.iterator(IgniteH2Indexing.java:831)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$3.iterator(IgniteH2Indexing.java:829)
at 
org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor$1.iterator(DmlStatementsProcessor.java:268)
... 24 

[jira] [Commented] (IGNITE-3964) SQL: implement support for custom table name

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov commented on IGNITE-3964:
--

TC test looks good.
Can be merged after review.

> SQL: implement support for custom table name
> 
>
> Key: IGNITE-3964
> URL: https://issues.apache.org/jira/browse/IGNITE-3964
> Project: Ignite
>  Issue Type: Task
>  Components: SQL
>Affects Versions: 1.6
>Reporter: Alexey Kuznetsov
>Assignee: Andrew Mashenkov
> Fix For: 2.0
>
>
> We have ability to specify aliases for columns via 
> org.apache.ignite.cache.QueryEntity#getAliases.
> But how about alias for table name? This could be useful in case of moving 
> legacy application to Ignite with a lot of SQL statements.



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

[jira] [Commented] (IGNITE-4465) Read-through is not properly working with multiple gets executed in parallel

[Semen Boikov (JIRA)]

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

Semen Boikov commented on IGNITE-4465:
--

I think now this is possible since empty entry can be concurrently removed 
between 'innerGet' and store loading, so 'get' will return loaded value but it 
will not be stored in entry:
- t1 calls entry.innerGetVersioned in GridCacheAdapter.getAllAsync0, it returns 
null, then T1 saves entry key/version in 'misses' map (note - one more race 
here, entry.version() already could change after innerGetVersioned call) 
- some other t2 calls ctx.evicts().touch(entry) for the same entry (e.g. from 
GridPartitionedSingleGetFuture.localGet), entry is empty, it is obsoleted and 
removed
- t1 loaded value from store and calls entry.versionedValue, original entry was 
obsoleted, so version check does not pass and value is not stored in entry


> Read-through is not properly working with multiple gets executed in parallel
> 
>
> Key: IGNITE-4465
> URL: https://issues.apache.org/jira/browse/IGNITE-4465
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.8
>Reporter: Valentin Kulichenko
>Assignee: Semen Boikov
>Priority: Critical
> Fix For: 1.9
>
> Attachments: ReadThroughTest.java
>
>
> The issue is sporadic and very hard to isolate, however I managed to create a 
> test that reproduces it. Basically, the scenario is the following:
> * We have one server and one client.
> * The client creates a cache with read through enabled.
> * The client then executes bunch of jobs (number of jobs is bigger than 
> number of threads in server's public pool) asynchronously in parallel.
> * {{CacheStore.load()}} method is called more than once and invocations go 
> one after another (sometimes even in the same thread!) with an interval of a 
> bit more than one second, which is the duration of load (there is a 
> {{Thread.sleep(1000)}} in the implementation.
> * In addition, statistics show that number of misses go up to 50 which is 
> number of jobs. I would not expect more than 16 there. First 16 jobs executed 
> in parallel can all register miss at the same time before load happens. But 
> all consecutive execution must read the value from cache.
> Test is attached.



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

[jira] [Commented] (IGNITE-4109) BinaryType.isEnum() throws an exception if typeId==0

[Dmitry Karachentsev (JIRA)]

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

Dmitry Karachentsev commented on IGNITE-4109:
-

Valentin,

Do you know any possible scenario for such situation? I can reproduce it with 
synthetic test only.

> BinaryType.isEnum() throws an exception if typeId==0
> 
>
> Key: IGNITE-4109
> URL: https://issues.apache.org/jira/browse/IGNITE-4109
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Dmitry Karachentsev
> Fix For: 2.0
>
>
> If {{typeId==0}} and full class name is written in the binary format, 
> {{BinaryType.isEnum()}} method fails with the exception:
> {noformat}
> Caused by: org.apache.ignite.binary.BinaryObjectException: Failed to get 
> binary type details [typeId=0]
>   at 
> org.apache.ignite.internal.binary.BinaryTypeProxy.target(BinaryTypeProxy.java:99)
>  ~[ignite-core-1.6.7.jar:1.6.7]
>   at 
> org.apache.ignite.internal.binary.BinaryTypeProxy.isEnum(BinaryTypeProxy.java:86)
>  ~[ignite-core-1.6.7.jar:1.6.7]
> {noformat}
> This happens because {{BinaryTypeProxy.target()}} method ignores this case. 
> If {{typeId==0}}, It should look up full class name from the object and 
> convert it to the actual type ID before trying to fetch metadata.



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

[jira] [Resolved] (IGNITE-4469) Hadoop: better defaults to memory page size and message size.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov resolved IGNITE-4469.
-
Resolution: Fixed

> Hadoop: better defaults to memory page size and message size.
> -
>
> Key: IGNITE-4469
> URL: https://issues.apache.org/jira/browse/IGNITE-4469
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Minor
> Fix For: 2.0
>
>
> Currently we have too low shuffle message size and too low initial memory 
> buffer size - 128Kb and 32Kb respectively. 
> As we target big data use case, it makes sense to make these properties 
> bigger. According to several experiments, good size is 1Mb each.



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

[jira] [Created] (IGNITE-4469) Hadoop: better defaults to memory page size and message size.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-4469:
---

 Summary: Hadoop: better defaults to memory page size and message 
size.
 Key: IGNITE-4469
 URL: https://issues.apache.org/jira/browse/IGNITE-4469
 Project: Ignite
  Issue Type: Task
  Components: hadoop
Affects Versions: 1.8
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
Priority: Minor
 Fix For: 2.0


Currently we have too low shuffle message size and too low initial memory 
buffer size - 128Kb and 32Kb respectively. 

As we target big data use case, it makes sense to make these properties bigger. 
According to several experiments, good size is 1Mb each.



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

[jira] [Resolved] (IGNITE-4296) Optimize GridDhtPartitionsSingleMessage processing

[Semen Boikov (JIRA)]

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

Semen Boikov resolved IGNITE-4296.
--
Resolution: Fixed

Changed update of GridDhtPartitionTopologyImpl to do not create unnecessary 
copies, moved processing of GridDhtPartitionsSingleMessage outside of exchange 
future mutex.

> Optimize GridDhtPartitionsSingleMessage processing
> --
>
> Key: IGNITE-4296
> URL: https://issues.apache.org/jira/browse/IGNITE-4296
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Semen Boikov
>Assignee: Semen Boikov
> Fix For: 2.0
>
>
> These optimizations are possible:
> - now on exchange GridDhtPartitionsSingleMessage is processed inside exchange 
> future exclusive lock
> - GridDhtPartitionTopology.update always creates copies of node2part, 
> part2node maps
> - it is possible for joning node do not send GridDhtPartitionsSingleMessage 
> since we know in advance it does not have any data
> - method GridDhtPartitionTopology.update returns map copy which is not 
> actually used



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

[jira] [Commented] (IGNITE-4396) Web console: Failed to edit File system checkpoint spi paths.

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-4396:


Tested.Closed.

> Web console: Failed to edit File system checkpoint spi paths.
> -
>
> Key: IGNITE-4396
> URL: https://issues.apache.org/jira/browse/IGNITE-4396
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 1.9
>Reporter: Vasiliy Sisko
>Assignee: Pavel Konstantinov
> Fix For: 2.0
>
>
> # Add FIle system checkpoint spi configuration.
> # Add some paths.
> # Try to remove or edit path.
> angular.js:13920 TypeError: Cannot create property 'FS' on string 'b'
> at fn (eval at compile (angular.js:14817), :4:813)
> at expensiveCheckFn (angular.js:15906)
> at callback (angular.js:25885)
> at Scope.$eval (angular.js:17682)
> at Scope.$apply (angular.js:17782)
> at HTMLElement. (angular.js:25890)
> at HTMLElement.dispatch (jquery.js:5201)
> at HTMLElement.elemData.handle (jquery.js:5009)



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

[jira] [Closed] (IGNITE-4396) Web console: Failed to edit File system checkpoint spi paths.

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov closed IGNITE-4396.
--
Assignee: Alexey Kuznetsov  (was: Pavel Konstantinov)

> Web console: Failed to edit File system checkpoint spi paths.
> -
>
> Key: IGNITE-4396
> URL: https://issues.apache.org/jira/browse/IGNITE-4396
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 1.9
>Reporter: Vasiliy Sisko
>Assignee: Alexey Kuznetsov
> Fix For: 2.0
>
>
> # Add FIle system checkpoint spi configuration.
> # Add some paths.
> # Try to remove or edit path.
> angular.js:13920 TypeError: Cannot create property 'FS' on string 'b'
> at fn (eval at compile (angular.js:14817), :4:813)
> at expensiveCheckFn (angular.js:15906)
> at callback (angular.js:25885)
> at Scope.$eval (angular.js:17682)
> at Scope.$apply (angular.js:17782)
> at HTMLElement. (angular.js:25890)
> at HTMLElement.dispatch (jquery.js:5201)
> at HTMLElement.elemData.handle (jquery.js:5009)



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

[jira] [Created] (IGNITE-4468) RoundRobinLoadBalancingSpi‘s documentation and Javadoc description incorrectly

[Yujue Li (JIRA)]

Yujue Li created IGNITE-4468:


 Summary: RoundRobinLoadBalancingSpi‘s documentation and Javadoc 
description incorrectly
 Key: IGNITE-4468
 URL: https://issues.apache.org/jira/browse/IGNITE-4468
 Project: Ignite
  Issue Type: Improvement
  Components: documentation
Affects Versions: 1.8
Reporter: Yujue Li
Priority: Minor
 Fix For: 1.9


Class RoundRobinLoadBalancingSpi
Description of the perTask attribute in this class is confusing.
Some places describe the default value of true, some places describe the 
default value of false, and from the source code analysis, the default value 
should be false.
I hope the community can unify the adjustment of Javadoc and related documents.



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

[jira] [Closed] (IGNITE-4317) Redesign Queries Screen

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov closed IGNITE-4317.
--
Assignee: Alexey Kuznetsov  (was: Pavel Konstantinov)

> Redesign Queries Screen
> ---
>
> Key: IGNITE-4317
> URL: https://issues.apache.org/jira/browse/IGNITE-4317
> Project: Ignite
>  Issue Type: Task
>Reporter: Dmitriy Shabalin
>Assignee: Alexey Kuznetsov
> Attachments: chart settings.png, scan.png
>
>
> Simplify queries screen to implement divide execute action to SCAN and QUERY 
> actions.



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

[jira] [Comment Edited] (IGNITE-4317) Redesign Queries Screen

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov edited comment on IGNITE-4317 at 12/21/16 8:51 AM:
--

Tested with demo mode:
# the option 'allow non-collocated joins' is unavailable (unclickable) in demo 
mode
# Allow non-collocated joins' doesn't work at all
Query
"select count(*) from Person p
inner join Department d on d.id=p.depid
inner join Organization o on o.id = d.orgid"

returns the same result for both modes.


was (Author: pkonstantinov):
Tested with demo mode:
# the option 'allow non-collocated joins' is unavailable (unclickable) in demo 
mode
# Allow non-collocated loins' doesn't work at all
Query
"select count(*) from Person p
inner join Department d on d.id=p.depid
inner join Organization o on o.id = d.orgid"

returns the same result for both modes.

> Redesign Queries Screen
> ---
>
> Key: IGNITE-4317
> URL: https://issues.apache.org/jira/browse/IGNITE-4317
> Project: Ignite
>  Issue Type: Task
>Reporter: Dmitriy Shabalin
>Assignee: Alexey Kuznetsov
> Attachments: chart settings.png, scan.png
>
>
> Simplify queries screen to implement divide execute action to SCAN and QUERY 
> actions.



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

[jira] [Commented] (IGNITE-4317) Redesign Queries Screen

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-4317:


Successfully tested.

> Redesign Queries Screen
> ---
>
> Key: IGNITE-4317
> URL: https://issues.apache.org/jira/browse/IGNITE-4317
> Project: Ignite
>  Issue Type: Task
>Reporter: Dmitriy Shabalin
>Assignee: Pavel Konstantinov
> Attachments: chart settings.png, scan.png
>
>
> Simplify queries screen to implement divide execute action to SCAN and QUERY 
> actions.



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

[jira] [Issue Comment Deleted] (IGNITE-4317) Redesign Queries Screen

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov updated IGNITE-4317:
---
Comment: was deleted

(was: 'Allow non-collocated loins' doesn't work.
Query
"select count(*) from Person p
inner join Department d on d.id=p.depid
inner join Organization o on o.id = d.orgid"

returns the same result for both modes.)

> Redesign Queries Screen
> ---
>
> Key: IGNITE-4317
> URL: https://issues.apache.org/jira/browse/IGNITE-4317
> Project: Ignite
>  Issue Type: Task
>Reporter: Dmitriy Shabalin
>Assignee: Pavel Konstantinov
> Attachments: chart settings.png, scan.png
>
>
> Simplify queries screen to implement divide execute action to SCAN and QUERY 
> actions.



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

[jira] [Comment Edited] (IGNITE-4317) Redesign Queries Screen

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov edited comment on IGNITE-4317 at 12/21/16 8:47 AM:
--

Tested with demo mode:
# the option 'allow non-collocated joins' is unavailable (unclickable) in demo 
mode
# Allow non-collocated loins' doesn't work at all
Query
"select count(*) from Person p
inner join Department d on d.id=p.depid
inner join Organization o on o.id = d.orgid"

returns the same result for both modes.


was (Author: pkonstantinov):
Tested with demo mode:
# the option 'allow non-collocated joins' is unavailable (unclickable) in demo 
mode

> Redesign Queries Screen
> ---
>
> Key: IGNITE-4317
> URL: https://issues.apache.org/jira/browse/IGNITE-4317
> Project: Ignite
>  Issue Type: Task
>Reporter: Dmitriy Shabalin
>Assignee: Pavel Konstantinov
> Attachments: chart settings.png, scan.png
>
>
> Simplify queries screen to implement divide execute action to SCAN and QUERY 
> actions.



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

[jira] [Updated] (IGNITE-4317) Redesign Queries Screen

[Andrey Novikov (JIRA)]

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

Andrey Novikov updated IGNITE-4317:
---
Assignee: Pavel Konstantinov  (was: Andrey Novikov)

> Redesign Queries Screen
> ---
>
> Key: IGNITE-4317
> URL: https://issues.apache.org/jira/browse/IGNITE-4317
> Project: Ignite
>  Issue Type: Task
>Reporter: Dmitriy Shabalin
>Assignee: Pavel Konstantinov
> Attachments: chart settings.png, scan.png
>
>
> Simplify queries screen to implement divide execute action to SCAN and QUERY 
> actions.



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

[jira] [Assigned] (IGNITE-4465) Read-through is not properly working with multiple gets executed in parallel

[Semen Boikov (JIRA)]

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

Semen Boikov reassigned IGNITE-4465:


Assignee: Semen Boikov

> Read-through is not properly working with multiple gets executed in parallel
> 
>
> Key: IGNITE-4465
> URL: https://issues.apache.org/jira/browse/IGNITE-4465
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.8
>Reporter: Valentin Kulichenko
>Assignee: Semen Boikov
>Priority: Critical
> Fix For: 1.9
>
> Attachments: ReadThroughTest.java
>
>
> The issue is sporadic and very hard to isolate, however I managed to create a 
> test that reproduces it. Basically, the scenario is the following:
> * We have one server and one client.
> * The client creates a cache with read through enabled.
> * The client then executes bunch of jobs (number of jobs is bigger than 
> number of threads in server's public pool) asynchronously in parallel.
> * {{CacheStore.load()}} method is called more than once and invocations go 
> one after another (sometimes even in the same thread!) with an interval of a 
> bit more than one second, which is the duration of load (there is a 
> {{Thread.sleep(1000)}} in the implementation.
> * In addition, statistics show that number of misses go up to 50 which is 
> number of jobs. I would not expect more than 16 there. First 16 jobs executed 
> in parallel can all register miss at the same time before load happens. But 
> all consecutive execution must read the value from cache.
> Test is attached.



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