[jira] [Created] (IGNITE-7760) Handle FS hangs
Alexander Belyak created IGNITE-7760: Summary: Handle FS hangs Key: IGNITE-7760 URL: https://issues.apache.org/jira/browse/IGNITE-7760 Project: Ignite Issue Type: Improvement Components: general Affects Versions: 2.2, 2.1, 2.0, 1.9, 1.8, 1.7, 1.6 Reporter: Alexander Belyak Need to handle FS operations hangs, for example - copy WAL into wal archive (specially if wal archive mount as network file system volume). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7744) OPTION_LIBS environment variable is not picked up
[ https://issues.apache.org/jira/browse/IGNITE-7744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-7744: Priority: Critical (was: Blocker) > OPTION_LIBS environment variable is not picked up > - > > Key: IGNITE-7744 > URL: https://issues.apache.org/jira/browse/IGNITE-7744 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Stéphane Thibaud >Priority: Critical > > When starting the Ignite docker container using `docker run -d --net=host -e > OPTION_LIBS=ignite-gce -e CONFIG_URI=secret_url ignite`, the container stops > immediately and the logs mention that the ignite-gce library was not loaded > correctly: > ``` > class org.apache.ignite.IgniteException: Failed to instantiate Spring XML > application context (make sure all classes used in Spring configuration are > present at CLASSPATH) > [springUrl=https://storage.googleapis.com/ignite-discovery/default-config.xml] > at > org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:966) > at org.apache.ignite.Ignition.start(Ignition.java:350) at > org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:302) > Caused by: class org.apache.ignite.IgniteCheckedException: Failed to > instantiate Spring XML application context (make sure all classes used in > Spring configuration are present at CLASSPATH) > [springUrl=https://storage.googleapis.com/ignite-discovery/default-config.xml] > at > org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.applicationContext(IgniteSpringHelperImpl.java:387) > at > org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.loadConfigurations(IgniteSpringHelperImpl.java:104) > at > org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.loadConfigurations(IgniteSpringHelperImpl.java:98) > at > org.apache.ignite.internal.IgnitionEx.loadConfigurations(IgnitionEx.java:673) > at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:874) at > org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:783) at > org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:653) at > org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:622) at > org.apache.ignite.Ignition.start(Ignition.java:347) ... 1 more Caused by: > org.springframework.beans.factory.BeanCreationException: Error creating bean > with name 'org.apache.ignite.configuration.IgniteConfiguration#0' defined in > URL [https://storage.googleapis.com/ignite-discovery/default-config.xml]: > Cannot create inner bean > 'org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi#1f021e6c' of type > [org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi] while setting bean > property 'discoverySpi'; nested exception is > org.springframework.beans.factory.BeanCreationException: Error creating bean > with name 'org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi#1f021e6c' > defined in URL > [https://storage.googleapis.com/ignite-discovery/default-config.xml]: Cannot > create inner bean > 'org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder#68ceda24' > of type > [org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder] > while setting bean property 'ipFinder'; nested exception is > org.springframework.beans.factory.BeanCreationException: Error creating bean > with name > 'org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder#68ceda24' > defined in URL > [https://storage.googleapis.com/ignite-discovery/default-config.xml]: > Instantiation of bean failed; nested exception is > org.springframework.beans.BeanInstantiationException: Failed to instantiate > [org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder]: > No default constructor found; nested exception is > java.lang.NoClassDefFoundError: > com/google/api/client/http/AbstractInputStreamContent at > org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveInnerBean(BeanDefinitionValueResolver.java:313) > at > org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:122) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1531) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1276) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:553) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:483) > at > org.
[jira] [Created] (IGNITE-7759) Logger does not print sockTimeout and ackTimeout default values for TcpDiscoverySpi
Roman Guseinov created IGNITE-7759: -- Summary: Logger does not print sockTimeout and ackTimeout default values for TcpDiscoverySpi Key: IGNITE-7759 URL: https://issues.apache.org/jira/browse/IGNITE-7759 Project: Ignite Issue Type: Bug Affects Versions: 2.3, 2.1, 1.9 Reporter: Roman Guseinov Logger does not print sockTimeout and ackTimeout default values for TcpDiscoverySpi Before starting TcpDiscoverySpi logger prints the following message (debug mode is enabled): {code:java} [main][GridDiscoveryManager] Starting SPI: TcpDiscoverySpi [addrRslvr=null, sockTimeout=0, ackTimeout=0, marsh=JdkMarshaller [clsFilter=org.apache.ignite.internal.IgniteKernal$5@402e37bc], reconCnt=10, reconDelay=2000, maxAckTimeout=60, forceSrvMode=false, clientReconnectDisabled=false] {code} Note, that sockTimeout=0 and ackTimeout=0. Default values initializing happens after TcpDiscoverySpi.spiStart is called: {code:java} public class TcpDiscoverySpi extends IgniteSpiAdapter implements DiscoverySpi { /** Node attribute that is mapped to node's external addresses (value is disc.tcp.ext-addrs). */ /** {@inheritDoc} */ @Override public void spiStart(@Nullable String igniteInstanceName) throws IgniteSpiException { initializeImpl(); } /** * */ private void initializeImpl() { if (impl != null) return; initFailureDetectionTimeout(); if (!forceSrvMode && (Boolean.TRUE.equals(ignite.configuration().isClientMode( { if (ackTimeout == 0) ackTimeout = DFLT_ACK_TIMEOUT_CLIENT; if (sockTimeout == 0) sockTimeout = DFLT_SOCK_TIMEOUT_CLIENT; impl = new ClientImpl(this); ctxInitLatch.countDown(); } else { if (ackTimeout == 0) ackTimeout = DFLT_ACK_TIMEOUT; if (sockTimeout == 0) sockTimeout = DFLT_SOCK_TIMEOUT; impl = new ServerImpl(this); } } } {code} To avoid confusion I suggest printing default sockTimeout and ackTimeout if they weren't changed like: {code:java} [main][GridDiscoveryManager] Starting SPI: TcpDiscoverySpi [addrRslvr=null, sockTimeout=5000, ackTimeout=5000, marsh=JdkMarshaller [clsFilter=org.apache.ignite.internal.IgniteKernal$5@402e37bc], reconCnt=10, reconDelay=2000, maxAckTimeout=60, forceSrvMode=false, clientReconnectDisabled=false] {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-3345) Implement support for optional key type in REST HTTP get command
[ https://issues.apache.org/jira/browse/IGNITE-3345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16369693#comment-16369693 ] Alexey Kuznetsov commented on IGNITE-3345: -- Added support for Java built in types for put/get operations via "keyType" and "valueType" optional parameters. List of supported types: * java.lang.Boolean (with alias boolean) * java.lang.Byte (with alias byte) * java.lang.Short (with alias short) * java.lang.Integer (with aliases int, integer) * java.lang.Long (with alias long) * java.lang.Float (with alias float) * java.lang.Double (with alias double) * java.sql.Date (with alias date) * java.sql.Time (with alias time) * java.sql.Timestamp (with alias timestamp) * java.util.UUUID (with alias uuid) * org.apache.ignite.lang.IgniteUuid (with alias IgniteUuid) For Date, Time, Timestamp value should be in format as specified in *valueOf(String)* methods of corresponding classes. Example for date: "2018-01-01" see [https://docs.oracle.com/javase/8/docs/api/java/sql/Date.html#valueOf-java.lang.String-] Example for time: "01:01:01" see [https://docs.oracle.com/javase/8/docs/api/java/sql/Time.html#valueOf-java.lang.String-] Example for timestamp: "2018-02-18%2001:01:01" see [https://docs.oracle.com/javase/8/docs/api/java/sql/Timestamp.html#valueOf-java.lang.String-] > Implement support for optional key type in REST HTTP get command > > > Key: IGNITE-3345 > URL: https://issues.apache.org/jira/browse/IGNITE-3345 > Project: Ignite > Issue Type: Task > Components: cache, rest >Affects Versions: 1.6 >Reporter: Alexey Kuznetsov >Assignee: Pavel Konstantinov >Priority: Major > Fix For: 2.5 > > > It seems that in current implementation > (https://apacheignite.readme.io/docs/rest-api#get) > GET command could work only with String keys. > We can add optional parameter "keyType" and implement support for common > built-in types such as Integer, Long, UUID,... and user classes that a valid > JavaBeans. > Sample: http://host:port/ignite?cmd=get&key=1&cacheName=myCache&keyType=Long -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-3345) Implement support for optional key type in REST HTTP get command
[ https://issues.apache.org/jira/browse/IGNITE-3345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-3345: Resolution: Fixed Assignee: Pavel Konstantinov (was: Alexey Kuznetsov) Merged to master. > Implement support for optional key type in REST HTTP get command > > > Key: IGNITE-3345 > URL: https://issues.apache.org/jira/browse/IGNITE-3345 > Project: Ignite > Issue Type: Task > Components: cache, rest >Affects Versions: 1.6 >Reporter: Alexey Kuznetsov >Assignee: Pavel Konstantinov >Priority: Major > Fix For: 2.5 > > > It seems that in current implementation > (https://apacheignite.readme.io/docs/rest-api#get) > GET command could work only with String keys. > We can add optional parameter "keyType" and implement support for common > built-in types such as Integer, Long, UUID,... and user classes that a valid > JavaBeans. > Sample: http://host:port/ignite?cmd=get&key=1&cacheName=myCache&keyType=Long -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7725) REST: expand parameters list of GetOrCreateCache command
[ https://issues.apache.org/jira/browse/IGNITE-7725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16369689#comment-16369689 ] Alexey Kuznetsov commented on IGNITE-7725: -- [~dmagda] I created issue IGNITE-7758 to update docs. > REST: expand parameters list of GetOrCreateCache command > > > Key: IGNITE-7725 > URL: https://issues.apache.org/jira/browse/IGNITE-7725 > Project: Ignite > Issue Type: Improvement > Components: rest >Affects Versions: 2.3 >Reporter: Alexey Kuznetsov >Assignee: Pavel Konstantinov >Priority: Major > Fix For: 2.5 > > > Current implementation is very primitive and do not allow to create caches > with custom options via REST. > http://host:port/ignite?cmd=getorcreate&cacheName=cache_name[&tempaleName=template_name][&backups=1][&writeSynchronizationMode=FULL_SYNC][&; > other options] > Ignite will support two pre-configured templates out of the box: PARTITIONED > and REPLICATED (same as SQL engine). > If template name is not specified, by default it will be PARTITIONED. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7758) Update REST documentation
[ https://issues.apache.org/jira/browse/IGNITE-7758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-7758: - Description: RETS documentation need to be updated: # GET_OR_CREATE_CACHE enhanced command with optional "templateName", "backups", "cacheGroup", "dataRegion" and "writeSynchronizationMode" options. # Added support for Java built in types for put/get operations via "keyType" and "valueType" optional parameters. List of supported types: * java.lang.Boolean (with alias boolean) * java.lang.Byte (with alias byte) * java.lang.Short (with alias short) * java.lang.Integer (with aliases int, integer) * java.lang.Long (with alias long) * java.lang.Float (with alias float) * java.lang.Double (with alias double) * java.sql.Date (with alias date) * java.sql.Time (with alias time) * java.sql.Timestamp (with alias timestamp) * java.util.UUUID (with alias uuid) * org.apache.ignite.lang.IgniteUuid (with alias IgniteUuid) For Date, Time, Timestamp value should be in format as specified in *valueOf(String)* methods of corresponding classes. Example for date: "2018-01-01" see https://docs.oracle.com/javase/8/docs/api/java/sql/Date.html#valueOf-java.lang.String- Example for time: "01:01:01" see https://docs.oracle.com/javase/8/docs/api/java/sql/Time.html#valueOf-java.lang.String- Example for timestamp: "2018-02-18%2001:01:01" see https://docs.oracle.com/javase/8/docs/api/java/sql/Timestamp.html#valueOf-java.lang.String- was: RETS documentation need to be updated: # GET_OR_CREATE_CACHE enhanced command with optional "templateName", "backups", "cacheGroup", "dataRegion" and "writeSynchronizationMode" options. # Added support for Java built in types for put/get operations via "keyType" and "valueType" optional parameters. List of supported types: > Update REST documentation > - > > Key: IGNITE-7758 > URL: https://issues.apache.org/jira/browse/IGNITE-7758 > Project: Ignite > Issue Type: Task > Components: documentation >Affects Versions: 2.5 >Reporter: Alexey Kuznetsov >Assignee: Denis Magda >Priority: Major > Fix For: 2.5 > > > RETS documentation need to be updated: > # GET_OR_CREATE_CACHE enhanced command with optional "templateName", > "backups", "cacheGroup", "dataRegion" and "writeSynchronizationMode" options. > # Added support for Java built in types for put/get operations via > "keyType" and "valueType" optional parameters. List of supported types: > * java.lang.Boolean (with alias boolean) > * java.lang.Byte (with alias byte) > * java.lang.Short (with alias short) > * java.lang.Integer (with aliases int, integer) > * java.lang.Long (with alias long) > * java.lang.Float (with alias float) > * java.lang.Double (with alias double) > * java.sql.Date (with alias date) > * java.sql.Time (with alias time) > * java.sql.Timestamp (with alias timestamp) > * java.util.UUUID (with alias uuid) > * org.apache.ignite.lang.IgniteUuid (with alias IgniteUuid) > For Date, Time, Timestamp value should be in format as specified in > *valueOf(String)* methods of corresponding classes. > Example for date: "2018-01-01" see > https://docs.oracle.com/javase/8/docs/api/java/sql/Date.html#valueOf-java.lang.String- > Example for time: "01:01:01" see > https://docs.oracle.com/javase/8/docs/api/java/sql/Time.html#valueOf-java.lang.String- > Example for timestamp: "2018-02-18%2001:01:01" see > https://docs.oracle.com/javase/8/docs/api/java/sql/Timestamp.html#valueOf-java.lang.String- > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7729) Add usage of Roles for Web Console E2E tests
[ https://issues.apache.org/jira/browse/IGNITE-7729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16369687#comment-16369687 ] Ilya Borisov commented on IGNITE-7729: -- [~alexdel] I left several review comments in upsource. > Add usage of Roles for Web Console E2E tests > > > Key: IGNITE-7729 > URL: https://issues.apache.org/jira/browse/IGNITE-7729 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Alexander Kalinin >Assignee: Ilya Borisov >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7758) Update REST documentation
Alexey Kuznetsov created IGNITE-7758: Summary: Update REST documentation Key: IGNITE-7758 URL: https://issues.apache.org/jira/browse/IGNITE-7758 Project: Ignite Issue Type: Task Components: documentation Affects Versions: 2.5 Reporter: Alexey Kuznetsov Assignee: Denis Magda Fix For: 2.5 RETS documentation need to be updated: # GET_OR_CREATE_CACHE enhanced command with optional "templateName", "backups", "cacheGroup", "dataRegion" and "writeSynchronizationMode" options. # Added support for Java built in types for put/get operations via "keyType" and "valueType" optional parameters. List of supported types: -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-7725) REST: expand parameters list of GetOrCreateCache command
[ https://issues.apache.org/jira/browse/IGNITE-7725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov resolved IGNITE-7725. -- Resolution: Fixed Assignee: Pavel Konstantinov (was: Alexey Kuznetsov) Merged to master. > REST: expand parameters list of GetOrCreateCache command > > > Key: IGNITE-7725 > URL: https://issues.apache.org/jira/browse/IGNITE-7725 > Project: Ignite > Issue Type: Improvement > Components: rest >Affects Versions: 2.3 >Reporter: Alexey Kuznetsov >Assignee: Pavel Konstantinov >Priority: Major > Fix For: 2.5 > > > Current implementation is very primitive and do not allow to create caches > with custom options via REST. > http://host:port/ignite?cmd=getorcreate&cacheName=cache_name[&tempaleName=template_name][&backups=1][&writeSynchronizationMode=FULL_SYNC][&; > other options] > Ignite will support two pre-configured templates out of the box: PARTITIONED > and REPLICATED (same as SQL engine). > If template name is not specified, by default it will be PARTITIONED. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7696) Deadlock at GridDhtAtomicCache.lockEntries called through GridDhtAtomicCache.updateAllAsyncInternal
[ https://issues.apache.org/jira/browse/IGNITE-7696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16369680#comment-16369680 ] Roman Shtykh commented on IGNITE-7696: -- [~frsyuki] I suggest you provide cluster configuration details and raise attention to the issue in the ml. > Deadlock at GridDhtAtomicCache.lockEntries called through > GridDhtAtomicCache.updateAllAsyncInternal > --- > > Key: IGNITE-7696 > URL: https://issues.apache.org/jira/browse/IGNITE-7696 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.3 > Environment: * Ignite 2.3 > * OpenJDK version "1.8.0_151" > * Linux 4.4.0 >Reporter: Sadayuki Furuhashi >Priority: Major > > We observed that all nodes in a cluster completely stalls and put/get/remove > operations to a cache block for ever. When it happens, we can see following > log in thread dump: > {code} > 2018-02-14_04:21:33.84410 Found one Java-level deadlock: > 2018-02-14_04:21:33.84410 = > 2018-02-14_04:21:33.84411 "sys-#41%IgniteManager%": > 2018-02-14_04:21:33.84411 waiting to lock monitor 0x7f6d5e41a558 > (object 0x000781083ef0, a > org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry), > 2018-02-14_04:21:33.84411 which is held by "sys-stripe-5-#6%IgniteManager%" > 2018-02-14_04:21:33.84412 "sys-stripe-5-#6%IgniteManager%": > 2018-02-14_04:21:33.84412 waiting to lock monitor 0x7f6d5e41de68 > (object 0x000781083e70, a > org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry) > 2018-02-14_04:21:33.84412 in JNI, which is held by > "sys-stripe-2-#3%IgniteManager%" > 2018-02-14_04:21:33.84412 "sys-stripe-2-#3%IgniteManager%": > 2018-02-14_04:21:33.84413 waiting to lock monitor 0x7f6d5e41a558 > (object 0x000781083ef0, a > org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry) > 2018-02-14_04:21:33.84413 in JNI, which is held by > "sys-stripe-5-#6%IgniteManager%" > 2018-02-14_04:21:33.84413 > 2018-02-14_04:21:33.84414 Java stack information for the threads listed above: > 2018-02-14_04:21:33.84414 === > 2018-02-14_04:21:33.84416 "sys-#41%IgniteManager%": > 2018-02-14_04:21:33.84416 at > org.apache.ignite.internal.processors.cache.GridCacheMapEntry.markObsoleteVersion(GridCacheMapEntry.java:2153) > 2018-02-14_04:21:33.84417 - waiting to lock <0x000781083ef0> (a > org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry) > 2018-02-14_04:21:33.84417 at > org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.removeVersionedEntry(GridDhtLocalPartition.java:368) > 2018-02-14_04:21:33.84418 at > org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.cleanupRemoveQueue(GridDhtLocalPartition.java:392) > 2018-02-14_04:21:33.84418 at > org.apache.ignite.internal.processors.cache.GridCacheProcessor$RemovedItemsCleanupTask$1.run(GridCacheProcessor.java:4051) > 2018-02-14_04:21:33.84418 at > org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6687) > 2018-02-14_04:21:33.84419 at > org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827) > 2018-02-14_04:21:33.84419 at > org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) > 2018-02-14_04:21:33.84419 at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > 2018-02-14_04:21:33.84420 at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > 2018-02-14_04:21:33.84421 at java.lang.Thread.run(Thread.java:748) > 2018-02-14_04:21:33.84421 "sys-stripe-5-#6%IgniteManager%": > 2018-02-14_04:21:33.84421 at sun.misc.Unsafe.monitorEnter(Native Method) > 2018-02-14_04:21:33.84421 at > org.apache.ignite.internal.util.GridUnsafe.monitorEnter(GridUnsafe.java:1207) > 2018-02-14_04:21:33.84422 at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.lockEntries(GridDhtAtomicCache.java:2848) > 2018-02-14_04:21:33.84422 at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1707) > 2018-02-14_04:21:33.84423 at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1629) > 2018-02-14_04:21:33.84423 at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:305
[jira] [Commented] (IGNITE-7725) REST: expand parameters list of GetOrCreateCache command
[ https://issues.apache.org/jira/browse/IGNITE-7725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16369678#comment-16369678 ] Alexey Kuznetsov commented on IGNITE-7725: -- No, other options are SQL specific. > REST: expand parameters list of GetOrCreateCache command > > > Key: IGNITE-7725 > URL: https://issues.apache.org/jira/browse/IGNITE-7725 > Project: Ignite > Issue Type: Improvement > Components: rest >Affects Versions: 2.3 >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.5 > > > Current implementation is very primitive and do not allow to create caches > with custom options via REST. > http://host:port/ignite?cmd=getorcreate&cacheName=cache_name[&tempaleName=template_name][&backups=1][&writeSynchronizationMode=FULL_SYNC][&; > other options] > Ignite will support two pre-configured templates out of the box: PARTITIONED > and REPLICATED (same as SQL engine). > If template name is not specified, by default it will be PARTITIONED. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-7650) Web Console: Rework signin page.
[ https://issues.apache.org/jira/browse/IGNITE-7650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Novikov closed IGNITE-7650. -- > Web Console: Rework signin page. > > > Key: IGNITE-7650 > URL: https://issues.apache.org/jira/browse/IGNITE-7650 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Alexander Kalinin >Assignee: Andrey Novikov >Priority: Major > Fix For: 2.5 > > > * Extract signin/signup form to separated page. > * Implement landing page, signin/signup page as components. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7650) Web Console: Rework signin page.
[ https://issues.apache.org/jira/browse/IGNITE-7650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Novikov reassigned IGNITE-7650: -- Resolution: Fixed Assignee: Andrey Novikov (was: Alexey Kuznetsov) > Web Console: Rework signin page. > > > Key: IGNITE-7650 > URL: https://issues.apache.org/jira/browse/IGNITE-7650 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Alexander Kalinin >Assignee: Andrey Novikov >Priority: Major > Fix For: 2.5 > > > * Extract signin/signup form to separated page. > * Implement landing page, signin/signup page as components. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7650) Web Console: Rework signin page.
[ https://issues.apache.org/jira/browse/IGNITE-7650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16369677#comment-16369677 ] Andrey Novikov commented on IGNITE-7650: Reviewed. Merged to master > Web Console: Rework signin page. > > > Key: IGNITE-7650 > URL: https://issues.apache.org/jira/browse/IGNITE-7650 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Alexander Kalinin >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.5 > > > * Extract signin/signup form to separated page. > * Implement landing page, signin/signup page as components. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7725) REST: expand parameters list of GetOrCreateCache command
[ https://issues.apache.org/jira/browse/IGNITE-7725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16369674#comment-16369674 ] Pavel Konstantinov edited comment on IGNITE-7725 at 2/20/18 3:22 AM: - Ignite documentation describes some others optional parameters for 'create table' query. Please refer to https://apacheignite-sql.readme.io/docs/create-table Should we add support for it as well? If NO then it can be merged. was (Author: pkonstantinov): Ignite documentation describes some others optional parameters for 'create table' query. Please refer to https://apacheignite-sql.readme.io/docs/create-table Should we add support for it as well? > REST: expand parameters list of GetOrCreateCache command > > > Key: IGNITE-7725 > URL: https://issues.apache.org/jira/browse/IGNITE-7725 > Project: Ignite > Issue Type: Improvement > Components: rest >Affects Versions: 2.3 >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.5 > > > Current implementation is very primitive and do not allow to create caches > with custom options via REST. > http://host:port/ignite?cmd=getorcreate&cacheName=cache_name[&tempaleName=template_name][&backups=1][&writeSynchronizationMode=FULL_SYNC][&; > other options] > Ignite will support two pre-configured templates out of the box: PARTITIONED > and REPLICATED (same as SQL engine). > If template name is not specified, by default it will be PARTITIONED. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7725) REST: expand parameters list of GetOrCreateCache command
[ https://issues.apache.org/jira/browse/IGNITE-7725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16369674#comment-16369674 ] Pavel Konstantinov commented on IGNITE-7725: Ignite documentation describes some others optional parameters for 'create table' query. Please refer to https://apacheignite-sql.readme.io/docs/create-table Should we add support for it as well? > REST: expand parameters list of GetOrCreateCache command > > > Key: IGNITE-7725 > URL: https://issues.apache.org/jira/browse/IGNITE-7725 > Project: Ignite > Issue Type: Improvement > Components: rest >Affects Versions: 2.3 >Reporter: Alexey Kuznetsov >Assignee: Pavel Konstantinov >Priority: Major > Fix For: 2.5 > > > Current implementation is very primitive and do not allow to create caches > with custom options via REST. > http://host:port/ignite?cmd=getorcreate&cacheName=cache_name[&tempaleName=template_name][&backups=1][&writeSynchronizationMode=FULL_SYNC][&; > other options] > Ignite will support two pre-configured templates out of the box: PARTITIONED > and REPLICATED (same as SQL engine). > If template name is not specified, by default it will be PARTITIONED. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7725) REST: expand parameters list of GetOrCreateCache command
[ https://issues.apache.org/jira/browse/IGNITE-7725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov reassigned IGNITE-7725: -- Assignee: Alexey Kuznetsov (was: Pavel Konstantinov) > REST: expand parameters list of GetOrCreateCache command > > > Key: IGNITE-7725 > URL: https://issues.apache.org/jira/browse/IGNITE-7725 > Project: Ignite > Issue Type: Improvement > Components: rest >Affects Versions: 2.3 >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.5 > > > Current implementation is very primitive and do not allow to create caches > with custom options via REST. > http://host:port/ignite?cmd=getorcreate&cacheName=cache_name[&tempaleName=template_name][&backups=1][&writeSynchronizationMode=FULL_SYNC][&; > other options] > Ignite will support two pre-configured templates out of the box: PARTITIONED > and REPLICATED (same as SQL engine). > If template name is not specified, by default it will be PARTITIONED. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7650) Web Console: Rework signin page.
[ https://issues.apache.org/jira/browse/IGNITE-7650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16369671#comment-16369671 ] Alexander Kalinin commented on IGNITE-7650: --- [~anovikov] Tests fixed. Please update ticket. > Web Console: Rework signin page. > > > Key: IGNITE-7650 > URL: https://issues.apache.org/jira/browse/IGNITE-7650 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Alexander Kalinin >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.5 > > > * Extract signin/signup form to separated page. > * Implement landing page, signin/signup page as components. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7757) Unable to create a new cache via REST in special case
[ https://issues.apache.org/jira/browse/IGNITE-7757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-7757: - Summary: Unable to create a new cache via REST in special case (was: Unable to create a new cache via REST) > Unable to create a new cache via REST in special case > - > > Key: IGNITE-7757 > URL: https://issues.apache.org/jira/browse/IGNITE-7757 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Konstantinov >Priority: Major > > 1. try to start a new cache with non-existing data region > {code} > localhost:8080/ignite?cmd=getorcreate&cacheName=cache1&dataRegion= > {code} > You will get correct error message > {code} > "Failed to handle request: [req=GET_OR_CREATE_CACHE, err=Requested DataRegion > is not configured: ]" > {code} > 2. then edit your request and make it correct and try again > {code} > localhost:8080/ignite?cmd=getorcreate&cacheName=cache1 > {code} > You will get the same error message > {code} > "Failed to handle request: [req=GET_OR_CREATE_CACHE, err=Requested DataRegion > is not configured: ]" > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7757) Unable to create a new cache via REST
[ https://issues.apache.org/jira/browse/IGNITE-7757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov updated IGNITE-7757: --- Description: 1. try to start a new cache with non-existing data region {code} localhost:8080/ignite?cmd=getorcreate&cacheName=cache1&dataRegion= {code} You will get correct error message {code} "Failed to handle request: [req=GET_OR_CREATE_CACHE, err=Requested DataRegion is not configured: ]" {code} 2. then edit your request and make it correct and try again {code} localhost:8080/ignite?cmd=getorcreate&cacheName=cache1 {code} You will get the same error message {code} "Failed to handle request: [req=GET_OR_CREATE_CACHE, err=Requested DataRegion is not configured: ]" {code} was: # try to start a new cache with non-existing data region {code} localhost:8080/ignite?cmd=getorcreate&cacheName=cache1&dataRegion= {code} You will get correct error message {code} "Failed to handle request: [req=GET_OR_CREATE_CACHE, err=Requested DataRegion is not configured: ]" {code} # then edit your request and make it correct and try again {code} localhost:8080/ignite?cmd=getorcreate&cacheName=cache1 {code} You will get the same error message {code} "Failed to handle request: [req=GET_OR_CREATE_CACHE, err=Requested DataRegion is not configured: ]" {code} > Unable to create a new cache via REST > - > > Key: IGNITE-7757 > URL: https://issues.apache.org/jira/browse/IGNITE-7757 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Konstantinov >Priority: Major > > 1. try to start a new cache with non-existing data region > {code} > localhost:8080/ignite?cmd=getorcreate&cacheName=cache1&dataRegion= > {code} > You will get correct error message > {code} > "Failed to handle request: [req=GET_OR_CREATE_CACHE, err=Requested DataRegion > is not configured: ]" > {code} > 2. then edit your request and make it correct and try again > {code} > localhost:8080/ignite?cmd=getorcreate&cacheName=cache1 > {code} > You will get the same error message > {code} > "Failed to handle request: [req=GET_OR_CREATE_CACHE, err=Requested DataRegion > is not configured: ]" > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7757) Unable to create a new cache via REST
[ https://issues.apache.org/jira/browse/IGNITE-7757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov updated IGNITE-7757: --- Description: # try to start a new cache with non-existing data region {code} localhost:8080/ignite?cmd=getorcreate&cacheName=cache1&dataRegion= {code} You will get correct error message {code} "Failed to handle request: [req=GET_OR_CREATE_CACHE, err=Requested DataRegion is not configured: ]" {code} # then edit your request and make it correct and try again {code} localhost:8080/ignite?cmd=getorcreate&cacheName=cache1 {code} You will get the same error message {code} "Failed to handle request: [req=GET_OR_CREATE_CACHE, err=Requested DataRegion is not configured: ]" {code} was: # try to start a new cache with non-existing data region {code} localhost:8080/ignite?cmd=getorcreate&cacheName=cache1&dataRegion= {code} # then edit your request and make it correct and try again {code} localhost:8080/ignite?cmd=getorcreate&cacheName=cache1 {code} You will get incorrect error message {code} "Failed to handle request: [req=GET_OR_CREATE_CACHE, err=Requested DataRegion is not configured: ]" {code} > Unable to create a new cache via REST > - > > Key: IGNITE-7757 > URL: https://issues.apache.org/jira/browse/IGNITE-7757 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Konstantinov >Priority: Major > > # try to start a new cache with non-existing data region > {code} > localhost:8080/ignite?cmd=getorcreate&cacheName=cache1&dataRegion= > {code} > You will get correct error message > {code} > "Failed to handle request: [req=GET_OR_CREATE_CACHE, err=Requested DataRegion > is not configured: ]" > {code} > # then edit your request and make it correct and try again > {code} > localhost:8080/ignite?cmd=getorcreate&cacheName=cache1 > {code} > You will get the same error message > {code} > "Failed to handle request: [req=GET_OR_CREATE_CACHE, err=Requested DataRegion > is not configured: ]" > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7757) Unable to create a new cache via REST
[ https://issues.apache.org/jira/browse/IGNITE-7757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov updated IGNITE-7757: --- Description: # try to start a new cache with non-existing data region {code} localhost:8080/ignite?cmd=getorcreate&cacheName=cache1&dataRegion= {code} # then edit your request and make it correct and try again {code} localhost:8080/ignite?cmd=getorcreate&cacheName=cache1 {code} You will get incorrect error message {code} "Failed to handle request: [req=GET_OR_CREATE_CACHE, err=Requested DataRegion is not configured: ]" {code} was: # try to start a new cache with non-existing cache group name {code} localhost:8080/ignite?cmd=getorcreate&cacheName=cache1&cacheGroup= {code} # then edit your request and make it correct and try again {code} localhost:8080/ignite?cmd=getorcreate&cacheName=cache1 {code} > Unable to create a new cache via REST > - > > Key: IGNITE-7757 > URL: https://issues.apache.org/jira/browse/IGNITE-7757 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Konstantinov >Priority: Major > > # try to start a new cache with non-existing data region > {code} > localhost:8080/ignite?cmd=getorcreate&cacheName=cache1&dataRegion= > {code} > # then edit your request and make it correct and try again > {code} > localhost:8080/ignite?cmd=getorcreate&cacheName=cache1 > {code} > You will get incorrect error message > {code} > "Failed to handle request: [req=GET_OR_CREATE_CACHE, err=Requested DataRegion > is not configured: ]" > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7757) Unable to create a new cache via REST
Pavel Konstantinov created IGNITE-7757: -- Summary: Unable to create a new cache via REST Key: IGNITE-7757 URL: https://issues.apache.org/jira/browse/IGNITE-7757 Project: Ignite Issue Type: Bug Reporter: Pavel Konstantinov # try to start a new cache with non-existing cache group name {code} localhost:8080/ignite?cmd=getorcreate&cacheName=cache1&cacheGroup= {code} # then edit your request and make it correct and try again {code} localhost:8080/ignite?cmd=getorcreate&cacheName=cache1 {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-3345) Implement support for optional key type in REST HTTP get command
[ https://issues.apache.org/jira/browse/IGNITE-3345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16369665#comment-16369665 ] Pavel Konstantinov commented on IGNITE-3345: Re-tested. > Implement support for optional key type in REST HTTP get command > > > Key: IGNITE-3345 > URL: https://issues.apache.org/jira/browse/IGNITE-3345 > Project: Ignite > Issue Type: Task > Components: cache, rest >Affects Versions: 1.6 >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.5 > > > It seems that in current implementation > (https://apacheignite.readme.io/docs/rest-api#get) > GET command could work only with String keys. > We can add optional parameter "keyType" and implement support for common > built-in types such as Integer, Long, UUID,... and user classes that a valid > JavaBeans. > Sample: http://host:port/ignite?cmd=get&key=1&cacheName=myCache&keyType=Long -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7744) OPTION_LIBS environment variable is not picked up
[ https://issues.apache.org/jira/browse/IGNITE-7744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stéphane Thibaud updated IGNITE-7744: - Summary: OPTION_LIBS environment variable is not picked up (was: OPTIONAL_LIBS environment variable is not picked up) > OPTION_LIBS environment variable is not picked up > - > > Key: IGNITE-7744 > URL: https://issues.apache.org/jira/browse/IGNITE-7744 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Stéphane Thibaud >Priority: Blocker > > When starting the Ignite docker container using `docker run -d --net=host -e > OPTION_LIBS=ignite-gce -e CONFIG_URI=secret_url ignite`, the container stops > immediately and the logs mention that the ignite-gce library was not loaded > correctly: > ``` > class org.apache.ignite.IgniteException: Failed to instantiate Spring XML > application context (make sure all classes used in Spring configuration are > present at CLASSPATH) > [springUrl=https://storage.googleapis.com/ignite-discovery/default-config.xml] > at > org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:966) > at org.apache.ignite.Ignition.start(Ignition.java:350) at > org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:302) > Caused by: class org.apache.ignite.IgniteCheckedException: Failed to > instantiate Spring XML application context (make sure all classes used in > Spring configuration are present at CLASSPATH) > [springUrl=https://storage.googleapis.com/ignite-discovery/default-config.xml] > at > org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.applicationContext(IgniteSpringHelperImpl.java:387) > at > org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.loadConfigurations(IgniteSpringHelperImpl.java:104) > at > org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.loadConfigurations(IgniteSpringHelperImpl.java:98) > at > org.apache.ignite.internal.IgnitionEx.loadConfigurations(IgnitionEx.java:673) > at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:874) at > org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:783) at > org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:653) at > org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:622) at > org.apache.ignite.Ignition.start(Ignition.java:347) ... 1 more Caused by: > org.springframework.beans.factory.BeanCreationException: Error creating bean > with name 'org.apache.ignite.configuration.IgniteConfiguration#0' defined in > URL [https://storage.googleapis.com/ignite-discovery/default-config.xml]: > Cannot create inner bean > 'org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi#1f021e6c' of type > [org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi] while setting bean > property 'discoverySpi'; nested exception is > org.springframework.beans.factory.BeanCreationException: Error creating bean > with name 'org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi#1f021e6c' > defined in URL > [https://storage.googleapis.com/ignite-discovery/default-config.xml]: Cannot > create inner bean > 'org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder#68ceda24' > of type > [org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder] > while setting bean property 'ipFinder'; nested exception is > org.springframework.beans.factory.BeanCreationException: Error creating bean > with name > 'org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder#68ceda24' > defined in URL > [https://storage.googleapis.com/ignite-discovery/default-config.xml]: > Instantiation of bean failed; nested exception is > org.springframework.beans.BeanInstantiationException: Failed to instantiate > [org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder]: > No default constructor found; nested exception is > java.lang.NoClassDefFoundError: > com/google/api/client/http/AbstractInputStreamContent at > org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveInnerBean(BeanDefinitionValueResolver.java:313) > at > org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:122) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1531) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1276) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:553) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBea
[jira] [Created] (IGNITE-7756) Streamer fails if IgniteUuid is indexed
Nikolay Izhikov created IGNITE-7756: --- Summary: Streamer fails if IgniteUuid is indexed Key: IGNITE-7756 URL: https://issues.apache.org/jira/browse/IGNITE-7756 Project: Ignite Issue Type: Bug Components: streaming Affects Versions: 2.3 Reporter: Nikolay Izhikov Assignee: Nikolay Izhikov Fix For: 2.5 IgniteDataStreamer are failed to put data to the cache if IgniteUuid is IndexedType. Spark tests in IGNITE-7227 are failed because of this issue. Reproducer: {code:java} public void testStreamer() throws Exception { Ignite client = grid("client"); CacheConfiguration ccfg = new CacheConfiguration("UUID_CACHE"); ccfg.setIndexedTypes(IgniteUuid.class, String.class); client.createCache(ccfg); try(IgniteDataStreamer cache = client.dataStreamer("UUID_CACHE")) { for(Integer i=0; i<2; i++) cache.addData(IgniteUuid.randomUuid(), i.toString()); } } {code} Exception stack trace: {noformat} [23:43:35] (err) Failed to execute compound future reducer: GridCompoundFuture [rdc=null, initFlag=1, lsnrCalls=0, done=false, cancelled=false, err=null, futs=[true, true]][23:43:35] (err) Failed to execute compound future reducer: GridCompoundFuture [rdc=null, initFlag=1, lsnrCalls=0, done=false, cancelled=false, err=null, futs=[true, true]]class org.apache.ignite.IgniteCheckedException: DataStreamer request failed [node=57961924-82ec-4d56-81eb-1a4109a0] at org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$Buffer.onResponse(DataStreamerImpl.java:1900) at org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$3.onMessage(DataStreamerImpl.java:344) at org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1554) at org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1182) at org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125) at org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1089) at org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:499) at java.lang.Thread.run(Thread.java:748) Caused by: class org.apache.ignite.IgniteException: Failed to set initial value for cache entry at org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$IsolatedUpdater.receive(DataStreamerImpl.java:2135) at org.apache.ignite.internal.processors.datastreamer.DataStreamerUpdateJob.call(DataStreamerUpdateJob.java:140) at org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.localUpdate(DataStreamProcessor.java:397) at org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.processRequest(DataStreamProcessor.java:302) at org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.access$000(DataStreamProcessor.java:59) at org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor$1.onMessage(DataStreamProcessor.java:89) ... 6 more Caused by: class org.apache.ignite.IgniteCheckedException: Failed to update index, incorrect key class [expCls=org.apache.ignite.lang.IgniteUuid, actualCls=org.apache.ignite.internal.binary.BinaryObjectImpl] at org.apache.ignite.internal.processors.query.GridQueryProcessor.typeByValue(GridQueryProcessor.java:1954) at org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:1877) at org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:403) at org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishUpdate(IgniteCacheOffheapManagerImpl.java:1343) at org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1207) at org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:345) at org.apache.ignite.internal.processors.cache.GridCacheMapEntry.storeValue(GridCacheMapEntry.java:3527) at org.apache.ignite.internal.processors.cache.GridCacheMapEntry.initialValue(GridCacheMapEntry.java:2735) at org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$IsolatedUpdater.receive(DataStreamerImpl.java:2113) ... 11 more class org.apache.ignite.IgniteCheckedException: DataStreamer request failed [node=57961924-82ec-4d56-81eb-1a4109a0] at org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$Buffer.onResponse(DataStreamerImpl.java:1900) at org
[jira] [Commented] (IGNITE-6842) Stop all nodes after test by default.
[ https://issues.apache.org/jira/browse/IGNITE-6842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16369470#comment-16369470 ] ASF GitHub Bot commented on IGNITE-6842: GitHub user Mmuzaf opened a pull request: https://github.com/apache/ignite/pull/3542 IGNITE-6842 Test PR for learning contributing processes. - Remove duplicated code stopGrid methods; - Add stopAllGridsSilently method throwing exception in case stop grids fails; - Make stopGrids default behavior for afterTestsStopped; You can merge this pull request into a Git repository by running: $ git pull https://github.com/Mmuzaf/ignite ignite-6842 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/3542.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 #3542 commit 40f9c158e226942a02a22673637e593a28096496 Author: Maxim Muzafarov Date: 2018-02-18T14:29:55Z IGNITE-6842: make stopAllGrids as default behavior for afterTestsStop commit 18248091903a0d44e292eb2502f0c40a18abd3cd Author: Maxim Muzafarov Date: 2018-02-19T09:25:52Z IGNITE-6842:add stopAllGridsSilently as default stop grid commit b18d9aadc6613c9f5c48e7b2cec2b53ed385c994 Author: Maxim Muzafarov Date: 2018-02-19T09:26:21Z Merge branch 'master' of https://github.com/apache/ignite into ignite-6842 > Stop all nodes after test by default. > - > > Key: IGNITE-6842 > URL: https://issues.apache.org/jira/browse/IGNITE-6842 > Project: Ignite > Issue Type: Improvement >Reporter: Alexei Scherbakov >Assignee: Maxim Muzafarov >Priority: Major > Labels: newbie > Fix For: 2.5 > > > Currently it's required to manually call stopAllGrids() after test completion. > This leads to errors in subsequent tests if someone forgets to call it and to > additional boilerplate code in tests. > Right choice is to make this default behavior. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7655) Spark Data Frames: saving data frames into Ignite needs to be documented
[ https://issues.apache.org/jira/browse/IGNITE-7655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov reassigned IGNITE-7655: --- Assignee: Denis Magda (was: Nikolay Izhikov) > Spark Data Frames: saving data frames into Ignite needs to be documented > > > Key: IGNITE-7655 > URL: https://issues.apache.org/jira/browse/IGNITE-7655 > Project: Ignite > Issue Type: Bug > Components: spark >Reporter: Nikolay Izhikov >Assignee: Denis Magda >Priority: Major > Fix For: 2.4 > > > Once IGNITE-7337 is ready for merge. > This new feature of Ignite needs to be documented. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7648) Revert IGNITE_ENABLE_FORCIBLE_NODE_KILL system property.
[ https://issues.apache.org/jira/browse/IGNITE-7648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16369323#comment-16369323 ] Igor Seliverstov commented on IGNITE-7648: -- [~ascherbakov], the code looks OK, but I'd change {code:java} long delay = failureDetectionTimeoutEnabled() ? failureDetectionTimeout() / reconCnt : connTimeout0 - (U.currentTimeMillis() - start); {code} To something like: {code:java} long delay = failureDetectionTimeoutEnabled() ? timeoutHelper.remainingTime(U.currentTimeMillis()) / (reconCnt - attempt) : connTimeout0 - (U.currentTimeMillis() - start);{code} In {{org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi#createTcpClient}} Also I'm not sure is it a good idea to enable force kill by default. Lets consider next example: We successfully joined the topology but due to some local issue cannot open a direct connection to any node via Communication SPI. This way using your approach we will kill each node we try to send a message to. Even in current shape IGNITE_ENABLE_FORCIBLE_NODE_KILL doesn't look like a production feature and, in my opinion, cannot be used by default. > Revert IGNITE_ENABLE_FORCIBLE_NODE_KILL system property. > > > Key: IGNITE-7648 > URL: https://issues.apache.org/jira/browse/IGNITE-7648 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Alexei Scherbakov >Assignee: Alexei Scherbakov >Priority: Major > Fix For: 2.5 > > > IGNITE_ENABLE_FORCIBLE_NODE_KILL system property was introduced in > IGNITE-5718 as a way to prevent unnecessary node drops in case of short > network problems. > I suppose it's wrong decision to fix it in such way. > We had faced some issues in our production due to lack of automatic kicking > of ill-behaving nodes (on example, hanging due to long GC pauses) until we > realised the necessity of changing default behavior via property. > Right solution is to kick nodes only if failure threshold is reached. Such > behavior should be always enabled. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7742) AssertionError in IgniteCacheOffheapManagerImpl when Iterate Cache with expire policy and persistence
[ https://issues.apache.org/jira/browse/IGNITE-7742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16369312#comment-16369312 ] Sergey Kosarev commented on IGNITE-7742: Test update added case for cahe.get() from remote node - it causes AssertionError on remote node and hanging up of waiting thread. > AssertionError in IgniteCacheOffheapManagerImpl when Iterate Cache with > expire policy and persistence > - > > Key: IGNITE-7742 > URL: https://issues.apache.org/jira/browse/IGNITE-7742 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.4 >Reporter: Sergey Kosarev >Priority: Major > Attachments: IgniteDbExpirePolicyTest.java > > > Some assertions were added in IGNITE-6423 > One of them fires here. > We check for > assert > cctx.shared().database().checkpointLockIsHeldByThread(); > but we don't have this lock > {code:java} > java.lang.AssertionError > at > org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:1372) > at > org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.remove(GridCacheOffheapManager.java:1364) > at > org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:370) > at > org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:3602) > at > org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onExpired(GridCacheMapEntry.java:3355) > at > org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:421) > at > org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:369) > at > org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.advance(GridCacheQueryManager.java:3043) > at > org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.onHasNext(GridCacheQueryManager.java:2999) > at > org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53) > at > org.apache.ignite.internal.processors.cache.CacheWeakQueryIteratorsHolder$WeakQueryCloseableIterator.onHasNext(CacheWeakQueryIteratorsHolder.java:308) > at > org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53) > at > org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45) > at > org.apache.ignite.internal.processors.database.IgniteDbExpireTest.testIterators(IgniteDbExpireTest.java:132) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at junit.framework.TestCase.runTest(TestCase.java:176) > at > org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2001) > at > org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133) > at > org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1916) > at java.lang.Thread.run(Thread.java:748){code} > Simple test fails > [^IgniteDbExpirePolicyTest.java] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7742) AssertionError in IgniteCacheOffheapManagerImpl when Iterate Cache with expire policy and persistence
[ https://issues.apache.org/jira/browse/IGNITE-7742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16369312#comment-16369312 ] Sergey Kosarev edited comment on IGNITE-7742 at 2/19/18 4:52 PM: - Test update added case for cache.get() from remote node - it causes AssertionError on remote node and hanging up of waiting thread. was (Author: macrergate): Test update added case for cahe.get() from remote node - it causes AssertionError on remote node and hanging up of waiting thread. > AssertionError in IgniteCacheOffheapManagerImpl when Iterate Cache with > expire policy and persistence > - > > Key: IGNITE-7742 > URL: https://issues.apache.org/jira/browse/IGNITE-7742 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.4 >Reporter: Sergey Kosarev >Priority: Major > Attachments: IgniteDbExpirePolicyTest.java > > > Some assertions were added in IGNITE-6423 > One of them fires here. > We check for > assert > cctx.shared().database().checkpointLockIsHeldByThread(); > but we don't have this lock > {code:java} > java.lang.AssertionError > at > org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:1372) > at > org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.remove(GridCacheOffheapManager.java:1364) > at > org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:370) > at > org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:3602) > at > org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onExpired(GridCacheMapEntry.java:3355) > at > org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:421) > at > org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:369) > at > org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.advance(GridCacheQueryManager.java:3043) > at > org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.onHasNext(GridCacheQueryManager.java:2999) > at > org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53) > at > org.apache.ignite.internal.processors.cache.CacheWeakQueryIteratorsHolder$WeakQueryCloseableIterator.onHasNext(CacheWeakQueryIteratorsHolder.java:308) > at > org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53) > at > org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45) > at > org.apache.ignite.internal.processors.database.IgniteDbExpireTest.testIterators(IgniteDbExpireTest.java:132) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at junit.framework.TestCase.runTest(TestCase.java:176) > at > org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2001) > at > org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133) > at > org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1916) > at java.lang.Thread.run(Thread.java:748){code} > Simple test fails > [^IgniteDbExpirePolicyTest.java] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7742) AssertionError in IgniteCacheOffheapManagerImpl when Iterate Cache with expire policy and persistence
[ https://issues.apache.org/jira/browse/IGNITE-7742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Kosarev updated IGNITE-7742: --- Attachment: (was: IgniteDbExpirePolicyTest.java) > AssertionError in IgniteCacheOffheapManagerImpl when Iterate Cache with > expire policy and persistence > - > > Key: IGNITE-7742 > URL: https://issues.apache.org/jira/browse/IGNITE-7742 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.4 >Reporter: Sergey Kosarev >Priority: Major > Attachments: IgniteDbExpirePolicyTest.java > > > Some assertions were added in IGNITE-6423 > One of them fires here. > We check for > assert > cctx.shared().database().checkpointLockIsHeldByThread(); > but we don't have this lock > {code:java} > java.lang.AssertionError > at > org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:1372) > at > org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.remove(GridCacheOffheapManager.java:1364) > at > org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:370) > at > org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:3602) > at > org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onExpired(GridCacheMapEntry.java:3355) > at > org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:421) > at > org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:369) > at > org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.advance(GridCacheQueryManager.java:3043) > at > org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.onHasNext(GridCacheQueryManager.java:2999) > at > org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53) > at > org.apache.ignite.internal.processors.cache.CacheWeakQueryIteratorsHolder$WeakQueryCloseableIterator.onHasNext(CacheWeakQueryIteratorsHolder.java:308) > at > org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53) > at > org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45) > at > org.apache.ignite.internal.processors.database.IgniteDbExpireTest.testIterators(IgniteDbExpireTest.java:132) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at junit.framework.TestCase.runTest(TestCase.java:176) > at > org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2001) > at > org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133) > at > org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1916) > at java.lang.Thread.run(Thread.java:748){code} > Simple test fails > [^IgniteDbExpirePolicyTest.java] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7742) AssertionError in IgniteCacheOffheapManagerImpl when Iterate Cache with expire policy and persistence
[ https://issues.apache.org/jira/browse/IGNITE-7742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Kosarev updated IGNITE-7742: --- Attachment: IgniteDbExpirePolicyTest.java > AssertionError in IgniteCacheOffheapManagerImpl when Iterate Cache with > expire policy and persistence > - > > Key: IGNITE-7742 > URL: https://issues.apache.org/jira/browse/IGNITE-7742 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.4 >Reporter: Sergey Kosarev >Priority: Major > Attachments: IgniteDbExpirePolicyTest.java > > > Some assertions were added in IGNITE-6423 > One of them fires here. > We check for > assert > cctx.shared().database().checkpointLockIsHeldByThread(); > but we don't have this lock > {code:java} > java.lang.AssertionError > at > org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:1372) > at > org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.remove(GridCacheOffheapManager.java:1364) > at > org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:370) > at > org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:3602) > at > org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onExpired(GridCacheMapEntry.java:3355) > at > org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:421) > at > org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:369) > at > org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.advance(GridCacheQueryManager.java:3043) > at > org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.onHasNext(GridCacheQueryManager.java:2999) > at > org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53) > at > org.apache.ignite.internal.processors.cache.CacheWeakQueryIteratorsHolder$WeakQueryCloseableIterator.onHasNext(CacheWeakQueryIteratorsHolder.java:308) > at > org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53) > at > org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45) > at > org.apache.ignite.internal.processors.database.IgniteDbExpireTest.testIterators(IgniteDbExpireTest.java:132) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at junit.framework.TestCase.runTest(TestCase.java:176) > at > org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2001) > at > org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133) > at > org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1916) > at java.lang.Thread.run(Thread.java:748){code} > Simple test fails > [^IgniteDbExpirePolicyTest.java] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7718) Collections.singleton() and Collections.singletonMap() are not properly serialized by binary marshaller
[ https://issues.apache.org/jira/browse/IGNITE-7718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16369302#comment-16369302 ] Dmitriy Pavlov commented on IGNITE-7718: I've triggered Run all for this PR. It is simpler to check chain results, moreover bug in such changes may cause compatibilty problems at least in PDS. I suggest to use run all chain for all PRs https://ci.ignite.apache.org/viewQueued.html?itemId=1102019&tab=queuedBuildOverviewTab > Collections.singleton() and Collections.singletonMap() are not properly > serialized by binary marshaller > --- > > Key: IGNITE-7718 > URL: https://issues.apache.org/jira/browse/IGNITE-7718 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.3 >Reporter: Pavel Vinokurov >Assignee: Pavel Vinokurov >Priority: Major > > After desialization collections obtained by Collections.singleton() and > Collections.singletonMap() does not return collection of binary objects, but > rather collection of deserialized objects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7263) Daemon-mode Ignite node should not open&listen client port (10800)
[ https://issues.apache.org/jira/browse/IGNITE-7263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16369292#comment-16369292 ] Vladimir Ozerov commented on IGNITE-7263: - [~dpavlov], [~pvinokurov], patch looks good to me. > Daemon-mode Ignite node should not open&listen client port (10800) > -- > > Key: IGNITE-7263 > URL: https://issues.apache.org/jira/browse/IGNITE-7263 > Project: Ignite > Issue Type: Bug > Components: visor >Affects Versions: 2.1 >Reporter: Alexey Popov >Assignee: Pavel Vinokurov >Priority: Minor > Labels: core > Fix For: 2.4 > > > When I run a Visor console with default configuration file it opens a default > port (10800) for ODBC driver connection (and for thin JDBC, and for new > "thin" client). > Then I run several Ignite nodes. > So after that, the ODBC driver with default settings goes directly to a Visor > (daemon-mode Ignite) and does not able to get any data (daemon-mode Ignite > does not keep any data) > It is better to avoid such situation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7632) NPE in IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.updateIgfsMetrics()
[ https://issues.apache.org/jira/browse/IGNITE-7632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16369290#comment-16369290 ] Pavel Kovalenko commented on IGNITE-7632: - [~agoncharuk] This issue is not fixed in IGNITE-6113. There is no defense against possible NullPointers in partition eviction process. > NPE in IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.updateIgfsMetrics() > --- > > Key: IGNITE-7632 > URL: https://issues.apache.org/jira/browse/IGNITE-7632 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.3 >Reporter: Alexandr Kuramshin >Priority: Major > Fix For: 2.4 > > > Occurs on destroying cache while rebuilding indices in progress > {noformat} > Partition eviction failed, this can cause grid hang. > java.lang.NullPointerException: null > at > org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.updateIgfsMetrics(IgniteCacheOffheapManagerImpl.java:1576) > at > org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishRemove(IgniteCacheOffheapManagerImpl.java:1403) > at > org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:1368) > at > org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.remove(GridCacheOffheapManager.java:1312) > at > org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:368) > at > org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:3224) > at > org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.clearInternal(GridDhtCacheEntry.java:588) > at > org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.clearAll(GridDhtLocalPartition.java:895) > at > org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.tryEvict(GridDhtLocalPartition.java:753) > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader$3.call(GridDhtPreloader.java:593) > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader$3.call(GridDhtPreloader.java:580) > at > org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6639) > at > org.apache.ignite.internal.processors.closure.GridClosureProcessor$2.body(GridClosureProcessor.java:967) > ... > {noformat} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7263) Daemon-mode Ignite node should not open&listen client port (10800)
[ https://issues.apache.org/jira/browse/IGNITE-7263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16369284#comment-16369284 ] Dmitriy Pavlov commented on IGNITE-7263: Hi [~vozerov], I've checked TC results and code style. Could you please confirm we can simply ignore daemon node in ClientListenerProcessor.java, line 82 > Daemon-mode Ignite node should not open&listen client port (10800) > -- > > Key: IGNITE-7263 > URL: https://issues.apache.org/jira/browse/IGNITE-7263 > Project: Ignite > Issue Type: Bug > Components: visor >Affects Versions: 2.1 >Reporter: Alexey Popov >Assignee: Pavel Vinokurov >Priority: Minor > Labels: core > Fix For: 2.4 > > > When I run a Visor console with default configuration file it opens a default > port (10800) for ODBC driver connection (and for thin JDBC, and for new > "thin" client). > Then I run several Ignite nodes. > So after that, the ODBC driver with default settings goes directly to a Visor > (daemon-mode Ignite) and does not able to get any data (daemon-mode Ignite > does not keep any data) > It is better to avoid such situation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7750) testMultiThreadStatisticsEnable is flaky on TC
[ https://issues.apache.org/jira/browse/IGNITE-7750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Kovalenko reassigned IGNITE-7750: --- Assignee: Alexey Goncharuk (was: Pavel Kovalenko) Affects Version/s: 2.5 Fix is ready. Changes are tiny and only in test. TC (Suite contains this test): https://ci.ignite.apache.org/viewLog.html?buildId=1100809&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_IgniteCache3 PR: https://github.com/apache/ignite/pull/3541 > testMultiThreadStatisticsEnable is flaky on TC > -- > > Key: IGNITE-7750 > URL: https://issues.apache.org/jira/browse/IGNITE-7750 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.5 >Reporter: Pavel Kovalenko >Assignee: Alexey Goncharuk >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.5 > > > {code:java} > class org.apache.ignite.IgniteException: Cache not found [cacheName=cache2] > at > org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:985) > at > org.apache.ignite.internal.cluster.IgniteClusterImpl.enableStatistics(IgniteClusterImpl.java:497) > at > org.apache.ignite.internal.processors.cache.CacheMetricsEnableRuntimeTest$3.run(CacheMetricsEnableRuntimeTest.java:181) > at > org.apache.ignite.testframework.GridTestUtils$9.call(GridTestUtils.java:1275) > at > org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86) > Caused by: class org.apache.ignite.IgniteCheckedException: Cache not found > [cacheName=cache2] > at > org.apache.ignite.internal.processors.cache.GridCacheProcessor.enableStatistics(GridCacheProcessor.java:4227) > at > org.apache.ignite.internal.cluster.IgniteClusterImpl.enableStatistics(IgniteClusterImpl.java:494) > ... 3 more > {code} > The problem of the test: > 1) We don't wait for exchange future completion after "cache2" is started and > it may lead to NullPointerException when we try to obtain reference to > "cache2" on the node which doesn't complete exchange future and initialize > cache proxy. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7754) WAL in LOG_ONLY mode doesn't execute fsync on checkpoint begin
[ https://issues.apache.org/jira/browse/IGNITE-7754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-7754: --- Component/s: persistence > WAL in LOG_ONLY mode doesn't execute fsync on checkpoint begin > -- > > Key: IGNITE-7754 > URL: https://issues.apache.org/jira/browse/IGNITE-7754 > Project: Ignite > Issue Type: Bug > Components: persistence >Reporter: Ilya Lantukh >Assignee: Ilya Lantukh >Priority: Critical > > On checkpoint begin method IgniteWriteAheadLogManager.fsync(WALPointer ptr) > will be called, but it won't actually perform fsync because mode isn't FSYNC. > It might lead to LFS corruption if OS or hardware failed until checkpoint had > been finished. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7755) Potentially crash during write cp-***-start.bin can lead to the impossibility of recovering
[ https://issues.apache.org/jira/browse/IGNITE-7755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-7755: --- Component/s: persistence > Potentially crash during write cp-***-start.bin can lead to the impossibility > of recovering > --- > > Key: IGNITE-7755 > URL: https://issues.apache.org/jira/browse/IGNITE-7755 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.3, 2.4 >Reporter: Dmitriy Govorukhin >Priority: Critical > Fix For: 2.5 > > > We can crashed after cp-***-start.bin created but before content (wal point) > is recorded. On recovery after trying read wal point we got an exception. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7725) REST: expand parameters list of GetOrCreateCache command
[ https://issues.apache.org/jira/browse/IGNITE-7725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16369240#comment-16369240 ] Alexey Kuznetsov edited comment on IGNITE-7725 at 2/19/18 3:40 PM: --- Please test. I added support of following optional parameters: * templateName=PARTITIONED|REPLICATED|_custom_template_ * backups=N * writeSynchronizationMode=FULL_SYNC|FULL_ASYNC|PRIMARY_SYNC * cacheGroup=_custom_cache_group_ * dataRegion=_name_of_existing_data_region_ Please also test negative scenarios, like: buckups=zzz, writeSynchronizationMode=zzz, etc was (Author: kuaw26): Please test. I added support of following optional parameters: * templateName=PARTITIONED|REPLICATED|_custom_template_ * backups=N * writeSynchronizationMode=FULL_SYNC|FULL_ASYNC|PRIMARY_SYNC * cacheGroup=_custom_cache_group_ * dataRegion=_name_of_existing_data_region_ > REST: expand parameters list of GetOrCreateCache command > > > Key: IGNITE-7725 > URL: https://issues.apache.org/jira/browse/IGNITE-7725 > Project: Ignite > Issue Type: Improvement > Components: rest >Affects Versions: 2.3 >Reporter: Alexey Kuznetsov >Assignee: Pavel Konstantinov >Priority: Major > Fix For: 2.5 > > > Current implementation is very primitive and do not allow to create caches > with custom options via REST. > http://host:port/ignite?cmd=getorcreate&cacheName=cache_name[&tempaleName=template_name][&backups=1][&writeSynchronizationMode=FULL_SYNC][&; > other options] > Ignite will support two pre-configured templates out of the box: PARTITIONED > and REPLICATED (same as SQL engine). > If template name is not specified, by default it will be PARTITIONED. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7755) Potentially crash during write cp-***-start.bin can lead to the impossibility of recovering
Dmitriy Govorukhin created IGNITE-7755: -- Summary: Potentially crash during write cp-***-start.bin can lead to the impossibility of recovering Key: IGNITE-7755 URL: https://issues.apache.org/jira/browse/IGNITE-7755 Project: Ignite Issue Type: Bug Affects Versions: 2.3, 2.4 Reporter: Dmitriy Govorukhin Fix For: 2.5 We can crashed after cp-***-start.bin created but before content (wal point) is recorded. On recovery after trying read wal point we got an exception. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7725) REST: expand parameters list of GetOrCreateCache command
[ https://issues.apache.org/jira/browse/IGNITE-7725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16369240#comment-16369240 ] Alexey Kuznetsov edited comment on IGNITE-7725 at 2/19/18 3:38 PM: --- Please test. I added support of following optional parameters: * templateName=PARTITIONED|REPLICATED|_custom_template_ * backups=N * writeSynchronizationMode=FULL_SYNC|FULL_ASYNC|PRIMARY_SYNC * cacheGroup=_custom_cache_group_ * dataRegion=_name_of_existing_data_region_ was (Author: kuaw26): Please test. I added support of following optional parameters: *templateName=PARTITIONED|REPLICATED|_custom_template_ *backups=N *writeSynchronizationMode=FULL_SYNC|FULL_ASYNC|PRIMARY_SYNC *cacheGroup=_custom_cache_group_ *dataRegion=_name_of_existing_data_region_ > REST: expand parameters list of GetOrCreateCache command > > > Key: IGNITE-7725 > URL: https://issues.apache.org/jira/browse/IGNITE-7725 > Project: Ignite > Issue Type: Improvement > Components: rest >Affects Versions: 2.3 >Reporter: Alexey Kuznetsov >Assignee: Pavel Konstantinov >Priority: Major > Fix For: 2.5 > > > Current implementation is very primitive and do not allow to create caches > with custom options via REST. > http://host:port/ignite?cmd=getorcreate&cacheName=cache_name[&tempaleName=template_name][&backups=1][&writeSynchronizationMode=FULL_SYNC][&; > other options] > Ignite will support two pre-configured templates out of the box: PARTITIONED > and REPLICATED (same as SQL engine). > If template name is not specified, by default it will be PARTITIONED. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7725) REST: expand parameters list of GetOrCreateCache command
[ https://issues.apache.org/jira/browse/IGNITE-7725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-7725: Assignee: Pavel Konstantinov (was: Vladimir Ozerov) Please test. I added support of following optional parameters: *templateName=PARTITIONED|REPLICATED|_custom_template_ *backups=N *writeSynchronizationMode=FULL_SYNC|FULL_ASYNC|PRIMARY_SYNC *cacheGroup=_custom_cache_group_ *dataRegion=_name_of_existing_data_region_ > REST: expand parameters list of GetOrCreateCache command > > > Key: IGNITE-7725 > URL: https://issues.apache.org/jira/browse/IGNITE-7725 > Project: Ignite > Issue Type: Improvement > Components: rest >Affects Versions: 2.3 >Reporter: Alexey Kuznetsov >Assignee: Pavel Konstantinov >Priority: Major > Fix For: 2.5 > > > Current implementation is very primitive and do not allow to create caches > with custom options via REST. > http://host:port/ignite?cmd=getorcreate&cacheName=cache_name[&tempaleName=template_name][&backups=1][&writeSynchronizationMode=FULL_SYNC][&; > other options] > Ignite will support two pre-configured templates out of the box: PARTITIONED > and REPLICATED (same as SQL engine). > If template name is not specified, by default it will be PARTITIONED. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7754) WAL in LOG_ONLY mode doesn't execute fsync on checkpoint begin
Ilya Lantukh created IGNITE-7754: Summary: WAL in LOG_ONLY mode doesn't execute fsync on checkpoint begin Key: IGNITE-7754 URL: https://issues.apache.org/jira/browse/IGNITE-7754 Project: Ignite Issue Type: Bug Reporter: Ilya Lantukh Assignee: Ilya Lantukh On checkpoint begin method IgniteWriteAheadLogManager.fsync(WALPointer ptr) will be called, but it won't actually perform fsync because mode isn't FSYNC. It might lead to LFS corruption if OS or hardware failed until checkpoint had been finished. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7727) IgniteRDDSpec. Failing tests
[ https://issues.apache.org/jira/browse/IGNITE-7727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov reassigned IGNITE-7727: --- Assignee: Nikolay Izhikov > IgniteRDDSpec. Failing tests > > > Key: IGNITE-7727 > URL: https://issues.apache.org/jira/browse/IGNITE-7727 > Project: Ignite > Issue Type: Bug > Components: spark >Affects Versions: 2.4 >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.5 > > > Two spark tests are broken. > Need to fix it. > 1. IgniteRDDSpec.IgniteRDD should successfully store data to ignite using > saveValues > 2. IgniteRDDSpec.IgniteRDD should successfully store data to ignite using > saveValues with inline transformation -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7042) Test written in scala doesn't executed on TC
[ https://issues.apache.org/jira/browse/IGNITE-7042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16369236#comment-16369236 ] ASF GitHub Bot commented on IGNITE-7042: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/3530 > Test written in scala doesn't executed on TC > - > > Key: IGNITE-7042 > URL: https://issues.apache.org/jira/browse/IGNITE-7042 > Project: Ignite > Issue Type: Bug > Components: spark >Affects Versions: 2.3 >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Minor > Fix For: 2.5 > > > Tests from module `spark` and `spark_2.10` written in scala don't executes on > TC. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7426) Thin client Java API - encryption
[ https://issues.apache.org/jira/browse/IGNITE-7426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kukushkin updated IGNITE-7426: - Description: Implement SSL/TLS configuration client Java API including unit and system tests and samples. ClientConfiguration(ssl configuration) > Thin client Java API - encryption > - > > Key: IGNITE-7426 > URL: https://issues.apache.org/jira/browse/IGNITE-7426 > Project: Ignite > Issue Type: Sub-task >Reporter: Alexey Kukushkin >Assignee: Alexey Kukushkin >Priority: Major > Labels: data, java, thin > > Implement SSL/TLS configuration client Java API including unit and system > tests and samples. > ClientConfiguration(ssl configuration) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7426) Thin client Java API - encryption
[ https://issues.apache.org/jira/browse/IGNITE-7426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kukushkin updated IGNITE-7426: - Environment: (was: Implement SSL/TLS configuration client Java API including unit and system tests and samples. ClientConfiguration(ssl configuration)) > Thin client Java API - encryption > - > > Key: IGNITE-7426 > URL: https://issues.apache.org/jira/browse/IGNITE-7426 > Project: Ignite > Issue Type: Sub-task >Reporter: Alexey Kukushkin >Assignee: Alexey Kukushkin >Priority: Major > Labels: data, java, thin > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7426) Thin client Java API - encryption
[ https://issues.apache.org/jira/browse/IGNITE-7426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kukushkin reassigned IGNITE-7426: Assignee: Alexey Kukushkin > Thin client Java API - encryption > - > > Key: IGNITE-7426 > URL: https://issues.apache.org/jira/browse/IGNITE-7426 > Project: Ignite > Issue Type: Sub-task > Environment: Implement SSL/TLS configuration client Java API > including unit and system tests and samples. > ClientConfiguration(ssl configuration) >Reporter: Alexey Kukushkin >Assignee: Alexey Kukushkin >Priority: Major > Labels: data, java, thin > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-7435) Thin client Java API - fields query API
[ https://issues.apache.org/jira/browse/IGNITE-7435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kukushkin resolved IGNITE-7435. -- Resolution: Fixed > Thin client Java API - fields query API > --- > > Key: IGNITE-7435 > URL: https://issues.apache.org/jira/browse/IGNITE-7435 > Project: Ignite > Issue Type: Sub-task >Reporter: Alexey Kukushkin >Assignee: Alexey Kukushkin >Priority: Major > Labels: data, java, thin > > Implement cache fields query thin client Java API including unit and system > tests and samples. > Cache > query(qry: SqlFieldsQuery): FieldsQueryCursor -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7751) Pages Write Throttle mode doesn't protect from checkpoint buffer overflow
[ https://issues.apache.org/jira/browse/IGNITE-7751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Rakov updated IGNITE-7751: --- Issue Type: Bug (was: Improvement) > Pages Write Throttle mode doesn't protect from checkpoint buffer overflow > - > > Key: IGNITE-7751 > URL: https://issues.apache.org/jira/browse/IGNITE-7751 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Ivan Rakov >Assignee: Ivan Rakov >Priority: Critical > Fix For: 2.5 > > > Even with write throttling enabled, checkpoint buffer still can be > overflowed. Overflow chance increases with number of writing threads. Example > stacktrace: > {noformat} > 2018-02-17 21:00:14.777 > [ERROR][sys-stripe-12-#13%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.dht.GridDhtTxRemote] > Commit failed. > org.apache.ignite.internal.transactions.IgniteTxHeuristicCheckedException: > Commit produced a runtime exception (all transaction entries will be > invalidated): > GridDhtTxRemote[id=06db48da161--07c5-23f5--0005, > concurrency=OPTIMISTIC, isolation=SERIALIZABLE, state=COMMITTING, > invalidate=false, rollbackOnly=false, > nodeId=da415868-d9b3-48a5-9b56-0706ae60dd3b, duration=60] > at > org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitIfLocked(GridDistributedTxRemoteAdapter.java:739) > at > org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitRemoteTx(GridDistributedTxRemoteAdapter.java:813) > at > org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:1319) > at > org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processDhtTxFinishRequest(IgniteTxHandler.java:1231) > at > org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$600(IgniteTxHandler.java:97) > at > org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$7.apply(IgniteTxHandler.java:213) > at > org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$7.apply(IgniteTxHandler.java:211) > at > org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1060) > at > org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579) > at > org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378) > at > org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304) > at > org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99) > at > org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293) > at > org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1555) > at > org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1183) > at > org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126) > at > org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1090) > at > org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:499) > at java.lang.Thread.run(Thread.java:745) > Caused by: org.apache.ignite.IgniteException: Runtime failure on row: > Row@9f0a081[ key: 4694439661580364888, val: > com.sbt.bm.ucp.common.dpl.model.party.DUserInfo_DPL_PROXY [idHash=1290746929, > hash=400782371, colocationKey=16678, lastChangeDate=1518890414661, > userFullName=null, partition_DPL_id=6, bankInfo_DPL_id=4694439661580364888, > bankInfo_DPL_colocationKey=16678, ownerId=null, > infoFlowChannel_DPL_colocationKey=0, userLogin=reloading, > uid=1102030258731339432, isDeleted=false, infoFlowChannel_DPL_id=0, > sourceSystem_DPL_id=65, id=4694439661580364888, > colocationId=1102030258828706483], ver: GridCacheVersion [topVer=130360309, > order=1519034613156, nodeOrder=5] ][ 1102030258731339432, reloading, > 4694439661580364888, 0, null, 65, 4694439661580364888, FALSE, 6 ] > at > org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2102) > at > org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putx(BPlusTree.java:2049) > at > org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.putx(H2TreeIndex.java:247) > at > org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.addToIndex(GridH2Table.java:536) > at > org.apache.ignite.internal.processors.q
[jira] [Updated] (IGNITE-6917) SQL: implement COPY command for efficient data loading
[ https://issues.apache.org/jira/browse/IGNITE-6917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-6917: Fix Version/s: (was: 2.4) 2.5 > SQL: implement COPY command for efficient data loading > -- > > Key: IGNITE-6917 > URL: https://issues.apache.org/jira/browse/IGNITE-6917 > Project: Ignite > Issue Type: New Feature > Components: sql >Affects Versions: 2.4 >Reporter: Vladimir Ozerov >Assignee: Kirill Shirokov >Priority: Major > Labels: iep-1 > Fix For: 2.5 > > > Inspired by Postgres [1] > Common use case - bulk data load through JDBC/ODBC interface. Currently it is > only possible to execute single commands one by one. We already can batch > them to improve performance, but there is still big room for improvement. > We should think of a completely new command - {{COPY}}. It will accept a file > (or input stream in general case) on the client side, then transfer data to > the cluster, and then execute update inside the cluster, e.g. through > streamer. > First of all we need to create quick and dirty prototype to assess potential > performance improvement. It speedup is confirmed, we should build base > implementation which will accept only files. But at the same time we should > understand how it will evolve in future: multiple file formats (probably > including Hadoop formarts, e.g. Parquet), escape characters, input streams, > etc.. > [1] [https://www.postgresql.org/docs/9.6/static/sql-copy.html] > h1. Proposed syntax > Curent implementation: > {noformat} > COPY > FROM "file.name" > INTO . > [(col-name, ...)] > FORMAT -- Only CSV format is supported in the current > release > [BATCH_SIZE ] > {noformat} > We may want to gradually add features to this command in future to have > something like this: > {noformat} > COPY > FROM "file.name"[CHARSET ""] > INTO . [CREATE [IF NOT EXISTS]] > [(col-name [] [NULLABLE] [ESCAPES], ...) [MATCH HEADER]] > FORMAT (csv|tsv|...) > -- CSV format options: > [FIELDSEP='column-separators-regexp'] > [LINESEP='row-separators-regexp'] > [QUOTE='quote-chars'] > [ESCAPE='escape-char'] > [NULL='null-sequence'] > [COMMENT='single-line-comment-start-char'] > [TRIM_LINES] > [IMPORT_EMPTY_LINES] > [CHARSET ""] > [ROWS -] > --or-- > [SKIP ROWS ] [MAX ROWS ] > [COLS -] > --or-- > [SKIP COLS ] [MAX COLS ] > [(MATCH | SKIP) HEADER] > [(REPLACE|IGNORE|ABORT ON [])) DUPLICATE KEYS] > [BATCH SIZE ( ROWS | [K|M|G|T|P])] > [COMPRESS "codec-name" [codec options]] > [LOCK (TABLE|ROWS)] > [NOLOGGING] > [BACKEND (DIRECT | STREAMER)] > {noformat} > h1. Implementation decisions and notes > h2. Parsing > * We support CSV format described in RFC 4180. > * Custom row and column separators, quoting characters are currently hardcoded > * Escape sequences, line comment characters are currently not supported > * We may want to support fixed-length formats (via format descriptors) in > future > * We may want to strip comments from lines (for example, starting with '#') > * We may want to allow user to either ignore empty lines or treat them as a > special case of record having all default values > * We may allow user to enable whitespace trimming from beginning and end of a > line > * We may want to allow user to specify error handling strategy: e.g., only > one quote character is present or escape sequence is invalid. > h2. File handling > * File character set to be supported in future > * Skipped/imported row number (or first/last line or skip header option), > skipped/imported column number (or first/last column): to be supported in > future > * Line start pattern (as in MySQL): no support planned > * We currently support only client-side import. No server-side file import. > * We may want to support client-side stdin import in future. > * We do not handle importing multiple files from single command > * We don't benefit from any kind of pre-sorting pre-partitioning data on > client side. > * We don't include any any metadata, such as line number from client side. > h3. Transferring data > * We send file data via batches. In future we will support batch size > (specified with rows per batch or data block size > per batch). > * We may want to implement data compression in future. > * We connect to single node in JDBC driver (no multi-node connections). > h3. Cache/tables/column handling > * We don't create table in the bulk load command > * We may want to have and option for reading header row, which contains > column names to match columns > * In future we may wish to support COLUMNS (col1, _, col2, _, col3) syntax, > where '_' marker means a skipped column (MySQ
[jira] [Updated] (IGNITE-7586) SQL COPY: add code examples
[ https://issues.apache.org/jira/browse/IGNITE-7586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-7586: Fix Version/s: (was: 2.4) 2.5 > SQL COPY: add code examples > --- > > Key: IGNITE-7586 > URL: https://issues.apache.org/jira/browse/IGNITE-7586 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.4 >Reporter: Kirill Shirokov >Assignee: Kirill Shirokov >Priority: Major > Labels: iep-1 > Fix For: 2.5 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7709) SQL COPY: fix file name handling
[ https://issues.apache.org/jira/browse/IGNITE-7709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-7709: Fix Version/s: 2.5 > SQL COPY: fix file name handling > > > Key: IGNITE-7709 > URL: https://issues.apache.org/jira/browse/IGNITE-7709 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.3, 2.4, 2.5 >Reporter: Kirill Shirokov >Assignee: Kirill Shirokov >Priority: Major > Fix For: 2.5 > > > Currently the file name is parsed as identifier, which is obviously a bug. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7753) Processors are incorrectly initialized if a node joins during cluster activation
[ https://issues.apache.org/jira/browse/IGNITE-7753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16369189#comment-16369189 ] Stanislav Lukyanov edited comment on IGNITE-7753 at 2/19/18 2:44 PM: - The bug is caused by a coding error in the GridClusterStateProcessor.onStateFinishMessage. Future that holds the activation result is always finished with false (joinFut.onDone(false)). The patch below fixes the problem: --- modules/core/src/main/java/org/apache/ignite/internal/processors/cluster/GridClusterStateProcessor.java (revision 1a6e54489d58ceb50521523c00383b13d6e3bd8b) +++ modules/core/src/main/java/org/apache/ignite/internal/processors/cluster/GridClusterStateProcessor.java (date 1519047408803) @@ -389,7 +389,7 @@ TransitionOnJoinWaitFuture joinFut = this.joinFut; if (joinFut != null) -joinFut.onDone(false); +joinFut.onDone(msg.clusterActive()); GridFutureAdapter transitionFut = transitionFuts.remove(state.transitionRequestId()); was (Author: slukyanov): The bug is caused by a coding error in the GridClusterStateProcessor.onStateFinishMessage. Future that holds the activation result is always finished with false (joinFut.onDone(false)). The patch below fixes the problem: {{ --- modules/core/src/main/java/org/apache/ignite/internal/processors/cluster/GridClusterStateProcessor.java (revision 1a6e54489d58ceb50521523c00383b13d6e3bd8b) +++ modules/core/src/main/java/org/apache/ignite/internal/processors/cluster/GridClusterStateProcessor.java (date 1519047408803) @@ -389,7 +389,7 @@ TransitionOnJoinWaitFuture joinFut = this.joinFut; if (joinFut != null) -joinFut.onDone(false); +joinFut.onDone(msg.clusterActive()); GridFutureAdapter transitionFut = transitionFuts.remove(state.transitionRequestId()); }} > Processors are incorrectly initialized if a node joins during cluster > activation > > > Key: IGNITE-7753 > URL: https://issues.apache.org/jira/browse/IGNITE-7753 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.3, 2.4, 2.5 >Reporter: Stanislav Lukyanov >Assignee: Stanislav Lukyanov >Priority: Major > > If a node joins during the cluster activation process (while the related > exchange operation is in progress), then some of the GridProcessor instances > of that node will be incorrectly initialized. While GridClusterStateProcessor > will correctly report the active cluster state, other processors that are > sensitive to the cluster state, e.g. GridServiceProcessor, will be not > initialized. > A reproducer is below. > === > Ignite server = > IgnitionEx.start("examples/config/persistentstore/example-persistent-store.xml", > "server"); > CyclicBarrier barrier = new CyclicBarrier(2); > Thread activationThread = new Thread(() -> { > try { > barrier.await(); > server.active(true); > } > catch (Exception e) { > e.printStackTrace(); // TODO implement. > } > }); > activationThread.start(); > barrier.await(); > IgnitionEx.setClientMode(true); > Ignite client = > IgnitionEx.start("examples/config/persistentstore/example-persistent-store.xml", > "client"); > activationThread.join(); > client.services().deployClusterSingleton("myClusterSingleton", new > SimpleMapServiceImpl<>()); > === > Here a single server node is started, then simultaneously a client node is > being started and the cluster is being activated, then client attempts to > deploy a service. As the result, the thread calling the deploy method hangs > forever with a stack trace like this: > === > "main@1" prio=5 tid=0x1 nid=NA waiting > java.lang.Thread.State: WAITING > at sun.misc.Unsafe.park(Unsafe.java:-1) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) > at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) > at > org.apache.ignite.internal.util.IgniteUtils.awaitQuiet(IgniteUtils.java:7505) > at > org.apache.ignite.internal.processors.service.GridServiceProcess
[jira] [Comment Edited] (IGNITE-7753) Processors are incorrectly initialized if a node joins during cluster activation
[ https://issues.apache.org/jira/browse/IGNITE-7753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16369189#comment-16369189 ] Stanislav Lukyanov edited comment on IGNITE-7753 at 2/19/18 2:43 PM: - The bug is caused by a coding error in the GridClusterStateProcessor.onStateFinishMessage. Future that holds the activation result is always finished with false (joinFut.onDone(false)). The patch below fixes the problem: {{ --- modules/core/src/main/java/org/apache/ignite/internal/processors/cluster/GridClusterStateProcessor.java (revision 1a6e54489d58ceb50521523c00383b13d6e3bd8b) +++ modules/core/src/main/java/org/apache/ignite/internal/processors/cluster/GridClusterStateProcessor.java (date 1519047408803) @@ -389,7 +389,7 @@ TransitionOnJoinWaitFuture joinFut = this.joinFut; if (joinFut != null) -joinFut.onDone(false); +joinFut.onDone(msg.clusterActive()); GridFutureAdapter transitionFut = transitionFuts.remove(state.transitionRequestId()); }} was (Author: slukyanov): The bug is caused by a coding error in the GridClusterStateProcessor.onStateFinishMessage. Future that holds the activation result is always finished with false (joinFut.onDone(false)). The patch below fixes the problem: {{--- modules/core/src/main/java/org/apache/ignite/internal/processors/cluster/GridClusterStateProcessor.java (revision 1a6e54489d58ceb50521523c00383b13d6e3bd8b) +++ modules/core/src/main/java/org/apache/ignite/internal/processors/cluster/GridClusterStateProcessor.java (date 1519047408803) @@ -389,7 +389,7 @@ TransitionOnJoinWaitFuture joinFut = this.joinFut; if (joinFut != null) -joinFut.onDone(false); +joinFut.onDone(msg.clusterActive()); GridFutureAdapter transitionFut = transitionFuts.remove(state.transitionRequestId()); }} > Processors are incorrectly initialized if a node joins during cluster > activation > > > Key: IGNITE-7753 > URL: https://issues.apache.org/jira/browse/IGNITE-7753 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.3, 2.4, 2.5 >Reporter: Stanislav Lukyanov >Assignee: Stanislav Lukyanov >Priority: Major > > If a node joins during the cluster activation process (while the related > exchange operation is in progress), then some of the GridProcessor instances > of that node will be incorrectly initialized. While GridClusterStateProcessor > will correctly report the active cluster state, other processors that are > sensitive to the cluster state, e.g. GridServiceProcessor, will be not > initialized. > A reproducer is below. > === > Ignite server = > IgnitionEx.start("examples/config/persistentstore/example-persistent-store.xml", > "server"); > CyclicBarrier barrier = new CyclicBarrier(2); > Thread activationThread = new Thread(() -> { > try { > barrier.await(); > server.active(true); > } > catch (Exception e) { > e.printStackTrace(); // TODO implement. > } > }); > activationThread.start(); > barrier.await(); > IgnitionEx.setClientMode(true); > Ignite client = > IgnitionEx.start("examples/config/persistentstore/example-persistent-store.xml", > "client"); > activationThread.join(); > client.services().deployClusterSingleton("myClusterSingleton", new > SimpleMapServiceImpl<>()); > === > Here a single server node is started, then simultaneously a client node is > being started and the cluster is being activated, then client attempts to > deploy a service. As the result, the thread calling the deploy method hangs > forever with a stack trace like this: > === > "main@1" prio=5 tid=0x1 nid=NA waiting > java.lang.Thread.State: WAITING > at sun.misc.Unsafe.park(Unsafe.java:-1) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) > at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) > at > org.apache.ignite.internal.util.IgniteUtils.awaitQuiet(IgniteUtils.java:7505) > at > org.apache.ignite.internal.processors.service.GridServiceProces
[jira] [Comment Edited] (IGNITE-7753) Processors are incorrectly initialized if a node joins during cluster activation
[ https://issues.apache.org/jira/browse/IGNITE-7753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16369189#comment-16369189 ] Stanislav Lukyanov edited comment on IGNITE-7753 at 2/19/18 2:43 PM: - The bug is caused by a coding error in the GridClusterStateProcessor.onStateFinishMessage. Future that holds the activation result is always finished with false (joinFut.onDone(false)). The patch below fixes the problem: {{--- modules/core/src/main/java/org/apache/ignite/internal/processors/cluster/GridClusterStateProcessor.java (revision 1a6e54489d58ceb50521523c00383b13d6e3bd8b) +++ modules/core/src/main/java/org/apache/ignite/internal/processors/cluster/GridClusterStateProcessor.java (date 1519047408803) @@ -389,7 +389,7 @@ TransitionOnJoinWaitFuture joinFut = this.joinFut; if (joinFut != null) -joinFut.onDone(false); +joinFut.onDone(msg.clusterActive()); GridFutureAdapter transitionFut = transitionFuts.remove(state.transitionRequestId()); }} was (Author: slukyanov): The bug is caused by a coding error in the GridClusterStateProcessor.onStateFinishMessage. Future that holds the activation result is always finished with false (joinFut.onDone(false)). The patch below fixes the problem: --- modules/core/src/main/java/org/apache/ignite/internal/processors/cluster/GridClusterStateProcessor.java (revision 1a6e54489d58ceb50521523c00383b13d6e3bd8b) +++ modules/core/src/main/java/org/apache/ignite/internal/processors/cluster/GridClusterStateProcessor.java (date 1519047408803) @@ -389,7 +389,7 @@ TransitionOnJoinWaitFuture joinFut = this.joinFut; if (joinFut != null) -joinFut.onDone(false); +joinFut.onDone(msg.clusterActive()); GridFutureAdapter transitionFut = transitionFuts.remove(state.transitionRequestId()); > Processors are incorrectly initialized if a node joins during cluster > activation > > > Key: IGNITE-7753 > URL: https://issues.apache.org/jira/browse/IGNITE-7753 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.3, 2.4, 2.5 >Reporter: Stanislav Lukyanov >Assignee: Stanislav Lukyanov >Priority: Major > > If a node joins during the cluster activation process (while the related > exchange operation is in progress), then some of the GridProcessor instances > of that node will be incorrectly initialized. While GridClusterStateProcessor > will correctly report the active cluster state, other processors that are > sensitive to the cluster state, e.g. GridServiceProcessor, will be not > initialized. > A reproducer is below. > === > Ignite server = > IgnitionEx.start("examples/config/persistentstore/example-persistent-store.xml", > "server"); > CyclicBarrier barrier = new CyclicBarrier(2); > Thread activationThread = new Thread(() -> { > try { > barrier.await(); > server.active(true); > } > catch (Exception e) { > e.printStackTrace(); // TODO implement. > } > }); > activationThread.start(); > barrier.await(); > IgnitionEx.setClientMode(true); > Ignite client = > IgnitionEx.start("examples/config/persistentstore/example-persistent-store.xml", > "client"); > activationThread.join(); > client.services().deployClusterSingleton("myClusterSingleton", new > SimpleMapServiceImpl<>()); > === > Here a single server node is started, then simultaneously a client node is > being started and the cluster is being activated, then client attempts to > deploy a service. As the result, the thread calling the deploy method hangs > forever with a stack trace like this: > === > "main@1" prio=5 tid=0x1 nid=NA waiting > java.lang.Thread.State: WAITING > at sun.misc.Unsafe.park(Unsafe.java:-1) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) > at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) > at > org.apache.ignite.internal.util.IgniteUtils.awaitQuiet(IgniteUtils.java:7505) > at > org.apache.ignite.internal.processors.service.GridServiceProcessor.s
[jira] [Commented] (IGNITE-7753) Processors are incorrectly initialized if a node joins during cluster activation
[ https://issues.apache.org/jira/browse/IGNITE-7753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16369189#comment-16369189 ] Stanislav Lukyanov commented on IGNITE-7753: The bug is caused by a coding error in the GridClusterStateProcessor.onStateFinishMessage. Future that holds the activation result is always finished with false (joinFut.onDone(false)). The patch below fixes the problem: --- modules/core/src/main/java/org/apache/ignite/internal/processors/cluster/GridClusterStateProcessor.java (revision 1a6e54489d58ceb50521523c00383b13d6e3bd8b) +++ modules/core/src/main/java/org/apache/ignite/internal/processors/cluster/GridClusterStateProcessor.java (date 1519047408803) @@ -389,7 +389,7 @@ TransitionOnJoinWaitFuture joinFut = this.joinFut; if (joinFut != null) -joinFut.onDone(false); +joinFut.onDone(msg.clusterActive()); GridFutureAdapter transitionFut = transitionFuts.remove(state.transitionRequestId()); > Processors are incorrectly initialized if a node joins during cluster > activation > > > Key: IGNITE-7753 > URL: https://issues.apache.org/jira/browse/IGNITE-7753 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.3, 2.4, 2.5 >Reporter: Stanislav Lukyanov >Assignee: Stanislav Lukyanov >Priority: Major > > If a node joins during the cluster activation process (while the related > exchange operation is in progress), then some of the GridProcessor instances > of that node will be incorrectly initialized. While GridClusterStateProcessor > will correctly report the active cluster state, other processors that are > sensitive to the cluster state, e.g. GridServiceProcessor, will be not > initialized. > A reproducer is below. > === > Ignite server = > IgnitionEx.start("examples/config/persistentstore/example-persistent-store.xml", > "server"); > CyclicBarrier barrier = new CyclicBarrier(2); > Thread activationThread = new Thread(() -> { > try { > barrier.await(); > server.active(true); > } > catch (Exception e) { > e.printStackTrace(); // TODO implement. > } > }); > activationThread.start(); > barrier.await(); > IgnitionEx.setClientMode(true); > Ignite client = > IgnitionEx.start("examples/config/persistentstore/example-persistent-store.xml", > "client"); > activationThread.join(); > client.services().deployClusterSingleton("myClusterSingleton", new > SimpleMapServiceImpl<>()); > === > Here a single server node is started, then simultaneously a client node is > being started and the cluster is being activated, then client attempts to > deploy a service. As the result, the thread calling the deploy method hangs > forever with a stack trace like this: > === > "main@1" prio=5 tid=0x1 nid=NA waiting > java.lang.Thread.State: WAITING > at sun.misc.Unsafe.park(Unsafe.java:-1) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) > at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) > at > org.apache.ignite.internal.util.IgniteUtils.awaitQuiet(IgniteUtils.java:7505) > at > org.apache.ignite.internal.processors.service.GridServiceProcessor.serviceCache(GridServiceProcessor.java:290) > at > org.apache.ignite.internal.processors.service.GridServiceProcessor.writeServiceToCache(GridServiceProcessor.java:728) > at > org.apache.ignite.internal.processors.service.GridServiceProcessor.deployAll(GridServiceProcessor.java:634) > at > org.apache.ignite.internal.processors.service.GridServiceProcessor.deployAll(GridServiceProcessor.java:600) > at > org.apache.ignite.internal.processors.service.GridServiceProcessor.deployMultiple(GridServiceProcessor.java:488) > at > org.apache.ignite.internal.processors.service.GridServiceProcessor.deployClusterSingleton(GridServiceProcessor.java:469) > at > org.apache.ignite.internal.IgniteServicesImpl.deployClusterSingleton(IgniteServicesImpl.java:120) > === > The behavior depends on the timings - the client has to join in the middle of > the acti
[jira] [Assigned] (IGNITE-7383) Failed to restore memory after cluster restart and activating from outdated node
[ https://issues.apache.org/jira/browse/IGNITE-7383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Lantukh reassigned IGNITE-7383: Assignee: Ilya Lantukh > Failed to restore memory after cluster restart and activating from outdated > node > > > Key: IGNITE-7383 > URL: https://issues.apache.org/jira/browse/IGNITE-7383 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.3 >Reporter: Alexandr Kuramshin >Assignee: Ilya Lantukh >Priority: Major > > Do the following steps for reproducing the problem: > 1) start nodes 0-1-2 > 2) stop node 2 > 3) create a new cache and put some data into it > 4) stop remaining nodes 0-1 > 5) start nodes 0-1-2 > 6) activate the cluster from the node 2 > Then 2 different results could be taken depending on which node is > coordinator: > a) node 2 is a coordinator: > {noformat} > Failed to activate node components > [nodeId=42d762c7-b1e0-4283-939b-aeeb3c70, client=false, > topVer=AffinityTopologyVersion [topVer=3, minorTopVer=1]] > class org.apache.ignite.IgniteCheckedException: Failed to find cache group > descriptor [grpId=3119] > at > org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.getPageMemoryForCacheGroup(GridCacheDatabaseSharedManager.java:1602) > at > org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreMemory(GridCacheDatabaseSharedManager.java:1544) > at > org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readCheckpointAndRestoreMemory(GridCacheDatabaseSharedManager.java:570) > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest(GridDhtPartitionsExchangeFuture.java:820) > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:583) > at > org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2279) > at > org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) > at java.lang.Thread.run(Thread.java:748) > {noformat} > and activation will be failed. > b) node 2 is NOT a coordinator: > we will get an error from the previous version, but the activation process > will not be failed and then we will take "Failed to wait PME" after a number > of assertions > {noformat} > Failed to process message [senderId=a940742f-bf17-41b4-bfc2-728bee72, > messageType=class > o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsSingleMessage] > java.lang.AssertionError: -2100569601 > at > org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.clientTopology(GridCachePartitionExchangeManager.java:733) > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.updatePartitionSingleMap(GridDhtPartitionsExchangeFuture.java:2877) > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processSingleMessage(GridDhtPartitionsExchangeFuture.java:1935) > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$100(GridDhtPartitionsExchangeFuture.java:116) > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:1810) > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:1798) > at > org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383) > at > org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353) > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onReceiveSingleMessage(GridDhtPartitionsExchangeFuture.java:1798) > at > org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.processSinglePartitionUpdate(GridCachePartitionExchangeManager.java:1484) > at > org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.access$1000(GridCachePartitionExchangeManager.java:131) > at > org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:327) > at > org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCach
[jira] [Created] (IGNITE-7753) Processors are incorrectly initialized if a node joins during cluster activation
Stanislav Lukyanov created IGNITE-7753: -- Summary: Processors are incorrectly initialized if a node joins during cluster activation Key: IGNITE-7753 URL: https://issues.apache.org/jira/browse/IGNITE-7753 Project: Ignite Issue Type: Bug Affects Versions: 2.3, 2.4, 2.5 Reporter: Stanislav Lukyanov Assignee: Stanislav Lukyanov If a node joins during the cluster activation process (while the related exchange operation is in progress), then some of the GridProcessor instances of that node will be incorrectly initialized. While GridClusterStateProcessor will correctly report the active cluster state, other processors that are sensitive to the cluster state, e.g. GridServiceProcessor, will be not initialized. A reproducer is below. === Ignite server = IgnitionEx.start("examples/config/persistentstore/example-persistent-store.xml", "server"); CyclicBarrier barrier = new CyclicBarrier(2); Thread activationThread = new Thread(() -> { try { barrier.await(); server.active(true); } catch (Exception e) { e.printStackTrace(); // TODO implement. } }); activationThread.start(); barrier.await(); IgnitionEx.setClientMode(true); Ignite client = IgnitionEx.start("examples/config/persistentstore/example-persistent-store.xml", "client"); activationThread.join(); client.services().deployClusterSingleton("myClusterSingleton", new SimpleMapServiceImpl<>()); === Here a single server node is started, then simultaneously a client node is being started and the cluster is being activated, then client attempts to deploy a service. As the result, the thread calling the deploy method hangs forever with a stack trace like this: === "main@1" prio=5 tid=0x1 nid=NA waiting java.lang.Thread.State: WAITING at sun.misc.Unsafe.park(Unsafe.java:-1) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) at org.apache.ignite.internal.util.IgniteUtils.awaitQuiet(IgniteUtils.java:7505) at org.apache.ignite.internal.processors.service.GridServiceProcessor.serviceCache(GridServiceProcessor.java:290) at org.apache.ignite.internal.processors.service.GridServiceProcessor.writeServiceToCache(GridServiceProcessor.java:728) at org.apache.ignite.internal.processors.service.GridServiceProcessor.deployAll(GridServiceProcessor.java:634) at org.apache.ignite.internal.processors.service.GridServiceProcessor.deployAll(GridServiceProcessor.java:600) at org.apache.ignite.internal.processors.service.GridServiceProcessor.deployMultiple(GridServiceProcessor.java:488) at org.apache.ignite.internal.processors.service.GridServiceProcessor.deployClusterSingleton(GridServiceProcessor.java:469) at org.apache.ignite.internal.IgniteServicesImpl.deployClusterSingleton(IgniteServicesImpl.java:120) === The behavior depends on the timings - the client has to join in the middle of the activation's exchange process. Putting Thread.sleep(4000) into GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest seems to work on a development laptop. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7042) Test written in scala doesn't executed on TC
[ https://issues.apache.org/jira/browse/IGNITE-7042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16369147#comment-16369147 ] Anton Vinogradov commented on IGNITE-7042: -- [~NIzhikov] Changes looks good to me > Test written in scala doesn't executed on TC > - > > Key: IGNITE-7042 > URL: https://issues.apache.org/jira/browse/IGNITE-7042 > Project: Ignite > Issue Type: Bug > Components: spark >Affects Versions: 2.3 >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Minor > Fix For: 2.5 > > > Tests from module `spark` and `spark_2.10` written in scala don't executes on > TC. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7752) Update Ignite KafkaStreamer to use new KafkaConsmer configuration.
[ https://issues.apache.org/jira/browse/IGNITE-7752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-7752: - Labels: newbie (was: ) > Update Ignite KafkaStreamer to use new KafkaConsmer configuration. > -- > > Key: IGNITE-7752 > URL: https://issues.apache.org/jira/browse/IGNITE-7752 > Project: Ignite > Issue Type: Task > Components: streaming >Reporter: Andrew Mashenkov >Priority: Major > Labels: newbie > Fix For: 2.5 > > > Seems, for now it is impossible to use new style KafkaConsumer configuration > in KafkaStreamer. > The issue here is Ignite use > kafka.consumer.Consumer.createJavaConsumerConnector() method which creates > old consumer (ZookeeperConsumerConnector). > We should create a new KafkaConsumer instead which looks like support both, > old and new style configs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7752) Update Ignite KafkaStreamer to use new KafkaConsmer configuration.
Andrew Mashenkov created IGNITE-7752: Summary: Update Ignite KafkaStreamer to use new KafkaConsmer configuration. Key: IGNITE-7752 URL: https://issues.apache.org/jira/browse/IGNITE-7752 Project: Ignite Issue Type: Task Components: streaming Reporter: Andrew Mashenkov Fix For: 2.5 Seems, for now it is impossible to use new style KafkaConsumer configuration in KafkaStreamer. The issue here is Ignite use kafka.consumer.Consumer.createJavaConsumerConnector() method which creates old consumer (ZookeeperConsumerConnector). We should create a new KafkaConsumer instead which looks like support both, old and new style configs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7594) Tx performance drop after WAL optimization
[ https://issues.apache.org/jira/browse/IGNITE-7594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Lantukh reassigned IGNITE-7594: Assignee: Ilya Lantukh > Tx performance drop after WAL optimization > --- > > Key: IGNITE-7594 > URL: https://issues.apache.org/jira/browse/IGNITE-7594 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Aleksey Chetaev >Assignee: Ilya Lantukh >Priority: Critical > > Perfomance dropes in tx-putAll benchmarks after commit with WAL optimization. > WAL Mode: Default > First bad commit: > [https://github.com/apache/ignite/commit/a5ffd4eb18e6e9eab30c176a7bb4008a51b3d59d] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7751) Pages Write Throttle mode doesn't protect from checkpoint buffer overflow
[ https://issues.apache.org/jira/browse/IGNITE-7751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Rakov updated IGNITE-7751: --- Description: Even with write throttling enabled, checkpoint buffer still can be overflowed. Overflow chance increases with number of writing threads. Example stacktrace: {noformat} 2018-02-17 21:00:14.777 [ERROR][sys-stripe-12-#13%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.dht.GridDhtTxRemote] Commit failed. org.apache.ignite.internal.transactions.IgniteTxHeuristicCheckedException: Commit produced a runtime exception (all transaction entries will be invalidated): GridDhtTxRemote[id=06db48da161--07c5-23f5--0005, concurrency=OPTIMISTIC, isolation=SERIALIZABLE, state=COMMITTING, invalidate=false, rollbackOnly=false, nodeId=da415868-d9b3-48a5-9b56-0706ae60dd3b, duration=60] at org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitIfLocked(GridDistributedTxRemoteAdapter.java:739) at org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitRemoteTx(GridDistributedTxRemoteAdapter.java:813) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:1319) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processDhtTxFinishRequest(IgniteTxHandler.java:1231) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$600(IgniteTxHandler.java:97) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$7.apply(IgniteTxHandler.java:213) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$7.apply(IgniteTxHandler.java:211) at org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1060) at org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579) at org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378) at org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304) at org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99) at org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293) at org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1555) at org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1183) at org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126) at org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1090) at org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:499) at java.lang.Thread.run(Thread.java:745) Caused by: org.apache.ignite.IgniteException: Runtime failure on row: Row@9f0a081[ key: 4694439661580364888, val: com.sbt.bm.ucp.common.dpl.model.party.DUserInfo_DPL_PROXY [idHash=1290746929, hash=400782371, colocationKey=16678, lastChangeDate=1518890414661, userFullName=null, partition_DPL_id=6, bankInfo_DPL_id=4694439661580364888, bankInfo_DPL_colocationKey=16678, ownerId=null, infoFlowChannel_DPL_colocationKey=0, userLogin=reloading, uid=1102030258731339432, isDeleted=false, infoFlowChannel_DPL_id=0, sourceSystem_DPL_id=65, id=4694439661580364888, colocationId=1102030258828706483], ver: GridCacheVersion [topVer=130360309, order=1519034613156, nodeOrder=5] ][ 1102030258731339432, reloading, 4694439661580364888, 0, null, 65, 4694439661580364888, FALSE, 6 ] at org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2102) at org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putx(BPlusTree.java:2049) at org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.putx(H2TreeIndex.java:247) at org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.addToIndex(GridH2Table.java:536) at org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:468) at org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:595) at org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:1865) at org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:407) at org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishUpdate(IgniteCacheOffheapManagerImpl.java:1343) at org.apache.ignite.internal.proces
[jira] [Created] (IGNITE-7751) Pages Write Throttle mode doesn't protect from checkpoint buffer overflow
Ivan Rakov created IGNITE-7751: -- Summary: Pages Write Throttle mode doesn't protect from checkpoint buffer overflow Key: IGNITE-7751 URL: https://issues.apache.org/jira/browse/IGNITE-7751 Project: Ignite Issue Type: Improvement Affects Versions: 2.3 Reporter: Ivan Rakov Assignee: Ivan Rakov Fix For: 2.5 Even with write throttling enabled, checkpoint buffer still can be overflowed. Example stacktrace: {noformat} 2018-02-17 21:00:14.777 [ERROR][sys-stripe-12-#13%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.dht.GridDhtTxRemote] Commit failed. org.apache.ignite.internal.transactions.IgniteTxHeuristicCheckedException: Commit produced a runtime exception (all transaction entries will be invalidated): GridDhtTxRemote[id=06db48da161--07c5-23f5--0005, concurrency=OPTIMISTIC, isolation=SERIALIZABLE, state=COMMITTING, invalidate=false, rollbackOnly=false, nodeId=da415868-d9b3-48a5-9b56-0706ae60dd3b, duration=60] at org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitIfLocked(GridDistributedTxRemoteAdapter.java:739) at org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitRemoteTx(GridDistributedTxRemoteAdapter.java:813) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:1319) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processDhtTxFinishRequest(IgniteTxHandler.java:1231) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$600(IgniteTxHandler.java:97) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$7.apply(IgniteTxHandler.java:213) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$7.apply(IgniteTxHandler.java:211) at org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1060) at org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579) at org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378) at org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304) at org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99) at org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293) at org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1555) at org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1183) at org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126) at org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1090) at org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:499) at java.lang.Thread.run(Thread.java:745) Caused by: org.apache.ignite.IgniteException: Runtime failure on row: Row@9f0a081[ key: 4694439661580364888, val: com.sbt.bm.ucp.common.dpl.model.party.DUserInfo_DPL_PROXY [idHash=1290746929, hash=400782371, colocationKey=16678, lastChangeDate=1518890414661, userFullName=null, partition_DPL_id=6, bankInfo_DPL_id=4694439661580364888, bankInfo_DPL_colocationKey=16678, ownerId=null, infoFlowChannel_DPL_colocationKey=0, userLogin=reloading, uid=1102030258731339432, isDeleted=false, infoFlowChannel_DPL_id=0, sourceSystem_DPL_id=65, id=4694439661580364888, colocationId=1102030258828706483], ver: GridCacheVersion [topVer=130360309, order=1519034613156, nodeOrder=5] ][ 1102030258731339432, reloading, 4694439661580364888, 0, null, 65, 4694439661580364888, FALSE, 6 ] at org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2102) at org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putx(BPlusTree.java:2049) at org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.putx(H2TreeIndex.java:247) at org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.addToIndex(GridH2Table.java:536) at org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:468) at org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:595) at org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:1865) at org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:407) at org.apa
[jira] [Updated] (IGNITE-7751) Pages Write Throttle mode doesn't protect from checkpoint buffer overflow
[ https://issues.apache.org/jira/browse/IGNITE-7751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Rakov updated IGNITE-7751: --- Description: Even with write throttling enabled, checkpoint buffer still can be overflowed. Example stacktrace: {noformat} 2018-02-17 21:00:14.777 [ERROR][sys-stripe-12-#13%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.dht.GridDhtTxRemote] Commit failed. org.apache.ignite.internal.transactions.IgniteTxHeuristicCheckedException: Commit produced a runtime exception (all transaction entries will be invalidated): GridDhtTxRemote[id=06db48da161--07c5-23f5--0005, concurrency=OPTIMISTIC, isolation=SERIALIZABLE, state=COMMITTING, invalidate=false, rollbackOnly=false, nodeId=da415868-d9b3-48a5-9b56-0706ae60dd3b, duration=60] at org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitIfLocked(GridDistributedTxRemoteAdapter.java:739) at org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitRemoteTx(GridDistributedTxRemoteAdapter.java:813) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:1319) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processDhtTxFinishRequest(IgniteTxHandler.java:1231) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$600(IgniteTxHandler.java:97) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$7.apply(IgniteTxHandler.java:213) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$7.apply(IgniteTxHandler.java:211) at org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1060) at org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579) at org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378) at org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304) at org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99) at org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293) at org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1555) at org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1183) at org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126) at org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1090) at org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:499) at java.lang.Thread.run(Thread.java:745) Caused by: org.apache.ignite.IgniteException: Runtime failure on row: Row@9f0a081[ key: 4694439661580364888, val: com.sbt.bm.ucp.common.dpl.model.party.DUserInfo_DPL_PROXY [idHash=1290746929, hash=400782371, colocationKey=16678, lastChangeDate=1518890414661, userFullName=null, partition_DPL_id=6, bankInfo_DPL_id=4694439661580364888, bankInfo_DPL_colocationKey=16678, ownerId=null, infoFlowChannel_DPL_colocationKey=0, userLogin=reloading, uid=1102030258731339432, isDeleted=false, infoFlowChannel_DPL_id=0, sourceSystem_DPL_id=65, id=4694439661580364888, colocationId=1102030258828706483], ver: GridCacheVersion [topVer=130360309, order=1519034613156, nodeOrder=5] ][ 1102030258731339432, reloading, 4694439661580364888, 0, null, 65, 4694439661580364888, FALSE, 6 ] at org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2102) at org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putx(BPlusTree.java:2049) at org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.putx(H2TreeIndex.java:247) at org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.addToIndex(GridH2Table.java:536) at org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:468) at org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:595) at org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:1865) at org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:407) at org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishUpdate(IgniteCacheOffheapManagerImpl.java:1343) at org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImp
[jira] [Commented] (IGNITE-6579) WAL history does not used when node returns to cluster again
[ https://issues.apache.org/jira/browse/IGNITE-6579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16369104#comment-16369104 ] Pavel Pereslegin commented on IGNITE-6579: -- [~v.pyatkov], I think it's better to create a separate ticket to improve the logging and close this one (as Won't FIX). > WAL history does not used when node returns to cluster again > > > Key: IGNITE-6579 > URL: https://issues.apache.org/jira/browse/IGNITE-6579 > Project: Ignite > Issue Type: Bug > Components: persistence >Reporter: Vladislav Pyatkov >Priority: Major > > When I have set big enough value to "WAL history size" and stop node on 20 > minutes, I got the message from coordinator (order=1): > {noformat} > 2017-10-06 15:46:33.429 [WARN > ][sys-#10740%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.GridDhtPartitionTopologyImpl] > Partition has been scheduled for rebalancing due to outdated update counter > [nodeId=e51a1db2-f49b-44a9-b122-adde4016d9e7, > cacheOrGroupName=CACHEGROUP_PARTICLE_DServiceZone, partId=2424, > haveHistory=false] > 2017-10-06 15:46:33.429 [WARN > ][sys-#10740%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.GridDhtPartitionTopologyImpl] > Partition has been scheduled for rebalancing due to outdated update counter > [nodeId=e51a1db2-f49b-44a9-b122-adde4016d9e7, > cacheOrGroupName=CACHEGROUP_PARTICLE_DServiceZone, partId=2427, > haveHistory=false] > 2017-10-06 15:46:33.429 [WARN > ][sys-#10740%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.GridDhtPartitionTopologyImpl] > Partition has been scheduled for rebalancing due to outdated update counter > [nodeId=e51a1db2-f49b-44a9-b122-adde4016d9e7, > cacheOrGroupName=CACHEGROUP_PARTICLE_DServiceZone, partId=2426, > haveHistory=false] > {noformat} > after start node again. > I think, history size should be enough, but I see it is not by logs > (haveHistory=false). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-6579) WAL history does not used when node returns to cluster again
[ https://issues.apache.org/jira/browse/IGNITE-6579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16328816#comment-16328816 ] Pavel Pereslegin edited comment on IGNITE-6579 at 2/19/18 12:59 PM: Hello, [~v.pyatkov]. I agree, but since coordinator doesn't have information about non local partition sizes we can't simply point to this restriction here, at least without some irrelevant changes to existing partition exchange procedure. To improve understanding, may be, we can add debug message on nodes where WAL history is being reserved for exchange (in case partition size too small for partial rebalancing)? was (Author: xtern): Hello, [~v.pyatkov]. I agreed, but since coordinator doesn't have information about non local partition sizes we can't simply point to this restriction here, at least without some irrelevant changes to existing partition exchange procedure. To improve understanding, may be, we can add debug message on nodes where WAL history is being reserved for exchange (in case partition size too small for partial rebalancing)? > WAL history does not used when node returns to cluster again > > > Key: IGNITE-6579 > URL: https://issues.apache.org/jira/browse/IGNITE-6579 > Project: Ignite > Issue Type: Bug > Components: persistence >Reporter: Vladislav Pyatkov >Priority: Major > > When I have set big enough value to "WAL history size" and stop node on 20 > minutes, I got the message from coordinator (order=1): > {noformat} > 2017-10-06 15:46:33.429 [WARN > ][sys-#10740%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.GridDhtPartitionTopologyImpl] > Partition has been scheduled for rebalancing due to outdated update counter > [nodeId=e51a1db2-f49b-44a9-b122-adde4016d9e7, > cacheOrGroupName=CACHEGROUP_PARTICLE_DServiceZone, partId=2424, > haveHistory=false] > 2017-10-06 15:46:33.429 [WARN > ][sys-#10740%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.GridDhtPartitionTopologyImpl] > Partition has been scheduled for rebalancing due to outdated update counter > [nodeId=e51a1db2-f49b-44a9-b122-adde4016d9e7, > cacheOrGroupName=CACHEGROUP_PARTICLE_DServiceZone, partId=2427, > haveHistory=false] > 2017-10-06 15:46:33.429 [WARN > ][sys-#10740%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.GridDhtPartitionTopologyImpl] > Partition has been scheduled for rebalancing due to outdated update counter > [nodeId=e51a1db2-f49b-44a9-b122-adde4016d9e7, > cacheOrGroupName=CACHEGROUP_PARTICLE_DServiceZone, partId=2426, > haveHistory=false] > {noformat} > after start node again. > I think, history size should be enough, but I see it is not by logs > (haveHistory=false). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7253) JDBC thin driver: introduce streaming mode
[ https://issues.apache.org/jira/browse/IGNITE-7253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16369101#comment-16369101 ] ASF GitHub Bot commented on IGNITE-7253: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/3499 > JDBC thin driver: introduce streaming mode > -- > > Key: IGNITE-7253 > URL: https://issues.apache.org/jira/browse/IGNITE-7253 > Project: Ignite > Issue Type: Task > Components: jdbc, sql >Reporter: Vladimir Ozerov >Assignee: Alexander Paschenko >Priority: Major > Fix For: 2.5 > > > Should be done after IGNITE-6022. We should allow optional streaming mode for > JDBC driver. In this mode only INSERTs without SELECT should be possible. All > other DML operations should throw an exception. > Design considerations: > 1) Add command {{SET STREAMING=1|ON|0|OFF}} which will enable or disable > streaming for connection. > 2) Add command {{STREAMER FLUSH}} which will force data flush. > 3) Only INSERT without SELECT works, all other DML statements should throw an > exception > 4) It should be possible to stream into several tables simultaneously (i.e. > several streamers could be opened) > 5) Any DDL statement should force flush of all currently opened streamers. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7750) testMultiThreadStatisticsEnable is flaky on TC
[ https://issues.apache.org/jira/browse/IGNITE-7750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Kovalenko updated IGNITE-7750: Fix Version/s: 2.5 > testMultiThreadStatisticsEnable is flaky on TC > -- > > Key: IGNITE-7750 > URL: https://issues.apache.org/jira/browse/IGNITE-7750 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Pavel Kovalenko >Assignee: Pavel Kovalenko >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.5 > > > {code:java} > class org.apache.ignite.IgniteException: Cache not found [cacheName=cache2] > at > org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:985) > at > org.apache.ignite.internal.cluster.IgniteClusterImpl.enableStatistics(IgniteClusterImpl.java:497) > at > org.apache.ignite.internal.processors.cache.CacheMetricsEnableRuntimeTest$3.run(CacheMetricsEnableRuntimeTest.java:181) > at > org.apache.ignite.testframework.GridTestUtils$9.call(GridTestUtils.java:1275) > at > org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86) > Caused by: class org.apache.ignite.IgniteCheckedException: Cache not found > [cacheName=cache2] > at > org.apache.ignite.internal.processors.cache.GridCacheProcessor.enableStatistics(GridCacheProcessor.java:4227) > at > org.apache.ignite.internal.cluster.IgniteClusterImpl.enableStatistics(IgniteClusterImpl.java:494) > ... 3 more > {code} > The problem of the test: > 1) We don't wait for exchange future completion after "cache2" is started and > it may lead to NullPointerException when we try to obtain reference to > "cache2" on the node which doesn't complete exchange future and initialize > cache proxy. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7717) testAssignmentAfterRestarts is flaky on TC
[ https://issues.apache.org/jira/browse/IGNITE-7717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Kovalenko updated IGNITE-7717: Fix Version/s: 2.5 > testAssignmentAfterRestarts is flaky on TC > -- > > Key: IGNITE-7717 > URL: https://issues.apache.org/jira/browse/IGNITE-7717 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.5 >Reporter: Pavel Kovalenko >Assignee: Alexey Goncharuk >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.5 > > > There is infinite awaiting of partitions map exchange: > {noformat} > [2018-02-15 13:41:46,180][WARN > ][test-runner-#1%persistence.IgnitePdsCacheAssignmentNodeRestartsTest%][root] > Waiting for topology map update > [igniteInstanceName=persistence.IgnitePdsCacheAssignmentNodeRestartsTest0, > cache=ignite-sys-cache, cacheId=-2100569601, topVer=AffinityTopologyVersion > [topVer=11, minorTopVer=0], p=0, affNodesCnt=5, ownersCnt=3, > affNodes=[126cbc54-1b9f-46b8-a978-b6c61ee1, > 0971749e-e313-4c57-99ab-40400b10, 84f71ca6-6213-43a0-91ea-42eca512, > 3d781b31-ed38-49c8-8875-bdfa2fa3, 8f4bdf1c-a2c8-45e8-acd7-64bb4564], > owners=[0971749e-e313-4c57-99ab-40400b10, > 126cbc54-1b9f-46b8-a978-b6c61ee1, 3d781b31-ed38-49c8-8875-bdfa2fa3], > topFut=GridDhtPartitionsExchangeFuture [firstDiscoEvt=DiscoveryEvent > [evtNode=TcpDiscoveryNode [id=3d781b31-ed38-49c8-8875-bdfa2fa3, > addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, > intOrder=6, lastExchangeTime=1518691298151, loc=false, > ver=2.5.0#19700101-sha1:, isClient=false], topVer=9, > nodeId8=0971749e, msg=Node joined: TcpDiscoveryNode > [id=3d781b31-ed38-49c8-8875-bdfa2fa3, addrs=[127.0.0.1], > sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, intOrder=6, > lastExchangeTime=1518691298151, loc=false, ver=2.5.0#19700101-sha1:, > isClient=false], type=NODE_JOINED, tstamp=1518691298244], > crd=TcpDiscoveryNode [id=0971749e-e313-4c57-99ab-40400b10, > addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, > intOrder=1, lastExchangeTime=1518691306165, loc=true, > ver=2.5.0#19700101-sha1:, isClient=false], > exchId=GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=9, > minorTopVer=0], discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode > [id=3d781b31-ed38-49c8-8875-bdfa2fa3, addrs=[127.0.0.1], > sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, intOrder=6, > lastExchangeTime=1518691298151, loc=false, ver=2.5.0#19700101-sha1:, > isClient=false], topVer=9, nodeId8=0971749e, msg=Node joined: > TcpDiscoveryNode [id=3d781b31-ed38-49c8-8875-bdfa2fa3, addrs=[127.0.0.1], > sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, intOrder=6, > lastExchangeTime=1518691298151, loc=false, ver=2.5.0#19700101-sha1:, > isClient=false], type=NODE_JOINED, tstamp=1518691298244], nodeId=3d781b31, > evt=NODE_JOINED], added=true, initFut=GridFutureAdapter > [ignoreInterrupts=false, state=DONE, res=true, hash=2121252210], init=true, > lastVer=GridCacheVersion [topVer=0, order=1518691297806, nodeOrder=0], > partReleaseFut=PartitionReleaseFuture [topVer=AffinityTopologyVersion > [topVer=9, minorTopVer=0], futures=[ExplicitLockReleaseFuture > [topVer=AffinityTopologyVersion [topVer=9, minorTopVer=0], futures=[]], > TxReleaseFuture [topVer=AffinityTopologyVersion [topVer=9, minorTopVer=0], > futures=[]], AtomicUpdateReleaseFuture [topVer=AffinityTopologyVersion > [topVer=9, minorTopVer=0], futures=[]], DataStreamerReleaseFuture > [topVer=AffinityTopologyVersion [topVer=9, minorTopVer=0], futures=[, > exchActions=null, affChangeMsg=null, initTs=1518691298244, > centralizedAff=false, forceAffReassignment=false, changeGlobalStateE=null, > done=true, state=DONE, evtLatch=0, remaining=[], super=GridFutureAdapter > [ignoreInterrupts=false, state=DONE, res=AffinityTopologyVersion [topVer=11, > minorTopVer=0], hash=1135515588]], locNode=TcpDiscoveryNode > [id=0971749e-e313-4c57-99ab-40400b10, addrs=[127.0.0.1], > sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, > lastExchangeTime=1518691306165, loc=true, ver=2.5.0#19700101-sha1:, > isClient=false]] > {noformat} > This happens because of inconsistency of discoCache (cacheGrpAffNodes map) on > different nodes after restart. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-7253) JDBC thin driver: introduce streaming mode
[ https://issues.apache.org/jira/browse/IGNITE-7253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-7253. - Resolution: Fixed > JDBC thin driver: introduce streaming mode > -- > > Key: IGNITE-7253 > URL: https://issues.apache.org/jira/browse/IGNITE-7253 > Project: Ignite > Issue Type: Task > Components: jdbc, sql >Reporter: Vladimir Ozerov >Assignee: Alexander Paschenko >Priority: Major > Fix For: 2.5 > > > Should be done after IGNITE-6022. We should allow optional streaming mode for > JDBC driver. In this mode only INSERTs without SELECT should be possible. All > other DML operations should throw an exception. > Design considerations: > 1) Add command {{SET STREAMING=1|ON|0|OFF}} which will enable or disable > streaming for connection. > 2) Add command {{STREAMER FLUSH}} which will force data flush. > 3) Only INSERT without SELECT works, all other DML statements should throw an > exception > 4) It should be possible to stream into several tables simultaneously (i.e. > several streamers could be opened) > 5) Any DDL statement should force flush of all currently opened streamers. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7749) testDiscoCacheReuseOnNodeJoin fails on TC
[ https://issues.apache.org/jira/browse/IGNITE-7749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Kovalenko updated IGNITE-7749: Fix Version/s: 2.5 > testDiscoCacheReuseOnNodeJoin fails on TC > - > > Key: IGNITE-7749 > URL: https://issues.apache.org/jira/browse/IGNITE-7749 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.5 >Reporter: Pavel Kovalenko >Assignee: Alexey Goncharuk >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.5 > > > {code:java} > java.lang.ClassCastException: > org.apache.ignite.internal.util.GridConcurrentHashSet cannot be cast to > java.lang.String > at > org.apache.ignite.spi.discovery.IgniteDiscoveryCacheReuseSelfTest.assertDiscoCacheReuse(IgniteDiscoveryCacheReuseSelfTest.java:93) > at > org.apache.ignite.spi.discovery.IgniteDiscoveryCacheReuseSelfTest.testDiscoCacheReuseOnNodeJoin(IgniteDiscoveryCacheReuseSelfTest.java:64) > {code} > There are 2 problems in the test. > 1) We don't wait for final topology version is set on all nodes and start > checking discovery caches immediately after grids starting. It leads to > possible NullPointerException while accessing to discovery caches history. > 2) We don't use explicit assertEquals(String, Object, Object) related to > comparing Objects, while Java can choose assertEquals(String, String) method > to compare discovery cache fields which we're getting in runtime using > reflection. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6113) Partition eviction prevents exchange from completion
[ https://issues.apache.org/jira/browse/IGNITE-6113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Kovalenko updated IGNITE-6113: Fix Version/s: 2.5 > Partition eviction prevents exchange from completion > > > Key: IGNITE-6113 > URL: https://issues.apache.org/jira/browse/IGNITE-6113 > Project: Ignite > Issue Type: Bug > Components: cache, persistence >Affects Versions: 2.1 >Reporter: Vladislav Pyatkov >Assignee: Alexey Goncharuk >Priority: Major > Fix For: 2.5 > > > I has waited for 3 hours for completion without any success. > exchange-worker is blocked. > {noformat} > "exchange-worker-#92%DPL_GRID%grid554.ca.sbrf.ru%" #173 prio=5 os_prio=0 > tid=0x7f0835c2e000 nid=0xb907 runnable [0x7e74ab1d] >java.lang.Thread.State: TIMED_WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x7efee630a7c0> (a > org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition$1) > at > java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328) > at > org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:189) > at > org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:139) > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.assign(GridDhtPreloader.java:340) > at > org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1801) > at > org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) > at java.lang.Thread.run(Thread.java:748) >Locked ownable synchronizers: > - None > {noformat} > {noformat} > "sys-#124%DPL_GRID%grid554.ca.sbrf.ru%" #278 prio=5 os_prio=0 > tid=0x7e731c02d000 nid=0xbf4d runnable [0x7e734e7f7000] >java.lang.Thread.State: RUNNABLE > at sun.nio.ch.FileDispatcherImpl.write0(Native Method) > at sun.nio.ch.FileDispatcherImpl.write(FileDispatcherImpl.java:60) > at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) > at sun.nio.ch.IOUtil.write(IOUtil.java:51) > at sun.nio.ch.FileChannelImpl.write(FileChannelImpl.java:211) > - locked <0x7f056161bf88> (a java.lang.Object) > at > org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager$FileWriteHandle.writeBuffer(FileWriteAheadLogManager.java:1829) > at > org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager$FileWriteHandle.flush(FileWriteAheadLogManager.java:1572) > at > org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager$FileWriteHandle.addRecord(FileWriteAheadLogManager.java:1421) > at > org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager$FileWriteHandle.access$800(FileWriteAheadLogManager.java:1331) > at > org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager.log(FileWriteAheadLogManager.java:339) > at > org.gridgain.grid.internal.processors.cache.database.pagemem.PageMemoryImpl.beforeReleaseWrite(PageMemoryImpl.java:1287) > at > org.gridgain.grid.internal.processors.cache.database.pagemem.PageMemoryImpl.writeUnlockPage(PageMemoryImpl.java:1142) > at > org.gridgain.grid.internal.processors.cache.database.pagemem.PageImpl.releaseWrite(PageImpl.java:167) > at > org.apache.ignite.internal.processors.cache.database.tree.util.PageHandler.writeUnlock(PageHandler.java:193) > at > org.apache.ignite.internal.processors.cache.database.tree.util.PageHandler.writePage(PageHandler.java:242) > at > org.apache.ignite.internal.processors.cache.database.tree.util.PageHandler.writePage(PageHandler.java:119) > at > org.apache.ignite.internal.processors.cache.database.tree.BPlusTree$Remove.doRemoveFromLeaf(BPlusTree.java:2886) > at > org.apache.ignite.internal.processors.cache.database.tree.BPlusTree$Remove.removeFromLeaf(BPlusTree.java:2865) > at > org.apache.ignite.internal.processors.cache.database.tree.BPlusTree$Remove.access$6900(BPlusTree.java:2515) > at > org.apache.ignite.internal.processors.cache.database.tree.BPlusTree.removeDown(BPlusTree.java:1607) > at > org.apache.ignite.internal.processors.cache.database.tree.BPlusTree.removeDown(BPlusTree.java:1574) > at > org.apache.ignite.internal.processors.cache.database.tree.BPlusTree.removeDown(BPlusTree.java:1574) > at > o
[jira] [Updated] (IGNITE-6113) Partition eviction prevents exchange from completion
[ https://issues.apache.org/jira/browse/IGNITE-6113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Kovalenko updated IGNITE-6113: Component/s: cache > Partition eviction prevents exchange from completion > > > Key: IGNITE-6113 > URL: https://issues.apache.org/jira/browse/IGNITE-6113 > Project: Ignite > Issue Type: Bug > Components: cache, persistence >Affects Versions: 2.1 >Reporter: Vladislav Pyatkov >Assignee: Alexey Goncharuk >Priority: Major > Fix For: 2.5 > > > I has waited for 3 hours for completion without any success. > exchange-worker is blocked. > {noformat} > "exchange-worker-#92%DPL_GRID%grid554.ca.sbrf.ru%" #173 prio=5 os_prio=0 > tid=0x7f0835c2e000 nid=0xb907 runnable [0x7e74ab1d] >java.lang.Thread.State: TIMED_WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x7efee630a7c0> (a > org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition$1) > at > java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328) > at > org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:189) > at > org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:139) > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.assign(GridDhtPreloader.java:340) > at > org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1801) > at > org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) > at java.lang.Thread.run(Thread.java:748) >Locked ownable synchronizers: > - None > {noformat} > {noformat} > "sys-#124%DPL_GRID%grid554.ca.sbrf.ru%" #278 prio=5 os_prio=0 > tid=0x7e731c02d000 nid=0xbf4d runnable [0x7e734e7f7000] >java.lang.Thread.State: RUNNABLE > at sun.nio.ch.FileDispatcherImpl.write0(Native Method) > at sun.nio.ch.FileDispatcherImpl.write(FileDispatcherImpl.java:60) > at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) > at sun.nio.ch.IOUtil.write(IOUtil.java:51) > at sun.nio.ch.FileChannelImpl.write(FileChannelImpl.java:211) > - locked <0x7f056161bf88> (a java.lang.Object) > at > org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager$FileWriteHandle.writeBuffer(FileWriteAheadLogManager.java:1829) > at > org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager$FileWriteHandle.flush(FileWriteAheadLogManager.java:1572) > at > org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager$FileWriteHandle.addRecord(FileWriteAheadLogManager.java:1421) > at > org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager$FileWriteHandle.access$800(FileWriteAheadLogManager.java:1331) > at > org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager.log(FileWriteAheadLogManager.java:339) > at > org.gridgain.grid.internal.processors.cache.database.pagemem.PageMemoryImpl.beforeReleaseWrite(PageMemoryImpl.java:1287) > at > org.gridgain.grid.internal.processors.cache.database.pagemem.PageMemoryImpl.writeUnlockPage(PageMemoryImpl.java:1142) > at > org.gridgain.grid.internal.processors.cache.database.pagemem.PageImpl.releaseWrite(PageImpl.java:167) > at > org.apache.ignite.internal.processors.cache.database.tree.util.PageHandler.writeUnlock(PageHandler.java:193) > at > org.apache.ignite.internal.processors.cache.database.tree.util.PageHandler.writePage(PageHandler.java:242) > at > org.apache.ignite.internal.processors.cache.database.tree.util.PageHandler.writePage(PageHandler.java:119) > at > org.apache.ignite.internal.processors.cache.database.tree.BPlusTree$Remove.doRemoveFromLeaf(BPlusTree.java:2886) > at > org.apache.ignite.internal.processors.cache.database.tree.BPlusTree$Remove.removeFromLeaf(BPlusTree.java:2865) > at > org.apache.ignite.internal.processors.cache.database.tree.BPlusTree$Remove.access$6900(BPlusTree.java:2515) > at > org.apache.ignite.internal.processors.cache.database.tree.BPlusTree.removeDown(BPlusTree.java:1607) > at > org.apache.ignite.internal.processors.cache.database.tree.BPlusTree.removeDown(BPlusTree.java:1574) > at > org.apache.ignite.internal.processors.cache.database.tree.BPlusTree.removeDown(BPlusTree.java:1574) > at > o
[jira] [Updated] (IGNITE-6113) Partition eviction prevents exchange from completion
[ https://issues.apache.org/jira/browse/IGNITE-6113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Kovalenko updated IGNITE-6113: Component/s: persistence > Partition eviction prevents exchange from completion > > > Key: IGNITE-6113 > URL: https://issues.apache.org/jira/browse/IGNITE-6113 > Project: Ignite > Issue Type: Bug > Components: cache, persistence >Affects Versions: 2.1 >Reporter: Vladislav Pyatkov >Assignee: Alexey Goncharuk >Priority: Major > Fix For: 2.5 > > > I has waited for 3 hours for completion without any success. > exchange-worker is blocked. > {noformat} > "exchange-worker-#92%DPL_GRID%grid554.ca.sbrf.ru%" #173 prio=5 os_prio=0 > tid=0x7f0835c2e000 nid=0xb907 runnable [0x7e74ab1d] >java.lang.Thread.State: TIMED_WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x7efee630a7c0> (a > org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition$1) > at > java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328) > at > org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:189) > at > org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:139) > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.assign(GridDhtPreloader.java:340) > at > org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1801) > at > org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) > at java.lang.Thread.run(Thread.java:748) >Locked ownable synchronizers: > - None > {noformat} > {noformat} > "sys-#124%DPL_GRID%grid554.ca.sbrf.ru%" #278 prio=5 os_prio=0 > tid=0x7e731c02d000 nid=0xbf4d runnable [0x7e734e7f7000] >java.lang.Thread.State: RUNNABLE > at sun.nio.ch.FileDispatcherImpl.write0(Native Method) > at sun.nio.ch.FileDispatcherImpl.write(FileDispatcherImpl.java:60) > at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) > at sun.nio.ch.IOUtil.write(IOUtil.java:51) > at sun.nio.ch.FileChannelImpl.write(FileChannelImpl.java:211) > - locked <0x7f056161bf88> (a java.lang.Object) > at > org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager$FileWriteHandle.writeBuffer(FileWriteAheadLogManager.java:1829) > at > org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager$FileWriteHandle.flush(FileWriteAheadLogManager.java:1572) > at > org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager$FileWriteHandle.addRecord(FileWriteAheadLogManager.java:1421) > at > org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager$FileWriteHandle.access$800(FileWriteAheadLogManager.java:1331) > at > org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager.log(FileWriteAheadLogManager.java:339) > at > org.gridgain.grid.internal.processors.cache.database.pagemem.PageMemoryImpl.beforeReleaseWrite(PageMemoryImpl.java:1287) > at > org.gridgain.grid.internal.processors.cache.database.pagemem.PageMemoryImpl.writeUnlockPage(PageMemoryImpl.java:1142) > at > org.gridgain.grid.internal.processors.cache.database.pagemem.PageImpl.releaseWrite(PageImpl.java:167) > at > org.apache.ignite.internal.processors.cache.database.tree.util.PageHandler.writeUnlock(PageHandler.java:193) > at > org.apache.ignite.internal.processors.cache.database.tree.util.PageHandler.writePage(PageHandler.java:242) > at > org.apache.ignite.internal.processors.cache.database.tree.util.PageHandler.writePage(PageHandler.java:119) > at > org.apache.ignite.internal.processors.cache.database.tree.BPlusTree$Remove.doRemoveFromLeaf(BPlusTree.java:2886) > at > org.apache.ignite.internal.processors.cache.database.tree.BPlusTree$Remove.removeFromLeaf(BPlusTree.java:2865) > at > org.apache.ignite.internal.processors.cache.database.tree.BPlusTree$Remove.access$6900(BPlusTree.java:2515) > at > org.apache.ignite.internal.processors.cache.database.tree.BPlusTree.removeDown(BPlusTree.java:1607) > at > org.apache.ignite.internal.processors.cache.database.tree.BPlusTree.removeDown(BPlusTree.java:1574) > at > org.apache.ignite.internal.processors.cache.database.tree.BPlusTree.removeDown(BPlusTree.java:1574) > a
[jira] [Commented] (IGNITE-7750) testMultiThreadStatisticsEnable is flaky on TC
[ https://issues.apache.org/jira/browse/IGNITE-7750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16369043#comment-16369043 ] ASF GitHub Bot commented on IGNITE-7750: GitHub user Jokser opened a pull request: https://github.com/apache/ignite/pull/3541 IGNITE-7750 Fixed testMultiThreadStatisticsEnable test. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-7750 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/3541.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 #3541 commit 1418eb9659f10831621426beefe2a4f8978b63a5 Author: Pavel Kovalenko Date: 2018-02-19T11:47:37Z IGNITE-7750 Fixed testMultiThreadStatisticsEnable test. > testMultiThreadStatisticsEnable is flaky on TC > -- > > Key: IGNITE-7750 > URL: https://issues.apache.org/jira/browse/IGNITE-7750 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Pavel Kovalenko >Assignee: Pavel Kovalenko >Priority: Major > Labels: MakeTeamcityGreenAgain > > {code:java} > class org.apache.ignite.IgniteException: Cache not found [cacheName=cache2] > at > org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:985) > at > org.apache.ignite.internal.cluster.IgniteClusterImpl.enableStatistics(IgniteClusterImpl.java:497) > at > org.apache.ignite.internal.processors.cache.CacheMetricsEnableRuntimeTest$3.run(CacheMetricsEnableRuntimeTest.java:181) > at > org.apache.ignite.testframework.GridTestUtils$9.call(GridTestUtils.java:1275) > at > org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86) > Caused by: class org.apache.ignite.IgniteCheckedException: Cache not found > [cacheName=cache2] > at > org.apache.ignite.internal.processors.cache.GridCacheProcessor.enableStatistics(GridCacheProcessor.java:4227) > at > org.apache.ignite.internal.cluster.IgniteClusterImpl.enableStatistics(IgniteClusterImpl.java:494) > ... 3 more > {code} > The problem of the test: > 1) We don't wait for exchange future completion after "cache2" is started and > it may lead to NullPointerException when we try to obtain reference to > "cache2" on the node which doesn't complete exchange future and initialize > cache proxy. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7749) testDiscoCacheReuseOnNodeJoin fails on TC
[ https://issues.apache.org/jira/browse/IGNITE-7749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Kovalenko reassigned IGNITE-7749: --- Assignee: Alexey Goncharuk (was: Pavel Kovalenko) Affects Version/s: 2.5 Fix is ready. Changes are only in the test behavior. TC: https://ci.ignite.apache.org/viewLog.html?buildId=1100808&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_IgniteSpi PR: https://github.com/apache/ignite/pull/3540 > testDiscoCacheReuseOnNodeJoin fails on TC > - > > Key: IGNITE-7749 > URL: https://issues.apache.org/jira/browse/IGNITE-7749 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.5 >Reporter: Pavel Kovalenko >Assignee: Alexey Goncharuk >Priority: Major > Labels: MakeTeamcityGreenAgain > > {code:java} > java.lang.ClassCastException: > org.apache.ignite.internal.util.GridConcurrentHashSet cannot be cast to > java.lang.String > at > org.apache.ignite.spi.discovery.IgniteDiscoveryCacheReuseSelfTest.assertDiscoCacheReuse(IgniteDiscoveryCacheReuseSelfTest.java:93) > at > org.apache.ignite.spi.discovery.IgniteDiscoveryCacheReuseSelfTest.testDiscoCacheReuseOnNodeJoin(IgniteDiscoveryCacheReuseSelfTest.java:64) > {code} > There are 2 problems in the test. > 1) We don't wait for final topology version is set on all nodes and start > checking discovery caches immediately after grids starting. It leads to > possible NullPointerException while accessing to discovery caches history. > 2) We don't use explicit assertEquals(String, Object, Object) related to > comparing Objects, while Java can choose assertEquals(String, String) method > to compare discovery cache fields which we're getting in runtime using > reflection. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7750) testMultiThreadStatisticsEnable is flaky on TC
Pavel Kovalenko created IGNITE-7750: --- Summary: testMultiThreadStatisticsEnable is flaky on TC Key: IGNITE-7750 URL: https://issues.apache.org/jira/browse/IGNITE-7750 Project: Ignite Issue Type: Bug Components: cache Reporter: Pavel Kovalenko Assignee: Pavel Kovalenko {code:java} class org.apache.ignite.IgniteException: Cache not found [cacheName=cache2] at org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:985) at org.apache.ignite.internal.cluster.IgniteClusterImpl.enableStatistics(IgniteClusterImpl.java:497) at org.apache.ignite.internal.processors.cache.CacheMetricsEnableRuntimeTest$3.run(CacheMetricsEnableRuntimeTest.java:181) at org.apache.ignite.testframework.GridTestUtils$9.call(GridTestUtils.java:1275) at org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86) Caused by: class org.apache.ignite.IgniteCheckedException: Cache not found [cacheName=cache2] at org.apache.ignite.internal.processors.cache.GridCacheProcessor.enableStatistics(GridCacheProcessor.java:4227) at org.apache.ignite.internal.cluster.IgniteClusterImpl.enableStatistics(IgniteClusterImpl.java:494) ... 3 more {code} The problem of the test: 1) We don't wait for exchange future completion after "cache2" is started and it may lead to NullPointerException when we try to obtain reference to "cache2" on the node which doesn't complete exchange future and initialize cache proxy. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7729) Add usage of Roles for Web Console E2E tests
[ https://issues.apache.org/jira/browse/IGNITE-7729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kalinin reassigned IGNITE-7729: - Assignee: Ilya Borisov (was: Alexander Kalinin) Please review. > Add usage of Roles for Web Console E2E tests > > > Key: IGNITE-7729 > URL: https://issues.apache.org/jira/browse/IGNITE-7729 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Alexander Kalinin >Assignee: Ilya Borisov >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7749) testDiscoCacheReuseOnNodeJoin fails on TC
[ https://issues.apache.org/jira/browse/IGNITE-7749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16368981#comment-16368981 ] ASF GitHub Bot commented on IGNITE-7749: GitHub user Jokser opened a pull request: https://github.com/apache/ignite/pull/3540 IGNITE-7749 Fixed testDiscoCacheReuseOnNodeJoin test. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-7749 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/3540.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 #3540 commit 5233269ea684e4cff8d4a7d46d3ce1dc343dd5f1 Author: Pavel Kovalenko Date: 2018-02-19T10:46:26Z IGNITE-7749 Fixed testDiscoCacheReuseOnNodeJoin test. > testDiscoCacheReuseOnNodeJoin fails on TC > - > > Key: IGNITE-7749 > URL: https://issues.apache.org/jira/browse/IGNITE-7749 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Pavel Kovalenko >Assignee: Pavel Kovalenko >Priority: Major > Labels: MakeTeamcityGreenAgain > > {code:java} > java.lang.ClassCastException: > org.apache.ignite.internal.util.GridConcurrentHashSet cannot be cast to > java.lang.String > at > org.apache.ignite.spi.discovery.IgniteDiscoveryCacheReuseSelfTest.assertDiscoCacheReuse(IgniteDiscoveryCacheReuseSelfTest.java:93) > at > org.apache.ignite.spi.discovery.IgniteDiscoveryCacheReuseSelfTest.testDiscoCacheReuseOnNodeJoin(IgniteDiscoveryCacheReuseSelfTest.java:64) > {code} > There are 2 problems in the test. > 1) We don't wait for final topology version is set on all nodes and start > checking discovery caches immediately after grids starting. It leads to > possible NullPointerException while accessing to discovery caches history. > 2) We don't use explicit assertEquals(String, Object, Object) related to > comparing Objects, while Java can choose assertEquals(String, String) method > to compare discovery cache fields which we're getting in runtime using > reflection. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7749) testDiscoCacheReuseOnNodeJoin fails on TC
Pavel Kovalenko created IGNITE-7749: --- Summary: testDiscoCacheReuseOnNodeJoin fails on TC Key: IGNITE-7749 URL: https://issues.apache.org/jira/browse/IGNITE-7749 Project: Ignite Issue Type: Bug Components: cache Reporter: Pavel Kovalenko Assignee: Pavel Kovalenko {code:java} java.lang.ClassCastException: org.apache.ignite.internal.util.GridConcurrentHashSet cannot be cast to java.lang.String at org.apache.ignite.spi.discovery.IgniteDiscoveryCacheReuseSelfTest.assertDiscoCacheReuse(IgniteDiscoveryCacheReuseSelfTest.java:93) at org.apache.ignite.spi.discovery.IgniteDiscoveryCacheReuseSelfTest.testDiscoCacheReuseOnNodeJoin(IgniteDiscoveryCacheReuseSelfTest.java:64) {code} There are 2 problems in the test. 1) We don't wait for final topology version is set on all nodes and start checking discovery caches immediately after grids starting. It leads to possible NullPointerException while accessing to discovery caches history. 2) We don't use explicit assertEquals(String, Object, Object) related to comparing Objects, while Java can choose assertEquals(String, String) method to compare discovery cache fields which we're getting in runtime using reflection. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7747) WAL manage getAndReserveWalFiles should not throw exception if segments not found
[ https://issues.apache.org/jira/browse/IGNITE-7747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16368974#comment-16368974 ] Dmitriy Govorukhin commented on IGNITE-7747: [~agoncharuk] Please review my changes. > WAL manage getAndReserveWalFiles should not throw exception if segments not > found > - > > Key: IGNITE-7747 > URL: https://issues.apache.org/jira/browse/IGNITE-7747 > Project: Ignite > Issue Type: Improvement > Components: persistence >Affects Versions: 2.3, 2.4 >Reporter: Dmitriy Govorukhin >Assignee: Dmitriy Govorukhin >Priority: Major > Fix For: 2.5 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7747) WAL manage getAndReserveWalFiles should not throw exception if segments not found
[ https://issues.apache.org/jira/browse/IGNITE-7747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16368969#comment-16368969 ] ASF GitHub Bot commented on IGNITE-7747: GitHub user DmitriyGovorukhin opened a pull request: https://github.com/apache/ignite/pull/3539 IGNITE-7747 An exception should not be throw if segments not found An exception should not be throw if segments not found for getAndReserveWalFiles. Stopped iteration if next segment not found You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-7747 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/3539.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 #3539 commit bc381187292e0c032f30069e9174bc78d1376789 Author: Dmitriy Govorukhin Date: 2018-02-19T10:34:17Z IGNITE-7747 Exception should not be throw if segments not found for getAndReserveWalFiles. Stopped iteration if next segment not found > WAL manage getAndReserveWalFiles should not throw exception if segments not > found > - > > Key: IGNITE-7747 > URL: https://issues.apache.org/jira/browse/IGNITE-7747 > Project: Ignite > Issue Type: Improvement > Components: persistence >Affects Versions: 2.3, 2.4 >Reporter: Dmitriy Govorukhin >Assignee: Dmitriy Govorukhin >Priority: Major > Fix For: 2.5 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7747) WAL manage getAndReserveWalFiles should not throw exception if segments not found
[ https://issues.apache.org/jira/browse/IGNITE-7747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-7747: --- Affects Version/s: 2.4 > WAL manage getAndReserveWalFiles should not throw exception if segments not > found > - > > Key: IGNITE-7747 > URL: https://issues.apache.org/jira/browse/IGNITE-7747 > Project: Ignite > Issue Type: Improvement > Components: persistence >Affects Versions: 2.3, 2.4 >Reporter: Dmitriy Govorukhin >Assignee: Dmitriy Govorukhin >Priority: Major > Fix For: 2.5 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7747) WAL manage getAndReserveWalFiles should not throw exception if segments not found
[ https://issues.apache.org/jira/browse/IGNITE-7747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-7747: --- Affects Version/s: 2.3 > WAL manage getAndReserveWalFiles should not throw exception if segments not > found > - > > Key: IGNITE-7747 > URL: https://issues.apache.org/jira/browse/IGNITE-7747 > Project: Ignite > Issue Type: Improvement > Components: persistence >Affects Versions: 2.3, 2.4 >Reporter: Dmitriy Govorukhin >Assignee: Dmitriy Govorukhin >Priority: Major > Fix For: 2.5 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7747) WAL manage getAndReserveWalFiles should not throw exception if segments not found
[ https://issues.apache.org/jira/browse/IGNITE-7747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-7747: --- Component/s: persistence > WAL manage getAndReserveWalFiles should not throw exception if segments not > found > - > > Key: IGNITE-7747 > URL: https://issues.apache.org/jira/browse/IGNITE-7747 > Project: Ignite > Issue Type: Improvement > Components: persistence >Reporter: Dmitriy Govorukhin >Assignee: Dmitriy Govorukhin >Priority: Major > Fix For: 2.5 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7748) MVCC TX Implement TxLog related stuctures
Igor Seliverstov created IGNITE-7748: Summary: MVCC TX Implement TxLog related stuctures Key: IGNITE-7748 URL: https://issues.apache.org/jira/browse/IGNITE-7748 Project: Ignite Issue Type: Task Components: cache Reporter: Igor Seliverstov Assignee: Igor Seliverstov Create TxLog on the basis of BPlusTree. The key is a pair of two long (which correspond to crd version and mvcc cntr of MvccVersion) The value is TxState - an enum. TxState has next possible values : PREPARED, COMMITTED, ABORTED, NA. NA is a special value, which is returned when there is no info about requested TX. TxLog is managed by MvccProcessor and initiated along with MvccProcessor. At the first step there is no special WAL records corresponding to TxLog operation (will be implemented in future. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7193) IgniteReflectionFactory does not handle primitive data types.
[ https://issues.apache.org/jira/browse/IGNITE-7193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16368956#comment-16368956 ] Dmitriy Pavlov commented on IGNITE-7193: Hi [~slava.koptilin], are there any news on this issue? > IgniteReflectionFactory does not handle primitive data types. > - > > Key: IGNITE-7193 > URL: https://issues.apache.org/jira/browse/IGNITE-7193 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.1 >Reporter: Vyacheslav Koptilin >Assignee: Vyacheslav Koptilin >Priority: Minor > Fix For: 2.5 > > > {code:java} > public class TestClass { > public static final int INITIAL_VALUE = 12; > public static final int UPDATED_VALUE = 42; > private int field = INITIAL_VALUE; > public void setField(int value) { > this.field = value; > } > public int getField() { > return this.field; > } > public static void main(String[] args) { > Map props = new HashMap<>(); > props.put("field", UPDATED_VALUE); > IgniteReflectionFactory factory = new > IgniteReflectionFactory<>(ExampleNodeStartup.TestClass.class); > factory.setProperties(props); > assertEquals(UPDATED_VALUE, factory.create().getField()); > } > } > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7747) WAL manage getAndReserveWalFiles should not throw exception if segments not found
Dmitriy Govorukhin created IGNITE-7747: -- Summary: WAL manage getAndReserveWalFiles should not throw exception if segments not found Key: IGNITE-7747 URL: https://issues.apache.org/jira/browse/IGNITE-7747 Project: Ignite Issue Type: Improvement Reporter: Dmitriy Govorukhin Assignee: Dmitriy Govorukhin -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7747) WAL manage getAndReserveWalFiles should not throw exception if segments not found
[ https://issues.apache.org/jira/browse/IGNITE-7747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-7747: --- Fix Version/s: 2.5 > WAL manage getAndReserveWalFiles should not throw exception if segments not > found > - > > Key: IGNITE-7747 > URL: https://issues.apache.org/jira/browse/IGNITE-7747 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitriy Govorukhin >Assignee: Dmitriy Govorukhin >Priority: Major > Fix For: 2.5 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7717) testAssignmentAfterRestarts is flaky on TC
[ https://issues.apache.org/jira/browse/IGNITE-7717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Kovalenko reassigned IGNITE-7717: --- Assignee: Alexey Goncharuk (was: Pavel Kovalenko) Ready to review. Unfortunately fix heals only the described problem. TC Run: https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&branch_IgniteTests24Java8=pull%2F3536%2Fhead PR: https://github.com/apache/ignite/pull/3536 > testAssignmentAfterRestarts is flaky on TC > -- > > Key: IGNITE-7717 > URL: https://issues.apache.org/jira/browse/IGNITE-7717 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.5 >Reporter: Pavel Kovalenko >Assignee: Alexey Goncharuk >Priority: Major > Labels: MakeTeamcityGreenAgain > > There is infinite awaiting of partitions map exchange: > {noformat} > [2018-02-15 13:41:46,180][WARN > ][test-runner-#1%persistence.IgnitePdsCacheAssignmentNodeRestartsTest%][root] > Waiting for topology map update > [igniteInstanceName=persistence.IgnitePdsCacheAssignmentNodeRestartsTest0, > cache=ignite-sys-cache, cacheId=-2100569601, topVer=AffinityTopologyVersion > [topVer=11, minorTopVer=0], p=0, affNodesCnt=5, ownersCnt=3, > affNodes=[126cbc54-1b9f-46b8-a978-b6c61ee1, > 0971749e-e313-4c57-99ab-40400b10, 84f71ca6-6213-43a0-91ea-42eca512, > 3d781b31-ed38-49c8-8875-bdfa2fa3, 8f4bdf1c-a2c8-45e8-acd7-64bb4564], > owners=[0971749e-e313-4c57-99ab-40400b10, > 126cbc54-1b9f-46b8-a978-b6c61ee1, 3d781b31-ed38-49c8-8875-bdfa2fa3], > topFut=GridDhtPartitionsExchangeFuture [firstDiscoEvt=DiscoveryEvent > [evtNode=TcpDiscoveryNode [id=3d781b31-ed38-49c8-8875-bdfa2fa3, > addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, > intOrder=6, lastExchangeTime=1518691298151, loc=false, > ver=2.5.0#19700101-sha1:, isClient=false], topVer=9, > nodeId8=0971749e, msg=Node joined: TcpDiscoveryNode > [id=3d781b31-ed38-49c8-8875-bdfa2fa3, addrs=[127.0.0.1], > sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, intOrder=6, > lastExchangeTime=1518691298151, loc=false, ver=2.5.0#19700101-sha1:, > isClient=false], type=NODE_JOINED, tstamp=1518691298244], > crd=TcpDiscoveryNode [id=0971749e-e313-4c57-99ab-40400b10, > addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, > intOrder=1, lastExchangeTime=1518691306165, loc=true, > ver=2.5.0#19700101-sha1:, isClient=false], > exchId=GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=9, > minorTopVer=0], discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode > [id=3d781b31-ed38-49c8-8875-bdfa2fa3, addrs=[127.0.0.1], > sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, intOrder=6, > lastExchangeTime=1518691298151, loc=false, ver=2.5.0#19700101-sha1:, > isClient=false], topVer=9, nodeId8=0971749e, msg=Node joined: > TcpDiscoveryNode [id=3d781b31-ed38-49c8-8875-bdfa2fa3, addrs=[127.0.0.1], > sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, intOrder=6, > lastExchangeTime=1518691298151, loc=false, ver=2.5.0#19700101-sha1:, > isClient=false], type=NODE_JOINED, tstamp=1518691298244], nodeId=3d781b31, > evt=NODE_JOINED], added=true, initFut=GridFutureAdapter > [ignoreInterrupts=false, state=DONE, res=true, hash=2121252210], init=true, > lastVer=GridCacheVersion [topVer=0, order=1518691297806, nodeOrder=0], > partReleaseFut=PartitionReleaseFuture [topVer=AffinityTopologyVersion > [topVer=9, minorTopVer=0], futures=[ExplicitLockReleaseFuture > [topVer=AffinityTopologyVersion [topVer=9, minorTopVer=0], futures=[]], > TxReleaseFuture [topVer=AffinityTopologyVersion [topVer=9, minorTopVer=0], > futures=[]], AtomicUpdateReleaseFuture [topVer=AffinityTopologyVersion > [topVer=9, minorTopVer=0], futures=[]], DataStreamerReleaseFuture > [topVer=AffinityTopologyVersion [topVer=9, minorTopVer=0], futures=[, > exchActions=null, affChangeMsg=null, initTs=1518691298244, > centralizedAff=false, forceAffReassignment=false, changeGlobalStateE=null, > done=true, state=DONE, evtLatch=0, remaining=[], super=GridFutureAdapter > [ignoreInterrupts=false, state=DONE, res=AffinityTopologyVersion [topVer=11, > minorTopVer=0], hash=1135515588]], locNode=TcpDiscoveryNode > [id=0971749e-e313-4c57-99ab-40400b10, addrs=[127.0.0.1], > sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, > lastExchangeTime=1518691306165, loc=true, ver=2.5.0#19700101-sha1:, > isClient=false]] > {noformat} > This happens because of inconsistency of discoCache (cacheGrpAffNodes map) on > different nodes after restart. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7718) Collections.singleton() and Collections.singletonMap() are not properly serialized by binary marshaller
[ https://issues.apache.org/jira/browse/IGNITE-7718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16368857#comment-16368857 ] Pavel Vinokurov commented on IGNITE-7718: - [~dpavlov], Please review my changes > Collections.singleton() and Collections.singletonMap() are not properly > serialized by binary marshaller > --- > > Key: IGNITE-7718 > URL: https://issues.apache.org/jira/browse/IGNITE-7718 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.3 >Reporter: Pavel Vinokurov >Assignee: Pavel Vinokurov >Priority: Major > > After desialization collections obtained by Collections.singleton() and > Collections.singletonMap() does not return collection of binary objects, but > rather collection of deserialized objects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7718) Collections.singleton() and Collections.singletonMap() are not properly serialized by binary marshaller
[ https://issues.apache.org/jira/browse/IGNITE-7718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16368855#comment-16368855 ] Pavel Vinokurov commented on IGNITE-7718: - https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&branch_IgniteTests24Java8=pull%2F3534%2Fmerge > Collections.singleton() and Collections.singletonMap() are not properly > serialized by binary marshaller > --- > > Key: IGNITE-7718 > URL: https://issues.apache.org/jira/browse/IGNITE-7718 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.3 >Reporter: Pavel Vinokurov >Assignee: Pavel Vinokurov >Priority: Major > > After desialization collections obtained by Collections.singleton() and > Collections.singletonMap() does not return collection of binary objects, but > rather collection of deserialized objects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-3345) Implement support for optional key type in REST HTTP get command
[ https://issues.apache.org/jira/browse/IGNITE-3345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov reassigned IGNITE-3345: -- Assignee: Alexey Kuznetsov (was: Pavel Konstantinov) > Implement support for optional key type in REST HTTP get command > > > Key: IGNITE-3345 > URL: https://issues.apache.org/jira/browse/IGNITE-3345 > Project: Ignite > Issue Type: Task > Components: cache, rest >Affects Versions: 1.6 >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.5 > > > It seems that in current implementation > (https://apacheignite.readme.io/docs/rest-api#get) > GET command could work only with String keys. > We can add optional parameter "keyType" and implement support for common > built-in types such as Integer, Long, UUID,... and user classes that a valid > JavaBeans. > Sample: http://host:port/ignite?cmd=get&key=1&cacheName=myCache&keyType=Long -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-3345) Implement support for optional key type in REST HTTP get command
[ https://issues.apache.org/jira/browse/IGNITE-3345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16368850#comment-16368850 ] Pavel Konstantinov commented on IGNITE-3345: Successful in general but in some case error is empty in response although the node console had an error > Implement support for optional key type in REST HTTP get command > > > Key: IGNITE-3345 > URL: https://issues.apache.org/jira/browse/IGNITE-3345 > Project: Ignite > Issue Type: Task > Components: cache, rest >Affects Versions: 1.6 >Reporter: Alexey Kuznetsov >Assignee: Pavel Konstantinov >Priority: Major > Fix For: 2.5 > > > It seems that in current implementation > (https://apacheignite.readme.io/docs/rest-api#get) > GET command could work only with String keys. > We can add optional parameter "keyType" and implement support for common > built-in types such as Integer, Long, UUID,... and user classes that a valid > JavaBeans. > Sample: http://host:port/ignite?cmd=get&key=1&cacheName=myCache&keyType=Long -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7746) Failed to put data into cache if IndexedTypes configured.
Alexey Kuznetsov created IGNITE-7746: Summary: Failed to put data into cache if IndexedTypes configured. Key: IGNITE-7746 URL: https://issues.apache.org/jira/browse/IGNITE-7746 Project: Ignite Issue Type: Improvement Components: cache, sql Reporter: Alexey Kuznetsov Assignee: Vladimir Ozerov Fix For: 2.5 reproducer {code} import org.apache.ignite.configuration.CacheConfiguration; import org.apache.ignite.configuration.IgniteConfiguration; public class Reproducer { /** * @param args Command line arguments. */ public static void main(String[] args) { IgniteConfiguration cfg = new IgniteConfiguration(); CacheConfiguration ccfg = new CacheConfiguration("test"); ccfg.setIndexedTypes(String.class, String.class); cfg.setCacheConfiguration(ccfg); try(Ignite ignite = Ignition.start(cfg)) { IgniteCache cStr = ignite.cache("test"); cStr.put("key", "value"); IgniteCache cInt = ignite.cache("test"); cInt.put(1, 2); IgniteCache cIntStr = ignite.cache("test"); cIntStr.put(7, "test"); } } } {code} {noformat} Exception in thread "main" org.apache.ignite.cache.CachePartialUpdateException: Failed to update keys (retry update if possible).: [7] at org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1278) at org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1731) at org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1087) at org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:886) at org.apache.ignite.Reproducer.main(Reproducer.java:26) Caused by: class org.apache.ignite.internal.processors.cache.CachePartialUpdateCheckedException: Failed to update keys (retry update if possible).: [7] at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.onPrimaryError(GridNearAtomicAbstractUpdateFuture.java:397) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.onPrimaryResponse(GridNearAtomicSingleUpdateFuture.java:253) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture$1.apply(GridNearAtomicAbstractUpdateFuture.java:303) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture$1.apply(GridNearAtomicAbstractUpdateFuture.java:300) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicAbstractUpdateFuture.map(GridDhtAtomicAbstractUpdateFuture.java:390) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1805) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1628) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:483) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:443) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1117) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:606) at org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2369) at org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2346) at org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1084) ... 2 more Suppressed: class org.apache.ignite.IgniteCheckedException: Failed to update keys. at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.UpdateErrors.addFailedKey(UpdateErrors.java:108) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateResponse.addFailedKey(GridNearAtomicUpdateResponse.java:329) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2559) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:1883) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.Gri