[jira] [Commented] (IGNITE-9031) SpringCacheManager throws AssertionError during Spring initialization
[ https://issues.apache.org/jira/browse/IGNITE-9031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16575745#comment-16575745 ] ASF GitHub Bot commented on IGNITE-9031: GitHub user amirakhmedov opened a pull request: https://github.com/apache/ignite/pull/4511 IGNITE-9031: SpringCacheManager throws AssertionError during Spring i… …nitialization You can merge this pull request into a Git repository by running: $ git pull https://github.com/amirakhmedov/ignite IGNITE-9031 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4511.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 #4511 commit e8c4b0f96c1ee107fbc024caebdd7323ee17bba4 Author: Amir Akhmedov Date: 2018-08-10T04:25:28Z IGNITE-9031: SpringCacheManager throws AssertionError during Spring initialization > SpringCacheManager throws AssertionError during Spring initialization > - > > Key: IGNITE-9031 > URL: https://issues.apache.org/jira/browse/IGNITE-9031 > Project: Ignite > Issue Type: Bug > Components: spring >Affects Versions: 2.6 >Reporter: Joel Lang >Assignee: Amir Akhmedov >Priority: Major > > When initializing Ignite using an IgniteSpringBean and also having a > SpringCacheManager defined, the SpringCacheManager throws an AssertionError > in the onApplicationEvent() method due to it being called more than once. > There is an "assert ignite == null" that fails after the first call. > This is related to the changes in IGNITE-8740. This happened immediately when > I first tried to start Ignite after upgrading from 2.5 to 2.6. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7616) GridDataStreamExecutor and GridCallbackExecutor JMX beans return incorrect values due to invalid interface registration.
[ https://issues.apache.org/jira/browse/IGNITE-7616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16575640#comment-16575640 ] David Harvey commented on IGNITE-7616: -- The other issue is we need a IgniteStripedThreadPoolExecutorMXBeanAdapter. The general theme seems to be to have these adapters be standalone, and not require that the class they wrap be aware of them (i.e., reference them). What I'm currently doing in IgniteStripedThreadPoolExecutorMXBeanAdapter enumerating the stripes, creating an ThreadPoolMXBeanAdapter for each, and summing values. Either IgniteStripedThreadPoolExecutor can, given a stripe number, return an ExecutorService or it could return a ThreadPoolMXBeanAdapter. The former removes the obfuscation that Executors.newSingleThreadExecutor() tried to impose for users of IgniteStripedThreadPoolExecutor, but the latter makes IgniteStripedThreadPoolExecutor depend on ThreadPoolMXBeanAdapter. I've opted for the former. > GridDataStreamExecutor and GridCallbackExecutor JMX beans return incorrect > values due to invalid interface registration. > > > Key: IGNITE-7616 > URL: https://issues.apache.org/jira/browse/IGNITE-7616 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Max Shonichev >Assignee: David Harvey >Priority: Major > Labels: jmx > Fix For: 2.7 > > > Two of newly added management beans as a result of implementing feature > request https://issues.apache.org/jira/browse/IGNITE-7217 have bugs: > # GridDataStreamExecutor is registered as conforming to ThreadPoolMXBean > interface, though actually it is an incompatible StripedExecutor. > # GridCallbackExecutor is registered as conforming to ThreadPoolMXBean > interface, though actually it is an incompatible > IgniteStripedThreadPoolExecutor. > # ThreadPoolMXBeanAdapter checks whether adapted instance is > ThreadPoolExecutor, and as interfaces are incompatible, most of the JMX > attributes of GridCallbackExecutor and GridDataStreamExecutor are returned as > -1 or null. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7616) GridDataStreamExecutor and GridCallbackExecutor JMX beans return incorrect values due to invalid interface registration.
[ https://issues.apache.org/jira/browse/IGNITE-7616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16575631#comment-16575631 ] David Harvey edited comment on IGNITE-7616 at 8/10/18 1:09 AM: --- I have a solution coded and running against 2.5. The main issue is I needed to have IgniteStripedThreadPoolExecutor use Executors.newFixedThreadPool(1, factory) rather than newSingleThreadExecutor(factory) because the latter hides the underlying ThreadPoolExecutor. That hiding may have value in cases where the ThreadPoolExecutor is exposed, but IgniteStripedThreadPoolExecutor is providing another level of delegation anyway. was (Author: syssoftsol): I have a solution coded and running against 2.5. The main issue is I needed to have IgniteStripedThreadPoolExecutor use Executors.newFixedThreadPool(1, factory) rather than newSingleThreadExecutor(factory) because the latter hides the underlying ThreadPoolExecutor. That hiding may have value in cases where the ThreadPoolExecutor is exposed, but IgniteStripedThreadPoolExecutor is providing another level of delegation anyway. > GridDataStreamExecutor and GridCallbackExecutor JMX beans return incorrect > values due to invalid interface registration. > > > Key: IGNITE-7616 > URL: https://issues.apache.org/jira/browse/IGNITE-7616 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Max Shonichev >Assignee: David Harvey >Priority: Major > Labels: jmx > Fix For: 2.7 > > > Two of newly added management beans as a result of implementing feature > request https://issues.apache.org/jira/browse/IGNITE-7217 have bugs: > # GridDataStreamExecutor is registered as conforming to ThreadPoolMXBean > interface, though actually it is an incompatible StripedExecutor. > # GridCallbackExecutor is registered as conforming to ThreadPoolMXBean > interface, though actually it is an incompatible > IgniteStripedThreadPoolExecutor. > # ThreadPoolMXBeanAdapter checks whether adapted instance is > ThreadPoolExecutor, and as interfaces are incompatible, most of the JMX > attributes of GridCallbackExecutor and GridDataStreamExecutor are returned as > -1 or null. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7616) GridDataStreamExecutor and GridCallbackExecutor JMX beans return incorrect values due to invalid interface registration.
[ https://issues.apache.org/jira/browse/IGNITE-7616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16575631#comment-16575631 ] David Harvey commented on IGNITE-7616: -- I have a solution coded and running against 2.5. The main issue is I needed to have IgniteStripedThreadPoolExecutor use Executors.newFixedThreadPool(1, factory) rather than newSingleThreadExecutor(factory) because the latter hides the underlying ThreadPoolExecutor. That hiding may have value in cases where the ThreadPoolExecutor is exposed, but IgniteStripedThreadPoolExecutor is providing another level of delegation anyway. > GridDataStreamExecutor and GridCallbackExecutor JMX beans return incorrect > values due to invalid interface registration. > > > Key: IGNITE-7616 > URL: https://issues.apache.org/jira/browse/IGNITE-7616 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Max Shonichev >Assignee: David Harvey >Priority: Major > Labels: jmx > Fix For: 2.7 > > > Two of newly added management beans as a result of implementing feature > request https://issues.apache.org/jira/browse/IGNITE-7217 have bugs: > # GridDataStreamExecutor is registered as conforming to ThreadPoolMXBean > interface, though actually it is an incompatible StripedExecutor. > # GridCallbackExecutor is registered as conforming to ThreadPoolMXBean > interface, though actually it is an incompatible > IgniteStripedThreadPoolExecutor. > # ThreadPoolMXBeanAdapter checks whether adapted instance is > ThreadPoolExecutor, and as interfaces are incompatible, most of the JMX > attributes of GridCallbackExecutor and GridDataStreamExecutor are returned as > -1 or null. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7219) Reduce memory allocation in cassandra.persistence.PojoFieldAccessor
[
https://issues.apache.org/jira/browse/IGNITE-7219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16574957#comment-16574957
]
Stepan Ilchenko edited comment on IGNITE-7219 at 8/9/18 6:08 PM:
-
Hi, it's not only about memory allocation. We see quite big contention on
frequent calls of getValue, because getReadMethod is called each time and this
method of PropertyDescriptor is synchronized.
{noformat}
"flusher-7-#50" #78 prio=5 os_prio=0 tid=0x7f664057e800 nid=0x3c81 waiting
for monitor entry [0x7f65ec4c8000]
java.lang.Thread.State: BLOCKED (on object monitor)
at
java.beans.PropertyDescriptor.getReadMethod(PropertyDescriptor.java:207)
- waiting to lock <0x0006c0647cc8> (a java.beans.PropertyDescriptor)
at
org.apache.ignite.cache.store.cassandra.persistence.PojoFieldAccessor.getValue(PojoFieldAccessor.java:123)
at
org.apache.ignite.cache.store.cassandra.persistence.PojoField.getValueFromObject(PojoField.java:167)
at
org.apache.ignite.cache.store.cassandra.persistence.PersistenceController.bindValues(PersistenceController.java:450)
at
org.apache.ignite.cache.store.cassandra.persistence.PersistenceController.bindKeyValue(PersistenceController.java:203)
at
org.apache.ignite.cache.store.cassandra.CassandraCacheStore$4.bindStatement(CassandraCacheStore.java:368)
at
org.apache.ignite.cache.store.cassandra.CassandraCacheStore$4.bindStatement(CassandraCacheStore.java:354)
at
org.apache.ignite.cache.store.cassandra.session.CassandraSessionImpl.execute(CassandraSessionImpl.java:247)
at
org.apache.ignite.cache.store.cassandra.CassandraCacheStore.writeAll(CassandraCacheStore.java:354)
at
org.apache.ignite.internal.processors.cache.store.GridCacheWriteBehindStore.updateStore(GridCacheWriteBehindStore.java:815)
at
org.apache.ignite.internal.processors.cache.store.GridCacheWriteBehindStore.applyBatch(GridCacheWriteBehindStore.java:725)
at
org.apache.ignite.internal.processors.cache.store.GridCacheWriteBehindStore.access$2400(GridCacheWriteBehindStore.java:75)
at
org.apache.ignite.internal.processors.cache.store.GridCacheWriteBehindStore$Flusher.flushCacheCoalescing(GridCacheWriteBehindStore.java:1119)
at
org.apache.ignite.internal.processors.cache.store.GridCacheWriteBehindStore$Flusher.body(GridCacheWriteBehindStore.java:1017)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:748)
{noformat}
Attached proposed fix with caching of thread safe Method classes for reads and
writes. [^PojoFieldAccessor.java]
was (Author: mifist0):
Hi, it's not only about memory allocation. We see quite big contention on
frequent calls of getValue, because getReadMethod is called each time and this
method of PropertyDescriptor is synchronized.
{noformat}
java.lang.Thread.State: RUNNABLE
at java.util.Arrays.copyOfRange(Arrays.java:3664)
at java.lang.String.(String.java:207)
at java.lang.String.substring(String.java:1969)
at
sun.reflect.misc.ReflectUtil.isNonPublicProxyClass(ReflectUtil.java:288)
at sun.reflect.misc.ReflectUtil.checkPackageAccess(ReflectUtil.java:165)
at
sun.reflect.misc.ReflectUtil.isPackageAccessible(ReflectUtil.java:195)
at java.beans.MethodRef.get(MethodRef.java:72)
at
java.beans.PropertyDescriptor.getReadMethod(PropertyDescriptor.java:207)
- locked <0x0006c0647cc8> (a java.beans.PropertyDescriptor)
at
org.apache.ignite.cache.store.cassandra.persistence.PojoFieldAccessor.getValue(PojoFieldAccessor.java:123)
at
org.apache.ignite.cache.store.cassandra.persistence.PojoField.getValueFromObject(PojoField.java:167)
at
org.apache.ignite.cache.store.cassandra.persistence.PersistenceController.bindValues(PersistenceController.java:450)
at
org.apache.ignite.cache.store.cassandra.persistence.PersistenceController.bindKeyValue(PersistenceController.java:203)
at
org.apache.ignite.cache.store.cassandra.CassandraCacheStore$4.bindStatement(CassandraCacheStore.java:368)
at
org.apache.ignite.cache.store.cassandra.CassandraCacheStore$4.bindStatement(CassandraCacheStore.java:354)
at
org.apache.ignite.cache.store.cassandra.session.CassandraSessionImpl.execute(CassandraSessionImpl.java:247)
at
org.apache.ignite.cache.store.cassandra.CassandraCacheStore.writeAll(CassandraCacheStore.java:354)
at
org.apache.ignite.internal.processors.cache.store.GridCacheWriteBehindStore.updateStore(GridCacheWriteBehindStore.java:815)
at
org.apache.ignite.internal.processors.cache.store.GridCacheWriteBehindStore.applyBatch(GridCacheWriteBehindStore.java:725)
at
[jira] [Commented] (IGNITE-9243) Avoid test suit hangs on stopAllGrids
[ https://issues.apache.org/jira/browse/IGNITE-9243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16575214#comment-16575214 ] ASF GitHub Bot commented on IGNITE-9243: GitHub user BiryukovVA opened a pull request: https://github.com/apache/ignite/pull/4509 IGNITE-9243: G.allGrids() replaced by IgnitionEx.allGridsx() You can merge this pull request into a Git repository by running: $ git pull https://github.com/BiryukovVA/ignite IGNITE-9243 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4509.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 #4509 > Avoid test suit hangs on stopAllGrids > - > > Key: IGNITE-9243 > URL: https://issues.apache.org/jira/browse/IGNITE-9243 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.6 >Reporter: Vitaliy Biryukov >Assignee: Vitaliy Biryukov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > Tests sometimes hang on node join to topology, and this leads to the hang of > the whole suite. > Solution: Do not wait for nodes to join a topology in *stopAllGrids* method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9243) Avoid test suit hangs on stopAllGrids
Vitaliy Biryukov created IGNITE-9243: Summary: Avoid test suit hangs on stopAllGrids Key: IGNITE-9243 URL: https://issues.apache.org/jira/browse/IGNITE-9243 Project: Ignite Issue Type: Improvement Affects Versions: 2.6 Reporter: Vitaliy Biryukov Assignee: Vitaliy Biryukov Fix For: 2.7 Tests sometimes hang on node join to topology, and this leads to the hang of the whole suite. Solution: Do not wait for nodes to join a topology in *stopAllGrids* method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9196) SQL: Memory leak in MapNodeResults
[
https://issues.apache.org/jira/browse/IGNITE-9196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16575180#comment-16575180
]
Denis Mekhanikov commented on IGNITE-9196:
--
Please review my patch: https://github.com/apache/ignite/pull/4505
TC:
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8_IgniteTests24Java8=pull%2F4505%2Fhead
> SQL: Memory leak in MapNodeResults
> --
>
> Key: IGNITE-9196
> URL: https://issues.apache.org/jira/browse/IGNITE-9196
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.6
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>Priority: Blocker
>
> When size of a SQL query result set is a multiple of {{Query#pageSize}}, then
> {{MapQueryResult}} is never closed and removed from {{MapNodeResults#res}}
> collection.
> The following code leads to OOME when run with 1Gb heap:
> {code:java}
> public class MemLeakRepro {
> public static void main(String[] args) {
> Ignition.start(getConfiguration("server"));
> try (Ignite client =
> Ignition.start(getConfiguration("client").setClientMode(true))) {
> IgniteCache cache = startPeopleCache(client);
> int pages = 10;
> int pageSize = 1024;
> for (int i = 0; i < pages * pageSize; i++) {
> Person p = new Person("Person #" + i, 25);
> cache.put(i, p);
> }
> for (int i = 0; i < 1_000_000; i++) {
> if (i % 1000 == 0)
> System.out.println("Select iteration #" + i);
> Query> qry = new SqlFieldsQuery("select * from
> people");
> qry.setPageSize(pageSize);
> QueryCursor> cursor = cache.query(qry);
> cursor.getAll();
> cursor.close();
> }
> }
> }
> private static IgniteConfiguration getConfiguration(String instanceName) {
> IgniteConfiguration igniteCfg = new IgniteConfiguration();
> igniteCfg.setIgniteInstanceName(instanceName);
> TcpDiscoverySpi discoSpi = new TcpDiscoverySpi();
> discoSpi.setIpFinder(new TcpDiscoveryVmIpFinder(true));
> return igniteCfg;
> }
> private static IgniteCache startPeopleCache(Ignite node)
> {
> CacheConfiguration cacheCfg = new
> CacheConfiguration<>("cache");
> QueryEntity qe = new QueryEntity(Integer.class, Person.class);
> qe.setTableName("people");
> cacheCfg.setQueryEntities(Collections.singleton(qe));
> cacheCfg.setSqlSchema("PUBLIC");
> return node.getOrCreateCache(cacheCfg);
> }
> public static class Person {
> @QuerySqlField
> private String name;
> @QuerySqlField
> private int age;
> public Person(String name, int age) {
> this.name = name;
> this.age = age;
> }
> }
> }
> {code}
>
> At the same time it works perfectly fine, when there are, for example,
> {{pages * pageSize - 1}} records in cache instead.
> The reason for it is that {{MapQueryResult#fetchNextPage(...)}} method
> doesn't return true, when the result set size is a multiple of the page size.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9044) Update scala dependency version in Apache Ignite
[ https://issues.apache.org/jira/browse/IGNITE-9044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16575109#comment-16575109 ] Nikolai Kulagin commented on IGNITE-9044: - [~kuaw26], how can I test this on Java 9? > Update scala dependency version in Apache Ignite > > > Key: IGNITE-9044 > URL: https://issues.apache.org/jira/browse/IGNITE-9044 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitriy Pavlov >Assignee: Nikolai Kulagin >Priority: Major > Fix For: 2.7 > > > *ignite-scalar* > scala.library.version=2.11.8, need to be at least 2.11.12 or newer. > *ignite-scalar_2.10* > scala210.library.version 2.10.6, need to be at least 2.10.7, probably newer > *visor 2.10* > scala210.jline.version = 2.10.4 , need to be at least 2.10.7, probably newer > Probably impact would be wider. > We need at least run run-all, local build.sh and optionally release candate > step on TC. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7616) GridDataStreamExecutor and GridCallbackExecutor JMX beans return incorrect values due to invalid interface registration.
[ https://issues.apache.org/jira/browse/IGNITE-7616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Harvey reassigned IGNITE-7616: Assignee: David Harvey > GridDataStreamExecutor and GridCallbackExecutor JMX beans return incorrect > values due to invalid interface registration. > > > Key: IGNITE-7616 > URL: https://issues.apache.org/jira/browse/IGNITE-7616 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Max Shonichev >Assignee: David Harvey >Priority: Major > Labels: jmx > Fix For: 2.7 > > > Two of newly added management beans as a result of implementing feature > request https://issues.apache.org/jira/browse/IGNITE-7217 have bugs: > # GridDataStreamExecutor is registered as conforming to ThreadPoolMXBean > interface, though actually it is an incompatible StripedExecutor. > # GridCallbackExecutor is registered as conforming to ThreadPoolMXBean > interface, though actually it is an incompatible > IgniteStripedThreadPoolExecutor. > # ThreadPoolMXBeanAdapter checks whether adapted instance is > ThreadPoolExecutor, and as interfaces are incompatible, most of the JMX > attributes of GridCallbackExecutor and GridDataStreamExecutor are returned as > -1 or null. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9242) IgniteConfiguration.PeerAssemblyLoadingEnabled referenced in error message but doesn't exist
Ilya Kasnacheev created IGNITE-9242: --- Summary: IgniteConfiguration.PeerAssemblyLoadingEnabled referenced in error message but doesn't exist Key: IGNITE-9242 URL: https://issues.apache.org/jira/browse/IGNITE-9242 Project: Ignite Issue Type: Bug Components: platforms Affects Versions: 2.6 Reporter: Ilya Kasnacheev Instead, there is IgniteConfiguration.PeerAssemblyLoadingMode as per https://apacheignite-net.readme.io/docs/zero-deployment Message should be amended. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7219) Reduce memory allocation in cassandra.persistence.PojoFieldAccessor
[
https://issues.apache.org/jira/browse/IGNITE-7219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16574957#comment-16574957
]
Stepan Ilchenko commented on IGNITE-7219:
-
Hi, it's not only about memory allocation. We see quite big contention on
frequent calls of getValue, because getReadMethod is called each time and this
method of PropertyDescriptor is synchronized.
{noformat}
java.lang.Thread.State: RUNNABLE
at java.util.Arrays.copyOfRange(Arrays.java:3664)
at java.lang.String.(String.java:207)
at java.lang.String.substring(String.java:1969)
at
sun.reflect.misc.ReflectUtil.isNonPublicProxyClass(ReflectUtil.java:288)
at sun.reflect.misc.ReflectUtil.checkPackageAccess(ReflectUtil.java:165)
at
sun.reflect.misc.ReflectUtil.isPackageAccessible(ReflectUtil.java:195)
at java.beans.MethodRef.get(MethodRef.java:72)
at
java.beans.PropertyDescriptor.getReadMethod(PropertyDescriptor.java:207)
- locked <0x0006c0647cc8> (a java.beans.PropertyDescriptor)
at
org.apache.ignite.cache.store.cassandra.persistence.PojoFieldAccessor.getValue(PojoFieldAccessor.java:123)
at
org.apache.ignite.cache.store.cassandra.persistence.PojoField.getValueFromObject(PojoField.java:167)
at
org.apache.ignite.cache.store.cassandra.persistence.PersistenceController.bindValues(PersistenceController.java:450)
at
org.apache.ignite.cache.store.cassandra.persistence.PersistenceController.bindKeyValue(PersistenceController.java:203)
at
org.apache.ignite.cache.store.cassandra.CassandraCacheStore$4.bindStatement(CassandraCacheStore.java:368)
at
org.apache.ignite.cache.store.cassandra.CassandraCacheStore$4.bindStatement(CassandraCacheStore.java:354)
at
org.apache.ignite.cache.store.cassandra.session.CassandraSessionImpl.execute(CassandraSessionImpl.java:247)
at
org.apache.ignite.cache.store.cassandra.CassandraCacheStore.writeAll(CassandraCacheStore.java:354)
at
org.apache.ignite.internal.processors.cache.store.GridCacheWriteBehindStore.updateStore(GridCacheWriteBehindStore.java:815)
at
org.apache.ignite.internal.processors.cache.store.GridCacheWriteBehindStore.applyBatch(GridCacheWriteBehindStore.java:725)
at
org.apache.ignite.internal.processors.cache.store.GridCacheWriteBehindStore.access$2400(GridCacheWriteBehindStore.java:75)
at
org.apache.ignite.internal.processors.cache.store.GridCacheWriteBehindStore$Flusher.flushCacheCoalescing(GridCacheWriteBehindStore.java:1119)
at
org.apache.ignite.internal.processors.cache.store.GridCacheWriteBehindStore$Flusher.body(GridCacheWriteBehindStore.java:1017)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:748)
{noformat}
Attached proposed fix with caching of thread safe Method classes for reads and
writes. [^PojoFieldAccessor.java]
> Reduce memory allocation in cassandra.persistence.PojoFieldAccessor
> ---
>
> Key: IGNITE-7219
> URL: https://issues.apache.org/jira/browse/IGNITE-7219
> Project: Ignite
> Issue Type: Improvement
> Components: cassandra
>Affects Versions: 2.1, 2.2, 2.3
>Reporter: Dmitry Konstantinov
>Priority: Major
> Attachments: PojoFieldAccessor.java,
> ignitePojoFieldAccessorMemAlloc.png
>
>
> As a part of store logic of CassandraCacheStore if strategy="POJO" is used to
> store a value entity -
> org.apache.ignite.cache.store.cassandra.persistence.PojoFieldAccessor is used
> to work with POJO properties. Within the methods getValue/setValue
> getReadMethod()/getWriteMethod() are invoked each time. As a part of the
> methods invocation sun.reflect.misc.ReflectUtil#isNonPublicProxyClass is
> triggered which works with class names as strings and allocates a memory. It
> is a small allocation by itself but it is triggered very frequently - for
> each field for each entity per each DB operation - so in summary it create a
> significant pressure. See attach: [^ignitePojoFieldAccessorMemAlloc.png]
> Suggestion: we can cache and reuse getReadMethod()/getWriteMethod() results
> as a part of constructor logic of PojoFieldAccessor
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7219) Reduce memory allocation in cassandra.persistence.PojoFieldAccessor
[ https://issues.apache.org/jira/browse/IGNITE-7219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stepan Ilchenko updated IGNITE-7219: Attachment: PojoFieldAccessor.java > Reduce memory allocation in cassandra.persistence.PojoFieldAccessor > --- > > Key: IGNITE-7219 > URL: https://issues.apache.org/jira/browse/IGNITE-7219 > Project: Ignite > Issue Type: Improvement > Components: cassandra >Affects Versions: 2.1, 2.2, 2.3 >Reporter: Dmitry Konstantinov >Priority: Major > Attachments: PojoFieldAccessor.java, > ignitePojoFieldAccessorMemAlloc.png > > > As a part of store logic of CassandraCacheStore if strategy="POJO" is used to > store a value entity - > org.apache.ignite.cache.store.cassandra.persistence.PojoFieldAccessor is used > to work with POJO properties. Within the methods getValue/setValue > getReadMethod()/getWriteMethod() are invoked each time. As a part of the > methods invocation sun.reflect.misc.ReflectUtil#isNonPublicProxyClass is > triggered which works with class names as strings and allocates a memory. It > is a small allocation by itself but it is triggered very frequently - for > each field for each entity per each DB operation - so in summary it create a > significant pressure. See attach: [^ignitePojoFieldAccessorMemAlloc.png] > Suggestion: we can cache and reuse getReadMethod()/getWriteMethod() results > as a part of constructor logic of PojoFieldAccessor -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8731) .NET: intermittent failures in DataStreamerTest.TestFinalizer test
[
https://issues.apache.org/jira/browse/IGNITE-8731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16574859#comment-16574859
]
Alexey Goncharuk commented on IGNITE-8731:
--
[~vozerov], [~ptupitsyn], I still see similar test failures on TC, now on all
agents. At the same time, I commented the {{TestFinalizer}} test in branch
ignite-8983, and TC runs look much better [1].
Reopening this ticket.
[1]
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8_IgniteTests24Java8=ignite-8983
> .NET: intermittent failures in DataStreamerTest.TestFinalizer test
> --
>
> Key: IGNITE-8731
> URL: https://issues.apache.org/jira/browse/IGNITE-8731
> Project: Ignite
> Issue Type: Task
> Components: platforms
>Affects Versions: 2.5
>Reporter: Vladimir Ozerov
>Assignee: Peter Ivanov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> {{DataStreamerTest.TsetFinalizer}} constantly fails on some TC agents, while
> work OK on others. Most likely we have an environmental issue.
> OK:
> # publicagent01_03_9090
> # publicagent02_02_9090
> Not OK:
> # publicagent01_01_9090
> # publicagent01_02_9090
> # publicagent02_01_9090
> # publicagent02_03_9090
> Quick comparison of agent's configuration reveals only one difference -
> version of PowerShell. On "good" machines it is {{5.1.16299.15}}, on "bad"
> machines it is {{5.1.17134.1}}.
> PowerShell is essential part of build infrastructure so chances that some
> incorrect dependencies are linked at some point. I am not sure that this
> might be the root cause of failures, but at the very least we can try.
> Let's downgrade PowerShell on one of affected machines and see if it works.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Reopened] (IGNITE-8731) .NET: intermittent failures in DataStreamerTest.TestFinalizer test
[
https://issues.apache.org/jira/browse/IGNITE-8731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk reopened IGNITE-8731:
--
Assignee: (was: Peter Ivanov)
> .NET: intermittent failures in DataStreamerTest.TestFinalizer test
> --
>
> Key: IGNITE-8731
> URL: https://issues.apache.org/jira/browse/IGNITE-8731
> Project: Ignite
> Issue Type: Task
> Components: platforms
>Affects Versions: 2.5
>Reporter: Vladimir Ozerov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> {{DataStreamerTest.TsetFinalizer}} constantly fails on some TC agents, while
> work OK on others. Most likely we have an environmental issue.
> OK:
> # publicagent01_03_9090
> # publicagent02_02_9090
> Not OK:
> # publicagent01_01_9090
> # publicagent01_02_9090
> # publicagent02_01_9090
> # publicagent02_03_9090
> Quick comparison of agent's configuration reveals only one difference -
> version of PowerShell. On "good" machines it is {{5.1.16299.15}}, on "bad"
> machines it is {{5.1.17134.1}}.
> PowerShell is essential part of build infrastructure so chances that some
> incorrect dependencies are linked at some point. I am not sure that this
> might be the root cause of failures, but at the very least we can try.
> Let's downgrade PowerShell on one of affected machines and see if it works.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9228) Spark SQL Table Schema Specification
[ https://issues.apache.org/jira/browse/IGNITE-9228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-9228: Affects Version/s: 2.6 Fix Version/s: 2.7 > Spark SQL Table Schema Specification > > > Key: IGNITE-9228 > URL: https://issues.apache.org/jira/browse/IGNITE-9228 > Project: Ignite > Issue Type: Improvement > Components: spark >Affects Versions: 2.6 >Reporter: Stuart Macdonald >Priority: Major > Fix For: 2.7 > > > The Ignite Spark SQL interface currently takes just “table name” as a > parameter which it uses to supply a Spark dataset with data from the > underlying Ignite SQL table with that name. > To do this it loops through each cache and finds the first one with the > given table name [1]. This causes issues if there are multiple tables > registered in different schema with the same table name as you can only > access one of those from Spark. We could either: > 1. Pass an extra parameter through the Ignite Spark data source which > optionally specifies the schema name. > 2. Support namespacing in the existing table name parameter, ie > “schemaName.tableName” > [1 > ]https://github.com/apache/ignite/blob/ca973ad99c6112160a305df05be9458e29f88307/modules/spark/src/main/scala/org/apache/ignite/spark/impl/package.scala#L119 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9229) Integration with Spark Data Frame. Add support for a ARRAY data type
[ https://issues.apache.org/jira/browse/IGNITE-9229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov reassigned IGNITE-9229: --- Assignee: Nikolay Izhikov > Integration with Spark Data Frame. Add support for a ARRAY data type > > > Key: IGNITE-9229 > URL: https://issues.apache.org/jira/browse/IGNITE-9229 > Project: Ignite > Issue Type: Bug > Components: spark >Affects Versions: 2.6 >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Critical > Fix For: 2.7 > > > Currently, integration with Spark Data Frames doesn't support ARRAY data type. > We need to add support for it -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9231) onMarkDirty improvement throttle implementation.
[ https://issues.apache.org/jira/browse/IGNITE-9231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16574827#comment-16574827 ] ASF GitHub Bot commented on IGNITE-9231: GitHub user zstan opened a pull request: https://github.com/apache/ignite/pull/4506 IGNITE-9231 improvement throttle implementation …Buf condition. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9231 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4506.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 #4506 commit 8601b8393cb86a80b978b8c26c5bbc9d28841f67 Author: Evgeny Stanilovskiy Date: 2018-08-09T10:50:50Z IGNITE-9231 improvement throttle implementation, unpark threads on cpBuf condition. > onMarkDirty improvement throttle implementation. > > > Key: IGNITE-9231 > URL: https://issues.apache.org/jira/browse/IGNITE-9231 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.6 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Fix For: 2.7 > > > PagesWriteThrottle#onMarkDirty implementation park threads if > checkpointBuffer is near to overflow, but further release of checkpointBuffer > has no effect on parking threads, they still can be parked. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9004) Failed to reinitialize local partitions
[
https://issues.apache.org/jira/browse/IGNITE-9004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16574797#comment-16574797
]
ASF GitHub Bot commented on IGNITE-9004:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4383
> Failed to reinitialize local partitions
> ---
>
> Key: IGNITE-9004
> URL: https://issues.apache.org/jira/browse/IGNITE-9004
> Project: Ignite
> Issue Type: Test
>Reporter: Anton Kalashnikov
>Assignee: Eduard Shangareev
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> Reproduced by Activate/Deactivate suit, almost any tests in
> IgniteChangeGlobalStateTest class. for example
> IgniteChangeGlobalStateTest#testStopPrimaryAndActivateFromClientNode
> {noformat}
> Failed to reinitialize local partitions (preloading will be stopped):
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=6,
> minorTopVer=1], discoEvt=DiscoveryCustomEvent
> [customMsg=ChangeGlobalStateMessage
> [id=9093c48a461-165cdacd-8a3b-4072-9f48-e80e1b63fda9,
> reqId=07393ea5-1c6a-4581-b016-9eb88d6bd978,
> initiatingNodeId=8dced5ba-725d-494b-8e8e-ffc76453fecd, activate=true,
> baselineTopology=BaselineTopology [id=0, branchingHash=314980173,
> branchingType='Cluster activation', baselineNodes=[node2, node0, node1]],
> forceChangeBaselineTopology=false, timestamp=1531832492029],
> affTopVer=AffinityTopologyVersion [topVer=6, minorTopVer=1],
> super=DiscoveryEvent [evtNode=TcpDiscoveryNode
> [id=8dced5ba-725d-494b-8e8e-ffc76453fecd, addrs=[0:0:0:0:0:0:0:1%lo,
> 127.0.0.1, 172.25.4.132], sockAddrs=[/172.25.4.132:47504,
> /0:0:0:0:0:0:0:1%lo:47504, /127.0.0.1:47504], discPort=47504, order=2,
> intOrder=2, lastExchangeTime=1531832486546, loc=false,
> ver=2.7.0#19700101-sha1:, isClient=false], topVer=6,
> nodeId8=9960f6b9, msg=null, type=DISCOVERY_CUSTOM_EVT,
> tstamp=1531832492035]], nodeId=8dced5ba, evt=DISCOVERY_CUSTOM_EVT]
> java.lang.AssertionError: calculatedOffset=3072, allocated=2048,
> headerSize=1024
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.read(FilePageStore.java:358)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:400)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:384)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:783)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:627)
> at
> org.apache.ignite.internal.processors.cache.persistence.DataStructure.acquirePage(DataStructure.java:144)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.init(PagesList.java:169)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.AbstractFreeList.(AbstractFreeList.java:371)
> at
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage$FreeListImpl.(MetaStorage.java:484)
> at
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage.init(MetaStorage.java:143)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readCheckpointAndRestoreMemory(GridCacheDatabaseSharedManager.java:852)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest(GridDhtPartitionsExchangeFuture.java:954)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:661)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2484)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2364)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Given:
> # Activated Node1-1 in grid1.
> # MetaStorage on node1-1 in OffHeap.
> # MetaStorage have not storage on disk yet.
> When:
> # Checkpoint on node1-1 is starting. Start checkpoint marker was written.
> # node2-1 in grid2 is starting.(grid1 and grid2 have same persistence)
> Then:
> # node2-1 found expected checkpoint marker("Found unexpected checkpoint
> marker") and initialize FilePageStore for metaStorage by empty page
> # node1-1 finished checkpoint and wrote MetaStorage on disk.
> # After stop grid1 and activate grid2 node2-1 was failed because try read
> more than one page.
>
[jira] [Commented] (IGNITE-9196) SQL: Memory leak in MapNodeResults
[
https://issues.apache.org/jira/browse/IGNITE-9196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16574793#comment-16574793
]
ASF GitHub Bot commented on IGNITE-9196:
GitHub user dmekhanikov opened a pull request:
https://github.com/apache/ignite/pull/4505
IGNITE-9196 Fix memory leak in MapNodeResults
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-9196
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4505.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 #4505
commit bc6377008fa62f1217a5cd54bae34f6ad4d809d0
Author: Denis Mekhanikov
Date: 2018-08-09T12:43:46Z
IGNITE-9196 Fix memory leak in MapNodeResults.
> SQL: Memory leak in MapNodeResults
> --
>
> Key: IGNITE-9196
> URL: https://issues.apache.org/jira/browse/IGNITE-9196
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.6
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>Priority: Blocker
>
> When size of a SQL query result set is a multiple of {{Query#pageSize}}, then
> {{MapQueryResult}} is never closed and removed from {{MapNodeResults#res}}
> collection.
> The following code leads to OOME when run with 1Gb heap:
> {code:java}
> public class MemLeakRepro {
> public static void main(String[] args) {
> Ignition.start(getConfiguration("server"));
> try (Ignite client =
> Ignition.start(getConfiguration("client").setClientMode(true))) {
> IgniteCache cache = startPeopleCache(client);
> int pages = 10;
> int pageSize = 1024;
> for (int i = 0; i < pages * pageSize; i++) {
> Person p = new Person("Person #" + i, 25);
> cache.put(i, p);
> }
> for (int i = 0; i < 1_000_000; i++) {
> if (i % 1000 == 0)
> System.out.println("Select iteration #" + i);
> Query> qry = new SqlFieldsQuery("select * from
> people");
> qry.setPageSize(pageSize);
> QueryCursor> cursor = cache.query(qry);
> cursor.getAll();
> cursor.close();
> }
> }
> }
> private static IgniteConfiguration getConfiguration(String instanceName) {
> IgniteConfiguration igniteCfg = new IgniteConfiguration();
> igniteCfg.setIgniteInstanceName(instanceName);
> TcpDiscoverySpi discoSpi = new TcpDiscoverySpi();
> discoSpi.setIpFinder(new TcpDiscoveryVmIpFinder(true));
> return igniteCfg;
> }
> private static IgniteCache startPeopleCache(Ignite node)
> {
> CacheConfiguration cacheCfg = new
> CacheConfiguration<>("cache");
> QueryEntity qe = new QueryEntity(Integer.class, Person.class);
> qe.setTableName("people");
> cacheCfg.setQueryEntities(Collections.singleton(qe));
> cacheCfg.setSqlSchema("PUBLIC");
> return node.getOrCreateCache(cacheCfg);
> }
> public static class Person {
> @QuerySqlField
> private String name;
> @QuerySqlField
> private int age;
> public Person(String name, int age) {
> this.name = name;
> this.age = age;
> }
> }
> }
> {code}
>
> At the same time it works perfectly fine, when there are, for example,
> {{pages * pageSize - 1}} records in cache instead.
> The reason for it is that {{MapQueryResult#fetchNextPage(...)}} method
> doesn't return true, when the result set size is a multiple of the page size.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9219) Uncomment 13 test classes in IgniteCacheTestSuite4 (Cache 4)
[
https://issues.apache.org/jira/browse/IGNITE-9219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16574764#comment-16574764
]
Ilya Kasnacheev commented on IGNITE-9219:
-
[~dpavlov] please review proposed fix
> Uncomment 13 test classes in IgniteCacheTestSuite4 (Cache 4)
>
>
> Key: IGNITE-9219
> URL: https://issues.apache.org/jira/browse/IGNITE-9219
> Project: Ignite
> Issue Type: Sub-task
> Components: cache
>Reporter: Ilya Kasnacheev
>Priority: Major
>
> {code}
> //suite.addTestSuite(IgniteCacheAtomicCopyOnReadDisabledTest.class);
> //suite.addTestSuite(IgniteCacheTxCopyOnReadDisabledTest.class);
> //suite.addTestSuite(IgniteCacheAtomicLocalStoreValueTest.class);
> //suite.addTestSuite(IgniteCacheAtomicStoreValueTest.class);
> //
> suite.addTestSuite(IgniteCacheAtomicNearEnabledStoreValueTest.class);
> //
> suite.addTestSuite(IgniteCacheAtomicPrimaryWriteOrderStoreValueTest.class);
> //
> suite.addTestSuite(IgniteCacheAtomicPrimaryWriteOrderNearEnabledStoreValueTest.class);
> //suite.addTestSuite(IgniteCacheTxLocalStoreValueTest.class);
> //suite.addTestSuite(IgniteCacheTxStoreValueTest.class);
> //suite.addTestSuite(IgniteCacheTxNearEnabledStoreValueTest.class);
>
> //suite.addTestSuite(CacheStoreSessionListenerLifecycleSelfTest.class);
> // suite.addTestSuite(CacheSwapUnswapGetTest.class);
> // suite.addTestSuite(CacheSwapUnswapGetTestSmallQueueSize.class);
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9219) Uncomment 13 test classes in IgniteCacheTestSuite4 (Cache 4)
[
https://issues.apache.org/jira/browse/IGNITE-9219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16574755#comment-16574755
]
ASF GitHub Bot commented on IGNITE-9219:
GitHub user alamar opened a pull request:
https://github.com/apache/ignite/pull/4504
IGNITE-9219 Uncomment tests in IgniteCacheTestSuite4, minor fixes.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-9219
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4504.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 #4504
commit bf6b49e29026ecf6117751d10e73db1c2dc7c05f
Author: Ilya Kasnacheev
Date: 2018-08-09T12:15:28Z
IGNITE-9219 Uncomment tests in IgniteCacheTestSuite4, minor fixes.
> Uncomment 13 test classes in IgniteCacheTestSuite4 (Cache 4)
>
>
> Key: IGNITE-9219
> URL: https://issues.apache.org/jira/browse/IGNITE-9219
> Project: Ignite
> Issue Type: Sub-task
> Components: cache
>Reporter: Ilya Kasnacheev
>Priority: Major
>
> {code}
> //suite.addTestSuite(IgniteCacheAtomicCopyOnReadDisabledTest.class);
> //suite.addTestSuite(IgniteCacheTxCopyOnReadDisabledTest.class);
> //suite.addTestSuite(IgniteCacheAtomicLocalStoreValueTest.class);
> //suite.addTestSuite(IgniteCacheAtomicStoreValueTest.class);
> //
> suite.addTestSuite(IgniteCacheAtomicNearEnabledStoreValueTest.class);
> //
> suite.addTestSuite(IgniteCacheAtomicPrimaryWriteOrderStoreValueTest.class);
> //
> suite.addTestSuite(IgniteCacheAtomicPrimaryWriteOrderNearEnabledStoreValueTest.class);
> //suite.addTestSuite(IgniteCacheTxLocalStoreValueTest.class);
> //suite.addTestSuite(IgniteCacheTxStoreValueTest.class);
> //suite.addTestSuite(IgniteCacheTxNearEnabledStoreValueTest.class);
>
> //suite.addTestSuite(CacheStoreSessionListenerLifecycleSelfTest.class);
> // suite.addTestSuite(CacheSwapUnswapGetTest.class);
> // suite.addTestSuite(CacheSwapUnswapGetTestSmallQueueSize.class);
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-2907) GridServiceNotFoundException is not descriptive
[ https://issues.apache.org/jira/browse/IGNITE-2907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur reassigned IGNITE-2907: -- Assignee: Vyacheslav Daradur > GridServiceNotFoundException is not descriptive > --- > > Key: IGNITE-2907 > URL: https://issues.apache.org/jira/browse/IGNITE-2907 > Project: Ignite > Issue Type: Bug > Components: managed services >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn >Assignee: Vyacheslav Daradur >Priority: Minor > > "Service node found" message does not make sense. > * Message should be fixed > * More details should be added (why is this situation possible, how to fix it) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-5103) TcpDiscoverySpi ignores maxMissedClientHeartbeats property
[
https://issues.apache.org/jira/browse/IGNITE-5103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16574732#comment-16574732
]
Anton Kalashnikov commented on IGNITE-5103:
---
Thanks, Evgenii. Now everything looks good for me. I think it can be merged.
> TcpDiscoverySpi ignores maxMissedClientHeartbeats property
> --
>
> Key: IGNITE-5103
> URL: https://issues.apache.org/jira/browse/IGNITE-5103
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.9
>Reporter: Valentin Kulichenko
>Assignee: Evgenii Zhuravlev
>Priority: Blocker
> Fix For: 2.7
>
> Attachments: TcpDiscoveryClientSuspensionSelfTest.java
>
>
> Test scenario is the following:
> * Start one or more servers.
> * Start a client node.
> * Suspend client process using {{-SIGSTOP}} signal.
> * Wait for {{maxMissedClientHeartbeats*heartbeatFrequency}}.
> * Client node is expected to be removed from topology, but server nodes don't
> do that.
> Attached is the unit test reproducing the same by stopping the heartbeat
> sender thread on the client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-7441) Drop IGNITE_SERVICES_COMPATIBILITY_MODE system property
[ https://issues.apache.org/jira/browse/IGNITE-7441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur reassigned IGNITE-7441: -- Assignee: Vyacheslav Daradur > Drop IGNITE_SERVICES_COMPATIBILITY_MODE system property > --- > > Key: IGNITE-7441 > URL: https://issues.apache.org/jira/browse/IGNITE-7441 > Project: Ignite > Issue Type: Task >Reporter: Denis Mekhanikov >Assignee: Vyacheslav Daradur >Priority: Minor > > IGNITE_SERVICES_COMPATIBILITY_MODE system property was introduced to > configure backward compatibility mode for service configuration classes. But > since it was done in 1.9 and current version is completely incompatible with > it, there is no point in keeping this property. > Moreover, it is ignored after IGNITE-5145. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-1905) High contention for CacheLockImpl causes AssertionErrors
[
https://issues.apache.org/jira/browse/IGNITE-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16574717#comment-16574717
]
Vitaliy Biryukov commented on IGNITE-1905:
--
[~agoncharuk], we can't use future as the synch monitor, because it'll cause
deadlocks.
As far as I understand *map* phase is always before *onResult* method is
called. Just need to make *timeoutObj* field volatile.
> High contention for CacheLockImpl causes AssertionErrors
>
>
> Key: IGNITE-1905
> URL: https://issues.apache.org/jira/browse/IGNITE-1905
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: ignite-1.4
> Environment: Windows 7
>Reporter: Denis Magda
>Assignee: Vitaliy Biryukov
>Priority: Major
> Attachments: ClientTest.java, ServerTest.java
>
>
> When multiple threads, running on the same client node, compete for
> CacheLockImpl this leads to AssertionErrors.
> Pseudo-code snippet, that is called from multiple threads and causes the
> assertions, looks like this:
> {noformat}
> boolean locked = lock.tryLock(100, TimeUnit.MILLISECONDS);
> if (locked)
> lock.unlock();
> {noformat}
> Initially the issue was detected on ignite-1.4.
> In server's node logs the following assertion appears
> {noformat}
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.addOwned(GridDhtLockFuture.java:958)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.map(GridDhtLockFuture.java:918)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.onOwnerChanged(GridDhtLockFuture.java:663)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMvccManager$2.onOwnerChanged(GridCacheMvccManager.java:155)
> at
> org.apache.ignite.internal.processors.cache.distributed.GridDistributedCacheEntry.checkOwnerChanged(GridDistributedCacheEntry.java:810)
> at
> org.apache.ignite.internal.processors.cache.distributed.GridDistributedCacheEntry.readyLock(GridDistributedCacheEntry.java:516)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.readyLocks(GridDhtLockFuture.java:576)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.map(GridDhtLockFuture.java:764)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.lockAllAsync(GridDhtTransactionalCacheAdapter.java:973)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processNearLockRequest(GridDhtTransactionalCacheAdapter.java:557)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.access$000(GridDhtTransactionalCacheAdapter.java:88)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$2.apply(GridDhtTransactionalCacheAdapter.java:132)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$2.apply(GridDhtTransactionalCacheAdapter.java:130)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:580)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:280)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:198)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:77)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:160)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:811)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1500(GridIoManager.java:106)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:774)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
>
> In addition from time to time a client node also outputs a different kind of
> assertion:
> {noformat}
> Exception in thread "ignite-#4%sys-null%" java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.GridCacheExplicitLockSpan.markOwned(GridCacheExplicitLockSpan.java:196)
> at
>
[jira] [Commented] (IGNITE-8493) GridToStringBuilder fails with NPE deals with primitive arrays operations.
[ https://issues.apache.org/jira/browse/IGNITE-8493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16574707#comment-16574707 ] Stanilovsky Evgeny commented on IGNITE-8493: thanks, done, [~agoncharuk] can u merge it? > GridToStringBuilder fails with NPE deals with primitive arrays operations. > -- > > Key: IGNITE-8493 > URL: https://issues.apache.org/jira/browse/IGNITE-8493 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.4 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Fix For: 2.7 > > > GridToStringBuilder#arrayToString fails with NPE, if input is a primitive > array. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8724) Skip logging 3-rd parameter while calling U.warn with initialized logger.
[
https://issues.apache.org/jira/browse/IGNITE-8724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16574689#comment-16574689
]
Stanilovsky Evgeny commented on IGNITE-8724:
Thanks for review, make changes, TC link updated and in progress now.
> Skip logging 3-rd parameter while calling U.warn with initialized logger.
> -
>
> Key: IGNITE-8724
> URL: https://issues.apache.org/jira/browse/IGNITE-8724
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.5
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Fix For: 2.7
>
> Attachments: tc.png
>
>
> There are a lot of places where exception need to be logged, for example :
> {code:java}
> U.warn(log,"Unable to await partitions release future", e);
> {code}
> but current U.warn realization silently swallow it.
> {code:java}
> public static void warn(@Nullable IgniteLogger log, Object longMsg,
> Object shortMsg) {
> assert longMsg != null;
> assert shortMsg != null;
> if (log != null)
> log.warning(compact(longMsg.toString()));
> else
> X.println("[" + SHORT_DATE_FMT.format(new java.util.Date()) + "]
> (wrn) " +
> compact(shortMsg.toString()));
> }
> {code}
> fix, looks like simple add:
> {code:java}
> public static void warn(@Nullable IgniteLogger log, Object longMsg,
> Throwable ex) {
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9202) .NET `TestRemoteNodes` fails with "Failed to map SQL query to topology"
[
https://issues.apache.org/jira/browse/IGNITE-9202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16574682#comment-16574682
]
Maxim Muzafarov commented on IGNITE-9202:
-
[~vozerov],
Will you have time to take a look at? Which `timeout` is better to use here to
avoid this exception?
I think we have some options here:
* `1000_000L` timeout as it used in JUnit tests, can be set it via environment
variables
* Can use {{zero}} timeout via setting in for query
* Can increase defalut timeout in our java code part.
> .NET `TestRemoteNodes` fails with "Failed to map SQL query to topology"
> ---
>
> Key: IGNITE-9202
> URL: https://issues.apache.org/jira/browse/IGNITE-9202
> Project: Ignite
> Issue Type: Test
>Reporter: Maxim Muzafarov
>Priority: Blocker
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> Tests constantly fails with exception `Failed to map SQL query to topology.`
> * ExamplesTest.TestRemoteNodes(BinaryModeExample)
> * ExamplesTest.TestRemoteNodes(LinqExample)
> * ExamplesTest.TestRemoteNodes(SqlExample)
> {code:java}
> Test(s) failed. Apache.Ignite.Core.Cache.CacheException : Failed to map SQL
> query to topology. > Apache.Ignite.Core.Common.JavaException :
> javax.cache.CacheException: Failed to map SQL query to topology.
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:577)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$8.iterator(IgniteH2Indexing.java:1447)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:95)
> at
> org.apache.ignite.internal.processors.platform.cache.query.PlatformAbstractQueryCursor.processInLongOutLong(PlatformAbstractQueryCursor.java:147)
> at
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inLongOutLong(PlatformTargetProxyImpl.java:55)
> {code}
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-3155722801840665529=%3Cdefault%3E=testDetails
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8987) Ignite hangs during getting of atomic structure after autoactivation
[ https://issues.apache.org/jira/browse/IGNITE-8987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk reassigned IGNITE-8987: Assignee: Roman Guseinov > Ignite hangs during getting of atomic structure after autoactivation > > > Key: IGNITE-8987 > URL: https://issues.apache.org/jira/browse/IGNITE-8987 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.4 >Reporter: Andrey Aleksandrov >Assignee: Roman Guseinov >Priority: Major > Fix For: 2.7 > > Attachments: reproducer.java > > > I investigate the use cases with autoactivation and creating of the > IgniteAtomicSequence. It hangs on awaitInitialization() method in case if it > called after the last node from BLT was started. > Steps to reproduce: > First iteration: > > Do next in one thread: > 1)Start server 1 > 2)Start server 2 > 3)Activate the cluster > 4)Create the IgniteAtomicSequence using next code: > IgniteAtomicSequence igniteAtomicSequence = ignite.atomicSequence( > "TestName", > atomicConfiguration, > 10, > true); > Second iteration: > 1)Start server 1 > 2)Start server 2 (Autoactivation will be started) > 3)Get the IgniteAtomicSequence using next code: > IgniteAtomicSequence igniteAtomicSequence = ignite.atomicSequence( > "TestName", > 10, > true); //could be false because TestName was already created in iteration 1 > In this case, we hang in awaitInitialization() method in > DataStructureProcessor.getAtomic() method. > In case if I added some sleep timeout between step 2 and 3 in the second > iteration then everything was ok. Looks like we have some race here. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8987) Ignite hangs during getting of atomic structure after autoactivation
[ https://issues.apache.org/jira/browse/IGNITE-8987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Gerus reassigned IGNITE-8987: --- Assignee: Roman Guseinov (was: Alexey Goncharuk) > Ignite hangs during getting of atomic structure after autoactivation > > > Key: IGNITE-8987 > URL: https://issues.apache.org/jira/browse/IGNITE-8987 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.4 >Reporter: Andrey Aleksandrov >Assignee: Roman Guseinov >Priority: Major > Fix For: 2.7 > > Attachments: reproducer.java > > > I investigate the use cases with autoactivation and creating of the > IgniteAtomicSequence. It hangs on awaitInitialization() method in case if it > called after the last node from BLT was started. > Steps to reproduce: > First iteration: > > Do next in one thread: > 1)Start server 1 > 2)Start server 2 > 3)Activate the cluster > 4)Create the IgniteAtomicSequence using next code: > IgniteAtomicSequence igniteAtomicSequence = ignite.atomicSequence( > "TestName", > atomicConfiguration, > 10, > true); > Second iteration: > 1)Start server 1 > 2)Start server 2 (Autoactivation will be started) > 3)Get the IgniteAtomicSequence using next code: > IgniteAtomicSequence igniteAtomicSequence = ignite.atomicSequence( > "TestName", > 10, > true); //could be false because TestName was already created in iteration 1 > In this case, we hang in awaitInitialization() method in > DataStructureProcessor.getAtomic() method. > In case if I added some sleep timeout between step 2 and 3 in the second > iteration then everything was ok. Looks like we have some race here. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8987) Ignite hangs during getting of atomic structure after autoactivation
[ https://issues.apache.org/jira/browse/IGNITE-8987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk reassigned IGNITE-8987: Assignee: (was: Roman Guseinov) > Ignite hangs during getting of atomic structure after autoactivation > > > Key: IGNITE-8987 > URL: https://issues.apache.org/jira/browse/IGNITE-8987 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.4 >Reporter: Andrey Aleksandrov >Priority: Major > Fix For: 2.7 > > Attachments: reproducer.java > > > I investigate the use cases with autoactivation and creating of the > IgniteAtomicSequence. It hangs on awaitInitialization() method in case if it > called after the last node from BLT was started. > Steps to reproduce: > First iteration: > > Do next in one thread: > 1)Start server 1 > 2)Start server 2 > 3)Activate the cluster > 4)Create the IgniteAtomicSequence using next code: > IgniteAtomicSequence igniteAtomicSequence = ignite.atomicSequence( > "TestName", > atomicConfiguration, > 10, > true); > Second iteration: > 1)Start server 1 > 2)Start server 2 (Autoactivation will be started) > 3)Get the IgniteAtomicSequence using next code: > IgniteAtomicSequence igniteAtomicSequence = ignite.atomicSequence( > "TestName", > 10, > true); //could be false because TestName was already created in iteration 1 > In this case, we hang in awaitInitialization() method in > DataStructureProcessor.getAtomic() method. > In case if I added some sleep timeout between step 2 and 3 in the second > iteration then everything was ok. Looks like we have some race here. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6069) Service versioning
[ https://issues.apache.org/jira/browse/IGNITE-6069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur updated IGNITE-6069: --- Component/s: managed services > Service versioning > -- > > Key: IGNITE-6069 > URL: https://issues.apache.org/jira/browse/IGNITE-6069 > Project: Ignite > Issue Type: New Feature > Components: general, managed services >Affects Versions: 2.1 >Reporter: Ilya Lantukh >Assignee: Ilya Lantukh >Priority: Major > > Make services upgradable -again-. > Main points: > - compute binary type ID by (classname + version) > - use serialVersionUuid as version ( ?) > - all service instances with the same name must have the same version > - make ServiceProxy aware of versions and upgrade process, pause requests > while service is being upgraded > - extend Service interface (UpgradableService?) - add ability to collect > state of previous version before start. > Once the feature is implemented, it has to be documented extensively. The > ticket must not be closed until this happens. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-7251) Remove term "fabric" from Ignite deliverables
[
https://issues.apache.org/jira/browse/IGNITE-7251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-7251:
-
Comment: was deleted
(was: Github user vveider closed the pull request at:
https://github.com/apache/ignite/pull/3315
)
> Remove term "fabric" from Ignite deliverables
> -
>
> Key: IGNITE-7251
> URL: https://issues.apache.org/jira/browse/IGNITE-7251
> Project: Ignite
> Issue Type: Task
>Reporter: Denis Magda
>Assignee: Anton Vinogradov
>Priority: Blocker
> Labels: important
> Fix For: 2.7
>
>
> Apache Ignite binary releases still include “fabric” word in their names:
> https://ignite.apache.org/download.cgi#binaries
> For instance, this is a full name of the previous release -
> apache-ignite-fabric-2.3.0-bin.
> It’s a little oversight on our side because the project has not been
> positioned as a fabric for a while.
> Remove “fabric” from the name and have the binary releases named as -
> {{apache-ignite-\{version}-bin}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-8686) Web console: 'Get started' points to the wrong page
[ https://issues.apache.org/jira/browse/IGNITE-8686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko resolved IGNITE-8686. --- Resolution: Won't Fix Assignee: Alexey Kuznetsov > Web console: 'Get started' points to the wrong page > --- > > Key: IGNITE-8686 > URL: https://issues.apache.org/jira/browse/IGNITE-8686 > Project: Ignite > Issue Type: Bug > Components: wizards >Affects Versions: 2.5 >Reporter: Pavel Konstantinov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > Attachments: screenshot-1.png > > > I'm noticed that 'Get started' button on the landing page points to 'signin' > page, but should point to 'signup' page. > !screenshot-1.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8686) Web console: 'Get started' points to the wrong page
[ https://issues.apache.org/jira/browse/IGNITE-8686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16574669#comment-16574669 ] Vasiliy Sisko commented on IGNITE-8686: --- Not reproduced. *Get started* button open valid sign up page. > Web console: 'Get started' points to the wrong page > --- > > Key: IGNITE-8686 > URL: https://issues.apache.org/jira/browse/IGNITE-8686 > Project: Ignite > Issue Type: Bug > Components: wizards >Affects Versions: 2.5 >Reporter: Pavel Konstantinov >Priority: Major > Fix For: 2.7 > > Attachments: screenshot-1.png > > > I'm noticed that 'Get started' button on the landing page points to 'signin' > page, but should point to 'signup' page. > !screenshot-1.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-8686) Web console: 'Get started' points to the wrong page
[ https://issues.apache.org/jira/browse/IGNITE-8686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko closed IGNITE-8686. - > Web console: 'Get started' points to the wrong page > --- > > Key: IGNITE-8686 > URL: https://issues.apache.org/jira/browse/IGNITE-8686 > Project: Ignite > Issue Type: Bug > Components: wizards >Affects Versions: 2.5 >Reporter: Pavel Konstantinov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > Attachments: screenshot-1.png > > > I'm noticed that 'Get started' button on the landing page points to 'signin' > page, but should point to 'signup' page. > !screenshot-1.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8493) GridToStringBuilder fails with NPE deals with primitive arrays operations.
[ https://issues.apache.org/jira/browse/IGNITE-8493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16574663#comment-16574663 ] Ryabov Dmitrii commented on IGNITE-8493: [~zstan], thx. Code is ok for me, but I noticed 2 codestyle issues. Please, fix them and then ask Alexey to check PR. > GridToStringBuilder fails with NPE deals with primitive arrays operations. > -- > > Key: IGNITE-8493 > URL: https://issues.apache.org/jira/browse/IGNITE-8493 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.4 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Fix For: 2.7 > > > GridToStringBuilder#arrayToString fails with NPE, if input is a primitive > array. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7460) Web console: revise inputs with step for correct validation
[ https://issues.apache.org/jira/browse/IGNITE-7460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko reassigned IGNITE-7460: - Assignee: Pavel Konstantinov (was: Vasiliy Sisko) > Web console: revise inputs with step for correct validation > --- > > Key: IGNITE-7460 > URL: https://issues.apache.org/jira/browse/IGNITE-7460 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Pavel Konstantinov >Priority: Minor > > For example Cluster-Data storage configuration-Default data region. > 'Eviction threshold' input become invalid if value = 0.89 due to it's step=0.5 > So you need to enter the value multiple of 0.5 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7460) Web console: revise inputs with step for correct validation
[ https://issues.apache.org/jira/browse/IGNITE-7460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16574662#comment-16574662 ] Vasiliy Sisko commented on IGNITE-7460: --- Fixed step for *Eviction threshold* field. > Web console: revise inputs with step for correct validation > --- > > Key: IGNITE-7460 > URL: https://issues.apache.org/jira/browse/IGNITE-7460 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Vasiliy Sisko >Priority: Minor > > For example Cluster-Data storage configuration-Default data region. > 'Eviction threshold' input become invalid if value = 0.89 due to it's step=0.5 > So you need to enter the value multiple of 0.5 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7251) Remove term "fabric" from Ignite deliverables
[
https://issues.apache.org/jira/browse/IGNITE-7251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16574647#comment-16574647
]
ASF GitHub Bot commented on IGNITE-7251:
Github user vveider closed the pull request at:
https://github.com/apache/ignite/pull/3315
> Remove term "fabric" from Ignite deliverables
> -
>
> Key: IGNITE-7251
> URL: https://issues.apache.org/jira/browse/IGNITE-7251
> Project: Ignite
> Issue Type: Task
>Reporter: Denis Magda
>Assignee: Anton Vinogradov
>Priority: Blocker
> Labels: important
> Fix For: 2.7
>
>
> Apache Ignite binary releases still include “fabric” word in their names:
> https://ignite.apache.org/download.cgi#binaries
> For instance, this is a full name of the previous release -
> apache-ignite-fabric-2.3.0-bin.
> It’s a little oversight on our side because the project has not been
> positioned as a fabric for a while.
> Remove “fabric” from the name and have the binary releases named as -
> {{apache-ignite-\{version}-bin}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-1905) High contention for CacheLockImpl causes AssertionErrors
[
https://issues.apache.org/jira/browse/IGNITE-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16574649#comment-16574649
]
Alexey Goncharuk commented on IGNITE-1905:
--
Guys,
I do not like that we synchronize on a field that may be null and also set to a
non-null value during map phase. Is it possible to use the future as the synch
monitor?
> High contention for CacheLockImpl causes AssertionErrors
>
>
> Key: IGNITE-1905
> URL: https://issues.apache.org/jira/browse/IGNITE-1905
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: ignite-1.4
> Environment: Windows 7
>Reporter: Denis Magda
>Assignee: Vitaliy Biryukov
>Priority: Major
> Attachments: ClientTest.java, ServerTest.java
>
>
> When multiple threads, running on the same client node, compete for
> CacheLockImpl this leads to AssertionErrors.
> Pseudo-code snippet, that is called from multiple threads and causes the
> assertions, looks like this:
> {noformat}
> boolean locked = lock.tryLock(100, TimeUnit.MILLISECONDS);
> if (locked)
> lock.unlock();
> {noformat}
> Initially the issue was detected on ignite-1.4.
> In server's node logs the following assertion appears
> {noformat}
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.addOwned(GridDhtLockFuture.java:958)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.map(GridDhtLockFuture.java:918)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.onOwnerChanged(GridDhtLockFuture.java:663)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMvccManager$2.onOwnerChanged(GridCacheMvccManager.java:155)
> at
> org.apache.ignite.internal.processors.cache.distributed.GridDistributedCacheEntry.checkOwnerChanged(GridDistributedCacheEntry.java:810)
> at
> org.apache.ignite.internal.processors.cache.distributed.GridDistributedCacheEntry.readyLock(GridDistributedCacheEntry.java:516)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.readyLocks(GridDhtLockFuture.java:576)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.map(GridDhtLockFuture.java:764)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.lockAllAsync(GridDhtTransactionalCacheAdapter.java:973)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processNearLockRequest(GridDhtTransactionalCacheAdapter.java:557)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.access$000(GridDhtTransactionalCacheAdapter.java:88)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$2.apply(GridDhtTransactionalCacheAdapter.java:132)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$2.apply(GridDhtTransactionalCacheAdapter.java:130)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:580)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:280)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:198)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:77)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:160)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:811)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1500(GridIoManager.java:106)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:774)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
>
> In addition from time to time a client node also outputs a different kind of
> assertion:
> {noformat}
> Exception in thread "ignite-#4%sys-null%" java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.GridCacheExplicitLockSpan.markOwned(GridCacheExplicitLockSpan.java:196)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMvccManager.markExplicitOwner(GridCacheMvccManager.java:862)
> at
>
[jira] [Assigned] (IGNITE-7460) Web console: revise inputs with step for correct validation
[ https://issues.apache.org/jira/browse/IGNITE-7460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko reassigned IGNITE-7460: - Assignee: Vasiliy Sisko > Web console: revise inputs with step for correct validation > --- > > Key: IGNITE-7460 > URL: https://issues.apache.org/jira/browse/IGNITE-7460 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Vasiliy Sisko >Priority: Minor > > For example Cluster-Data storage configuration-Default data region. > 'Eviction threshold' input become invalid if value = 0.89 due to it's step=0.5 > So you need to enter the value multiple of 0.5 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9241) TcpClusterNode.isClient semantic is broken.
[ https://issues.apache.org/jira/browse/IGNITE-9241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-9241: - Description: For now TcpClusterNode.isClient() cal return false is client mode is started with forced server mode. ServerMode is feature of TcpClusterNode (concrete implementation of ClusterNode). We should fix isClient semantic e.g. to use node attributes and introduce separate internal isRingNode() as a part of concrete implementation (not interface) that can be used in TcpDiscoverySpi. Also, seems forceServerMode should be deprecated and ticket for removal should be created. See also [1] discussion on dev list. [1] [http://apache-ignite-developers.2346864.n4.nabble.com/Deprecate-force-server-mode-for-clients-td33614.html] was: For now TcpClusterNode.isClient() cal return false is client mode is started with forced server mode. ServerMode is feature of TcpClusterNode (concrete implementation of ClusterNode). We should fix isClient semantic e.g. to use node attributes and introduce separate internal isRingNode() as a part of concrete implementation (not interface) that can be used in TcpDiscoverySpi. Also, seems forceServerMode should be deprecated [1] [1] http://apache-ignite-developers.2346864.n4.nabble.com/Deprecate-force-server-mode-for-clients-td33614.html > TcpClusterNode.isClient semantic is broken. > --- > > Key: IGNITE-9241 > URL: https://issues.apache.org/jira/browse/IGNITE-9241 > Project: Ignite > Issue Type: Bug >Reporter: Andrew Mashenkov >Priority: Major > Fix For: 2.7 > > > For now TcpClusterNode.isClient() cal return false is client mode is started > with forced server mode. > ServerMode is feature of TcpClusterNode (concrete implementation of > ClusterNode). > We should fix isClient semantic e.g. to use node attributes and introduce > separate internal isRingNode() as a part of concrete implementation (not > interface) that can be used in TcpDiscoverySpi. > Also, seems forceServerMode should be deprecated and ticket for removal > should be created. See also [1] discussion on dev list. > [1] > [http://apache-ignite-developers.2346864.n4.nabble.com/Deprecate-force-server-mode-for-clients-td33614.html] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9225) Cache 7 (With Persistence) configuration halted by failure handler.
[
https://issues.apache.org/jira/browse/IGNITE-9225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16574623#comment-16574623
]
ASF GitHub Bot commented on IGNITE-9225:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4497
> Cache 7 (With Persistence) configuration halted by failure handler.
> ---
>
> Key: IGNITE-9225
> URL: https://issues.apache.org/jira/browse/IGNITE-9225
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Fix For: 2.7
>
>
> WalModeChangeCommonAbstractSelfTest uses default failure handler and can halt
> JVM.
> Example of such failure on TC:
> https://ci.ignite.apache.org/viewLog.html?buildId=1589136=IgniteTests24Java8_Cache7=buildResultsDiv
> Log output:
> {noformat}
> [12:51:02]W: [org.apache.ignite:ignite-core] [2018-08-04
> 09:51:02,859][ERROR][main][root] Test failed.
> [12:51:02]W: [org.apache.ignite:ignite-core]
> junit.framework.AssertionFailedError: Failed to wait for disconnect/reconnect
> event.
> [12:51:02]W: [org.apache.ignite:ignite-core]at
> junit.framework.Assert.fail(Assert.java:57)
> [12:51:02]W: [org.apache.ignite:ignite-core]at
> junit.framework.TestCase.fail(TestCase.java:227)
> [12:51:02]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.IgniteClientReconnectAbstractTest.waitReconnectEvent(IgniteClientReconnectAbstractTest.java:122)
> [12:51:02]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.IgniteClientReconnectAbstractTest.reconnectClientNodes(IgniteClientReconnectAbstractTest.java:314)
> [12:51:02]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.IgniteClientReconnectAbstractTest.reconnectClientNode(IgniteClientReconnectAbstractTest.java:256)
> [12:51:02]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.WalModeChangeAdvancedSelfTest.testClientReconnect(WalModeChangeAdvancedSelfTest.java:350)
> [12:51:02] : [Step 3/4] [2018-08-04 09:51:02,861][INFO ][main][root] >>>
> Stopping test: WalModeChangeAdvancedSelfTest#testClientReconnect in 33858 ms
> <<<
> [12:51:02]W: [org.apache.ignite:ignite-core]at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [12:51:02] : [Step 3/4] [2018-08-04 09:51:02,861][INFO ][main][root] >>>
> Stopping test class: WalModeChangeAdvancedSelfTest <<<
> [12:51:02]W: [org.apache.ignite:ignite-core]at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [12:51:02] : [Step 3/4] [2018-08-04 09:51:02,861][INFO ][main][root] >>>
> Stopping grid [name=cli, id=6481a605-7bfb-486d-a796-2a4f1c8d0469]
> [12:51:02]W: [org.apache.ignite:ignite-core]at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [12:51:02]W: [org.apache.ignite:ignite-core]at
> java.lang.reflect.Method.invoke(Method.java:498)
> [12:51:02]W: [org.apache.ignite:ignite-core]at
> junit.framework.TestCase.runTest(TestCase.java:176)
> [12:51:02]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2156)
> [12:51:02]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:143)
> [12:51:02]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2071)
> [12:51:02]W: [org.apache.ignite:ignite-core]at
> java.lang.Thread.run(Thread.java:748)
> [12:51:03]W: [org.apache.ignite:ignite-core] Aug 04, 2018 9:51:03
> AM org.apache.ignite.logger.java.JavaLogger warning
> [12:51:03]W: [org.apache.ignite:ignite-core] WARNING: Local node
> was dropped from cluster due to network problems, will try to reconnect with
> new id after 1ms (reconnect delay can be changed using
> IGNITE_DISCO_FAILED_CLIENT_RECONNECT_DELAY system property)
> [newId=788c53f8-f985-449a-853e-bf47ed90e388,
> prevId=6481a605-7bfb-486d-a796-2a4f1c8d0469, locNode=TcpDiscoveryNode
> [id=6481a605-7bfb-486d-a796-2a4f1c8d0469, addrs=ArrayList [127.0.0.1],
> sockAddrs=HashSet [/127.0.0.1:0], discPort=0, order=18, intOrder=0,
> lastExchangeTime=1533376229447, loc=true, ver=2.7.0#20180803-sha1:3ab8bbad,
> isClient=true], nodeInitiatedFail=53d116c7-bb4f-43e9-b97c-6d3ce404cd51,
> msg=null]
> [12:51:03]W: [org.apache.ignite:ignite-core] Aug 04, 2018 9:51:03
[jira] [Assigned] (IGNITE-9196) SQL: Memory leak in MapNodeResults
[
https://issues.apache.org/jira/browse/IGNITE-9196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Mekhanikov reassigned IGNITE-9196:
Assignee: Denis Mekhanikov
> SQL: Memory leak in MapNodeResults
> --
>
> Key: IGNITE-9196
> URL: https://issues.apache.org/jira/browse/IGNITE-9196
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.6
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>Priority: Blocker
>
> When size of a SQL query result set is a multiple of {{Query#pageSize}}, then
> {{MapQueryResult}} is never closed and removed from {{MapNodeResults#res}}
> collection.
> The following code leads to OOME when run with 1Gb heap:
> {code:java}
> public class MemLeakRepro {
> public static void main(String[] args) {
> Ignition.start(getConfiguration("server"));
> try (Ignite client =
> Ignition.start(getConfiguration("client").setClientMode(true))) {
> IgniteCache cache = startPeopleCache(client);
> int pages = 10;
> int pageSize = 1024;
> for (int i = 0; i < pages * pageSize; i++) {
> Person p = new Person("Person #" + i, 25);
> cache.put(i, p);
> }
> for (int i = 0; i < 1_000_000; i++) {
> if (i % 1000 == 0)
> System.out.println("Select iteration #" + i);
> Query> qry = new SqlFieldsQuery("select * from
> people");
> qry.setPageSize(pageSize);
> QueryCursor> cursor = cache.query(qry);
> cursor.getAll();
> cursor.close();
> }
> }
> }
> private static IgniteConfiguration getConfiguration(String instanceName) {
> IgniteConfiguration igniteCfg = new IgniteConfiguration();
> igniteCfg.setIgniteInstanceName(instanceName);
> TcpDiscoverySpi discoSpi = new TcpDiscoverySpi();
> discoSpi.setIpFinder(new TcpDiscoveryVmIpFinder(true));
> return igniteCfg;
> }
> private static IgniteCache startPeopleCache(Ignite node)
> {
> CacheConfiguration cacheCfg = new
> CacheConfiguration<>("cache");
> QueryEntity qe = new QueryEntity(Integer.class, Person.class);
> qe.setTableName("people");
> cacheCfg.setQueryEntities(Collections.singleton(qe));
> cacheCfg.setSqlSchema("PUBLIC");
> return node.getOrCreateCache(cacheCfg);
> }
> public static class Person {
> @QuerySqlField
> private String name;
> @QuerySqlField
> private int age;
> public Person(String name, int age) {
> this.name = name;
> this.age = age;
> }
> }
> }
> {code}
>
> At the same time it works perfectly fine, when there are, for example,
> {{pages * pageSize - 1}} records in cache instead.
> The reason for it is that {{MapQueryResult#fetchNextPage(...)}} method
> doesn't return true, when the result set size is a multiple of the page size.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9241) TcpClusterNode.isClient semantic is broken.
Andrew Mashenkov created IGNITE-9241: Summary: TcpClusterNode.isClient semantic is broken. Key: IGNITE-9241 URL: https://issues.apache.org/jira/browse/IGNITE-9241 Project: Ignite Issue Type: Bug Reporter: Andrew Mashenkov Fix For: 2.7 For now TcpClusterNode.isClient() cal return false is client mode is started with forced server mode. ServerMode is feature of TcpClusterNode (concrete implementation of ClusterNode). We should fix isClient semantic e.g. to use node attributes and introduce separate internal isRingNode() as a part of concrete implementation (not interface) that can be used in TcpDiscoverySpi. Also, seems forceServerMode should be deprecated [1] [1] http://apache-ignite-developers.2346864.n4.nabble.com/Deprecate-force-server-mode-for-clients-td33614.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9225) Cache 7 (With Persistence) configuration halted by failure handler.
[
https://issues.apache.org/jira/browse/IGNITE-9225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16574595#comment-16574595
]
Alexey Goncharuk commented on IGNITE-9225:
--
Thanks, merged your changes to master.
> Cache 7 (With Persistence) configuration halted by failure handler.
> ---
>
> Key: IGNITE-9225
> URL: https://issues.apache.org/jira/browse/IGNITE-9225
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Fix For: 2.7
>
>
> WalModeChangeCommonAbstractSelfTest uses default failure handler and can halt
> JVM.
> Example of such failure on TC:
> https://ci.ignite.apache.org/viewLog.html?buildId=1589136=IgniteTests24Java8_Cache7=buildResultsDiv
> Log output:
> {noformat}
> [12:51:02]W: [org.apache.ignite:ignite-core] [2018-08-04
> 09:51:02,859][ERROR][main][root] Test failed.
> [12:51:02]W: [org.apache.ignite:ignite-core]
> junit.framework.AssertionFailedError: Failed to wait for disconnect/reconnect
> event.
> [12:51:02]W: [org.apache.ignite:ignite-core]at
> junit.framework.Assert.fail(Assert.java:57)
> [12:51:02]W: [org.apache.ignite:ignite-core]at
> junit.framework.TestCase.fail(TestCase.java:227)
> [12:51:02]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.IgniteClientReconnectAbstractTest.waitReconnectEvent(IgniteClientReconnectAbstractTest.java:122)
> [12:51:02]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.IgniteClientReconnectAbstractTest.reconnectClientNodes(IgniteClientReconnectAbstractTest.java:314)
> [12:51:02]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.IgniteClientReconnectAbstractTest.reconnectClientNode(IgniteClientReconnectAbstractTest.java:256)
> [12:51:02]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.WalModeChangeAdvancedSelfTest.testClientReconnect(WalModeChangeAdvancedSelfTest.java:350)
> [12:51:02] : [Step 3/4] [2018-08-04 09:51:02,861][INFO ][main][root] >>>
> Stopping test: WalModeChangeAdvancedSelfTest#testClientReconnect in 33858 ms
> <<<
> [12:51:02]W: [org.apache.ignite:ignite-core]at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [12:51:02] : [Step 3/4] [2018-08-04 09:51:02,861][INFO ][main][root] >>>
> Stopping test class: WalModeChangeAdvancedSelfTest <<<
> [12:51:02]W: [org.apache.ignite:ignite-core]at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [12:51:02] : [Step 3/4] [2018-08-04 09:51:02,861][INFO ][main][root] >>>
> Stopping grid [name=cli, id=6481a605-7bfb-486d-a796-2a4f1c8d0469]
> [12:51:02]W: [org.apache.ignite:ignite-core]at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [12:51:02]W: [org.apache.ignite:ignite-core]at
> java.lang.reflect.Method.invoke(Method.java:498)
> [12:51:02]W: [org.apache.ignite:ignite-core]at
> junit.framework.TestCase.runTest(TestCase.java:176)
> [12:51:02]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2156)
> [12:51:02]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:143)
> [12:51:02]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2071)
> [12:51:02]W: [org.apache.ignite:ignite-core]at
> java.lang.Thread.run(Thread.java:748)
> [12:51:03]W: [org.apache.ignite:ignite-core] Aug 04, 2018 9:51:03
> AM org.apache.ignite.logger.java.JavaLogger warning
> [12:51:03]W: [org.apache.ignite:ignite-core] WARNING: Local node
> was dropped from cluster due to network problems, will try to reconnect with
> new id after 1ms (reconnect delay can be changed using
> IGNITE_DISCO_FAILED_CLIENT_RECONNECT_DELAY system property)
> [newId=788c53f8-f985-449a-853e-bf47ed90e388,
> prevId=6481a605-7bfb-486d-a796-2a4f1c8d0469, locNode=TcpDiscoveryNode
> [id=6481a605-7bfb-486d-a796-2a4f1c8d0469, addrs=ArrayList [127.0.0.1],
> sockAddrs=HashSet [/127.0.0.1:0], discPort=0, order=18, intOrder=0,
> lastExchangeTime=1533376229447, loc=true, ver=2.7.0#20180803-sha1:3ab8bbad,
> isClient=true], nodeInitiatedFail=53d116c7-bb4f-43e9-b97c-6d3ce404cd51,
> msg=null]
> [12:51:03]W: [org.apache.ignite:ignite-core] Aug 04, 2018 9:51:03
> AM org.apache.ignite.logger.java.JavaLogger info
>
[jira] [Commented] (IGNITE-5103) TcpDiscoverySpi ignores maxMissedClientHeartbeats property
[
https://issues.apache.org/jira/browse/IGNITE-5103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16574588#comment-16574588
]
Evgenii Zhuravlev commented on IGNITE-5103:
---
[~akalashnikov], thank you for review. I've fixed tests from this suite by
increasing clientFailureDetectionTimeout for these tests and some additional
changes for certain tests:
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Spi_IgniteTests24Java8=pull%2F4446%2Fhead=buildTypeStatusDiv
> TcpDiscoverySpi ignores maxMissedClientHeartbeats property
> --
>
> Key: IGNITE-5103
> URL: https://issues.apache.org/jira/browse/IGNITE-5103
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.9
>Reporter: Valentin Kulichenko
>Assignee: Evgenii Zhuravlev
>Priority: Blocker
> Fix For: 2.7
>
> Attachments: TcpDiscoveryClientSuspensionSelfTest.java
>
>
> Test scenario is the following:
> * Start one or more servers.
> * Start a client node.
> * Suspend client process using {{-SIGSTOP}} signal.
> * Wait for {{maxMissedClientHeartbeats*heartbeatFrequency}}.
> * Client node is expected to be removed from topology, but server nodes don't
> do that.
> Attached is the unit test reproducing the same by stopping the heartbeat
> sender thread on the client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9240) Web console: plus sign not clickable on low resolution
Stepan Pilschikov created IGNITE-9240: - Summary: Web console: plus sign not clickable on low resolution Key: IGNITE-9240 URL: https://issues.apache.org/jira/browse/IGNITE-9240 Project: Ignite Issue Type: Bug Components: wizards Reporter: Stepan Pilschikov Attachments: image-2018-08-09-12-37-13-907.png path: /configuration/advanced/clusters Binary configuration panel On resolution less then 960px plus sign in Type configurations going under parent element and becoming not clickable Also this behavior correct for others configuration elements except addresses !image-2018-08-09-12-37-13-907.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9239) [ML] KMeansTrainer crashed if amount of possible clusters more than amount of partitions in dataset
Aleksey Zinoviev created IGNITE-9239: Summary: [ML] KMeansTrainer crashed if amount of possible clusters more than amount of partitions in dataset Key: IGNITE-9239 URL: https://issues.apache.org/jira/browse/IGNITE-9239 Project: Ignite Issue Type: Bug Components: ml Reporter: Aleksey Zinoviev Assignee: Aleksey Zinoviev How to reproduce? Set the K parameter in KMeans Trainer to 100, and run KMeansClusterization Example \ StackTrace is Exception in thread "KMeansClusterizationExample-#44" java.lang.RuntimeException: java.lang.IllegalArgumentException: bound must be positive at org.apache.ignite.ml.clustering.kmeans.KMeansTrainer.fit(KMeansTrainer.java:112) at org.apache.ignite.ml.clustering.kmeans.KMeansTrainer.fit(KMeansTrainer.java:46) at org.apache.ignite.ml.trainers.DatasetTrainer.fit(DatasetTrainer.java:68) at org.apache.ignite.examples.ml.clustering.KMeansClusterizationExample.lambda$main$0(KMeansClusterizationExample.java:60) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.IllegalArgumentException: bound must be positive at java.util.Random.nextInt(Random.java:388) at org.apache.ignite.ml.clustering.kmeans.KMeansTrainer.initClusterCentersRandomly(KMeansTrainer.java:193) at org.apache.ignite.ml.clustering.kmeans.KMeansTrainer.fit(KMeansTrainer.java:86) ... 4 more The possible solution : correct the mechanism of rndPnts computation in the row 180-190 in KMeansTrainer -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8888) Possible data loss durring restaring of the nodes with empty pds
[ https://issues.apache.org/jira/browse/IGNITE-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16574476#comment-16574476 ] Anton Kalashnikov commented on IGNITE-: --- Now tests also looks good. It can be merged. > Possible data loss durring restaring of the nodes with empty pds > > > Key: IGNITE- > URL: https://issues.apache.org/jira/browse/IGNITE- > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.4 >Reporter: Andrey Aleksandrov >Assignee: Alexey Stelmak >Priority: Major > Fix For: 2.7 > > Attachments: reproducer.java > > > Case: > 1)Start 3 data nodes and activate the cluster with cache with 1 backup and > PartitionLossPolicy.READ_ONLY_SAFE. > 2)Start client and add the data to your cache. Stop the client > 3)Stop DN2 and clear it pds and val > 4)Start DN2. Rebalance will start. > 5)During rebalance stop DN3. > 6)Start DN3. > At this moment some partitions from DN2 marked as LOST and cache size will be > less than expected. > 7) Run resetLostPartitions(caches). > Now all partitions on DN2 marked as OWNING but cache size is still less than > expected. > Workaround: > after step 6 do: > 7)force rebalance using deactivate/activate methods. > 8)wait for completion of rebalance > Now cache size is expected but some partitions from DN2 marked as LOST > 9)Run resetLostPartitions(caches). > Now cache size is OK and all partitions from DN2 marked as OWNING. > However, looks like without force rebalance we have data loss here. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9004) Failed to reinitialize local partitions
[
https://issues.apache.org/jira/browse/IGNITE-9004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16574474#comment-16574474
]
Anton Kalashnikov commented on IGNITE-9004:
---
Note: After merge this changes, two grids on one persistence will not be
allowed.
> Failed to reinitialize local partitions
> ---
>
> Key: IGNITE-9004
> URL: https://issues.apache.org/jira/browse/IGNITE-9004
> Project: Ignite
> Issue Type: Test
>Reporter: Anton Kalashnikov
>Assignee: Eduard Shangareev
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> Reproduced by Activate/Deactivate suit, almost any tests in
> IgniteChangeGlobalStateTest class. for example
> IgniteChangeGlobalStateTest#testStopPrimaryAndActivateFromClientNode
> {noformat}
> Failed to reinitialize local partitions (preloading will be stopped):
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=6,
> minorTopVer=1], discoEvt=DiscoveryCustomEvent
> [customMsg=ChangeGlobalStateMessage
> [id=9093c48a461-165cdacd-8a3b-4072-9f48-e80e1b63fda9,
> reqId=07393ea5-1c6a-4581-b016-9eb88d6bd978,
> initiatingNodeId=8dced5ba-725d-494b-8e8e-ffc76453fecd, activate=true,
> baselineTopology=BaselineTopology [id=0, branchingHash=314980173,
> branchingType='Cluster activation', baselineNodes=[node2, node0, node1]],
> forceChangeBaselineTopology=false, timestamp=1531832492029],
> affTopVer=AffinityTopologyVersion [topVer=6, minorTopVer=1],
> super=DiscoveryEvent [evtNode=TcpDiscoveryNode
> [id=8dced5ba-725d-494b-8e8e-ffc76453fecd, addrs=[0:0:0:0:0:0:0:1%lo,
> 127.0.0.1, 172.25.4.132], sockAddrs=[/172.25.4.132:47504,
> /0:0:0:0:0:0:0:1%lo:47504, /127.0.0.1:47504], discPort=47504, order=2,
> intOrder=2, lastExchangeTime=1531832486546, loc=false,
> ver=2.7.0#19700101-sha1:, isClient=false], topVer=6,
> nodeId8=9960f6b9, msg=null, type=DISCOVERY_CUSTOM_EVT,
> tstamp=1531832492035]], nodeId=8dced5ba, evt=DISCOVERY_CUSTOM_EVT]
> java.lang.AssertionError: calculatedOffset=3072, allocated=2048,
> headerSize=1024
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.read(FilePageStore.java:358)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:400)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:384)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:783)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:627)
> at
> org.apache.ignite.internal.processors.cache.persistence.DataStructure.acquirePage(DataStructure.java:144)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.init(PagesList.java:169)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.AbstractFreeList.(AbstractFreeList.java:371)
> at
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage$FreeListImpl.(MetaStorage.java:484)
> at
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage.init(MetaStorage.java:143)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readCheckpointAndRestoreMemory(GridCacheDatabaseSharedManager.java:852)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest(GridDhtPartitionsExchangeFuture.java:954)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:661)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2484)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2364)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Given:
> # Activated Node1-1 in grid1.
> # MetaStorage on node1-1 in OffHeap.
> # MetaStorage have not storage on disk yet.
> When:
> # Checkpoint on node1-1 is starting. Start checkpoint marker was written.
> # node2-1 in grid2 is starting.(grid1 and grid2 have same persistence)
> Then:
> # node2-1 found expected checkpoint marker("Found unexpected checkpoint
> marker") and initialize FilePageStore for metaStorage by empty page
> # node1-1 finished checkpoint and wrote MetaStorage on disk.
> # After stop grid1 and activate grid2 node2-1 was failed because try read
> more than one page.
> Possible
[jira] [Resolved] (IGNITE-6538) Ignite Activate/Deactivate Cluster suite: After tests validation improvements test became flaky on TC
[
https://issues.apache.org/jira/browse/IGNITE-6538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Kalashnikov resolved IGNITE-6538.
---
Resolution: Duplicate
> Ignite Activate/Deactivate Cluster suite: After tests validation improvements
> test became flaky on TC
> -
>
> Key: IGNITE-6538
> URL: https://issues.apache.org/jira/browse/IGNITE-6538
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Priority: Blocker
> Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.7
>
>
> https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=-238119157387028099=testDetails_Ignite20Tests=%3Cdefault%3E
> {code}
> [14:36:09]W: [org.apache.ignite:ignite-core] [2018-05-22
> 11:36:09,817][WARN
> ][exchange-worker-#202059%node1-backUp%][GridDhtPartitionsExchangeFuture]
> Unable to await partitions release latch within timeout: ClientLatch
> [coordinator=TcpDiscoveryNode [id=ba7f90d8-3a1f-488a-a8ea-3ae2fdf016fe,
> addrs=[127.0.0.1, 172.17.0.7], sockAddrs=[/127.0.0.1:47503,
> d377975c5791/172.17.0.7:47503], discPort=47503, order=1, intOrder=1,
> lastExchangeTime=1526985998704, loc=false, ver=2.5.0#20180522-sha1:d37470c7,
> isClient=false], ackSent=true, super=CompletableLatch [id=exchange,
> topVer=AffinityTopologyVersion [topVer=6, minorTopVer=1]]]
> {code}
> Fail test:
> {code}
> org.apache.ignite.internal.processors.cache.persistence.standbycluster.IgniteChangeGlobalStateTest#testActivateAfterFailGetLock
> {code}
> Fail test 2:
> {noformat}
> IgniteChangeGlobalStateTest#testConcurrentActivateFromClientNodeAndServerNode
> {noformat}
> As result of the test there is page corruption in metastorage:
> {noformat}
> [org.apache.ignite:ignite-core] java.lang.AssertionError:
> calculatedOffset=3072, allocated=2048, headerSize=1024
> [13:46:39]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.read(FilePageStore.java:346)
> [13:46:39]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:341)
> [13:46:39]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:325)
> [13:46:39]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:779)
> [13:46:39]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:624)
> [13:46:39]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.persistence.DataStructure.acquirePage(DataStructure.java:142)
> [13:46:39]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.init(PagesList.java:167)
> [13:46:39]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.persistence.freelist.AbstractFreeList.(AbstractFreeList.java:370)
> [13:46:39]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage$FreeListImpl.(MetaStorage.java:472)
> [13:46:39]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage.init(MetaStorage.java:139)
> [13:46:39]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readCheckpointAndRestoreMemory(GridCacheDatabaseSharedManager.java:808)
> [13:46:39]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest(GridDhtPartitionsExchangeFuture.java:901)
> [13:46:39]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:648)
> [13:46:39]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2452)
> [13:46:39]W: [org.apache.ignite:ignite-core]at
>
[jira] [Commented] (IGNITE-9004) Failed to reinitialize local partitions
[
https://issues.apache.org/jira/browse/IGNITE-9004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16574469#comment-16574469
]
Anton Kalashnikov commented on IGNITE-9004:
---
Looks good for me. It can be merged.
> Failed to reinitialize local partitions
> ---
>
> Key: IGNITE-9004
> URL: https://issues.apache.org/jira/browse/IGNITE-9004
> Project: Ignite
> Issue Type: Test
>Reporter: Anton Kalashnikov
>Assignee: Eduard Shangareev
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> Reproduced by Activate/Deactivate suit, almost any tests in
> IgniteChangeGlobalStateTest class. for example
> IgniteChangeGlobalStateTest#testStopPrimaryAndActivateFromClientNode
> {noformat}
> Failed to reinitialize local partitions (preloading will be stopped):
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=6,
> minorTopVer=1], discoEvt=DiscoveryCustomEvent
> [customMsg=ChangeGlobalStateMessage
> [id=9093c48a461-165cdacd-8a3b-4072-9f48-e80e1b63fda9,
> reqId=07393ea5-1c6a-4581-b016-9eb88d6bd978,
> initiatingNodeId=8dced5ba-725d-494b-8e8e-ffc76453fecd, activate=true,
> baselineTopology=BaselineTopology [id=0, branchingHash=314980173,
> branchingType='Cluster activation', baselineNodes=[node2, node0, node1]],
> forceChangeBaselineTopology=false, timestamp=1531832492029],
> affTopVer=AffinityTopologyVersion [topVer=6, minorTopVer=1],
> super=DiscoveryEvent [evtNode=TcpDiscoveryNode
> [id=8dced5ba-725d-494b-8e8e-ffc76453fecd, addrs=[0:0:0:0:0:0:0:1%lo,
> 127.0.0.1, 172.25.4.132], sockAddrs=[/172.25.4.132:47504,
> /0:0:0:0:0:0:0:1%lo:47504, /127.0.0.1:47504], discPort=47504, order=2,
> intOrder=2, lastExchangeTime=1531832486546, loc=false,
> ver=2.7.0#19700101-sha1:, isClient=false], topVer=6,
> nodeId8=9960f6b9, msg=null, type=DISCOVERY_CUSTOM_EVT,
> tstamp=1531832492035]], nodeId=8dced5ba, evt=DISCOVERY_CUSTOM_EVT]
> java.lang.AssertionError: calculatedOffset=3072, allocated=2048,
> headerSize=1024
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.read(FilePageStore.java:358)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:400)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:384)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:783)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:627)
> at
> org.apache.ignite.internal.processors.cache.persistence.DataStructure.acquirePage(DataStructure.java:144)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.init(PagesList.java:169)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.AbstractFreeList.(AbstractFreeList.java:371)
> at
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage$FreeListImpl.(MetaStorage.java:484)
> at
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage.init(MetaStorage.java:143)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readCheckpointAndRestoreMemory(GridCacheDatabaseSharedManager.java:852)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest(GridDhtPartitionsExchangeFuture.java:954)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:661)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2484)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2364)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Given:
> # Activated Node1-1 in grid1.
> # MetaStorage on node1-1 in OffHeap.
> # MetaStorage have not storage on disk yet.
> When:
> # Checkpoint on node1-1 is starting. Start checkpoint marker was written.
> # node2-1 in grid2 is starting.(grid1 and grid2 have same persistence)
> Then:
> # node2-1 found expected checkpoint marker("Found unexpected checkpoint
> marker") and initialize FilePageStore for metaStorage by empty page
> # node1-1 finished checkpoint and wrote MetaStorage on disk.
> # After stop grid1 and activate grid2 node2-1 was failed because try read
> more than one page.
> Possible solution:
> * We can skip initialization
[jira] [Commented] (IGNITE-7339) RENTING partition is not evicted after restore from storage
[ https://issues.apache.org/jira/browse/IGNITE-7339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16574466#comment-16574466 ] Alexei Scherbakov commented on IGNITE-7339: --- [~Jokser], I've made fixes you recommended. TC looks acceptable, pls take a look. > RENTING partition is not evicted after restore from storage > --- > > Key: IGNITE-7339 > URL: https://issues.apache.org/jira/browse/IGNITE-7339 > Project: Ignite > Issue Type: Bug >Reporter: Semen Boikov >Assignee: Alexei Scherbakov >Priority: Critical > > If partition was in RENTING state at the moment when node is stopped, then > after restart it is not evicted. > It seems it is an issue in GridDhtLocalPartition.rent, 'tryEvictAsync' is not > called is partition was already in RENTING state. > Also there is error in GridDhtPartitionTopologyImpl.checkEvictions: partition > state is always treated as changed after part.rent call even if part.rent > does not actually change state. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8714) CacheEntryEvent.getOldValue should be available
[ https://issues.apache.org/jira/browse/IGNITE-8714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16574431#comment-16574431 ] ASF GitHub Bot commented on IGNITE-8714: Github user NSAmelchev closed the pull request at: https://github.com/apache/ignite/pull/4313 > CacheEntryEvent.getOldValue should be available > --- > > Key: IGNITE-8714 > URL: https://issues.apache.org/jira/browse/IGNITE-8714 > Project: Ignite > Issue Type: Sub-task >Reporter: Alexander Menshikov >Assignee: Amelchev Nikita >Priority: Major > Labels: iep-21 > Fix For: 2.7 > > > A table is copied from speck changing discussion: > When CacheEntryListenerConfiguration#isOldValueRequired is *true*: > ||CacheEntryEvent Method||CreatedListener||UpdatedListener||Removed/Expired > Listener|| > |getValue()|_value_|_value_|_oldValue_| > |getOldValue()|null|_oldValue_|_oldValue_| > The last column is new behavior for #getValue(). > Сurrent master fails with this reason on following tests: > * CacheListenerTest.testFilteredListener > * CacheListenerTest.testCacheEntryListener > I have to say tests testFilteredListener and testCacheEntryListener also fail > in `afterTests` section because of IGNITE-8715, so PR will not change the > number of failed tests if ignite-8715 unfixed. But it will change the reason > – please see the log. > Please see also link on JCache TCK and speck 1.1.0 changes. > > *UPD:* > There are a lot of our tests wich going to break by this change. Also, we use > events in Services deployment, which will be affected too. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7024) Introduce some kind of network compression
[ https://issues.apache.org/jira/browse/IGNITE-7024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16574429#comment-16574429 ] ASF GitHub Bot commented on IGNITE-7024: Github user NSAmelchev closed the pull request at: https://github.com/apache/ignite/pull/3815 > Introduce some kind of network compression > -- > > Key: IGNITE-7024 > URL: https://issues.apache.org/jira/browse/IGNITE-7024 > Project: Ignite > Issue Type: New Feature >Affects Versions: 2.3 >Reporter: Amelchev Nikita >Assignee: Amelchev Nikita >Priority: Major > Fix For: 2.7 > > > Introduce some kind of pluggable compression at network level > The main idea is using in-line compression and writes encoded bytes in > network channel by bytes array buffer. It allows us avoiding expensive > memory allocation. > A solution may be implemented at TcpCommunicationSpi level. > For example, introduce Compressor interface which will allow us to describe > our compression strategy, for example, exclude some small messages, choose > compression algorithm and other… -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8493) GridToStringBuilder fails with NPE deals with primitive arrays operations.
[ https://issues.apache.org/jira/browse/IGNITE-8493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16574400#comment-16574400 ] Stanilovsky Evgeny commented on IGNITE-8493: yep, i see that conflict was due to partially commit of previous code. Plz take a look ones more. > GridToStringBuilder fails with NPE deals with primitive arrays operations. > -- > > Key: IGNITE-8493 > URL: https://issues.apache.org/jira/browse/IGNITE-8493 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.4 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Fix For: 2.7 > > > GridToStringBuilder#arrayToString fails with NPE, if input is a primitive > array. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8493) GridToStringBuilder fails with NPE deals with primitive arrays operations.
[ https://issues.apache.org/jira/browse/IGNITE-8493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16574391#comment-16574391 ] ASF GitHub Bot commented on IGNITE-8493: GitHub user zstan opened a pull request: https://github.com/apache/ignite/pull/4501 IGNITE-8493 GridToStringBuilder arrayToString refactoring. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-8493 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4501.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 #4501 commit 05438f8fed26e2b0dac34349062b8c10f96fabad Author: Evgeny Stanilovskiy Date: 2018-08-09T07:22:37Z IGNITE-8493 GridToStringBuilder arrayToString refactoring. > GridToStringBuilder fails with NPE deals with primitive arrays operations. > -- > > Key: IGNITE-8493 > URL: https://issues.apache.org/jira/browse/IGNITE-8493 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.4 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Fix For: 2.7 > > > GridToStringBuilder#arrayToString fails with NPE, if input is a primitive > array. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8493) GridToStringBuilder fails with NPE deals with primitive arrays operations.
[ https://issues.apache.org/jira/browse/IGNITE-8493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16574386#comment-16574386 ] ASF GitHub Bot commented on IGNITE-8493: Github user zstan closed the pull request at: https://github.com/apache/ignite/pull/3999 > GridToStringBuilder fails with NPE deals with primitive arrays operations. > -- > > Key: IGNITE-8493 > URL: https://issues.apache.org/jira/browse/IGNITE-8493 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.4 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Fix For: 2.7 > > > GridToStringBuilder#arrayToString fails with NPE, if input is a primitive > array. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
