[jira] [Assigned] (IGNITE-2619) BinaryObjectException: Cannot find schema for object with compact footer

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-2619:
---

Assignee: Vladimir Ozerov

> BinaryObjectException: Cannot find schema for object with compact footer
> 
>
> Key: IGNITE-2619
> URL: https://issues.apache.org/jira/browse/IGNITE-2619
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Semen Boikov
>Assignee: Vladimir Ozerov
>Priority: Critical
>
> Added test CacheQueryBuildValueTest:
> - first build and put in cache object without indexed field
> - then build and put in cache object with indexed field 
> - second put fails with error 'BinaryObjectException: Cannot find schema for 
> object with compact footer'



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

[jira] [Updated] (IGNITE-2619) BinaryObjectException: Cannot find schema for object with compact footer

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2619:

Fix Version/s: (was: 1.7)

> BinaryObjectException: Cannot find schema for object with compact footer
> 
>
> Key: IGNITE-2619
> URL: https://issues.apache.org/jira/browse/IGNITE-2619
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Semen Boikov
>Assignee: Vladimir Ozerov
>Priority: Critical
>
> Added test CacheQueryBuildValueTest:
> - first build and put in cache object without indexed field
> - then build and put in cache object with indexed field 
> - second put fails with error 'BinaryObjectException: Cannot find schema for 
> object with compact footer'



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

[jira] [Updated] (IGNITE-2619) BinaryObjectException: Cannot find schema for object with compact footer

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2619:

Assignee: (was: Vladimir Ozerov)

> BinaryObjectException: Cannot find schema for object with compact footer
> 
>
> Key: IGNITE-2619
> URL: https://issues.apache.org/jira/browse/IGNITE-2619
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Semen Boikov
>Priority: Critical
>
> Added test CacheQueryBuildValueTest:
> - first build and put in cache object without indexed field
> - then build and put in cache object with indexed field 
> - second put fails with error 'BinaryObjectException: Cannot find schema for 
> object with compact footer'



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

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

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-1543:

Fix Version/s: 1.8

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



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

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

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-1543:

Fix Version/s: (was: 1.7)

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



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

[jira] [Updated] (IGNITE-2974) ODBC: Implement fine-grained NIO server configuration.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2974:

Assignee: (was: Vladimir Ozerov)

> ODBC: Implement fine-grained NIO server configuration.
> --
>
> Key: IGNITE-2974
> URL: https://issues.apache.org/jira/browse/IGNITE-2974
> Project: Ignite
>  Issue Type: Task
>  Components: general, odbc
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>
> ODBC uses {{GridNioServer}} internally to handle user requests. This server 
> has a number of properties, e.g. selector count buffer size, etc. 
> We can expose these properties in {{OdbcConfiguration}}, but it appears to be 
> too complex for users. Moreover, this is not the only component where we need 
> NIO server configuration.
> I propose to create separate bean and name it {{ServerConfiguration}}. This 
> bean will be used in ODBC and any other component.



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

[jira] [Updated] (IGNITE-3342) Hadoop: improve Java options documentation.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-3342:

Assignee: (was: Vladimir Ozerov)

> Hadoop: improve Java options documentation.
> ---
>
> Key: IGNITE-3342
> URL: https://issues.apache.org/jira/browse/IGNITE-3342
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation, hadoop
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Priority: Critical
>
> 1) Mentioned library path;
> 2) CMS garbage collector with class unloading options;
> 3) PermGetn/MetaSpace
> 4) Code cache
> Examples:
> *Java 8*
> {{-J-XX:MaxMetaspaceSize=[VALUE] -J-XX:ReservedCodeCacheSize=768m 
> -J-XX:+UseConcMarkSweepGC -J-XX:+CMSClassUnloadingEnabled 
> -J-XX:+CMSPermGenSweepingEnabled 
> -J-Djava.library.path=/usr/iop/current/hadoop/lib/native/}}
> *Java 7*
> {{-J-XX:MaxPermSize=[VALUE] -J-XX:ReservedCodeCacheSize=768m 
> -J-XX:+UseConcMarkSweepGC -J-XX:+CMSClassUnloadingEnabled 
> -J-XX:+CMSPermGenSweepingEnabled 
> -J-Djava.library.path=/usr/iop/current/hadoop/lib/native/}}



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

[jira] [Updated] (IGNITE-3342) Hadoop: improve Java options documentation.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-3342:

Fix Version/s: (was: 1.8)

> Hadoop: improve Java options documentation.
> ---
>
> Key: IGNITE-3342
> URL: https://issues.apache.org/jira/browse/IGNITE-3342
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation, hadoop
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
>
> 1) Mentioned library path;
> 2) CMS garbage collector with class unloading options;
> 3) PermGetn/MetaSpace
> 4) Code cache
> Examples:
> *Java 8*
> {{-J-XX:MaxMetaspaceSize=[VALUE] -J-XX:ReservedCodeCacheSize=768m 
> -J-XX:+UseConcMarkSweepGC -J-XX:+CMSClassUnloadingEnabled 
> -J-XX:+CMSPermGenSweepingEnabled 
> -J-Djava.library.path=/usr/iop/current/hadoop/lib/native/}}
> *Java 7*
> {{-J-XX:MaxPermSize=[VALUE] -J-XX:ReservedCodeCacheSize=768m 
> -J-XX:+UseConcMarkSweepGC -J-XX:+CMSClassUnloadingEnabled 
> -J-XX:+CMSPermGenSweepingEnabled 
> -J-Djava.library.path=/usr/iop/current/hadoop/lib/native/}}



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

[jira] [Updated] (IGNITE-2978) Optimize field set inside Java object factory.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2978:

Labels: performance  (was: )

> Optimize field set inside Java object factory.
> --
>
> Key: IGNITE-2978
> URL: https://issues.apache.org/jira/browse/IGNITE-2978
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Priority: Critical
>  Labels: performance
>
> Cache resolved fields. Need to be careful to avoid class leaks.



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

[jira] [Updated] (IGNITE-1785) .Net: Improve PlatformMemory/PortableStream performance and memory usage

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-1785:

Labels: .net performance  (was: .net)

> .Net: Improve PlatformMemory/PortableStream performance and memory usage
> 
>
> Key: IGNITE-1785
> URL: https://issues.apache.org/jira/browse/IGNITE-1785
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Pavel Tupitsyn
>  Labels: .net, performance
>
> * PlatformMemory is just a single "long _memPtr" and can be easily converted 
> to a struct to reduce allocations (it is allocated a lot)
> * PlatformMemoryStream works with PlatformMemory.Length and Capacity 
> indirectly. By employing a struct approach from 
> https://issues.apache.org/jira/browse/IGNITE-1428 we can work with Length and 
> Capacity directly, which may be faster, and will eliminate the need for 
> SyncronizeInput/Output calls.
> * PlatformMemoryStream is allocated even more often than PlatformMemory, need 
> to investigate whether it can also be a struct. See how List<>.GetEnumerator 
> works, which is a struct.



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

[jira] [Updated] (IGNITE-2978) Optimize field set inside Java object factory.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2978:

Assignee: (was: Vladimir Ozerov)

> Optimize field set inside Java object factory.
> --
>
> Key: IGNITE-2978
> URL: https://issues.apache.org/jira/browse/IGNITE-2978
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Priority: Critical
>  Labels: performance
>
> Cache resolved fields. Need to be careful to avoid class leaks.



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

[jira] [Updated] (IGNITE-2978) Optimize field set inside Java object factory.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2978:

Fix Version/s: (was: 1.8)

> Optimize field set inside Java object factory.
> --
>
> Key: IGNITE-2978
> URL: https://issues.apache.org/jira/browse/IGNITE-2978
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
>  Labels: performance
>
> Cache resolved fields. Need to be careful to avoid class leaks.



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

[jira] [Updated] (IGNITE-1428) .Net: Use struct with fixed layout for InteropMemory operations.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-1428:

Labels: .net  (was: .net performance)

> .Net: Use struct with fixed layout for InteropMemory operations.
> 
>
> Key: IGNITE-1428
> URL: https://issues.apache.org/jira/browse/IGNITE-1428
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Minor
>  Labels: .net
> Fix For: 1.8
>
>
> This will decrease probability of bugs caused by pointer arithmetics.



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

[jira] [Updated] (IGNITE-1428) .Net: Use struct with fixed layout for InteropMemory operations.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-1428:

Labels: .net performance  (was: .net)

> .Net: Use struct with fixed layout for InteropMemory operations.
> 
>
> Key: IGNITE-1428
> URL: https://issues.apache.org/jira/browse/IGNITE-1428
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Minor
>  Labels: .net
> Fix For: 1.8
>
>
> This will decrease probability of bugs caused by pointer arithmetics.



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

[jira] [Updated] (IGNITE-1430) Platforms: Incorrect behavior of write-behind store on node stop

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-1430:

Fix Version/s: (was: 1.8)

> Platforms: Incorrect behavior of write-behind store on node stop
> 
>
> Key: IGNITE-1430
> URL: https://issues.apache.org/jira/browse/IGNITE-1430
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>Priority: Blocker
>
> We destroy unmanaged native resources on node "stop" phase. But write-behind 
> store can still have som unflushed data at this point because cache processor 
> is not stoped yet.
> To fix this we must add more callbacks to platform processor which are 
> invoked before any component is started and after any component is stopped.



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

[jira] [Updated] (IGNITE-2493) Get rid fo sun.misc.Cleaner in PlatformMemoryPool.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2493:

Assignee: (was: Vladimir Ozerov)

> Get rid fo sun.misc.Cleaner in PlatformMemoryPool.
> --
>
> Key: IGNITE-2493
> URL: https://issues.apache.org/jira/browse/IGNITE-2493
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>




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

[jira] [Updated] (IGNITE-2109) PlatformUtils.errorData() contains invalid call to PlatformInputStream.remaining()

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2109:

Fix Version/s: (was: 1.8)

> PlatformUtils.errorData() contains invalid call to 
> PlatformInputStream.remaining()
> --
>
> Key: IGNITE-2109
> URL: https://issues.apache.org/jira/browse/IGNITE-2109
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>
> See the following line:
> {code}int len = in.remaining();{code}
> WTF is that? Probably "length()" method should be called instead.



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

[jira] [Updated] (IGNITE-2493) Get rid fo sun.misc.Cleaner in PlatformMemoryPool.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2493:

Fix Version/s: (was: 1.8)

> Get rid fo sun.misc.Cleaner in PlatformMemoryPool.
> --
>
> Key: IGNITE-2493
> URL: https://issues.apache.org/jira/browse/IGNITE-2493
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>




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

[jira] [Updated] (IGNITE-2109) PlatformUtils.errorData() contains invalid call to PlatformInputStream.remaining()

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2109:

Assignee: (was: Vladimir Ozerov)

> PlatformUtils.errorData() contains invalid call to 
> PlatformInputStream.remaining()
> --
>
> Key: IGNITE-2109
> URL: https://issues.apache.org/jira/browse/IGNITE-2109
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>
> See the following line:
> {code}int len = in.remaining();{code}
> WTF is that? Probably "length()" method should be called instead.



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

[jira] [Updated] (IGNITE-1430) Platforms: Incorrect behavior of write-behind store on node stop

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-1430:

Assignee: (was: Vladimir Ozerov)

> Platforms: Incorrect behavior of write-behind store on node stop
> 
>
> Key: IGNITE-1430
> URL: https://issues.apache.org/jira/browse/IGNITE-1430
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>Priority: Blocker
>
> We destroy unmanaged native resources on node "stop" phase. But write-behind 
> store can still have som unflushed data at this point because cache processor 
> is not stoped yet.
> To fix this we must add more callbacks to platform processor which are 
> invoked before any component is started and after any component is stopped.



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

[jira] [Updated] (IGNITE-3159) WebSession: Incorrect handling of HttpServletRequest.getRequestedSessionId.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-3159:

Assignee: (was: Vladimir Ozerov)

> WebSession: Incorrect handling of HttpServletRequest.getRequestedSessionId.
> ---
>
> Key: IGNITE-3159
> URL: https://issues.apache.org/jira/browse/IGNITE-3159
> Project: Ignite
>  Issue Type: Bug
>  Components: websession
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
> Fix For: 1.8
>
>
> {{WebSessionFilter}} use HttpServletRequest.getRequestedSessionId() method to 
> get session ID.
> However, specification says that this method might return ID which is 
> different from ID of currently active session. E.g. when request is performed 
> with ID of already invalidated session. But we never account for this and 
> pass this session ID to our session.



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

[jira] [Closed] (IGNITE-1346) Implement striped spin busy lock.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-1346.
---

> Implement striped spin busy lock.
> -
>
> Key: IGNITE-1346
> URL: https://issues.apache.org/jira/browse/IGNITE-1346
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> We have lots of places in code which require "busy" state semantics:
> 1) Multiple readers access some resource concurrently setting "busy" state.
> 2) At some point a single writer comes, prevents all further readers from 
> accessing the resource, and blocks until all other previous reades are out.
> Currently we do that using either GridBusyLock or GridSpinBusyLock. The first 
> one is based on ReentrantReadWriteLock and the second one is based on 
> GridSpinReadWriteLock. 
> Both implementation have the same performance characteristics, being limited 
> by CPU bus bandwidth when trying to update atomically a shared variable. 
> Better approach is to "stripe" the lock across multiple variables this 
> minimizing contention between threads. That is, in ideal case each thread 
> increments/decrements his own variable without any contention. Writer will 
> have to iterate over all these variables and block on each until all readers 
> are out.



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

[jira] [Updated] (IGNITE-1346) Implement striped spin busy lock.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-1346:

Fix Version/s: (was: 1.8)
   1.6

> Implement striped spin busy lock.
> -
>
> Key: IGNITE-1346
> URL: https://issues.apache.org/jira/browse/IGNITE-1346
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> We have lots of places in code which require "busy" state semantics:
> 1) Multiple readers access some resource concurrently setting "busy" state.
> 2) At some point a single writer comes, prevents all further readers from 
> accessing the resource, and blocks until all other previous reades are out.
> Currently we do that using either GridBusyLock or GridSpinBusyLock. The first 
> one is based on ReentrantReadWriteLock and the second one is based on 
> GridSpinReadWriteLock. 
> Both implementation have the same performance characteristics, being limited 
> by CPU bus bandwidth when trying to update atomically a shared variable. 
> Better approach is to "stripe" the lock across multiple variables this 
> minimizing contention between threads. That is, in ideal case each thread 
> increments/decrements his own variable without any contention. Writer will 
> have to iterate over all these variables and block on each until all readers 
> are out.



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

[jira] [Resolved] (IGNITE-1346) Implement striped spin busy lock.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov resolved IGNITE-1346.
-
Resolution: Fixed

> Implement striped spin busy lock.
> -
>
> Key: IGNITE-1346
> URL: https://issues.apache.org/jira/browse/IGNITE-1346
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 1.8
>
>
> We have lots of places in code which require "busy" state semantics:
> 1) Multiple readers access some resource concurrently setting "busy" state.
> 2) At some point a single writer comes, prevents all further readers from 
> accessing the resource, and blocks until all other previous reades are out.
> Currently we do that using either GridBusyLock or GridSpinBusyLock. The first 
> one is based on ReentrantReadWriteLock and the second one is based on 
> GridSpinReadWriteLock. 
> Both implementation have the same performance characteristics, being limited 
> by CPU bus bandwidth when trying to update atomically a shared variable. 
> Better approach is to "stripe" the lock across multiple variables this 
> minimizing contention between threads. That is, in ideal case each thread 
> increments/decrements his own variable without any contention. Writer will 
> have to iterate over all these variables and block on each until all readers 
> are out.



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

[jira] [Updated] (IGNITE-1962) Binary writer: implement speculative field ID guessing.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-1962:

Labels: performance  (was: )

> Binary writer: implement speculative field ID guessing.
> ---
>
> Key: IGNITE-1962
> URL: https://issues.apache.org/jira/browse/IGNITE-1962
> Project: Ignite
>  Issue Type: Task
>  Components: general, platforms
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>  Labels: performance
>
> Field ID calculation with deafult ID mapper is relatively costly operation. 
> It can be avoided in most cases if we implement a kind of table for 
> speculative guessing. It will track performed write "tracks" and do it's best 
> to avoid ID mapper call.
> We already have this tecnique in .NET and it shown pretty good marshlling 
> perf improvement.



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

[jira] [Commented] (IGNITE-1977) IgniteSemaphore's failover related tests lead to the deadlock or fail

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-1977:
-

Looks like this ticket was incorrectly assigned to me. Vladislav, I re-assigned 
it to you because it looks like you are currently working on it. Please correct 
me if I wrong.

> IgniteSemaphore's failover related tests lead to the deadlock or fail
> -
>
> Key: IGNITE-1977
> URL: https://issues.apache.org/jira/browse/IGNITE-1977
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Vladisav Jelisavcic
>
> All {{IgniteSemaphore}} related tests from 
> {{GridCacheAbstractDataStructuresFailoverSelfTest}} may cause a deadlock 
> which leads to the whole suite hanging.
> The threads are waiting for the following condition:
> {noformat}
> "topology-change-thread-3" prio=6 tid=0x1d98d800 nid=0x2b20 waiting 
> on condition [0x2066f000]
>java.lang.Thread.State: WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for  <0x000798149948> (a 
> org.apache.ignite.internal.processors.datastructures.GridCacheSemaphoreImpl$Sync)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
>   at 
> org.apache.ignite.internal.processors.datastructures.GridCacheSemaphoreImpl.acquire(GridCacheSemaphoreImpl.java:538)
>   at 
> org.apache.ignite.internal.processors.datastructures.GridCacheSemaphoreImpl.acquire(GridCacheSemaphoreImpl.java:525)
>   at 
> org.apache.ignite.internal.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest$7.apply(GridCacheAbstractDataStructuresFailoverSelfTest.java:571)
>   at 
> org.apache.ignite.internal.util.lang.GridAbsClosure.run(GridAbsClosure.java:50)
>   at 
> org.apache.ignite.testframework.GridTestUtils$7.call(GridTestUtils.java:967)
>   at 
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
> {noformat}
> Probably the semaphore is not properly released when a node leaves the 
> topology abruptly.
> In addition the tests should be rewritten to the way which is followed by 
> other data structures and atomics from this suite: using 
> {{ConstantTopologyChangeWorker}} and its descendants.



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

[jira] [Resolved] (IGNITE-2418) .NET: Combine .Net example configuration files into one like for Java examples

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov resolved IGNITE-2418.
-
Resolution: Duplicate

Already resolved as a part of Ignite 1.7.

> .NET: Combine .Net example configuration files into one like for Java examples
> --
>
> Key: IGNITE-2418
> URL: https://issues.apache.org/jira/browse/IGNITE-2418
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Sergey Kozlov
>Assignee: Vladimir Ozerov
>Priority: Minor
>  Labels: .net, roadmap
>
> .Net platform examples required a set of configuration files. But if there's 
> no significant reason for that then we can just combine into one like it 
> impemented for Java



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

[jira] [Updated] (IGNITE-1977) IgniteSemaphore's failover related tests lead to the deadlock or fail

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-1977:

Assignee: Vladisav Jelisavcic  (was: Vladimir Ozerov)

> IgniteSemaphore's failover related tests lead to the deadlock or fail
> -
>
> Key: IGNITE-1977
> URL: https://issues.apache.org/jira/browse/IGNITE-1977
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Vladisav Jelisavcic
>
> All {{IgniteSemaphore}} related tests from 
> {{GridCacheAbstractDataStructuresFailoverSelfTest}} may cause a deadlock 
> which leads to the whole suite hanging.
> The threads are waiting for the following condition:
> {noformat}
> "topology-change-thread-3" prio=6 tid=0x1d98d800 nid=0x2b20 waiting 
> on condition [0x2066f000]
>java.lang.Thread.State: WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for  <0x000798149948> (a 
> org.apache.ignite.internal.processors.datastructures.GridCacheSemaphoreImpl$Sync)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
>   at 
> org.apache.ignite.internal.processors.datastructures.GridCacheSemaphoreImpl.acquire(GridCacheSemaphoreImpl.java:538)
>   at 
> org.apache.ignite.internal.processors.datastructures.GridCacheSemaphoreImpl.acquire(GridCacheSemaphoreImpl.java:525)
>   at 
> org.apache.ignite.internal.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest$7.apply(GridCacheAbstractDataStructuresFailoverSelfTest.java:571)
>   at 
> org.apache.ignite.internal.util.lang.GridAbsClosure.run(GridAbsClosure.java:50)
>   at 
> org.apache.ignite.testframework.GridTestUtils$7.call(GridTestUtils.java:967)
>   at 
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
> {noformat}
> Probably the semaphore is not properly released when a node leaves the 
> topology abruptly.
> In addition the tests should be rewritten to the way which is followed by 
> other data structures and atomics from this suite: using 
> {{ConstantTopologyChangeWorker}} and its descendants.



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

[jira] [Updated] (IGNITE-1324) Optimize platform entry processor for local execution.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-1324:

Labels: performance  (was: )

> Optimize platform entry processor for local execution.
> --
>
> Key: IGNITE-1324
> URL: https://issues.apache.org/jira/browse/IGNITE-1324
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>Priority: Critical
>  Labels: performance
>
> Currently entry processor is passed to Java as if it was remote, even for 
> local execution. As a result, local execution require additional 
> marshal-unmarshal cycle to execute it on native platform (that is, pointer 
> field is always 0)).
> We need to optimize it.



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

[jira] [Updated] (IGNITE-1321) Revisit PlatformAbstractTask locking logic.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-1321:

Labels: performance  (was: )

> Revisit PlatformAbstractTask locking logic.
> ---
>
> Key: IGNITE-1321
> URL: https://issues.apache.org/jira/browse/IGNITE-1321
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>  Labels: performance
>
> Currently it is implemented with RW lock to ensure that task cannot be 
> cancelled/completed concurrently when notie platform process job result. 
> This was done when we were dealing with non-unique native pointers.
> Now this is not a problem because we use "handle registry" approach and all 
> "pointers" are guaranteed to be unique. Therefore, probably we can get rid of 
> this lock at all.



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

[jira] [Updated] (IGNITE-1352) Platforms: move cpp and .Net examples to Ignite

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-1352:

Assignee: (was: Vladimir Ozerov)

> Platforms: move cpp and .Net examples to Ignite
> ---
>
> Key: IGNITE-1352
> URL: https://issues.apache.org/jira/browse/IGNITE-1352
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>
> Move the platform examples to Ignite.
> Portable API examples have already been moved and the changes should be 
> committed to the master soon. Track IGNITE-1351 status for that.
> When the platform examples are moved make sure that 
> {{CacheClientPortableCrossPlatformExample}} works as expected.



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

[jira] [Updated] (IGNITE-1324) Optimize platform entry processor for local execution.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-1324:

Assignee: (was: Vladimir Ozerov)

> Optimize platform entry processor for local execution.
> --
>
> Key: IGNITE-1324
> URL: https://issues.apache.org/jira/browse/IGNITE-1324
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>Priority: Critical
>  Labels: performance
>
> Currently entry processor is passed to Java as if it was remote, even for 
> local execution. As a result, local execution require additional 
> marshal-unmarshal cycle to execute it on native platform (that is, pointer 
> field is always 0)).
> We need to optimize it.



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

[jira] [Updated] (IGNITE-1321) Revisit PlatformAbstractTask locking logic.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-1321:

Assignee: (was: Vladimir Ozerov)

> Revisit PlatformAbstractTask locking logic.
> ---
>
> Key: IGNITE-1321
> URL: https://issues.apache.org/jira/browse/IGNITE-1321
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>
> Currently it is implemented with RW lock to ensure that task cannot be 
> cancelled/completed concurrently when notie platform process job result. 
> This was done when we were dealing with non-unique native pointers.
> Now this is not a problem because we use "handle registry" approach and all 
> "pointers" are guaranteed to be unique. Therefore, probably we can get rid of 
> this lock at all.



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

[jira] [Commented] (IGNITE-3331) IGFS: Route client tasks to primary node when metadata co-location is enabled.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-3331:
-

Patch looks good for me. Need to test it's perf.

> IGFS: Route client tasks to primary node when metadata co-location is enabled.
> --
>
> Key: IGNITE-3331
> URL: https://issues.apache.org/jira/browse/IGNITE-3331
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>Priority: Critical
>  Labels: important, performance
> Fix For: 1.8
>
>
> Currently we route IGFS client tasks to random metadata data node. When 
> co-location is enabled, it makes sense to requests which are going to change 
> metadata directly to primary node. 



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

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

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-3625:

Description: 
Currently IGFS is configured by passing names of two caches: meta and data. See 
{{FileSystemConfiguration.metaCacheName}} and 
{{FileSystemConfiguration.dataCacheName}}.

These two caches are considered internal then and are not accessible for the 
user.

We need to do the following during node startup:

1) If certain cache is configured as meta or data cache for multiple IGFS-es, 
or if it is configured as both meta and data cache for a single IGFS, then 
throw an exception.
Relevant code pieces:
{{IgfsProcessor.validateLocalIgfsConfigurations}}
{{IgfsProcessorSelfTest}}.

2) During node startup change the name of this cache to {{igfs-IGFS_NAME-meta}} 
or {{igfs-IGFS_NAME-data}}. Change must be performed both inside IGFS config 
and cache config.
Relevant code pieces:
{{CacheConfiguration.name}}
{{FileSystemConfiguration.metaCacheName}}
{{FileSystemConfiguration.dataCacheName}}
{{IgfsUtils.prepareCacheConfiguration}} - where change will be done.

3) If any of new names clashes with any other cache name, an exception should 
be thrown. The most simple way: throw an exception if user-configured cache 
name starts with "{{gfs-}} and ends with {{-meta}} or {{-data}}.
Relevant code pieces:
{{IgniteNamedInstance.initializeDefaultCacheConfiguration}}.

  was:
Currently IGFS is configured by passing names of two caches: meta and data. See 
{{FileSystemConfiguration.metaCacheName}} and 
{{FileSystemConfiguration.dataCacheName}}.

These two caches are considered internal then and are not accessible for the 
user.

We need to do the following during node startup:

1) If certain cache is configured as meta or data cache for multiple IGFS-es, 
or if it is configured as both meta and data cache for a single IGFS, then 
throw an exception.
Relevant code pieces:
{{IgfsProcessor.validateLocalIgfsConfigurations}}
{{IgfsProcessorSelfTest}}.

2) During node startup change the name of this cache to 
{{igfs-[IGFS_NAME]-meta}} or {{igfs-[IGFS_NAME]-data}}. Change must be 
performed both inside IGFS config and cache config.
Relevant code pieces:
{{CacheConfiguration.name}}
{{FileSystemConfiguration.metaCacheName}}
{{FileSystemConfiguration.dataCacheName}}
{{IgfsUtils.prepareCacheConfiguration}} - where change will be done.

3) If any of new names clashes with any other cache name, an exception should 
be thrown. The most simple way: throw an exception if user-configured cache 
name starts with "{{gfs-}} and ends with {{-meta}} or {{-data}}.
Relevant code pieces:
{{IgniteNamedInstance.initializeDefaultCacheConfiguration}}.


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



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

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

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-3625:
---

 Summary: IGFS: Use common naming for IGFS meta and data caches.
 Key: IGNITE-3625
 URL: https://issues.apache.org/jira/browse/IGNITE-3625
 Project: Ignite
  Issue Type: Task
  Components: IGFS
Affects Versions: 1.6
Reporter: Vladimir Ozerov
Assignee: Taras Ledkov
 Fix For: 1.8


Currently IGFS is configured by passing names of two caches: meta and data. See 
{{FileSystemConfiguration.metaCacheName}} and 
{{FileSystemConfiguration.dataCacheName}}.

These two caches are considered internal then and are not accessible for the 
user.

We need to do the following during node startup:

1) If certain cache is configured as meta or data cache for multiple IGFS-es, 
or if it is configured as both meta and data cache for a single IGFS, then 
throw an exception.
Relevant code pieces:
{{IgfsProcessor.validateLocalIgfsConfigurations}}
{{IgfsProcessorSelfTest}}.

2) During node startup change the name of this cache to 
{{igfs-[IGFS_NAME]-meta}} or {{igfs-[IGFS_NAME]-data}}. Change must be 
performed both inside IGFS config and cache config.
Relevant code pieces:
{{CacheConfiguration.name}}
{{FileSystemConfiguration.metaCacheName}}
{{FileSystemConfiguration.dataCacheName}}
{{IgfsUtils.prepareCacheConfiguration}} - where change will be done.

3) If any of new names clashes with any other cache name, an exception should 
be thrown. The most simple way: throw an exception if user-configured cache 
name starts with "{{gfs-}} and ends with {{-meta}} or {{-data}}.
Relevant code pieces:
{{IgniteNamedInstance.initializeDefaultCacheConfiguration}}.



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

[jira] [Closed] (IGNITE-3335) IGFS: Route client requests only to metadata affinity nodes.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-3335.
---

> IGFS: Route client requests only to metadata affinity nodes. 
> -
>
> Key: IGNITE-3335
> URL: https://issues.apache.org/jira/browse/IGNITE-3335
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>  Labels: important, performance
> Fix For: 1.8
>
>




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

[jira] [Assigned] (IGNITE-3335) IGFS: Route client requests only to metadata affinity nodes.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-3335:
---

Assignee: Vladimir Ozerov

> IGFS: Route client requests only to metadata affinity nodes. 
> -
>
> Key: IGNITE-3335
> URL: https://issues.apache.org/jira/browse/IGNITE-3335
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>  Labels: important, performance
> Fix For: 1.8
>
>




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

[jira] [Resolved] (IGNITE-3335) IGFS: Route client requests only to metadata affinity nodes.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov resolved IGNITE-3335.
-
Resolution: Duplicate

Already fixed as part of one of the previous ticket.

> IGFS: Route client requests only to metadata affinity nodes. 
> -
>
> Key: IGNITE-3335
> URL: https://issues.apache.org/jira/browse/IGNITE-3335
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>  Labels: important, performance
> Fix For: 1.8
>
>




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

[jira] [Commented] (IGNITE-2079) GridCacheIoManager eats exception trail if it falls into the directed case

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-2079:
-

[~AndreyVel], do you have any progress on this? When you expect to finish 
working on the issue?

> GridCacheIoManager eats exception trail if it falls into the directed case
> --
>
> Key: IGNITE-2079
> URL: https://issues.apache.org/jira/browse/IGNITE-2079
> Project: Ignite
>  Issue Type: Bug
>Reporter: Anton Vinogradov
>Assignee: Andrey Velichko
>  Labels: ignite-3424
> Fix For: 1.7
>
> Attachments: IgniteCacheP2pUnmarshallingContinuousQueryErrorTest.java
>
>
> During a recent test I have run into an issue where a storage disabled client 
> of a Fabric that has services deployed for which the client does not have the 
> fabric in the class path failed with the following exception:
> com.company.fabric.HelloWorldTest STANDARD_ERROR
> Nov 08, 2015 6:15:20 PM org.apache.ignite.logger.java.JavaLogger error
> SEVERE: Failed to process message 
> [senderId=30775397-457a-400f-a6c9-077c9e762d61, messageType=class 
> o.a.i.i.processors.cache.query.GridCacheQueryResponse]
> class org.apache.ignite.IgniteCheckedException: Failed to send response to 
> node. Unsupported direct type [message=GridCacheQueryResponse [finished=true, 
> reqId=5, err=null, fields=false, metadata=null]]
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processFailedMessage(GridCacheIoManager.java:546)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:272)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$700(GridCacheIoManager.java:77)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1078)
>  at 
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2302)
>  at 
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:992)
>  at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1700(GridIoManager.java:106)
>  at 
> org.apache.ignite.internal.managers.communication.GridIoManager$6.run(GridIoManager.java:961)
>  at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  at java.lang.Thread.run(Thread.java:745)
> This unfortunately gives me 0 information to work on to resolve the issue, as 
> the original unmarshalling exception (from the JdkMarshaller) was eaten as 
> this is the code for the default process failed message:
> default:
> throw new IgniteCheckedException("Failed to send response to node. 
> Unsupported direct type [message="
> + msg + "]");
> }
> you should also include the original stack from msg.getError() in the newly 
> thrown IgniteCheckedException



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

[jira] [Commented] (IGNITE-1192) Provide integration with Spring Data

[Dmitriy Setrakyan (JIRA)]

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

Dmitriy Setrakyan commented on IGNITE-1192:
---

Eduard,
1. Please advance the ticket Patch Available status
2. Feel free to start a discussion on the dev list and propose a few things.

> Provide integration with Spring Data
> 
>
> Key: IGNITE-1192
> URL: https://issues.apache.org/jira/browse/IGNITE-1192
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.1.4
>Reporter: Valentin Kulichenko
>Assignee: Eduard Shangareev
>Priority: Minor
>  Labels: Newbie
> Fix For: 1.7
>
>
> Spring Data docs:
> * http://docs.spring.io/spring-data/data-commons/docs/current/reference/html/
> * http://docs.spring.io/spring-data/data-commons/docs/current/api/



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

[jira] [Created] (IGNITE-3624) Provide API to get the size of the cache in bytes

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-3624:
---

 Summary: Provide API to get the size of the cache in bytes
 Key: IGNITE-3624
 URL: https://issues.apache.org/jira/browse/IGNITE-3624
 Project: Ignite
  Issue Type: New Feature
  Components: cache
Affects Versions: 1.6
Reporter: Valentin Kulichenko


Sometimes it's useful to know how much memory cache objects consume. We can add 
{{memorySize()}} method to {{CacheMetrics}} and calculate the value  in the 
same way as we do in {{LruEvictionPolicy}}. This works only when cache 
statistics are enabled.



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

[jira] [Commented] (IGNITE-1192) Provide integration with Spring Data

[Eduard Shangareev (JIRA)]

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

Eduard Shangareev commented on IGNITE-1192:
---

The first prototype is available.

https://github.com/EdShangGG/ignite/blob/IGNITE-1192/modules/spring-data/src/test/java/org/ignite/spring/data/FirstRepository.java

Now the repository works.

But there are many things to do. Also, need start discussion about what exactly 
we want to achieve.

> Provide integration with Spring Data
> 
>
> Key: IGNITE-1192
> URL: https://issues.apache.org/jira/browse/IGNITE-1192
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.1.4
>Reporter: Valentin Kulichenko
>Assignee: Eduard Shangareev
>Priority: Minor
>  Labels: Newbie
> Fix For: 1.7
>
>
> Spring Data docs:
> * http://docs.spring.io/spring-data/data-commons/docs/current/reference/html/
> * http://docs.spring.io/spring-data/data-commons/docs/current/api/



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

[jira] [Commented] (IGNITE-2310) Lock cache partition for affinityRun/affinityCall execution

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-2310:
--

[Test 
results|http://149.202.210.143:8111/viewQueued.html?itemId=298152=queuedBuildOverviewTab]
 after merge with 1.6.4

> Lock cache partition for affinityRun/affinityCall execution
> ---
>
> Key: IGNITE-2310
> URL: https://issues.apache.org/jira/browse/IGNITE-2310
> Project: Ignite
>  Issue Type: New Feature
>  Components: cache
>Reporter: Valentin Kulichenko
>Assignee: Taras Ledkov
>Priority: Critical
>  Labels: community
> Fix For: 1.7
>
>
> Partition of a key passed to {{affinityRun}} must be located on the affinity 
> node when a compute job is being sent to the node. The partition has to be 
> locked on the cache until the compute job is being executed. This will let to 
> execute queries safely (Scan or local SQL) over the data that is located 
> locally in the locked partition.
> In addition Ignite Compute API has to be extended by adding {{affinityCall}} 
> and {{affinityRun}} methods that accept list of caches which partitions have 
> to be locked at the time a compute task is being executed.
> Test cases to validate the functionality:
> 1) local SQL query over data located in a concrete partition in multple 
> caches.
> - create cache Organisation cache and create Persons cache.
> - collocate Persons by 'organisationID';
> - send {{affinityRun}} using 'organisationID' as an affinity key and passing 
> Organisation and Persons caches' names to the method to be sure that the 
> partition will be locked on caches;
> - execute local SQL query "SELECT * FROM Persons as p, Organisation as o 
> WHERE p.orgId=o.id' on a changing topology. The result set must be complete, 
> the partition over which the query will be executed mustn't be moved to the 
> other node. Due to affinity collocation the partition number will be the same 
> for all Persons that belong to particular 'organisationID'
> 2) Scan Query over particular partition that is locked when {{affinityCall}} 
> is executed.  
> UPD (YZ May, 31)
> # If closure arrives to node but partition is not there it should be silently 
> failed over to current owner.
> # I don't think user should provide list of caches. How about reserving only 
> one partition, but evict partitions after all partitions in all caches (with 
> same affinity function) on this node are locked for eviction. [~sboikov], can 
> you please comment? It seems this should work faster for closures and will 
> hardly affect rebalancing stuff.
> # I would add method {{affinityCall(int partId, String cacheName, 
> IgniteCallable)}} and same for Runnable. This will allow me not to mess with 
> affinity key in case I know partition before.
> UPD (SB, June, 01)
> Yakov, I think it is possible to implement this 'locking for evictions' 
> approach, but personally I better like partitions reservation:
> - approach with reservation already implemented and works fine in sql queries
> - partition reservation is just CAS operation, if we need do ~10 reservation 
> I think this will be negligible comparing to  job execution time
> - now caches are rebalanced completely independently and changing this be 
> complicated refactoring
> - I see some difficulties how to understand that caches have same affinity. 
> If user uses custom function should he implement 'equals'? For standard 
> affinity functions user can set backup filter, what do in this case? should 
> user implement 'equals' for filter? Even if affinity functions are the same 
> cache configuration can have node filter, so affinity mapping will be 
> different. 



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

[jira] [Commented] (IGNITE-1084) [Test] HibernateL2CacheSelfTest#testNaturalIdCache() is broken

[Yakov Zhdanov (JIRA)]

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

Yakov Zhdanov commented on IGNITE-1084:
---

[~milap.wadhwa] can you please describe your changes in a few words?

> [Test] HibernateL2CacheSelfTest#testNaturalIdCache() is broken
> --
>
> Key: IGNITE-1084
> URL: https://issues.apache.org/jira/browse/IGNITE-1084
> Project: Ignite
>  Issue Type: Test
>  Components: cache
>Reporter: Sergey Evdokimov
>Assignee: Milap Wadhwa
>Priority: Minor
>  Labels: Muted_test
>
> Test HibernateL2CacheSelfTest#testNaturalIdCache() should be unmuted and 
> fixed.



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

[jira] [Updated] (IGNITE-1629) .NET: Introduce native logging facility.

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-1629:
---
Summary: .NET: Introduce native logging facility.  (was: .Net: Introduce 
native logging facility.)

> .NET: Introduce native logging facility.
> 
>
> Key: IGNITE-1629
> URL: https://issues.apache.org/jira/browse/IGNITE-1629
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
>Priority: Blocker
>  Labels: .net, roadmap
> Fix For: 1.8
>
>
> This is pretty serious usability issue. Currently Ignite produces logs using 
> Java "log4j" library. While naural for Java environment, this is somewhat 
> alien for Windows users. 
> We need to investigate ability to hack into normal .Net logging frameworks. 
> This include both native Windows APIs (e.g. events), and widely-used .Net 
> loggers.



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

[jira] [Commented] (IGNITE-1629) .Net: Introduce native logging facility.

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-1629:


Investigating the approach with delegating to Java by default again, this will 
allow simpler transition to the new logging system.

> .Net: Introduce native logging facility.
> 
>
> Key: IGNITE-1629
> URL: https://issues.apache.org/jira/browse/IGNITE-1629
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
>Priority: Blocker
>  Labels: .net, roadmap
> Fix For: 1.8
>
>
> This is pretty serious usability issue. Currently Ignite produces logs using 
> Java "log4j" library. While naural for Java environment, this is somewhat 
> alien for Windows users. 
> We need to investigate ability to hack into normal .Net logging frameworks. 
> This include both native Windows APIs (e.g. events), and widely-used .Net 
> loggers.



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

[jira] [Updated] (IGNITE-3597) IgniteConfiguration.igniteWorkDir has no effect

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-3597:
-
Flags: Patch

> IgniteConfiguration.igniteWorkDir has no effect
> ---
>
> Key: IGNITE-3597
> URL: https://issues.apache.org/jira/browse/IGNITE-3597
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.5.0.final
>Reporter: Pavel Tupitsyn
>Assignee: Andrew Mashenkov
>Priority: Critical
>
> U.setWorkDirectory method ensures that work dir is set only once.
> If there are multiple nodes in a process, or a node is stopped and then 
> started, IgniteConfiguration.igniteWorkDir is ignored.



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

[jira] [Commented] (IGNITE-3331) IGFS: Route client tasks to primary node when metadata co-location is enabled.

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-3331:
--

[Tests 
results|http://149.202.210.143:8111/project.html?projectId=IgniteTests_IgniteTests=pull%2F921%2Fhead]

> IGFS: Route client tasks to primary node when metadata co-location is enabled.
> --
>
> Key: IGNITE-3331
> URL: https://issues.apache.org/jira/browse/IGNITE-3331
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>Priority: Critical
>  Labels: important, performance
> Fix For: 1.8
>
>
> Currently we route IGFS client tasks to random metadata data node. When 
> co-location is enabled, it makes sense to requests which are going to change 
> metadata directly to primary node. 



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

[jira] [Commented] (IGNITE-3331) IGFS: Route client tasks to primary node when metadata co-location is enabled.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-3331:


GitHub user tledkov-gridgain opened a pull request:

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

IGNITE-3331 IGFS: Route client tasks to primary node when metadata co…

…-location is enabled.

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

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

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

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


commit be6ad25e2107267928122cda93dfa28a0da2166d
Author: tledkov-gridgain 
Date:   2016-08-03T13:47:06Z

IGNITE-3331 IGFS: Route client tasks to primary node when metadata 
co-location is enabled.




> IGFS: Route client tasks to primary node when metadata co-location is enabled.
> --
>
> Key: IGNITE-3331
> URL: https://issues.apache.org/jira/browse/IGNITE-3331
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>Priority: Critical
>  Labels: important, performance
> Fix For: 1.8
>
>
> Currently we route IGFS client tasks to random metadata data node. When 
> co-location is enabled, it makes sense to requests which are going to change 
> metadata directly to primary node. 



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

[jira] [Commented] (IGNITE-1192) Provide integration with Spring Data

[Eduard Shangareev (JIRA)]

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

Eduard Shangareev commented on IGNITE-1192:
---

Well, because of Juan inactivity I have assigned the ticket to me myself.
Now I am investigation Spring Data entrails.

> Provide integration with Spring Data
> 
>
> Key: IGNITE-1192
> URL: https://issues.apache.org/jira/browse/IGNITE-1192
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.1.4
>Reporter: Valentin Kulichenko
>Assignee: Eduard Shangareev
>Priority: Minor
>  Labels: Newbie
> Fix For: 1.7
>
>
> Spring Data docs:
> * http://docs.spring.io/spring-data/data-commons/docs/current/reference/html/
> * http://docs.spring.io/spring-data/data-commons/docs/current/api/



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

[jira] [Assigned] (IGNITE-1192) Provide integration with Spring Data

[Eduard Shangareev (JIRA)]

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

Eduard Shangareev reassigned IGNITE-1192:
-

Assignee: Eduard Shangareev  (was: Juan C Fiorenzano)

> Provide integration with Spring Data
> 
>
> Key: IGNITE-1192
> URL: https://issues.apache.org/jira/browse/IGNITE-1192
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.1.4
>Reporter: Valentin Kulichenko
>Assignee: Eduard Shangareev
>Priority: Minor
>  Labels: Newbie
> Fix For: 1.7
>
>
> Spring Data docs:
> * http://docs.spring.io/spring-data/data-commons/docs/current/reference/html/
> * http://docs.spring.io/spring-data/data-commons/docs/current/api/



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

[jira] [Updated] (IGNITE-3293) AWS bootstrap scripts patch for Ignite-Cassandra

[Ilya Suntsov (JIRA)]

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

Ilya Suntsov updated IGNITE-3293:
-
Attachment: fail-03-08-cassandra-tests.zip

> AWS bootstrap scripts patch for Ignite-Cassandra 
> -
>
> Key: IGNITE-3293
> URL: https://issues.apache.org/jira/browse/IGNITE-3293
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.6, 1.7
>Reporter: Igor Rudyak
>Assignee: Nikolay Tikhonov
> Attachments: aws-linux-fail.zip, fail-03-08-cassandra-tests.zip, 
> logs-aws-linux-1307.zip, logs-aws-linux-fail-1407.zip, 
> logs-cassandra-ignite.zip, logs-gail-ignite-cass-0208.zip
>
>
> New version of AWS bootstrap script having:
> 1) Gaglia monitoring
> 2) Allows to manually trigger tests execution multiple times on the same 
> ifstastructure



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

[jira] [Commented] (IGNITE-3293) AWS bootstrap scripts patch for Ignite-Cassandra

[Ilya Suntsov (JIRA)]

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

Ilya Suntsov commented on IGNITE-3293:
--

Igor,

You a right. Sorry. As I understand latest commit is:
{noformat}
commit f41060473465f4843a2e28c42d52b3ab97cbf8ed
Author: Igor 
Date:   Tue Aug 2 17:01:31 2016 -0700

minor fix - "netty-all" removed from cassandra-all artifact exclusions

diff --git a/modules/cassandra/pom.xml b/modules/cassandra/pom.xml
index 91a8507..9fc880b 100644
--- a/modules/cassandra/pom.xml
+++ b/modules/cassandra/pom.xml
{noformat}
Right?

I've rebuilt ignite-cassandra-tests and ran "ignite" tests with 3 ignite and 
cassandra nodes and with 2 tests nodes. All work fine. 
But when I tried to change TESTS_TYPE to "cassandra" then got 2 new errors.

Ignite error:
{noformat}
Check your system clock
[ERROR] Failed to configure ganglia-core
[ERROR]-
[ERROR] Failed to start ignite node
[ERROR]-
upload: ../ignite-cassandra-tests/bootstrap/start_result to 
s3://qa-is-cass/test1/ignite/failure/ip-172-31-0-27.ec2.internal/__error__
[INFO] Removing ignite node registration from: 
s3://qa-is-cass/test1/ignite/discovery/ip-172-31-0-27.ec2.internal
[INFO] Node registration actually haven't been previously created
Aug 03 12:59:32 cloud-init[2723]: util.py[WARNING]: Failed running 
/var/lib/cloud/instance/scripts/part-001 [1]
Aug 03 12:59:32 cloud-init[2723]: cc_scripts_user.py[WARNING]: Failed to run 
module scripts-user (scripts in /var/lib/cloud/instance/scripts)
Aug 03 12:59:32 cloud-init[2723]: util.py[WARNING]: Running module scripts-user 
() failed
{noformat}

Cassandra error:
{noformat}
[INFO] Removing cassandra node registration from: 
s3://qa-is-cass/test1/cassandra/discovery/ip-172-31-0-233.ec2.internal
[INFO] Node registration actually haven't been previously created
[INFO] Trying to get first node lock: 
s3://qa-is-cass/test1/cassandra/first-node-lock
[INFO] Checking for the first node lock: 
s3://qa-is-cass/test1/cassandra/first-node-lock
[INFO] First node lock doesn't exist

[ERROR] Failed to create first node lock: 
s3://qa-is-cass/test1/cassandra/first-node-lock
[ERROR]-
[ERROR] Failed to start cassandra node
[ERROR]-
Completed 1 part(s) with ... file(s) remaining
[ERROR] Failed to drop report folder: 
s3://qa-is-cass/test1/cassandra/failure/ip-172-31-0-233.ec2.internal

[ERROR] Failed to export node start result to: 
s3://qa-is-cass/test1/cassandra/failure/ip-172-31-0-233.ec2.internal/__error__
[INFO] Removing cassandra node registration from: 
s3://qa-is-cass/test1/cassandra/discovery/ip-172-31-0-233.ec2.internal
[INFO] Node registration actually haven't been previously created
{noformat}

Started only 2 ignite and cassandra nodes (should be 3).
I didn't change roles, policies, time zones and anithing else (except 
TESTS_TYPE) after "ignite" tests.

Please take a look on logs at attachment.


> AWS bootstrap scripts patch for Ignite-Cassandra 
> -
>
> Key: IGNITE-3293
> URL: https://issues.apache.org/jira/browse/IGNITE-3293
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.6, 1.7
>Reporter: Igor Rudyak
>Assignee: Nikolay Tikhonov
> Attachments: aws-linux-fail.zip, fail-03-08-cassandra-tests.zip, 
> logs-aws-linux-1307.zip, logs-aws-linux-fail-1407.zip, 
> logs-cassandra-ignite.zip, logs-gail-ignite-cass-0208.zip
>
>
> New version of AWS bootstrap script having:
> 1) Gaglia monitoring
> 2) Allows to manually trigger tests execution multiple times on the same 
> ifstastructure



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

[jira] [Updated] (IGNITE-3623) Drivers hung during streaming load test

[Ksenia Rybakova (JIRA)]

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

Ksenia Rybakova updated IGNITE-3623:

Attachment: run-load.xml
run-load.properties
ignite-base-load-config.xml
driver_d0.log

> Drivers hung during streaming load test
> ---
>
> Key: IGNITE-3623
> URL: https://issues.apache.org/jira/browse/IGNITE-3623
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Ksenia Rybakova
> Attachments: driver_d0.log, ignite-base-load-config.xml, 
> run-load.properties, run-load.xml
>
>
> Drivers hang during streaming load test. Cpu dropps to 0% and test doesn't 
> finish. Every time it happens almost at the end of the test. 
> Config:
> - benchmark: CacheRandomOperation
> - 5 hosts
> - Heap: 8Gb for servers, 1Gb for clients
> - 20 clients, 40 servers
> - Number of caches: 12
> - Types of caches (atomicity mode): different (atomic, transactional)
> - Types of caches (tiered storage mode): different (onheap without eviction, 
> onheap with eviction, offheap_tired, offheap_values)
> - Types of caches (indexing): different (with and without indexes)
> - Types of caches (cache mode): partitioned
> - Backups count: 1
> - Number of entries: 8M
> Benchmark property file and xml configs are attached. Thread dump of one of 
> the drivers is attached.



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

[jira] [Created] (IGNITE-3623) Drivers hung during streaming load test

[Ksenia Rybakova (JIRA)]

Ksenia Rybakova created IGNITE-3623:
---

 Summary: Drivers hung during streaming load test
 Key: IGNITE-3623
 URL: https://issues.apache.org/jira/browse/IGNITE-3623
 Project: Ignite
  Issue Type: Bug
Affects Versions: 1.7
Reporter: Ksenia Rybakova


Drivers hang during streaming load test. Cpu dropps to 0% and test doesn't 
finish. Every time it happens almost at the end of the test. 

Config:
- benchmark: CacheRandomOperation
- 5 hosts
- Heap: 8Gb for servers, 1Gb for clients
- 20 clients, 40 servers
- Number of caches: 12
- Types of caches (atomicity mode): different (atomic, transactional)
- Types of caches (tiered storage mode): different (onheap without eviction, 
onheap with eviction, offheap_tired, offheap_values)
- Types of caches (indexing): different (with and without indexes)
- Types of caches (cache mode): partitioned
- Backups count: 1
- Number of entries: 8M

Benchmark property file and xml configs are attached. Thread dump of one of the 
drivers is attached.



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

[jira] [Assigned] (IGNITE-3331) IGFS: Route client tasks to primary node when metadata co-location is enabled.

[Taras Ledkov (JIRA)]

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

Taras Ledkov reassigned IGNITE-3331:


Assignee: Taras Ledkov

> IGFS: Route client tasks to primary node when metadata co-location is enabled.
> --
>
> Key: IGNITE-3331
> URL: https://issues.apache.org/jira/browse/IGNITE-3331
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>Priority: Critical
>  Labels: important, performance
> Fix For: 1.8
>
>
> Currently we route IGFS client tasks to random metadata data node. When 
> co-location is enabled, it makes sense to requests which are going to change 
> metadata directly to primary node. 



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

[jira] [Commented] (IGNITE-3331) IGFS: Route client tasks to primary node when metadata co-location is enabled.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-3331:
-

Key methods:
{{IgfsMetaManager.runClientTask}}
{{IgfsMetaManager.clientCompute}}
{{FileSystemConfiguration.isColocateMetadata}}

If colocate metadata flag is set, we should pick only primary node for 
IgfsUtils.ROOT_ID key in meta cache. Probably this can be achieved with 
{{IgniteCompute.affinityCall}} method.

> IGFS: Route client tasks to primary node when metadata co-location is enabled.
> --
>
> Key: IGNITE-3331
> URL: https://issues.apache.org/jira/browse/IGNITE-3331
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Priority: Critical
>  Labels: important, performance
> Fix For: 1.8
>
>
> Currently we route IGFS client tasks to random metadata data node. When 
> co-location is enabled, it makes sense to requests which are going to change 
> metadata directly to primary node. 



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

[jira] [Commented] (IGNITE-2310) Lock cache partition for affinityRun/affinityCall execution

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-2310:


GitHub user tledkov-gridgain opened a pull request:

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

IGNITE-2310 Lock cache partition for affinityRun/affinityCall execution



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

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

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

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


commit 485f4bf6cd9289d8a5364fbe0e93e8204d6311fe
Author: tledkov-gridgain 
Date:   2016-05-27T12:16:27Z

IGNITE-2310 Lock cache partition for affinityRun/affinityCall execution




> Lock cache partition for affinityRun/affinityCall execution
> ---
>
> Key: IGNITE-2310
> URL: https://issues.apache.org/jira/browse/IGNITE-2310
> Project: Ignite
>  Issue Type: New Feature
>  Components: cache
>Reporter: Valentin Kulichenko
>Assignee: Taras Ledkov
>Priority: Critical
>  Labels: community
> Fix For: 1.7
>
>
> Partition of a key passed to {{affinityRun}} must be located on the affinity 
> node when a compute job is being sent to the node. The partition has to be 
> locked on the cache until the compute job is being executed. This will let to 
> execute queries safely (Scan or local SQL) over the data that is located 
> locally in the locked partition.
> In addition Ignite Compute API has to be extended by adding {{affinityCall}} 
> and {{affinityRun}} methods that accept list of caches which partitions have 
> to be locked at the time a compute task is being executed.
> Test cases to validate the functionality:
> 1) local SQL query over data located in a concrete partition in multple 
> caches.
> - create cache Organisation cache and create Persons cache.
> - collocate Persons by 'organisationID';
> - send {{affinityRun}} using 'organisationID' as an affinity key and passing 
> Organisation and Persons caches' names to the method to be sure that the 
> partition will be locked on caches;
> - execute local SQL query "SELECT * FROM Persons as p, Organisation as o 
> WHERE p.orgId=o.id' on a changing topology. The result set must be complete, 
> the partition over which the query will be executed mustn't be moved to the 
> other node. Due to affinity collocation the partition number will be the same 
> for all Persons that belong to particular 'organisationID'
> 2) Scan Query over particular partition that is locked when {{affinityCall}} 
> is executed.  
> UPD (YZ May, 31)
> # If closure arrives to node but partition is not there it should be silently 
> failed over to current owner.
> # I don't think user should provide list of caches. How about reserving only 
> one partition, but evict partitions after all partitions in all caches (with 
> same affinity function) on this node are locked for eviction. [~sboikov], can 
> you please comment? It seems this should work faster for closures and will 
> hardly affect rebalancing stuff.
> # I would add method {{affinityCall(int partId, String cacheName, 
> IgniteCallable)}} and same for Runnable. This will allow me not to mess with 
> affinity key in case I know partition before.
> UPD (SB, June, 01)
> Yakov, I think it is possible to implement this 'locking for evictions' 
> approach, but personally I better like partitions reservation:
> - approach with reservation already implemented and works fine in sql queries
> - partition reservation is just CAS operation, if we need do ~10 reservation 
> I think this will be negligible comparing to  job execution time
> - now caches are rebalanced completely independently and changing this be 
> complicated refactoring
> - I see some difficulties how to understand that caches have same affinity. 
> If user uses custom function should he implement 'equals'? For standard 
> affinity functions user can set backup filter, what do in this case? should 
> user implement 'equals' for filter? Even if affinity functions are the same 
> cache configuration can have node filter, so affinity mapping will be 
> different. 



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

[jira] [Updated] (IGNITE-3390) ODBC: Add system DSN support for Windows.

[Igor Sapego (JIRA)]

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

Igor Sapego updated IGNITE-3390:

Attachment: dsn_configuration_window_v3.png

> ODBC: Add system DSN support for Windows.
> -
>
> Key: IGNITE-3390
> URL: https://issues.apache.org/jira/browse/IGNITE-3390
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Affects Versions: 1.6
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 1.8
>
> Attachments: dsn_configuration_window.png, 
> dsn_configuration_window_reworked.png, dsn_configuration_window_v3.png
>
>
> Need to add support for the DSN creation/modification in Windows. To do so we 
> will need to create some UI windows with matching fields.
> DSN stands for the Data Source Name, and it is actually list of options for 
> the ODBC driver which can be used to establish connection. In our case it is 
> set of the host name, tcp port and cache name to which connection should be 
> established. In Windows it seems to be common practice to use "ODBC Data 
> Source Administrator" system tool to configure DNS for the ODBC driver. "ODBC 
> Data Source Administrator" it it's turn uses GUI windows to get DSN 
> information from the user. So to support this feature, we'd needed to 
> implement GUI window that would allow our users to configure their own DSNs.



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

[jira] [Updated] (IGNITE-3622) BinaryObject: print idHash in toString() method only in debug mode

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-3622:
-
Description: 
Current implementation of BinaryObject.toString() method print idHash for 
internal objects, for example, for AffinityKey.

This lead to "unstable" result of toString() method, you will get different 
strings on each toString() invocation.

Possible fix: introduce
{code}
private static final boolean debug = false;
{code}

And check this flag in toString().

If some one will need idHash for debug reasons he could change this flag in its 
private build and debug.

  was:
Current implementation of BinaryObject.toString() method print idHash for 
internal objects, for example, for AffinityKey.

This lead to "unstable" result of toString() method, you will get different 
strings on each toString() invocation.

Possible fix: introduce

private static final boolean debug = false;

And check this flag in toString().

If some one will need idHash for debug reasons he could change this flag in its 
private build and debug.


> BinaryObject: print idHash in toString() method only in debug mode
> --
>
> Key: IGNITE-3622
> URL: https://issues.apache.org/jira/browse/IGNITE-3622
> Project: Ignite
>  Issue Type: Task
>Affects Versions: 1.6
>Reporter: Alexey Kuznetsov
>Priority: Minor
> Fix For: 1.8
>
>
> Current implementation of BinaryObject.toString() method print idHash for 
> internal objects, for example, for AffinityKey.
> This lead to "unstable" result of toString() method, you will get different 
> strings on each toString() invocation.
> Possible fix: introduce
> {code}
> private static final boolean debug = false;
> {code}
> And check this flag in toString().
> If some one will need idHash for debug reasons he could change this flag in 
> its private build and debug.



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

[jira] [Updated] (IGNITE-3622) BinaryObject: print idHash in toString() method only in debug mode

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-3622:
-
Assignee: (was: Alexey Kuznetsov)

> BinaryObject: print idHash in toString() method only in debug mode
> --
>
> Key: IGNITE-3622
> URL: https://issues.apache.org/jira/browse/IGNITE-3622
> Project: Ignite
>  Issue Type: Task
>Affects Versions: 1.6
>Reporter: Alexey Kuznetsov
>Priority: Minor
> Fix For: 1.8
>
>
> Current implementation of BinaryObject.toString() method print idHash for 
> internal objects, for example, for AffinityKey.
> This lead to "unstable" result of toString() method, you will get different 
> strings on each toString() invocation.
> Possible fix: introduce
> private static final boolean debug = false;
> And check this flag in toString().
> If some one will need idHash for debug reasons he could change this flag in 
> its private build and debug.



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

[jira] [Updated] (IGNITE-3622) BinaryObject: print idHash in toString() method only in debug mode

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-3622:
-
Description: 
Current implementation of BinaryObject.toString() method print idHash for 
internal objects, for example, for AffinityKey.

This lead to "unstable" result of toString() method, you will get different 
strings on each toString() invocation.

Possible fix: introduce

private static final boolean debug = false;

And check this flag in toString().

If some one will need idHash for debug reasons he could change this flag in its 
private build and debug.

  was:
Current implementation of BinaryObject.toString() method print idHash for 
internal objects, for example, for AffinityKey.

This lead to "unstable" result of toString() method, you will get 2 different 
strings on each toString() invocation.

Possible fix: introduce

private static final boolean debug = false;

And check this flag in toString().

If some one will need idHash for debug reasons he could change this flag in its 
private build and debug.


> BinaryObject: print idHash in toString() method only in debug mode
> --
>
> Key: IGNITE-3622
> URL: https://issues.apache.org/jira/browse/IGNITE-3622
> Project: Ignite
>  Issue Type: Task
>Affects Versions: 1.6
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Minor
> Fix For: 1.8
>
>
> Current implementation of BinaryObject.toString() method print idHash for 
> internal objects, for example, for AffinityKey.
> This lead to "unstable" result of toString() method, you will get different 
> strings on each toString() invocation.
> Possible fix: introduce
> private static final boolean debug = false;
> And check this flag in toString().
> If some one will need idHash for debug reasons he could change this flag in 
> its private build and debug.



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

[jira] [Created] (IGNITE-3622) BinaryObject: print idHash in toString() method only in debug mode

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-3622:


 Summary: BinaryObject: print idHash in toString() method only in 
debug mode
 Key: IGNITE-3622
 URL: https://issues.apache.org/jira/browse/IGNITE-3622
 Project: Ignite
  Issue Type: Task
Affects Versions: 1.6
Reporter: Alexey Kuznetsov
Assignee: Alexey Kuznetsov
Priority: Minor
 Fix For: 1.8


Current implementation of BinaryObject.toString() method print idHash for 
internal objects, for example, for AffinityKey.

This lead to "unstable" result of toString() method, you will get 2 different 
strings on each toString() invocation.

Possible fix: introduce

private static final boolean debug = false;

And check this flag in toString().

If some one will need idHash for debug reasons he could change this flag in its 
private build and debug.



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

[jira] [Commented] (IGNITE-3217) Text input in number field

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko commented on IGNITE-3217:
---

# Cluster -> General - Static addresses table. Collapse and extend general 
section. Error in log on value edit.
# Cluster -> General - Zones and regions. Collapse and extend general section. 
Values is not editable.
# Cache -> Memory and Server near cache - Select eviction policy. Show/hide 
settings not work.
# Undo showed when input in number field 2 symbols.
# On quick change of valid -> invalid -> valid state field can have invalid 
presentation. F.e. Cluster -> General -> Local host
# Chrome -> Cluster -> General: Input two letter in port number field, press 
section undo. Global undo and Save stay active.

> Text input in number field
> --
>
> Key: IGNITE-3217
> URL: https://issues.apache.org/jira/browse/IGNITE-3217
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Affects Versions: 1.7
>Reporter: Vasiliy Sisko
>Assignee: Dmitriyff
> Fix For: 1.7
>
>
> Create new cluster and try to input text into number field (f.e. Cluster - 
> General - Port number):
> # Field is empty (Chrome) or show text with error message (Firefox or Chrome 
> for 'e' symbol),
> # field in model (backupItem) is not set,
> # Buttons "Save" and "Undo all" and "Undo" is available (For empty fields in 
> chrome),
> # On undo of section "Save" and "Undo all" still available.
> # Undo does not revert text in number fields.
> Also following scenario should be tested:
> # Remove all clusters.
> # Create new cluster. Save.
> # Change some field to "-1" (invalid). DO NOT Save.
> # Click "Add cluster" - new cluster created, but invalid field with "-1" is 
> not cleared.
> On cluster page in failover configuration:
> Configure custom failover configuration and stay SPI implementation field 
> empty.
> That configuration is saved without any errors.
> Also reproduced in cluster binary type configuration for type configuration 
> table.



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

[jira] [Commented] (IGNITE-3618) Client can not load data after server restarts

[Vladislav Pyatkov (JIRA)]

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

Vladislav Pyatkov commented on IGNITE-3618:
---

The test, which attached, reproduce the issue if put it to ignite-indexing.
The exception was thrown because client cached metodata (about object type) 
from internal map (see at 
{{CacheObjectBinaryProcessorImpl#clientMetaDataCache}}).

> Client can not load data after server restarts
> --
>
> Key: IGNITE-3618
> URL: https://issues.apache.org/jira/browse/IGNITE-3618
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vladislav Pyatkov
> Attachments: ClientReconnectTest.java, src.zip
>
>
> Start {{TestServer}} and {{TestCache}}
> After client has printed "Sleep", need to restart server
> Wait topology update and client will be reconnect
> Type enter in client console and you will see in client console "No object in 
> cache"
> Server throws exception:
> {noformat}
> Caused by: class org.apache.ignite.binary.BinaryObjectException: Cannot find 
> metadata for object with compact footer: -995427962
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.getOrCreateSchema(BinaryReaderExImpl.java:1687)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:255)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:168)
>   at 
> org.apache.ignite.internal.binary.BinaryObjectImpl.reader(BinaryObjectImpl.java:572)
>   at 
> org.apache.ignite.internal.binary.BinaryObjectImpl.reader(BinaryObjectImpl.java:585)
>   at 
> org.apache.ignite.internal.binary.BinaryObjectImpl.hasField(BinaryObjectImpl.java:395)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$BinaryProperty.value(GridQueryProcessor.java:1990)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$RowDescriptor.columnValue(IgniteH2Indexing.java:2513)
>   at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2AbstractKeyValueRow.getValue(GridH2AbstractKeyValueRow.java:289)
>   at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2IndexBase.compareRows(GridH2IndexBase.java:119)
>   at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2TreeIndex.compare(GridH2TreeIndex.java:248)
>   at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2TreeIndex.compare(GridH2TreeIndex.java:49)
>   at 
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap$2.compareTo(GridOffHeapSnapTreeMap.java:1350)
>   at 
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap$2.compareTo(GridOffHeapSnapTreeMap.java:1346)
>   at 
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2102)
>   at 
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.updateUnderRoot(GridOffHeapSnapTreeMap.java:2034)
>   at 
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.update(GridOffHeapSnapTreeMap.java:1915)
>   at 
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.put(GridOffHeapSnapTreeMap.java:1864)
>   at 
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.put(GridOffHeapSnapTreeMap.java:108)
>   at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2TreeIndex.put(GridH2TreeIndex.java:403)
>   at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.doUpdate(GridH2Table.java:405)
>   at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:339)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:539)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:700)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:407)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.updateIndex(GridCacheMapEntry.java:4024)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerSet(GridCacheMapEntry.java:1244)
>   at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.userCommit(IgniteTxLocalAdapter.java:802)
>   ... 29 more
> {noformat}



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

[jira] [Updated] (IGNITE-3618) Client can not load data after server restarts

[Vladislav Pyatkov (JIRA)]

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

Vladislav Pyatkov updated IGNITE-3618:
--
Attachment: ClientReconnectTest.java

> Client can not load data after server restarts
> --
>
> Key: IGNITE-3618
> URL: https://issues.apache.org/jira/browse/IGNITE-3618
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vladislav Pyatkov
> Attachments: ClientReconnectTest.java, src.zip
>
>
> Start {{TestServer}} and {{TestCache}}
> After client has printed "Sleep", need to restart server
> Wait topology update and client will be reconnect
> Type enter in client console and you will see in client console "No object in 
> cache"
> Server throws exception:
> {noformat}
> Caused by: class org.apache.ignite.binary.BinaryObjectException: Cannot find 
> metadata for object with compact footer: -995427962
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.getOrCreateSchema(BinaryReaderExImpl.java:1687)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:255)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:168)
>   at 
> org.apache.ignite.internal.binary.BinaryObjectImpl.reader(BinaryObjectImpl.java:572)
>   at 
> org.apache.ignite.internal.binary.BinaryObjectImpl.reader(BinaryObjectImpl.java:585)
>   at 
> org.apache.ignite.internal.binary.BinaryObjectImpl.hasField(BinaryObjectImpl.java:395)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$BinaryProperty.value(GridQueryProcessor.java:1990)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$RowDescriptor.columnValue(IgniteH2Indexing.java:2513)
>   at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2AbstractKeyValueRow.getValue(GridH2AbstractKeyValueRow.java:289)
>   at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2IndexBase.compareRows(GridH2IndexBase.java:119)
>   at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2TreeIndex.compare(GridH2TreeIndex.java:248)
>   at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2TreeIndex.compare(GridH2TreeIndex.java:49)
>   at 
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap$2.compareTo(GridOffHeapSnapTreeMap.java:1350)
>   at 
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap$2.compareTo(GridOffHeapSnapTreeMap.java:1346)
>   at 
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2102)
>   at 
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.updateUnderRoot(GridOffHeapSnapTreeMap.java:2034)
>   at 
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.update(GridOffHeapSnapTreeMap.java:1915)
>   at 
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.put(GridOffHeapSnapTreeMap.java:1864)
>   at 
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.put(GridOffHeapSnapTreeMap.java:108)
>   at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2TreeIndex.put(GridH2TreeIndex.java:403)
>   at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.doUpdate(GridH2Table.java:405)
>   at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:339)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:539)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:700)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:407)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.updateIndex(GridCacheMapEntry.java:4024)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerSet(GridCacheMapEntry.java:1244)
>   at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.userCommit(IgniteTxLocalAdapter.java:802)
>   ... 29 more
> {noformat}



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

[jira] [Updated] (IGNITE-3618) Client can not load data after server restarts

[Vladislav Pyatkov (JIRA)]

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

Vladislav Pyatkov updated IGNITE-3618:
--
Attachment: (was: ClientReconnectTest.java)

> Client can not load data after server restarts
> --
>
> Key: IGNITE-3618
> URL: https://issues.apache.org/jira/browse/IGNITE-3618
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vladislav Pyatkov
> Attachments: ClientReconnectTest.java, src.zip
>
>
> Start {{TestServer}} and {{TestCache}}
> After client has printed "Sleep", need to restart server
> Wait topology update and client will be reconnect
> Type enter in client console and you will see in client console "No object in 
> cache"
> Server throws exception:
> {noformat}
> Caused by: class org.apache.ignite.binary.BinaryObjectException: Cannot find 
> metadata for object with compact footer: -995427962
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.getOrCreateSchema(BinaryReaderExImpl.java:1687)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:255)
>   at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:168)
>   at 
> org.apache.ignite.internal.binary.BinaryObjectImpl.reader(BinaryObjectImpl.java:572)
>   at 
> org.apache.ignite.internal.binary.BinaryObjectImpl.reader(BinaryObjectImpl.java:585)
>   at 
> org.apache.ignite.internal.binary.BinaryObjectImpl.hasField(BinaryObjectImpl.java:395)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$BinaryProperty.value(GridQueryProcessor.java:1990)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$RowDescriptor.columnValue(IgniteH2Indexing.java:2513)
>   at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2AbstractKeyValueRow.getValue(GridH2AbstractKeyValueRow.java:289)
>   at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2IndexBase.compareRows(GridH2IndexBase.java:119)
>   at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2TreeIndex.compare(GridH2TreeIndex.java:248)
>   at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2TreeIndex.compare(GridH2TreeIndex.java:49)
>   at 
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap$2.compareTo(GridOffHeapSnapTreeMap.java:1350)
>   at 
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap$2.compareTo(GridOffHeapSnapTreeMap.java:1346)
>   at 
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.attemptUpdate(GridOffHeapSnapTreeMap.java:2102)
>   at 
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.updateUnderRoot(GridOffHeapSnapTreeMap.java:2034)
>   at 
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.update(GridOffHeapSnapTreeMap.java:1915)
>   at 
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.put(GridOffHeapSnapTreeMap.java:1864)
>   at 
> org.apache.ignite.internal.util.offheap.unsafe.GridOffHeapSnapTreeMap.put(GridOffHeapSnapTreeMap.java:108)
>   at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2TreeIndex.put(GridH2TreeIndex.java:403)
>   at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.doUpdate(GridH2Table.java:405)
>   at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:339)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:539)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:700)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:407)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.updateIndex(GridCacheMapEntry.java:4024)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerSet(GridCacheMapEntry.java:1244)
>   at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.userCommit(IgniteTxLocalAdapter.java:802)
>   ... 29 more
> {noformat}



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

[jira] [Created] (IGNITE-3620) Hide error popover on section collapse.

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-3620:
-

 Summary: Hide error popover on section collapse.
 Key: IGNITE-3620
 URL: https://issues.apache.org/jira/browse/IGNITE-3620
 Project: Ignite
  Issue Type: Sub-task
Reporter: Vasiliy Sisko






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

[jira] [Updated] (IGNITE-3620) Hide error popover on section collapse.

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko updated IGNITE-3620:
--
Component/s: wizards

> Hide error popover on section collapse.
> ---
>
> Key: IGNITE-3620
> URL: https://issues.apache.org/jira/browse/IGNITE-3620
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Vasiliy Sisko
> Fix For: 1.7
>
>




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

[jira] [Commented] (IGNITE-3359) .NET: IgniteConfiguration.ToXml

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-3359:


GitHub user ptupitsyn opened a pull request:

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

IGNITE-3359 .NET: Implement IgniteConfiguration.ToXml/FromXml



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

$ git pull https://github.com/ptupitsyn/ignite ignite-3359

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

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


commit 7927ab813c75368f6664394c91d21cc61491d675
Author: Pavel Tupitsyn 
Date:   2016-08-03T08:53:23Z

IGNITE-3359 .NET: IgniteConfiguration.ToXml

commit 63aa0bb71bc6341bb9f00c832c8115873cbe8f41
Author: Pavel Tupitsyn 
Date:   2016-08-03T08:54:50Z

wip tests

commit ad4368ab634f816e04d15f665b429d9e4d461116
Author: Pavel Tupitsyn 
Date:   2016-08-03T09:02:44Z

wip

commit c55a4f84123032640fe0a02f54c65891dd90ad12
Author: Pavel Tupitsyn 
Date:   2016-08-03T09:08:52Z

wip

commit 958f34cefb1e4d16a18f6016a256d4c8ba786cb2
Author: Pavel Tupitsyn 
Date:   2016-08-03T09:11:28Z

wip

commit 206f0a1ecae7534a6a7c83e3b9098dea8897dbe3
Author: Pavel Tupitsyn 
Date:   2016-08-03T09:28:27Z

ToXml test done

commit c8448e8f8ba00355e839a7d8b6ea96f3807b82aa
Author: Pavel Tupitsyn 
Date:   2016-08-03T10:03:19Z

wip FromXml

commit 5d862d59a5c4e80b0ba31a00f70c84cc8cd346c1
Author: Pavel Tupitsyn 
Date:   2016-08-03T10:06:36Z

wip tests

commit 60f40a389cfab8ba68c3cd59d8b200bceb4c85ad
Author: Pavel Tupitsyn 
Date:   2016-08-03T10:11:07Z

Tests done

commit ec36f01c30f4811442f34cbfc56933604b737525
Author: Pavel Tupitsyn 
Date:   2016-08-03T10:15:03Z

all done




> .NET: IgniteConfiguration.ToXml
> ---
>
> Key: IGNITE-3359
> URL: https://issues.apache.org/jira/browse/IGNITE-3359
> Project: Ignite
>  Issue Type: Improvement
>  Components: community, platforms
>Affects Versions: 1.6
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .net
> Fix For: 1.8
>
>
> There were multiple questions on user list and in gitter on how to specify 
> some property in xml in the IgniteConfigurationSection.
> We do provide the XSD schema, but it is easier to just call a method and get 
> a piece of XML to copy and paste.



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

[jira] [Updated] (IGNITE-2852) Support of Comparable interface for BinaryObject

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2852:

Assignee: Andrew Mashenkov  (was: Andrey Velichko)

> Support of Comparable interface for BinaryObject
> 
>
> Key: IGNITE-2852
> URL: https://issues.apache.org/jira/browse/IGNITE-2852
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Andrew Mashenkov
> Fix For: 1.7
>
>
> When trying to convert {{TreeMap}} into binary object using {{toBinary}} 
> method, the following exception fails:
> {noformat}
> Exception in thread "main" java.lang.ClassCastException: 
> org.apache.ignite.internal.binary.BinaryObjectImpl cannot be cast to 
> java.lang.Comparable
>   at java.util.TreeMap.compare(TreeMap.java:1188)
>   at java.util.TreeMap.put(TreeMap.java:531)
>   at 
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.marshalToBinary(CacheObjectBinaryProcessorImpl.java:495)
>   at 
> org.apache.ignite.internal.processors.cache.binary.IgniteBinaryImpl.toBinary(IgniteBinaryImpl.java:67)
>   at TreeMapTest.main(TreeMapTest.java:15)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
> {noformat}
> This happens because maps are not wrapped into binary objects, therefore we 
> create another {{TreeMap}} and put {{BinaryObject}} instances, which are not 
> {{Comparable}}.



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

[jira] [Updated] (IGNITE-3597) IgniteConfiguration.igniteWorkDir has no effect

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-3597:

Assignee: Andrew Mashenkov

> IgniteConfiguration.igniteWorkDir has no effect
> ---
>
> Key: IGNITE-3597
> URL: https://issues.apache.org/jira/browse/IGNITE-3597
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.5.0.final
>Reporter: Pavel Tupitsyn
>Assignee: Andrew Mashenkov
>Priority: Critical
>
> U.setWorkDirectory method ensures that work dir is set only once.
> If there are multiple nodes in a process, or a node is stopped and then 
> started, IgniteConfiguration.igniteWorkDir is ignored.



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

[jira] [Updated] (IGNITE-3332) IGFS: Use task for file unlock routine on client nodes.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-3332:

Labels: important performance  (was: important perfomance)

> IGFS: Use task for file unlock routine on client nodes.
> ---
>
> Key: IGNITE-3332
> URL: https://issues.apache.org/jira/browse/IGNITE-3332
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>  Labels: important, performance
> Fix For: 1.8
>
>




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

[jira] [Updated] (IGNITE-3553) IGFS: Implement internal light-weight closure execution.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-3553:

Labels: performance  (was: )

> IGFS: Implement internal light-weight closure execution.
> 
>
> Key: IGNITE-3553
> URL: https://issues.apache.org/jira/browse/IGNITE-3553
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
>  Labels: performance
> Fix For: 1.8
>
>
> The main goal is speed. No failover. No sessions. No injections. Just 
> extremely compact message and execution.



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

[jira] [Updated] (IGNITE-3331) IGFS: Route client tasks to primary node when metadata co-location is enabled.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-3331:

Labels: important performance  (was: important perfomance)

> IGFS: Route client tasks to primary node when metadata co-location is enabled.
> --
>
> Key: IGNITE-3331
> URL: https://issues.apache.org/jira/browse/IGNITE-3331
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Priority: Critical
>  Labels: important, performance
> Fix For: 1.8
>
>
> Currently we route IGFS client tasks to random metadata data node. When 
> co-location is enabled, it makes sense to requests which are going to change 
> metadata directly to primary node. 



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

[jira] [Updated] (IGNITE-3552) IGFS: Performance improvements.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-3552:

Labels: performance roadmap  (was: roadmap)

> IGFS: Performance improvements.
> ---
>
> Key: IGNITE-3552
> URL: https://issues.apache.org/jira/browse/IGNITE-3552
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>  Labels: performance, roadmap
> Fix For: 1.8
>
>
> This is an umbrella ticket for all recent performance improvements planned 
> for IGFS.



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

[jira] [Updated] (IGNITE-2794) ODBC: Make sure that SQL_C_BINARY type is supported.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2794:

Fix Version/s: (was: 1.7)
   1.8

> ODBC: Make sure that SQL_C_BINARY type is supported.
> 
>
> Key: IGNITE-2794
> URL: https://issues.apache.org/jira/browse/IGNITE-2794
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Affects Versions: 1.5.0.final
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 1.8
>
>
> Need to make sure that any column can be fetched as {{SQL_C_BINARY}} type.



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

[jira] [Updated] (IGNITE-2628) ODBC: Add multi-threaded tests.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2628:

Fix Version/s: (was: 1.7)
   1.8

> ODBC: Add multi-threaded tests.
> ---
>
> Key: IGNITE-2628
> URL: https://issues.apache.org/jira/browse/IGNITE-2628
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Igor Sapego
> Fix For: 1.8
>
>




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

[jira] [Updated] (IGNITE-2804) ODBC: Implement ODBC-related events.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2804:

Fix Version/s: (was: 1.7)
   1.8

> ODBC: Implement ODBC-related events.
> 
>
> Key: IGNITE-2804
> URL: https://issues.apache.org/jira/browse/IGNITE-2804
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Affects Versions: 1.5.0.final
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 1.8
>
>
> We should implement ODBC-related events, e.g. OdbcConnect/OdbcDisconnect 
> events.



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

[jira] [Updated] (IGNITE-2803) ODBC: Add SSL support.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2803:

Fix Version/s: (was: 1.7)
   1.8

> ODBC: Add SSL support.
> --
>
> Key: IGNITE-2803
> URL: https://issues.apache.org/jira/browse/IGNITE-2803
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Affects Versions: 1.5.0.final
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 1.8
>
>
> Need to implement SSL support for the ODBC.



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

[jira] [Updated] (IGNITE-2238) ODBC: Implement basic cursor operations for the ODBC driver.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2238:

Fix Version/s: (was: 1.7)
   1.8

> ODBC: Implement basic cursor operations for the ODBC driver.
> 
>
> Key: IGNITE-2238
> URL: https://issues.apache.org/jira/browse/IGNITE-2238
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Reporter: Igor Sapego
> Fix For: 1.8
>
>
> This feature listed in the [ODBC Core Interface 
> Conformance|https://msdn.microsoft.com/en-us/library/ms714086(v=vs.85).aspx] 
> and should be implemented for our driver. It includes implementation of the 
> following functions:
> - {{SQLCloseCursor}};
> - {{SQLGetCursorName}};
> - {{SQLSetCursorName}}.



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

[jira] [Updated] (IGNITE-2974) ODBC: Implement fine-grained NIO server configuration.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2974:

Fix Version/s: (was: 1.7)
   1.8

> ODBC: Implement fine-grained NIO server configuration.
> --
>
> Key: IGNITE-2974
> URL: https://issues.apache.org/jira/browse/IGNITE-2974
> Project: Ignite
>  Issue Type: Task
>  Components: general, odbc
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 1.8
>
>
> ODBC uses {{GridNioServer}} internally to handle user requests. This server 
> has a number of properties, e.g. selector count buffer size, etc. 
> We can expose these properties in {{OdbcConfiguration}}, but it appears to be 
> too complex for users. Moreover, this is not the only component where we need 
> NIO server configuration.
> I propose to create separate bean and name it {{ServerConfiguration}}. This 
> bean will be used in ODBC and any other component.



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

[jira] [Updated] (IGNITE-3069) Move ODBC tests to separate test suit.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-3069:

Fix Version/s: (was: 1.7)
   1.8

> Move ODBC tests to separate test suit.
> --
>
> Key: IGNITE-3069
> URL: https://issues.apache.org/jira/browse/IGNITE-3069
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Affects Versions: 1.5.0.final
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 1.8
>
>
> Currently ODBC tests are part of the Ignite Platform CPP test suits for TC. 
> Move them to separate test suit.



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

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

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2793:

Fix Version/s: (was: 1.7)
   1.8

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



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

[jira] [Updated] (IGNITE-2246) ODBC: Implement Descriptors support for the ODBC driver.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2246:

Fix Version/s: (was: 1.7)
   1.8

> ODBC: Implement Descriptors support for the ODBC driver.
> 
>
> Key: IGNITE-2246
> URL: https://issues.apache.org/jira/browse/IGNITE-2246
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 1.8
>
>
> This feature listed in the [ODBC Core Interface 
> Conformance|https://msdn.microsoft.com/en-us/library/ms714086(v=vs.85).aspx] 
> and should be implemented for our driver.
> This includes implementation of the following functions:
> - {{SQLCopyDesc}}
> - {{SQLGetDescField}}
> - {{SQLGetDescRec}}
> - {{SQLSetDescField}}
> - {{SQLSetDescRec}}
> Following header fields:
> - {{SQL_DESC_ALLOC_TYPE}}
> - {{SQL_DESC_ARRAY_SIZE}}
> - {{SQL_DESC_ARRAY_STATUS_PTR}}
> - {{SQL_DESC_BIND_OFFSET_PTR}}
> - {{SQL_DESC_BIND_TYPE}}
> - {{SQL_DESC_COUNT}}
> - {{SQL_DESC_ROWS_PROCESSED_PTR}}
> Following record fields:
> - {{SQL_DESC_BASE_COLUMN_NAME}}
> - {{SQL_DESC_CASE_SENSITIVE}}
> - {{SQL_DESC_CONCISE_TYPE}}
> - {{SQL_DESC_DATA_PTR}}
> - {{SQL_DESC_DATETIME_INTERVAL_ CODE}}
> - {{SQL_DESC_DATETIME_INTERVAL_ PRECISION}}
> - {{SQL_DESC_DISPLAY_SIZE}}
> - {{SQL_DESC_FIXED_PREC_SCALE}}
> - {{SQL_DESC_INDICATOR_PTR}}
> - {{SQL_DESC_LENGTH}}
> - {{SQL_DESC_LITERAL_PREFIX}}
> - {{SQL_DESC_LITERAL_SUFFIX}}
> - {{SQL_DESC_LOCAL_TYPE_NAME}}
> - {{SQL_DESC_NAME}}
> - {{SQL_DESC_NULLABLE}}
> - {{SQL_DESC_OCTET_LENGTH}}
> - {{SQL_DESC_OCTET_LENGTH_PTR}}
> - {{SQL_DESC_PARAMETER_TYPE}}
> - {{SQL_DESC_PRECISION}}
> - {{SQL_DESC_SCALE}}
> - {{SQL_DESC_SEARCHABLE}}
> - {{SQL_DESC_TYPE}}
> - {{SQL_DESC_TYPE_NAME}}
> - {{SQL_DESC_UNNAMED}}
> - {{SQL_DESC_UNSIGNED}}
> - {{SQL_DESC_UPDATABLE}}



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

[jira] [Updated] (IGNITE-2644) ODBC: Add metrics.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2644:

Fix Version/s: (was: 1.7)
   1.8

> ODBC: Add metrics.
> --
>
> Key: IGNITE-2644
> URL: https://issues.apache.org/jira/browse/IGNITE-2644
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Igor Sapego
> Fix For: 1.8
>
>
> Let's plan this feature for further releases (e.g. 1.7).
> We should add ODBC metrics. Several ideas on what to count:
> 1) Currently connected clients
> 2) Max connected clients
> 3) Total connected clients
> 4) SQL requests executed
> 5) Records fetched
> 6) Average processing time
> Anything else?



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

[jira] [Updated] (IGNITE-2802) ODBC: Add support for address ranges.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2802:

Fix Version/s: (was: 1.7)
   1.8

> ODBC: Add support for address ranges.
> -
>
> Key: IGNITE-2802
> URL: https://issues.apache.org/jira/browse/IGNITE-2802
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Affects Versions: 1.5.0.final
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 1.8
>
>
> We should add ability for user to input address range from which ODBC driver 
> can choose a node to connect.



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

[jira] [Updated] (IGNITE-3468) Missing Primary Key flag in getColumns()

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-3468:

Fix Version/s: (was: 1.7)
   1.8

> Missing Primary Key flag in getColumns()
> 
>
> Key: IGNITE-3468
> URL: https://issues.apache.org/jira/browse/IGNITE-3468
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache, odbc, SQL
>Affects Versions: 1.6
>Reporter: Alexandre Boudnik
>Assignee: Alexandre Boudnik
> Fix For: 1.8
>
>
> When implemented it allows BI tools to build more optimal queries



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

[jira] [Updated] (IGNITE-2629) ODBC: Added GridNioAsyncNotifyFilter and GridConnectionBytesVerifyFilter to NIO server.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2629:

Fix Version/s: (was: 1.7)
   1.8

> ODBC: Added GridNioAsyncNotifyFilter and GridConnectionBytesVerifyFilter to 
> NIO server.
> ---
>
> Key: IGNITE-2629
> URL: https://issues.apache.org/jira/browse/IGNITE-2629
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Igor Sapego
>Priority: Minor
> Fix For: 1.8
>
>
> This is low-priority task, lets return to it once everything else is finished.
> Justification:
> 1) *GridNioAsyncNotifyFilter* moves requests processing to separate thread 
> pool. If you do no do that, all NIO workers might stuck in potentially 
> long-running query operations and you will not be able to accept new client 
> requests what may result in timeouts on client side.
> 2) *GridConnectionBytesVerifyFilter* expects special magic header to ensure 
> connected client identity.



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

[jira] [Updated] (IGNITE-2244) ODBC: Implement Connection attributes manipulation for the ODBC driver.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2244:

Fix Version/s: (was: 1.7)
   1.8

> ODBC: Implement Connection attributes manipulation for the ODBC driver.
> ---
>
> Key: IGNITE-2244
> URL: https://issues.apache.org/jira/browse/IGNITE-2244
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 1.8
>
>
> This feature listed in the [ODBC Core Interface 
> Conformance|https://msdn.microsoft.com/en-us/library/ms714086(v=vs.85).aspx] 
> and should be implemented for our driver.
> The list of functions that should be implemented:
> - {{SQLGetConnectAttr}}
> - {{SQLSetConnectAttr}}
> The minimum list of attributes that should be supported:
> - {{SQL_ATTR_ACCESS_MODE}}
> - {{SQL_ATTR_ODBC_CURSORS}}
> - {{SQL_ATTR_QUIET_MODE}}
> - {{SQL_ATTR_TRACE}}
> - {{SQL_ATTR_TRACEFILE}}
> - {{SQL_ATTR_TRANSLATE_LIB}}
> - {{SQL_ATTR_TRANSLATE_OPTION}}



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

[jira] [Updated] (IGNITE-3467) jdbc getTables() returns catalog as null

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-3467:

Fix Version/s: (was: 1.7)
   1.8

> jdbc getTables() returns catalog as null
> 
>
> Key: IGNITE-3467
> URL: https://issues.apache.org/jira/browse/IGNITE-3467
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc, SQL
>Affects Versions: 1.6
>Reporter: Alexandre Boudnik
>Assignee: Alexandre Boudnik
>Priority: Critical
> Fix For: 1.8
>
>
> Then some jdbc query tool uses null values as catalog name. An H2 database 
> returns word "DATABASE" in CATALOG column, and then correctly resolves a 
> fully-qualified name. I would recommend to do the same for these metadata.



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

[jira] [Updated] (IGNITE-2245) ODBC: Implement Statement attributes manipulation for the ODBC driver.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2245:

Fix Version/s: (was: 1.7)
   1.8

> ODBC: Implement Statement attributes manipulation for the ODBC driver.
> --
>
> Key: IGNITE-2245
> URL: https://issues.apache.org/jira/browse/IGNITE-2245
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 1.8
>
>
> This feature listed in the [ODBC Core Interface 
> Conformance|https://msdn.microsoft.com/en-us/library/ms714086(v=vs.85).aspx] 
> and should be implemented for our driver.
> The list of functions that should be implemented:
> - {{SQLGetStmtAttr}}
> - {{SQLSetStmtAttr}}
> The minimum list of attributes that should be supported:
> - {{SQL_ATTR_APP_PARAM_DESC}}
> - {{SQL_ATTR_APP_ROW_DESC}}
> - {{SQL_ATTR_IMP_PARAM_DESC}}
> - {{SQL_ATTR_IMP_ROW_DESC}}
> - {{SQL_ATTR_METADATA_ID}}
> - {{SQL_ATTR_NOSCAN}}
> - {{SQL_ATTR_PARAM_BIND_OFFSET_PTR}}
> - {{SQL_ATTR_PARAM_BIND_TYPE}}
> - {{SQL_ATTR_PARAM_OPERATION_PTR}}
> - {{SQL_ATTR_PARAM_STATUS_PTR}}
> - {{SQL_ATTR_PARAMS_PROCESSED_PTR}}
> - {{SQL_ATTR_PARAMSET_SIZE}}
> - {{SQL_ATTR_ROW_ARRAY_SIZE}}
> - {{SQL_ATTR_ROW_BIND_OFFSET_PTR}}
> - {{SQL_ATTR_ROW_BIND_TYPE}}
> - {{SQL_ATTR_ROW_STATUS_PTR}}
> - {{SQL_ATTR_ROWS_FETCHED_PTR}}



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

[jira] [Updated] (IGNITE-1926) Implement IgfsSecondaryFileSystem using java.io.File API

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-1926:

Fix Version/s: (was: 1.7)
   1.8

> Implement IgfsSecondaryFileSystem using java.io.File API
> 
>
> Key: IGNITE-1926
> URL: https://issues.apache.org/jira/browse/IGNITE-1926
> Project: Ignite
>  Issue Type: Improvement
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Valentin Kulichenko
>Assignee: Dmitry Karachentsev
>  Labels: roadmap
> Fix For: 1.8
>
>
> This will allow to persist IGFS data on the local disk. Currently we have 
> only Hadoop-based implementation.
> Corresponding user thread: 
> http://apache-ignite-users.70518.x6.nabble.com/IGFS-backed-by-persistence-on-physical-filesystem-td1882.html



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

[jira] [Updated] (IGNITE-3187) IGFS: Print acceptable IGFS endpoints to the console on node start.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-3187:

Fix Version/s: (was: 1.7)
   1.8

> IGFS: Print acceptable IGFS endpoints to the console on node start.
> ---
>
> Key: IGNITE-3187
> URL: https://issues.apache.org/jira/browse/IGNITE-3187
> Project: Ignite
>  Issue Type: Improvement
>  Components: hadoop, IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
> Fix For: 1.8
>
>
> *Problem*
> When user starts a node with IGFS, he need to know it's endpoint to be used 
> in URI's (e.g. "igfs://igfs@"). There are non-trivial rules no how the scheme 
> is formed, and sometime it is difficult to understand which scheme to use.
> *Solution*
> Let's print acceptable schemes to the console on node start.



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

[jira] [Updated] (IGNITE-3163) IGFS: Add working directory notion.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-3163:

Fix Version/s: (was: 1.7)
   1.8

> IGFS: Add working directory notion.
> ---
>
> Key: IGNITE-3163
> URL: https://issues.apache.org/jira/browse/IGNITE-3163
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Priority: Critical
>  Labels: important
> Fix For: 1.8
>
>
> Currently when user configure secondary file system, it provides URI. We do 
> not use path of this URI and rely only on authority component.  For this 
> reason "file:///" and "file:///path/" setting will be processed in the same 
> We need to respect path component as well and append it so that use can use 
> relative paths easily.



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

[jira] [Updated] (IGNITE-3331) IGFS: Route client tasks to primary node when metadata co-location is enabled.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-3331:

Fix Version/s: (was: 1.7)
   1.8

> IGFS: Route client tasks to primary node when metadata co-location is enabled.
> --
>
> Key: IGNITE-3331
> URL: https://issues.apache.org/jira/browse/IGNITE-3331
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Priority: Critical
>  Labels: important, perfomance
> Fix For: 1.8
>
>
> Currently we route IGFS client tasks to random metadata data node. When 
> co-location is enabled, it makes sense to requests which are going to change 
> metadata directly to primary node. 



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

[jira] [Updated] (IGNITE-3543) IGFS: Merge isRetryForSecondary() and verifyIntegrity() methods.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-3543:

Fix Version/s: (was: 1.7)
   1.8

> IGFS: Merge isRetryForSecondary() and verifyIntegrity() methods.
> 
>
> Key: IGNITE-3543
> URL: https://issues.apache.org/jira/browse/IGNITE-3543
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
> Fix For: 1.8
>
>
> There are two methods with very similar semantics:
> 1) {{IgfsPathIds.verifyIntegrity}}
> 2) {{IgfsMetaManager.isRetryForSecondary}}
> The latter method ensures that if path is incomplete, then the last existing 
> item do not have reference to child with expected name, but unexpected ID. 
> Semantically this situation means that concurrent update occurred. 
> Instead of heaving two identical methods, we should merge these checks in a 
> single method {{IgfsPathIds.verifyIntegrity}}.



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

[jira] [Updated] (IGNITE-3333) IGFS: Allow for ATOMIC data cache.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-:

Fix Version/s: (was: 1.7)
   1.8

> IGFS: Allow for ATOMIC data cache.
> --
>
> Key: IGNITE-
> URL: https://issues.apache.org/jira/browse/IGNITE-
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
>  Labels: performance
> Fix For: 1.8
>
>
> Currently data cache must be transactional. It means that some updates even 
> on single key will require 2PC. Instead, it makes sense to try change update 
> logic to work always on single keys. In this case we will be able to switch 
> to ATOMIC cache, what could improve performance dramatically.



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

[jira] [Updated] (IGNITE-3590) Create test and first simple implementation of secondary file system.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-3590:

Fix Version/s: (was: 1.7)
   1.8

> Create test and first simple implementation of secondary file system.
> -
>
> Key: IGNITE-3590
> URL: https://issues.apache.org/jira/browse/IGNITE-3590
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Dmitry Karachentsev
>Assignee: Vladimir Ozerov
> Fix For: 1.8
>
>
> Create new simple (copy paste from IgniteHadoopIgfsSecondaryFileSystem) 
> inplementation and tests for it as start point.



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