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

[Semen Boikov (JIRA)]

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

Semen Boikov edited comment on IGNITE-4109 at 12/23/16 7:33 AM:


Hi Dmitry,

I'm not sure about this in BinaryTypeProxy.target():
{noformat}
typeId = ctx.userTypeMapper(clsName).typeId(clsName);
{noformat}
Isn't it more correct to use instead
{noformat}
typeId = ctx.typeId(clsName);
{noformat}

Thanks!


was (Author: sboikov):
Hi Dmitry,
Hi Dmitry,

I'm not sure about this in BinaryTypeProxy.target():
{noformat}
typeId = ctx.userTypeMapper(clsName).typeId(clsName);
{noformat}
Isn't it more correct to use instead
{noformat}
typeId = ctx.typeId(clsName);
{noformat}

Thanks!

> 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-4142) Assertion in ClientImpl.updateMetrics()

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko commented on IGNITE-4142:
-

[~amashenkov], if you decided to fix this way, then it should be similarly 
fixed in {{ServerImpl}} as well. Basically, I think we can get rid of 
{{TcpDiscoveryHeartbeatMessage.hasCacheMetrics()}} without parameters and use 
the one that check for particular node ID instead. Agree?

> 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-4439) Create attribute based node filter

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4439:


Github user vkulichenko closed the pull request at:

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


> Create attribute based node filter
> --
>
> Key: IGNITE-4439
> URL: https://issues.apache.org/jira/browse/IGNITE-4439
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.8
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
> Fix For: 1.9
>
>
> We have a {{CacheConfiguration.nodeFilter}} configuration property which 
> takes a predicate that defines on which nodes cache is deployed. Therefore 
> using it implies creating a new class and deploying it on all nodes.
> However, in vast majority of cases users filter out nodes based on custom 
> attributes, so it can be useful to provide such implementation out of the box.



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

[jira] [Commented] (IGNITE-518) TTL is not updated for reader when entry is accessed on backup

[Alper Tekinalp (JIRA)]

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

Alper Tekinalp commented on IGNITE-518:
---

Hi. I want to work on that bug. Can you briefly explain what is the expected 
logic?

> TTL is not updated for reader when entry is accessed on backup
> --
>
> Key: IGNITE-518
> URL: https://issues.apache.org/jira/browse/IGNITE-518
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: sprint-2
>Reporter: Alexey Goncharuk
>  Labels: Muted_test
>
> When ttl is updated, readers are recorded locally and update is then sent 
> based on collected data. When get is performed on backup, readers are empty, 
> so near readers are not updated.
> {{IgniteCacheAtomicExpiryPolicyTest.testNearAccess}} fails.



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

[jira] [Comment Edited] (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=15770993#comment-15770993
 ] 

Saikat Maitra edited comment on IGNITE-1943 at 12/22/16 8:16 PM:
-

[~anovikov] [~dmagda]

Hi Andrey, Denis

I have completed the changes required for mcompact command. Please review and 
let me know if you have any feedback.

PR : https://github.com/apache/ignite/pull/1179/files

Regards,
Saikat


was (Author: samaitra):
[~anovikov][~dmagda]

Hi Andrey, Denis

I have completed the changes required for mcompact command. Please review and 
let me know if you have any feedback.

PR : https://github.com/apache/ignite/pull/1179/files

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-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=15770993#comment-15770993
 ] 

Saikat Maitra edited comment on IGNITE-1943 at 12/22/16 8:16 PM:
-

[~anovikov][~dmagda]

Hi Andrey, Denis

I have completed the changes required for mcompact command. Please review and 
let me know if you have any feedback.

PR : https://github.com/apache/ignite/pull/1179/files

Regards,
Saikat


was (Author: samaitra):
[~anovikov][~dmagda]

Hi Andrey, Denis

I have completed the changes required for mcompact command. Please review and 
let me know if you have any feedback.

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] [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=15770993#comment-15770993
 ] 

Saikat Maitra commented on IGNITE-1943:
---

[~anovikov][~dmagda]

Hi Andrey, Denis

I have completed the changes required for mcompact command. Please review and 
let me know if you have any feedback.

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] [Commented] (IGNITE-4439) Create attribute based node filter

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-4439:
-

Val, let's move it to "util" package. Looks good to merge.

> Create attribute based node filter
> --
>
> Key: IGNITE-4439
> URL: https://issues.apache.org/jira/browse/IGNITE-4439
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.8
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
> Fix For: 1.9
>
>
> We have a {{CacheConfiguration.nodeFilter}} configuration property which 
> takes a predicate that defines on which nodes cache is deployed. Therefore 
> using it implies creating a new class and deploying it on all nodes.
> However, in vast majority of cases users filter out nodes based on custom 
> attributes, so it can be useful to provide such implementation out of the box.



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

[jira] [Updated] (IGNITE-4485) CacheJdbcPojoStore returns unexpected BinaryObject upon loadCache()

[Alexandr Kuramshin (JIRA)]

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

Alexandr Kuramshin updated IGNITE-4485:
---
Assignee: Alexey Kuznetsov

> CacheJdbcPojoStore returns unexpected BinaryObject upon loadCache()
> ---
>
> Key: IGNITE-4485
> URL: https://issues.apache.org/jira/browse/IGNITE-4485
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.7, 1.8
>Reporter: Alexandr Kuramshin
>Assignee: Alexey Kuznetsov
>  Labels: easyfix
>
> When calling loadCache(IgniteBiInClosure clo, Object... args) sometimes we 
> get unexpected values of type BinaryObject in IgniteBiInClosure.apply(), 
> whereas POJO value kind was registered previously for well known key type.
> It's so because getOrCreateCacheMappings returns HashMap which resorts entity 
> mappings for the same key but with different value kind. When 
> BinaryMarshaller is used, then this map contains two mappings for the same 
> key - POJO and BINARY.
> Possible fix is to use LinkedHashMap, then POJO mapping will be picked first.



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

[jira] [Created] (IGNITE-4485) CacheJdbcPojoStore returns unexpected BinaryObject upon loadCache()

[Alexandr Kuramshin (JIRA)]

Alexandr Kuramshin created IGNITE-4485:
--

 Summary: CacheJdbcPojoStore returns unexpected BinaryObject upon 
loadCache()
 Key: IGNITE-4485
 URL: https://issues.apache.org/jira/browse/IGNITE-4485
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 1.8, 1.7
Reporter: Alexandr Kuramshin


When calling loadCache(IgniteBiInClosure clo, Object... args) sometimes we get 
unexpected values of type BinaryObject in IgniteBiInClosure.apply(), whereas 
POJO value kind was registered previously for well known key type.

It's so because getOrCreateCacheMappings returns HashMap which resorts entity 
mappings for the same key but with different value kind. When BinaryMarshaller 
is used, then this map contains two mappings for the same key - POJO and BINARY.

Possible fix is to use LinkedHashMap, then POJO mapping will be picked first.



--
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=15770594#comment-15770594
 ] 

Igor Sapego commented on IGNITE-4230:
-

Ready for review.

> 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] [Created] (IGNITE-4484) Call commit for read-only transactions.

[Alexei Scherbakov (JIRA)]

Alexei Scherbakov created IGNITE-4484:
-

 Summary: Call commit for read-only transactions.
 Key: IGNITE-4484
 URL: https://issues.apache.org/jira/browse/IGNITE-4484
 Project: Ignite
  Issue Type: Improvement
  Components: cache
Affects Versions: 1.8
Reporter: Alexei Scherbakov
 Fix For: 1.9


IGNITE-3601 introduces a behavior, which is not compliant with tx isolation 
semantics.

Read-only transaction doesn't throw optimisitc exception in case if entry 
version were changes by other writing tx.

With the appearance of IGNITE-4285 this is no longer needed.



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

[jira] [Commented] (IGNITE-1443) CPP: Implement cache continuous queries.

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-1443:


Merged the fix to master.

> CPP: Implement cache continuous queries.
> 
>
> Key: IGNITE-1443
> URL: https://issues.apache.org/jira/browse/IGNITE-1443
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
>  Labels: cpp, important, roadmap
> Fix For: 2.0
>
>




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

[jira] [Commented] (IGNITE-1443) CPP: Implement cache continuous queries.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-1443:


Github user asfgit closed the pull request at:

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


> CPP: Implement cache continuous queries.
> 
>
> Key: IGNITE-1443
> URL: https://issues.apache.org/jira/browse/IGNITE-1443
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
>  Labels: cpp, important, roadmap
> Fix For: 2.0
>
>




--
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=15770305#comment-15770305
 ] 

Semen Boikov commented on IGNITE-4465:
--

Implemented following fix: before trying to load entry from store we need 
somehow prevent entry eviction, for this I added 'IS_EVICT_DISABLED' flag in 
GridCacheMapEntry. This flag is set in innerGetVersioned and then should be 
reset after load is finished, also this flag is reset each time entry is 
updated. Initial test stared to pass, need verify on tests on TeamCity.

> 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-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=15770271#comment-15770271
 ] 

Sergey Chugunov commented on IGNITE-4157:
-

Created test for server nodes' failures scenario for #4, fixed several minor 
issues along the way.

> 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-4063) BinaryType.fieldNames() should return names in consistent order

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4063:


Github user asfgit closed the pull request at:

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


> BinaryType.fieldNames() should return names in consistent order
> ---
>
> Key: IGNITE-4063
> URL: https://issues.apache.org/jira/browse/IGNITE-4063
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Taras Ledkov
>Priority: Critical
> Fix For: 2.0
>
>
> In some cases it can be useful to get the field names from metadata in the 
> order fields were written when the metadata was created (i.e. object was 
> serialized for the first time). For example, this can be used to recreate the 
> object using builder preserving the consistent field ordering, so that 
> {{BinaryObject.equals()}} method works properly.
> Basically, we just need to replace {{HashMap}} with {{LinkedHashMap}} in the 
> {{BinaryType}} implementation.



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

[jira] [Commented] (IGNITE-4379) SQL: Local SQL field query broken in master

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4379:


Github user asfgit closed the pull request at:

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


> SQL: Local SQL field query broken in master
> ---
>
> Key: IGNITE-4379
> URL: https://issues.apache.org/jira/browse/IGNITE-4379
> Project: Ignite
>  Issue Type: Bug
>  Components: SQL
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
> Fix For: 2.0
>
>
> Local SQL field query returns entries from backup partition.
> For now query context is being cleared in 
> IgniteH2Indexing.queryLocalSqlFields() method before query is really executed.
> It seems, GridQueryFieldsResultAdapter should restore query context before 
> query run in iterator() method or move back query execution to outside 
> GridQueryFieldsResultAdapter.



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

[jira] [Commented] (IGNITE-4264) Offheap cache entries statistics is broken in master

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4264:


Github user asfgit closed the pull request at:

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


> Offheap cache entries statistics is broken in master
> 
>
> Key: IGNITE-4264
> URL: https://issues.apache.org/jira/browse/IGNITE-4264
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
> Fix For: 2.0
>
> Attachments: Test.java
>
>
> Reproducer is attached. Test is fine on 1.7 release branch, but fails in 
> master
> cache.metrics().getOffHeapPrimaryEntriesCount() returns wrong number. Also it 
> seems the number grows with increasing number of clients.



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

[jira] [Created] (IGNITE-4483) REST API - AtomicLong get/set/remove

[Roman Bielik (JIRA)]

Roman Bielik created IGNITE-4483:


 Summary: REST API - AtomicLong get/set/remove
 Key: IGNITE-4483
 URL: https://issues.apache.org/jira/browse/IGNITE-4483
 Project: Ignite
  Issue Type: Improvement
  Components: rest
Affects Versions: 1.8
Reporter: Roman Bielik


The Ignite REST API lacks operations for setting and deleting a counter (atomic 
long). It would be also nice to have a pure get operation, but there is at 
least a workaround in using increment/decrement with delta = 0.

IgniteAtomicLong.get()
IgniteAtomicLong.getAndSet()
IgniteAtomicLong.close()




--
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=15770201#comment-15770201
 ] 

Andrew Mashenkov commented on IGNITE-4142:
--

TC tests look good.


> 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] [Reopened] (IGNITE-1443) CPP: Implement cache continuous queries.

[Igor Sapego (JIRA)]

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

Igor Sapego reopened IGNITE-1443:
-
  Assignee: Igor Sapego

> CPP: Implement cache continuous queries.
> 
>
> Key: IGNITE-1443
> URL: https://issues.apache.org/jira/browse/IGNITE-1443
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>Assignee: Igor Sapego
>  Labels: cpp, important, roadmap
> Fix For: 2.0
>
>




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

[jira] [Commented] (IGNITE-1443) CPP: Implement cache continuous queries.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-1443:


GitHub user isapego opened a pull request:

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

IGNITE-1443: Minor fix.



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

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

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

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


commit 7fe666b2942ffb04ad8554de2ad3268b405d82d9
Author: Igor Sapego 
Date:   2016-12-22T14:19:45Z

IGNITE-1443: Minor fix.




> CPP: Implement cache continuous queries.
> 
>
> Key: IGNITE-1443
> URL: https://issues.apache.org/jira/browse/IGNITE-1443
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>  Labels: cpp, important, roadmap
> Fix For: 2.0
>
>




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

[jira] [Resolved] (IGNITE-3612) Remove IgniteAsyncSupport,

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov resolved IGNITE-3612.
-
Resolution: Duplicate

> Remove IgniteAsyncSupport,
> --
>
> Key: IGNITE-3612
> URL: https://issues.apache.org/jira/browse/IGNITE-3612
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>
> We need to remove {{IgniteAsyncSupport}} as it is hard and error prone to 
> use. 
> Instead, we should all async methods must be implemented as another method in 
> target interface with "Async" prefix. E.g.:
> {{Cache.get}}
> {{Cache.getAsync}}



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

[jira] [Updated] (IGNITE-3579) Message type should be short.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-3579:

Priority: Critical  (was: Major)

> 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: Chandresh Pancholi
>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.4#6332)

[jira] [Commented] (IGNITE-3579) Message type should be short.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-3579:
-

Priority is critical because we are already almost out of slots for new 
messages.

> 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: Chandresh Pancholi
>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.4#6332)

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

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-4471:
---
Summary: ODBC: Can not retrieve table metadata  (was: ODBC: Can not 
retrieve table metadata.)

> 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] [Commented] (IGNITE-4471) ODBC: Can not retrieve table metadata.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4471:


GitHub user isapego opened a pull request:

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

IGNITE-4471: Fixed ODBC string-reading utility function.



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

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

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

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


commit 95d417d570af82d05119ee6be193b10106e99614
Author: Igor Sapego 
Date:   2016-12-22T13:34:10Z

IGNITE-4471: Fixed ODBC string-reading utility 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] [Updated] (IGNITE-3488) Prohibit null as name in all the components (cache name first of all).

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-3488:

Affects Version/s: 1.8

> Prohibit null as name in all the components (cache name first of all).
> --
>
> Key: IGNITE-3488
> URL: https://issues.apache.org/jira/browse/IGNITE-3488
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.8
>Reporter: Sergi Vladykin
>Priority: Critical
>  Labels: important
> Fix For: 2.0
>
>
> Need to create a list of all the affected components.



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

[jira] [Updated] (IGNITE-3478) Transactional SQL

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-3478:

Component/s: SQL

> Transactional SQL
> -
>
> Key: IGNITE-3478
> URL: https://issues.apache.org/jira/browse/IGNITE-3478
> Project: Ignite
>  Issue Type: Task
>  Components: cache, SQL
>Reporter: Alexey Goncharuk
>Assignee: Sergi Vladykin
>  Labels: important
> Fix For: 2.0
>
>
> Current Ignite SQL does not take into account transaction boundaries. For 
> example, if a transaction atomically changes balance of two accounts, then a 
> concurrent SQL query can see partially committed transaction. This works for 
> data analytics, but does not work for more strict and demanding scenarios.
> It would be perfect if we had a mode which ensures transaction boundaries are 
> taken into account for SQL query.



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

[jira] [Updated] (IGNITE-3488) Prohibit null as name in all the components (cache name first of all).

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-3488:

Component/s: general

> Prohibit null as name in all the components (cache name first of all).
> --
>
> Key: IGNITE-3488
> URL: https://issues.apache.org/jira/browse/IGNITE-3488
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Reporter: Sergi Vladykin
>Priority: Critical
>  Labels: important
> Fix For: 2.0
>
>
> Need to create a list of all the affected components.



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

[jira] [Updated] (IGNITE-2580) Investigate HashMap.Node[] allocations from GridDhtTxPrepareFuture.readyLocks(Iterable)

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2580:

Priority: Minor  (was: Major)

> Investigate HashMap.Node[] allocations from 
> GridDhtTxPrepareFuture.readyLocks(Iterable)
> ---
>
> Key: IGNITE-2580
> URL: https://issues.apache.org/jira/browse/IGNITE-2580
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Priority: Minor
>  Labels: performance
> Fix For: 2.0
>
>
> *Problem*
> GridDhtTxPrepareFuture is initialized with empty HashSet by default. When 
> single lock is ready HashSet.add() is called causing immediate expansion of 
> underlying HashMap table.
> *Solution*
> Do we really need fully-fledged hash set immediately? Probably we can 
> optimize for single-lock case so that HashSet is not needed at all.



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

[jira] [Updated] (IGNITE-2577) Investigate HashMap.Node[] allocations from GridDistributedTxMapping.add()

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2577:

Priority: Minor  (was: Major)

> Investigate HashMap.Node[] allocations from GridDistributedTxMapping.add()
> --
>
> Key: IGNITE-2577
> URL: https://issues.apache.org/jira/browse/IGNITE-2577
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Priority: Minor
>  Labels: performance
> Fix For: 2.0
>
>
> *Problem*
> GridDistributedTxMapping is initialized with empty HashSet() for TX entries 
> by default. 
> When the very first element is added, undelying HashMap expands causing 
> memory traffic.
> *Proposed solutions*
> 1) Use LinkedList instead. One can notice that when GridDistributedTxMapping 
> is deserialized using direct reader, "entries" are read as list. Furthermore, 
> both "reads" and "writes" projections are returned as wrapped views, so that 
> do not benefit form fast lookups.
> If we neither perform lookups from entries, nor require "unique" Set 
> semantics, "entries" could be changed to LinkedList thus decresaing memory 
> traffic.
> 2) Use special singleton collection. This way we will have to evaluate all 
> "entries" usages very carefully.



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

[jira] [Updated] (IGNITE-2297) DirectByteBufferStreamImplV2: add special cases for maps with a single element.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2297:

Priority: Minor  (was: Major)

> DirectByteBufferStreamImplV2: add special cases for maps with a single 
> element.
> ---
>
> Key: IGNITE-2297
> URL: https://issues.apache.org/jira/browse/IGNITE-2297
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Priority: Minor
>  Labels: performance
> Fix For: 2.0
>
>
> The biggest hotspot in a simple PUT scenario is Entry[] creation caused by 
> empty HashMap inflation inside DirectByteBufferStreamImplV2 read methods.
> It is interesting, that in lots cases the map being read contains only one 
> element. 
> Looks like this common case could be optimized - create a map with single 
> key/val pair with optional fallback to normal map.



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

[jira] [Updated] (IGNITE-2274) Avoid ArrayList creation for a single element when possible.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2274:

Priority: Minor  (was: Major)

> Avoid ArrayList creation for a single element when possible.
> 
>
> Key: IGNITE-2274
> URL: https://issues.apache.org/jira/browse/IGNITE-2274
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Priority: Minor
>  Labels: performance
> Fix For: 2.0
>
>
> Profiling shown lots of ArrayList allocations. Investigation shown the 
> following usual pattern in our code:
> 1) Create empty ArrayList.
> 2) Then add a single element to it at some point. When this addition happens, 
> ArrayList allocates Object[10] array. 
> But in lots cases we know in advance that particular senario will contain 
> only single entry in this collection.
> Need to fix places where it is trivial to detect and handle.



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

[jira] [Updated] (IGNITE-2233) Avoid boxing in BinaryContext collections

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2233:

Priority: Minor  (was: Major)

> Avoid boxing in BinaryContext collections
> -
>
> Key: IGNITE-2233
> URL: https://issues.apache.org/jira/browse/IGNITE-2233
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Priority: Minor
>  Labels: performance
> Fix For: 2.0
>
>
> The following methods generate visible GC pressure due to constant boxing of 
> int keys:
> BinaryContext.descriptorForTypeId
> BinaryContext.userTypeIdMapper
> BinaryContext.schemaRegistry
> Possilbe solutions:
> 1) int -> Object maps (e.g. see Martin Thompson's Argona lib).
> 2) COW semantics instead of concurrent maps/sets as these collections are 
> updated only during warmup.



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

[jira] [Updated] (IGNITE-2216) Duplicate field names with aliases do not work in queries.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2216:

Component/s: SQL

> Duplicate field names with aliases do not work in queries.
> --
>
> Key: IGNITE-2216
> URL: https://issues.apache.org/jira/browse/IGNITE-2216
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, SQL
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>




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

[jira] [Commented] (IGNITE-2194) IgniteCacheProxy is not serialized properly.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-2194:
-

Alex,

Is this issue still relevant? We heavily reworked serialization logic and 
chances that this is not a problem anymore.

> IgniteCacheProxy is not serialized properly.
> 
>
> Key: IGNITE-2194
> URL: https://issues.apache.org/jira/browse/IGNITE-2194
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Alexey Goncharuk
> Fix For: 2.0
>
>
> See 
> org.apache.ignite.internal.processors.cache.IgniteCacheSerializationSelfTest
> I believe that only proxy instances should be serializable. However, the 
> change should be done carefully to preserve backward compatibility.



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

[jira] [Updated] (IGNITE-2210) Cannot query annotated methods when BinaryMarshaller is set.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2210:

Component/s: SQL

> Cannot query annotated methods when BinaryMarshaller is set.
> 
>
> Key: IGNITE-2210
> URL: https://issues.apache.org/jira/browse/IGNITE-2210
> Project: Ignite
>  Issue Type: Task
>  Components: general, SQL
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>
> Because it is impossible to call method from object in binary form. Several 
> solutions could be applied here:
> 1) Throw exception when method annotation is found and BinaryMarshaller is 
> set.
> 2) Or call this method and record it as a field to the object.
> Sample test: 
> IgniteCacheAbstractFieldsQuerySelfTest.testMethodAnnotationWithoutGet



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

[jira] [Updated] (IGNITE-2177) User defined aggregate functions for SQL

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2177:

Component/s: SQL

> User defined aggregate functions for SQL
> 
>
> Key: IGNITE-2177
> URL: https://issues.apache.org/jira/browse/IGNITE-2177
> Project: Ignite
>  Issue Type: Wish
>  Components: SQL
>Affects Versions: 1.8
>Reporter: Sergi Vladykin
> Fix For: 2.0
>
>
> Need to design some factory like abstraction for creating map part and reduce 
> part of the aggregate. 



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

[jira] [Updated] (IGNITE-2177) User defined aggregate functions for SQL

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2177:

Affects Version/s: 1.8

> User defined aggregate functions for SQL
> 
>
> Key: IGNITE-2177
> URL: https://issues.apache.org/jira/browse/IGNITE-2177
> Project: Ignite
>  Issue Type: Wish
>  Components: SQL
>Affects Versions: 1.8
>Reporter: Sergi Vladykin
> Fix For: 2.0
>
>
> Need to design some factory like abstraction for creating map part and reduce 
> part of the aggregate. 



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

[jira] [Updated] (IGNITE-1914) .Net: Get rid of boxing in DoOutInOpNullable

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-1914:

Labels: .net performance  (was: .net)

> .Net: Get rid of boxing in DoOutInOpNullable
> 
>
> Key: IGNITE-1914
> URL: https://issues.apache.org/jira/browse/IGNITE-1914
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Priority: Minor
>  Labels: .net, performance
> Fix For: 2.0
>
>
> See CacheImpl.DoOutInOpNullable overloads.
> We read result as object and then check for null. Nulls are quite frequent in 
> these scenarios.
> To get rid of boxing we need to introduce TryUnmarshal method which allows 
> reading value types with null semantics.



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

[jira] [Closed] (IGNITE-1650) Add ability to specify thread pool for IgniteFuture listen/chain methods.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-1650.
---

> Add ability to specify thread pool for IgniteFuture listen/chain methods.
> -
>
> Key: IGNITE-1650
> URL: https://issues.apache.org/jira/browse/IGNITE-1650
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Chandresh Pancholi
> Fix For: 2.0
>
>
> Closures passed to IgniteFuture listen() and chain() methods are executed 
> either in the same thread if future is completed, or in a completion thread 
> (usually this is a thread from one of Ignite pools).
> This enforces restrictions on what user can do in closures. He cannot use 
> call operations, he cannot call any Ignite operations. Otherwise deadlocks or 
> starvation could occur.
> To fix that we should allow user to pass optional thread pool where passed 
> closure should be executed. This already done in Java 8 CompletableFuture. We 
> should do almost the same.



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

[jira] [Resolved] (IGNITE-1650) Add ability to specify thread pool for IgniteFuture listen/chain methods.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov resolved IGNITE-1650.
-
Resolution: Duplicate

> Add ability to specify thread pool for IgniteFuture listen/chain methods.
> -
>
> Key: IGNITE-1650
> URL: https://issues.apache.org/jira/browse/IGNITE-1650
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Chandresh Pancholi
> Fix For: 2.0
>
>
> Closures passed to IgniteFuture listen() and chain() methods are executed 
> either in the same thread if future is completed, or in a completion thread 
> (usually this is a thread from one of Ignite pools).
> This enforces restrictions on what user can do in closures. He cannot use 
> call operations, he cannot call any Ignite operations. Otherwise deadlocks or 
> starvation could occur.
> To fix that we should allow user to pass optional thread pool where passed 
> closure should be executed. This already done in Java 8 CompletableFuture. We 
> should do almost the same.



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

[jira] [Commented] (IGNITE-1650) Add ability to specify thread pool for IgniteFuture listen/chain methods.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-1650:
-

Updated and more correct design can be found in IGNITE-4477. 

> Add ability to specify thread pool for IgniteFuture listen/chain methods.
> -
>
> Key: IGNITE-1650
> URL: https://issues.apache.org/jira/browse/IGNITE-1650
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Chandresh Pancholi
> Fix For: 2.0
>
>
> Closures passed to IgniteFuture listen() and chain() methods are executed 
> either in the same thread if future is completed, or in a completion thread 
> (usually this is a thread from one of Ignite pools).
> This enforces restrictions on what user can do in closures. He cannot use 
> call operations, he cannot call any Ignite operations. Otherwise deadlocks or 
> starvation could occur.
> To fix that we should allow user to pass optional thread pool where passed 
> closure should be executed. This already done in Java 8 CompletableFuture. We 
> should do almost the same.



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

[jira] [Updated] (IGNITE-1543) SqlQuery returns empty result set when custom PortableIdMapper

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-1543:

Component/s: SQL

> SqlQuery returns empty result set when custom PortableIdMapper
> --
>
> Key: IGNITE-1543
> URL: https://issues.apache.org/jira/browse/IGNITE-1543
> Project: Ignite
>  Issue Type: Bug
>  Components: general, SQL
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Priority: Minor
> Fix For: 2.0
>
> Attachments: ClientTest.java
>
>
> Set custom {{PortableIdMapper}} for a type. Let this mapper to return some 
> predefined id for this type (like 12345).
> Then execute SQL to get all the entries of this type. The query will return 
> an empty result set. 
> Seems that at some point of execution SQL engine or some other part of the 
> platform uses default type to id mapping ignoring given {{PotableIdMapper}}.
> To reproduce:
> - Start a server node with portable marshaller enabled;
> - run the code attached (ClientTest.java).
> Add a test to our test suites.



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

[jira] [Updated] (IGNITE-1072) Need to automatically support LocalDateTime class in indexing

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-1072:

Component/s: SQL

> Need to automatically support LocalDateTime class in indexing
> -
>
> Key: IGNITE-1072
> URL: https://issues.apache.org/jira/browse/IGNITE-1072
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, SQL
>Affects Versions: 1.1.4
>Reporter: Valentin Kulichenko
>Priority: Critical
>  Labels: Usability
> Fix For: 2.0
>
>
> Currently this query doesn't work if {{localDate}} is an instance of 
> {{LocalDateTime}}:
> {code}
> SqlFieldsQuery qry = new SqlFieldsQuery(
> "SELECT localDate from MyObject " +
> "WHERE localDate = '2013-09-12T11:00'");
> {code}
> It's not supported because {{LocalDateTime}} is JDK8 class. But probably we 
> can use reflection to solve this.
> Also need to go through all classes in {{java.time}} package and see if any 
> of them need to be supported as well.



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

[jira] [Resolved] (IGNITE-735) Need to add support for dynamic indexes

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov resolved IGNITE-735.

Resolution: Won't Fix

This task will be handled separately as a part of upcoming DDL efforts.

> Need to add support for dynamic indexes
> ---
>
> Key: IGNITE-735
> URL: https://issues.apache.org/jira/browse/IGNITE-735
> Project: Ignite
>  Issue Type: Task
>  Components: SQL
>Reporter: Alexey Kuznetsov
>Assignee: Sergi Vladykin
> Fix For: 2.0
>
>
> We should support dynamic index creation and deletion.



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

[jira] [Resolved] (IGNITE-104) Need to enable thread-per-partition mode for atomic caches

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov resolved IGNITE-104.

Resolution: Duplicate

Already implemented.

> Need to enable thread-per-partition mode for atomic caches
> --
>
> Key: IGNITE-104
> URL: https://issues.apache.org/jira/browse/IGNITE-104
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache
>Reporter: Dmitriy Setrakyan
>Assignee: Yakov Zhdanov
>Priority: Critical
> Fix For: 2.0
>
>
> Currently messages are processed in any order for atomic caches. We can add 
> ordered processing by assigning a thread per partition. This way we will be 
> able to remove any locking as well.
> {{Cache.invoke()}} method would be able to invoke the EntryProcessor on 
> primary and backup independently. Right now we only invoke the EntryProcessor 
> only on the primary node and the send the computed value to the backup node, 
> which may be expensive.



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

[jira] [Updated] (IGNITE-481) Add tests for Metrics to the file system tests infrastructure

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-481:
---
Component/s: (was: hadoop)
 IGFS

> Add tests for Metrics to the file system tests infrastructure
> -
>
> Key: IGNITE-481
> URL: https://issues.apache.org/jira/browse/IGNITE-481
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Ivan Veselovsky
>Assignee: Vladimir Ozerov
>Priority: Minor
> Fix For: 2.0
>
>
> Need to add tests for org.apache.ignite.igfs.IgfsMetrics to the filesystem 
> tests.
> See org.apache.ignite.IgniteFileSystem#metrics , 
> org.apache.ignite.IgniteFileSystem#resetMetrics .



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

[jira] [Updated] (IGNITE-4437) Make sure data structures do not use outTx call

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4437:

Fix Version/s: (was: 2,0)
   2.0

> Make sure data structures do not use outTx call
> ---
>
> Key: IGNITE-4437
> URL: https://issues.apache.org/jira/browse/IGNITE-4437
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache, data structures
>Reporter: Alexei Scherbakov
> Fix For: 2.0
>
>
> Ignite's data structures use outTx call to avoid an intersection with user 
> transaction.
> This is no longer necessary, because system and user transactions are now 
> separated.
> Need to get rid of these calls.



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

[jira] [Updated] (IGNITE-4448) Implement correct affinity validation on joining topology.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4448:

Fix Version/s: (was: 2,0)
   2.0

> Implement correct affinity validation on joining topology.
> --
>
> Key: IGNITE-4448
> URL: https://issues.apache.org/jira/browse/IGNITE-4448
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
> Fix For: 2.0
>
>
> Currently on joining a topology only affinity class name and partition number 
> are checked between configurations of local and remote nodes.
> This is not enough in case of configured backup filter and possible extension 
> with primary filter and can lead to disastrous situations due to node 
> misconfiguration.
> We should implement something like {{AffinityValidator}} having signature as 
> follows:
> {noformat}
> boolean validate(Affinity affinity)
> {noformat}
> Maybe it'll be useful for other grid objects as well, like 
> {{CacheStore}},{{NodeFilter}}, etc.



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

[jira] [Updated] (IGNITE-4358) Better error reporting in case of unmarshallable classes.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4358:

Fix Version/s: (was: 2,0)
   2.0

> Better error reporting in case of unmarshallable classes.
> -
>
> Key: IGNITE-4358
> URL: https://issues.apache.org/jira/browse/IGNITE-4358
> Project: Ignite
>  Issue Type: Improvement
>  Components: compute, messaging, newbie
>Affects Versions: 1.6
>Reporter: Alexei Scherbakov
>Assignee: Rohit Mohta
>Priority: Trivial
>  Labels: newbie
> Fix For: 2.0
>
> Attachments: IGNITE-4358-Exceptionlog-05Dec2016.txt, 
> IGNITE-4358-GridClosureProcessor-05Dec2016.patch, PureIgniteRunTest.java
>
>
> When trying to execute Thread's derived class implementing IgniteRunnable 
> using compute API, it silently serializes to null because Thread 
> serialization is prohibited in MarshallerExclusions and throws NPE on 
> executing node.
> We need to throw more informative exception for such case.
> Reproducer in the attachment.



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

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

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-4441:
-

It would also be cool to have a shortcut method to get plugin configuration 
inside {{IPluginContext}}. E.g.:
{code}
T pluginConfiguration();
{code}

> Define plugin API in .NET
> -
>
> Key: IGNITE-4441
> URL: https://issues.apache.org/jira/browse/IGNITE-4441
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> Define plugin API in .NET similar to Java API:
> * {{IgniteConfiguration.PluginConfigurations}}
> * {{IPluginProvider}}
> * {{IPluginContext}}
> Should work like this:
> * Plugin author implements {{IPluginProvider}}
> * We discover plugins on Ignite start by examining all DLL files in the 
> folder, load DLLs where {{IPluginProvider}} implementations are present, 
> instantiate these implementations, and call 
> {{IPluginProvider.Start(IPluginContext)}} method.
> * Plugin user can retrieve plugin via {{IIgnite.GetPlugin(string name)}}, 
> or via helper extension method provided by plugin author.
> This task does not include the possibility to interact with Java from the 
> plugin code.



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

[jira] [Resolved] (IGNITE-4430) .NET: Cannot convert the "Name" value of type "System.String" to type "System.Management.Automation.ScriptBlock"

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn resolved IGNITE-4430.

Resolution: Won't Fix
  Assignee: (was: Pavel Tupitsyn)

> .NET: Cannot convert the "Name" value of type "System.String" to type 
> "System.Management.Automation.ScriptBlock"
> 
>
> Key: IGNITE-4430
> URL: https://issues.apache.org/jira/browse/IGNITE-4430
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.8
>Reporter: Ksenia Rybakova
>Priority: Minor
>
> Environment:
> - Windows7
> - VS 2015
> - NuGet Package Manager 3.4.4
> - Powershell version
> {noformat}
> PS C:\Users\San> $PSVersionTable.PSVersion
> Major  Minor  Build  Revision
> -  -  -  
> 2  0  -1 -1
> {noformat}
> While installing/uninstalling Apache.Ignite package the following exception 
> occurs
> {noformat}
> PM> Install-Package Apache.Ignite -Source 
> https://www.myget.org/F/apache-ignite-staging/api/v2 -Version 1.8.1
> Attempting to gather dependency information for package 'Apache.Ignite.1.8.1' 
> with respect to project 'WebApplication1', targeting 
> '.NETFramework,Version=v4.5.2'
> Attempting to resolve dependencies for package 'Apache.Ignite.1.8.1' with 
> DependencyBehavior 'Lowest'
> Resolving actions to install package 'Apache.Ignite.1.8.1'
> Resolved actions to install package 'Apache.Ignite.1.8.1'
> Adding package 'Apache.Ignite.1.8.1' to folder 
> 'D:\Work_Ksu\Platform_tests\WebApplication1\packages'
> Added package 'Apache.Ignite.1.8.1' to folder 
> 'D:\Work_Ksu\Platform_tests\WebApplication1\packages'
> Added package 'Apache.Ignite.1.8.1' to 'packages.config'
> Executing script file 
> 'D:\Work_Ksu\Platform_tests\WebApplication1\packages\Apache.Ignite.1.8.1\tools\Install.ps1'
> Updating project properties...
> Where-Object : Cannot bind parameter 'FilterScript'. Cannot convert the 
> "Name" value of type "System.String" to type "System.Management.Automation.Scr
> iptBlock".
> At 
> D:\Work_Ksu\Platform_tests\WebApplication1\packages\Apache.Ignite.1.8.1\tools\Install.ps1:33
>  char:37
> + $binDir = ($_.Properties | Where   Name -match OutputPath).Value
> + CategoryInfo  : InvalidArgument: (:) [Where-Object], 
> ParameterBindingException
> + FullyQualifiedErrorId : 
> CannotConvertArgumentNoMessage,Microsoft.PowerShell.Commands.WhereObjectCommand
>  
> Where-Object : Cannot bind parameter 'FilterScript'. Cannot convert the 
> "Name" value of type "System.String" to type "System.Management.Automation.Scr
> iptBlock".
> At 
> D:\Work_Ksu\Platform_tests\WebApplication1\packages\Apache.Ignite.1.8.1\tools\Install.ps1:33
>  char:37
> + $binDir = ($_.Properties | Where   Name -match OutputPath).Value
> + CategoryInfo  : InvalidArgument: (:) [Where-Object], 
> ParameterBindingException
> + FullyQualifiedErrorId : 
> CannotConvertArgumentNoMessage,Microsoft.PowerShell.Commands.WhereObjectCommand
>  
> Welcome to Apache Ignite.NET!
> Successfully installed 'Apache.Ignite 1.8.1' to WebApplication1
> PM> 
> PM> Uninstall-Package Apache.Ignite
> Attempting to gather dependency information for package 'Apache.Ignite.1.8.1' 
> with respect to project 'WebApplication1', targeting 
> '.NETFramework,Version=v4.5.2'
> Resolving actions to uninstall package 'Apache.Ignite.1.8.1'
> Resolved actions to uninstall package 'Apache.Ignite.1.8.1'
> Executing script file 
> 'D:\Work_Ksu\Platform_tests\WebApplication1\packages\Apache.Ignite.1.8.1\tools\Uninstall.ps1'
> Where-Object : Cannot bind parameter 'FilterScript'. Cannot convert the 
> "Name" value of type "System.String" to type "System.Management.Automation.Scr
> iptBlock".
> At 
> D:\Work_Ksu\Platform_tests\WebApplication1\packages\Apache.Ignite.1.8.1\tools\Uninstall.ps1:29
>  char:37
> + $binDir = ($_.Properties | Where   Name -match OutputPath).Value
> + CategoryInfo  : InvalidArgument: (:) [Where-Object], 
> ParameterBindingException
> + FullyQualifiedErrorId : 
> CannotConvertArgumentNoMessage,Microsoft.PowerShell.Commands.WhereObjectCommand
>  
> Where-Object : Cannot bind parameter 'FilterScript'. Cannot convert the 
> "Name" value of type "System.String" to type "System.Management.Automation.Scr
> iptBlock".
> At 
> D:\Work_Ksu\Platform_tests\WebApplication1\packages\Apache.Ignite.1.8.1\tools\Uninstall.ps1:29
>  char:37
> + $binDir = ($_.Properties | Where   Name -match OutputPath).Value
> + CategoryInfo  : InvalidArgument: (:) [Where-Object], 
> ParameterBindingException
> + FullyQualifiedErrorId : 
> CannotConvertArgumentNoMessage,Microsoft.PowerShell.Commands.WhereObjectCommand
>  
> Removed package 'Apache.Ignite.1.8.1' 

[jira] [Commented] (IGNITE-4430) .NET: Cannot convert the "Name" value of type "System.String" to type "System.Management.Automation.ScriptBlock"

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-4430:


This is caused by outdated PowerShell 2.0. All supported Windows versions have 
at least 4.0 installed (https://en.wikipedia.org/wiki/PowerShell#Versions). 
Please make sure that OS is updated properly.

> .NET: Cannot convert the "Name" value of type "System.String" to type 
> "System.Management.Automation.ScriptBlock"
> 
>
> Key: IGNITE-4430
> URL: https://issues.apache.org/jira/browse/IGNITE-4430
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.8
>Reporter: Ksenia Rybakova
>Assignee: Pavel Tupitsyn
>Priority: Minor
>
> Environment:
> - Windows7
> - VS 2015
> - NuGet Package Manager 3.4.4
> - Powershell version
> {noformat}
> PS C:\Users\San> $PSVersionTable.PSVersion
> Major  Minor  Build  Revision
> -  -  -  
> 2  0  -1 -1
> {noformat}
> While installing/uninstalling Apache.Ignite package the following exception 
> occurs
> {noformat}
> PM> Install-Package Apache.Ignite -Source 
> https://www.myget.org/F/apache-ignite-staging/api/v2 -Version 1.8.1
> Attempting to gather dependency information for package 'Apache.Ignite.1.8.1' 
> with respect to project 'WebApplication1', targeting 
> '.NETFramework,Version=v4.5.2'
> Attempting to resolve dependencies for package 'Apache.Ignite.1.8.1' with 
> DependencyBehavior 'Lowest'
> Resolving actions to install package 'Apache.Ignite.1.8.1'
> Resolved actions to install package 'Apache.Ignite.1.8.1'
> Adding package 'Apache.Ignite.1.8.1' to folder 
> 'D:\Work_Ksu\Platform_tests\WebApplication1\packages'
> Added package 'Apache.Ignite.1.8.1' to folder 
> 'D:\Work_Ksu\Platform_tests\WebApplication1\packages'
> Added package 'Apache.Ignite.1.8.1' to 'packages.config'
> Executing script file 
> 'D:\Work_Ksu\Platform_tests\WebApplication1\packages\Apache.Ignite.1.8.1\tools\Install.ps1'
> Updating project properties...
> Where-Object : Cannot bind parameter 'FilterScript'. Cannot convert the 
> "Name" value of type "System.String" to type "System.Management.Automation.Scr
> iptBlock".
> At 
> D:\Work_Ksu\Platform_tests\WebApplication1\packages\Apache.Ignite.1.8.1\tools\Install.ps1:33
>  char:37
> + $binDir = ($_.Properties | Where   Name -match OutputPath).Value
> + CategoryInfo  : InvalidArgument: (:) [Where-Object], 
> ParameterBindingException
> + FullyQualifiedErrorId : 
> CannotConvertArgumentNoMessage,Microsoft.PowerShell.Commands.WhereObjectCommand
>  
> Where-Object : Cannot bind parameter 'FilterScript'. Cannot convert the 
> "Name" value of type "System.String" to type "System.Management.Automation.Scr
> iptBlock".
> At 
> D:\Work_Ksu\Platform_tests\WebApplication1\packages\Apache.Ignite.1.8.1\tools\Install.ps1:33
>  char:37
> + $binDir = ($_.Properties | Where   Name -match OutputPath).Value
> + CategoryInfo  : InvalidArgument: (:) [Where-Object], 
> ParameterBindingException
> + FullyQualifiedErrorId : 
> CannotConvertArgumentNoMessage,Microsoft.PowerShell.Commands.WhereObjectCommand
>  
> Welcome to Apache Ignite.NET!
> Successfully installed 'Apache.Ignite 1.8.1' to WebApplication1
> PM> 
> PM> Uninstall-Package Apache.Ignite
> Attempting to gather dependency information for package 'Apache.Ignite.1.8.1' 
> with respect to project 'WebApplication1', targeting 
> '.NETFramework,Version=v4.5.2'
> Resolving actions to uninstall package 'Apache.Ignite.1.8.1'
> Resolved actions to uninstall package 'Apache.Ignite.1.8.1'
> Executing script file 
> 'D:\Work_Ksu\Platform_tests\WebApplication1\packages\Apache.Ignite.1.8.1\tools\Uninstall.ps1'
> Where-Object : Cannot bind parameter 'FilterScript'. Cannot convert the 
> "Name" value of type "System.String" to type "System.Management.Automation.Scr
> iptBlock".
> At 
> D:\Work_Ksu\Platform_tests\WebApplication1\packages\Apache.Ignite.1.8.1\tools\Uninstall.ps1:29
>  char:37
> + $binDir = ($_.Properties | Where   Name -match OutputPath).Value
> + CategoryInfo  : InvalidArgument: (:) [Where-Object], 
> ParameterBindingException
> + FullyQualifiedErrorId : 
> CannotConvertArgumentNoMessage,Microsoft.PowerShell.Commands.WhereObjectCommand
>  
> Where-Object : Cannot bind parameter 'FilterScript'. Cannot convert the 
> "Name" value of type "System.String" to type "System.Management.Automation.Scr
> iptBlock".
> At 
> D:\Work_Ksu\Platform_tests\WebApplication1\packages\Apache.Ignite.1.8.1\tools\Uninstall.ps1:29
>  char:37
> + $binDir = ($_.Properties | Where   Name -match OutputPath).Value
> + CategoryInfo  : 

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

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-4441:
-

Pavel,
I am a bit concerned about {{IPluginConfiguration.CreateProvider}} method. 
Ideally user should not have access to this method. Can we define an attribute 
on concrete configuration which will point to a plugin class name?

> Define plugin API in .NET
> -
>
> Key: IGNITE-4441
> URL: https://issues.apache.org/jira/browse/IGNITE-4441
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Vladimir Ozerov
>  Labels: .NET
> Fix For: 2.0
>
>
> Define plugin API in .NET similar to Java API:
> * {{IgniteConfiguration.PluginConfigurations}}
> * {{IPluginProvider}}
> * {{IPluginContext}}
> Should work like this:
> * Plugin author implements {{IPluginProvider}}
> * We discover plugins on Ignite start by examining all DLL files in the 
> folder, load DLLs where {{IPluginProvider}} implementations are present, 
> instantiate these implementations, and call 
> {{IPluginProvider.Start(IPluginContext)}} method.
> * Plugin user can retrieve plugin via {{IIgnite.GetPlugin(string name)}}, 
> or via helper extension method provided by plugin author.
> This task does not include the possibility to interact with Java from the 
> plugin code.



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

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

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-4212:
--

Oleg,
we should name subtasks in proper way.
Now I see 3 "Part of IGNITE-4212" and it's impossible to understand what these 
tasks responsible for.

> 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] [Assigned] (IGNITE-4430) .NET: Cannot convert the "Name" value of type "System.String" to type "System.Management.Automation.ScriptBlock"

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn reassigned IGNITE-4430:
--

Assignee: Pavel Tupitsyn

> .NET: Cannot convert the "Name" value of type "System.String" to type 
> "System.Management.Automation.ScriptBlock"
> 
>
> Key: IGNITE-4430
> URL: https://issues.apache.org/jira/browse/IGNITE-4430
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.8
>Reporter: Ksenia Rybakova
>Assignee: Pavel Tupitsyn
>Priority: Minor
>
> Environment:
> - Windows7
> - VS 2015
> - NuGet Package Manager 3.4.4
> - Powershell version
> {noformat}
> PS C:\Users\San> $PSVersionTable.PSVersion
> Major  Minor  Build  Revision
> -  -  -  
> 2  0  -1 -1
> {noformat}
> While installing/uninstalling Apache.Ignite package the following exception 
> occurs
> {noformat}
> PM> Install-Package Apache.Ignite -Source 
> https://www.myget.org/F/apache-ignite-staging/api/v2 -Version 1.8.1
> Attempting to gather dependency information for package 'Apache.Ignite.1.8.1' 
> with respect to project 'WebApplication1', targeting 
> '.NETFramework,Version=v4.5.2'
> Attempting to resolve dependencies for package 'Apache.Ignite.1.8.1' with 
> DependencyBehavior 'Lowest'
> Resolving actions to install package 'Apache.Ignite.1.8.1'
> Resolved actions to install package 'Apache.Ignite.1.8.1'
> Adding package 'Apache.Ignite.1.8.1' to folder 
> 'D:\Work_Ksu\Platform_tests\WebApplication1\packages'
> Added package 'Apache.Ignite.1.8.1' to folder 
> 'D:\Work_Ksu\Platform_tests\WebApplication1\packages'
> Added package 'Apache.Ignite.1.8.1' to 'packages.config'
> Executing script file 
> 'D:\Work_Ksu\Platform_tests\WebApplication1\packages\Apache.Ignite.1.8.1\tools\Install.ps1'
> Updating project properties...
> Where-Object : Cannot bind parameter 'FilterScript'. Cannot convert the 
> "Name" value of type "System.String" to type "System.Management.Automation.Scr
> iptBlock".
> At 
> D:\Work_Ksu\Platform_tests\WebApplication1\packages\Apache.Ignite.1.8.1\tools\Install.ps1:33
>  char:37
> + $binDir = ($_.Properties | Where   Name -match OutputPath).Value
> + CategoryInfo  : InvalidArgument: (:) [Where-Object], 
> ParameterBindingException
> + FullyQualifiedErrorId : 
> CannotConvertArgumentNoMessage,Microsoft.PowerShell.Commands.WhereObjectCommand
>  
> Where-Object : Cannot bind parameter 'FilterScript'. Cannot convert the 
> "Name" value of type "System.String" to type "System.Management.Automation.Scr
> iptBlock".
> At 
> D:\Work_Ksu\Platform_tests\WebApplication1\packages\Apache.Ignite.1.8.1\tools\Install.ps1:33
>  char:37
> + $binDir = ($_.Properties | Where   Name -match OutputPath).Value
> + CategoryInfo  : InvalidArgument: (:) [Where-Object], 
> ParameterBindingException
> + FullyQualifiedErrorId : 
> CannotConvertArgumentNoMessage,Microsoft.PowerShell.Commands.WhereObjectCommand
>  
> Welcome to Apache Ignite.NET!
> Successfully installed 'Apache.Ignite 1.8.1' to WebApplication1
> PM> 
> PM> Uninstall-Package Apache.Ignite
> Attempting to gather dependency information for package 'Apache.Ignite.1.8.1' 
> with respect to project 'WebApplication1', targeting 
> '.NETFramework,Version=v4.5.2'
> Resolving actions to uninstall package 'Apache.Ignite.1.8.1'
> Resolved actions to uninstall package 'Apache.Ignite.1.8.1'
> Executing script file 
> 'D:\Work_Ksu\Platform_tests\WebApplication1\packages\Apache.Ignite.1.8.1\tools\Uninstall.ps1'
> Where-Object : Cannot bind parameter 'FilterScript'. Cannot convert the 
> "Name" value of type "System.String" to type "System.Management.Automation.Scr
> iptBlock".
> At 
> D:\Work_Ksu\Platform_tests\WebApplication1\packages\Apache.Ignite.1.8.1\tools\Uninstall.ps1:29
>  char:37
> + $binDir = ($_.Properties | Where   Name -match OutputPath).Value
> + CategoryInfo  : InvalidArgument: (:) [Where-Object], 
> ParameterBindingException
> + FullyQualifiedErrorId : 
> CannotConvertArgumentNoMessage,Microsoft.PowerShell.Commands.WhereObjectCommand
>  
> Where-Object : Cannot bind parameter 'FilterScript'. Cannot convert the 
> "Name" value of type "System.String" to type "System.Management.Automation.Scr
> iptBlock".
> At 
> D:\Work_Ksu\Platform_tests\WebApplication1\packages\Apache.Ignite.1.8.1\tools\Uninstall.ps1:29
>  char:37
> + $binDir = ($_.Properties | Where   Name -match OutputPath).Value
> + CategoryInfo  : InvalidArgument: (:) [Where-Object], 
> ParameterBindingException
> + FullyQualifiedErrorId : 
> CannotConvertArgumentNoMessage,Microsoft.PowerShell.Commands.WhereObjectCommand
>  
> Removed package 

[jira] [Updated] (IGNITE-4430) .NET: Cannot convert the "Name" value of type "System.String" to type "System.Management.Automation.ScriptBlock"

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-4430:
---
Summary: .NET: Cannot convert the "Name" value of type "System.String" to 
type "System.Management.Automation.ScriptBlock"  (was: .NET: Cannot convert the 
"Name" value of type "System.String" to type "System.Management.Automation.Scr 
iptBlock")

> .NET: Cannot convert the "Name" value of type "System.String" to type 
> "System.Management.Automation.ScriptBlock"
> 
>
> Key: IGNITE-4430
> URL: https://issues.apache.org/jira/browse/IGNITE-4430
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.8
>Reporter: Ksenia Rybakova
>Priority: Minor
>
> Environment:
> - Windows7
> - VS 2015
> - NuGet Package Manager 3.4.4
> - Powershell version
> {noformat}
> PS C:\Users\San> $PSVersionTable.PSVersion
> Major  Minor  Build  Revision
> -  -  -  
> 2  0  -1 -1
> {noformat}
> While installing/uninstalling Apache.Ignite package the following exception 
> occurs
> {noformat}
> PM> Install-Package Apache.Ignite -Source 
> https://www.myget.org/F/apache-ignite-staging/api/v2 -Version 1.8.1
> Attempting to gather dependency information for package 'Apache.Ignite.1.8.1' 
> with respect to project 'WebApplication1', targeting 
> '.NETFramework,Version=v4.5.2'
> Attempting to resolve dependencies for package 'Apache.Ignite.1.8.1' with 
> DependencyBehavior 'Lowest'
> Resolving actions to install package 'Apache.Ignite.1.8.1'
> Resolved actions to install package 'Apache.Ignite.1.8.1'
> Adding package 'Apache.Ignite.1.8.1' to folder 
> 'D:\Work_Ksu\Platform_tests\WebApplication1\packages'
> Added package 'Apache.Ignite.1.8.1' to folder 
> 'D:\Work_Ksu\Platform_tests\WebApplication1\packages'
> Added package 'Apache.Ignite.1.8.1' to 'packages.config'
> Executing script file 
> 'D:\Work_Ksu\Platform_tests\WebApplication1\packages\Apache.Ignite.1.8.1\tools\Install.ps1'
> Updating project properties...
> Where-Object : Cannot bind parameter 'FilterScript'. Cannot convert the 
> "Name" value of type "System.String" to type "System.Management.Automation.Scr
> iptBlock".
> At 
> D:\Work_Ksu\Platform_tests\WebApplication1\packages\Apache.Ignite.1.8.1\tools\Install.ps1:33
>  char:37
> + $binDir = ($_.Properties | Where   Name -match OutputPath).Value
> + CategoryInfo  : InvalidArgument: (:) [Where-Object], 
> ParameterBindingException
> + FullyQualifiedErrorId : 
> CannotConvertArgumentNoMessage,Microsoft.PowerShell.Commands.WhereObjectCommand
>  
> Where-Object : Cannot bind parameter 'FilterScript'. Cannot convert the 
> "Name" value of type "System.String" to type "System.Management.Automation.Scr
> iptBlock".
> At 
> D:\Work_Ksu\Platform_tests\WebApplication1\packages\Apache.Ignite.1.8.1\tools\Install.ps1:33
>  char:37
> + $binDir = ($_.Properties | Where   Name -match OutputPath).Value
> + CategoryInfo  : InvalidArgument: (:) [Where-Object], 
> ParameterBindingException
> + FullyQualifiedErrorId : 
> CannotConvertArgumentNoMessage,Microsoft.PowerShell.Commands.WhereObjectCommand
>  
> Welcome to Apache Ignite.NET!
> Successfully installed 'Apache.Ignite 1.8.1' to WebApplication1
> PM> 
> PM> Uninstall-Package Apache.Ignite
> Attempting to gather dependency information for package 'Apache.Ignite.1.8.1' 
> with respect to project 'WebApplication1', targeting 
> '.NETFramework,Version=v4.5.2'
> Resolving actions to uninstall package 'Apache.Ignite.1.8.1'
> Resolved actions to uninstall package 'Apache.Ignite.1.8.1'
> Executing script file 
> 'D:\Work_Ksu\Platform_tests\WebApplication1\packages\Apache.Ignite.1.8.1\tools\Uninstall.ps1'
> Where-Object : Cannot bind parameter 'FilterScript'. Cannot convert the 
> "Name" value of type "System.String" to type "System.Management.Automation.Scr
> iptBlock".
> At 
> D:\Work_Ksu\Platform_tests\WebApplication1\packages\Apache.Ignite.1.8.1\tools\Uninstall.ps1:29
>  char:37
> + $binDir = ($_.Properties | Where   Name -match OutputPath).Value
> + CategoryInfo  : InvalidArgument: (:) [Where-Object], 
> ParameterBindingException
> + FullyQualifiedErrorId : 
> CannotConvertArgumentNoMessage,Microsoft.PowerShell.Commands.WhereObjectCommand
>  
> Where-Object : Cannot bind parameter 'FilterScript'. Cannot convert the 
> "Name" value of type "System.String" to type "System.Management.Automation.Scr
> iptBlock".
> At 
> D:\Work_Ksu\Platform_tests\WebApplication1\packages\Apache.Ignite.1.8.1\tools\Uninstall.ps1:29
>  char:37
> + $binDir = ($_.Properties | Where   Name -match OutputPath).Value
> + CategoryInfo  : InvalidArgument: (:) [Where-Object], 
> 

[jira] [Commented] (IGNITE-4477) Fix IgniteFuture.listen() and IgniteFuture.chain() semantics

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-4477:
-

More correct approach to this would be:
{code}
IgniteFuture listen(Closure); // Executed synchronously or in completion thread
IgniteFuture listenAsync(Closure); // Always async
IgniteFuture listenAsync(Closure, Executor);

IgniteFuture chain(...);
IgniteFuture chainAsync(Closure);
IgniteFuture chainAsync(Closure, Executor);
{code}

> Fix IgniteFuture.listen() and IgniteFuture.chain() semantics
> 
>
> Key: IGNITE-4477
> URL: https://issues.apache.org/jira/browse/IGNITE-4477
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>
> *Problem*
> We allow users to pass continuations to {{IgniteFuture}} which will be 
> executed on future completion. This can be done through {{listen}} or 
> {{chain}} methods.
> However, continuation semantics is broken intrinsically:
> 1) If future is already completed, user code executed in the same thread;
> 2) If future is not completed yet, it will be executed in completion thread.
> Neither of this options are valid because it easily leads to starvation. E.g.:
> {code}
> IgniteFuture fut = cache.getAsync(key2);
> fut.listen(fut0 -> {
>  cache.put(key2, val2); // Possible deadlock, because invoked in sys pool;
> });
> {code}
> *Solution*
> 1) By default callbacks must be executed asynchronously in some common pool 
> (public pool? new "callback pool"? FJP?)
> 2) It should be possible to specify where to execute a callback explicitly:
> {code}
> IgniteFuture.listen(IgniteClosure, ExecutorService);
> {code}
> 3) We may want to expose our public pool on API for convenience.



--
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=15769805#comment-15769805
 ] 

Oleg Ostanin commented on IGNITE-4212:
--

I divided original task into three smaller subtasks to resolve each step 
individually. 

> 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] [Created] (IGNITE-4482) Part of IGNITE-4212

[Oleg Ostanin (JIRA)]

Oleg Ostanin created IGNITE-4482:


 Summary: Part of IGNITE-4212
 Key: IGNITE-4482
 URL: https://issues.apache.org/jira/browse/IGNITE-4482
 Project: Ignite
  Issue Type: Sub-task
Reporter: Oleg Ostanin
Assignee: Oleg Ostanin


The goal of this subtask is to resolve the last part of original task:

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-4457) Define cache plugin API in .NET

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4457:


GitHub user ptupitsyn opened a pull request:

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

IGNITE-4457 Define cache plugin API in .NET



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

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

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

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


commit 8001c3838e2b13edaf8fe159b3a98691b6110089
Author: Pavel Tupitsyn 
Date:   2016-12-22T11:09:01Z

IGNITE-4457 Define cache plugin API in .NET




> 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] [Created] (IGNITE-4481) Part of IGNITE-4212

[Oleg Ostanin (JIRA)]

Oleg Ostanin created IGNITE-4481:


 Summary: Part of IGNITE-4212
 Key: IGNITE-4481
 URL: https://issues.apache.org/jira/browse/IGNITE-4481
 Project: Ignite
  Issue Type: Sub-task
Reporter: Oleg Ostanin
Assignee: Oleg Ostanin


The goal of this subtask is to resolve this part of original task:

Every deliverable must contain an executable (bat or sh file) with a clear 
instruction on how to start a specific benchmark from the console.



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

[jira] [Created] (IGNITE-4480) Incorrect cancellation semantics in IgniteFuture.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-4480:
---

 Summary: Incorrect cancellation semantics in IgniteFuture.
 Key: IGNITE-4480
 URL: https://issues.apache.org/jira/browse/IGNITE-4480
 Project: Ignite
  Issue Type: Task
  Components: general
Affects Versions: 1.8
Reporter: Vladimir Ozerov
 Fix For: 2.0


*Problem*
Normally, if user invoke "cancel()" on future, he expects that it will be 
completed immediately. E.g. this is how JDK {{CompletableFuture}} works. 
However, this is not the case for Ignite - we inform user about cancellation 
through flag, which is also not set properly in most cases.

*Solution*
1) {{cancel()}} must complete future with special "CancellationException" 
immediately.
2) {{isCancelled()}} method should be either removed or deprecated.
3{ We should add {{isCompletedExceptionally()}} method which will return 
{{true}} in case future was completed with any kind of exception. This will 
work similar to JDK {{CompletableFuture}}.



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

[jira] [Created] (IGNITE-4479) Remove startTime() and duration() methods from IgniteFuture

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-4479:
---

 Summary: Remove startTime() and duration() methods from 
IgniteFuture
 Key: IGNITE-4479
 URL: https://issues.apache.org/jira/browse/IGNITE-4479
 Project: Ignite
  Issue Type: Task
  Components: general
Affects Versions: 1.8
Reporter: Vladimir Ozerov
 Fix For: 2.0


These methods are of no use for users and should not be in future API. THe only 
place where they are used is cache exchange manager. 

We should remove these methods form all futures and leave them only for cache 
exchange logic.



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

[jira] [Created] (IGNITE-4478) Part of IGNITE-4212

[Oleg Ostanin (JIRA)]

Oleg Ostanin created IGNITE-4478:


 Summary: Part of IGNITE-4212
 Key: IGNITE-4478
 URL: https://issues.apache.org/jira/browse/IGNITE-4478
 Project: Ignite
  Issue Type: Sub-task
Reporter: Oleg Ostanin
Assignee: Oleg Ostanin


The goal of this subtask is to resolve the first part of original task:

Ignite-yardstick benchmarks have to be pre-compiled and available with every 
Ignite deliverable.

We need to create "benchmarks" folder and put it under the root of an Apache 
Ignite distribution. The structure of this folder is shown below.
apache_ignite_root_folder
– bin
– examples
...
– benchmarks
— bin (contains scripts needed to run the benchmarks)
— src (contains benchmarks sources and a pom.xml in order to create a project 
in an IDE instantaneously)
— config (configs for amazon and well as for local benchmarks execution)
— libs (compiled and ready-to-run benchmarks)
— README.txt (instructions how to run the benchmarks)



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

[jira] [Created] (IGNITE-4477) Fix IgniteFuture.listen() and IgniteFuture.chain() semantics

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-4477:
---

 Summary: Fix IgniteFuture.listen() and IgniteFuture.chain() 
semantics
 Key: IGNITE-4477
 URL: https://issues.apache.org/jira/browse/IGNITE-4477
 Project: Ignite
  Issue Type: Task
  Components: general
Affects Versions: 1.8
Reporter: Vladimir Ozerov
 Fix For: 2.0


*Problem*
We allow users to pass continuations to {{IgniteFuture}} which will be executed 
on future completion. This can be done through {{listen}} or {{chain}} methods.
However, continuation semantics is broken intrinsically:
1) If future is already completed, user code executed in the same thread;
2) If future is not completed yet, it will be executed in completion thread.
Neither of this options are valid because it easily leads to starvation. E.g.:
{code}
IgniteFuture fut = cache.getAsync(key2);

fut.listen(fut0 -> {
 cache.put(key2, val2); // Possible deadlock, because invoked in sys pool;
});
{code}

*Solution*
1) By default callbacks must be executed asynchronously in some common pool 
(public pool? new "callback pool"? FJP?)
2) It should be possible to specify where to execute a callback explicitly:
{code}
IgniteFuture.listen(IgniteClosure, ExecutorService);
{code}
3) We may want to expose our public pool on API for convenience.



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

[jira] [Created] (IGNITE-4476) GridIoManger must always process messages asynchronously

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-4476:
---

 Summary: GridIoManger must always process messages asynchronously
 Key: IGNITE-4476
 URL: https://issues.apache.org/jira/browse/IGNITE-4476
 Project: Ignite
  Issue Type: Task
  Components: general
Affects Versions: 1.8
Reporter: Vladimir Ozerov
 Fix For: 2.0


*Problem*
If message is to be sent to remote node, we just send it (surprise :-)). But if 
message is to be sent to local node, we have a strange "optimization" - we 
process it synchronously in the same thread. 
This is wrong as it easily leads to all kind of weird starvations and deadlocks.

*Solution*
Never ever process messages synchronously. For local node we should put message 
runnable into appropriate thread pool and exit.




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

[jira] [Created] (IGNITE-4475) Simplify async API

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-4475:
---

 Summary: 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
 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.



--
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=15769703#comment-15769703
 ] 

Pavel Tupitsyn commented on IGNITE-4457:


Can't add tests for invalid cache providers due to IGNITE-4474

> 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] [Created] (IGNITE-4474) Ignite.createCache hangs on exception in CachePluginConfiguration.createProvider

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-4474:
--

 Summary: Ignite.createCache hangs on exception in 
CachePluginConfiguration.createProvider
 Key: IGNITE-4474
 URL: https://issues.apache.org/jira/browse/IGNITE-4474
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 1.8
Reporter: Pavel Tupitsyn
Priority: Minor
 Fix For: 2.0


When there is an exception during provider initialization, {{createCache}} 
hangs.

{code}
public class CacheCfg implements CachePluginConfiguration {
@Override public CachePluginProvider createProvider(CachePluginContext ctx) 
{
throw new IgniteException("foo");
}
}
{code}



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

[jira] [Created] (IGNITE-4473) Client should re-try connection attempt in case of concurrent network failure

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-4473:
---

 Summary: Client should re-try connection attempt in case of 
concurrent network failure
 Key: IGNITE-4473
 URL: https://issues.apache.org/jira/browse/IGNITE-4473
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 1.8
Reporter: Vladimir Ozerov
 Fix For: 2.0


*Problem*
Consider the following scenario:
1) Client started, but there are no servers, so it hangs somewhere inside start 
routine.
2) Server appears, and discovery finishes successfully.
3) Nodes start talking to each other through communication SPI to finish start 
process (e.g. to complete exchange).
4) But network glitch occurs and server becomes unreachable.

*Expected behavior*
Client disconnects and hangs waiting for reconnect.

*Actual behavior*
Client throws an exception and never tries to reconnect.



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4248:


Github user AMashenkov closed the pull request at:

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


> 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] [Commented] (IGNITE-4436) SQL: create API to collect list of running SQL queries

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov commented on IGNITE-4436:
--

I think it make sense to collect only "long running" queries.
User could specify time in milliseconds (say 3000 by default) and we could 
collect only such queries.

> SQL: create API to collect list of running SQL queries
> --
>
> Key: IGNITE-4436
> URL: https://issues.apache.org/jira/browse/IGNITE-4436
> Project: Ignite
>  Issue Type: Task
>  Components: SQL
>Affects Versions: 1.8
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
> Fix For: 2.0
>
>
> It may be very useful for monitoring tools to be able to collect list of 
> currently running SQL queries with possibility to cancel them.
> See discussion on dev list for more info: 
> http://apache-ignite-developers.2346864.n4.nabble.com/API-to-collect-list-of-running-SQL-queries-td13031.html



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

[jira] [Assigned] (IGNITE-4436) SQL: create API to collect list of running SQL queries

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-4436:


Assignee: Alexey Kuznetsov

> SQL: create API to collect list of running SQL queries
> --
>
> Key: IGNITE-4436
> URL: https://issues.apache.org/jira/browse/IGNITE-4436
> Project: Ignite
>  Issue Type: Task
>  Components: SQL
>Affects Versions: 1.8
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
> Fix For: 2.0
>
>
> It may be very useful for monitoring tools to be able to collect list of 
> currently running SQL queries with possibility to cancel them.
> See discussion on dev list for more info: 
> http://apache-ignite-developers.2346864.n4.nabble.com/API-to-collect-list-of-running-SQL-queries-td13031.html



--
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=15769588#comment-15769588
 ] 

Igor Sapego commented on IGNITE-4230:
-

Denis, I hope to finish today. Unfortunately, I've faced an issue when I was 
working on this ticket, which blocked me from finishing it faster - 
IGNITE-4471. Once Its done I will assign it to you for review.

> 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] [Updated] (IGNITE-2793) ODBC: Add support for Arrays.

[Igor Sapego (JIRA)]

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

Igor Sapego updated IGNITE-2793:

Assignee: (was: Igor Sapego)

> 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
>  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] [Closed] (IGNITE-4098) Spilled map-reduce: reduce side.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-4098.
---

> Spilled map-reduce: reduce side.
> 
>
> Key: IGNITE-4098
> URL: https://issues.apache.org/jira/browse/IGNITE-4098
> Project: Ignite
>  Issue Type: Sub-task
>  Components: hadoop
>Affects Versions: 1.6
>Reporter: Ivan Veselovsky
>Assignee: Ivan Veselovsky
> Fix For: 2.0
>
>
> Implement spilling data on the reducers side.



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

[jira] [Resolved] (IGNITE-4037) High memory consumption when executing TeraSort Hadoop example

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov resolved IGNITE-4037.
-
Resolution: Won't Fix

> High memory consumption when executing TeraSort Hadoop example
> --
>
> Key: IGNITE-4037
> URL: https://issues.apache.org/jira/browse/IGNITE-4037
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Ivan Veselovsky
>Assignee: Vladimir Ozerov
> Fix For: 2.0
>
>
> When executing TeraSort Hadoop example, we observe high memory consumption 
> that frequently leads to cluster malfunction.
> The problem can be reproduced in unit test, even with 1 node, and with not 
> huge input data set as 100Mb. 
> Dump analysis shows that  memory is taken in various queues: 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopExecutorService#queue
>  
> and 
> task queue of 
> org.apache.ignite.internal.processors.hadoop.jobtracker.HadoopJobTracker#evtProcSvc
>   .
> Since objects stored in these queues hold byte arrays of significant size, 
> memory if consumed very fast.
> It looks like real cause of the problem is that some tasks are blocked.



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

[jira] [Closed] (IGNITE-4037) High memory consumption when executing TeraSort Hadoop example

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-4037.
---

> High memory consumption when executing TeraSort Hadoop example
> --
>
> Key: IGNITE-4037
> URL: https://issues.apache.org/jira/browse/IGNITE-4037
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Ivan Veselovsky
>Assignee: Vladimir Ozerov
> Fix For: 2.0
>
>
> When executing TeraSort Hadoop example, we observe high memory consumption 
> that frequently leads to cluster malfunction.
> The problem can be reproduced in unit test, even with 1 node, and with not 
> huge input data set as 100Mb. 
> Dump analysis shows that  memory is taken in various queues: 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopExecutorService#queue
>  
> and 
> task queue of 
> org.apache.ignite.internal.processors.hadoop.jobtracker.HadoopJobTracker#evtProcSvc
>   .
> Since objects stored in these queues hold byte arrays of significant size, 
> memory if consumed very fast.
> It looks like real cause of the problem is that some tasks are blocked.



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

[jira] [Resolved] (IGNITE-4098) Spilled map-reduce: reduce side.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov resolved IGNITE-4098.
-
Resolution: Won't Fix

Won't fix for now as it might incur unacceptable performance penalty.

> Spilled map-reduce: reduce side.
> 
>
> Key: IGNITE-4098
> URL: https://issues.apache.org/jira/browse/IGNITE-4098
> Project: Ignite
>  Issue Type: Sub-task
>  Components: hadoop
>Affects Versions: 1.6
>Reporter: Ivan Veselovsky
>Assignee: Ivan Veselovsky
> Fix For: 2.0
>
>
> Implement spilling data on the reducers side.



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

[jira] [Assigned] (IGNITE-4037) High memory consumption when executing TeraSort Hadoop example

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-4037:
---

Assignee: Vladimir Ozerov  (was: Ivan Veselovsky)

> High memory consumption when executing TeraSort Hadoop example
> --
>
> Key: IGNITE-4037
> URL: https://issues.apache.org/jira/browse/IGNITE-4037
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Ivan Veselovsky
>Assignee: Vladimir Ozerov
> Fix For: 2.0
>
>
> When executing TeraSort Hadoop example, we observe high memory consumption 
> that frequently leads to cluster malfunction.
> The problem can be reproduced in unit test, even with 1 node, and with not 
> huge input data set as 100Mb. 
> Dump analysis shows that  memory is taken in various queues: 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopExecutorService#queue
>  
> and 
> task queue of 
> org.apache.ignite.internal.processors.hadoop.jobtracker.HadoopJobTracker#evtProcSvc
>   .
> Since objects stored in these queues hold byte arrays of significant size, 
> memory if consumed very fast.
> It looks like real cause of the problem is that some tasks are blocked.



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

[jira] [Assigned] (IGNITE-4097) Spilled map-reduce: map side.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-4097:
---

Assignee: Vladimir Ozerov  (was: Ivan Veselovsky)

> Spilled map-reduce: map side.
> -
>
> Key: IGNITE-4097
> URL: https://issues.apache.org/jira/browse/IGNITE-4097
> Project: Ignite
>  Issue Type: Sub-task
>  Components: hadoop
>Affects Versions: 1.6
>Reporter: Ivan Veselovsky
>Assignee: Vladimir Ozerov
>
> Implement spilled output on Map side of map-reduce.
> In general, algorithm should follow the one used in Hadoop. The difference on 
> the Map side is that 
> 1) we use sorting collection (Hadoop sorts a range of map outputs explicitly);
> 2) we store the map output in files not using FileSystem , but rather local 
> files.



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

[jira] [Resolved] (IGNITE-4097) Spilled map-reduce: map side.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov resolved IGNITE-4097.
-
Resolution: Won't Fix

Won't fix for now as it might incur unacceptable performance penalty.

> Spilled map-reduce: map side.
> -
>
> Key: IGNITE-4097
> URL: https://issues.apache.org/jira/browse/IGNITE-4097
> Project: Ignite
>  Issue Type: Sub-task
>  Components: hadoop
>Affects Versions: 1.6
>Reporter: Ivan Veselovsky
>Assignee: Vladimir Ozerov
>
> Implement spilled output on Map side of map-reduce.
> In general, algorithm should follow the one used in Hadoop. The difference on 
> the Map side is that 
> 1) we use sorting collection (Hadoop sorts a range of map outputs explicitly);
> 2) we store the map output in files not using FileSystem , but rather local 
> files.



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

[Sergey Chugunov (JIRA)]

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

Sergey Chugunov commented on IGNITE-4325:
-

[~dmagda], I created this jira as a subtask under [IGNITE-4157] as an attempt 
to split big task into series of a smaller ones.
I'll close this ticket as soon as parent jira is moved to resolved status. In 
fact parent was already reviewed and now I'm working on some comments from the 
[review|http://reviews.ignite.apache.org/ignite/review/IGNT-CR-35].

> 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] [Updated] (IGNITE-4392) Web Console: Implement support of management role

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov updated IGNITE-4392:
---
Description: 
In current implementation we have following roles: user and admins.
We need one more role: manager - this role will allow to view admin panel, but 
all other actions: delete users and giving admin rights to other users should 
be disabled.

Also need to add a column 'Role' on admin panel.

  was:
In current implementation we have following roles: user and admins.
We need one more role: manager - this role will allow to view admin panel, but 
all other actions: delete users and giving admin rights to other users should 
be disabled.


> Web Console: Implement support of management role
> -
>
> Key: IGNITE-4392
> URL: https://issues.apache.org/jira/browse/IGNITE-4392
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Affects Versions: 1.8
>Reporter: Alexey Kuznetsov
> Fix For: 2.0
>
>
> In current implementation we have following roles: user and admins.
> We need one more role: manager - this role will allow to view admin panel, 
> but all other actions: delete users and giving admin rights to other users 
> should be disabled.
> Also need to add a column 'Role' on admin panel.



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