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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-3293:


Github user asfgit closed the pull request at:

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


> 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: Alexey Kuznetsov
> 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] [Closed] (IGNITE-3293) AWS bootstrap scripts patch for Ignite-Cassandra

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov closed IGNITE-3293.

Assignee: (was: Alexey Kuznetsov)

Merged to master.

> 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
> 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-3507) misspelling and broken URL on Ignite features page

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-3507:

Assignee: Prachi Garg

> misspelling and broken URL on Ignite features page
> --
>
> Key: IGNITE-3507
> URL: https://issues.apache.org/jira/browse/IGNITE-3507
> Project: Ignite
>  Issue Type: Bug
>  Components: documentation
>Reporter: Sarychev Roman
>Assignee: Prachi Garg
>Priority: Trivial
>
> https://ignite.apache.org/features.html
> 1. "Memached Support"
> should be MemCached Support
> 2. link to Semaphore (Docs for this feature) are broken - 404
> https://apacheignite.readme.io/docs/distributed-semaphore



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

[jira] [Commented] (IGNITE-3507) misspelling and broken URL on Ignite features page

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-3507:
-

[~pgarg], please fix the issues listed in the ticket.

> misspelling and broken URL on Ignite features page
> --
>
> Key: IGNITE-3507
> URL: https://issues.apache.org/jira/browse/IGNITE-3507
> Project: Ignite
>  Issue Type: Bug
>  Components: documentation
>Reporter: Sarychev Roman
>Assignee: Prachi Garg
>Priority: Trivial
>
> https://ignite.apache.org/features.html
> 1. "Memached Support"
> should be MemCached Support
> 2. link to Semaphore (Docs for this feature) are broken - 404
> https://apacheignite.readme.io/docs/distributed-semaphore



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

[jira] [Commented] (IGNITE-2294) Implement SQL DML (insert, update, delete) clauses.

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko commented on IGNITE-2294:
-

JDBC driver integration for modifying operations almost finished, removed 
public API overhead introduced together with those operations, it's unchanged 
after all.

> Implement SQL DML (insert, update, delete) clauses.
> ---
>
> Key: IGNITE-2294
> URL: https://issues.apache.org/jira/browse/IGNITE-2294
> Project: Ignite
>  Issue Type: Wish
>Reporter: Sergi Vladykin
>Assignee: Alexander Paschenko
> Fix For: 1.7
>
>
> We need to add parsing for all the listed SQL commands and translate them 
> into respective cache operations (putIfAbstent, put, remove).



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

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

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-2310:
-

There must no be any compatibility related issues especially compile time ones. 
We need to find a way to avoid this situation.

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

Pavel Tupitsyn commented on IGNITE-1629:


The following logic implemented:

1) If there is NO user-defined logger in .NET:
* Java side works as before, logging to a logger defined in Spring or the 
default one
* .NET delegates logging to Java

2) If there is user-defined logger in .NET:
* PlatformLogger is set in Java on startup. Java delegates all logging to .NET
* .NET logs directly to the user logger

This way we have the old behavior by default (File + Console or 
Spring-configured). And logs from both .NET and Java are combined in one place 
(either in .NET or in Java, depending on configuration).

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

Eduard Shangareev commented on IGNITE-1192:
---

Update: 
I have added support for querying by almost all PartTree.Type.  
I've looked at Querydsql and I think it is not worth to add support right now.

> 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] [Comment Edited] (IGNITE-1084) [Test] HibernateL2CacheSelfTest#testNaturalIdCache() is broken

[Milap Wadhwa (JIRA)]

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

Milap Wadhwa edited comment on IGNITE-1084 at 8/4/16 2:31 PM:
--

Hi [~yzhdanov],

Issue is with NONSTRICT_READ_WRITE policy in hibernate.

In case of Read_Write policy hibernate uses Optimistic Locking where NaturalId 
key is used as a lock. If someone is trying to update the row, hibernate will 
acquire the lock on the key and subsequent reads/writes for the same key will 
be served by DB layer and later L2 cache will get updated asynchronously and 
eventually will remove the lock on the key.

But in case of NonStrictReadWrite, Hibernate allows read on inconsistent key 
from L2 cache i.e. It does not acquire the lock. which means subsequent reads 
will be allowed to read from L2 cache and background process will evict the 
cache for the key asynchronously. 

Test case is failing because It is checking non-existence of k (NaturalId) 
which is correct behaviour because test case is changing k to k`
In NonStrictReadWrite L2 cache has reads for both keys k and k` because It does 
not have lock on k which is incorrect. 
This is not causing problem for ReadWrite because key k is always locked in L2 
cache which delegate this read to db which eventually does not have key k 
(update with k`) and hence the test case is passing.

Solution:
problem is due to inconsistent L2 cache state in case of updating the 
naturalId. So, before validating the test case, wrote a utility to reload the 
entire L2 cache. 

I hope I have explained it properly. Please let me know If you need more info.


Regards,
Milap Wadhwa


was (Author: milap.wadhwa):
Hi Yakov,

Issue is with NONSTRICT_READ_WRITE policy in hibernate.

In case of Read_Write policy hibernate uses Optimistic Locking where NaturalId 
key is used as a lock. If someone is trying to update the row, hibernate will 
acquire the lock on the key and subsequent reads/writes for the same key will 
be served by DB layer and later L2 cache will get updated asynchronously and 
eventually will remove the lock on the key.

But in case of NonStrictReadWrite, Hibernate allows read on inconsistent key 
from L2 cache i.e. It does not acquire the lock. which means subsequent reads 
will be allowed to read from L2 cache and background process will evict the 
cache for the key asynchronously. 

Test case is failing because It is checking non-existence of k (NaturalId) 
which is correct behaviour because test case is changing k to k`
In NonStrictReadWrite L2 cache has reads for both keys k and k` because It does 
not have lock on k which is incorrect. 
This is not causing problem for ReadWrite because key k is always locked in L2 
cache which delegate this read to db which eventually does not have key k 
(update with k`) and hence the test case is passing.

Solution:
problem is due to inconsistent L2 cache state in case of updating the 
naturalId. So, before validating the test case, wrote a utility to reload the 
entire L2 cache. 

I hope I have explained it properly. Please let me know If you need more info.


Regards,
Milap Wadhwa

> [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] [Commented] (IGNITE-1084) [Test] HibernateL2CacheSelfTest#testNaturalIdCache() is broken

[Milap Wadhwa (JIRA)]

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

Milap Wadhwa commented on IGNITE-1084:
--

Hi Yakov,

Issue is with NONSTRICT_READ_WRITE policy in hibernate.

In case of Read_Write policy hibernate uses Optimistic Locking where NaturalId 
key is used as a lock. If someone is trying to update the row, hibernate will 
acquire the lock on the key and subsequent reads/writes for the same key will 
be served by DB layer and later L2 cache will get updated asynchronously and 
eventually will remove the lock on the key.

But in case of NonStrictReadWrite, Hibernate allows read on inconsistent key 
from L2 cache i.e. It does not acquire the lock. which means subsequent reads 
will be allowed to read from L2 cache and background process will evict the 
cache for the key asynchronously. 

Test case is failing because It is checking non-existence of k (NaturalId) 
which is correct behaviour because test case is changing k to k`
In NonStrictReadWrite L2 cache has reads for both keys k and k` because It does 
not have lock on k which is incorrect. 
This is not causing problem for ReadWrite because key k is always locked in L2 
cache which delegate this read to db which eventually does not have key k 
(update with k`) and hence the test case is passing.

Solution:
problem is due to inconsistent L2 cache state in case of updating the 
naturalId. So, before validating the test case, wrote a utility to reload the 
entire L2 cache. 

I hope I have explained it properly. Please let me know If you need more info.


Regards,
Milap Wadhwa

> [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] [Closed] (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 closed IGNITE-3331.
---

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

Vladimir Ozerov commented on IGNITE-3331:
-

Slight performance gain is confirmed.

> 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-3625) IGFS: Use common naming for IGFS meta and data caches.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-3625:


GitHub user tledkov-gridgain opened a pull request:

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

IGNITE-3625 IGFS: Use common naming for IGFS meta and data caches



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

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

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

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


commit 6be0a6f16fc76792dd35c82e992c7b685526c512
Author: tledkov-gridgain 
Date:   2016-08-04T09:31:44Z

IGNITE-3625 IGFS: Use common naming for IGFS meta and data caches




> 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 caches with any other cache name, an exception should 
> be thrown. The most simple way: throw an exception if user-configured cache 
> name starts with {{igfs-}} and ends with {{-meta}} or {{-data}}.
> Relevant code pieces:
> {{IgniteNamedInstance.initializeDefaultCacheConfiguration}}.



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

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

[Taras Ledkov (JIRA)]

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

Taras Ledkov 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 caches with any other cache name, an exception should be 
thrown. The most simple way: throw an exception if user-configured cache name 
starts with {{igfs-}} and ends with {{-meta}} or {{-data}}.
Relevant code pieces:
{{IgniteNamedInstance.initializeDefaultCacheConfiguration}}.

  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 {{igfs-}} 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 caches with any other cache name, an exception should 
> be thrown. The most simple way: throw an exception if user-configured cache 
> name starts with {{igfs-}} and ends with {{-meta}} or {{-data}}.
> Relevant code pieces:
> {{IgniteNamedInstance.initializeDefaultCacheConfiguration}}.



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

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

Eduard Shangareev edited comment on IGNITE-1192 at 8/4/16 11:26 AM:


I have sent email with my thoughts to dev-list. Pls, take a look.


was (Author: edshanggg):
I have sent my thoughts to dev-list. Pls, take a look.

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

Eduard Shangareev commented on IGNITE-1192:
---

I have sent my thoughts to dev-list. Pls, take a look.

> 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-3293) AWS bootstrap scripts patch for Ignite-Cassandra

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-3293:


Assignee: Alexey Kuznetsov  (was: Nikolay Tikhonov)

> 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: Alexey Kuznetsov
> 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=15407578#comment-15407578
 ] 

Ilya Suntsov commented on IGNITE-3293:
--

Alexey, 

I think - yes, we can merge.

> 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

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov commented on IGNITE-3293:
--

Ilya, Igor

So it seems I could merge to master?

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

Ilya Suntsov commented on IGNITE-3293:
--

Igor,

I've re-tested your changes. Load tests work fine.  

> 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-3569) Set copyOnRead property to FALSE for marshaller cache

[Dmitry Karachentsev (JIRA)]

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

Dmitry Karachentsev updated IGNITE-3569:

Assignee: Yakov Zhdanov  (was: Dmitry Karachentsev)

> Set copyOnRead property to FALSE for marshaller cache
> -
>
> Key: IGNITE-3569
> URL: https://issues.apache.org/jira/browse/IGNITE-3569
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Yakov Zhdanov
>Assignee: Yakov Zhdanov
> Fix For: 1.7
>
>
> Ignite unmarshalls type metadata when accessing it which is an overhead. Need 
> to fix this for marshaller cache and, probably, for other internal caches 
> (this needs to be investigated).



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

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

[Dmitry Karachentsev (JIRA)]

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

Dmitry Karachentsev updated IGNITE-1926:

Assignee: (was: Dmitry Karachentsev)

> 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
>  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] [Commented] (IGNITE-3628) ODBC: Improve data fetching performance.

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-3628:
-

I'm going to start with the simple benchmark so changes in the performance 
could be measured.

> ODBC: Improve data fetching performance.
> 
>
> Key: IGNITE-3628
> URL: https://issues.apache.org/jira/browse/IGNITE-3628
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Affects Versions: 1.6
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Critical
>  Labels: important, odbc
> Fix For: 1.8
>
>
> Need to add some kind of benchmark to be able to measure fetching performance 
> of the ODBC driver, then profile it and improve performance where it is 
> possible. Pay attention to the fetching page size.
> Consider adding "Fast first row" feature.
> Consider adding {{FETCH_PAGE_SIZE}} connection argument.



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

[jira] [Created] (IGNITE-3629) Web Console: Implement test for backend API routes

[Maxim Afanasiev (JIRA)]

Maxim Afanasiev created IGNITE-3629:
---

 Summary: Web Console: Implement test for backend API routes
 Key: IGNITE-3629
 URL: https://issues.apache.org/jira/browse/IGNITE-3629
 Project: Ignite
  Issue Type: Improvement
Reporter: Maxim Afanasiev
Assignee: Maxim Afanasiev


Need to implement integration tests for all backend routes.



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

[jira] [Updated] (IGNITE-3628) ODBC: Improve data fetching performance.

[Igor Sapego (JIRA)]

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

Igor Sapego updated IGNITE-3628:

Description: 
Need to add some kind of benchmark to be able to measure fetching performance 
of the ODBC driver, then profile it and improve performance where it is 
possible. Pay attention to the fetching page size.

Consider adding "Fast first row" feature.
Consider adding {{FETCH_PAGE_SIZE}} connection argument.

  was:Need to add some kind of benchmark to be able to measure fetching 
performance of the ODBC driver, then profile it and improve performance where 
it is possible. Pay attention to the fetching page size. Consider adding "Fast 
first row" feature.


> ODBC: Improve data fetching performance.
> 
>
> Key: IGNITE-3628
> URL: https://issues.apache.org/jira/browse/IGNITE-3628
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Affects Versions: 1.6
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Critical
>  Labels: important, odbc
> Fix For: 1.8
>
>
> Need to add some kind of benchmark to be able to measure fetching performance 
> of the ODBC driver, then profile it and improve performance where it is 
> possible. Pay attention to the fetching page size.
> Consider adding "Fast first row" feature.
> Consider adding {{FETCH_PAGE_SIZE}} connection argument.



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

[jira] [Updated] (IGNITE-3628) ODBC: Improve data fetching performance.

[Igor Sapego (JIRA)]

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

Igor Sapego updated IGNITE-3628:

Description: Need to add some kind of benchmark to be able to measure 
fetching performance of the ODBC driver, then profile it and improve 
performance where it is possible. Pay attention to the fetching page size. 
Consider adding "Fast first row" feature.  (was: Need to add some kind of 
benchmark to be able to measure fetching performance of the ODBC driver, then 
profile it and improve performance where it is possible. )

> ODBC: Improve data fetching performance.
> 
>
> Key: IGNITE-3628
> URL: https://issues.apache.org/jira/browse/IGNITE-3628
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Affects Versions: 1.6
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Critical
>  Labels: important, odbc
> Fix For: 1.8
>
>
> Need to add some kind of benchmark to be able to measure fetching performance 
> of the ODBC driver, then profile it and improve performance where it is 
> possible. Pay attention to the fetching page size. Consider adding "Fast 
> first row" feature.



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

[jira] [Updated] (IGNITE-3628) ODBC: Improve data fetching performance.

[Igor Sapego (JIRA)]

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

Igor Sapego updated IGNITE-3628:

Priority: Critical  (was: Major)

> ODBC: Improve data fetching performance.
> 
>
> Key: IGNITE-3628
> URL: https://issues.apache.org/jira/browse/IGNITE-3628
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Affects Versions: 1.6
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Critical
>  Labels: important, odbc
> Fix For: 1.8
>
>
> Need to add some kind of benchmark to be able to measure fetching performance 
> of the ODBC driver, then profile it and improve performance where it is 
> possible. 



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

[jira] [Created] (IGNITE-3628) ODBC: Improve data fetching performance.

[Igor Sapego (JIRA)]

Igor Sapego created IGNITE-3628:
---

 Summary: ODBC: Improve data fetching performance.
 Key: IGNITE-3628
 URL: https://issues.apache.org/jira/browse/IGNITE-3628
 Project: Ignite
  Issue Type: Task
  Components: odbc
Affects Versions: 1.6
Reporter: Igor Sapego
Assignee: Igor Sapego
 Fix For: 1.8


Need to add some kind of benchmark to be able to measure fetching performance 
of the ODBC driver, then profile it and improve performance where it is 
possible.



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

[jira] [Updated] (IGNITE-3628) ODBC: Improve data fetching performance.

[Igor Sapego (JIRA)]

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

Igor Sapego updated IGNITE-3628:

Description: Need to add some kind of benchmark to be able to measure 
fetching performance of the ODBC driver, then profile it and improve 
performance where it is possible.   (was: Need to add some kind of benchmark to 
be able to measure fetching performance of the ODBC driver, then profile it and 
improve performance where it is possible.)

> ODBC: Improve data fetching performance.
> 
>
> Key: IGNITE-3628
> URL: https://issues.apache.org/jira/browse/IGNITE-3628
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Affects Versions: 1.6
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>  Labels: important, odbc
> Fix For: 1.8
>
>
> Need to add some kind of benchmark to be able to measure fetching performance 
> of the ODBC driver, then profile it and improve performance where it is 
> possible. 



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

[jira] [Updated] (IGNITE-3627) ODBC: Tune ODBC capabilities to match capabilities of the Ignite SQL.

[Igor Sapego (JIRA)]

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

Igor Sapego updated IGNITE-3627:

Priority: Critical  (was: Major)

> ODBC: Tune ODBC capabilities to match capabilities of the Ignite SQL.
> -
>
> Key: IGNITE-3627
> URL: https://issues.apache.org/jira/browse/IGNITE-3627
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Affects Versions: 1.6
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Critical
>  Labels: important, odbc
> Fix For: 1.8
>
>
> Capabilities provided by {{ConnectionInfo}} class should be adjusted so that 
> {{SQLGetInfo}} would return real capabilities of Ignite SQL.



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

[jira] [Created] (IGNITE-3627) ODBC: Tune ODBC capabilities to match capabilities of the Ignite SQL.

[Igor Sapego (JIRA)]

Igor Sapego created IGNITE-3627:
---

 Summary: ODBC: Tune ODBC capabilities to match capabilities of the 
Ignite SQL.
 Key: IGNITE-3627
 URL: https://issues.apache.org/jira/browse/IGNITE-3627
 Project: Ignite
  Issue Type: Task
  Components: odbc
Affects Versions: 1.6
Reporter: Igor Sapego
Assignee: Igor Sapego
 Fix For: 1.8


Capabilities provided by {{ConnectionInfo}} class should be adjusted so that 
{{SQLGetInfo}} would return real capabilities of Ignite SQL.



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

[jira] [Updated] (IGNITE-3627) ODBC: Tune ODBC capabilities to match capabilities of the Ignite SQL.

[Igor Sapego (JIRA)]

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

Igor Sapego updated IGNITE-3627:

Labels: important odbc  (was: odbc)

> ODBC: Tune ODBC capabilities to match capabilities of the Ignite SQL.
> -
>
> Key: IGNITE-3627
> URL: https://issues.apache.org/jira/browse/IGNITE-3627
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Affects Versions: 1.6
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>  Labels: important, odbc
> Fix For: 1.8
>
>
> Capabilities provided by {{ConnectionInfo}} class should be adjusted so that 
> {{SQLGetInfo}} would return real capabilities of Ignite SQL.



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

[jira] [Updated] (IGNITE-3626) ODBC: Performance drop when connecting to Ignite with Tableau on Windows.

[Igor Sapego (JIRA)]

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

Igor Sapego updated IGNITE-3626:

Labels: important odbc  (was: odbc)

> ODBC: Performance drop when connecting to Ignite with Tableau on Windows.
> -
>
> Key: IGNITE-3626
> URL: https://issues.apache.org/jira/browse/IGNITE-3626
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 1.6
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Critical
>  Labels: important, odbc
> Fix For: 1.8
>
>
> It seems like we have a performance drop on Ignite after we connect to it 
> with Tableau on Windows (only connecting, no queries are being run).



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

[jira] [Created] (IGNITE-3626) ODBC: Performance drop when connecting to Ignite with Tableau on Windows.

[Igor Sapego (JIRA)]

Igor Sapego created IGNITE-3626:
---

 Summary: ODBC: Performance drop when connecting to Ignite with 
Tableau on Windows.
 Key: IGNITE-3626
 URL: https://issues.apache.org/jira/browse/IGNITE-3626
 Project: Ignite
  Issue Type: Bug
  Components: odbc
Affects Versions: 1.6
Reporter: Igor Sapego
Assignee: Igor Sapego
Priority: Critical
 Fix For: 1.8


It seems like we have a performance drop on Ignite after we connect to it with 
Tableau on Windows (only connecting, no queries are being run).



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

[jira] [Assigned] (IGNITE-2649) Ignition.localIgnite() unreliable under Gateways and cause wrong components deserialization.

[Dmitry Karachentsev (JIRA)]

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

Dmitry Karachentsev reassigned IGNITE-2649:
---

Assignee: Vladimir Ozerov  (was: Dmitry Karachentsev)

> Ignition.localIgnite() unreliable under Gateways and cause wrong components 
> deserialization.
> 
>
> Key: IGNITE-2649
> URL: https://issues.apache.org/jira/browse/IGNITE-2649
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ershov
>Assignee: Vladimir Ozerov
>Priority: Critical
>  Labels: 1.6, community
> Fix For: 1.7
>
>   Original Estimate: 8h
>  Remaining Estimate: 8h
>
> We can get something like this:
> {noformat}
> java.lang.IllegalArgumentException: This method should be accessed under 
> org.apache.ignite.thread.IgniteThread
> at org.apache.ignite.internal.IgnitionEx.localIgnite(IgnitionEx.java:1252)
> at org.apache.ignite.Ignition.localIgnite(Ignition.java:531)
> at org.project.MyPojo.readResolve(MyPojo.java:123)
> at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:746)
> at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1448)
> at 
> org.apache.ignite.internal.binary.BinaryUtils.doReadObject(BinaryUtils.java:1564)
> at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readObject(BinaryReaderExImpl.java:1086)
> at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.readFixedType(BinaryFieldAccessor.java:827)
> at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read(BinaryFieldAccessor.java:643)
> at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:734)
> at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1448)
> at 
> org.apache.ignite.internal.binary.BinaryUtils.doReadObject(BinaryUtils.java:1564)
> at 
> org.apache.ignite.internal.binary.BinaryUtils.deserializeOrUnmarshal(BinaryUtils.java:1908)
> at 
> org.apache.ignite.internal.binary.BinaryUtils.doReadMap(BinaryUtils.java:1892)
> at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1595)
> at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1644)
> at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read(BinaryFieldAccessor.java:643)
> at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:734)
> at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1448)
> at 
> org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:537)
> at 
> org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:117)
> at 
> org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinary(CacheObjectContext.java:257)
> at 
> org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:148)
> at 
> org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:135)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1757)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.setResult(GridPartitionedSingleGetFuture.java:629)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.localGet(GridPartitionedSingleGetFuture.java:421)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.mapKeyToNode(GridPartitionedSingleGetFuture.java:337)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.map(GridPartitionedSingleGetFuture.java:204)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.init(GridPartitionedSingleGetFuture.java:196)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.getAsync(GridDhtColocatedCache.java:266)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4774)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4758)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1391)
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.get(IgniteCacheProxy.java:865)
> {noformat}



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

Eduard Shangareev commented on IGNITE-1192:
---

Dmitriy,
1. I think, it is too early state to advance status.
2. I want to start the discussion today. Describe what was done, what problems 
I see and a list of features what 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=15407375#comment-15407375
 ] 

Taras Ledkov commented on IGNITE-2310:
--

The last version of the public API:
{code:title=IgniteCompute.java|borderStyle=solid}
public void affinityRun(@Nullable String cacheName, Object affKey, 
IgniteRunnable job) throws IgniteException;
public void affinityRun(@NotNull Collection cacheNames, Object affKey, 
IgniteRunnable job) throws IgniteException;
public void affinityRun(@NotNull Collection cacheNames, int partId, 
IgniteRunnable job) throws IgniteException;
public  R affinityCall(@Nullable String cacheName, Object affKey, 
IgniteCallable job) throws IgniteException;
public  R affinityCall(@NotNull Collection cacheNames, Object 
affKey, IgniteCallable job) throws IgniteException;
public  R affinityCall(@NotNull Collection cacheNames, int partId, 
IgniteCallable job) throws IgniteException;
{code}
Ambiguity is fixed on the tests side. In case this API will be approved we 
should notify customers about potential compilation fails.
I'll sent email on dev-list after approving.

> 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-3293) AWS bootstrap scripts patch for Ignite-Cassandra

[Igor Rudyak (JIRA)]

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

Igor Rudyak commented on IGNITE-3293:
-

Ilya,

It actually not the problem of "cassandra" test type. According to the logs 
there are couple of problems:

1) Cassandra node failed to bootstrap because of "upload failed: 
opt/ignite-cassandra-tests/bootstrap/first-node-lock to 
s3://qa-is-cass/test1/cassandra/first-node-lock Unable to locate credentials". 
It looks like there is a problem with permissions for 
"s3://qa-is-cass/test1/cassandra" folder or with role based authentication.

2) Ignite node failed to bootstrap because of "checking whether build 
environment is sane... configure: error: newly created file is older than 
distributed files!". The problem happened while trying to build Ganglia agent 
from source code. The reason for this is that EC2 node time was out of sync 
while it's started, however ntp was installed. I added additional logic to 
handle this by refreshing ntpd service.

All the changes were committed to "ignite-3293" branch.

> 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-3580) IGFS: Allow IGFS tasks execution on machines where IGFS is not configured.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-3580:
-

As this task is pretty big, I would split it into three subtasks, and implement 
them one by one in that order:
1) Pass {{IgfsOperationContext}} to all relevant {{IgfsMetaManager}} methods. 
2) Pass {{IgfsOperationContext}} to all relevant {{IgfsDataManager}} methods. 
3) At these points neither {{IgfsMetaManager}}. nor {{IgfsDataManager}} will 
depend on {{IgfsContext}}. So we can easily move them to {{IgfsProcessor}} and 
ensure that they always start, even if no IGFSs are configured on the node.


> IGFS: Allow IGFS tasks execution on machines where IGFS is not configured.
> --
>
> Key: IGNITE-3580
> URL: https://issues.apache.org/jira/browse/IGNITE-3580
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>Priority: Critical
> Fix For: 1.8
>
>
> Currently user has to configure IGFS on all nodes where data and meta caches 
> reside. Otherwise, he will not be able to execute metadata and data updates 
> on these machines.
> This requirement is synthetic. No reason to force user doing this. Instead, 
> all required tasks can be executed on data nodes without IGFS started on 
> them. Need to refactor IGFS to allow this.



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

[jira] [Commented] (IGNITE-3580) IGFS: Allow IGFS tasks execution on machines where IGFS is not configured.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-3580:
-

To achieve this we must do the following:
1) Complete IGNITE-3625 first. This way we will always be ready to derive meta 
and data cache names from IGFS name.

2) {{IgfsMetaManager}} and {{IgfsDataManager}} will become shared. That is, 
they must be placed directly into {{IgfsProcessor}}. Now they are placed inside 
{{IgfsContext}} (i.e. they belong to concrete IGFS instance for now).

3) We need to introduce some value object which will store the following data: 
kernal context, meta cache name, data cache name, client flag. E.g.:
{code}
class IgfsOperationContext {
GridKernalContext ctx;
String metaCacheName;
String dataCacheName;
boolean client;
}
{code}

4) This context will be passed to all {{IgfsDataManager}} and 
{{IgfsMetaManager}} operations.

5) Each {{IgfsImpl}} instance will create their own {{IgfsOperationContext}} on 
start. 

6) Each client operation will create this context when task is received on the 
server node as follows (pseudocode):
{code}
IgfsOperationContext createContext(GridKernalContext ctx, String igfsName) {
String metaCacheName = IgfsUtils.metaCacheName(igfsName); // IGNITE-3625
String dataCacheName = IgfsUtils.metaCacheName(igfsName); // IGNITE-3625
boolean client = false; // Task are routed only to server nodes, so client 
flag is always false.

return new IgfsOpeartionContext(ctx, metaCacheName, dataCacheName, client);
}
{code}


> IGFS: Allow IGFS tasks execution on machines where IGFS is not configured.
> --
>
> Key: IGNITE-3580
> URL: https://issues.apache.org/jira/browse/IGNITE-3580
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>Priority: Critical
> Fix For: 1.8
>
>
> Currently user has to configure IGFS on all nodes where data and meta caches 
> reside. Otherwise, he will not be able to execute metadata and data updates 
> on these machines.
> This requirement is synthetic. No reason to force user doing this. Instead, 
> all required tasks can be executed on data nodes without IGFS started on 
> them. Need to refactor IGFS to allow this.



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

[jira] [Updated] (IGNITE-3580) IGFS: Allow IGFS tasks execution on machines where IGFS is not configured.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-3580:

Assignee: Taras Ledkov

> IGFS: Allow IGFS tasks execution on machines where IGFS is not configured.
> --
>
> Key: IGNITE-3580
> URL: https://issues.apache.org/jira/browse/IGNITE-3580
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>Priority: Critical
> Fix For: 1.8
>
>
> Currently user has to configure IGFS on all nodes where data and meta caches 
> reside. Otherwise, he will not be able to execute metadata and data updates 
> on these machines.
> This requirement is synthetic. No reason to force user doing this. Instead, 
> all required tasks can be executed on data nodes without IGFS started on 
> them. Need to refactor IGFS to allow this.



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

[jira] [Commented] (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:comment-tabpanel=15407264#comment-15407264
 ] 

Vladimir Ozerov commented on IGNITE-3597:
-

Sorry for missing description, I forgot to move it here from dev list 
discussion. Essentially, we need to do the following:
1) When Ignite is about to start, we must resolve it's work directory and put 
it to {{IgniteConfiguration.workDirectory}} field.
Relevant code pieces: {{IgnitionEx$IgniteNamedInstance.intializeConfiguration}}.
Note that we should not put anything to static variables.

2) Rework all places (I see 18) where {{IgniteUtils.resolveWorkDirectory}} is 
called. Now it should accept three arguments: 
- instance's work dir you set on the step 1;
- path;
- "delIfExists" flag.

The main challenge here is to get the first argument in all the places where 
{{IgniteUtils.resolveWorkDirectory}} is called.

> 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
> Fix For: 1.8
>
>
> 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] [Closed] (IGNITE-3559) CPP: Review Ignite C++ API and provide list of breaking improvements that can be included in Ignite 2.0

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-3559.
---

> CPP: Review Ignite C++ API and provide list of breaking improvements that can 
> be included in Ignite 2.0
> ---
>
> Key: IGNITE-3559
> URL: https://issues.apache.org/jira/browse/IGNITE-3559
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Igor Sapego
>Assignee: Vladimir Ozerov
>  Labels: cpp
> Fix For: 1.8
>
>
> As there is going to be Ignite 2.0 release soon, It is a good opportunity to 
> improve Ignite C++ API without the need to maintain backward compatibility. 
> Let's collect and discuss all the proposal for the changes in this task and 
> then create matching subtasks for all the accepted proposals.



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

[jira] [Commented] (IGNITE-3559) CPP: Review Ignite C++ API and provide list of breaking improvements that can be included in Ignite 2.0

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-3559:
-

Looks good to me. Closing this ticket.

> CPP: Review Ignite C++ API and provide list of breaking improvements that can 
> be included in Ignite 2.0
> ---
>
> Key: IGNITE-3559
> URL: https://issues.apache.org/jira/browse/IGNITE-3559
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Igor Sapego
>Assignee: Vladimir Ozerov
>  Labels: cpp
> Fix For: 1.8
>
>
> As there is going to be Ignite 2.0 release soon, It is a good opportunity to 
> improve Ignite C++ API without the need to maintain backward compatibility. 
> Let's collect and discuss all the proposal for the changes in this task and 
> then create matching subtasks for all the accepted proposals.



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

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

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-3359.
---

> .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: Vladimir Ozerov
>  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] [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=15407246#comment-15407246
 ] 

ASF GitHub Bot commented on IGNITE-3359:


Github user asfgit closed the pull request at:

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


> .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: Vladimir Ozerov
>  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] [Commented] (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:comment-tabpanel=15407236#comment-15407236
 ] 

Vladimir Ozerov commented on IGNITE-2852:
-

This appears to be pretty tough task. As soon as object is converted to binary 
form we are no longer able to compare it with another binaries since we lost 
comparison logic.

Let's keep this ticket on hold for a while, until we came up with clear 
solution.

> 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] [Assigned] (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 reassigned IGNITE-2852:
---

Assignee: Vladimir Ozerov  (was: Andrew Mashenkov)

> 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: Vladimir Ozerov
> 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)