[jira] [Commented] (IGNITE-3207) Rename IgniteConfiguration.gridName

2016-05-27 Thread Dmitriy Setrakyan (JIRA)

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

Dmitriy Setrakyan commented on IGNITE-3207:
---

I think I like {{instaneName}} better.

> Rename IgniteConfiguration.gridName
> ---
>
> Key: IGNITE-3207
> URL: https://issues.apache.org/jira/browse/IGNITE-3207
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Biao Ma
> Fix For: 1.7
>
>
> We have got a TON of questions on gridName property. Everyone thinks that 
> clusters are formed based on the gridName, that is, nodes with the same grid 
> name will join one cluster, and nodes with a different name will be in a 
> separate cluster.
> Let's do the following:
> * Deprecate IgniteConfiguration.gridName
> * Add IgniteConfiguration.localInstanceName
> * Rename related parameters in Ignition class (and other places, if present)
> * Update Javadoc: clearly state that this name only works locally and has no 
> effect on topology.



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


[jira] [Commented] (IGNITE-2969) Optimistic transactions support in deadlock detection

2016-05-27 Thread Semen Boikov (JIRA)

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

Semen Boikov commented on IGNITE-2969:
--

Did quick review, have some comments:
- you added additional 'sychronized' usages, need check that it does not impact 
performance, please execute some single-node benchmark. If performance is 
impacted then need to use additional synchronization only if timeout is enabled
- in some places there is nested synchronization, I think it can be changed to 
use only one mutex
- now transactions implement GridTimeoutObject and 'isTimedOut' is called in 
some random places, I think this complicates timeout handling logic and is not 
really needed. Let's remove GridTimeoutObject from tx, and all timeout handling 
logic should remain only in transaction futures (lock and prepare futures)

> Optimistic transactions support in deadlock detection
> -
>
> Key: IGNITE-2969
> URL: https://issues.apache.org/jira/browse/IGNITE-2969
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Reporter: Andrey Gura
>Assignee: Andrey Gura
> Fix For: 1.7
>
>
> Deadlock detection doesn't support optimistic transactions now. It should be 
> implemented.



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


[jira] [Commented] (IGNITE-1371) Key-Value store (like Cassandra) as CacheStore

2016-05-27 Thread Igor Rudyak (JIRA)

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

Igor Rudyak commented on IGNITE-1371:
-

Anton, my login is: irudyak

> Key-Value store (like Cassandra) as CacheStore
> --
>
> Key: IGNITE-1371
> URL: https://issues.apache.org/jira/browse/IGNITE-1371
> Project: Ignite
>  Issue Type: New Feature
>  Components: cache
>Affects Versions: ignite-1.4
>Reporter: Alexandre Boudnik
> Fix For: 1.6
>
> Attachments: master_02b59e4_ignite-1371.patch
>
>   Original Estimate: 504h
>  Remaining Estimate: 504h
>
> It will provide ability to map particular cache holding POJOs to Cassandra 
> table. Later it would be generalized to support eventually any any Key-Value 
> store.



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


[jira] [Commented] (IGNITE-2616) NonHeap memory usage metrics don't work as expected.

2016-05-27 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on IGNITE-2616:


GitHub user vldpyatkov opened a pull request:

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

IGNITE-2616

IGNITE-2616
NonHeap memory usage metrics don't work as expected.

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

$ git pull https://github.com/vldpyatkov/ignite ignite-2616

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

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


commit cacb62a92888cc27f9baab9a27518e66bfc3484e
Author: vdpyatkov 
Date:   2016-05-27T15:41:11Z

IGNITE-2616
NonHeap memory usage metrics don't work as expected.




> NonHeap memory usage metrics don't work as expected.
> 
>
> Key: IGNITE-2616
> URL: https://issues.apache.org/jira/browse/IGNITE-2616
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ershov
>Assignee: Vladislav Pyatkov
>Priority: Minor
> Attachments: ClusterMetricsOnCacheSelfTest.java
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> This simple code:
> {noformat}
> public static void main(String ... args) {
> MemoryMXBean mxBean = ManagementFactory.getMemoryMXBean();
> System.out.println(mxBean.getNonHeapMemoryUsage());
> GridUnsafeMemory uMem = new GridUnsafeMemory(1024L * 1024 * 1024 * 
> 3); //3GB
> System.out.println(mxBean.getNonHeapMemoryUsage());
> uMem.allocate(1024 * 1024 * 1024, true, false);
> System.out.println(mxBean.getNonHeapMemoryUsage());
> uMem.allocate(1024 * 1024 * 1024, true, true);
> System.out.println(mxBean.getNonHeapMemoryUsage());
> }
> {noformat}
> shows: 
> {noformat}
> init = 2555904(2496K) used = 4783352(4671K) committed = 8060928(7872K) max = 
> -1(-1K)
> init = 2555904(2496K) used = 5018704(4901K) committed = 8060928(7872K) max = 
> -1(-1K)
> init = 2555904(2496K) used = 5018960(4901K) committed = 8060928(7872K) max = 
> -1(-1K)
> init = 2555904(2496K) used = 5018960(4901K) committed = 8060928(7872K) max = 
> -1(-1K)
> {noformat}
> which means: offHeap metrics are incorrect. The  problem is: Apache Ignite 
> uses that MemoryMXBean  for collecting metrics, thus Apache Ignite offHeap 
> metrics are incorrect too. We should find the way to fix this, if there are 
> any.



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


[jira] [Commented] (IGNITE-3207) Rename IgniteConfiguration.gridName

2016-05-27 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on IGNITE-3207:


GitHub user f7753 opened a pull request:

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

IGNITE-3207 Rename IgniteConfiguration.gridName

Deprecate IgniteConfiguration.gridName
Add IgniteConfiguration.localInstanceName
Rename related parameters in Ignition class (and other places, if present)
Update Javadoc: clearly state that this name only works locally and has no 
effect on topology.

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

$ git pull https://github.com/f7753/ignite gridname

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

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


commit 3eb575a547ae3f99313906cfea7baaef0501ebaf
Author: MaBiao 
Date:   2016-05-27T14:36:49Z

fix the name from gridName to localInstanceName




> Rename IgniteConfiguration.gridName
> ---
>
> Key: IGNITE-3207
> URL: https://issues.apache.org/jira/browse/IGNITE-3207
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Biao Ma
> Fix For: 1.7
>
>
> We have got a TON of questions on gridName property. Everyone thinks that 
> clusters are formed based on the gridName, that is, nodes with the same grid 
> name will join one cluster, and nodes with a different name will be in a 
> separate cluster.
> Let's do the following:
> * Deprecate IgniteConfiguration.gridName
> * Add IgniteConfiguration.localInstanceName
> * Rename related parameters in Ignition class (and other places, if present)
> * Update Javadoc: clearly state that this name only works locally and has no 
> effect on topology.



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


[jira] [Commented] (IGNITE-3183) ScanQuery and localEntries are ignored keepBinary flag in OFFHEAP_TIERED mode

2016-05-27 Thread Anton Vinogradov (JIRA)

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

Anton Vinogradov commented on IGNITE-3183:
--

Semen,

That's behavior was not changed. 
Previously object deserialised at AbstractLazySwapEntry.key() ignoring 
keepBinary flag.
Now it deserialised at 
org/apache/ignite/internal/processors/cache/query/GridCacheQueryManager.java:1160

> ScanQuery and localEntries are ignored keepBinary flag in OFFHEAP_TIERED mode
> -
>
> Key: IGNITE-3183
> URL: https://issues.apache.org/jira/browse/IGNITE-3183
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, important
>Affects Versions: 1.6
>Reporter: Nikolay Tikhonov
>Assignee: Anton Vinogradov
> Attachments: CacheKeepBinaryIterationTest.java
>
>
> {{ScanQuery}} and {{localEntries}} method returns iterator which contains 
> deserialized entries but they have been called with withKeepBinary flag. 
> Reproducible test attached.



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


[jira] [Commented] (IGNITE-3192) Leaks at the GridCacheQueryManager on iterator canceling

2016-05-27 Thread Semen Boikov (JIRA)

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

Semen Boikov commented on IGNITE-3192:
--

Reviewed, looks good, merged into master (commit d01a305).

> Leaks at the GridCacheQueryManager on iterator canceling
> 
>
> Key: IGNITE-3192
> URL: https://issues.apache.org/jira/browse/IGNITE-3192
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 1.7
>
>
> When cancel request and scan request are processed with a race the 
> GridFutureAdapter object isn't removed form the  
> GridCacheQueryManager.qryIters submaps.
> The problem is reproduced occasionally by the test:  
> [GridCacheAtomicNearEnabledPrimaryWriteOrderMultiNodeFullApiSelfTest.testIgniteCacheIterator|http://149.202.210.143:8111/viewLog.html?buildId=250124=buildResultsDiv=IgniteTests_IgniteCacheFullApi]



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


[jira] [Closed] (IGNITE-3192) Leaks at the GridCacheQueryManager on iterator canceling

2016-05-27 Thread Semen Boikov (JIRA)

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

Semen Boikov closed IGNITE-3192.


> Leaks at the GridCacheQueryManager on iterator canceling
> 
>
> Key: IGNITE-3192
> URL: https://issues.apache.org/jira/browse/IGNITE-3192
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 1.7
>
>
> When cancel request and scan request are processed with a race the 
> GridFutureAdapter object isn't removed form the  
> GridCacheQueryManager.qryIters submaps.
> The problem is reproduced occasionally by the test:  
> [GridCacheAtomicNearEnabledPrimaryWriteOrderMultiNodeFullApiSelfTest.testIgniteCacheIterator|http://149.202.210.143:8111/viewLog.html?buildId=250124=buildResultsDiv=IgniteTests_IgniteCacheFullApi]



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


[jira] [Commented] (IGNITE-3192) Leaks at the GridCacheQueryManager on iterator canceling

2016-05-27 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on IGNITE-3192:


Github user asfgit closed the pull request at:

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


> Leaks at the GridCacheQueryManager on iterator canceling
> 
>
> Key: IGNITE-3192
> URL: https://issues.apache.org/jira/browse/IGNITE-3192
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 1.7
>
>
> When cancel request and scan request are processed with a race the 
> GridFutureAdapter object isn't removed form the  
> GridCacheQueryManager.qryIters submaps.
> The problem is reproduced occasionally by the test:  
> [GridCacheAtomicNearEnabledPrimaryWriteOrderMultiNodeFullApiSelfTest.testIgniteCacheIterator|http://149.202.210.143:8111/viewLog.html?buildId=250124=buildResultsDiv=IgniteTests_IgniteCacheFullApi]



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


[jira] [Assigned] (IGNITE-3207) Rename IgniteConfiguration.gridName

2016-05-27 Thread Biao Ma (JIRA)

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

Biao Ma reassigned IGNITE-3207:
---

Assignee: Biao Ma

> Rename IgniteConfiguration.gridName
> ---
>
> Key: IGNITE-3207
> URL: https://issues.apache.org/jira/browse/IGNITE-3207
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Biao Ma
> Fix For: 1.7
>
>
> We have got a TON of questions on gridName property. Everyone thinks that 
> clusters are formed based on the gridName, that is, nodes with the same grid 
> name will join one cluster, and nodes with a different name will be in a 
> separate cluster.
> Let's do the following:
> * Deprecate IgniteConfiguration.gridName
> * Add IgniteConfiguration.localInstanceName
> * Rename related parameters in Ignition class (and other places, if present)
> * Update Javadoc: clearly state that this name only works locally and has no 
> effect on topology.



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


[jira] [Updated] (IGNITE-1915) .Net: Ignite as Entity Framework Second-Level Cache

2016-05-27 Thread Pavel Tupitsyn (JIRA)

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

Pavel Tupitsyn updated IGNITE-1915:
---
Description: 
Entity Framework is #1 ORM for .NET
We should provide easy solution to boost Entity Framework performance with 
Ignite.

EF5 and EF6 have different 2nd level cache mechanisms (EF5 has a built-in one, 
EF6 requies more customization or a 3rd party lib like 
https://efcache.codeplex.com/). For now, let's do EF6 only.

This should be in a separate assembly and a separate NuGet package.

  was:
Entity Framework is #1 ORM for .NET
We should provide easy solution to boost Entity Framework performance with 
Ignite.

* EF5 and EF6 have different 2nd level cache mechanisms (EF5 has a built-in 
one, EF6 requies more customization or a 3rd party lib like 
https://efcache.codeplex.com/)


> .Net: Ignite as Entity Framework Second-Level Cache
> ---
>
> Key: IGNITE-1915
> URL: https://issues.apache.org/jira/browse/IGNITE-1915
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>
> Entity Framework is #1 ORM for .NET
> We should provide easy solution to boost Entity Framework performance with 
> Ignite.
> EF5 and EF6 have different 2nd level cache mechanisms (EF5 has a built-in 
> one, EF6 requies more customization or a 3rd party lib like 
> https://efcache.codeplex.com/). For now, let's do EF6 only.
> This should be in a separate assembly and a separate NuGet package.



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


[jira] [Commented] (IGNITE-3183) ScanQuery and localEntries are ignored keepBinary flag in OFFHEAP_TIERED mode

2016-05-27 Thread Semen Boikov (JIRA)

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

Semen Boikov commented on IGNITE-3183:
--

Reviewed, I didn't like that method 'context.keepBinary' which is based on 
thread-local variable is called from random places, I changed this to call it 
once in GridCacheAdapter and pass to all 'terators' methods, please take a look 
at my changes.

Also it isn't clear why key and value are handled differently in 
'GridCacheQueryManager.scanIterator', could you please explain this?

> ScanQuery and localEntries are ignored keepBinary flag in OFFHEAP_TIERED mode
> -
>
> Key: IGNITE-3183
> URL: https://issues.apache.org/jira/browse/IGNITE-3183
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, important
>Affects Versions: 1.6
>Reporter: Nikolay Tikhonov
>Assignee: Anton Vinogradov
> Attachments: CacheKeepBinaryIterationTest.java
>
>
> {{ScanQuery}} and {{localEntries}} method returns iterator which contains 
> deserialized entries but they have been called with withKeepBinary flag. 
> Reproducible test attached.



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


[jira] [Assigned] (IGNITE-2680) Terminating running SQL queries

2016-05-27 Thread Alexei Scherbakov (JIRA)

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

Alexei Scherbakov reassigned IGNITE-2680:
-

Assignee: Alexei Scherbakov

> Terminating running SQL queries
> ---
>
> Key: IGNITE-2680
> URL: https://issues.apache.org/jira/browse/IGNITE-2680
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Alexei Scherbakov
>  Labels: important
>
> If to start a long running SQL query over a huge cache will millions of 
> entries there should be a way terminate it. Even if {{QueryCursor}} is closed 
> the query won't be cancelled consuming available resources.
> There should be a way to close a query having using an object that is related 
> to it. Seems that ideally we can use {{QueryCursor.close()}} method for that;



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


[jira] [Commented] (IGNITE-1371) Key-Value store (like Cassandra) as CacheStore

2016-05-27 Thread Anton Vinogradov (JIRA)

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

Anton Vinogradov commented on IGNITE-1371:
--

Igor, I can add you to contributors group.
Please register and provide me your login.

> Key-Value store (like Cassandra) as CacheStore
> --
>
> Key: IGNITE-1371
> URL: https://issues.apache.org/jira/browse/IGNITE-1371
> Project: Ignite
>  Issue Type: New Feature
>  Components: cache
>Affects Versions: ignite-1.4
>Reporter: Alexandre Boudnik
> Fix For: 1.6
>
> Attachments: master_02b59e4_ignite-1371.patch
>
>   Original Estimate: 504h
>  Remaining Estimate: 504h
>
> It will provide ability to map particular cache holding POJOs to Cassandra 
> table. Later it would be generalized to support eventually any any Key-Value 
> store.



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


[jira] [Resolved] (IGNITE-1575) NPE when cache is started concurrently with the node stop

2016-05-27 Thread Alexei Scherbakov (JIRA)

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

Alexei Scherbakov resolved IGNITE-1575.
---
Resolution: Cannot Reproduce
  Assignee: Valentin Kulichenko  (was: Alexei Scherbakov)

I was not able to reproduce it using different configurations of a grid.
Need more info on how it was achieved.


> NPE when cache is started concurrently with the node stop
> -
>
> Key: IGNITE-1575
> URL: https://issues.apache.org/jira/browse/IGNITE-1575
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
> Fix For: 1.7
>
>
> It's not causing any harm, but it's possible to get the NPE below during the 
> node stop.
> {noformat}
> 57724 [main] ERROR IgniteKernal%t1-1 - Got exception while starting (will 
> rollback startup routine).
> java.lang.NullPointerException
> at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.onKernalStart0(CacheContinuousQueryManager.java:91)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheManagerAdapter.onKernalStart(GridCacheManagerAdapter.java:97)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:1058)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:833)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:829)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1549)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1416)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:916)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:477)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:458)
> at org.apache.ignite.Ignition.start(Ignition.java:321)
> .. application stack frames ...
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
> at 
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {noformat}



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


[jira] [Created] (IGNITE-3209) Need to wait for affinity assignment change during affinityCall failover

2016-05-27 Thread Valentin Kulichenko (JIRA)
Valentin Kulichenko created IGNITE-3209:
---

 Summary: Need to wait for affinity assignment change during 
affinityCall failover
 Key: IGNITE-3209
 URL: https://issues.apache.org/jira/browse/IGNITE-3209
 Project: Ignite
  Issue Type: Bug
  Components: compute
Affects Versions: 1.6
Reporter: Valentin Kulichenko
Assignee: Valentin Kulichenko
 Fix For: 1.7


{{AlwaysFailoverSpi.failover()}} method makes several attempts (5 by default) 
to get new primary node for the affinity key. Affinity assignment takes time, 
so there is a big chance to make all these attempts before new node is returned.

We need to add discovery event that initiated failover to {{FailoverContext}} 
and wait for affinity is assigned.



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


[jira] [Created] (IGNITE-3208) Add ability to yardstick to restart drivers

2016-05-27 Thread Ksenia Rybakova (JIRA)
Ksenia Rybakova created IGNITE-3208:
---

 Summary: Add ability to yardstick to restart drivers
 Key: IGNITE-3208
 URL: https://issues.apache.org/jira/browse/IGNITE-3208
 Project: Ignite
  Issue Type: Wish
Affects Versions: 1.6
Reporter: Ksenia Rybakova


Currently, yardstick supports only RESTART_SERVERS option. Please, add similar 
option to restart drivers. This is required for fault tolerance tests.



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


[jira] [Created] (IGNITE-3207) Rename IgniteConfiguration.gridName

2016-05-27 Thread Pavel Tupitsyn (JIRA)
Pavel Tupitsyn created IGNITE-3207:
--

 Summary: Rename IgniteConfiguration.gridName
 Key: IGNITE-3207
 URL: https://issues.apache.org/jira/browse/IGNITE-3207
 Project: Ignite
  Issue Type: Improvement
  Components: general
Affects Versions: 1.1.4
Reporter: Pavel Tupitsyn
 Fix For: 1.7


We have got a TON of questions on gridName property. Everyone thinks that 
clusters are formed based on the gridName, that is, nodes with the same grid 
name will join one cluster, and nodes with a different name will be in a 
separate cluster.

Let's do the following:
* Deprecate IgniteConfiguration.gridName
* Add IgniteConfiguration.localInstanceName
* Rename related parameters in Ignition class (and other places, if present)
* Update Javadoc: clearly state that this name only works locally and has no 
effect on topology.



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


[jira] [Resolved] (IGNITE-3147) Add missing properties to configuration (CollisionSpi and FailoverSpi)

2016-05-27 Thread Vasiliy Sisko (JIRA)

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

Vasiliy Sisko resolved IGNITE-3147.
---
Resolution: Fixed
  Assignee: Pavel Konstantinov  (was: Vasiliy Sisko)

# Fixed unique attribute check
# Fixed removing of JobStealing attribute
# Fixed Logger code generation.

> Add missing properties to configuration (CollisionSpi and FailoverSpi)
> --
>
> Key: IGNITE-3147
> URL: https://issues.apache.org/jira/browse/IGNITE-3147
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Affects Versions: 1.7
>Reporter: Vasiliy Sisko
>Assignee: Pavel Konstantinov
> Fix For: 1.7
>
>
> See 
> http://apache-ignite-users.70518.x6.nabble.com/How-to-auto-generate-spring-configuration-file-td4284.html



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


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

2016-05-27 Thread Taras Ledkov (JIRA)

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

Taras Ledkov reassigned IGNITE-2310:


Assignee: Taras Ledkov  (was: Andrey Gura)

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



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


[jira] [Commented] (IGNITE-3192) Leaks at the GridCacheQueryManager on iterator canceling

2016-05-27 Thread Taras Ledkov (JIRA)

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

Taras Ledkov commented on IGNITE-3192:
--

Review issue is fixed. Query execution is skipped in specified case. Please 
take a look.
Tests [results|http://149.202.210.143:8111/viewLog.html?buildId=253136] on the 
branch

> Leaks at the GridCacheQueryManager on iterator canceling
> 
>
> Key: IGNITE-3192
> URL: https://issues.apache.org/jira/browse/IGNITE-3192
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 1.7
>
>
> When cancel request and scan request are processed with a race the 
> GridFutureAdapter object isn't removed form the  
> GridCacheQueryManager.qryIters submaps.
> The problem is reproduced occasionally by the test:  
> [GridCacheAtomicNearEnabledPrimaryWriteOrderMultiNodeFullApiSelfTest.testIgniteCacheIterator|http://149.202.210.143:8111/viewLog.html?buildId=250124=buildResultsDiv=IgniteTests_IgniteCacheFullApi]



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


[jira] [Closed] (IGNITE-3145) Display in metadata list cache schema name instead of cache name if schema present in cache configuration

2016-05-27 Thread Pavel Konstantinov (JIRA)

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

Pavel Konstantinov closed IGNITE-3145.
--
Assignee: (was: Pavel Konstantinov)

Closed.

> Display in metadata list cache schema name instead of cache name if schema 
> present in cache configuration 
> --
>
> Key: IGNITE-3145
> URL: https://issues.apache.org/jira/browse/IGNITE-3145
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Pavel Konstantinov
>Priority: Minor
> Fix For: 1.7
>
>
> Currently we display cache name, but sort alphabetically considering cache 
> schema name.



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


[jira] [Commented] (IGNITE-3147) Add missing properties to configuration (CollisionSpi and FailoverSpi)

2016-05-27 Thread Pavel Konstantinov (JIRA)

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

Pavel Konstantinov commented on IGNITE-3147:


{code}Caused by: class org.apache.ignite.IgniteCheckedException: Log4j 
configuration path was not found: undefined{code}

> Add missing properties to configuration (CollisionSpi and FailoverSpi)
> --
>
> Key: IGNITE-3147
> URL: https://issues.apache.org/jira/browse/IGNITE-3147
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Affects Versions: 1.7
>Reporter: Vasiliy Sisko
>Assignee: Vasiliy Sisko
> Fix For: 1.7
>
>
> See 
> http://apache-ignite-users.70518.x6.nabble.com/How-to-auto-generate-spring-configuration-file-td4284.html



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


[jira] [Commented] (IGNITE-3147) Add missing properties to configuration (CollisionSpi and FailoverSpi)

2016-05-27 Thread Pavel Konstantinov (JIRA)

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

Pavel Konstantinov commented on IGNITE-3147:


Generated incorrect java-code ""
{code}






{code}

> Add missing properties to configuration (CollisionSpi and FailoverSpi)
> --
>
> Key: IGNITE-3147
> URL: https://issues.apache.org/jira/browse/IGNITE-3147
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Affects Versions: 1.7
>Reporter: Vasiliy Sisko
>Assignee: Vasiliy Sisko
> Fix For: 1.7
>
>
> See 
> http://apache-ignite-users.70518.x6.nabble.com/How-to-auto-generate-spring-configuration-file-td4284.html



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


[jira] [Reopened] (IGNITE-3147) Add missing properties to configuration (CollisionSpi and FailoverSpi)

2016-05-27 Thread Pavel Konstantinov (JIRA)

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

Pavel Konstantinov reopened IGNITE-3147:

  Assignee: Vasiliy Sisko  (was: Pavel Konstantinov)

# Should the key be unique for Job Stealing CollisionSpi items? I was able to 
create two items with the same key.
# error when trying to remove Job Stealing items
{code}
13:06:55.721 Error: _model(...)[field.model] is undefined
tableRemove@https://staging-console.gridgain.com/app.js:22053:25
.execute/https://staging-console.gridgain.com/app.js:18358:50
anonymous/fn@https://staging-console.gridgain.com/vendors.js line 117717 > 
Function:2:580
expensiveCheckFn@https://staging-console.gridgain.com/vendors.js:118625:24
ngEventHandler/https://staging-console.gridgain.com/vendors.js:121598:21
$RootScopeProvider/this.$gethttps://staging-console.gridgain.com/vendors.js:119403:22
$RootScopeProvider/this.$gethttps://staging-console.gridgain.com/vendors.js:119426:26
ngEventHandler/<@https://staging-console.gridgain.com/vendors.js:121603:21
jQuery.event.dispatch@https://staging-console.gridgain.com/vendors.js:107979:25
jQuery.event.add/elemData.handle@https://staging-console.gridgain.com/vendors.js:107850:91
1 vendors.js:116904:24
consoleLog/<() vendors.js:116904
$ExceptionHandlerProvider/this.$get Add missing properties to configuration (CollisionSpi and FailoverSpi)
> --
>
> Key: IGNITE-3147
> URL: https://issues.apache.org/jira/browse/IGNITE-3147
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Affects Versions: 1.7
>Reporter: Vasiliy Sisko
>Assignee: Vasiliy Sisko
> Fix For: 1.7
>
>
> See 
> http://apache-ignite-users.70518.x6.nabble.com/How-to-auto-generate-spring-configuration-file-td4284.html



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