[jira] [Commented] (IGNITE-3207) Rename IgniteConfiguration.gridName
[ 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
[ 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
[ 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.
[ 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: vdpyatkovDate: 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
[ 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: MaBiaoDate: 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
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
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
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)
[ 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
[ 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
[ 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
[ 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)
[ 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)
[ 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)
[ 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)