[jira] [Commented] (IGNITE-2948) Optimize usage of GridCacheConcurrentMap
[ https://issues.apache.org/jira/browse/IGNITE-2948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15233238#comment-15233238 ] Ilya Lantukh commented on IGNITE-2948: -- Possible further optimizations: 1. GridCachePartitionTopologyImpl - get rid of RW lock, use volatile reads/writes. 2. Adjust parameters of internal CHM in new GridCacheConcurrentMapImpl. Fixed most of the tests, working on the following problems now: 1. Occasional hang-ups in tests that involve constant topology changes. 2. Sometimes GridCacheAdapter tries to create local partition that shouldn't belong to current node, resulting in GridDhtInvalidPartitionException. > Optimize usage of GridCacheConcurrentMap > > > Key: IGNITE-2948 > URL: https://issues.apache.org/jira/browse/IGNITE-2948 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Ilya Lantukh >Assignee: Ilya Lantukh > > 1. Eliminate cases where an entry is stored in multiple maps. > 2. Change GridCacheConcurrentMap implementation to be based on internal > ConcurrentMap. > 3. Remove redundant and obsolete code related to map usage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-2948) Optimize usage of GridCacheConcurrentMap
[ https://issues.apache.org/jira/browse/IGNITE-2948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15233238#comment-15233238 ] Ilya Lantukh edited comment on IGNITE-2948 at 4/9/16 12:53 AM: --- Possible further optimizations: 1. GridCachePartitionTopologyImpl - get rid of RW lock, use volatile reads/writes. 2. Adjust parameters of internal CHM in new GridCacheConcurrentMapImpl. Fixed most of simple test failures, working on the following problems now: 1. Occasional hang-ups in tests that involve constant topology changes. 2. Sometimes GridCacheAdapter tries to create local partition that shouldn't belong to current node, resulting in GridDhtInvalidPartitionException. was (Author: ilantukh): Possible further optimizations: 1. GridCachePartitionTopologyImpl - get rid of RW lock, use volatile reads/writes. 2. Adjust parameters of internal CHM in new GridCacheConcurrentMapImpl. Fixed most of the tests, working on the following problems now: 1. Occasional hang-ups in tests that involve constant topology changes. 2. Sometimes GridCacheAdapter tries to create local partition that shouldn't belong to current node, resulting in GridDhtInvalidPartitionException. > Optimize usage of GridCacheConcurrentMap > > > Key: IGNITE-2948 > URL: https://issues.apache.org/jira/browse/IGNITE-2948 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Ilya Lantukh >Assignee: Ilya Lantukh > > 1. Eliminate cases where an entry is stored in multiple maps. > 2. Change GridCacheConcurrentMap implementation to be based on internal > ConcurrentMap. > 3. Remove redundant and obsolete code related to map usage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2854) Need to implement deadlock detection
[
https://issues.apache.org/jira/browse/IGNITE-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15233174#comment-15233174
]
Andrey Gura commented on IGNITE-2854:
-
Removed redundant messages for synchronization awaiting for finishing of
deadlock detection. {{GridDhtLockFuture}} just doesn't release locks on
{{onTimeout}} invocation. Locks will be release during transaction rolling back.
Detection process is asynchronous now and doesn't block any thread.
It makes sense to implement detection for near cache and optimistic
transactions separately. Created IGNITE-2968 and IGNITE-2969.
> Need to implement deadlock detection
>
>
> Key: IGNITE-2854
> URL: https://issues.apache.org/jira/browse/IGNITE-2854
> Project: Ignite
> Issue Type: New Feature
> Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Andrey Gura
> Fix For: 1.6
>
>
> Currently, if transactional deadlock occurred, there is no easy way to find
> out which locks were reordered.
> We need to add a mechanism that will collect information about awating
> candidates, analyze it and show guilty keys. Most likely this should be
> implemented with the help of custom discovery message.
> In addition we should automatically execute this mechanism if transaction
> times out and add information to timeout exception.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-2969) Optimistic transactions support in deadlock detection
Andrey Gura created IGNITE-2969: --- Summary: 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.6 Deadlock detection doesn't support optimistic transactions now. It should be implemented. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2968) Near cache support in transactions deadlock detection
Andrey Gura created IGNITE-2968: --- Summary: Near cache support in transactions deadlock detection Key: IGNITE-2968 URL: https://issues.apache.org/jira/browse/IGNITE-2968 Project: Ignite Issue Type: Improvement Components: cache Reporter: Andrey Gura Assignee: Andrey Gura Fix For: 1.6 Deadlock detection doesn't support transactions on near cache. Need implement it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-813) Apache Flink Integration -- data streaming connector
[ https://issues.apache.org/jira/browse/IGNITE-813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Saikat Maitra updated IGNITE-813: - Attachment: IgniteSink.txt > Apache Flink Integration -- data streaming connector > > > Key: IGNITE-813 > URL: https://issues.apache.org/jira/browse/IGNITE-813 > Project: Ignite > Issue Type: New Feature > Components: streaming >Reporter: Suminda Dharmasena >Assignee: Saikat Maitra > Fix For: 1.6 > > Attachments: IgniteSink.txt > > > Sink connector -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-813) Apache Flink Integration -- data streaming connector
[ https://issues.apache.org/jira/browse/IGNITE-813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15232731#comment-15232731 ] Saikat Maitra commented on IGNITE-813: -- [~raulvk] Hi Raul, I am preparing the doc. I will attach to this ticket. Thank you Saikat > Apache Flink Integration -- data streaming connector > > > Key: IGNITE-813 > URL: https://issues.apache.org/jira/browse/IGNITE-813 > Project: Ignite > Issue Type: New Feature > Components: streaming >Reporter: Suminda Dharmasena >Assignee: Saikat Maitra > Fix For: 1.6 > > > Sink connector -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2899) BinaryObject is deserialized before getting passed to CacheInterceptor
[
https://issues.apache.org/jira/browse/IGNITE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15232727#comment-15232727
]
Artem Shutak commented on IGNITE-2899:
--
Fixed new tx tests. Currently have 2 different failures.
# {{InvokeAll}} sometimes return keys as user objects instead of BinaryObjects
# {{Invoke}} fails on internal assert
> BinaryObject is deserialized before getting passed to CacheInterceptor
> --
>
> Key: IGNITE-2899
> URL: https://issues.apache.org/jira/browse/IGNITE-2899
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Artem Shutak
> Fix For: 1.6
>
> Attachments: BinaryInterceptorIssue.java,
> BinaryInterceptorNoTypeIssue.java
>
>
> If {{CacheInterceptor}} is configured for a cache that stores
> {{BinaryObjects}} then the objects are always deserialized before being
> passed to the interceptor body.
> Refer to BinaryInterceptorIssue test attached to the ticket to reproduce the
> following stack trace
> {noformat}
> java.lang.ClassCastException:
> org.apache.ignite.examples.tests.BinaryInterceptorIssue$ValidObject cannot be
> cast to org.apache.ignite.binary.BinaryObject
> at
> org.apache.ignite.examples.tests.BinaryInterceptorIssue$ValidationInterceptor.onBeforePut(BinaryInterceptorIssue.java:49)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2309)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2044)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1439)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1314)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.mapSingle(GridNearAtomicUpdateFuture.java:457)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.access$1400(GridNearAtomicUpdateFuture.java:72)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture$UpdateState.map(GridNearAtomicUpdateFuture.java:931)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.mapOnTopology(GridNearAtomicUpdateFuture.java:417)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.map(GridNearAtomicUpdateFuture.java:283)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$21.apply(GridDhtAtomicCache.java:1006)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$21.apply(GridDhtAtomicCache.java:1004)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.asyncOp(GridDhtAtomicCache.java:737)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsync0(GridDhtAtomicCache.java:1004)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.putAsync0(GridDhtAtomicCache.java:465)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.putAsync(GridCacheAdapter.java:2491)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put(GridDhtAtomicCache.java:440)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2170)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.put(IgniteCacheProxy.java:1127)
> at
> org.apache.ignite.examples.tests.BinaryInterceptorIssue.main(BinaryInterceptorIssue.java:37)
> 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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
> Exception in thread "main"
> org.apache.ignite.cache.CachePartialUpdateException: Failed to update keys
> (retry update if possible).: [1]
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1577)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.cacheException(IgniteCacheProxy.java:1931)
> at
>
[jira] [Commented] (IGNITE-2725) Assertion in org.apache.ignite.internal.processors.hadoop.jobtracker.HadoopJobTracker.CancelJobProcessor#update fails if a job failed with an exception
[
https://issues.apache.org/jira/browse/IGNITE-2725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15232619#comment-15232619
]
Ivan Veselovsky commented on IGNITE-2725:
-
In
org.apache.ignite.internal.processors.hadoop.jobtracker.HadoopJobTracker#onTaskFinished,
line 541 we have
{code}
cache.invokeAsync(info.jobId(), new
UpdatePhaseProcessor(incrCntrs, PHASE_COMPLETE)).
listen(failsLog);
{code}
, so it looks like the HadoopJobMetadata#phase may asynchronously become
"PHASE_COMPLETE", so there is no surprise the problematic assertion fails.
> Assertion in
> org.apache.ignite.internal.processors.hadoop.jobtracker.HadoopJobTracker.CancelJobProcessor#update
> fails if a job failed with an exception
> ---
>
> Key: IGNITE-2725
> URL: https://issues.apache.org/jira/browse/IGNITE-2725
> Project: Ignite
> Issue Type: Bug
> Components: hadoop
>Affects Versions: 1.6
>Reporter: Ivan Veselovsky
>Assignee: Ivan Veselovsky
>
> Assertion in
> org.apache.ignite.internal.processors.hadoop.jobtracker.HadoopJobTracker.CancelJobProcessor#update
> : 1584 failed if a Hadoop job failed with an exception. The problem is that
> assertion expects the phase to be PHASE_CANCELLING , while actual phase is
> PHASE_COMPLETE.
> {code}
> assert meta.phase() == PHASE_CANCELLING || err != null: "Invalid phase for
> cancel: " + meta;
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2645) Assertion error in ATOMIC cachce for invokeAll and cache store
[ https://issues.apache.org/jira/browse/IGNITE-2645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15232473#comment-15232473 ] Artem Shutak commented on IGNITE-2645: -- I discussed the Alexey's comment with him today and now I see the problem. 'putIfAbsent' will has the same issue. The following steps can be used to verify that the issue exists: 1. Put key-value pair at cache. 2. Clear the value for the key from primary node (backup node should still has the value). 3. Execute invoke operation, which doesn't change a value, just return something. 4. Check that entry version equals no primary and backup. Expected that now it fails here. At point 3, Ignite will read value from store (on innerGet), new entry version will be genarated, but as long as entry processor does not change the value, value will not be updated on backup node. I think, we should fix the issue in bounds of new jira. Thoughts? > Assertion error in ATOMIC cachce for invokeAll and cache store > -- > > Key: IGNITE-2645 > URL: https://issues.apache.org/jira/browse/IGNITE-2645 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: ignite-1.4 >Reporter: Alexey Goncharuk >Assignee: Artem Shutak > Labels: community > Fix For: 1.6 > > Attachments: EntryProcessorFails.java > > > Assertion happens under the following conditions: > * Cache is empty > * Cache store contains non-null values for some keys > * invokeAll is invoked for those keys > Update version is generated when update request reaches the primary node. > Then, we need to read-through stored values (the cache is empty) and pass > them to transformers. Since read-through changes entry version, subsequent > update fails with an assertion because read-through version is generated > later than update version. > The scenario when a read-through is implemented via a separate loop with > innerGet() is possible only with invokeAll() because this is the only > multi-key cache operation that requires the previous entry value. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2952) Add yardstick benchmark for cache load testing
[ https://issues.apache.org/jira/browse/IGNITE-2952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15232428#comment-15232428 ] Vladislav Pyatkov commented on IGNITE-2952: --- Developed load test with all designated operations. But some cases not all cache parameters considering. I continue to work, until test will not all finished and will show correct resutls. > Add yardstick benchmark for cache load testing > -- > > Key: IGNITE-2952 > URL: https://issues.apache.org/jira/browse/IGNITE-2952 > Project: Ignite > Issue Type: Test >Reporter: Semen Boikov >Assignee: Vladislav Pyatkov > > Need implement yardstick benchmark which will be used for cache load testing > (add it in 'yardstick' module). > For this load testing nodes will be started with several pre-configured > caches. Benchmark on each call of 'test' method should iterate over all > configured caches (can get list of caches using Ignite.cacheNames) and > execute some random operations: > - put(All) > - get(All) > - invoke(All) > - remove(All) > - putIfAbsent > - replace > - scan query > If cache is transactional it also should execute cache operations inside > explicitly start transaction with random concurrency/isolation mode. > This benchmark can be run in scenario when server nodes are restarted, so for > explicit transaction need use method IgniteBenchmarkUtils.doInTransaction > which has logic for exception handling. > It should be possible to pre-load some cache data before starting test , > there should be special benchmark parameter which specifies how many entries > load in caches on start (see IgniteSqlQueryBenchmark.setUp as example of > benchmark doing preloading) > Also it should use non-primitives objects as cache keys/values. Value class > should have String, int, long, double, byte[] fields. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2965) Failed to read class name from file on deserialization
[ https://issues.apache.org/jira/browse/IGNITE-2965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15232367#comment-15232367 ] Anton Vinogradov commented on IGNITE-2965: -- Implemented, waoting for TeamCity check. > Failed to read class name from file on deserialization > -- > > Key: IGNITE-2965 > URL: https://issues.apache.org/jira/browse/IGNITE-2965 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Semen Boikov >Assignee: Anton Vinogradov >Priority: Critical > Fix For: 1.6 > > > I added test MarshallerCacheJobRunNodeRestartTest from time to reproducing > error 'Failed to read class name from file' during during deserialization. > This is some issue with marshaller cache: it is updated usign putIfAbsent > method, now its implementation has a race and sometimes it can exit before > value is updated on backup node. As a workaround for marshaller cache I > usggest using 'getAndPut' instead of 'putIfAbsent (just need implement > 'tryGetAndPut' method which will not wait for topology changes). > Also let's make error message in MarshallerContextImpl.className more > informative. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2354) Ensure that Hadoop client is still operational after failed map-reduce jobs.
[ https://issues.apache.org/jira/browse/IGNITE-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15232338#comment-15232338 ] Ivan Veselovsky commented on IGNITE-2354: - Pull request: https://github.com/apache/ignite/pull/622 . New test: org.apache.ignite.internal.processors.hadoop.HadoopMapReduceErrorResilienceTest . > Ensure that Hadoop client is still operational after failed map-reduce jobs. > > > Key: IGNITE-2354 > URL: https://issues.apache.org/jira/browse/IGNITE-2354 > Project: Ignite > Issue Type: Bug > Components: hadoop >Affects Versions: ignite-1.4 >Reporter: Vladimir Ozerov >Assignee: Ivan Veselovsky >Priority: Critical > Labels: important > Fix For: 1.6 > > > We need to ensure that MR failures on the server doesn't block further job > submissions. > First of all we should cover such situations with tests. > 1) Test exceptions on all job stages (setup, map, reduce, combine, cleanup) > 2) Test several exception types: > - Exceptions expected from Hadoop interface > - Exceptions unexpected form Hadoop interface > - Errors. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-2967) .NET: Provide meaningful error message when platform fails on Java-only node
[ https://issues.apache.org/jira/browse/IGNITE-2967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15232275#comment-15232275 ] Pavel Tupitsyn edited comment on IGNITE-2967 at 4/8/16 3:28 PM: What happens with C++ nodes? They have PlatformProcessor, but it can't execute .NET code. We can have separate PlatformProcessor in each platform, and add platform info to all predicates, processors, etc, and throw an error on platform mismatch. was (Author: ptupitsyn): What happens with C++ nodes? They have PlatformProcessor, but it can't execute .NET code. > .NET: Provide meaningful error message when platform fails on Java-only node > > > Key: IGNITE-2967 > URL: https://issues.apache.org/jira/browse/IGNITE-2967 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.6 > > > When there are Java-only nodes in the cluster, operations such as cache > invoke and continuous queries with remote filter will fail with NPE or other > exceptions, because PlatformContext is null. > Need to provide a special exception with descriptive error message. > See PlatformNoopProcessor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2963) .NET: Document mixed-cluster behavior
[ https://issues.apache.org/jira/browse/IGNITE-2963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15232278#comment-15232278 ] Pavel Tupitsyn commented on IGNITE-2963: * Page updated: https://apacheignite-net.readme.io/docs/platform-interoperability * Mixed cluster tested with CacheEntryProcessor. IGNITE-2967 created as a result. > .NET: Document mixed-cluster behavior > - > > Key: IGNITE-2963 > URL: https://issues.apache.org/jira/browse/IGNITE-2963 > Project: Ignite > Issue Type: Task > Components: documentation, platforms >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.6 > > > * Create a page on https://apacheignite-net.readme.io/ that describes > Ignite.NET behavior when used in mixed clusters (with Java-only and CPP > nodes). > * Test what happens when .NET predicates are deployed to Java-only nodes -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2967) .NET: Provide meaningful error message when platform fails on Java-only node
[ https://issues.apache.org/jira/browse/IGNITE-2967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15232275#comment-15232275 ] Pavel Tupitsyn commented on IGNITE-2967: What happens with C++ nodes? They have PlatformProcessor, but it can't execute .NET code. > .NET: Provide meaningful error message when platform fails on Java-only node > > > Key: IGNITE-2967 > URL: https://issues.apache.org/jira/browse/IGNITE-2967 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.6 > > > When there are Java-only nodes in the cluster, operations such as cache > invoke and continuous queries with remote filter will fail with NPE or other > exceptions, because PlatformContext is null. > Need to provide a special exception with descriptive error message. > See PlatformNoopProcessor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2967) .NET: Provide meaningful error message when platform fails on Java-only node
[ https://issues.apache.org/jira/browse/IGNITE-2967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-2967: --- Description: When there are Java-only nodes in the cluster, operations such as cache invoke and continuous queries with remote filter will fail with NPE or other exceptions, because PlatformContext is null. Need to provide a special exception with descriptive error message. See PlatformNoopProcessor. was: When there are Java-only nodes in the cluster, operations such as cache invoke and continuous queries with remote filter will fail with NPE or other exceptions, because PlatformContext is null. Need to provide a special exception with descriptive error message. > .NET: Provide meaningful error message when platform fails on Java-only node > > > Key: IGNITE-2967 > URL: https://issues.apache.org/jira/browse/IGNITE-2967 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.6 > > > When there are Java-only nodes in the cluster, operations such as cache > invoke and continuous queries with remote filter will fail with NPE or other > exceptions, because PlatformContext is null. > Need to provide a special exception with descriptive error message. > See PlatformNoopProcessor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-2965) Failed to read class name from file on deserialization
[ https://issues.apache.org/jira/browse/IGNITE-2965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov reassigned IGNITE-2965: Assignee: Anton Vinogradov > Failed to read class name from file on deserialization > -- > > Key: IGNITE-2965 > URL: https://issues.apache.org/jira/browse/IGNITE-2965 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Semen Boikov >Assignee: Anton Vinogradov >Priority: Critical > Fix For: 1.6 > > > I added test MarshallerCacheJobRunNodeRestartTest from time to reproducing > error 'Failed to read class name from file' during during deserialization. > This is some issue with marshaller cache: it is updated usign putIfAbsent > method, now its implementation has a race and sometimes it can exit before > value is updated on backup node. As a workaround for marshaller cache I > usggest using 'getAndPut' instead of 'putIfAbsent (just need implement > 'tryGetAndPut' method which will not wait for topology changes). > Also let's make error message in MarshallerContextImpl.className more > informative. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-2966) Hadoop tests: in case of Hadop download failure do not delete all the install directory
[ https://issues.apache.org/jira/browse/IGNITE-2966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15232199#comment-15232199 ] Ivan Veselovsky edited comment on IGNITE-2966 at 4/8/16 2:07 PM: - https://github.com/apache/ignite/pull/626 fix tested on public TC. was (Author: iveselovskiy): https://github.com/apache/ignite/pull/626 fix tested on public TC during IGNITE-2354 testing. > Hadoop tests: in case of Hadop download failure do not delete all the install > directory > --- > > Key: IGNITE-2966 > URL: https://issues.apache.org/jira/browse/IGNITE-2966 > Project: Ignite > Issue Type: Bug > Components: hadoop >Affects Versions: 1.6 >Reporter: Ivan Veselovsky >Assignee: Vladimir Ozerov > Fix For: 1.6 > > > Hadoop distribution is downloaded automatically for Hadoop tests. Several > download URLs are tried. In case of failure download is cleaned up and next > URL is tried. > But due to bug in org.apache.ignite.testsuites.IgniteHadoopTestSuite , line > 333 all the install directory is deleted, while only the component whose > download is failed should be deleted. > Due to this problem tests fail on 'master' branch on public TC, e.g.: > http://204.14.53.153/viewLog.html?buildTypeId=IgniteTests_IgniteHadoop=224064 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1481) It is possible to configure local cache with affinity function
[
https://issues.apache.org/jira/browse/IGNITE-1481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15232214#comment-15232214
]
kcheng.mvp commented on IGNITE-1481:
PR : https://github.com/apache/ignite/pull/617
> It is possible to configure local cache with affinity function
> --
>
> Key: IGNITE-1481
> URL: https://issues.apache.org/jira/browse/IGNITE-1481
> Project: Ignite
> Issue Type: Bug
> Components: newbie
>Reporter: Andrey Gura
>Assignee: kcheng.mvp
> Labels: newbie
>
> {{LOCAL}} cache always uses {{GridCacheProcessor.LocalAffinityFunction}}.
> Durign configuration of local cache it is possible to pass other affinity
> function to cache configuration. All cache operations will work correctly,
> but user can obtain affinity manager that internally uses incorrect affinity
> function ({{GridCacheContext.cctx.affinity().aff.aff}}).
> Expected behaviour: {{GridCacheContext.cctx.affinity().aff.aff}} always
> refers to {{GridCacheProcessor.LocalAffinityFunction}} for {{LOCAL}} caches.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2966) Hadoop tests: in case of Hadop download failure do not delete all the install directory
[ https://issues.apache.org/jira/browse/IGNITE-2966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Veselovsky updated IGNITE-2966: Description: Hadoop distribution is downloaded automatically for Hadoop tests. Several download URLs are tried. In case of failure download is cleaned up and next URL is tried. But due to bug in org.apache.ignite.testsuites.IgniteHadoopTestSuite , line 333 all the install directory is deleted, while only the component whose download is failed should be deleted. Due to this problem tests fail on 'master' branch on public TC, e.g.: http://204.14.53.153/viewLog.html?buildTypeId=IgniteTests_IgniteHadoop=224064 was: Hadoop distribution is downloaded automatically for Hadoop tests. Several download URLs are tried. In case of failure download is cleaned up and next URL is tried. But due to bug in org.apache.ignite.testsuites.IgniteHadoopTestSuite , line 333 all the install directory is deleted, while only the component whose download is failed should be deleted. > Hadoop tests: in case of Hadop download failure do not delete all the install > directory > --- > > Key: IGNITE-2966 > URL: https://issues.apache.org/jira/browse/IGNITE-2966 > Project: Ignite > Issue Type: Bug > Components: hadoop >Affects Versions: 1.6 >Reporter: Ivan Veselovsky >Assignee: Vladimir Ozerov > Fix For: 1.6 > > > Hadoop distribution is downloaded automatically for Hadoop tests. Several > download URLs are tried. In case of failure download is cleaned up and next > URL is tried. > But due to bug in org.apache.ignite.testsuites.IgniteHadoopTestSuite , line > 333 all the install directory is deleted, while only the component whose > download is failed should be deleted. > Due to this problem tests fail on 'master' branch on public TC, e.g.: > http://204.14.53.153/viewLog.html?buildTypeId=IgniteTests_IgniteHadoop=224064 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2967) .NET: Provide meaningful error message when platform fails on Java-only node
Pavel Tupitsyn created IGNITE-2967: -- Summary: .NET: Provide meaningful error message when platform fails on Java-only node Key: IGNITE-2967 URL: https://issues.apache.org/jira/browse/IGNITE-2967 Project: Ignite Issue Type: Improvement Components: platforms Affects Versions: 1.1.4 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 1.6 When there are Java-only nodes in the cluster, operations such as cache invoke and continuous queries with remote filter will fail with NPE or other exceptions, because PlatformContext is null. Need to provide a special exception with descriptive error message. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2966) Hadoop tests: in case of Hadop download failure do not delete all the install directory
Ivan Veselovsky created IGNITE-2966: --- Summary: Hadoop tests: in case of Hadop download failure do not delete all the install directory Key: IGNITE-2966 URL: https://issues.apache.org/jira/browse/IGNITE-2966 Project: Ignite Issue Type: Bug Components: hadoop Affects Versions: 1.6 Reporter: Ivan Veselovsky Assignee: Ivan Veselovsky Fix For: 1.6 Hadoop distribution is downloaded automatically for Hadoop tests. Several download URLs are tried. In case of failure download is cleaned up and next URL is tried. But due to bug in org.apache.ignite.testsuites.IgniteHadoopTestSuite , line 333 all the install directory is deleted, while only the component whose download is failed should be deleted. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-2941) Add getOrStart method to ignition
[ https://issues.apache.org/jira/browse/IGNITE-2941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexei Scherbakov reassigned IGNITE-2941: - Assignee: Alexei Scherbakov (was: Valentin Kulichenko) > Add getOrStart method to ignition > - > > Key: IGNITE-2941 > URL: https://issues.apache.org/jira/browse/IGNITE-2941 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 1.5.0.final >Reporter: Alexey Goncharuk >Assignee: Alexei Scherbakov > > Currently there is no way to atomically check if an Ignite instance with the > given name is started and start it, if it was not started. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2947) BinaryContext doesn't honor custom loader set through IgniteConfiguration.classLoader
[
https://issues.apache.org/jira/browse/IGNITE-2947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15232165#comment-15232165
]
Anton Vinogradov commented on IGNITE-2947:
--
Correct, I see failures even if user classloader specified at
org/apache/ignite/internal/binary/GridBinaryMarshallerCtxDisabledSelfTest.java:70
> BinaryContext doesn't honor custom loader set through
> IgniteConfiguration.classLoader
> -
>
> Key: IGNITE-2947
> URL: https://issues.apache.org/jira/browse/IGNITE-2947
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Anton Vinogradov
>Priority: Critical
> Labels: community, important
> Fix For: 1.6
>
>
> If to register a specific object with {{BinaryTypeConfiguration}} setting its
> {{typeName}} and load Class of objects of this type using a custom class
> loader passed to {{IgniteConfiguration.classLoader}} then at
> {{BinaryContext}} initialization time the context will not properly register
> this {{BinaryTypeConfiguration}} because it doesn't suppose that the Class of
> the type can be loaded by the custom class loader
> In the code below {{Class.forName}} has to use
> {{IgniteConfiguration.classLoader}} if the latest is set and fall back to
> {{dfltLdr}} otherwise.
> {noformat}
> @SuppressWarnings("ErrorNotRethrown")
> public void registerUserType(String clsName,
> BinaryInternalMapper mapper,
> @Nullable BinarySerializer serializer,
> @Nullable String affKeyFieldName,
> boolean isEnum)
> throws BinaryObjectException {
> assert mapper != null;
> Class cls = null;
> try {
> cls = Class.forName(clsName);
> }
> catch (ClassNotFoundException | NoClassDefFoundError ignored) {
> // No-op.
> }
> {noformat}
> Also there are several conditions in {{BinaryContext}} that are done for
> {{dfltLdr}}. The same conditions have to be executed for
> {{IgniteConfiguration.classLoader}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1481) It is possible to configure local cache with affinity function
[
https://issues.apache.org/jira/browse/IGNITE-1481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15232156#comment-15232156
]
Denis Magda commented on IGNITE-1481:
-
Thanks,
I'll review the next week. Please provide a valid link to the pull-request. I
saw you closed/opened many of them.
> It is possible to configure local cache with affinity function
> --
>
> Key: IGNITE-1481
> URL: https://issues.apache.org/jira/browse/IGNITE-1481
> Project: Ignite
> Issue Type: Bug
> Components: newbie
>Reporter: Andrey Gura
>Assignee: kcheng.mvp
> Labels: newbie
>
> {{LOCAL}} cache always uses {{GridCacheProcessor.LocalAffinityFunction}}.
> Durign configuration of local cache it is possible to pass other affinity
> function to cache configuration. All cache operations will work correctly,
> but user can obtain affinity manager that internally uses incorrect affinity
> function ({{GridCacheContext.cctx.affinity().aff.aff}}).
> Expected behaviour: {{GridCacheContext.cctx.affinity().aff.aff}} always
> refers to {{GridCacheProcessor.LocalAffinityFunction}} for {{LOCAL}} caches.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2947) BinaryContext doesn't honor custom loader set through IgniteConfiguration.classLoader
[
https://issues.apache.org/jira/browse/IGNITE-2947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15232140#comment-15232140
]
Denis Magda commented on IGNITE-2947:
-
Please try to load {{SimpleObject}} used in the test with the custom loader and
work with its instance.
> BinaryContext doesn't honor custom loader set through
> IgniteConfiguration.classLoader
> -
>
> Key: IGNITE-2947
> URL: https://issues.apache.org/jira/browse/IGNITE-2947
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Anton Vinogradov
>Priority: Critical
> Labels: community, important
> Fix For: 1.6
>
>
> If to register a specific object with {{BinaryTypeConfiguration}} setting its
> {{typeName}} and load Class of objects of this type using a custom class
> loader passed to {{IgniteConfiguration.classLoader}} then at
> {{BinaryContext}} initialization time the context will not properly register
> this {{BinaryTypeConfiguration}} because it doesn't suppose that the Class of
> the type can be loaded by the custom class loader
> In the code below {{Class.forName}} has to use
> {{IgniteConfiguration.classLoader}} if the latest is set and fall back to
> {{dfltLdr}} otherwise.
> {noformat}
> @SuppressWarnings("ErrorNotRethrown")
> public void registerUserType(String clsName,
> BinaryInternalMapper mapper,
> @Nullable BinarySerializer serializer,
> @Nullable String affKeyFieldName,
> boolean isEnum)
> throws BinaryObjectException {
> assert mapper != null;
> Class cls = null;
> try {
> cls = Class.forName(clsName);
> }
> catch (ClassNotFoundException | NoClassDefFoundError ignored) {
> // No-op.
> }
> {noformat}
> Also there are several conditions in {{BinaryContext}} that are done for
> {{dfltLdr}}. The same conditions have to be executed for
> {{IgniteConfiguration.classLoader}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-642) Implement IgniteReentrantLock data structure
[
https://issues.apache.org/jira/browse/IGNITE-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15231951#comment-15231951
]
Vladisav Jelisavcic commented on IGNITE-642:
Yakov,
everything should be fine now.
Please do the review again and let me know if I missed anything.
Thanks!
> Implement IgniteReentrantLock data structure
>
>
> Key: IGNITE-642
> URL: https://issues.apache.org/jira/browse/IGNITE-642
> Project: Ignite
> Issue Type: Sub-task
> Components: data structures
>Affects Versions: 1.6
>Reporter: Dmitriy Setrakyan
>Assignee: Vladisav Jelisavcic
> Labels: features
> Fix For: 1.6
>
>
> We need to add {{IgniteReentrantLock}} data structure in addition to other
> data structures provided by Ignite. {{IgniteReentrantLock}} should have
> similar API to {{java.util.concurrent.locks.ReentrantLock}} class in JDK.
> As an example, you can see how
> [IgniteCountDownLatch|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/IgniteCountDownLatch.java]
> is implemented in
> [GridCacheCountDownLatchImpl|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastructures/GridCacheCountDownLatchImpl.java]
> class.
> In general we need to have an entity in ATOMIC cache storing lock-owner
> identifier together with a queue of waiters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (IGNITE-2950) Incorrect params list in secret.properties for PostgreSQL
[
https://issues.apache.org/jira/browse/IGNITE-2950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vasiliy Sisko resolved IGNITE-2950.
---
Resolution: Fixed
Assignee: Pavel Konstantinov (was: Vasiliy Sisko)
> Incorrect params list in secret.properties for PostgreSQL
> -
>
> Key: IGNITE-2950
> URL: https://issues.apache.org/jira/browse/IGNITE-2950
> Project: Ignite
> Issue Type: Sub-task
> Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
> Fix For: 1.6
>
>
> Currently we generate the following parameters (incorrect):
> {code}
> dsPostgreSQL.jdbc.server_name=YOUR_DATABASE_SERVER_NAME
> dsPostgreSQL.jdbc.database_name=YOUR_DATABASE_NAME
> dsPostgreSQL.jdbc.username=YOUR_USER_NAME
> dsPostgreSQL.jdbc.password=YOUR_PASSWORD
> {code}
> But in XML configuration we use (correct)
> {code}
>
>
>
> {code}
> Please fix params in secret.properties.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2919) Visor CMD: Add ability to attach custom scripts to alerts
[
https://issues.apache.org/jira/browse/IGNITE-2919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15231842#comment-15231842
]
Vasiliy Sisko commented on IGNITE-2919:
---
Implemented execution of script on alert.
To configure use arguments:
*-n* Alert name (opt.).
*-s* Path to script file.
*-i* Minimal interval of script execution that should be passed
Script is executed on unsuccessful check of alert condition after successful.
When alert check is unsuccessful longer than interval time script is not
executed second time.
To script passed the next arguments: 1) Alert name, 2) alert condition, 3, ...)
checked values of alert conditions.
For example for script: {code}alert -t=5 -r -n=Test -nc=gte2 -cc=lte16 -i=15
-s=/home/user/1.sh{code}
with script:
{code:title=1.sh}echo ALERT [$1] CONDITION [$2] alarmed with node count [$3]
and cpu count [$4] > test.txt{code}
will generated string: {code}ALERT [Test] CONDITION [-nc=gte2 -cc=lte16]
alarmed with node count [2] and cpu count [8]{code}
> Visor CMD: Add ability to attach custom scripts to alerts
> -
>
> Key: IGNITE-2919
> URL: https://issues.apache.org/jira/browse/IGNITE-2919
> Project: Ignite
> Issue Type: Bug
> Components: visor
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Vasiliy Sisko
> Labels: community, important
> Fix For: 1.6
>
>
> Visor cmd support "alert" command that allows to listen on particular
> triggers (heap usage, nodes count, ...).
> If a trigger is fired Visor will print info into the log file.
> However it makes sense specify a custom script that will be triggered when a
> trigger is fired.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-472) Do not show system caches in visor console by default
[ https://issues.apache.org/jira/browse/IGNITE-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] kcheng.mvp updated IGNITE-472: -- Attachment: screenshot.png Describe how to turn on/off show/hide system cache. > Do not show system caches in visor console by default > - > > Key: IGNITE-472 > URL: https://issues.apache.org/jira/browse/IGNITE-472 > Project: Ignite > Issue Type: Task > Components: UI >Affects Versions: sprint-2 >Reporter: Pavel Konstantinov >Assignee: kcheng.mvp >Priority: Minor > Attachments: screenshot.png > > > I think we need to add a special option like '-sys' to show system caches -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-472) Do not show system caches in visor console by default
[ https://issues.apache.org/jira/browse/IGNITE-472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15231772#comment-15231772 ] kcheng.mvp commented on IGNITE-472: --- In fact there is a such option called "-system" to turn on/off show system cache, but the "help cache" command does not address this. Right now the "cache" command would not show system cache by default. > Do not show system caches in visor console by default > - > > Key: IGNITE-472 > URL: https://issues.apache.org/jira/browse/IGNITE-472 > Project: Ignite > Issue Type: Task > Components: UI >Affects Versions: sprint-2 >Reporter: Pavel Konstantinov >Assignee: kcheng.mvp >Priority: Minor > > I think we need to add a special option like '-sys' to show system caches -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-472) Do not show system caches in visor console by default
[ https://issues.apache.org/jira/browse/IGNITE-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] kcheng.mvp reassigned IGNITE-472: - Assignee: kcheng.mvp > Do not show system caches in visor console by default > - > > Key: IGNITE-472 > URL: https://issues.apache.org/jira/browse/IGNITE-472 > Project: Ignite > Issue Type: Task > Components: UI >Affects Versions: sprint-2 >Reporter: Pavel Konstantinov >Assignee: kcheng.mvp >Priority: Minor > > I think we need to add a special option like '-sys' to show system caches -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1481) It is possible to configure local cache with affinity function
[
https://issues.apache.org/jira/browse/IGNITE-1481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15231755#comment-15231755
]
kcheng.mvp commented on IGNITE-1481:
All the cases has passed in the teamcity
http://204.14.53.153/viewLog.html?buildId=223902=buildResultsDiv=IgniteTests_IgniteDataGrid
Please help to review, thanks
> It is possible to configure local cache with affinity function
> --
>
> Key: IGNITE-1481
> URL: https://issues.apache.org/jira/browse/IGNITE-1481
> Project: Ignite
> Issue Type: Bug
> Components: newbie
>Reporter: Andrey Gura
>Assignee: kcheng.mvp
> Labels: newbie
>
> {{LOCAL}} cache always uses {{GridCacheProcessor.LocalAffinityFunction}}.
> Durign configuration of local cache it is possible to pass other affinity
> function to cache configuration. All cache operations will work correctly,
> but user can obtain affinity manager that internally uses incorrect affinity
> function ({{GridCacheContext.cctx.affinity().aff.aff}}).
> Expected behaviour: {{GridCacheContext.cctx.affinity().aff.aff}} always
> refers to {{GridCacheProcessor.LocalAffinityFunction}} for {{LOCAL}} caches.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (IGNITE-1837) Rebalancing on a big cluster (30 nodes and more)
[ https://issues.apache.org/jira/browse/IGNITE-1837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semen Boikov reassigned IGNITE-1837: Assignee: Semen Boikov (was: Alexey Goncharuk) > Rebalancing on a big cluster (30 nodes and more) > > > Key: IGNITE-1837 > URL: https://issues.apache.org/jira/browse/IGNITE-1837 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: ignite-1.4 >Reporter: Denis Magda >Assignee: Semen Boikov > Fix For: 1.6 > > > It seems that Ignite has different rebalancing related issues that appear > when a big cluster is started. > Under the big cluster I mean: > - cluster of 64 server nodes; > - cluster of 64 server and 64 client nodes. > The issues can be divided on three main use cases. > 1) Slow rebalancing on start. > - If to set partitions number for some cache to value bigger than default one > (to 3200 or to 6400, etc.) then rebalancing of such caches may take several > minutes. The caches are empty at that time. In addition, as a part of this > issue let's document that the number of partitions can't exceed some value. > - exchange message on NODE_JOINED event that times out for a long time. > Discussed there: > http://apache-ignite-users.70518.x6.nabble.com/Help-with-tuning-for-larger-clusters-td1692.html#a1813 > 2) Slow rebalancing on client nodes shutdown. > If to stop a significant number of client nodes at the same time then again > by some reason the rebalancing will take serveral minutes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-1069) Need to add information about node's type:server or client (visorcmd)
[
https://issues.apache.org/jira/browse/IGNITE-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
kcheng.mvp reassigned IGNITE-1069:
--
Assignee: kcheng.mvp
> Need to add information about node's type:server or client (visorcmd)
> -
>
> Key: IGNITE-1069
> URL: https://issues.apache.org/jira/browse/IGNITE-1069
> Project: Ignite
> Issue Type: Bug
> Components: build
>Affects Versions: sprint-7
> Environment: OS X 10.10.3
> jdk1.7.0_79
>Reporter: Ilya Suntsov
>Assignee: kcheng.mvp
> Fix For: 1.6
>
>
> Steps for reproduction:
> 1. Start one server node and two clients
> 1. Start ignitevisorcmd.sh
> 2. Connect to grid (open)
> 3. Print topology (top)
> Results:
> {noformat}
> top
> Hosts: 1
> ++
> | Int./Ext. IPs | Node ID8(@)| OS
> | CPUs | MACs| CPU Load |
> ++
> | 2001:db8:85a3:0:0:8a2e:370:7334 | 1: 9D4F0AC0(@n0) | Mac OS X x86_64
> 10.10.3 | 8| 10:40:F3:A7:6A:B6 | 0.16 % |
> | 192.168.3.7 | 2: 6D746DAC(@n1) |
> | | | |
> | 0:0:0:0:0:0:0:1 | 3: A496C669(@n2) |
> | | | |
> | 127.0.0.1 | |
> | | | |
> ++
> Summary:
> +-+
> | Total hosts| 1 |
> | Total nodes| 3 |
> | Total CPUs | 8 |
> | Avg. CPU load | 0.16 % |
> | Avg. free heap | 80.00 %|
> | Avg. Up time | 00:02:44 |
> | Snapshot time | 07/01/15, 17:59:14 |
> +-+
> {noformat}
> I think here we should print node's types in order to know how many in a
> topology of servers and how many clients
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1226) Need to add method that returns names of all available caches
[
https://issues.apache.org/jira/browse/IGNITE-1226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15231712#comment-15231712
]
ASF GitHub Bot commented on IGNITE-1226:
Github user kcheng-mvp closed the pull request at:
https://github.com/apache/ignite/pull/35
> Need to add method that returns names of all available caches
> -
>
> Key: IGNITE-1226
> URL: https://issues.apache.org/jira/browse/IGNITE-1226
> Project: Ignite
> Issue Type: Bug
> Components: cache, newbie
>Affects Versions: 1.1.4
>Reporter: Valentin Kulichenko
>Assignee: kcheng.mvp
>Priority: Critical
> Labels: newbie, usability, user-request
> Fix For: 1.5.0.final
>
>
> We need to add {{Ignite.cacheNames()}} method that will return collection of
> names of currently available caches.
> User forum discussion:
> http://apache-ignite-users.70518.x6.nabble.com/Getting-a-list-of-started-caches-td876.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1153) Improve stop node message
[ https://issues.apache.org/jira/browse/IGNITE-1153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15231711#comment-15231711 ] ASF GitHub Bot commented on IGNITE-1153: Github user kcheng-mvp closed the pull request at: https://github.com/apache/ignite/pull/44 > Improve stop node message > - > > Key: IGNITE-1153 > URL: https://issues.apache.org/jira/browse/IGNITE-1153 > Project: Ignite > Issue Type: Task > Components: general >Affects Versions: sprint-1 >Reporter: Alexey Kuznetsov >Assignee: kcheng.mvp >Priority: Trivial > Labels: newbie > Fix For: 1.5.0.final > > > When node stopped it prints to log: > [15:03:07] Ignite node stopped OK [uptime=00:00:52:597] > But in case when several nodes run in same JVM it will be useful to see node > name that was stopped. > So message could look like: > [15:03:07] Ignite node stopped OK [name=n1, uptime=00:00:52:597] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2941) Add getOrStart method to ignition
[
https://issues.apache.org/jira/browse/IGNITE-2941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15231687#comment-15231687
]
Denis Magda commented on IGNITE-2941:
-
Probably we should add boolean parameter like {{failIfStarted}} to
{{IgnitionEx.start0()}}. If the flag is true (default) then everything will
work as presently. Otherwise an existed (old) instance should be returned.
Tests has to be added as well to validate the functionality.
> Add getOrStart method to ignition
> -
>
> Key: IGNITE-2941
> URL: https://issues.apache.org/jira/browse/IGNITE-2941
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.5.0.final
>Reporter: Alexey Goncharuk
>Assignee: Valentin Kulichenko
>
> Currently there is no way to atomically check if an Ignite instance with the
> given name is started and start it, if it was not started.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
