[jira] [Updated] (IGNITE-5229) Specify caches when using Redis protocol

[Roman Shtykh (JIRA)]

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

Roman Shtykh updated IGNITE-5229:
-
Description: 
Currently there's no way to switch caches -- all requests go to 'default'.
_Note that this is the switch needed only for a subset of Redis data structures 
(currently only STRINGs) -- for SETs and HASHTABLEs caches will be specified as 
keys (see IGNITE-5241)_

As an idea, we can use {{CONFIG SET parameter value}} to set the current cache, 
save it in {{GridRestProcessor}} and use it until the user switches to another 
one.

  was:
Currently there's no way to switch caches -- all requests go to 'default'.
_Note that this is the switch for only a subset of Redis data structures 
(currently only STRINGs) -- for SETs and HASHTABLEs caches will be specified as 
keys (see IGNITE-5241)_

As an idea, we can use {{CONFIG SET parameter value}} to set the current cache, 
save it in {{GridRestProcessor}} and use it until the user switches to another 
one.


> Specify caches when using Redis protocol
> 
>
> Key: IGNITE-5229
> URL: https://issues.apache.org/jira/browse/IGNITE-5229
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>
> Currently there's no way to switch caches -- all requests go to 'default'.
> _Note that this is the switch needed only for a subset of Redis data 
> structures (currently only STRINGs) -- for SETs and HASHTABLEs caches will be 
> specified as keys (see IGNITE-5241)_
> As an idea, we can use {{CONFIG SET parameter value}} to set the current 
> cache, save it in {{GridRestProcessor}} and use it until the user switches to 
> another one.



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

[jira] [Updated] (IGNITE-5229) Specify caches when using Redis protocol

[Roman Shtykh (JIRA)]

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

Roman Shtykh updated IGNITE-5229:
-
Description: 
Currently there's no way to switch caches -- all requests go to 'default'.
_Note that this is the switch for only a subset of Redis data structures 
(currently only STRINGs) -- for SETs and HASHTABLEs caches will be specified as 
keys (see IGNITE-5241)_

As an idea, we can use {{CONFIG SET parameter value}} to set the current cache, 
save it in {{GridRestProcessor}} and use it until the user switches to another 
one.

  was:
Currently there's no way to switch caches -- all requests go to 'default'.
_Note that this is the switch for only a subset of Redis data structures 
(currently only STRINGs) -- for SETs and HASHTABLEs caches will be specified as 
keys (see https://issues.apache.org/jira/browse/IGNITE-5241)_

As an idea, we can use {{CONFIG SET parameter value}} to set the current cache, 
save it in {{GridRestProcessor}} and use it until the user switches to another 
one.


> Specify caches when using Redis protocol
> 
>
> Key: IGNITE-5229
> URL: https://issues.apache.org/jira/browse/IGNITE-5229
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>
> Currently there's no way to switch caches -- all requests go to 'default'.
> _Note that this is the switch for only a subset of Redis data structures 
> (currently only STRINGs) -- for SETs and HASHTABLEs caches will be specified 
> as keys (see IGNITE-5241)_
> As an idea, we can use {{CONFIG SET parameter value}} to set the current 
> cache, save it in {{GridRestProcessor}} and use it until the user switches to 
> another one.



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

[jira] [Updated] (IGNITE-5229) Specify caches when using Redis protocol

[Roman Shtykh (JIRA)]

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

Roman Shtykh updated IGNITE-5229:
-
Description: 
Currently there's no way to switch caches -- all requests go to 'default'.
_Note that this is the switch for only a subset of Redis data structures 
(currently only STRINGs) -- for SETs and HASHTABLEs caches will be specified as 
keys (see https://issues.apache.org/jira/browse/IGNITE-5241)_

As an idea, we can use {{CONFIG SET parameter value}} to set the current cache, 
save it in {{GridRestProcessor}} and use it until the user switches to another 
one.

  was:
Currently there's no way to switch caches -- all requests go to 'default'.
_Note that this is the switch for only a subset of Redis data structures 
(currently only STRINGs) -- for SETs and HASHTABLEs caches will be specified as 
keys (see )_

As an idea, we can use {{CONFIG SET parameter value}} to set the current cache, 
save it in {{GridRestProcessor}} and use it until the user switches to another 
one.


> Specify caches when using Redis protocol
> 
>
> Key: IGNITE-5229
> URL: https://issues.apache.org/jira/browse/IGNITE-5229
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>
> Currently there's no way to switch caches -- all requests go to 'default'.
> _Note that this is the switch for only a subset of Redis data structures 
> (currently only STRINGs) -- for SETs and HASHTABLEs caches will be specified 
> as keys (see https://issues.apache.org/jira/browse/IGNITE-5241)_
> As an idea, we can use {{CONFIG SET parameter value}} to set the current 
> cache, save it in {{GridRestProcessor}} and use it until the user switches to 
> another one.



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

[jira] [Created] (IGNITE-5241) Redis hash table support

[Roman Shtykh (JIRA)]

Roman Shtykh created IGNITE-5241:


 Summary: Redis hash table support
 Key: IGNITE-5241
 URL: https://issues.apache.org/jira/browse/IGNITE-5241
 Project: Ignite
  Issue Type: New Feature
Reporter: Roman Shtykh
Assignee: Roman Shtykh






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

[jira] [Updated] (IGNITE-5240) Web console: Invalid docker repository name in compose file

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko updated IGNITE-5240:
--
Description: 
in docker/compose/docker-compose.yml

Optimize test dependencies end exclude them in build process.

  was:in docker/compose/docker-compose.yml


> Web console: Invalid docker repository name in compose file
> ---
>
> Key: IGNITE-5240
> URL: https://issues.apache.org/jira/browse/IGNITE-5240
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vasiliy Sisko
>Assignee: Vasiliy Sisko
>
> in docker/compose/docker-compose.yml
> Optimize test dependencies end exclude them in build process.



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

[jira] [Updated] (IGNITE-5229) Specify caches when using Redis protocol

[Roman Shtykh (JIRA)]

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

Roman Shtykh updated IGNITE-5229:
-
Description: 
Currently there's no way to switch caches -- all requests go to 'default'.
_Note that this is the switch for only a subset of Redis data structures 
(currently only STRINGs) -- for SETs and HASHTABLEs caches will be specified as 
keys (see )_

As an idea, we can use {{CONFIG SET parameter value}} to set the current cache, 
save it in {{GridRestProcessor}} and use it until the user switches to another 
one.

  was:
Currently there's no way to switch caches -- all requests go to 'default'.
_Note that this is the switch for only a subset of Redis data structures -- for 
SETs and HASHTABLEs caches will be specified as keys (see )_

As an idea, we can use {{CONFIG SET parameter value}} to set the current cache, 
save it in {{GridRestProcessor}} and use it until the user switches to another 
one.


> Specify caches when using Redis protocol
> 
>
> Key: IGNITE-5229
> URL: https://issues.apache.org/jira/browse/IGNITE-5229
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>
> Currently there's no way to switch caches -- all requests go to 'default'.
> _Note that this is the switch for only a subset of Redis data structures 
> (currently only STRINGs) -- for SETs and HASHTABLEs caches will be specified 
> as keys (see )_
> As an idea, we can use {{CONFIG SET parameter value}} to set the current 
> cache, save it in {{GridRestProcessor}} and use it until the user switches to 
> another one.



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

[jira] [Updated] (IGNITE-5229) Specify caches when using Redis protocol

[Roman Shtykh (JIRA)]

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

Roman Shtykh updated IGNITE-5229:
-
Description: 
Currently there's no way to switch caches -- all requests go to 'default'.
_Note that this is the switch for only a subset of Redis data structures -- for 
SETs and HASHTABLEs caches will be specified as keys (see )_

As an idea, we can use {{CONFIG SET parameter value}} to set the current cache, 
save it in {{GridRestProcessor}} and use it until the user switches to another 
one.

  was:
Currently there's no way to switch caches -- all requests go to 'default'.
_Note that this is the switch for only a subset of Redis data structures -- for 
SETs and HASHTABLEs caches will be specified as keys (see )

As an idea, we can use {{CONFIG SET parameter value}} to set the current cache, 
save it in {{GridRestProcessor}} and use it until the user switches to another 
one.


> Specify caches when using Redis protocol
> 
>
> Key: IGNITE-5229
> URL: https://issues.apache.org/jira/browse/IGNITE-5229
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>
> Currently there's no way to switch caches -- all requests go to 'default'.
> _Note that this is the switch for only a subset of Redis data structures -- 
> for SETs and HASHTABLEs caches will be specified as keys (see )_
> As an idea, we can use {{CONFIG SET parameter value}} to set the current 
> cache, save it in {{GridRestProcessor}} and use it until the user switches to 
> another one.



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

[jira] [Updated] (IGNITE-5229) Specify caches when using Redis protocol

[Roman Shtykh (JIRA)]

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

Roman Shtykh updated IGNITE-5229:
-
Description: 
Currently there's no way to switch caches -- all requests go to 'default'.
_Note that this is the switch for only a subset of Redis data structures -- for 
SETs and HASHTABLEs caches will be specified as keys (see )

As an idea, we can use {{CONFIG SET parameter value}} to set the current cache, 
save it in {{GridRestProcessor}} and use it until the user switches to another 
one.

  was:
Currently there's no way to switch caches -- all requests go to 'default'.

As an idea, we can use {{CONFIG SET parameter value}} to set the current cache, 
save it in {{GridRestProcessor}} and use it until the user switches to another 
one.


> Specify caches when using Redis protocol
> 
>
> Key: IGNITE-5229
> URL: https://issues.apache.org/jira/browse/IGNITE-5229
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>
> Currently there's no way to switch caches -- all requests go to 'default'.
> _Note that this is the switch for only a subset of Redis data structures -- 
> for SETs and HASHTABLEs caches will be specified as keys (see )
> As an idea, we can use {{CONFIG SET parameter value}} to set the current 
> cache, save it in {{GridRestProcessor}} and use it until the user switches to 
> another one.



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

[jira] [Created] (IGNITE-5240) Web console: Invalid docker repository name in compose file

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-5240:
-

 Summary: Web console: Invalid docker repository name in compose 
file
 Key: IGNITE-5240
 URL: https://issues.apache.org/jira/browse/IGNITE-5240
 Project: Ignite
  Issue Type: Bug
Reporter: Vasiliy Sisko
Assignee: Vasiliy Sisko


in docker/compose/docker-compose.yml



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

[jira] [Created] (IGNITE-5239) Web Console: Add an option to show full stack trace on Queries screen

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-5239:


 Summary: Web Console: Add an option to show full stack trace on 
Queries screen
 Key: IGNITE-5239
 URL: https://issues.apache.org/jira/browse/IGNITE-5239
 Project: Ignite
  Issue Type: Task
  Components: UI, wizards
Affects Versions: 2.0
Reporter: Alexey Kuznetsov
 Fix For: 2.1


In some situations we need full stack trace to show real error like: 
{code}
Caused by: org.postgresql.util.PSQLException: ERROR: update or delete on table 
"city" violates foreign key constraint "country_capital_fkey" on table "country"
  Detail: Key (id)=(3503) is still referenced from table "country".
{code}



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

[jira] [Created] (IGNITE-5238) Ignite Spark can't be used with Ignite REST

[Denis Magda (JIRA)]

Denis Magda created IGNITE-5238:
---

 Summary: Ignite Spark can't be used with Ignite REST
 Key: IGNITE-5238
 URL: https://issues.apache.org/jira/browse/IGNITE-5238
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.0
Reporter: Denis Magda
Priority: Blocker
 Fix For: 2.1


{{ignite-rest-http}} can't be used together with {{ignite-spark}} because the 
former imports some legacy version of Jackson library and the following 
exception is thrown from an IDEA in attempt to use Ignite+Spark application:

{code}
Exception in thread "main" java.lang.ExceptionInInitializerError
at org.apache.spark.SparkContext.withScope(SparkContext.scala:701)
at org.apache.spark.SparkContext.parallelize(SparkContext.scala:715)
at 
org.apache.spark.api.java.JavaSparkContext.parallelizePairs(JavaSparkContext.scala:153)
at 
org.apache.spark.api.java.JavaSparkContext.parallelizePairs(JavaSparkContext.scala:158)
at 
org.apache.ignite.iot.SparkStreamerStartup.preloadSensorsData(SparkStreamerStartup.java:123)
at 
org.apache.ignite.iot.SparkStreamerStartup.main(SparkStreamerStartup.java:96)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
Caused by: com.fasterxml.jackson.databind.JsonMappingException: Incompatible 
Jackson version: 2.8.8
at 
com.fasterxml.jackson.module.scala.JacksonModule$class.setupModule(JacksonModule.scala:64)
at 
com.fasterxml.jackson.module.scala.DefaultScalaModule.setupModule(DefaultScalaModule.scala:19)
at 
com.fasterxml.jackson.databind.ObjectMapper.registerModule(ObjectMapper.java:745)
at 
org.apache.spark.rdd.RDDOperationScope$.(RDDOperationScope.scala:82)
at 
org.apache.spark.rdd.RDDOperationScope$.(RDDOperationScope.scala)
... 11 more
{code}

To reproduce:
- Download this project and open in IntellijIdea: 
https://github.com/dmagda/IgniteSparkIoT
- Go to pom.xml and uncomment {{ignite-rest-http}} module. It has to be 
imported.
- Start a cluster node with IgniteNodeStartup
- Start SparkStreamerStartup and you will get the error above.

Looks like the Ignite REST module has to be upgraded to the recent Jackson 
version.



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

[jira] [Comment Edited] (IGNITE-602) [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by infinite recursion

[Andrey Gura (JIRA)]

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

Andrey Gura edited comment on IGNITE-602 at 5/16/17 5:51 PM:
-

[~SomeFire], I don't like that for every reference type instance 
{{ObjectWithPosition}} object will be created. It creates additional redundant 
pressure to GC. Also it seems that list is inappropriate data structure for 
reference tracking because it requires {{O( n)}} operation in order to check 
whether object is saved or not. It seems that {{IdentityHashMap}} is better 
choice for this purpose.


was (Author: agura):
[~SomeFire], I don't like that for every reference type instance 
{{ObjectWithPosition}} object will be created. It creates additional redundant 
pressure to GC. Also it seems that list is inappropriate data structure for 
reference tracking because it requires {{O(n)}} operation in order to check 
whether object is saved or not. It seems that {{IdentityHashMap}} is better 
choice for this purpose.

> [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by 
> infinite recursion
> 
>
> Key: IGNITE-602
> URL: https://issues.apache.org/jira/browse/IGNITE-602
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Artem Shutak
>Assignee: Ryabov Dmitrii
>  Labels: Muted_test
> Fix For: 2.1
>
>
> See test 
> org.gridgain.grid.util.tostring.GridToStringBuilderSelfTest#_testToStringCheckAdvancedRecursionPrevention
>  and related TODO in same source file.
> Also take a look at 
> http://stackoverflow.com/questions/11300203/most-efficient-way-to-prevent-an-infinite-recursion-in-tostring
> Test should be unmuted on TC after fix.
> see GG-5000.



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

[jira] [Commented] (IGNITE-602) [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by infinite recursion

[Andrey Gura (JIRA)]

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

Andrey Gura commented on IGNITE-602:


[~SomeFire], I don't like that for every reference type instance 
{{ObjectWithPosition}} object will be created. It creates additional redundant 
pressure to GC. Also it seems that list is inappropriate data structure for 
reference tracking because it requires O(n) operation in order to check whether 
object is saved or not. It seems that {{IdentityHashMap}} is better choice for 
this purpose.

> [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by 
> infinite recursion
> 
>
> Key: IGNITE-602
> URL: https://issues.apache.org/jira/browse/IGNITE-602
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Artem Shutak
>Assignee: Ryabov Dmitrii
>  Labels: Muted_test
> Fix For: 2.1
>
>
> See test 
> org.gridgain.grid.util.tostring.GridToStringBuilderSelfTest#_testToStringCheckAdvancedRecursionPrevention
>  and related TODO in same source file.
> Also take a look at 
> http://stackoverflow.com/questions/11300203/most-efficient-way-to-prevent-an-infinite-recursion-in-tostring
> Test should be unmuted on TC after fix.
> see GG-5000.



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

[jira] [Comment Edited] (IGNITE-602) [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by infinite recursion

[Andrey Gura (JIRA)]

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

Andrey Gura edited comment on IGNITE-602 at 5/16/17 5:50 PM:
-

[~SomeFire], I don't like that for every reference type instance 
{{ObjectWithPosition}} object will be created. It creates additional redundant 
pressure to GC. Also it seems that list is inappropriate data structure for 
reference tracking because it requires {{O(n)}} operation in order to check 
whether object is saved or not. It seems that {{IdentityHashMap}} is better 
choice for this purpose.


was (Author: agura):
[~SomeFire], I don't like that for every reference type instance 
{{ObjectWithPosition}} object will be created. It creates additional redundant 
pressure to GC. Also it seems that list is inappropriate data structure for 
reference tracking because it requires O(n) operation in order to check whether 
object is saved or not. It seems that {{IdentityHashMap}} is better choice for 
this purpose.

> [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by 
> infinite recursion
> 
>
> Key: IGNITE-602
> URL: https://issues.apache.org/jira/browse/IGNITE-602
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Artem Shutak
>Assignee: Ryabov Dmitrii
>  Labels: Muted_test
> Fix For: 2.1
>
>
> See test 
> org.gridgain.grid.util.tostring.GridToStringBuilderSelfTest#_testToStringCheckAdvancedRecursionPrevention
>  and related TODO in same source file.
> Also take a look at 
> http://stackoverflow.com/questions/11300203/most-efficient-way-to-prevent-an-infinite-recursion-in-tostring
> Test should be unmuted on TC after fix.
> see GG-5000.



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

[jira] [Updated] (IGNITE-4406) .NET: Control DateTime serialization via attribute

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-4406:
---
Description: 
.NET can write DateTime in internal format (preserves DateTime.Kind) and as 
Timestamp (does not allow non-UTC values).

By default we use internal format. To use Timestamp user has to mark field with 
QuerySqlField (non obvious), or override IBinarizable.

* Provide a dedicated attribute to enforce timestamp mode.
* Attribute can be applied to a field, property, or a whole type
* Provide a property on {{BinaryReflectiveSerializer}} to force Timestamp 
everywhere - this may be needed when class code can't be modified

  was:
.NET can write DateTime in internal format (preserves DateTime.Kind) and as 
Timestamp (does not allow non-UTC values).

By default we use internal format. To use Timestamp user has to mark field with 
QuerySqlField (non obvious), or override IBinarizable.

Provide a dedicated attribute to enforce timestamp mode.


> .NET: Control DateTime serialization via attribute
> --
>
> Key: IGNITE-4406
> URL: https://issues.apache.org/jira/browse/IGNITE-4406
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
>  Labels: .NET
> Fix For: 2.1
>
>
> .NET can write DateTime in internal format (preserves DateTime.Kind) and as 
> Timestamp (does not allow non-UTC values).
> By default we use internal format. To use Timestamp user has to mark field 
> with QuerySqlField (non obvious), or override IBinarizable.
> * Provide a dedicated attribute to enforce timestamp mode.
> * Attribute can be applied to a field, property, or a whole type
> * Provide a property on {{BinaryReflectiveSerializer}} to force Timestamp 
> everywhere - this may be needed when class code can't be modified



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

[jira] [Resolved] (IGNITE-5050) .NET: IIgnite.GetMemoryMetrics

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn resolved IGNITE-5050.

Resolution: Fixed

> .NET: IIgnite.GetMemoryMetrics
> --
>
> Key: IGNITE-5050
> URL: https://issues.apache.org/jira/browse/IGNITE-5050
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.1
>
>
> Add {{IIgnite.GetMemoryMetrics()}} in .NET which delegates to 
> {{Ignite.memoryMetrics()}} in Java



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

[jira] [Comment Edited] (IGNITE-5050) .NET: IIgnite.GetMemoryMetrics

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn edited comment on IGNITE-5050 at 5/16/17 4:36 PM:
-

Merged to master: {{73fc01c4f021854e3fdc5c9a3bfe9a0650a77055}}.

Added:
* {{IIgnite.GetMemoryMetrics()}}
* {{MemoryPolicyConfiguration.MetricsEnabled}}


was (Author: ptupitsyn):
Merged to master: {{73fc01c4f021854e3fdc5c9a3bfe9a0650a77055}}.

> .NET: IIgnite.GetMemoryMetrics
> --
>
> Key: IGNITE-5050
> URL: https://issues.apache.org/jira/browse/IGNITE-5050
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.1
>
>
> Add {{IIgnite.GetMemoryMetrics()}} in .NET which delegates to 
> {{Ignite.memoryMetrics()}} in Java



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

[jira] [Commented] (IGNITE-5050) .NET: IIgnite.GetMemoryMetrics

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-5050:


Merged to master: {{73fc01c4f021854e3fdc5c9a3bfe9a0650a77055}}.

> .NET: IIgnite.GetMemoryMetrics
> --
>
> Key: IGNITE-5050
> URL: https://issues.apache.org/jira/browse/IGNITE-5050
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.1
>
>
> Add {{IIgnite.GetMemoryMetrics()}} in .NET which delegates to 
> {{Ignite.memoryMetrics()}} in Java



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

[jira] [Created] (IGNITE-5237) JDBC Driver: support client info

[Taras Ledkov (JIRA)]

Taras Ledkov created IGNITE-5237:


 Summary: JDBC Driver: support client info
 Key: IGNITE-5237
 URL: https://issues.apache.org/jira/browse/IGNITE-5237
 Project: Ignite
  Issue Type: Task
  Components: sql
Affects Versions: 2.0
Reporter: Taras Ledkov
Assignee: Taras Ledkov
 Fix For: 2.1






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

[jira] [Created] (IGNITE-5236) JDBC Driver: implement Connection.isValid througn PING message

[Taras Ledkov (JIRA)]

Taras Ledkov created IGNITE-5236:


 Summary: JDBC Driver: implement Connection.isValid througn PING 
message
 Key: IGNITE-5236
 URL: https://issues.apache.org/jira/browse/IGNITE-5236
 Project: Ignite
  Issue Type: Task
  Components: sql
Affects Versions: 2.0
Reporter: Taras Ledkov
Assignee: Taras Ledkov
 Fix For: 2.1






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

[jira] [Created] (IGNITE-5235) JDBC Driver: impelemnt prepared statement

[Taras Ledkov (JIRA)]

Taras Ledkov created IGNITE-5235:


 Summary: JDBC Driver: impelemnt prepared statement
 Key: IGNITE-5235
 URL: https://issues.apache.org/jira/browse/IGNITE-5235
 Project: Ignite
  Issue Type: Task
  Components: sql
Affects Versions: 2.0
Reporter: Taras Ledkov
Assignee: Taras Ledkov
 Fix For: 2.1






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

[jira] [Created] (IGNITE-5234) JDBC Driver: support connection and query timeout

[Taras Ledkov (JIRA)]

Taras Ledkov created IGNITE-5234:


 Summary: JDBC Driver: support connection and query timeout
 Key: IGNITE-5234
 URL: https://issues.apache.org/jira/browse/IGNITE-5234
 Project: Ignite
  Issue Type: Task
  Components: sql
Affects Versions: 2.0
Reporter: Taras Ledkov
Assignee: Taras Ledkov
 Fix For: 2.1






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

[jira] [Created] (IGNITE-5233) JDBC Driver: implement metadata support

[Taras Ledkov (JIRA)]

Taras Ledkov created IGNITE-5233:


 Summary: JDBC Driver: implement metadata support 
 Key: IGNITE-5233
 URL: https://issues.apache.org/jira/browse/IGNITE-5233
 Project: Ignite
  Issue Type: Task
  Components: sql
Affects Versions: 2.0
Reporter: Taras Ledkov
Assignee: Taras Ledkov
 Fix For: 2.1






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

[jira] [Commented] (IGNITE-5052) Implement CREATE/DROP TABLE parsing and execution

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko commented on IGNITE-5052:
-

1, 2, 4, 5, 6, 8, 9 - fixed.
3, 7 - WIP.
10 - need advice from Semyon and probably yourself, Vlad, I will contact both 
of you additionally.

> Implement CREATE/DROP TABLE parsing and execution
> -
>
> Key: IGNITE-5052
> URL: https://issues.apache.org/jira/browse/IGNITE-5052
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
>  Labels: important
> Fix For: 2.1
>
>
> Convert SQL string to relevant Igntie command. This could be:
> - {{createCache}}
> - {{getOrCreateCache}} (for {{IF NOT EXISTS}} case)
> - {{destroyCache}}



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

[jira] [Commented] (IGNITE-5104) Refactor javadocs and annotations to single style

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-5104:
-

Hi Nikita, I will review the changes in the nearest couple of days.

> Refactor javadocs and annotations to single style
> -
>
> Key: IGNITE-5104
> URL: https://issues.apache.org/jira/browse/IGNITE-5104
> Project: Ignite
>  Issue Type: Task
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Trivial
>
> According to Ignite codestyle:
> We should use a shorter version of {@inheritDoc} when it possible.
> Annotations @Nullable and @Override should be placed on one line with declare 
> of method.



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

[jira] [Updated] (IGNITE-4763) doSetRollbackOnly method to be implemented in SpringTransactionManager

[Andrey Gura (JIRA)]

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

Andrey Gura updated IGNITE-4763:

Fix Version/s: 2.1

> doSetRollbackOnly method to be implemented in SpringTransactionManager
> --
>
> Key: IGNITE-4763
> URL: https://issues.apache.org/jira/browse/IGNITE-4763
> Project: Ignite
>  Issue Type: Bug
>  Components: spring
>Affects Versions: 1.8
>Reporter: Sumanta Ghosh
>Assignee: Amelchev Nikita
>  Labels: newbie, patch
> Fix For: 2.1
>
>
> This issue is raised in continuation with the message posted in ignite user 
> forum 
> (http://apache-ignite-users.70518.x6.nabble.com/SpringTransactionManager-Participating-in-existing-transactions-is-not-supported-td7305.html#a10624).
>  Since the doSetRollBackOnly method is not implemented in 
> SpringTransactionManager, it is not being possible to integrate with spring 
> data's ChainedTransactionManager class. A simple fix (below) would work it 
> seems (however, I did not yet tested with proper rollback test cases though, 
> this implementation at least get rid of the exception chainedtransaction 
> manager raises)
> @Override 
> protected void doSetRollbackOnly(DefaultTransactionStatus status) 
> throws TransactionException { 
> Transaction txn = 
> ((Ignite)this.getResourceFactory()).transactions().tx(); 
> if (txn!=null) txn.setRollbackOnly(); 
> }
> NOTE: This is the first time I am raising issues in apache. So, apologies if 
> all the details are not proper.



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

[jira] [Commented] (IGNITE-4763) doSetRollbackOnly method to be implemented in SpringTransactionManager

[Andrey Gura (JIRA)]

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

Andrey Gura commented on IGNITE-4763:
-

Hi, Nikita,

First of all thank you for contribution!

I've looked at your PR and have only one comment. Why do you check reference to 
the tx on {{null}} value? It seems that transaction should always be 
non-{{null}}. Otherwise is implementation error. May be it would be better just 
assert that {{tx}} doesn't equal {{null}}?

> doSetRollbackOnly method to be implemented in SpringTransactionManager
> --
>
> Key: IGNITE-4763
> URL: https://issues.apache.org/jira/browse/IGNITE-4763
> Project: Ignite
>  Issue Type: Bug
>  Components: spring
>Affects Versions: 1.8
>Reporter: Sumanta Ghosh
>Assignee: Amelchev Nikita
>  Labels: newbie, patch
>
> This issue is raised in continuation with the message posted in ignite user 
> forum 
> (http://apache-ignite-users.70518.x6.nabble.com/SpringTransactionManager-Participating-in-existing-transactions-is-not-supported-td7305.html#a10624).
>  Since the doSetRollBackOnly method is not implemented in 
> SpringTransactionManager, it is not being possible to integrate with spring 
> data's ChainedTransactionManager class. A simple fix (below) would work it 
> seems (however, I did not yet tested with proper rollback test cases though, 
> this implementation at least get rid of the exception chainedtransaction 
> manager raises)
> @Override 
> protected void doSetRollbackOnly(DefaultTransactionStatus status) 
> throws TransactionException { 
> Transaction txn = 
> ((Ignite)this.getResourceFactory()).transactions().tx(); 
> if (txn!=null) txn.setRollbackOnly(); 
> }
> NOTE: This is the first time I am raising issues in apache. So, apologies if 
> all the details are not proper.



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

[jira] [Assigned] (IGNITE-3562) Dependency to outdated Lucene 3.5.0

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov reassigned IGNITE-3562:


Assignee: Andrew Mashenkov  (was: Evgenii Zhuravlev)

> Dependency to outdated Lucene 3.5.0
> ---
>
> Key: IGNITE-3562
> URL: https://issues.apache.org/jira/browse/IGNITE-3562
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.6
>Reporter: Alexander Veit
>Assignee: Andrew Mashenkov
>  Labels: jar-hell
> Fix For: 2.1
>
>
> Ignite 1.6.0 comes with Lucene 3.5.0 core as dependency, which dates back to 
> the year 2011.
> This makes it difficult to integrate with newer software.



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

[jira] [Commented] (IGNITE-4831) Add an option to disable MBeans

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4831:


GitHub user rfqu opened a pull request:

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

IGNITE-4831 fixed (Add an option to disable MBeans).



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

$ git pull https://github.com/rfqu/ignite ignite-4831

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

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


commit d4fe48d417548739b60a4ccbd5c24fb3e85f6346
Author: rfqu 
Date:   2017-05-16T14:48:37Z

IGNITE-4831 fixed (Add an option to disable MBeans).




> Add an option to disable MBeans
> ---
>
> Key: IGNITE-4831
> URL: https://issues.apache.org/jira/browse/IGNITE-4831
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.8
>Reporter: Valentin Kulichenko
>
> There are multiple MBeans registered by Ignite and there is no way to avoid 
> their registration (in case they're not allowed for security reasons for 
> example). We should have a system property that will disable MBeans.
> In addition, if MBean registration throws a {{RuntimeException}}, this 
> exception is not properly handled. For example, if it happens during cache 
> creation, {{createCache}} method hangs forever.



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

[jira] [Comment Edited] (IGNITE-4496) Review all logging for sensitive data leak

[Semen Boikov (JIRA)]

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

Semen Boikov edited comment on IGNITE-4496 at 5/16/17 3:01 PM:
---

Hi Alexandr,

When I do diff with master it shows that there are lots of files where there 
are no changes except line separators, can you fix this? (e.g. 
AffinityKey.java).

Also diff shows empty files added: GridCacheSwapEntryImpl.java, 
OdbcQueryExecuteRequest.java.

GridCacheStoreManagerAdapter: why key is not sensitive here:
{noformat}
log.debug(S.toString("Loaded value from store",
"key", key, false,
"val", val, true));
{noformat}

Thanks


was (Author: sboikov):
Hi Alexandr,

When I do diff master it shows that lots of files where there are no changes 
except line separators, can you fix this? (e.g. AffinityKey.java).

Also diff shows empty files added: GridCacheSwapEntryImpl.java, 
OdbcQueryExecuteRequest.java.

GridCacheStoreManagerAdapter: why key is not sensitive here:
{noformat}
log.debug(S.toString("Loaded value from store",
"key", key, false,
"val", val, true));
{noformat}

Thanks

> Review all logging for sensitive data leak
> --
>
> Key: IGNITE-4496
> URL: https://issues.apache.org/jira/browse/IGNITE-4496
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexandr Kuramshin
>Assignee: Alexandr Kuramshin
>
> While sensitive logging option added and toString() methods fixed, not all 
> logging was checked for sensitive data leak



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

[jira] [Assigned] (IGNITE-4496) Review all logging for sensitive data leak

[Semen Boikov (JIRA)]

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

Semen Boikov reassigned IGNITE-4496:


Assignee: Alexandr Kuramshin  (was: Semen Boikov)

Hi Alexandr,

When I do diff master it shows that lots of files where there are no changes 
except line separators, can you fix this? (e.g. AffinityKey.java).

Also diff shows empty files added: GridCacheSwapEntryImpl.java, 
OdbcQueryExecuteRequest.java.

GridCacheStoreManagerAdapter: why key is not sensitive here:
{noformat}
log.debug(S.toString("Loaded value from store",
"key", key, false,
"val", val, true));
{noformat}

Thanks

> Review all logging for sensitive data leak
> --
>
> Key: IGNITE-4496
> URL: https://issues.apache.org/jira/browse/IGNITE-4496
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexandr Kuramshin
>Assignee: Alexandr Kuramshin
>
> While sensitive logging option added and toString() methods fixed, not all 
> logging was checked for sensitive data leak



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

[jira] [Updated] (IGNITE-5227) StackOverflowError in GridCacheMapEntry#checkOwnerChanged()

[Mikhail Cherkasov (JIRA)]

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

Mikhail Cherkasov updated IGNITE-5227:
--
Description: 
A simple test reproducing this error:
{code}
/**
 * @throws Exception if failed.
 */
public void testBatchUnlock() throws Exception {
   startGrid(0);
   grid(0).createCache(new CacheConfiguration(DEFAULT_CACHE_NAME)
.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL));

try {
final CountDownLatch releaseLatch = new CountDownLatch(1);

IgniteInternalFuture fut = GridTestUtils.runAsync(new 
Callable() {
@Override public Object call() throws Exception {
IgniteCache cache = grid(0).cache(null);

Lock lock = cache.lock("key");

try {
lock.lock();

releaseLatch.await();
}
finally {
lock.unlock();
}

return null;
}
});

Map putMap = new LinkedHashMap<>();

putMap.put("key", "trigger");

for (int i = 0; i < 10_000; i++)
putMap.put("key-" + i, "value");

IgniteCache asyncCache = 
grid(0).cache(null).withAsync();

asyncCache.putAll(putMap);

IgniteFuture resFut = asyncCache.future();

Thread.sleep(1000);

releaseLatch.countDown();

fut.get();

resFut.get();
}
finally {
stopAllGrids();
}
{code}
We should replace a recursive call with a simple iteration over the linked list.

  was:
A simple test reproducing this error:
{code}
/**
 * @throws Exception if failed.
 */
public void testBatchUnlock() throws Exception {
startGrid(0);

try {
final CountDownLatch releaseLatch = new CountDownLatch(1);

IgniteInternalFuture fut = GridTestUtils.runAsync(new 
Callable() {
@Override public Object call() throws Exception {
IgniteCache cache = grid(0).cache(null);

Lock lock = cache.lock("key");

try {
lock.lock();

releaseLatch.await();
}
finally {
lock.unlock();
}

return null;
}
});

Map putMap = new LinkedHashMap<>();

putMap.put("key", "trigger");

for (int i = 0; i < 10_000; i++)
putMap.put("key-" + i, "value");

IgniteCache asyncCache = 
grid(0).cache(null).withAsync();

asyncCache.putAll(putMap);

IgniteFuture resFut = asyncCache.future();

Thread.sleep(1000);

releaseLatch.countDown();

fut.get();

resFut.get();
}
finally {
stopAllGrids();
}
{code}
We should replace a recursive call with a simple iteration over the linked list.


> StackOverflowError in GridCacheMapEntry#checkOwnerChanged()
> ---
>
> Key: IGNITE-5227
> URL: https://issues.apache.org/jira/browse/IGNITE-5227
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Alexey Goncharuk
>Assignee: Mikhail Cherkasov
>Priority: Critical
> Fix For: 2.1
>
>
> A simple test reproducing this error:
> {code}
> /**
>  * @throws Exception if failed.
>  */
> public void testBatchUnlock() throws Exception {
>startGrid(0);
>grid(0).createCache(new CacheConfiguration Integer>(DEFAULT_CACHE_NAME)
> .setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL));
> try {
> final CountDownLatch releaseLatch = new CountDownLatch(1);
> IgniteInternalFuture fut = GridTestUtils.runAsync(new 
> Callable() {
> @Override public Object call() throws Exception {
> IgniteCache cache = grid(0).cache(null);
> Lock lock = cache.lock("key");
> try {
> lock.lock();
> releaseLatch.await();
> }
> finally {
> lock.unlock();
> }
> return null;
> }
> });
> Map putMap = new LinkedHashMap<>();
> putMap.put("key", "trigger");
> for (int i = 0; 

[jira] [Commented] (IGNITE-4205) CassandraCacheStore should start IgniteThread threads in loadCache() method

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko commented on IGNITE-4205:
-

Can you add test for it as well?

> CassandraCacheStore should start IgniteThread threads in loadCache() method
> ---
>
> Key: IGNITE-4205
> URL: https://issues.apache.org/jira/browse/IGNITE-4205
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Konstantin Dudkov
>
> {{CassandraCacheStore.loadCache()}} method starts a generic thread pool for 
> parallel data load. Threads in this thread pool can't deserialize Ignite 
> internal objects (e.g. {{IgniteKernal}}) which can cause unexpected behavior. 
> Here is one of the scenarios:
> * There is column in Cassandra which stores an object as BLOB using 
> {{JavaSerializer}}.
> * {{CacheConfiguration.storeKeepBinary}} is {{true}}.
> * When an object is saved, it's passed to the store as an instance of 
> {{BinaryObject}} which is converted to a byte array and saved in Cassandra.
> * When the same object is loaded in {{loadCache}}, the store takes the byte 
> array and tries to convert it to {{BinaryObject}}. But it can't because this 
> implies calling {{IgnitionEx.localIgnite()}} from non-Ignite thread.
> To fix this we need to provide a thread factory that will create instances of 
> {{IgniteThread}} and use it in the pool that loads the data.
> Most likely the same issue exists in {{CacheAbstractJdbcStore}}.
> And in general, any threads created by Ignite internals should be 
> {{IgniteThread}}-s. This should be revisited.



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

[jira] [Commented] (IGNITE-2313) Need to add a mode to fail atomic operations within a transaction

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov commented on IGNITE-2313:
--

[~SomeFire], looks good, but still there are some missed javadocs.
Fix it please, and ask Yakov to final review and merge to master.


> Need to add a mode to fail atomic operations within a transaction
> -
>
> Key: IGNITE-2313
> URL: https://issues.apache.org/jira/browse/IGNITE-2313
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Dmitriy Setrakyan
>Assignee: Ryabov Dmitrii
>Priority: Blocker
> Fix For: 2.1
>
>
> Currently atomic operations within a transaction succeed without alarming a 
> user that no transaction really occurs. We should add a mode to fail such 
> operations (such mode should be turned off by default).
> New transaction configuration flag (default is {{false}}):
> {code}TransactionConfiguration.isAllowAtomicUpdatesInTransaction(){code}
> If the flag is violated, we should throw an exception with the following 
> error message: {{Transaction spans operations on atomic cache (consider 
> setting TransactionConfiguration.isAllowAttomicUpdatesInTransaction() flag to 
> true)}}



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

[jira] [Commented] (IGNITE-5208) C++ Segfault on Put

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-5208:


[~isapego] looks good to me.

> C++ Segfault on Put
> ---
>
> Key: IGNITE-5208
> URL: https://issues.apache.org/jira/browse/IGNITE-5208
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Tolga HOŞGÖR
>Assignee: Igor Sapego
>Priority: Critical
>  Labels: c++
> Fix For: 2.1
>
>
> The following segfault happens when:
>   - using multiple caches (suffixed with number as in X_\{number\}),
>   - caches contain same type of object but not the same objects,
>   - doing multithreaded `::Put` operation, only one put is done on each cache 
> concurrently, independent caches (X_1, X_2, ...) can be operated on and 
> called `::Put` on concurrently, but that should not be relevant as cache api 
> is thread safe.
> {code:none}
> C  [test+0xf8116a]  std::less::operator()(int const&, int const&) 
> const+0x14
> C  [test+0x1106305]  std::_Rb_tree  >, std::_Select1st  > >, std::less, std::allocator  > > >::_M_lower_bound(std::_Rb_tree_node  > >*, std::_Rb_tree_node_base*, int const&)+0x41
> C  [test+0x1105a9d]  std::_Rb_tree  >, std::_Select1st  > >, std::less, std::allocator  > > >::find(int const&)+0x45
> C  [test+0x1104e7f]  std::map ignite::common::concurrent::SharedPointer,
>  std::less, std::allocator  > > >::find(int const&)+0x23
> C  [test+0x1104031]  
> ignite::impl::binary::BinaryTypeManager::GetHandler(std::__cxx11::basic_string  std::char_traits, std::allocator > const&, int)+0x6f
> C  [test+0xe6de2d]  void 
> ignite::impl::binary::BinaryWriterImpl::WriteTopObject  >(std::shared_ptr const&)+0xbb
> C  [test+0xe6cd48]  
> ignite::impl::In2Operation std::char_traits, std::allocator >, std::shared_ptr 
> >::ProcessInput(ignite::impl::binary::BinaryWriterImpl&)+0x3e
> C  [test+0x1128cf1]  
> ignite::impl::interop::InteropTarget::WriteTo(ignite::impl::interop::InteropMemory*,
>  ignite::impl::InputOperation&, ignite::IgniteError&)+0xa9
> C  [test+0x1128f67]  ignite::impl::interop::InteropTarget::OutOp(int, 
> ignite::impl::InputOperation&, ignite::IgniteError&)+0x65
> C  [test+0x1125f41]  
> ignite::impl::cache::CacheImpl::Put(ignite::impl::InputOperation&, 
> ignite::IgniteError&)+0x2d
> C  [test+0xe5539a]  ignite::cache::Cache std::char_traits, std::allocator >, std::shared_ptr 
> >::Put(std::__cxx11::basic_string std::allocator > const&, std::shared_ptr const&, 
> ignite::IgniteError&)+0x52
> {code}
> There seems to be some kind of race situation:
> {code:none}
> 0x01381206 in std::less::operator() (this=0x1a4e4b0, __x= reading variable>, __y=@0x7fff80846e04: 2066246303) at 
> /usr/include/c++/6.3.1/bits/stl_function.h:386
> {code}
> {code:none}
> #4  0x015040cd in ignite::impl::binary::BinaryTypeManager::GetHandler 
> (this=0x1a560d0, typeName="test.data", typeId=2066246303) at 
> src/impl/binary/binary_type_manager.cpp:56
> 56  std::map::iterator it = 
> snapshots0.find(typeId);
> (gdb) print snapshots0
> $10 = std::map with 42286576 elements = {[42312864] = {ptr = 0x285a4a0, impl 
> = 0x0}...}
> (gdb) print snapshot
> $11 = {ptr = 0x7fffda4f, impl = 0x11}
> {code}
> `impl` pointers seems to be corrupted on multiple places.



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

[jira] [Commented] (IGNITE-5097) BinaryMarshaller should write ints in "varint" encoding where it makes sense

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-5097:


[~isapego]
>  write length in varint, always using 4 bytes
Yep, that's what I meant above.

I think varlen makes sense for collection sizes. Things like {{string[]}}, 
{{int[]}}, {{byte[]}} can be quite common, and not necessary as an object field.

> BinaryMarshaller should write ints in "varint" encoding where it makes sense
> 
>
> Key: IGNITE-5097
> URL: https://issues.apache.org/jira/browse/IGNITE-5097
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 2.0
>Reporter: Vladimir Ozerov
>Assignee: Vyacheslav Daradur
>  Labels: important, performance
> Fix For: 2.1
>
>
> There are a lot of places in the code where we write integers for some 
> special purposes. Quite often their value will be vary small, so that 
> applying "varint" format could save a lot of space at the cost of very low 
> additional CPU overhead. 
> Specifically:
> 1) Array/collection/map lengths
> 2) BigDecimal's (usually will save ~6 bytes)
> 3) Strings
> 4) Enum ordinals



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

[jira] [Commented] (IGNITE-4575) Implement in Ignite wrapper for enums based on H2 user value type

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-4575:
-

[~skalashnikov], my comments:
1) {{BinaryClassDescriptor.enumMap}} - I am not sure this is correct place to 
store enum map, because it essentially duplicate to what is stored in metadata. 
I walked through it's usages, and it is only used in two places immediately 
after descriptor creation, so it is better to remove this field;
2) {{BinaryEnumObjectImpl.ctor}} - {{arr\[0\] == 
GridBinaryMarshaller.BINARY_ENUM}} looks wrong to me; you should pass only 
unwrapped array here, or array+offset, which points to start of real enum. See 
{{BinaryObjectImpl}} where the same idea is utilized.
3) {{BinaryEnumObjectImpl.enumName}} - as this method might be on hot paths, it 
should generate little to no garbage and be as lightweight as possible; it is 
better to expose some more internals to avoid {{BinaryMetadata -> BinaryType}} 
conversion.
4) {{BinaryEnumObjectImpl.enumName}} - IDEA shows me a warning about possible 
NPE in case type is null;
5) {{BinaryTypeImpl}} - cached values should be in {{BinaryMetadata}}, which is 
created only once, not in {{BinaryType}}, which can be created multiple times 
in different places
6) {{BinaryMetadata.VERSION}} - let's change it to byte, so that it will take 
only 1 byte instead of 4 (it will not change frequently)
7) {{BinaryMetadata.getEnumOrdinalByName}} - check for empty name is invalid 
here; empty or null names are not allowed, so we must thrown an exception, but 
not here, but rather somewhere in {{BinaryEnumObjectImpl}}.
8) {{BinaryWriteMode}} - I think {{BINARY_ENUM}} must be mapped to {{ENUM}} 
just like {{BinaryObjectImpl}} mapped to {{OBJ}} (see 
{{BINARY_OBJ(GridBinaryMarshaller.OBJ)}})
9) {{BinaryUtils.mergeMetadata}} - {{changed}} flag should be set to {{true}} 
only in case something really changed
10) {{BinaryWriterExImpl.doWriteBinaryEnum}} - if {{typeId != 
GridBinaryMarshaller.UNREGISTERED_TYPE_ID}} which is the most common case, we 
can unsafely allocate 9 bytes intead of 5, and write ordinal in unsafe manner 
as well

> Implement in Ignite wrapper for enums based on H2 user value type
> -
>
> Key: IGNITE-4575
> URL: https://issues.apache.org/jira/browse/IGNITE-4575
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Alexander Paschenko
>Assignee: Sergey Kalashnikov
>  Labels: important
> Fix For: 2.1
>
>




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

[jira] [Commented] (IGNITE-4947) Create AI 2.0 TC suites

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4947:


GitHub user dspavlov opened a pull request:

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

Ignite 4938 & IGNITE-4947: Fix AI 2.0 TC suites

Ignite 4938 & IGNITE-4947: Fix AI 2.0 TC suites

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

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

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

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


commit faa8681ab35e2332a7b16210492468495eb9518e
Author: Alexander Paschenko 
Date:   2017-04-10T16:47:17Z

IGNITE-4938 De-pub of OptimizedMarshaller - take 1

commit a3686db055a55c87484ebad04e37f13ad06f93ce
Author: Alexander Paschenko 
Date:   2017-04-11T11:43:48Z

Merge branch 'master' into ignite-4938

commit 7942d585fde3fd11964f479b0442caa2ba0459d1
Author: Alexander Paschenko 
Date:   2017-04-11T16:10:37Z

IGNITE-4938 De-pub of OptimizedMarshaller - take 2

commit 1115ca5f81dc1a729cc16bcffd6ad5697b82e319
Author: Alexander Paschenko 
Date:   2017-04-12T00:44:42Z

IGNITE-4938 OptimizedMarshaller de-pub take 3 - removed redundant test 
suites

commit c89cc392f6e9f3008707a532422e10ba12fe44f1
Author: Alexey Goncharuk 
Date:   2017-04-14T15:00:51Z

Merge branch 'master' of https://git-wip-us.apache.org/repos/asf/ignite 
into ignite-4938

Conflicts:
examples/config/filesystem/example-igfs.xml
modules/clients/src/test/config/jdbc-config.xml
modules/core/src/main/java/org/apache/ignite/IgniteSystemProperties.java
modules/core/src/main/java/org/apache/ignite/internal/IgniteKernal.java

modules/core/src/main/java/org/apache/ignite/internal/binary/BinaryClassDescriptor.java

modules/core/src/main/java/org/apache/ignite/internal/binary/BinaryContext.java

modules/core/src/main/java/org/apache/ignite/internal/client/marshaller/optimized/GridClientOptimizedMarshaller.java

modules/core/src/main/java/org/apache/ignite/internal/client/marshaller/optimized/GridClientZipOptimizedMarshaller.java

modules/core/src/main/java/org/apache/ignite/internal/marshaller/optimized/OptimizedClassDescriptor.java

modules/core/src/main/java/org/apache/ignite/internal/marshaller/optimized/OptimizedMarshaller.java

modules/core/src/main/java/org/apache/ignite/internal/marshaller/optimized/package-info.java
modules/core/src/main/java/org/apache/ignite/marshaller/Marshaller.java

modules/core/src/main/java/org/apache/ignite/marshaller/jdk/JdkMarshaller.java

modules/core/src/main/java/org/apache/ignite/marshaller/optimized/package-info.java
modules/core/src/main/resources/META-INF/classnames.properties
modules/core/src/test/config/example-cache.xml
modules/core/src/test/config/igfs-loopback.xml
modules/core/src/test/config/igfs-shmem.xml
modules/core/src/test/config/spring-start-nodes-attr.xml
modules/core/src/test/config/spring-start-nodes.xml
modules/core/src/test/config/websession/example-cache-base.xml

modules/core/src/test/java/org/apache/ignite/IgniteExternalizableAbstractTest.java

modules/core/src/test/java/org/apache/ignite/cache/store/jdbc/CacheJdbcPojoStoreOptimizedMarshallerSelfTest.java
modules/core/src/test/java/org/apache/ignite/igfs/IgfsPathSelfTest.java

modules/core/src/test/java/org/apache/ignite/internal/GridLifecycleAwareSelfTest.java

modules/core/src/test/java/org/apache/ignite/internal/managers/GridManagerStopSelfTest.java

modules/core/src/test/java/org/apache/ignite/internal/marshaller/optimized/package-info.java

modules/core/src/test/java/org/apache/ignite/internal/processors/cache/CacheStartupInDeploymentModesTest.java

modules/core/src/test/java/org/apache/ignite/internal/processors/cache/GridCacheEntryMemorySizeSelfTest.java

modules/core/src/test/java/org/apache/ignite/internal/processors/cache/GridCacheStoreManagerDeserializationTest.java

modules/core/src/test/java/org/apache/ignite/internal/processors/cache/GridCacheVersionSelfTest.java

modules/core/src/test/java/org/apache/ignite/internal/processors/cache/distributed/CacheAffinityEarlyTest.java

modules/core/src/test/java/org/apache/ignite/internal/processors/cache/distributed/CacheGetFutureHangsSelfTest.java

[jira] [Commented] (IGNITE-5100) Exchange queue is not used properly

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5100:


GitHub user zstan opened a pull request:

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

IGNITE-5100 don`t remove active exchange events from exchange list



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

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

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

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


commit f8157297707b30d6230e666752db3419b0a34b9f
Author: Evgeny Stanilovskiy 
Date:   2017-05-16T13:04:18Z

IGNITE-5100 don`t remove active exchange events from exchange list




> Exchange queue is not used properly
> ---
>
> Key: IGNITE-5100
> URL: https://issues.apache.org/jira/browse/IGNITE-5100
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.6
>Reporter: Alexei Scherbakov
>Assignee: Stanilovsky Evgeny
>Priority: Critical
> Fix For: 2.1
>
>
> Currently exchange futures share same queue for pending(incomplete) and 
> completed exchanges.
> The queue has fixed hardcoded size of 1000.
> This leads to a problem when > 1000 nodes try to enter grid.
> In such case oldest exchanges will be removed by ExchangeFutureSet size 
> limit, leading to whole exchange hanging.
> Solution: 
> 1. Use separate queues for pending and completed exchanges.
> 2. Pending exchange queue must be unbounded.
> 3. Add system property to control exchange history.



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

[jira] [Comment Edited] (IGNITE-5097) BinaryMarshaller should write ints in "varint" encoding where it makes sense

[Igor Sapego (JIRA)]

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

Igor Sapego edited comment on IGNITE-5097 at 5/16/17 1:07 PM:
--

Of course, we can still write length in varint, always using 4 bytes, often 
leaving first 3 bytes to be {{0x80}}. I'm just not sure, if this makes sense. 
If you consider that collection mostly containing objects, it means that most 
collections would take pretty much memory (single object header is 24 bytes 
long). So, does 3 at most bytes really make decent traffic saving in case of 
collections?


was (Author: isapego):
Of course, we can still write length in varint, always using 4 bytes, often 
leaving first 3 bytes to be {{0x80}}. I'm just not sure, if this makes sense. 
If you consider that collection mostly containing objects, it means that most 
collections would take pretty much memory (single object header is 24 bytes 
long). So, does 3 at most bytes really make decent traffic economy in case of 
collections?

> BinaryMarshaller should write ints in "varint" encoding where it makes sense
> 
>
> Key: IGNITE-5097
> URL: https://issues.apache.org/jira/browse/IGNITE-5097
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 2.0
>Reporter: Vladimir Ozerov
>Assignee: Vyacheslav Daradur
>  Labels: important, performance
> Fix For: 2.1
>
>
> There are a lot of places in the code where we write integers for some 
> special purposes. Quite often their value will be vary small, so that 
> applying "varint" format could save a lot of space at the cost of very low 
> additional CPU overhead. 
> Specifically:
> 1) Array/collection/map lengths
> 2) BigDecimal's (usually will save ~6 bytes)
> 3) Strings
> 4) Enum ordinals



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

[jira] [Commented] (IGNITE-5097) BinaryMarshaller should write ints in "varint" encoding where it makes sense

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-5097:
-

Of course, we can still write length in varint, always using 4 bytes, often 
leaving first 3 bytes to be {{0x80}}. I'm just not sure, if this makes sense. 
If you consider that collection mostly containing objects, it means that most 
collections would take pretty much memory (single object header is 24 bytes 
long). So, does 3 at most bytes really make decent traffic economy in case of 
collections?

> BinaryMarshaller should write ints in "varint" encoding where it makes sense
> 
>
> Key: IGNITE-5097
> URL: https://issues.apache.org/jira/browse/IGNITE-5097
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 2.0
>Reporter: Vladimir Ozerov
>Assignee: Vyacheslav Daradur
>  Labels: important, performance
> Fix For: 2.1
>
>
> There are a lot of places in the code where we write integers for some 
> special purposes. Quite often their value will be vary small, so that 
> applying "varint" format could save a lot of space at the cost of very low 
> additional CPU overhead. 
> Specifically:
> 1) Array/collection/map lengths
> 2) BigDecimal's (usually will save ~6 bytes)
> 3) Strings
> 4) Enum ordinals



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

[jira] [Commented] (IGNITE-5097) BinaryMarshaller should write ints in "varint" encoding where it makes sense

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-5097:
-

In Java collection are being written in *one* call, not in several steps, and 
with known size, so there is no such problem in Java.

{quote}
I guess we shoud just use varlen when possible, and reserve 4 bytes otherwise.
{quote}
The problem is, varint and int32 is not compatible.

> BinaryMarshaller should write ints in "varint" encoding where it makes sense
> 
>
> Key: IGNITE-5097
> URL: https://issues.apache.org/jira/browse/IGNITE-5097
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 2.0
>Reporter: Vladimir Ozerov
>Assignee: Vyacheslav Daradur
>  Labels: important, performance
> Fix For: 2.1
>
>
> There are a lot of places in the code where we write integers for some 
> special purposes. Quite often their value will be vary small, so that 
> applying "varint" format could save a lot of space at the cost of very low 
> additional CPU overhead. 
> Specifically:
> 1) Array/collection/map lengths
> 2) BigDecimal's (usually will save ~6 bytes)
> 3) Strings
> 4) Enum ordinals



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

[jira] [Resolved] (IGNITE-5191) .NET: BinaryEnum.ToString

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn resolved IGNITE-5191.

Resolution: Fixed

Fixed in master: {{256a4a3abd4683c86343a6ba9674b4612d7801de}}

> .NET: BinaryEnum.ToString
> -
>
> Key: IGNITE-5191
> URL: https://issues.apache.org/jira/browse/IGNITE-5191
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET, newbie
> Fix For: 2.1
>
>
> {{BinaryEnum}} should provide {{ToString}} overload.



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

[jira] [Commented] (IGNITE-4205) CassandraCacheStore should start IgniteThread threads in loadCache() method

[Konstantin Dudkov (JIRA)]

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

Konstantin Dudkov commented on IGNITE-4205:
---

I've fixed this issue in CacheAbstractJdbcStore too.

> CassandraCacheStore should start IgniteThread threads in loadCache() method
> ---
>
> Key: IGNITE-4205
> URL: https://issues.apache.org/jira/browse/IGNITE-4205
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Konstantin Dudkov
>
> {{CassandraCacheStore.loadCache()}} method starts a generic thread pool for 
> parallel data load. Threads in this thread pool can't deserialize Ignite 
> internal objects (e.g. {{IgniteKernal}}) which can cause unexpected behavior. 
> Here is one of the scenarios:
> * There is column in Cassandra which stores an object as BLOB using 
> {{JavaSerializer}}.
> * {{CacheConfiguration.storeKeepBinary}} is {{true}}.
> * When an object is saved, it's passed to the store as an instance of 
> {{BinaryObject}} which is converted to a byte array and saved in Cassandra.
> * When the same object is loaded in {{loadCache}}, the store takes the byte 
> array and tries to convert it to {{BinaryObject}}. But it can't because this 
> implies calling {{IgnitionEx.localIgnite()}} from non-Ignite thread.
> To fix this we need to provide a thread factory that will create instances of 
> {{IgniteThread}} and use it in the pool that loads the data.
> Most likely the same issue exists in {{CacheAbstractJdbcStore}}.
> And in general, any threads created by Ignite internals should be 
> {{IgniteThread}}-s. This should be revisited.



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

[jira] [Commented] (IGNITE-5208) C++ Segfault on Put

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5208:


GitHub user isapego opened a pull request:

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

IGNITE-5208: Fixed sigfault on concurrent map access.



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

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

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

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


commit 1cdd7926c92a552ef434326aa6bd0f785949e363
Author: Igor Sapego 
Date:   2017-05-16T11:55:43Z

IGNITE-5208: Fixed sigfault on concurrent map access




> C++ Segfault on Put
> ---
>
> Key: IGNITE-5208
> URL: https://issues.apache.org/jira/browse/IGNITE-5208
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Tolga HOŞGÖR
>Assignee: Igor Sapego
>Priority: Critical
>  Labels: c++
> Fix For: 2.1
>
>
> The following segfault happens when:
>   - using multiple caches (suffixed with number as in X_\{number\}),
>   - caches contain same type of object but not the same objects,
>   - doing multithreaded `::Put` operation, only one put is done on each cache 
> concurrently, independent caches (X_1, X_2, ...) can be operated on and 
> called `::Put` on concurrently, but that should not be relevant as cache api 
> is thread safe.
> {code:none}
> C  [test+0xf8116a]  std::less::operator()(int const&, int const&) 
> const+0x14
> C  [test+0x1106305]  std::_Rb_tree  >, std::_Select1st  > >, std::less, std::allocator  > > >::_M_lower_bound(std::_Rb_tree_node  > >*, std::_Rb_tree_node_base*, int const&)+0x41
> C  [test+0x1105a9d]  std::_Rb_tree  >, std::_Select1st  > >, std::less, std::allocator  > > >::find(int const&)+0x45
> C  [test+0x1104e7f]  std::map ignite::common::concurrent::SharedPointer,
>  std::less, std::allocator  > > >::find(int const&)+0x23
> C  [test+0x1104031]  
> ignite::impl::binary::BinaryTypeManager::GetHandler(std::__cxx11::basic_string  std::char_traits, std::allocator > const&, int)+0x6f
> C  [test+0xe6de2d]  void 
> ignite::impl::binary::BinaryWriterImpl::WriteTopObject  >(std::shared_ptr const&)+0xbb
> C  [test+0xe6cd48]  
> ignite::impl::In2Operation std::char_traits, std::allocator >, std::shared_ptr 
> >::ProcessInput(ignite::impl::binary::BinaryWriterImpl&)+0x3e
> C  [test+0x1128cf1]  
> ignite::impl::interop::InteropTarget::WriteTo(ignite::impl::interop::InteropMemory*,
>  ignite::impl::InputOperation&, ignite::IgniteError&)+0xa9
> C  [test+0x1128f67]  ignite::impl::interop::InteropTarget::OutOp(int, 
> ignite::impl::InputOperation&, ignite::IgniteError&)+0x65
> C  [test+0x1125f41]  
> ignite::impl::cache::CacheImpl::Put(ignite::impl::InputOperation&, 
> ignite::IgniteError&)+0x2d
> C  [test+0xe5539a]  ignite::cache::Cache std::char_traits, std::allocator >, std::shared_ptr 
> >::Put(std::__cxx11::basic_string std::allocator > const&, std::shared_ptr const&, 
> ignite::IgniteError&)+0x52
> {code}
> There seems to be some kind of race situation:
> {code:none}
> 0x01381206 in std::less::operator() (this=0x1a4e4b0, __x= reading variable>, __y=@0x7fff80846e04: 2066246303) at 
> /usr/include/c++/6.3.1/bits/stl_function.h:386
> {code}
> {code:none}
> #4  0x015040cd in ignite::impl::binary::BinaryTypeManager::GetHandler 
> (this=0x1a560d0, typeName="test.data", typeId=2066246303) at 
> src/impl/binary/binary_type_manager.cpp:56
> 56  std::map::iterator it = 
> snapshots0.find(typeId);
> (gdb) print snapshots0
> $10 = std::map with 42286576 elements = {[42312864] = {ptr = 0x285a4a0, impl 
> = 0x0}...}
> (gdb) print snapshot
> $11 = {ptr = 0x7fffda4f, impl = 0x11}
> {code}
> `impl` pointers seems to be corrupted on multiple places.



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

[jira] [Commented] (IGNITE-4205) CassandraCacheStore should start IgniteThread threads in loadCache() method

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko commented on IGNITE-4205:
-

I don't think it makes sense to separate these fixes. Can you fix the JDBC 
store in the same PR?

> CassandraCacheStore should start IgniteThread threads in loadCache() method
> ---
>
> Key: IGNITE-4205
> URL: https://issues.apache.org/jira/browse/IGNITE-4205
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Konstantin Dudkov
>
> {{CassandraCacheStore.loadCache()}} method starts a generic thread pool for 
> parallel data load. Threads in this thread pool can't deserialize Ignite 
> internal objects (e.g. {{IgniteKernal}}) which can cause unexpected behavior. 
> Here is one of the scenarios:
> * There is column in Cassandra which stores an object as BLOB using 
> {{JavaSerializer}}.
> * {{CacheConfiguration.storeKeepBinary}} is {{true}}.
> * When an object is saved, it's passed to the store as an instance of 
> {{BinaryObject}} which is converted to a byte array and saved in Cassandra.
> * When the same object is loaded in {{loadCache}}, the store takes the byte 
> array and tries to convert it to {{BinaryObject}}. But it can't because this 
> implies calling {{IgnitionEx.localIgnite()}} from non-Ignite thread.
> To fix this we need to provide a thread factory that will create instances of 
> {{IgniteThread}} and use it in the pool that loads the data.
> Most likely the same issue exists in {{CacheAbstractJdbcStore}}.
> And in general, any threads created by Ignite internals should be 
> {{IgniteThread}}-s. This should be revisited.



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

[jira] [Commented] (IGNITE-5050) .NET: IIgnite.GetMemoryMetrics

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-5050:


IGNITE-5072 fixed, there is now {{MemoryPolicyConfiguration.MetricsEnabled}}.

> .NET: IIgnite.GetMemoryMetrics
> --
>
> Key: IGNITE-5050
> URL: https://issues.apache.org/jira/browse/IGNITE-5050
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.1
>
>
> Add {{IIgnite.GetMemoryMetrics()}} in .NET which delegates to 
> {{Ignite.memoryMetrics()}} in Java



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

[jira] [Assigned] (IGNITE-5050) .NET: IIgnite.GetMemoryMetrics

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn reassigned IGNITE-5050:
--

Assignee: Pavel Tupitsyn

> .NET: IIgnite.GetMemoryMetrics
> --
>
> Key: IGNITE-5050
> URL: https://issues.apache.org/jira/browse/IGNITE-5050
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.1
>
>
> Add {{IIgnite.GetMemoryMetrics()}} in .NET which delegates to 
> {{Ignite.memoryMetrics()}} in Java



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

[jira] [Assigned] (IGNITE-5191) .NET: BinaryEnum.ToString

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn reassigned IGNITE-5191:
--

Assignee: Pavel Tupitsyn

> .NET: BinaryEnum.ToString
> -
>
> Key: IGNITE-5191
> URL: https://issues.apache.org/jira/browse/IGNITE-5191
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET, newbie
> Fix For: 2.1
>
>
> {{BinaryEnum}} should provide {{ToString}} overload.



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

[jira] [Assigned] (IGNITE-3275) .NET: Enable REST HTTP in .NET nodes

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn reassigned IGNITE-3275:
--

Assignee: Pavel Tupitsyn

> .NET: Enable REST HTTP in .NET nodes
> 
>
> Key: IGNITE-3275
> URL: https://issues.apache.org/jira/browse/IGNITE-3275
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
>  Labels: .net
> Fix For: 2.1
>
>
> * Include REST HTTP jars in NuGet (either in core, or in a separate package). 
> Keep in mind NuGet size limitation
> * Add required options to IgniteConfiguration to enable/disable REST 
> ({{ConnectorConfiguration}})



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

[jira] [Assigned] (IGNITE-4406) .NET: Control DateTime serialization via attribute

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn reassigned IGNITE-4406:
--

Assignee: Pavel Tupitsyn

> .NET: Control DateTime serialization via attribute
> --
>
> Key: IGNITE-4406
> URL: https://issues.apache.org/jira/browse/IGNITE-4406
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
>  Labels: .NET
> Fix For: 2.1
>
>
> .NET can write DateTime in internal format (preserves DateTime.Kind) and as 
> Timestamp (does not allow non-UTC values).
> By default we use internal format. To use Timestamp user has to mark field 
> with QuerySqlField (non obvious), or override IBinarizable.
> Provide a dedicated attribute to enforce timestamp mode.



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

[jira] [Updated] (IGNITE-2658) .NET: NHibernate Second Level Cache

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-2658:
---
Fix Version/s: (was: 2.1)

> .NET: NHibernate Second Level Cache
> ---
>
> Key: IGNITE-2658
> URL: https://issues.apache.org/jira/browse/IGNITE-2658
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>  Labels: .net
>
> http://nhibernate.info/blog/2009/02/09/quickly-setting-up-and-using-nhibernate-s-second-level-cache.html



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

[jira] [Updated] (IGNITE-3365) .NET: User-defined affinity mapper

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-3365:
---
Fix Version/s: (was: 2.1)

> .NET: User-defined affinity mapper
> --
>
> Key: IGNITE-3365
> URL: https://issues.apache.org/jira/browse/IGNITE-3365
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Pavel Tupitsyn
>  Labels: .net
>




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

[jira] [Updated] (IGNITE-3255) .NET: Script execution

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-3255:
---
Fix Version/s: (was: 2.1)

> .NET: Script execution
> --
>
> Key: IGNITE-3255
> URL: https://issues.apache.org/jira/browse/IGNITE-3255
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>  Labels: .net
>
> Introduce an ability to execute C# scripts on remote nodes.
> This may be useful for:
> * Diagnostics and debugging on live cluster
> * Quick try-out for computations
> * Demo purposes
> This is a light-weight alternative to IGNITE-2492: we don't have to deal with 
> automatically detecting whether assembly needs to be loaded remotely, with 
> it's dependencies and AppDomain lifecycle. 
> Instead, we send a string, compile it remotely, execute in a separate 
> AppDomain and unload it.



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

[jira] [Commented] (IGNITE-2190) ScanQuery without a filter triggers object's deserialization on the server side

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-2190:


Github user nizhikov closed the pull request at:

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


> ScanQuery without a filter triggers object's deserialization on the server 
> side
> ---
>
> Key: IGNITE-2190
> URL: https://issues.apache.org/jira/browse/IGNITE-2190
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Nikolay Izhikov
>Priority: Critical
>  Labels: newbie
> Fix For: 2.1
>
> Attachments: ScanQueryBug.java
>
>
> The issue is reproduced on version 1.4 where legacy PortableMarshaller is 
> used. However, I'm quiet sure that the issue happens when BinaryMarshaller is 
> used as well in 1.5.
> 1) Start a server using ignite.sh/bat
> 2) Create a simple app, that uses binary or portable marshaller, creates a 
> cache dynamically and executes a ScanQuery like below
> {{int size=employees1.query(new ScanQuery()).getAll().size();}}
> 3) As you see the query doesn't use any filters. However on the server side 
> some filter is still being checked 
> {{org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$5.checkPredicate(GridCacheQueryManager.java:963)}}
>  which makes the server to deserialize a value.
> According to the stack trace there is some internal filter that triggered 
> checkPredicate function - 
> filter=o.a.i.i.processors.cache.IgniteCacheProxy$1@3224ff7b.
> {noformat}
> [11:05:22,725][SEVERE][ignite-#25%sys-null%][GridCacheDistributedQueryManager]
>   Failed to run query [qry=GridCacheQueryInfo [loc=false, 
> trans=null, rdc=null, qry=GridCacheQueryAdapter [type=SCAN, clsName=null, 
> clause=null, filter=o.a.i.i.processors.cache.IgniteCacheProxy$1@3224ff7b, 
> part=null, incMeta=false, metrics=null, pageSize=1024, timeout=0, 
> keepAll=false, incBackups=false, dedup=false, prj=null, keepPortable=false, 
> subjId=c6aeb542-1693-4b5f-89db-96db50e3435f, taskHash=0], locFut=null, 
> sndId=c6aeb542-1693-4b5f-89db-96db50e3435f, reqId=14, incMeta=false, 
> all=false], node=209c237a-9e33-4d05-abe4-bbc14f93c439]
> class org.apache.ignite.IgniteCheckedException: 
> **.SubMessageB
> at org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:6979)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:166)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:115)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$CachedResult.iterator(GridCacheQueryManager.java:2784)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.runQuery(GridCacheQueryManager.java:1376)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager.processQueryRequest(GridCacheDistributedQueryManager.java:226)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$2.apply(GridCacheDistributedQueryManager.java:105)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$2.apply(GridCacheDistributedQueryManager.java:103)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:580)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:280)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:198)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:77)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:160)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:811)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1500(GridIoManager.java:106)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:774)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.ClassNotFoundException: 
> **.SubMessageB
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at 

[jira] [Updated] (IGNITE-3206) .NET: Automatic persistence

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-3206:
---
Fix Version/s: (was: 2.1)

> .NET: Automatic persistence
> ---
>
> Key: IGNITE-3206
> URL: https://issues.apache.org/jira/browse/IGNITE-3206
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>  Labels: .net
>
> See how Automatic Persistence works in Java: 
> http://apacheignite.gridgain.org/docs/automatic-persistence
> Think of a way to do the same in .NET with raw SqlClient and/or with 
> EntityFramework/NHibernate.



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

[jira] [Updated] (IGNITE-4427) .NET: Compute Checkpointing

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-4427:
---
Fix Version/s: (was: 2.1)

> .NET: Compute Checkpointing
> ---
>
> Key: IGNITE-4427
> URL: https://issues.apache.org/jira/browse/IGNITE-4427
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Reporter: Pavel Tupitsyn
>  Labels: .NET
>
> Implement compute checkpointing:
> https://apacheignite.readme.io/docs/checkpointing



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

[jira] [Updated] (IGNITE-2657) .NET: SqlDependency for cache items

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-2657:
---
Fix Version/s: (was: 2.1)
   2.2

> .NET: SqlDependency for cache items
> ---
>
> Key: IGNITE-2657
> URL: https://issues.apache.org/jira/browse/IGNITE-2657
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>  Labels: .net
> Fix For: 2.2
>
>
> Update cache when SQL Server data changes
> * https://msdn.microsoft.com/en-us/library/62xk7953(v=vs.110).aspx
> * http://www.alachisoft.com/ncache/database-synchronization.html



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

[jira] [Assigned] (IGNITE-5227) StackOverflowError in GridCacheMapEntry#checkOwnerChanged()

[Mikhail Cherkasov (JIRA)]

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

Mikhail Cherkasov reassigned IGNITE-5227:
-

Assignee: Mikhail Cherkasov

> StackOverflowError in GridCacheMapEntry#checkOwnerChanged()
> ---
>
> Key: IGNITE-5227
> URL: https://issues.apache.org/jira/browse/IGNITE-5227
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Alexey Goncharuk
>Assignee: Mikhail Cherkasov
>Priority: Critical
> Fix For: 2.1
>
>
> A simple test reproducing this error:
> {code}
> /**
>  * @throws Exception if failed.
>  */
> public void testBatchUnlock() throws Exception {
> startGrid(0);
> try {
> final CountDownLatch releaseLatch = new CountDownLatch(1);
> IgniteInternalFuture fut = GridTestUtils.runAsync(new 
> Callable() {
> @Override public Object call() throws Exception {
> IgniteCache cache = grid(0).cache(null);
> Lock lock = cache.lock("key");
> try {
> lock.lock();
> releaseLatch.await();
> }
> finally {
> lock.unlock();
> }
> return null;
> }
> });
> Map putMap = new LinkedHashMap<>();
> putMap.put("key", "trigger");
> for (int i = 0; i < 10_000; i++)
> putMap.put("key-" + i, "value");
> IgniteCache asyncCache = 
> grid(0).cache(null).withAsync();
> asyncCache.putAll(putMap);
> IgniteFuture resFut = asyncCache.future();
> Thread.sleep(1000);
> releaseLatch.countDown();
> fut.get();
> resFut.get();
> }
> finally {
> stopAllGrids();
> }
> {code}
> We should replace a recursive call with a simple iteration over the linked 
> list.



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

[jira] [Updated] (IGNITE-3189) .NET: Binarizables written from .NET can't be resolved on Java side

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-3189:
---
Fix Version/s: (was: 2.1)

> .NET: Binarizables written from .NET can't be resolved on Java side
> ---
>
> Key: IGNITE-3189
> URL: https://issues.apache.org/jira/browse/IGNITE-3189
> Project: Ignite
>  Issue Type: Test
>  Components: platforms
>Affects Versions: 1.7
>Reporter: Pavel Tupitsyn
>  Labels: .net
>
> Steps to reproduce:
> * Make sure to clean all Ignite work directories (in home and in 
> apache.ignite.core.tests folders)
> * Run ServicesTest.TestCallJavaService
> * Observe "Failed resolve class for ID: -1313284961" error
> Even though PlatformComputeBinarizable is properly registered in 
> BinaryConfiguration, if it has not been *written by java*, it can't be *read 
> by java*. Something does not get updated in BinaryContext/MarshallerContext.



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

[jira] [Updated] (IGNITE-3570) .NET: Rename Bool to Boolean

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-3570:
---
Fix Version/s: (was: 2.1)

> .NET: Rename Bool to Boolean
> 
>
> Key: IGNITE-3570
> URL: https://issues.apache.org/jira/browse/IGNITE-3570
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Priority: Trivial
>  Labels: .net, breaking-api
>
> Currently there is an inconsistency, some members are Bool, some are Boolean. 
> Let's rename everything to Boolean, to be consistent with system APIs (like 
> SerializationInfo)
> 2.0 migration guide has to be updated if needed: 
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0+Migration+Guide



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

[jira] [Updated] (IGNITE-5222) .NET: LINQ does not support IndexOf with char overloads

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-5222:
---
Priority: Minor  (was: Major)

> .NET: LINQ does not support IndexOf with char overloads
> ---
>
> Key: IGNITE-5222
> URL: https://issues.apache.org/jira/browse/IGNITE-5222
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Priority: Minor
>  Labels: .NET, LINQ
> Fix For: 2.1
>
>
> This works:
> {{orgs.AsCacheQueryable().Select(x => x.Value.Name.IndexOf("a")).Dump();}}
> This does not:
> {{orgs.AsCacheQueryable().Select(x => x.Value.Name.IndexOf('a')).Dump();}}
> See {{MethodVisitor.cs}}.



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

[jira] [Commented] (IGNITE-5163) JDBC Driver: implement handshake for thin jdbc driver based on common odbc/jdbc protocol

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-5163:
-

[~tledkov-gridgain], my comments:
1) {{BinaryWriterExImpl}} = why did we added dummy methods which do nothing 
more, but delefate to another one? I would remove all added {{do}} mehotds, and 
make relevant {{write}} methods public instead of package-private
2) {{GridBinaryMarshaller.JDK_MARSH}} - this constant should not be placed in 
{{GridBinaryMarshaller}} class, as binary protocol doesn't interact with JDK 
marshaller anyhow. Essentially, you build something on top of binary protocol, 
so this constant (flag?) should be somewhere inside {{SqlListener}} stuff.
3) {{GridKernalContext}} and {{GridKernalContextImpl}} - make sure to properly 
rename inner fields and javadocs as well
4) {{JdbcConnection}} - let's remove {{PROP_CACHE}} and {{cacheName}} 
completely, as it goes agains our plans to make schema "shareable" between 
caches. Instead, we should trakc current schema (through method setSchema()) 
and add it to SQL execute request. For now we will use schema name to derive 
cache name on the server side, but when IGNITE-5054 is completed, even this 
will be no longer necessary; make sure to change ODBC part in the same way
5) {{JdbcConnection.createStatement0}}, {{url}}, {{cacheName}} - unused methodы
6) {{JdbcConnection.timeout}} - looks like we never use it; let's print a 
warning for now that setting timeout is of no effect, and create separate 
ticket to handle it properly
7) {{JdbcConnection.getMetaData}} - throw unsupported exception instead of 
returning {{null}}? let's create another linked ticket for this
8) {{JdbcConnection.transactionIsolation}} - print a warning about unsupported 
feature, but do not throw an exception, because some external frameworks might 
call this method unconditionally;
9) {{JdbcConnection.setReadOnly}} - "updates are not supported" - really? 
anyway, according to spec this is just a hint for database, nothing more, so no 
exceptions should be raised here
10) {{JdbcConnection.setCatalog}} - according to spec "If the driver does not 
support catalogs, it will silently ignore this request."
11) {{JdbcConnection.prepareStatement}} - am I right that we have separate 
tickets for this?
12) {{JdbcConnection.isValid}} - incorrect implementation, you should return 
{{false}} if connection is closed, so {{ensureNotClosed}} is illegal here. 
Let's create separate ticket where we will send ping requests to the server 
when this method is called
13) {{JdbcConnection.getClientInfo}} - let's create separate ticket to support 
it properly
14) {{JdbcTcpIo.handshake}} - looks like you do not close the socket if 
handshake fails
15) New readers/writers - I completely lost on what is going on there; we 
should not mix binary and sql stuff anyhow. SQL must be built on top, it means 
composition, not inheritance with strange overrides.

> JDBC Driver: implement handshake for thin jdbc driver based on common 
> odbc/jdbc protocol
> 
>
> Key: IGNITE-5163
> URL: https://issues.apache.org/jira/browse/IGNITE-5163
> Project: Ignite
>  Issue Type: Task
>  Components: odbc, sql
>Affects Versions: 1.9
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.1
>
>
> The GridClient must be removed from thin jdbc driver.
> It is the first step to unify JDBC & ODBC protocols.



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

[jira] [Created] (IGNITE-5232) GridDhtPartitionDemander.requestPartitions invokes sendMessages consequently, which lead to significant increase of node start time on large clusters with ssl

[Evgenii Zhuravlev (JIRA)]

Evgenii Zhuravlev created IGNITE-5232:
-

 Summary: GridDhtPartitionDemander.requestPartitions invokes 
sendMessages consequently, which lead to significant increase of node start 
time on large clusters with ssl
 Key: IGNITE-5232
 URL: https://issues.apache.org/jira/browse/IGNITE-5232
 Project: Ignite
  Issue Type: Bug
Reporter: Evgenii Zhuravlev
 Fix For: 2.1






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

[jira] [Commented] (IGNITE-4447) Remove "Ignite 150 Clients" suite.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4447:


GitHub user vadopolski opened a pull request:

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

IGNITE-4447

Removed IgniteCache150ClientsTest.java to IgniteCacheTestSuite.java.

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

$ git pull https://github.com/vadopolski/ignite ignite-4447

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

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


commit 6e5f83233b5501bdb6a3bb03eb53f3be8871f786
Author: vopolski <2w3e4r5t>
Date:   2017-04-20T15:07:48Z

updating

commit f9d64f1e58b794caee47e584aa32ec18246fe434
Author: vopolski <2w3e4r5t>
Date:   2017-05-16T10:05:49Z

IGNITE-4447
Removed IgniteCache150ClientsTest.java to IgniteCacheTestSuite.java.

commit 185d5f9e685f6b0ec7ccf7bafa027dd46bfc156a
Author: vopolski <2w3e4r5t>
Date:   2017-05-16T10:28:54Z

IGNITE-4447
Removed IgniteCache150ClientsTest.java to IgniteCacheTestSuite.java.




> Remove "Ignite 150 Clients" suite.
> --
>
> Key: IGNITE-4447
> URL: https://issues.apache.org/jira/browse/IGNITE-4447
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Vadim Opolski
>Priority: Minor
> Fix For: 2.1
>
>
> It has only 1 tests. It runs for ~1m, but takes ~6m including build phase. 
> Let's just embed it into one of cache suites.



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

[jira] [Commented] (IGNITE-5226) Annotated fields compression

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5226:


GitHub user daradurvs opened a pull request:

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

IGNITE-5226



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

$ git pull https://github.com/daradurvs/ignite ignite-5226

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

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


commit 9df73f0808f9e45afc56622c0412472e3269763f
Author: Vyacheslav Daradur 
Date:   2017-05-15T16:15:21Z

ignite-5226: prototype

commit 868d3a89413b11593f1c4689b6a516f69c2c2d4a
Author: Vyacheslav Daradur 
Date:   2017-05-16T10:24:39Z

ignite-5226: minor refactoring




> Annotated fields compression
> 
>
> Key: IGNITE-5226
> URL: https://issues.apache.org/jira/browse/IGNITE-5226
> Project: Ignite
>  Issue Type: New Feature
>  Components: binary, cache
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
> Fix For: 2.1
>
>
> Develop solution for compression of annotated fields of an object.
> For example:
> {code}
> class Foo {
> @BinaryCompession
> String data;
> }
> {code}
> It must be compatible with querying and indexing.



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

[jira] [Commented] (IGNITE-4447) Remove "Ignite 150 Clients" suite.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4447:


Github user vadopolski closed the pull request at:

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


> Remove "Ignite 150 Clients" suite.
> --
>
> Key: IGNITE-4447
> URL: https://issues.apache.org/jira/browse/IGNITE-4447
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Vadim Opolski
>Priority: Minor
> Fix For: 2.1
>
>
> It has only 1 tests. It runs for ~1m, but takes ~6m including build phase. 
> Let's just embed it into one of cache suites.



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

[jira] [Assigned] (IGNITE-5231) Web Console: Add support for Ignite 2.0 cluster on Queries screen

[Andrey Novikov (JIRA)]

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

Andrey Novikov reassigned IGNITE-5231:
--

Assignee: Andrey Novikov

> Web Console: Add support for Ignite 2.0 cluster on Queries screen
> -
>
> Key: IGNITE-5231
> URL: https://issues.apache.org/jira/browse/IGNITE-5231
> Project: Ignite
>  Issue Type: Bug
>  Components: UI, wizards
>Affects Versions: 2.0
>Reporter: Andrey Novikov
>Assignee: Andrey Novikov
> Fix For: 2.1
>
>




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

[jira] [Created] (IGNITE-5231) Web Console: Add support for Ignite 2.0 cluster on Queries screen

[Andrey Novikov (JIRA)]

Andrey Novikov created IGNITE-5231:
--

 Summary: Web Console: Add support for Ignite 2.0 cluster on 
Queries screen
 Key: IGNITE-5231
 URL: https://issues.apache.org/jira/browse/IGNITE-5231
 Project: Ignite
  Issue Type: Bug
  Components: UI, wizards
Affects Versions: 2.0
Reporter: Andrey Novikov
 Fix For: 2.1






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

[jira] [Assigned] (IGNITE-5227) StackOverflowError in GridCacheMapEntry#checkOwnerChanged()

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk reassigned IGNITE-5227:


Assignee: (was: Alexandr Kuramshin)

> StackOverflowError in GridCacheMapEntry#checkOwnerChanged()
> ---
>
> Key: IGNITE-5227
> URL: https://issues.apache.org/jira/browse/IGNITE-5227
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Alexey Goncharuk
>Priority: Critical
> Fix For: 2.1
>
>
> A simple test reproducing this error:
> {code}
> /**
>  * @throws Exception if failed.
>  */
> public void testBatchUnlock() throws Exception {
> startGrid(0);
> try {
> final CountDownLatch releaseLatch = new CountDownLatch(1);
> IgniteInternalFuture fut = GridTestUtils.runAsync(new 
> Callable() {
> @Override public Object call() throws Exception {
> IgniteCache cache = grid(0).cache(null);
> Lock lock = cache.lock("key");
> try {
> lock.lock();
> releaseLatch.await();
> }
> finally {
> lock.unlock();
> }
> return null;
> }
> });
> Map putMap = new LinkedHashMap<>();
> putMap.put("key", "trigger");
> for (int i = 0; i < 10_000; i++)
> putMap.put("key-" + i, "value");
> IgniteCache asyncCache = 
> grid(0).cache(null).withAsync();
> asyncCache.putAll(putMap);
> IgniteFuture resFut = asyncCache.future();
> Thread.sleep(1000);
> releaseLatch.countDown();
> fut.get();
> resFut.get();
> }
> finally {
> stopAllGrids();
> }
> {code}
> We should replace a recursive call with a simple iteration over the linked 
> list.



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

[jira] [Commented] (IGNITE-4447) Remove "Ignite 150 Clients" suite.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4447:


GitHub user vadopolski opened a pull request:

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

IGNITE-4447

Removed IgniteCache150ClientsTest.java to IgniteCacheTestSuite.java.

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

$ git pull https://github.com/vadopolski/ignite ignite-4447

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

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


commit 6e5f83233b5501bdb6a3bb03eb53f3be8871f786
Author: vopolski <2w3e4r5t>
Date:   2017-04-20T15:07:48Z

updating

commit f9d64f1e58b794caee47e584aa32ec18246fe434
Author: vopolski <2w3e4r5t>
Date:   2017-05-16T10:05:49Z

IGNITE-4447
Removed IgniteCache150ClientsTest.java to IgniteCacheTestSuite.java.




> Remove "Ignite 150 Clients" suite.
> --
>
> Key: IGNITE-4447
> URL: https://issues.apache.org/jira/browse/IGNITE-4447
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Vadim Opolski
>Priority: Minor
> Fix For: 2.1
>
>
> It has only 1 tests. It runs for ~1m, but takes ~6m including build phase. 
> Let's just embed it into one of cache suites.



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

[jira] [Assigned] (IGNITE-5227) StackOverflowError in GridCacheMapEntry#checkOwnerChanged()

[Alexandr Kuramshin (JIRA)]

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

Alexandr Kuramshin reassigned IGNITE-5227:
--

Assignee: Alexandr Kuramshin  (was: Alexey Goncharuk)

> StackOverflowError in GridCacheMapEntry#checkOwnerChanged()
> ---
>
> Key: IGNITE-5227
> URL: https://issues.apache.org/jira/browse/IGNITE-5227
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Alexey Goncharuk
>Assignee: Alexandr Kuramshin
>Priority: Critical
> Fix For: 2.1
>
>
> A simple test reproducing this error:
> {code}
> /**
>  * @throws Exception if failed.
>  */
> public void testBatchUnlock() throws Exception {
> startGrid(0);
> try {
> final CountDownLatch releaseLatch = new CountDownLatch(1);
> IgniteInternalFuture fut = GridTestUtils.runAsync(new 
> Callable() {
> @Override public Object call() throws Exception {
> IgniteCache cache = grid(0).cache(null);
> Lock lock = cache.lock("key");
> try {
> lock.lock();
> releaseLatch.await();
> }
> finally {
> lock.unlock();
> }
> return null;
> }
> });
> Map putMap = new LinkedHashMap<>();
> putMap.put("key", "trigger");
> for (int i = 0; i < 10_000; i++)
> putMap.put("key-" + i, "value");
> IgniteCache asyncCache = 
> grid(0).cache(null).withAsync();
> asyncCache.putAll(putMap);
> IgniteFuture resFut = asyncCache.future();
> Thread.sleep(1000);
> releaseLatch.countDown();
> fut.get();
> resFut.get();
> }
> finally {
> stopAllGrids();
> }
> {code}
> We should replace a recursive call with a simple iteration over the linked 
> list.



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

[jira] [Commented] (IGNITE-5225) TcpCommunicationSpi.createTcpClient can cause OOME.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5225:


Github user AMashenkov closed the pull request at:

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


> TcpCommunicationSpi.createTcpClient can cause OOME.
> ---
>
> Key: IGNITE-5225
> URL: https://issues.apache.org/jira/browse/IGNITE-5225
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.0
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
> Fix For: 2.1
>
>
> TcpCommunicationSpi.filterReachable method doesn't shutdown executor 
> correctly that causes OOME.
> Possible reason is that user uses host name that can't be resolved somewhere 
> in configuration.
> Caused by: class org.apache.ignite.spi.IgniteSpiException: Failed to send 
> message to remote node: TcpDiscoveryNode 
> [id=edcb71b0-bd61-455a-8742-ade1653b0701, addrs=[0:0:0:0:0:0:0:1%lo, 
> 10.162.115.12, 127.0.
> 0.1], sockAddrs=[0:0:0:0:0:0:0:1%lo:0, /127.0.0.1:0, 
> mydomain.com/10.162.115.12:0], discPort=0, order=25, intOrder=25, 
> lastExchangeTime=1494183620982, loc=false, ver=,
>  isClient=true]
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2368)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2304)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1283)
> ... 34 more
> Caused by: class org.apache.ignite.IgniteCheckedException: 
> java.lang.NullPointerException
> at 
> org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7228)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:170)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:119)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2515)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2340)
> ... 36 more
> Caused by: java.util.concurrent.ExecutionException: 
> java.lang.NullPointerException
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:192)
> at 
> org.apache.ignite.internal.util.IgniteUtils.filterReachable(IgniteUtils.java:1884)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2775)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2587)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2479)
> ... 37 more
> Caused by: java.lang.NullPointerException
> at 
> org.apache.ignite.internal.util.IgniteUtils.reachable(IgniteUtils.java:2091)
> at 
> org.apache.ignite.internal.util.IgniteUtils$18.run(IgniteUtils.java:1873)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)



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

[jira] [Assigned] (IGNITE-5082) Redesign base template

[Ilya Borisov (JIRA)]

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

Ilya Borisov reassigned IGNITE-5082:


Assignee: Andrey Novikov  (was: Ilya Borisov)

Please review.

> Redesign base template
> --
>
> Key: IGNITE-5082
> URL: https://issues.apache.org/jira/browse/IGNITE-5082
> Project: Ignite
>  Issue Type: Task
>  Components: UI, wizards
>Affects Versions: 2.1
>Reporter: Dmitriy Shabalin
>Assignee: Andrey Novikov
> Fix For: 2.1
>
> Attachments: base layout.png
>
>




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

[jira] [Assigned] (IGNITE-5082) Redesign base template

[Ilya Borisov (JIRA)]

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

Ilya Borisov reassigned IGNITE-5082:


Assignee: Ilya Borisov  (was: Alexey Kuznetsov)

> Redesign base template
> --
>
> Key: IGNITE-5082
> URL: https://issues.apache.org/jira/browse/IGNITE-5082
> Project: Ignite
>  Issue Type: Task
>  Components: UI, wizards
>Affects Versions: 2.1
>Reporter: Dmitriy Shabalin
>Assignee: Ilya Borisov
> Fix For: 2.1
>
> Attachments: base layout.png
>
>




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

[jira] [Commented] (IGNITE-4205) CassandraCacheStore should start IgniteThread threads in loadCache() method

[Konstantin Dudkov (JIRA)]

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

Konstantin Dudkov commented on IGNITE-4205:
---

My last commit added this flag and checked read back works.

I'll check same issuei for CacheAbstractJdbcStore and will add separate ticket 
if it is same there.

> CassandraCacheStore should start IgniteThread threads in loadCache() method
> ---
>
> Key: IGNITE-4205
> URL: https://issues.apache.org/jira/browse/IGNITE-4205
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Konstantin Dudkov
>
> {{CassandraCacheStore.loadCache()}} method starts a generic thread pool for 
> parallel data load. Threads in this thread pool can't deserialize Ignite 
> internal objects (e.g. {{IgniteKernal}}) which can cause unexpected behavior. 
> Here is one of the scenarios:
> * There is column in Cassandra which stores an object as BLOB using 
> {{JavaSerializer}}.
> * {{CacheConfiguration.storeKeepBinary}} is {{true}}.
> * When an object is saved, it's passed to the store as an instance of 
> {{BinaryObject}} which is converted to a byte array and saved in Cassandra.
> * When the same object is loaded in {{loadCache}}, the store takes the byte 
> array and tries to convert it to {{BinaryObject}}. But it can't because this 
> implies calling {{IgnitionEx.localIgnite()}} from non-Ignite thread.
> To fix this we need to provide a thread factory that will create instances of 
> {{IgniteThread}} and use it in the pool that loads the data.
> Most likely the same issue exists in {{CacheAbstractJdbcStore}}.
> And in general, any threads created by Ignite internals should be 
> {{IgniteThread}}-s. This should be revisited.



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

[jira] [Commented] (IGNITE-5082) Redesign base template

[Ilya Borisov (JIRA)]

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

Ilya Borisov commented on IGNITE-5082:
--

[~vabramova] asked to change footer link colors in order to improve readability.

> Redesign base template
> --
>
> Key: IGNITE-5082
> URL: https://issues.apache.org/jira/browse/IGNITE-5082
> Project: Ignite
>  Issue Type: Task
>  Components: UI, wizards
>Affects Versions: 2.1
>Reporter: Dmitriy Shabalin
>Assignee: Alexey Kuznetsov
> Fix For: 2.1
>
> Attachments: base layout.png
>
>




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

[jira] [Commented] (IGNITE-4831) Add an option to disable MBeans

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4831:


Github user rfqu closed the pull request at:

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


> Add an option to disable MBeans
> ---
>
> Key: IGNITE-4831
> URL: https://issues.apache.org/jira/browse/IGNITE-4831
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.8
>Reporter: Valentin Kulichenko
>
> There are multiple MBeans registered by Ignite and there is no way to avoid 
> their registration (in case they're not allowed for security reasons for 
> example). We should have a system property that will disable MBeans.
> In addition, if MBean registration throws a {{RuntimeException}}, this 
> exception is not properly handled. For example, if it happens during cache 
> creation, {{createCache}} method hangs forever.



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

[jira] [Commented] (IGNITE-4205) CassandraCacheStore should start IgniteThread threads in loadCache() method

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko commented on IGNITE-4205:
-

[~kdudkov], can you please also check if the same issue exists in JDBC store 
({{CacheAbstractJdbcStore}})? If yes, it needs to be fixed in the same way.

As for your last comment, {{BinaryConfiguration#compactFooter}} should be set 
to {{false}} in this scenario. Please try and make sure it works.

> CassandraCacheStore should start IgniteThread threads in loadCache() method
> ---
>
> Key: IGNITE-4205
> URL: https://issues.apache.org/jira/browse/IGNITE-4205
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Konstantin Dudkov
>
> {{CassandraCacheStore.loadCache()}} method starts a generic thread pool for 
> parallel data load. Threads in this thread pool can't deserialize Ignite 
> internal objects (e.g. {{IgniteKernal}}) which can cause unexpected behavior. 
> Here is one of the scenarios:
> * There is column in Cassandra which stores an object as BLOB using 
> {{JavaSerializer}}.
> * {{CacheConfiguration.storeKeepBinary}} is {{true}}.
> * When an object is saved, it's passed to the store as an instance of 
> {{BinaryObject}} which is converted to a byte array and saved in Cassandra.
> * When the same object is loaded in {{loadCache}}, the store takes the byte 
> array and tries to convert it to {{BinaryObject}}. But it can't because this 
> implies calling {{IgnitionEx.localIgnite()}} from non-Ignite thread.
> To fix this we need to provide a thread factory that will create instances of 
> {{IgniteThread}} and use it in the pool that loads the data.
> Most likely the same issue exists in {{CacheAbstractJdbcStore}}.
> And in general, any threads created by Ignite internals should be 
> {{IgniteThread}}-s. This should be revisited.



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

[jira] [Created] (IGNITE-5230) Web Console: SVG icons integration

[Ilya Borisov (JIRA)]

Ilya Borisov created IGNITE-5230:


 Summary: Web Console: SVG icons integration
 Key: IGNITE-5230
 URL: https://issues.apache.org/jira/browse/IGNITE-5230
 Project: Ignite
  Issue Type: Task
  Components: wizards
Reporter: Ilya Borisov
Assignee: Ilya Borisov
Priority: Minor


We need a common way to use SVG icons that:
1. Does not require extra styles.
2. Allows for CSS styling of icons, especially icon color.
3. Easy to add new icons.



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

[jira] [Commented] (IGNITE-5052) Implement CREATE/DROP TABLE parsing and execution

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-5052:
-

[~al.psc], my comments:
1) {{IgniteQueryErrorCode.QUERY_ENTITIES_PRESENT}} - let's remove this error 
code
2) {{IgniteKernal.getOrCreateCache0}} - code duplication; looks like we should 
call {{getOrCreateCache0()}} from {{getOrCreateCache()}} to avoid it;
3) {{GridSqlCreateTable}} - please remove {{getSql()}} body, as it is not used
4) {{GridSqlQueryParser}} - unused imports and static constants
5) {{DdlStatementsProcessor.toQueryEntity}} - {{_KEY}} and {{_VAL}} columns 
should raise {{PARSING}} exception, they are already agnostic to caches; also 
it looks like all these checks should be moved to parser, so that successfull 
parsing mean that we have valid model (you already did that for NOT NULL 
columns and extra params)
6) {{IgniteH2Indexing.dynamicTableCreate}} - call to {{ctx.cache().cache()}} at 
the verн beginning is wrong; see 
{{org.apache.ignite.internal.IgniteKernal#createCache(java.lang.String)}} and 
{{org.apache.ignite.internal.processors.cache.GridCacheProcessor#createConfigFromTemplate}}
 on how to get configuration for template
7) {{IgniteH2Indexing.dynamicTableDrop}} - let's avoid call to 
{{space(schemaName)}} as this method will be removed soon to allow for multiple 
tables from different caches in the same schema
8) {{IgniteH2Indexing}} - both {{dynamicTableCreate}} and {{dynamicTableDrop}} 
methods do not have anything H2-specific; we should remove it from H2, and move 
relevant code to {{GridQueryProcessor}}
9) {{GridQueryProcessor}} - no wildcards in imports
10) {{GridCacheProcessor}} - I would ask [~agoncharuk] or [~sboikov] to review 
this change

> Implement CREATE/DROP TABLE parsing and execution
> -
>
> Key: IGNITE-5052
> URL: https://issues.apache.org/jira/browse/IGNITE-5052
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
>  Labels: important
> Fix For: 2.1
>
>
> Convert SQL string to relevant Igntie command. This could be:
> - {{createCache}}
> - {{getOrCreateCache}} (for {{IF NOT EXISTS}} case)
> - {{destroyCache}}



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

[jira] [Commented] (IGNITE-5155) Need to improve stats dump on exchange timeout

[Semen Boikov (JIRA)]

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

Semen Boikov commented on IGNITE-5155:
--

Yes, I already implemented exactly what Yakov suggested + more informative 
debug logging for some cache operation, will continue to work on this issue.

> Need to improve stats dump on exchange timeout
> --
>
> Key: IGNITE-5155
> URL: https://issues.apache.org/jira/browse/IGNITE-5155
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Yakov Zhdanov
>Assignee: Semen Boikov
> Fix For: 2.1
>
>
> Currently, on large topologies info dumped on "Failed to wait for partition 
> map exchange" 
> (org/apache/ignite/internal/processors/cache/GridCachePartitionExchangeManager.java:1713)
>  floods the log and we need to reduce information dumped.
> 1. Reduce output for exchange futures that are already done. Keep event, 
> topology version, servers count, clients count (more?)
> 2. Do not dump the whole communication stats, but send message to exchange 
> coordinator, ask for its status and for number of messages received and for 
> acked messages from local node.
> 3. we can think of sending new message from cache node to coordinator that 
> may be a sign of a problem on that node (e.g. unreleased tx locks or still 
> renting partitions) and coordinator may include this info to a status thus 
> every Ignite node may point to a problem node in the logs.



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

[jira] [Assigned] (IGNITE-5155) Need to improve stats dump on exchange timeout

[Semen Boikov (JIRA)]

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

Semen Boikov reassigned IGNITE-5155:


Assignee: Semen Boikov  (was: Stanilovsky Evgeny)

> Need to improve stats dump on exchange timeout
> --
>
> Key: IGNITE-5155
> URL: https://issues.apache.org/jira/browse/IGNITE-5155
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Yakov Zhdanov
>Assignee: Semen Boikov
> Fix For: 2.1
>
>
> Currently, on large topologies info dumped on "Failed to wait for partition 
> map exchange" 
> (org/apache/ignite/internal/processors/cache/GridCachePartitionExchangeManager.java:1713)
>  floods the log and we need to reduce information dumped.
> 1. Reduce output for exchange futures that are already done. Keep event, 
> topology version, servers count, clients count (more?)
> 2. Do not dump the whole communication stats, but send message to exchange 
> coordinator, ask for its status and for number of messages received and for 
> acked messages from local node.
> 3. we can think of sending new message from cache node to coordinator that 
> may be a sign of a problem on that node (e.g. unreleased tx locks or still 
> renting partitions) and coordinator may include this info to a status thus 
> every Ignite node may point to a problem node in the logs.



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