[jira] [Updated] (IGNITE-5303) WebConsole configuration wizard doesn't properly handle multiple RDBMS

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-5303:

Priority: Critical  (was: Major)

> WebConsole configuration wizard doesn't properly handle multiple RDBMS
> --
>
> Key: IGNITE-5303
> URL: https://issues.apache.org/jira/browse/IGNITE-5303
> Project: Ignite
>  Issue Type: Task
>Reporter: Denis Magda
>Assignee: Alexey Kuznetsov
>Priority: Critical
>
> Imagine a use case when cache_A needs to persist data in database_A while 
> cache_B has to be connected with database_B as a part of a single application.
> WebConsole allows importing a schema from both databases but:
> * in a final Spring XML configuration there will be only one data source bean 
> defined.
> * both cache_A and cache_B will use the data source of a database that was 
> used last for the schema importing.
> This is what we need to do:
> * Spring XML and Java configurations must include data source beans for every 
> database that was used for the schema importing.
> * security.properties file must contain a connection URL and credentials for 
> every database.
> * we need to support databases of different and similar vendors. For 
> instance, both database_A and database_B can be MySQL ones or database_B can 
> be based on PostgreSQL.



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

[jira] [Created] (IGNITE-5303) WebConsole configuration wizard doesn't properly handle multiple RDBMS

[Denis Magda (JIRA)]

Denis Magda created IGNITE-5303:
---

 Summary: WebConsole configuration wizard doesn't properly handle 
multiple RDBMS
 Key: IGNITE-5303
 URL: https://issues.apache.org/jira/browse/IGNITE-5303
 Project: Ignite
  Issue Type: Task
Reporter: Denis Magda
Assignee: Alexey Kuznetsov


Imagine a use case when cache_A needs to persist data in database_A while 
cache_B has to be connected with database_B as a part of a single application.

WebConsole allows importing a schema from both databases but:
* in a final Spring XML configuration there will be only one data source bean 
defined.
* both cache_A and cache_B will use the data source of a database that was used 
last for the schema importing.

This is what we need to do:
* Spring XML and Java configurations must include data source beans for every 
database that was used for the schema importing.
* security.properties file must contain a connection URL and credentials for 
every database.
* we need to support databases of different and similar vendors. For instance, 
both database_A and database_B can be MySQL ones or database_B can be based on 
PostgreSQL.



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

[jira] [Closed] (IGNITE-5295) NPE when Persistent Store is used and Memory Configuration is missing

[Denis Magda (JIRA)]

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

Denis Magda closed IGNITE-5295.
---

> NPE when Persistent Store is used and Memory Configuration is missing
> -
>
> Key: IGNITE-5295
> URL: https://issues.apache.org/jira/browse/IGNITE-5295
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Sergey Chugunov
>Priority: Blocker
> Fix For: 2.1
>
>
> Just added the first Persistent Store example to the branch that fosters the 
> donation:
> https://github.com/apache/ignite/tree/ignite-5267/examples/src/main/java/org/apache/ignite/examples/persistentstore
> However, the example fails with an NPE if a MemoryConfiguration is not 
> defined explicitly.
> {code}
> [17:55:39,334][ERROR][main][IgniteKernal] Exception during start processors, 
> node will be stopped and close connections
> class org.apache.ignite.IgniteCheckedException: Failed to start processor: 
> GridProcessorAdapter []
>   at 
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1766)
>   at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:925)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1895)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1647)
>   at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1075)
>   at 
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:993)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:879)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:778)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:648)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:617)
>   at org.apache.ignite.Ignition.start(Ignition.java:347)
>   at 
> org.apache.ignite.examples.persistentstore.PersistentStoreExample.main(PersistentStoreExample.java:56)
>   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: class org.apache.ignite.IgniteCheckedException: Failed to create 
> Ignite component (consider adding ignite-pds module to classpath) 
> [component=DATABASE_MANAGER, 
> cls=org.apache.ignite.internal.processors.cache.database.GridCacheDatabaseSharedManager]
>   at 
> org.apache.ignite.internal.IgniteComponentType.componentException(IgniteComponentType.java:335)
>   at 
> org.apache.ignite.internal.IgniteComponentType.create0(IgniteComponentType.java:311)
>   at 
> org.apache.ignite.internal.IgniteComponentType.create(IgniteComponentType.java:186)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.createSharedContext(GridCacheProcessor.java:2078)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.start(GridCacheProcessor.java:632)
>   at 
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1763)
>   ... 16 more
> Caused by: java.lang.reflect.InvocationTargetException
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>   at 
> org.apache.ignite.internal.IgniteComponentType.create0(IgniteComponentType.java:307)
>   ... 20 more
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.ignite.internal.processors.cache.database.GridCacheDatabaseSharedManager.(GridCacheDatabaseSharedManager.java:284)
>   ... 25 more
> [17:55:39,338][ERROR][main][IgniteKernal] Got exception while starting (will 
> rollback startup routine).
> class org.apache.ignite.IgniteCheckedException: Failed to start processor: 
> GridProcessorAdapter []
>   at 
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1766)
>   at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:925)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1895)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1647)
>   at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1075)
>   at 
> 

[jira] [Commented] (IGNITE-5295) NPE when Persistent Store is used and Memory Configuration is missing

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-5295:
-

Thanks, merged to ignite-5267.

> NPE when Persistent Store is used and Memory Configuration is missing
> -
>
> Key: IGNITE-5295
> URL: https://issues.apache.org/jira/browse/IGNITE-5295
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Sergey Chugunov
>Priority: Blocker
> Fix For: 2.1
>
>
> Just added the first Persistent Store example to the branch that fosters the 
> donation:
> https://github.com/apache/ignite/tree/ignite-5267/examples/src/main/java/org/apache/ignite/examples/persistentstore
> However, the example fails with an NPE if a MemoryConfiguration is not 
> defined explicitly.
> {code}
> [17:55:39,334][ERROR][main][IgniteKernal] Exception during start processors, 
> node will be stopped and close connections
> class org.apache.ignite.IgniteCheckedException: Failed to start processor: 
> GridProcessorAdapter []
>   at 
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1766)
>   at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:925)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1895)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1647)
>   at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1075)
>   at 
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:993)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:879)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:778)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:648)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:617)
>   at org.apache.ignite.Ignition.start(Ignition.java:347)
>   at 
> org.apache.ignite.examples.persistentstore.PersistentStoreExample.main(PersistentStoreExample.java:56)
>   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: class org.apache.ignite.IgniteCheckedException: Failed to create 
> Ignite component (consider adding ignite-pds module to classpath) 
> [component=DATABASE_MANAGER, 
> cls=org.apache.ignite.internal.processors.cache.database.GridCacheDatabaseSharedManager]
>   at 
> org.apache.ignite.internal.IgniteComponentType.componentException(IgniteComponentType.java:335)
>   at 
> org.apache.ignite.internal.IgniteComponentType.create0(IgniteComponentType.java:311)
>   at 
> org.apache.ignite.internal.IgniteComponentType.create(IgniteComponentType.java:186)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.createSharedContext(GridCacheProcessor.java:2078)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.start(GridCacheProcessor.java:632)
>   at 
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1763)
>   ... 16 more
> Caused by: java.lang.reflect.InvocationTargetException
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>   at 
> org.apache.ignite.internal.IgniteComponentType.create0(IgniteComponentType.java:307)
>   ... 20 more
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.ignite.internal.processors.cache.database.GridCacheDatabaseSharedManager.(GridCacheDatabaseSharedManager.java:284)
>   ... 25 more
> [17:55:39,338][ERROR][main][IgniteKernal] Got exception while starting (will 
> rollback startup routine).
> class org.apache.ignite.IgniteCheckedException: Failed to start processor: 
> GridProcessorAdapter []
>   at 
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1766)
>   at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:925)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1895)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1647)
>   at 

[jira] [Commented] (IGNITE-5294) Document Persistent Store

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-5294:
-

The Persistent Store is almost completed. Only the checkpointing part is left:
https://apacheignite.readme.io/v2.0/docs/distributed-persistent-store

> Document Persistent Store
> -
>
> Key: IGNITE-5294
> URL: https://issues.apache.org/jira/browse/IGNITE-5294
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Denis Magda
>Assignee: Denis Magda
> Fix For: 2.1
>
>
> Document the Persistent Store. Use these wiki pages as reference:
> https://cwiki.apache.org/confluence/display/IGNITE/Persistent+Store+Overview
> https://cwiki.apache.org/confluence/display/IGNITE/Persistent+Store+Internal+Design
> Pages to fill out or update:
> * Enhance the data loading page: 
> https://apacheignite.readme.io/v2.0/docs/data-loading
> * Rework the existing persistent store page: 
> https://apacheignite.readme.io/v2.0/docs/persistent-store
> * Create the page for the Ignite's distributed persistent store: 
> https://apacheignite.readme.io/v2.0/docs/distributed-persistent-store
> * Create an overview page. Describe the difference between all the storages 
> Ignite supports.
> * Add a link to Hadoop as a persistent store alternative.
> * Update the page memory documentation adding a paragraph about the 
> persistent store: https://apacheignite.readme.io/v2.0/docs/page-memory
> * Update the eviction documentation telling more about the persistent store: 
> https://apacheignite.readme.io/v2.0/docs/evictions



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

Igor Sapego commented on IGNITE-5097:
-

I mean only sizes of course.

> 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

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-5097:


[~isapego] I agree. 

> primitive arrays
You mean array size only, or also values?

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

Igor Sapego commented on IGNITE-5097:
-

[~daradurvs], [~ptupitsyn], so what is the decision, guys? I propose to only 
use varints in primitive arrays, strings, BigDecimals and Enum ordinals, where 
they could be most useful and would not interfere with platforms 
implementations.

> 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] [Assigned] (IGNITE-5301) JVM crashes on H2TreeIndex destroy

[Eduard Shangareev (JIRA)]

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

Eduard Shangareev reassigned IGNITE-5301:
-

Assignee: Eduard Shangareev

> JVM crashes on H2TreeIndex destroy
> --
>
> Key: IGNITE-5301
> URL: https://issues.apache.org/jira/browse/IGNITE-5301
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Igor Seliverstov
>Assignee: Eduard Shangareev
> Attachments: hs_err_pid9664.log
>
>
> There is a bug in destroy method because of which 
> {noformat}cctx.offheap().dropRootPageForIndex(idxName){noformat} method 
> actually does nothing. It happens because idx names on create RootPage and 
> destroy it are different (unlike creation a root page, a segment suffix isn't 
> added to tree name on destroy, so that it can't delete the page from 
> metastore by different key).
> After fixing this behavior I faced JVM crash. 
> I'm quite not familiar with the code, but I suppose something is wrong in 
> MetaStoreInnerIO logic.
> Crash report is attached.
> How to reproduce:
> just create and destroy a cache with indexed types and enabled PDS feature 
> after the fix I provided above is applied.



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

[jira] [Commented] (IGNITE-3355) CPP: Implement Compute::Call() for Ignite C++.

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov commented on IGNITE-3355:


[~isapego], I am ok with the changes.

> CPP: Implement Compute::Call() for Ignite C++.
> --
>
> Key: IGNITE-3355
> URL: https://issues.apache.org/jira/browse/IGNITE-3355
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>  Labels: cpp
> Fix For: 2.1
>
>
> Need to implement {{Compute}} class with {{Compute::Call}} method.



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

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

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov reassigned IGNITE-4575:
--

Assignee: Sergey Kalashnikov  (was: Igor Sapego)

> 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] [Assigned] (IGNITE-5295) NPE when Persistent Store is used and Memory Configuration is missing

[Sergey Chugunov (JIRA)]

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

Sergey Chugunov reassigned IGNITE-5295:
---

Assignee: Sergey Chugunov  (was: Alexey Goncharuk)

> NPE when Persistent Store is used and Memory Configuration is missing
> -
>
> Key: IGNITE-5295
> URL: https://issues.apache.org/jira/browse/IGNITE-5295
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Sergey Chugunov
>Priority: Blocker
> Fix For: 2.1
>
>
> Just added the first Persistent Store example to the branch that fosters the 
> donation:
> https://github.com/apache/ignite/tree/ignite-5267/examples/src/main/java/org/apache/ignite/examples/persistentstore
> However, the example fails with an NPE if a MemoryConfiguration is not 
> defined explicitly.
> {code}
> [17:55:39,334][ERROR][main][IgniteKernal] Exception during start processors, 
> node will be stopped and close connections
> class org.apache.ignite.IgniteCheckedException: Failed to start processor: 
> GridProcessorAdapter []
>   at 
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1766)
>   at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:925)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1895)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1647)
>   at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1075)
>   at 
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:993)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:879)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:778)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:648)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:617)
>   at org.apache.ignite.Ignition.start(Ignition.java:347)
>   at 
> org.apache.ignite.examples.persistentstore.PersistentStoreExample.main(PersistentStoreExample.java:56)
>   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: class org.apache.ignite.IgniteCheckedException: Failed to create 
> Ignite component (consider adding ignite-pds module to classpath) 
> [component=DATABASE_MANAGER, 
> cls=org.apache.ignite.internal.processors.cache.database.GridCacheDatabaseSharedManager]
>   at 
> org.apache.ignite.internal.IgniteComponentType.componentException(IgniteComponentType.java:335)
>   at 
> org.apache.ignite.internal.IgniteComponentType.create0(IgniteComponentType.java:311)
>   at 
> org.apache.ignite.internal.IgniteComponentType.create(IgniteComponentType.java:186)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.createSharedContext(GridCacheProcessor.java:2078)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.start(GridCacheProcessor.java:632)
>   at 
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1763)
>   ... 16 more
> Caused by: java.lang.reflect.InvocationTargetException
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>   at 
> org.apache.ignite.internal.IgniteComponentType.create0(IgniteComponentType.java:307)
>   ... 20 more
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.ignite.internal.processors.cache.database.GridCacheDatabaseSharedManager.(GridCacheDatabaseSharedManager.java:284)
>   ... 25 more
> [17:55:39,338][ERROR][main][IgniteKernal] Got exception while starting (will 
> rollback startup routine).
> class org.apache.ignite.IgniteCheckedException: Failed to start processor: 
> GridProcessorAdapter []
>   at 
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1766)
>   at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:925)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1895)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1647)
>   at 

[jira] [Commented] (IGNITE-5087) Enum comparison fails after marshal-unmarshal with BinaryMarshaller.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5087:


GitHub user NSAmelchev opened a pull request:

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

IGNITE-5087

Fix Enum comparison fails after marshal-unmarshal with BinaryMarshaller.

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

$ git pull https://github.com/NSAmelchev/ignite IGNITE-5087

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

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


commit bca9756cc4fbe3e89fbc29453d94619d2f90c95b
Author: NSAmelchev 
Date:   2017-02-07T14:04:02Z

Merge remote-tracking branch 'refs/remotes/apache/master'

commit fc8ed83579ee9781061490041c0cce553c9a4025
Author: NSAmelchev 
Date:   2017-03-27T12:45:44Z

Merge remote-tracking branch 'refs/remotes/apache/master'

commit 1c7493cbb5de000f1c131745c90b93d7b57d4d50
Author: NSAmelchev 
Date:   2017-04-04T09:50:52Z

Merge remote-tracking branch 'refs/remotes/apache/master'

commit 91703d9004a4f68bfd2ca694c93b6c3b2fb45101
Author: NSAmelchev 
Date:   2017-04-17T12:06:48Z

Merge remote-tracking branch 'refs/remotes/apache/master'

commit 7e0e55e52812d605cde570ca5b50c5764d69e0fb
Author: NSAmelchev 
Date:   2017-04-25T09:27:33Z

Merge remote-tracking branch 'refs/remotes/apache/master'

commit e603cc6107b6a972d752fb2176bf1d1461058584
Author: NSAmelchev 
Date:   2017-04-27T14:23:21Z

Merge branch 'master' of https://github.com/apache/ignite

commit e66897fddff3818c136e9d9afebe5b4bec802abe
Author: NSAmelchev 
Date:   2017-05-04T08:35:19Z

Merge remote-tracking branch 'refs/remotes/apache/master'

commit e8068b07fb8a7079385b113da821587fef4348c4
Author: NSAmelchev 
Date:   2017-05-18T10:17:40Z

Merge remote-tracking branch 'refs/remotes/apache/master'

commit fd9c2823571130cd4093a20e7d46563df6f4aade
Author: NSAmelchev 
Date:   2017-05-22T13:35:26Z

Merge branch 'master' of https://github.com/apache/ignite

commit 5dfee14838190c90155ea7a34a9d9e8f75cfb868
Author: NSAmelchev 
Date:   2017-05-26T12:46:10Z

Add fix and test for enum with declared body

commit 8e5fc52fdf998fa2af142e65823fa3b9d0bc4a2a
Author: NSAmelchev 
Date:   2017-05-26T12:55:28Z

Test refactoring

commit 1d7fa342a05e9fee7b9ef10a5b3d0289363ada6b
Author: NSAmelchev 
Date:   2017-05-26T13:52:10Z

Add method isEnum

commit 6fbf6a304f243ef80b4e1012d4c30ef15272a70e
Author: NSAmelchev 
Date:   2017-05-26T14:03:45Z

Javadoc refactor

commit 108df9521fed3d14762c2f697a791fb64dda5c11
Author: NSAmelchev 
Date:   2017-05-26T14:10:38Z

javadoc fix

commit 481e5e9ff24b23fb8616e1ce17ec47aab32c2e53
Author: NSAmelchev 
Date:   2017-05-26T14:16:51Z

Merge remote-tracking branch 'apache/master'

commit ca500a345fb1eef6ba567585d04ac8d666db
Author: NSAmelchev 
Date:   2017-05-26T14:32:54Z

Merge remote-tracking branch 'apache/master' into IGNITE-5087

# Conflicts:
#   
modules/core/src/test/java/org/apache/ignite/internal/binary/BinaryEnumsSelfTest.java

commit 305cd99e669eff149a502c221d80711399130c87
Author: NSAmelchev 
Date:   2017-05-26T14:34:58Z

Method refactor

commit cfd3250618c0b05be988000b3f456c61cf9f5b30
Author: NSAmelchev 
Date:   2017-05-26T14:39:35Z

Merge remote-tracking branch 'refs/remotes/origin/master' into IGNITE-5087




> Enum comparison fails after marshal-unmarshal with BinaryMarshaller.
> 
>
> Key: IGNITE-5087
> URL: https://issues.apache.org/jira/browse/IGNITE-5087
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.9
>Reporter: Andrew Mashenkov
>Assignee: Amelchev Nikita
> Fix For: 2.1
>
> Attachments: EnumBinaryMarshallerBug.java
>
>
> PFA repro.
> It fails on 1.9 and on 2.0-snapshot as well.



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

[jira] [Commented] (IGNITE-5204) The Unicode character in the value of a field which are included in an un-unique index will cause "stack overhead" exception

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov commented on IGNITE-5204:


[~wal...@sohu.com],
Thank you. This is valueable info. I did not know you use .NET API.
I rewrote my test for .NET. However, the issue is not reproduced for me. 
Some configuration details might be missing then.
Is it possible that you share your cache configuration?

Here is my .NET test (I have modified one of .NET examples for that purpose)
{code}
/*
 * Licensed to the Apache Software Foundation (ASF) under one or more
 * contributor license agreements.  See the NOTICE file distributed with
 * this work for additional information regarding copyright ownership.
 * The ASF licenses this file to You under the Apache License, Version 2.0
 * (the "License"); you may not use this file except in compliance with
 * the License.  You may obtain a copy of the License at
 *
 *  http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

namespace Apache.Ignite.Examples.Datagrid
{
using System;
using System.Text;
using Apache.Ignite.Core;
using Apache.Ignite.Core.Cache;
using Apache.Ignite.Core.Cache.Configuration;
using Apache.Ignite.Core.Cache.Query;
using Apache.Ignite.ExamplesDll.Binary;

/// 
/// This example showcases DML capabilities of Ignite's SQL engine.
/// 
/// 1) Build the project Apache.Ignite.ExamplesDll (select it -> 
right-click -> Build).
///Apache.Ignite.ExamplesDll.dll must appear in 
%IGNITE_HOME%/platforms/dotnet/examples/Apache.Ignite.ExamplesDll/bin/${Platform]/${Configuration}
 folder.
/// 2) Set this class as startup object (Apache.Ignite.Examples project -> 
right-click -> Properties ->
/// Application -> Startup object);
/// 3) Start example (F5 or Ctrl+F5).
/// 
/// This example can be run with standalone Apache Ignite.NET node:
/// 1) Run %IGNITE_HOME%/platforms/dotnet/bin/Apache.Ignite.exe:
/// Apache.Ignite.exe 
-configFileName=platforms\dotnet\examples\apache.ignite.examples\app.config 
-assembly=[path_to_Apache.Ignite.ExamplesDll.dll]
/// 2) Start example.
/// 
public class Ignite5204Example
{
private const string BillCacheName = "bill_cache";

public class Bill
{
[QuerySqlField(IsIndexed = true)]
public string BillId { get; set; }
}

public class Detail
{
[QuerySqlField(IsIndexed = true)]
public string BillId { get; set; }
}

[STAThread]
public static void Main()
{
using (var ignite = Ignition.StartFromApplicationConfiguration())
{
Console.WriteLine();
Console.WriteLine(">>> Example started.");

var billCache = ignite.GetOrCreateCache(
new CacheConfiguration(BillCacheName, 
new QueryEntity(typeof(string), typeof(Bill)),
new QueryEntity(typeof(string), typeof(Detail)) ));

billCache.Clear();

Insert(billCache);
Select(billCache, "Test");

Console.WriteLine();
}

Console.WriteLine();
Console.WriteLine(">>> Example finished, press any key to exit 
...");
Console.ReadKey();
}

private static void Select(ICache billCache, string 
message)
{
Console.WriteLine("\n>>> {0}", message);

var qry = new SqlFieldsQuery("select * from Bill where BillId = 
'草DX009090'");

using (var cursor = billCache.QueryFields(qry))
{
foreach (var row in cursor)
{
Console.WriteLine(">>> {0}", row[0]);
}
}

qry = new SqlFieldsQuery("select bill.*from bill left join detail 
on bill.billid = detail.billid");

using (var cursor = billCache.QueryFields(qry))
{
foreach (var row in cursor)
{
Console.WriteLine(">>> {0}", row[0]);
}
}
}

private static void Insert(ICache billCache)
{
var qry = new SqlFieldsQuery("insert into Bill (_key, BillId) 
values (?, ?)");

qry.Arguments = new object[] {"Bill_1", "DX000"};
billCache.QueryFields(qry);

qry.Arguments = new object[] {"Bill_2", 

[jira] [Commented] (IGNITE-4509) SQL: query with condition on affinity columns and without joins and subqueries can be replaced with GET

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov commented on IGNITE-4509:


*Important note*

The implemented approach differs from the one proposed in description/title.
The new approach attempts to derive a set of cache partitions that the given 
query covers 
from the query itself and its arguments. 
The query will be sent to execution only to those cluster nodes which have the 
derived partitions.

Thus if there is a condition in the {{where}} clause of form {{"_key = ?" or 
"affinityKey = ?"}}
the parameter (after binding) or a constant to the right is used to calculate 
the cache partition.

Multiple such conditions may be present. 
Additional non-key filters can be used in query and still the query may be 
optimized this way. 
(f.ex. {{"_key = ? and field = ?"}} as opposed to {{"_key = ? or field = ?"}} 
which cannot be optimized).

The approach does not put any constraints on the {{select expression_list}} 
clause of the query.
However, in the scope of this ticket, the queries with joins are not optimized 
this way (will be done in the scope of 
[https://issues.apache.org/jira/browse/IGNITE-4510]).

The {{cache.get()}} approach was considered not feasible for the following 
reasons:
1) requires specific {{cache.get()}} implementation that would accept a set of 
fields to retrieve,
which is essentially some sort of sql-like implementation;

2) limited application. Only the simplest form of queries can be optimized that 
way, 
i.e. no expressions over columns, no functions, just simplest {{_key=?}};

3) that kind of functionality doesn't fit seemlessly to the flow of sql query 
execution.


> SQL: query with condition on affinity columns and without joins and 
> subqueries can be replaced with GET
> ---
>
> Key: IGNITE-4509
> URL: https://issues.apache.org/jira/browse/IGNITE-4509
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Sergey Kalashnikov
>  Labels: important, performance, sql
> Fix For: 2.1
>
>
> Simple SQL queries usually demonstrate negative scalability when more nodes 
> are added. 
> Consider the following query:
> {code}
> SELECT * FROM Person p
> WHERE p.id = ?
> {code}
> If {{Person.id}} is affinity field, then query can be replaced with plain 
> {{IgniteCache.get}} or some specialized version of GET, which will return 
> only desired fields. This optimization will guarantee smooth scale with any 
> number of nodes.



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

[jira] [Updated] (IGNITE-5302) Empty LOST partition may be used as OWNING after resetting lost partitions

[Sergey Chugunov (JIRA)]

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

Sergey Chugunov updated IGNITE-5302:

Description: 
h2. Notes
Test *testPartitionLossAndRecover* reproducing the issue can be found in 
ignite-5267 branch with PDS functionality.

h2. Steps to reproduce
# Four nodes are started, some key is added to partitioned cache
# Primary and backup nodes for the key are stopped, key's partition is declared 
LOST on remaining nodes
# Primary and backup nodes are started again, cache's lost partitions are reset
# Key is requested from cache

h2. Expected behavior
Correct value is returned from primary for this partition

h2. Actual behavior
Request for value is sent to node where partition is empty (not to primary 
node), null is returned

h2. Latest findings
# The main problem with the scenario is that request for key gets mapped not 
only to P/B nodes with real value but also to the node where that partition 
existed only in LOST state after P/B shutdown on step #2
# It was found that on step #3 after primary and backup are joined partition 
counter is increased for empty partition in LOST state which looks wrong

  was:
h2 Notes
Test *testPartitionLossAndRecover* reproducing the issue can be found in 
ignite-5267 branch with PDS functionality.

h2 Steps to reproduce
# Four nodes are started, some key is added to partitioned cache
# Primary and backup nodes for the key are stopped, key's partition is declared 
LOST on remaining nodes
# Primary and backup nodes are started again, cache's lost partitions are reset
# Key is requested from cache

h2 Expected behavior
Correct value is returned from primary for this partition

h2 Actual behavior
Request for value is sent to node where partition is empty (not to primary 
node), null is returned

h2 Latest findings
# The main problem with the scenario is that request for key gets mapped not 
only to P/B nodes with real value but also to the node where that partition 
existed only in LOST state after P/B shutdown on step #2
# It was found that on step #3 after primary and backup are joined partition 
counter is increased for empty partition in LOST state which looks wrong


> Empty LOST partition may be used as OWNING after resetting lost partitions
> --
>
> Key: IGNITE-5302
> URL: https://issues.apache.org/jira/browse/IGNITE-5302
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Chugunov
>
> h2. Notes
> Test *testPartitionLossAndRecover* reproducing the issue can be found in 
> ignite-5267 branch with PDS functionality.
> h2. Steps to reproduce
> # Four nodes are started, some key is added to partitioned cache
> # Primary and backup nodes for the key are stopped, key's partition is 
> declared LOST on remaining nodes
> # Primary and backup nodes are started again, cache's lost partitions are 
> reset
> # Key is requested from cache
> h2. Expected behavior
> Correct value is returned from primary for this partition
> h2. Actual behavior
> Request for value is sent to node where partition is empty (not to primary 
> node), null is returned
> h2. Latest findings
> # The main problem with the scenario is that request for key gets mapped not 
> only to P/B nodes with real value but also to the node where that partition 
> existed only in LOST state after P/B shutdown on step #2
> # It was found that on step #3 after primary and backup are joined partition 
> counter is increased for empty partition in LOST state which looks wrong



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

[jira] [Created] (IGNITE-5302) Empty LOST partition may be used as OWNING after resetting lost partitions

[Sergey Chugunov (JIRA)]

Sergey Chugunov created IGNITE-5302:
---

 Summary: Empty LOST partition may be used as OWNING after 
resetting lost partitions
 Key: IGNITE-5302
 URL: https://issues.apache.org/jira/browse/IGNITE-5302
 Project: Ignite
  Issue Type: Bug
Reporter: Sergey Chugunov


h2 Notes
Test *testPartitionLossAndRecover* reproducing the issue can be found in 
ignite-5267 branch with PDS functionality.

h2 Steps to reproduce
# Four nodes are started, some key is added to partitioned cache
# Primary and backup nodes for the key are stopped, key's partition is declared 
LOST on remaining nodes
# Primary and backup nodes are started again, cache's lost partitions are reset
# Key is requested from cache

h2 Expected behavior
Correct value is returned from primary for this partition

h2 Actual behavior
Request for value is sent to node where partition is empty (not to primary 
node), null is returned

h2 Latest findings
# The main problem with the scenario is that request for key gets mapped not 
only to P/B nodes with real value but also to the node where that partition 
existed only in LOST state after P/B shutdown on step #2
# It was found that on step #3 after primary and backup are joined partition 
counter is increased for empty partition in LOST state which looks wrong



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

[jira] [Updated] (IGNITE-5301) JVM crashes on H2TreeIndex destroy

[Igor Seliverstov (JIRA)]

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

Igor Seliverstov updated IGNITE-5301:
-
Description: 
There is a bug in destroy method because of which 
{noformat}cctx.offheap().dropRootPageForIndex(idxName){noformat} method 
actually does nothing. It happens because idx names on create RootPage and 
destroy it are different (unlike creation a root page, a segment suffix isn't 
added to tree name on destroy, so that it can't delete the page from metastore 
by different key).

After fixing this behavior I faced JVM crash. 

I'm quite not familiar with the code, but I suppose something is wrong in 
MetaStoreInnerIO logic.

Crash report is attached.

How to reproduce:

just create and destroy a cache with indexed types and enabled PDS feature 
after the fix I provided above is applied.


  was:
There is a bug in destroy method because of which 
{noformat}cctx.offheap().dropRootPageForIndex(idxName){noformat} method 
actually does nothing. It happens because idx names on create RootPage and 
destroy it are different (unlike creation a root page, a segment suffix isn't 
added to tree name on destroy, so that it can't delete the page from metastore 
by different key).

After fixing this behavior I faced JVM crash. 

I'm quite not familiar with the code, but I suppose something is wrong in 
MetaStoreInnerIO logic.

Crash report is attached.

How to reproduce:

just create and destroy a cache with indexed types and enabled PDS feature 
after the fix I provided above.



> JVM crashes on H2TreeIndex destroy
> --
>
> Key: IGNITE-5301
> URL: https://issues.apache.org/jira/browse/IGNITE-5301
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Igor Seliverstov
> Attachments: hs_err_pid9664.log
>
>
> There is a bug in destroy method because of which 
> {noformat}cctx.offheap().dropRootPageForIndex(idxName){noformat} method 
> actually does nothing. It happens because idx names on create RootPage and 
> destroy it are different (unlike creation a root page, a segment suffix isn't 
> added to tree name on destroy, so that it can't delete the page from 
> metastore by different key).
> After fixing this behavior I faced JVM crash. 
> I'm quite not familiar with the code, but I suppose something is wrong in 
> MetaStoreInnerIO logic.
> Crash report is attached.
> How to reproduce:
> just create and destroy a cache with indexed types and enabled PDS feature 
> after the fix I provided above is applied.



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

[jira] [Updated] (IGNITE-5301) JVM crashes on H2TreeIndex destroy

[Igor Seliverstov (JIRA)]

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

Igor Seliverstov updated IGNITE-5301:
-
Description: 
There is a bug in destroy method because of which 
{noformat}cctx.offheap().dropRootPageForIndex(idxName){noformat} method 
actually does nothing. It happens because idx names on create RootPage and 
destroy it are different (unlike creation a root page, a segment suffix isn't 
added to tree name on destroy, so that it can't delete the page from metastore 
by different key).

After fixing this behavior I faced JVM crash. 

I'm quite not familiar with the code, but I suppose something is wrong in 
MetaStoreInnerIO logic.

Crash report is attached.

How to reproduce:

just create and destroy a cache with indexed types and enabled PDS feature 
after the fix I provided above.


  was:See the attached log.


> JVM crashes on H2TreeIndex destroy
> --
>
> Key: IGNITE-5301
> URL: https://issues.apache.org/jira/browse/IGNITE-5301
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Igor Seliverstov
> Attachments: hs_err_pid9664.log
>
>
> There is a bug in destroy method because of which 
> {noformat}cctx.offheap().dropRootPageForIndex(idxName){noformat} method 
> actually does nothing. It happens because idx names on create RootPage and 
> destroy it are different (unlike creation a root page, a segment suffix isn't 
> added to tree name on destroy, so that it can't delete the page from 
> metastore by different key).
> After fixing this behavior I faced JVM crash. 
> I'm quite not familiar with the code, but I suppose something is wrong in 
> MetaStoreInnerIO logic.
> Crash report is attached.
> How to reproduce:
> just create and destroy a cache with indexed types and enabled PDS feature 
> after the fix I provided above.



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

[jira] [Updated] (IGNITE-5301) JVM crashes on H2TreeIndex destroy

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-5301:
---
Component/s: sql

> JVM crashes on H2TreeIndex destroy
> --
>
> Key: IGNITE-5301
> URL: https://issues.apache.org/jira/browse/IGNITE-5301
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Igor Seliverstov
> Attachments: hs_err_pid9664.log
>
>
> See the attached log.



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

[jira] [Updated] (IGNITE-5301) JVM crashes on H2TreeIndex destroy

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-5301:
---
Summary: JVM crashes on H2TreeIndex destroy  (was: JVM crushes on 
H2TreeIndex destroy)

> JVM crashes on H2TreeIndex destroy
> --
>
> Key: IGNITE-5301
> URL: https://issues.apache.org/jira/browse/IGNITE-5301
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Igor Seliverstov
> Attachments: hs_err_pid9664.log
>
>




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

[jira] [Updated] (IGNITE-5301) JVM crashes on H2TreeIndex destroy

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-5301:
---
Description: See the attached log.

> JVM crashes on H2TreeIndex destroy
> --
>
> Key: IGNITE-5301
> URL: https://issues.apache.org/jira/browse/IGNITE-5301
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Igor Seliverstov
> Attachments: hs_err_pid9664.log
>
>
> See the attached log.



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

[jira] [Comment Edited] (IGNITE-4862) NPE in reading data from IGFS

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky edited comment on IGNITE-4862 at 5/26/17 1:33 PM:
--

[~vozerov] , thanks, fixed.
One note: as I understand, reading from the underlying secondary Fs stream does 
not need synchronization, only getting this stream and closing it needs to be 
synchronized.


was (Author: iveselovskiy):
[~vozerov] , thanks, fixed.

> NPE in reading data from IGFS
> -
>
> Key: IGNITE-4862
> URL: https://issues.apache.org/jira/browse/IGNITE-4862
> Project: Ignite
>  Issue Type: Bug
>  Components: hadoop
>Affects Versions: 1.9
>Reporter: Dmitry Karachentsev
>Assignee: Ivan Veselovsky
>Priority: Minor
> Fix For: 2.1
>
>
> {noformat}
> D:\app\CodexRT.CodexRT_20170314-1>hadoop\bin\hadoop fs -copyToLocal 
> igfs:///cacheLink/test3.orc D:\test3.orc
> -copyToLocal: Fatal internal error
> java.lang.NullPointerException
> at 
> org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsInputStream$FetchBufferPart.flatten(HadoopIgfsInputStream.java:458)
> at 
> org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsInputStream$DoubleFetchBuffer.flatten(HadoopIgfsInputStream.java:511)
> at 
> org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsInputStream.read(HadoopIgfsInputStream.java:177)
> at java.io.DataInputStream.read(DataInputStream.java:100)
> at org.apache.hadoop.io.IOUtils.copyBytes(IOUtils.java:91)
> at org.apache.hadoop.io.IOUtils.copyBytes(IOUtils.java:59)
> at org.apache.hadoop.io.IOUtils.copyBytes(IOUtils.java:119)
> at 
> org.apache.hadoop.fs.shell.CommandWithDestination$TargetFileSystem.writeStreamToFile(CommandWithDestination.java:466)
> at 
> org.apache.hadoop.fs.shell.CommandWithDestination.copyStreamToTarget(CommandWithDestination.java:391)
> at 
> org.apache.hadoop.fs.shell.CommandWithDestination.copyFileToTarget(CommandWithDestination.java:328)
> at 
> org.apache.hadoop.fs.shell.CommandWithDestination.processPath(CommandWithDestination.java:263)
> at 
> org.apache.hadoop.fs.shell.CommandWithDestination.processPath(CommandWithDestination.java:248)
> at org.apache.hadoop.fs.shell.Command.processPaths(Command.java:317)
> at 
> org.apache.hadoop.fs.shell.Command.processPathArgument(Command.java:289)
> at 
> org.apache.hadoop.fs.shell.CommandWithDestination.processPathArgument(CommandWithDestination.java:243)
> at 
> org.apache.hadoop.fs.shell.Command.processArgument(Command.java:271)
> at 
> org.apache.hadoop.fs.shell.Command.processArguments(Command.java:255)
> at 
> org.apache.hadoop.fs.shell.CommandWithDestination.processArguments(CommandWithDestination.java:220)
> at 
> org.apache.hadoop.fs.shell.Command.processRawArguments(Command.java:201)
> at org.apache.hadoop.fs.shell.Command.run(Command.java:165)
> at org.apache.hadoop.fs.FsShell.run(FsShell.java:287)
> at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:70)
> at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:84)
> at org.apache.hadoop.fs.FsShell.main(FsShell.java:340)
> {noformat}
> Details in discussion: 
> [http://apache-ignite-users.70518.x6.nabble.com/NullPointerException-when-using-IGFS-td11328.html]



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

[jira] [Created] (IGNITE-5301) JVM crushes on H2TreeIndex destroy

[Igor Seliverstov (JIRA)]

Igor Seliverstov created IGNITE-5301:


 Summary: JVM crushes on H2TreeIndex destroy
 Key: IGNITE-5301
 URL: https://issues.apache.org/jira/browse/IGNITE-5301
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.1
Reporter: Igor Seliverstov
 Attachments: hs_err_pid9664.log





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

[jira] [Updated] (IGNITE-5301) JVM crushes on H2TreeIndex destroy

[Igor Seliverstov (JIRA)]

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

Igor Seliverstov updated IGNITE-5301:
-
Attachment: hs_err_pid9664.log

> JVM crushes on H2TreeIndex destroy
> --
>
> Key: IGNITE-5301
> URL: https://issues.apache.org/jira/browse/IGNITE-5301
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Igor Seliverstov
> Attachments: hs_err_pid9664.log
>
>




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

[jira] [Created] (IGNITE-5300) .NET: LINQ RemoveAll examples

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-5300:
--

 Summary: .NET: LINQ RemoveAll examples
 Key: IGNITE-5300
 URL: https://issues.apache.org/jira/browse/IGNITE-5300
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Affects Versions: 2.1
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 2.1


Update examples (normal and LinqPad) to demonstrate {{RemoveAll}} LINQ bulk 
delete.



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

[jira] [Updated] (IGNITE-5300) .NET: LINQ RemoveAll examples

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-5300:
---
Description: Update examples (normal and LinqPad) to demonstrate 
{{RemoveAll}} LINQ bulk delete (IGNITE-4904).  (was: Update examples (normal 
and LinqPad) to demonstrate {{RemoveAll}} LINQ bulk delete.)

> .NET: LINQ RemoveAll examples
> -
>
> Key: IGNITE-5300
> URL: https://issues.apache.org/jira/browse/IGNITE-5300
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET, LINQ
> Fix For: 2.1
>
>
> Update examples (normal and LinqPad) to demonstrate {{RemoveAll}} LINQ bulk 
> delete (IGNITE-4904).



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

[jira] [Commented] (IGNITE-5293) Replicated cache performance degradation.

[Alexei Scherbakov (JIRA)]

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

Alexei Scherbakov commented on IGNITE-5293:
---

Updated the description with my local results.

> Replicated cache performance degradation.
> -
>
> Key: IGNITE-5293
> URL: https://issues.apache.org/jira/browse/IGNITE-5293
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.0
>Reporter: Alexei Scherbakov
> Fix For: 2.2
>
>
> With increase in number of nodes puts to replicated cache are slowed down 
> almost in the same proportion.
> Unit test reproducer:
> {noformat}
> /*
>  * Licensed to the Apache Software Foundation (ASF) under one or more
>  * contributor license agreements.  See the NOTICE file distributed with
>  * this work for additional information regarding copyright ownership.
>  * The ASF licenses this file to You under the Apache License, Version 2.0
>  * (the "License"); you may not use this file except in compliance with
>  * the License.  You may obtain a copy of the License at
>  *
>  *  http://www.apache.org/licenses/LICENSE-2.0
>  *
>  * Unless required by applicable law or agreed to in writing, software
>  * distributed under the License is distributed on an "AS IS" BASIS,
>  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
>  * See the License for the specific language governing permissions and
>  * limitations under the License.
>  */
> package org.apache.ignite.internal.processors.cache.distributed.replicated;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.IgniteCache;
> import org.apache.ignite.cache.CacheAtomicityMode;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.cache.CacheWriteSynchronizationMode;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.configuration.MemoryConfiguration;
> import org.apache.ignite.internal.IgniteEx;
> import org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi;
> import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
> import org.apache.ignite.transactions.Transaction;
> import org.apache.ignite.transactions.TransactionConcurrency;
> import org.apache.ignite.transactions.TransactionIsolation;
> /**
>  * Tests replicated cache performance .
>  */
> public class GridCacheReplicatedTransactionalDegradationTest extends 
> GridCommonAbstractTest {
> /** Keys. */
> private static final int KEYS = 100_000;
> @Override protected IgniteConfiguration getConfiguration(String gridName) 
> throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(gridName);
> cfg.setClientMode(gridName.startsWith("client"));
> CacheConfiguration ccfg = new CacheConfiguration();
> ccfg.setCacheMode(CacheMode.REPLICATED);
> ccfg.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL);
> 
> ccfg.setWriteSynchronizationMode(CacheWriteSynchronizationMode.FULL_SYNC);
> ccfg.setName("test");
> cfg.setCacheConfiguration(ccfg);
> return cfg;
> }
> /** */
> public void testThroughput() throws Exception {
> try {
> IgniteEx grid0 = startGrid(0);
> Ignite client = startGrid("client");
> IgniteCache cache = 
> client.getOrCreateCache("test");
> doTest(client, cache);
> startGrid(1);
> doTest(client, cache);
> startGrid(2);
> doTest(client, cache);
> } finally {
> stopAllGrids();
> }
> }
> /**
>  * @param client
>  * @param cache Cache.
>  */
> private void doTest(Ignite client, IgniteCache cache) {
> long t1 = System.currentTimeMillis();
> for (int i = 0; i < KEYS; i++) {
> try (Transaction tx = 
> client.transactions().txStart(TransactionConcurrency.PESSIMISTIC, 
> TransactionIsolation.REPEATABLE_READ)) {
> cache.put(i, i);
> tx.commit();
> }
> }
> log.info("TPS: " + Math.round(KEYS / 
> (float)(System.currentTimeMillis() - t1) * 1000));
> }
> }
> {noformat}
> My test results are:
> 1. transactional cache, explicit transaction.
> TPS: 2507
> TPS: 1660
> TPS: 1148
> 2. atomic cache
> TPS: 6416
> TPS: 5177
> TPS: 4403
> 3. transactional cache, no explicit transaction
> TPS: 4485
> TPS: 2289
> TPS: 1439



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

[jira] [Updated] (IGNITE-5293) Replicated cache performance degradation.

[Alexei Scherbakov (JIRA)]

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

Alexei Scherbakov updated IGNITE-5293:
--
Description: 
With increase in number of nodes puts to replicated cache are slowed down 
almost in the same proportion.

Unit test reproducer:
{noformat}
/*
 * Licensed to the Apache Software Foundation (ASF) under one or more
 * contributor license agreements.  See the NOTICE file distributed with
 * this work for additional information regarding copyright ownership.
 * The ASF licenses this file to You under the Apache License, Version 2.0
 * (the "License"); you may not use this file except in compliance with
 * the License.  You may obtain a copy of the License at
 *
 *  http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

package org.apache.ignite.internal.processors.cache.distributed.replicated;

import org.apache.ignite.Ignite;
import org.apache.ignite.IgniteCache;
import org.apache.ignite.cache.CacheAtomicityMode;
import org.apache.ignite.cache.CacheMode;
import org.apache.ignite.cache.CacheWriteSynchronizationMode;
import org.apache.ignite.configuration.CacheConfiguration;
import org.apache.ignite.configuration.IgniteConfiguration;
import org.apache.ignite.configuration.MemoryConfiguration;
import org.apache.ignite.internal.IgniteEx;
import org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi;
import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
import org.apache.ignite.transactions.Transaction;
import org.apache.ignite.transactions.TransactionConcurrency;
import org.apache.ignite.transactions.TransactionIsolation;

/**
 * Tests replicated cache performance .
 */
public class GridCacheReplicatedTransactionalDegradationTest extends 
GridCommonAbstractTest {
/** Keys. */
private static final int KEYS = 100_000;

@Override protected IgniteConfiguration getConfiguration(String gridName) 
throws Exception {
IgniteConfiguration cfg = super.getConfiguration(gridName);

cfg.setClientMode(gridName.startsWith("client"));

CacheConfiguration ccfg = new CacheConfiguration();

ccfg.setCacheMode(CacheMode.REPLICATED);
ccfg.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL);

ccfg.setWriteSynchronizationMode(CacheWriteSynchronizationMode.FULL_SYNC);
ccfg.setName("test");

cfg.setCacheConfiguration(ccfg);

return cfg;
}

/** */
public void testThroughput() throws Exception {
try {
IgniteEx grid0 = startGrid(0);

Ignite client = startGrid("client");

IgniteCache cache = client.getOrCreateCache("test");

doTest(client, cache);

startGrid(1);

doTest(client, cache);

startGrid(2);

doTest(client, cache);
} finally {
stopAllGrids();
}
}

/**
 * @param client
 * @param cache Cache.
 */
private void doTest(Ignite client, IgniteCache cache) {
long t1 = System.currentTimeMillis();

for (int i = 0; i < KEYS; i++) {
try (Transaction tx = 
client.transactions().txStart(TransactionConcurrency.PESSIMISTIC, 
TransactionIsolation.REPEATABLE_READ)) {
cache.put(i, i);

tx.commit();
}
}

log.info("TPS: " + Math.round(KEYS / (float)(System.currentTimeMillis() 
- t1) * 1000));
}
}
{noformat}

My test results are:

1. transactional cache, explicit transaction.
TPS: 2507
TPS: 1660
TPS: 1148

2. atomic cache
TPS: 6416
TPS: 5177
TPS: 4403

3. transactional cache, no explicit transaction
TPS: 4485
TPS: 2289
TPS: 1439



  was:
With increase in number of nodes puts to replicated cache are slowed down 
almost in the same proportion.

Unit test reproducer:
{noformat}
/*
 * Licensed to the Apache Software Foundation (ASF) under one or more
 * contributor license agreements.  See the NOTICE file distributed with
 * this work for additional information regarding copyright ownership.
 * The ASF licenses this file to You under the Apache License, Version 2.0
 * (the "License"); you may not use this file except in compliance with
 * the License.  You may obtain a copy of the License at
 *
 *  http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and

[jira] [Commented] (IGNITE-5298) .NET: DML update via LINQ

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-5298:


{{=}} cannot be used in expression trees: {{an expression tree may not contain 
an assignment operator}}.
However, there is an {{Expression.Assign}}. We can provide an extension method 
which works like this:

{{persons.Where(x => x.Key > 10).UpdateAll(x => x.Value.OrgId.Set(7));}}

> .NET: DML update via LINQ
> -
>
> Key: IGNITE-5298
> URL: https://issues.apache.org/jira/browse/IGNITE-5298
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET, LINQ, important
> Fix For: 2.2
>
>
> Bulk update with LINQ:
> {code}
> var persons = ignite.GetCache("persons").AsCacheQueryable();
> int affectedRows = persons.Where(x => x.Key > 10).UpdateAll(x => 
> x.Value.OrgId = 7);
> {code}
> See bulk delete with {{RemoveAll}}, IGNITE-4904.



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

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

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-5176:
-

[~tledkov-gridgain], why have you changed values of constants in 
{{SqlListenerRequest}}? You should have just add {{QRY_METADATA}} to the end of 
the list. This is totally unnecessary breaking change.

> JDBC Driver: implement query execution for thin jdbc driver based on common 
> odbc/jdbc protocol
> --
>
> Key: IGNITE-5176
> URL: https://issues.apache.org/jira/browse/IGNITE-5176
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.0
>Reporter: Taras Ledkov
>Assignee: Igor Sapego
> Fix For: 2.1
>
>
> Implementation query execution & fetch results for thin JDBC driver over ODBC 
> protocol.



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

[jira] [Assigned] (IGNITE-5298) .NET: DML update via LINQ

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn reassigned IGNITE-5298:
--

Assignee: Pavel Tupitsyn

> .NET: DML update via LINQ
> -
>
> Key: IGNITE-5298
> URL: https://issues.apache.org/jira/browse/IGNITE-5298
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET, LINQ, important
> Fix For: 2.2
>
>
> Bulk update with LINQ:
> {code}
> var persons = ignite.GetCache("persons").AsCacheQueryable();
> int affectedRows = persons.Where(x => x.Key > 10).UpdateAll(x => 
> x.Value.OrgId = 7);
> {code}
> See bulk delete with {{RemoveAll}}, IGNITE-4904.



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

[jira] [Created] (IGNITE-5299) Don't set IgniteLock as broken if lock is failoverSafe

[Evgenii Zhuravlev (JIRA)]

Evgenii Zhuravlev created IGNITE-5299:
-

 Summary: Don't set IgniteLock as broken if lock is failoverSafe
 Key: IGNITE-5299
 URL: https://issues.apache.org/jira/browse/IGNITE-5299
 Project: Ignite
  Issue Type: Bug
Reporter: Evgenii Zhuravlev


It's unnecessary to set isBroken flag to IgniteLock when failoverSafe=true, 
because it's only used in case when failoverSafe=false



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

[jira] [Closed] (IGNITE-1925) Test HadoopSkipListSelfTest.testLevel flakily fails

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-1925.
---

> Test HadoopSkipListSelfTest.testLevel flakily fails
> ---
>
> Key: IGNITE-1925
> URL: https://issues.apache.org/jira/browse/IGNITE-1925
> Project: Ignite
>  Issue Type: Bug
>  Components: hadoop
>Affects Versions: 1.6
>Reporter: Ivan Veselovsky
>Assignee: Ivan Veselovsky
>Priority: Minor
> Fix For: 2.1
>
>
> Test HadoopSkipListSelfTest.testLevel fails from time to time with ~ 3% 
> probability.
>  
> junit.framework.AssertionFailedError: null
> at junit.framework.Assert.fail(Assert.java:55)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.Assert.assertTrue(Assert.java:31)
> at junit.framework.TestCase.assertTrue(TestCase.java:201)
> at 
> org.apache.ignite.internal.processors.hadoop.shuffle.collections.HadoopSkipListSelfTest.testLevel(HadoopSkipListSelfTest.java:83)



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

[jira] [Assigned] (IGNITE-5210) If enabled security authentication, server is unable to restart if client tries to reconnect

[Dmitry Karachentsev (JIRA)]

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

Dmitry Karachentsev reassigned IGNITE-5210:
---

Assignee: Dmitry Karachentsev

> If enabled security authentication, server is unable to restart if client 
> tries to reconnect
> 
>
> Key: IGNITE-5210
> URL: https://issues.apache.org/jira/browse/IGNITE-5210
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.0
>Reporter: Dmitry Karachentsev
>Assignee: Dmitry Karachentsev
> Fix For: 2.1
>
>
> Steps to reproduce:
> # Configure security authentication.
> # Start server node.
> # Start client node.
> # Restart server node.
> # Server fails with ClassCastException
> {noformat}
> java.lang.ClassCastException: 
> org.apache.ignite.plugin.security.SecurityCredentials cannot be cast to [B
>   at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl.unmarshalCredentials(ServerImpl.java:1316)
>   at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl.access$2500(ServerImpl.java:168)
>   at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processJoinRequestMessage(ServerImpl.java:3362)
>   at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2573)
>   at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2393)
>   at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6491)
>   at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2479)
>   at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {noformat}



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

[jira] [Assigned] (IGNITE-5087) Enum comparison fails after marshal-unmarshal with BinaryMarshaller.

[Amelchev Nikita (JIRA)]

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

Amelchev Nikita reassigned IGNITE-5087:
---

Assignee: Amelchev Nikita

> Enum comparison fails after marshal-unmarshal with BinaryMarshaller.
> 
>
> Key: IGNITE-5087
> URL: https://issues.apache.org/jira/browse/IGNITE-5087
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.9
>Reporter: Andrew Mashenkov
>Assignee: Amelchev Nikita
> Fix For: 2.1
>
> Attachments: EnumBinaryMarshallerBug.java
>
>
> PFA repro.
> It fails on 1.9 and on 2.0-snapshot as well.



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

[jira] [Updated] (IGNITE-5210) If enabled security authentication, server is unable to restart if client tries to reconnect

[Dmitry Karachentsev (JIRA)]

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

Dmitry Karachentsev updated IGNITE-5210:

Fix Version/s: 2.1

> If enabled security authentication, server is unable to restart if client 
> tries to reconnect
> 
>
> Key: IGNITE-5210
> URL: https://issues.apache.org/jira/browse/IGNITE-5210
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.0
>Reporter: Dmitry Karachentsev
> Fix For: 2.1
>
>
> Steps to reproduce:
> # Configure security authentication.
> # Start server node.
> # Start client node.
> # Restart server node.
> # Server fails with ClassCastException
> {noformat}
> java.lang.ClassCastException: 
> org.apache.ignite.plugin.security.SecurityCredentials cannot be cast to [B
>   at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl.unmarshalCredentials(ServerImpl.java:1316)
>   at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl.access$2500(ServerImpl.java:168)
>   at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processJoinRequestMessage(ServerImpl.java:3362)
>   at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2573)
>   at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2393)
>   at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6491)
>   at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2479)
>   at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {noformat}



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

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

[Dmitry Karachentsev (JIRA)]

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

Dmitry Karachentsev commented on IGNITE-4477:
-

[~vozerov],
Fixed, please check.

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



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

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

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-4477:
-

[~dkarachentsev],
p.2 - yes, it is better to re-use existing {{GridFutureAdapter.chain}} method 
to avoid any subtle semantic changes. {{IgniteFutureImpl}} already depends on 
{{IgniteInternalFuture}} heavily, so no need decouple them this way.

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



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

[jira] [Commented] (IGNITE-4766) Relax worker thread wakeup logic in StipedExecutor

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-4766:
-

Closing as I failed to find any improvement in distributed benchmarks. Original 
patch is attached in case we would like to continue investigation in future.

> Relax worker thread wakeup logic in StipedExecutor
> --
>
> Key: IGNITE-4766
> URL: https://issues.apache.org/jira/browse/IGNITE-4766
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 1.9
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 2.1
>
> Attachments: IGNITE_4766.patch
>
>
> *Problem*
> Worker threads in {{StripedExecutor}} have {{parked}} state flag. When set to 
> {{true}} NIO threads will call {{LockSupport.unpark}} after submitting new 
> task to a queue.
> The problem is that this flag is only changed by worker thread. Thus, if NIO 
> worker submitted a new task and called {{unpark}}, worker will clean up 
> {{parked}} state only after real wake up what may take microseconds. All 
> subsequent submits from NIO thread occurred during this time will also invoke 
> {{unpark}} thus generating high contention on the underlying OS primitives. 
> Namely, condition variables which ultimately delegates to {{futex}} on Linux.
> *Solution*
> NIO threads must be able to clear {{parked}} state as well. Some CAS magic 
> will be required there. This way we will minimize number of {{unapark}} calls.



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

[jira] [Closed] (IGNITE-4766) Relax worker thread wakeup logic in StipedExecutor

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-4766.
---

> Relax worker thread wakeup logic in StipedExecutor
> --
>
> Key: IGNITE-4766
> URL: https://issues.apache.org/jira/browse/IGNITE-4766
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 1.9
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 2.1
>
> Attachments: IGNITE_4766.patch
>
>
> *Problem*
> Worker threads in {{StripedExecutor}} have {{parked}} state flag. When set to 
> {{true}} NIO threads will call {{LockSupport.unpark}} after submitting new 
> task to a queue.
> The problem is that this flag is only changed by worker thread. Thus, if NIO 
> worker submitted a new task and called {{unpark}}, worker will clean up 
> {{parked}} state only after real wake up what may take microseconds. All 
> subsequent submits from NIO thread occurred during this time will also invoke 
> {{unpark}} thus generating high contention on the underlying OS primitives. 
> Namely, condition variables which ultimately delegates to {{futex}} on Linux.
> *Solution*
> NIO threads must be able to clear {{parked}} state as well. Some CAS magic 
> will be required there. This way we will minimize number of {{unapark}} calls.



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

[jira] [Updated] (IGNITE-4766) Relax worker thread wakeup logic in StipedExecutor

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4766:

Attachment: IGNITE_4766.patch

> Relax worker thread wakeup logic in StipedExecutor
> --
>
> Key: IGNITE-4766
> URL: https://issues.apache.org/jira/browse/IGNITE-4766
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 1.9
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 2.1
>
> Attachments: IGNITE_4766.patch
>
>
> *Problem*
> Worker threads in {{StripedExecutor}} have {{parked}} state flag. When set to 
> {{true}} NIO threads will call {{LockSupport.unpark}} after submitting new 
> task to a queue.
> The problem is that this flag is only changed by worker thread. Thus, if NIO 
> worker submitted a new task and called {{unpark}}, worker will clean up 
> {{parked}} state only after real wake up what may take microseconds. All 
> subsequent submits from NIO thread occurred during this time will also invoke 
> {{unpark}} thus generating high contention on the underlying OS primitives. 
> Namely, condition variables which ultimately delegates to {{futex}} on Linux.
> *Solution*
> NIO threads must be able to clear {{parked}} state as well. Some CAS magic 
> will be required there. This way we will minimize number of {{unapark}} calls.



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

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

[Dmitry Karachentsev (JIRA)]

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

Dmitry Karachentsev edited comment on IGNITE-4477 at 5/26/17 11:27 AM:
---

[~vozerov], 
Thanks for the review!

1) Fixed (missed when removed default pool support).
2) It was made only for less relying on `IgniteInternalFuture`, but for sure, 
it's easier to use existing method. Shall I fix this as well?


was (Author: dkarachentsev):
[~vozerov], 
Thanks for the review!

1) Fixed (missed when removed default pool support).
2) It was made only for not relying on `IgniteInternalFuture`, but for sure, 
it's easier to use existing method. Shall I fix this as well?

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



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

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

[Dmitry Karachentsev (JIRA)]

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

Dmitry Karachentsev commented on IGNITE-4477:
-

[~vozerov], 
Thanks for the review!

1) Fixed (missed when removed default pool support).
2) It was made only for not relying on `IgniteInternalFuture`, but for sure, 
it's easier to use existing method. Shall I fix this as well?

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



--
This message was sent by Atlassian JIRA
(v6.3.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=16026151#comment-16026151
 ] 

Vladimir Ozerov commented on IGNITE-4575:
-

[~skalashnikov], 
Looks like CPP part is fine. I merged binary-related changes to master.

> 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: Igor Sapego
>  Labels: important
> Fix For: 2.1
>
>




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

[jira] [Assigned] (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:all-tabpanel
 ]

Vladimir Ozerov reassigned IGNITE-4575:
---

Assignee: Igor Sapego  (was: Sergey Kalashnikov)

> 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: Igor Sapego
>  Labels: important
> Fix For: 2.1
>
>




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

Vladimir Ozerov commented on IGNITE-4575:
-

[~skalashnikov], TeamCity looks good to me. However, we need to make sure that 
CPP is not affected. [~isapego], could you please do that?

> 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-5259) Minor serialization fix

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5259:


GitHub user dkarachentsev opened a pull request:

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

IGNITE-5259 Minor serialization fix

(cherry picked from commit b2040b7)

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

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

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

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


commit b6ad8535171951afb66d4c37d5cbf4bc3e208334
Author: dkarachentsev 
Date:   2017-05-23T13:14:08Z

IGNITE-5259 Minor serialization fix

(cherry picked from commit b2040b7)




> Minor serialization fix
> ---
>
> Key: IGNITE-5259
> URL: https://issues.apache.org/jira/browse/IGNITE-5259
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Dmitry Karachentsev
>Assignee: Dmitry Karachentsev
> Fix For: 2.1
>
>




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

[jira] [Commented] (IGNITE-5242) Disallow DROP TABLE on statically configured caches

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-5242:
-

p.2 - got it.

> Disallow DROP TABLE on statically configured caches
> ---
>
> Key: IGNITE-5242
> URL: https://issues.apache.org/jira/browse/IGNITE-5242
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.0
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
> Fix For: 2.1
>
>
> Should we allow {{DROP TABLE}} on statically configured cache, there will be 
> a room for weird situations when it is impossible to understand on whether to 
> start the cache or not.



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

[jira] [Commented] (IGNITE-5291) SQL: plans cache does not clear on cache stop

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-5291:
-

[~al.psc], fix looks good, but I see failed tests on TC (Ignite Binary Objects 
Simple Mapper Queries). Please confirm that TC is in acceptable state.

> SQL: plans cache does not clear on cache stop
> -
>
> Key: IGNITE-5291
> URL: https://issues.apache.org/jira/browse/IGNITE-5291
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.0
> Environment: After cache-schema decoupling mutation of 
> {{DmlStatementsProcessor#planCache}} appears to be broken (different pieces 
> of code contexts operate different schema names), have to do this 
> consistently.
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Fix For: 2.1
>
>




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

[jira] [Commented] (IGNITE-5290) Events might be missed during concurrent CQ registration and cache operations

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-5290:
--

[~amashenkov],
It is not duplicate. Its other issue.

> Events might be missed during concurrent CQ registration and cache operations
> -
>
> Key: IGNITE-5290
> URL: https://issues.apache.org/jira/browse/IGNITE-5290
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Nikolay Tikhonov
> Attachments: test.patch
>
>
> Events might be missed during concurrent CQ registration and cache 
> operations. See attached test.



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

[jira] [Commented] (IGNITE-5242) Disallow DROP TABLE on statically configured caches

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko commented on IGNITE-5242:
-

[~vozerov]

1, 3: agree, working on fixes

2: these flags (don't fail if exists; fail if not started; check thread tx) 
match those used in routines like {{createFromTemplate}} with except for the 
first. It's false as we want to process false result and throw schema opeation 
exception from client code that calls this method ({{GridQueryProcessor}}, to 
be precise), not from cache processor internals.

> Disallow DROP TABLE on statically configured caches
> ---
>
> Key: IGNITE-5242
> URL: https://issues.apache.org/jira/browse/IGNITE-5242
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.0
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
> Fix For: 2.1
>
>
> Should we allow {{DROP TABLE}} on statically configured cache, there will be 
> a room for weird situations when it is impossible to understand on whether to 
> start the cache or not.



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

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

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-4477:
-

[~dkarachentsev], my comments:
1) {{IgniteFuture}} - invalid JavaDocs. You claim that {{null}} executor will 
move callback to the public pool, while in reality you throw an exception. I 
think it is correct to disallow {{null}} here, so only JavaDocs need to be 
fixed;
2) {{IgniteFutureImpl.chainInternal}} - why did you change the whole 
implementation? There is already proper method to pass executor to in internal 
future: {{GridFutureAdapter.chain(IgniteClosure, Executor)}}

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



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

[jira] [Commented] (IGNITE-4904) .NET: DML via LINQ

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-4904:


Merged to master ({{d38ca8b1004effefa5126981f434649d26db1e68}}).

Ticket for {{UpdateAll}}: IGNITE-5298

> .NET: DML via LINQ
> --
>
> Key: IGNITE-4904
> URL: https://issues.apache.org/jira/browse/IGNITE-4904
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.9
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET, LINQ, important
> Fix For: 2.1
>
>
> Perform bulk update operations via LINQ: {{UPDATE WHERE}}, {{DELETE WHERE}}. 
> Insert can already be done on object level with {{ICache.PutAll}}.
> 1) {{DELETE WHERE}}. This is quite simple. We can provide an extension method 
> like this:
> {code}
> public static int DeleteAll(this ICache cache, 
> IQueryable> items);
> {code}
> 2) {{UPDATE WHERE}}. This is tricky, because LINQ only works with expression 
> trees, and multi-line methods are not supported. We should come up with a way 
> to provide a list of columns and values, something like
> {code}
> public static int UpdateAll(this ICache cache, 
> IQueryable> items, params UpdateAction[] actions);
> {code}
> where UpdateAction can consist of a MemberExpression and a value for that 
> member.
> We should probably do delete as a separate task first.



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

[jira] [Created] (IGNITE-5298) .NET: DML update via LINQ

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-5298:
--

 Summary: .NET: DML update via LINQ
 Key: IGNITE-5298
 URL: https://issues.apache.org/jira/browse/IGNITE-5298
 Project: Ignite
  Issue Type: New Feature
  Components: platforms
Affects Versions: 2.1
Reporter: Pavel Tupitsyn
 Fix For: 2.2


Bulk update with LINQ:

{code}
var persons = ignite.GetCache("persons").AsCacheQueryable();

int affectedRows = persons.Where(x => x.Key > 10).UpdateAll(x => x.Value.OrgId 
= 7);
{code}

See bulk delete with {{RemoveAll}}, IGNITE-4904.



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

[jira] [Created] (IGNITE-5297) .NET: DML update via LINQ

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-5297:
--

 Summary: .NET: DML update via LINQ
 Key: IGNITE-5297
 URL: https://issues.apache.org/jira/browse/IGNITE-5297
 Project: Ignite
  Issue Type: New Feature
  Components: platforms
Affects Versions: 2.1
Reporter: Pavel Tupitsyn
 Fix For: 2.2


Bulk update with LINQ:

{code}
var persons = ignite.GetCache("persons").AsCacheQueryable();

int affectedRows = persons.Where(x => x.Key > 10).UpdateAll(x => x.Value.OrgId 
= 7);
{code}

See bulk delete with {{RemoveAll}}, IGNITE-4904.



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

[jira] [Commented] (IGNITE-5293) Replicated cache performance degradation.

[Alexei Scherbakov (JIRA)]

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

Alexei Scherbakov commented on IGNITE-5293:
---

Seems in atomic mode this is not an issue.

> Replicated cache performance degradation.
> -
>
> Key: IGNITE-5293
> URL: https://issues.apache.org/jira/browse/IGNITE-5293
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.0
>Reporter: Alexei Scherbakov
> Fix For: 2.2
>
>
> With increase in number of nodes puts to replicated cache are slowed down 
> almost in the same proportion.
> Unit test reproducer:
> {noformat}
> /*
>  * Licensed to the Apache Software Foundation (ASF) under one or more
>  * contributor license agreements.  See the NOTICE file distributed with
>  * this work for additional information regarding copyright ownership.
>  * The ASF licenses this file to You under the Apache License, Version 2.0
>  * (the "License"); you may not use this file except in compliance with
>  * the License.  You may obtain a copy of the License at
>  *
>  *  http://www.apache.org/licenses/LICENSE-2.0
>  *
>  * Unless required by applicable law or agreed to in writing, software
>  * distributed under the License is distributed on an "AS IS" BASIS,
>  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
>  * See the License for the specific language governing permissions and
>  * limitations under the License.
>  */
> package org.apache.ignite.internal.processors.cache.distributed.replicated;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.IgniteCache;
> import org.apache.ignite.cache.CacheAtomicityMode;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.cache.CacheWriteSynchronizationMode;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.configuration.MemoryConfiguration;
> import org.apache.ignite.internal.IgniteEx;
> import org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi;
> import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
> import org.apache.ignite.transactions.Transaction;
> import org.apache.ignite.transactions.TransactionConcurrency;
> import org.apache.ignite.transactions.TransactionIsolation;
> /**
>  * Tests replicated cache performance .
>  */
> public class GridCacheReplicatedTransactionalDegradationTest extends 
> GridCommonAbstractTest {
> /** Keys. */
> private static final int KEYS = 100_000;
> @Override protected IgniteConfiguration getConfiguration(String gridName) 
> throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(gridName);
> cfg.setClientMode(gridName.startsWith("client"));
> CacheConfiguration ccfg = new CacheConfiguration();
> ccfg.setCacheMode(CacheMode.REPLICATED);
> ccfg.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL);
> 
> ccfg.setWriteSynchronizationMode(CacheWriteSynchronizationMode.FULL_SYNC);
> ccfg.setName("test");
> cfg.setCacheConfiguration(ccfg);
> return cfg;
> }
> /** */
> public void testThroughput() throws Exception {
> try {
> IgniteEx grid0 = startGrid(0);
> Ignite client = startGrid("client");
> IgniteCache cache = 
> client.getOrCreateCache("test");
> doTest(client, cache);
> startGrid(1);
> doTest(client, cache);
> startGrid(2);
> doTest(client, cache);
> } finally {
> stopAllGrids();
> }
> }
> /**
>  * @param client
>  * @param cache Cache.
>  */
> private void doTest(Ignite client, IgniteCache cache) {
> long t1 = System.currentTimeMillis();
> for (int i = 0; i < KEYS; i++) {
> try (Transaction tx = 
> client.transactions().txStart(TransactionConcurrency.PESSIMISTIC, 
> TransactionIsolation.REPEATABLE_READ)) {
> cache.put(i, i);
> tx.commit();
> }
> }
> log.info("TPS: " + Math.round(KEYS / 
> (float)(System.currentTimeMillis() - t1) * 1000));
> }
> }
> {noformat}



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

[jira] [Commented] (IGNITE-4904) .NET: DML via LINQ

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4904:


Github user asfgit closed the pull request at:

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


> .NET: DML via LINQ
> --
>
> Key: IGNITE-4904
> URL: https://issues.apache.org/jira/browse/IGNITE-4904
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.9
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET, LINQ, important
> Fix For: 2.1
>
>
> Perform bulk update operations via LINQ: {{UPDATE WHERE}}, {{DELETE WHERE}}. 
> Insert can already be done on object level with {{ICache.PutAll}}.
> 1) {{DELETE WHERE}}. This is quite simple. We can provide an extension method 
> like this:
> {code}
> public static int DeleteAll(this ICache cache, 
> IQueryable> items);
> {code}
> 2) {{UPDATE WHERE}}. This is tricky, because LINQ only works with expression 
> trees, and multi-line methods are not supported. We should come up with a way 
> to provide a list of columns and values, something like
> {code}
> public static int UpdateAll(this ICache cache, 
> IQueryable> items, params UpdateAction[] actions);
> {code}
> where UpdateAction can consist of a MemberExpression and a value for that 
> member.
> We should probably do delete as a separate task first.



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

[jira] [Commented] (IGNITE-4667) Throw exception on starting client cache when indexed types cannot be loaded

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4667:


GitHub user dkarachentsev opened a pull request:

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

IGNITE-4667 - Throw exception on starting client cache when indexed t…

…ypes cannot be loaded

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

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

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

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


commit 22a64e30a3e1e7cac322a520d12cfd7cb179c524
Author: dkarachentsev 
Date:   2017-05-26T09:55:55Z

IGNITE-4667 - Throw exception on starting client cache when indexed types 
cannot be loaded




> Throw exception on starting client cache when indexed types cannot be loaded
> 
>
> Key: IGNITE-4667
> URL: https://issues.apache.org/jira/browse/IGNITE-4667
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.8
>Reporter: Dmitry Karachentsev
>Assignee: Dmitry Karachentsev
> Fix For: 2.1
>
>
> Assume following situation:
> 1. Server node configured cache indexed types with classes that client node 
> doesn't have.
> 2. Start server.
> 3. Start client. Client successfully connected.
> 4. Try to get cache on client node.
> 5. Was thrown exception in GridQueryProcessor and request for cache on client 
> node hangs forever.
> If on some reason cache couldn't be initialized, exception must be thrown on 
> Ignite.cache() operation.



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

[jira] [Updated] (IGNITE-4667) Throw exception on starting client cache when indexed types cannot be loaded

[Dmitry Karachentsev (JIRA)]

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

Dmitry Karachentsev updated IGNITE-4667:

Fix Version/s: (was: 2.0)
   2.1

> Throw exception on starting client cache when indexed types cannot be loaded
> 
>
> Key: IGNITE-4667
> URL: https://issues.apache.org/jira/browse/IGNITE-4667
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.8
>Reporter: Dmitry Karachentsev
>Assignee: Dmitry Karachentsev
> Fix For: 2.1
>
>
> Assume following situation:
> 1. Server node configured cache indexed types with classes that client node 
> doesn't have.
> 2. Start server.
> 3. Start client. Client successfully connected.
> 4. Try to get cache on client node.
> 5. Was thrown exception in GridQueryProcessor and request for cache on client 
> node hangs forever.
> If on some reason cache couldn't be initialized, exception must be thrown on 
> Ignite.cache() operation.



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

[jira] [Updated] (IGNITE-4904) .NET: DML via LINQ

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4904:

Labels: .NET LINQ important  (was: .NET LINQ)

> .NET: DML via LINQ
> --
>
> Key: IGNITE-4904
> URL: https://issues.apache.org/jira/browse/IGNITE-4904
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.9
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET, LINQ, important
> Fix For: 2.1
>
>
> Perform bulk update operations via LINQ: {{UPDATE WHERE}}, {{DELETE WHERE}}. 
> Insert can already be done on object level with {{ICache.PutAll}}.
> 1) {{DELETE WHERE}}. This is quite simple. We can provide an extension method 
> like this:
> {code}
> public static int DeleteAll(this ICache cache, 
> IQueryable> items);
> {code}
> 2) {{UPDATE WHERE}}. This is tricky, because LINQ only works with expression 
> trees, and multi-line methods are not supported. We should come up with a way 
> to provide a list of columns and values, something like
> {code}
> public static int UpdateAll(this ICache cache, 
> IQueryable> items, params UpdateAction[] actions);
> {code}
> where UpdateAction can consist of a MemberExpression and a value for that 
> member.
> We should probably do delete as a separate task first.



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

[jira] [Commented] (IGNITE-4904) .NET: DML via LINQ

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-4904:
-

[~ptupitsyn], agree.

> .NET: DML via LINQ
> --
>
> Key: IGNITE-4904
> URL: https://issues.apache.org/jira/browse/IGNITE-4904
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.9
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET, LINQ, important
> Fix For: 2.1
>
>
> Perform bulk update operations via LINQ: {{UPDATE WHERE}}, {{DELETE WHERE}}. 
> Insert can already be done on object level with {{ICache.PutAll}}.
> 1) {{DELETE WHERE}}. This is quite simple. We can provide an extension method 
> like this:
> {code}
> public static int DeleteAll(this ICache cache, 
> IQueryable> items);
> {code}
> 2) {{UPDATE WHERE}}. This is tricky, because LINQ only works with expression 
> trees, and multi-line methods are not supported. We should come up with a way 
> to provide a list of columns and values, something like
> {code}
> public static int UpdateAll(this ICache cache, 
> IQueryable> items, params UpdateAction[] actions);
> {code}
> where UpdateAction can consist of a MemberExpression and a value for that 
> member.
> We should probably do delete as a separate task first.



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

[jira] [Commented] (IGNITE-5242) Disallow DROP TABLE on statically configured caches

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-5242:
-

[~al.psc], my comments:
1) {{ClusterCachesInfo}}:817 - why false? Shouldn't we pass SQL flag here?
2) {{GridCacheProcessor.dynamicStartSqlCache}} - I do not understand flags you 
pass.
3) Not enough tests. You should also test node join scenario to ensure that SQL 
flag is propagated correctly between nodes, and that SQL-created cache cannot 
be "merged" with non-sql cache.

> Disallow DROP TABLE on statically configured caches
> ---
>
> Key: IGNITE-5242
> URL: https://issues.apache.org/jira/browse/IGNITE-5242
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.0
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
> Fix For: 2.1
>
>
> Should we allow {{DROP TABLE}} on statically configured cache, there will be 
> a room for weird situations when it is impossible to understand on whether to 
> start the cache or not.



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

[jira] [Commented] (IGNITE-5038) BinaryMarshaller might need to use context class loader for deserialization

[Vladislav Pyatkov (JIRA)]

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

Vladislav Pyatkov commented on IGNITE-5038:
---

I heave add ability to customize class loader when deserialize object from 
binary.
Added method {{BinaryObject#deserialize(java.lang.ClassLoader)}}.

Lock at my PR:
https://github.com/apache/ignite/pull/2011

Now the fix is testing on TC

> BinaryMarshaller might need to use context class loader for deserialization
> ---
>
> Key: IGNITE-5038
> URL: https://issues.apache.org/jira/browse/IGNITE-5038
> Project: Ignite
>  Issue Type: New Feature
>  Components: cache
>Affects Versions: 2.0
>Reporter: Dmitry Karachentsev
>Assignee: Vladislav Pyatkov
>  Labels: features
> Fix For: 2.1
>
>
> There is a special use case discussed on the dev list:
> http://apache-ignite-developers.2346864.n4.nabble.com/Re-BinaryObjectImpl-deserializeValue-with-specific-ClassLoader-td17126.html#a17224
> According to the use case, BinaryMarshaller might need to try to deserialize 
> an object using a context class loader if it failed to do so with a custom 
> classloader (`IgniteConfiguration.getClassLoader()`) or the system one.



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

[jira] [Updated] (IGNITE-5277) Asynchronously establish connection to all the needed nodes in IgniteH2Indexing.send()

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5277:

Labels:   (was: important)

> Asynchronously establish connection to all the needed nodes in 
> IgniteH2Indexing.send()
> --
>
> Key: IGNITE-5277
> URL: https://issues.apache.org/jira/browse/IGNITE-5277
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Sergi Vladykin
> Fix For: 2.2
>
>
> it's only a minor optimization until the point when establishing each 
> connection takes 3-4 seconds, and we establish 32 of them in sequence.  At 
> that point it becomes a serious issue: the customer cannot run SQL queries 
> from their development machines



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

[jira] [Updated] (IGNITE-5277) Asynchronously establish connection to all the needed nodes in IgniteH2Indexing.send()

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5277:

Fix Version/s: (was: 2.1)
   2.2

> Asynchronously establish connection to all the needed nodes in 
> IgniteH2Indexing.send()
> --
>
> Key: IGNITE-5277
> URL: https://issues.apache.org/jira/browse/IGNITE-5277
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Sergi Vladykin
> Fix For: 2.2
>
>
> it's only a minor optimization until the point when establishing each 
> connection takes 3-4 seconds, and we establish 32 of them in sequence.  At 
> that point it becomes a serious issue: the customer cannot run SQL queries 
> from their development machines



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

[jira] [Commented] (IGNITE-4904) .NET: DML via LINQ

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-4904:


{{RemoveAll}} done, TC looks good. [~vozerov] please have a look. 
I think we should release {{RemoveAll}} now and implement {{UpdateAll}} later 
(it is a lot more complicated), do you agree?

> .NET: DML via LINQ
> --
>
> Key: IGNITE-4904
> URL: https://issues.apache.org/jira/browse/IGNITE-4904
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.9
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET, LINQ
> Fix For: 2.1
>
>
> Perform bulk update operations via LINQ: {{UPDATE WHERE}}, {{DELETE WHERE}}. 
> Insert can already be done on object level with {{ICache.PutAll}}.
> 1) {{DELETE WHERE}}. This is quite simple. We can provide an extension method 
> like this:
> {code}
> public static int DeleteAll(this ICache cache, 
> IQueryable> items);
> {code}
> 2) {{UPDATE WHERE}}. This is tricky, because LINQ only works with expression 
> trees, and multi-line methods are not supported. We should come up with a way 
> to provide a list of columns and values, something like
> {code}
> public static int UpdateAll(this ICache cache, 
> IQueryable> items, params UpdateAction[] actions);
> {code}
> where UpdateAction can consist of a MemberExpression and a value for that 
> member.
> We should probably do delete as a separate task first.



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

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

[Alexandr Kuramshin (JIRA)]

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

Alexandr Kuramshin reassigned IGNITE-4496:
--

 Assignee: Semen Boikov  (was: Alexandr Kuramshin)
Fix Version/s: 2.1
Affects Version/s: 2.0

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

> Review all logging for sensitive data leak
> --
>
> Key: IGNITE-4496
> URL: https://issues.apache.org/jira/browse/IGNITE-4496
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Alexandr Kuramshin
>Assignee: Semen Boikov
> Fix For: 2.1
>
>
> 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)