[jira] [Commented] (IGNITE-8286) ScanQuery ignore setLocal with non local partition
[ https://issues.apache.org/jira/browse/IGNITE-8286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16524621#comment-16524621 ] Roman Shtykh commented on IGNITE-8286: -- Hi [~ilantukh], thank you for the review! Please see the changes. > ScanQuery ignore setLocal with non local partition > -- > > Key: IGNITE-8286 > URL: https://issues.apache.org/jira/browse/IGNITE-8286 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Alexander Belyak >Assignee: Roman Shtykh >Priority: Major > Fix For: 2.7 > > > 1) Create partitioned cache on 2+ nodes cluster > 2) Select some partition N, local node should not be OWNER of partition N > 3) execute: cache.query(new ScanQuery<>().setLocal(true).setPartition(N)) > Expected result: > empty result (probaply with logging smth like "Trying to execute local query > with non local partition N") or even throw exception > Actual result: > executing (with ScanQueryFallbackClosableIterator) query on remote node. > Problem is that we execute local query on remote node. > Same behaviour can be achieved if we get empty node list from > GridCacheQueryAdapter.node() by any reasons, for example - if we run "local" > query from non data node from given cache (see > GridDiscoveryNamager.cacheAffinityNode(ClusterNode node, String cacheName) in > GridcacheQueryAdapter.executeScanQuery() -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8428) Web Console: Support connect to secured cluster
[ https://issues.apache.org/jira/browse/IGNITE-8428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-8428: Assignee: Andrey Novikov (was: Pavel Konstantinov) > Web Console: Support connect to secured cluster > --- > > Key: IGNITE-8428 > URL: https://issues.apache.org/jira/browse/IGNITE-8428 > Project: Ignite > Issue Type: Bug > Components: wizards >Affects Versions: 2.6 >Reporter: Alexey Kuznetsov >Assignee: Andrey Novikov >Priority: Major > Fix For: 2.7 > > > See: > https://stackoverflow.com/questions/50065120/how-to-add-security-to-run-ignite-web-console-in-k8s -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8428) Web Console: Support connect to secured cluster
[ https://issues.apache.org/jira/browse/IGNITE-8428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16524573#comment-16524573 ] Alexey Kuznetsov commented on IGNITE-8428: -- I tested and reviewed this fix. Looks good for me. > Web Console: Support connect to secured cluster > --- > > Key: IGNITE-8428 > URL: https://issues.apache.org/jira/browse/IGNITE-8428 > Project: Ignite > Issue Type: Bug > Components: wizards >Affects Versions: 2.6 >Reporter: Alexey Kuznetsov >Assignee: Pavel Konstantinov >Priority: Major > Fix For: 2.7 > > > See: > https://stackoverflow.com/questions/50065120/how-to-add-security-to-run-ignite-web-console-in-k8s -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-8270) Add documentation for MLP (release 2.5)
[ https://issues.apache.org/jira/browse/IGNITE-8270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prachi Garg closed IGNITE-8270. --- > Add documentation for MLP (release 2.5) > --- > > Key: IGNITE-8270 > URL: https://issues.apache.org/jira/browse/IGNITE-8270 > Project: Ignite > Issue Type: Improvement > Components: documentation, ml >Affects Versions: 2.5 >Reporter: Anton Dmitriev >Assignee: Prachi Garg >Priority: Major > > In Apache Ignite 2.5 we have added MLP (multilayer perceptron) based on > partition based dataset and now we need to add documentation for this > feature. > Affected pages: > [Multilayer > Perceptron|https://apacheignite.readme.io/v2.4/docs/multilayer-perceptron-25] > In release 2.5 > [https://apacheignite.readme.io/docs/multilayer-perceptron|https://apacheignite.readme.io/docs/multilayer-perceptron] > page should be changed to new one > [https://apacheignite.readme.io/docs/multilayer-perceptron-25|https://apacheignite.readme.io/docs/multilayer-perceptron-25]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8883) Semaphore fails on network partitioning 2
Mo created IGNITE-8883: -- Summary: Semaphore fails on network partitioning 2 Key: IGNITE-8883 URL: https://issues.apache.org/jira/browse/IGNITE-8883 Project: Ignite Issue Type: Bug Components: data structures Reporter: Mo Scenario: Three servers (s1,s2,s3) two clients (c1,c2). A semaphore with one permit is created. Config: # {{Release acquired permits if the node that owned them left topology: set to true}} steps: # c2 acquires the permit. # Network failure happens, isolating c2 from the rest of nodes for a period of time. # Network heals. # c2 releases the permit. # c2 acquires the permit. # c1 tries to acquire lock but fails (exception) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8882) Semaphore fails on network partitioning 1
Mo created IGNITE-8882: -- Summary: Semaphore fails on network partitioning 1 Key: IGNITE-8882 URL: https://issues.apache.org/jira/browse/IGNITE-8882 Project: Ignite Issue Type: Bug Components: data structures Reporter: Mo Scenario: Three servers (s1,s2,s3) two clients (c1, c2, c3, c4). A semaphore with one permit is created. Config: {{1. Release acquired permits if the node that owned them left topology: set to false}} 2. TCP discovery mode: on steps: # c2 acquires the permit. # Network failure happens, isolating s1,s2, c1, and c3 from s3, c2, and c4 (i.e., (s1,s2,c1,c3),(s3,c2,c4)}) # c2 releases the lock # c1 and c3 try to acquire lock, but fail (an exception happens) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8881) Semaphore hangs on network partitioning
[ https://issues.apache.org/jira/browse/IGNITE-8881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mo updated IGNITE-8881: --- Description: Scenario: Three servers (s1,s2,s3) two clients (c1,c2). A semaphore with one permit is created. Config: {{1. Release acquired permits if the node that owned them left topology: set to false}} 2. TCP discovery mode: on steps: # c2 acquires the permit. # Network failure happens, isolating c2 from the rest of nodes for a period of time. # Network heals. # c2 tries to release the permit but hangs. was: Scenario: Three servers (s1,s2,s3) two clients (c1,c2). A semaphore with one permit is created. Config: {{1. Release acquired permits if the node that owned them left topology: set to false}} 2. TCP discovery mode: on 1.c2 takes a lock 2. Network partitioning \{(s1,s2,,s3,c1),(c2)}, then heal it 4. c3 tries to release the lock, but hangs steps: # c2 acquires the permit. # Network failure happens, isolating c2 from the rest of nodes for a period of time. # Network heals. # c2 tries to release the permit but hangs. > Semaphore hangs on network partitioning > --- > > Key: IGNITE-8881 > URL: https://issues.apache.org/jira/browse/IGNITE-8881 > Project: Ignite > Issue Type: Bug > Components: data structures >Affects Versions: 2.4 >Reporter: Mo >Priority: Major > > Scenario: Three servers (s1,s2,s3) two clients (c1,c2). > A semaphore with one permit is created. > Config: > {{1. Release acquired permits if the node that owned them left topology: set > to false}} > 2. TCP discovery mode: on > steps: > # c2 acquires the permit. > # Network failure happens, isolating c2 from the rest of nodes for a period > of time. > # Network heals. > # c2 tries to release the permit but hangs. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8881) Semaphore hangs on network partitioning
Mo created IGNITE-8881: -- Summary: Semaphore hangs on network partitioning Key: IGNITE-8881 URL: https://issues.apache.org/jira/browse/IGNITE-8881 Project: Ignite Issue Type: Bug Components: data structures Affects Versions: 2.4 Reporter: Mo Scenario: Three servers (s1,s2,s3) two clients (c1,c2). A semaphore with one permit is created. Config: {{1. Release acquired permits if the node that owned them left topology: set to false}} 2. TCP discovery mode: on 1.c2 takes a lock 2. Network partitioning \{(s1,s2,,s3,c1),(c2)}, then heal it 4. c3 tries to release the lock, but hangs steps: # c2 acquires the permit. # Network failure happens, isolating c2 from the rest of nodes for a period of time. # Network heals. # c2 tries to release the permit but hangs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8593) The semaphore's isBroken function doesn't work properly.
[ https://issues.apache.org/jira/browse/IGNITE-8593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mo updated IGNITE-8593: --- Description: Scenario: Three servers (s1,s2,s3) two clients (c1,c2). A semaphore with one permit is created. Config: {{1. Release acquired permits if the node that owned them left topology: set to false}} 2. TCP discovery mode: off steps: # c2 acquires the permit. # Network failure happens, isolating c2 from the rest of nodes for a period of time. # Network heals. # c2 releases the permit. # c2 acquires the permit. # Calling semaphore.isBroken() returns false on both c1 and c2. # c1 tries to acquire the permit but fails. # Now calling isBroken() returns true on both c1 and c2. I think isBroken() should return true before a client tries to acquire a permit, and then fails (i.e., in step 6) rather than after acquiring a permit fails, as in the latter case, what purpose does the isBroken() function serves? was: Scenario: Three servers (s1,s2,s3) two clients (c1,c2). A semaphore with one permit is created. Config: {{1.Release acquired permits if node, that owned them, left topology: set to false}} 2. # c2 acquires the permit. # Network failure happens, isolating c2 from the rest of nodes for a period of time. # Network heals. # c2 releases the permit. # c2 acquires the permit. # Calling semaphore.isBroken() returns false on both c1 and c2. # c1 tries to acquire the permit but fails. # Now calling isBroken() returns true on both c1 and c2. I think isBroken() should return true before a client tries to acquire a permit, and then fails (i.e., in step 6) rather than after acquiring a permit fails, as in the latter case, what purpose does the isBroken() function serves? > The semaphore's isBroken function doesn't work properly. > > > Key: IGNITE-8593 > URL: https://issues.apache.org/jira/browse/IGNITE-8593 > Project: Ignite > Issue Type: Bug > Components: data structures >Affects Versions: 2.4 >Reporter: Mo >Priority: Minor > > Scenario: Three servers (s1,s2,s3) two clients (c1,c2). > A semaphore with one permit is created. > Config: > {{1. Release acquired permits if the node that owned them left topology: set > to false}} > 2. TCP discovery mode: off > > steps: > # c2 acquires the permit. > # Network failure happens, isolating c2 from the rest of nodes for a period > of time. > # Network heals. > # c2 releases the permit. > # c2 acquires the permit. > # Calling semaphore.isBroken() returns false on both c1 and c2. > # c1 tries to acquire the permit but fails. > # Now calling isBroken() returns true on both c1 and c2. > > I think isBroken() should return true before a client tries to acquire a > permit, and then fails (i.e., in step 6) rather than after acquiring a permit > fails, as in the latter case, what purpose does the isBroken() function > serves? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8593) The semaphore's isBroken function doesn't work properly.
[ https://issues.apache.org/jira/browse/IGNITE-8593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mo updated IGNITE-8593: --- Description: Scenario: Three servers (s1,s2,s3) two clients (c1,c2). A semaphore with one permit is created. Config: {{1.Release acquired permits if node, that owned them, left topology: set to false}} 2. # c2 acquires the permit. # Network failure happens, isolating c2 from the rest of nodes for a period of time. # Network heals. # c2 releases the permit. # c2 acquires the permit. # Calling semaphore.isBroken() returns false on both c1 and c2. # c1 tries to acquire the permit but fails. # Now calling isBroken() returns true on both c1 and c2. I think isBroken() should return true before a client tries to acquire a permit, and then fails (i.e., in step 6) rather than after acquiring a permit fails, as in the latter case, what purpose does the isBroken() function serves? was: Scenario: Three servers (s1,s2,s3) two clients (c1,c2). A semaphore with one permit is created. Config: {{Release acquired permits if node, that owned them, left topology: set to false}} # c2 acquires the permit. # Network failure happens, isolating c2 from the rest of nodes for a period of time. # Network heals. # c2 releases the permit. # c2 acquires the permit. # Calling semaphore.isBroken() returns false on both c1 and c2. # c1 tries to acquire the permit but fails. # Now calling isBroken() returns true on both c1 and c2. I think isBroken() should return true before a client tries to acquire a permit, and then fails (i.e., in step 6) rather than after acquiring a permit fails, as in the latter case, what purpose does the isBroken() function serves? > The semaphore's isBroken function doesn't work properly. > > > Key: IGNITE-8593 > URL: https://issues.apache.org/jira/browse/IGNITE-8593 > Project: Ignite > Issue Type: Bug > Components: data structures >Affects Versions: 2.4 >Reporter: Mo >Priority: Minor > > Scenario: Three servers (s1,s2,s3) two clients (c1,c2). > A semaphore with one permit is created. > Config: > {{1.Release acquired permits if node, that owned them, left topology: set to > false}} > 2. > # c2 acquires the permit. > # Network failure happens, isolating c2 from the rest of nodes for a period > of time. > # Network heals. > # c2 releases the permit. > # c2 acquires the permit. > # Calling semaphore.isBroken() returns false on both c1 and c2. > # c1 tries to acquire the permit but fails. > # Now calling isBroken() returns true on both c1 and c2. > > I think isBroken() should return true before a client tries to acquire a > permit, and then fails (i.e., in step 6) rather than after acquiring a permit > fails, as in the latter case, what purpose does the isBroken() function > serves? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8780) File I/O operations must be retried if buffer hasn't read/written completely
[ https://issues.apache.org/jira/browse/IGNITE-8780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16524121#comment-16524121 ] Eduard Shangareev commented on IGNITE-8780: --- [~astelmak], I would like to see a test with slow disk emulation (new test File IO). > File I/O operations must be retried if buffer hasn't read/written completely > > > Key: IGNITE-8780 > URL: https://issues.apache.org/jira/browse/IGNITE-8780 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.5 >Reporter: Pavel Kovalenko >Assignee: Alexey Stelmak >Priority: Critical > Fix For: 2.7 > > > Currently we don't actually ensure that we write or read some buffer > completely: > org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager#writeCheckpointEntry > org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager#nodeStart > As result we may not write to the disk actual data and after node restart we > can get BufferUnderflowException, like this: > {noformat} > java.nio.BufferUnderflowException > at java.nio.Buffer.nextGetIndex(Buffer.java:506) > at java.nio.HeapByteBuffer.getLong(HeapByteBuffer.java:412) > at > org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readPointer(GridCacheDatabaseSharedManager.java:1915) > at > org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readCheckpointStatus(GridCacheDatabaseSharedManager.java:1892) > at > org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:565) > at > org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.start0(GridCacheDatabaseSharedManager.java:525) > at > org.apache.ignite.internal.processors.cache.GridCacheSharedManagerAdapter.start(GridCacheSharedManagerAdapter.java:61) > at > org.apache.ignite.internal.processors.cache.GridCacheProcessor.start(GridCacheProcessor.java:700) > at > org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1738) > at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:985) > at > org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2014) > at > org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1723) > at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1151) > at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:671) > at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:596) > at org.apache.ignite.Ignition.start(Ignition.java:327) > at org.apache.ignite.ci.db.TcHelperDb.start(TcHelperDb.java:67) > at > org.apache.ignite.ci.web.CtxListener.contextInitialized(CtxListener.java:37) > at > org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:890) > at > org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:532) > at > org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:853) > at > org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:344) > at > org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1501) > at > org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1463) > at > org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:785) > at > org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:261) > at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:545) > at > org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68) > at > org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:131) > at org.eclipse.jetty.server.Server.start(Server.java:452) > at > org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:105) > at > org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:113) > at org.eclipse.jetty.server.Server.doStart(Server.java:419) > at > org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68) > at org.apache.ignite.ci.web.Launcher.runServer(Launcher.java:68) > at > org.apache.ignite.ci.TcHelperJettyLauncher.main(TcHelperJettyLauncher.java:10) > {noformat} > and node become into unrecoverable state. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-5937) Mvcc data structure for SQL queries
[ https://issues.apache.org/jira/browse/IGNITE-5937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-5937: --- Fix Version/s: (was: 2.6) 2.7 > Mvcc data structure for SQL queries > --- > > Key: IGNITE-5937 > URL: https://issues.apache.org/jira/browse/IGNITE-5937 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Semen Boikov >Assignee: Semen Boikov >Priority: Major > Fix For: 2.7 > > > Need implement some data structure to store/query multiple entry versions. > One possible option: > - committed value at first is stored in separate BPlusTree index (there also > need store related tx id to filter out data for non-finished transactions) > - periodically flush data for finished transaction in 'main' index > - for SQL queries need merge result from main index and filtered 'mvcc' > index. Note: it is possible 'mvcc' index will contain multiple committed > versions of the same entry, need make sure only one last one will appear in > result. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-4192) SQL TX: JDBC driver support
[ https://issues.apache.org/jira/browse/IGNITE-4192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-4192: --- Fix Version/s: (was: 2.6) 2.7 > SQL TX: JDBC driver support > --- > > Key: IGNITE-4192 > URL: https://issues.apache.org/jira/browse/IGNITE-4192 > Project: Ignite > Issue Type: Task > Components: jdbc, sql >Reporter: Denis Magda >Assignee: Alexander Paschenko >Priority: Major > Labels: iep-3 > Fix For: 2.7 > > > To support execution of DML and SELECT statements inside of a transaction > started from JDBC driver side. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8740) Support reuse of already initialized Ignite in IgniteSpringBean
[ https://issues.apache.org/jira/browse/IGNITE-8740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16524062#comment-16524062 ] Amir Akhmedov commented on IGNITE-8740: --- Done https://issues.apache.org/jira/browse/IGNITE-8880 > Support reuse of already initialized Ignite in IgniteSpringBean > --- > > Key: IGNITE-8740 > URL: https://issues.apache.org/jira/browse/IGNITE-8740 > Project: Ignite > Issue Type: Improvement > Components: spring >Affects Versions: 2.4 >Reporter: Ilya Kasnacheev >Assignee: Amir Akhmedov >Priority: Blocker > Fix For: 2.6 > > > See > http://apache-ignite-users.70518.x6.nabble.com/IgniteSpringBean-amp-Ignite-SpringTransactionManager-broken-with-2-4-td21667.html#a21724 > (there's patch available) > The idea is to introduce a workaround for users hit by IGNITE-6555, which > unfortunately broke some scenarios. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8070) .NET: FailureHandler should be added to Ignite configuration
[ https://issues.apache.org/jira/browse/IGNITE-8070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8070: --- Fix Version/s: (was: 2.6) 2.7 > .NET: FailureHandler should be added to Ignite configuration > > > Key: IGNITE-8070 > URL: https://issues.apache.org/jira/browse/IGNITE-8070 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Andrey Gura >Assignee: Ivan Daschinskiy >Priority: Major > Labels: .NET, iep-14 > Fix For: 2.7 > > > {{IgniteConfiguration}} class was extended by new methods: > {{setFailureHandler}} and {{getFailureHandler}}. Corresponding changes should > be done in ignite .Net -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8880) Add setIgnite() in SpringCacheManager and SpringTransactionManager
Amir Akhmedov created IGNITE-8880: - Summary: Add setIgnite() in SpringCacheManager and SpringTransactionManager Key: IGNITE-8880 URL: https://issues.apache.org/jira/browse/IGNITE-8880 Project: Ignite Issue Type: Improvement Components: spring Reporter: Amir Akhmedov Fix For: 2.7 Neet to add setIgnite() in SpringCacheManager and SpringTransactionManager to make explicit injection of Ignite instance. For more details refer: https://issues.apache.org/jira/browse/IGNITE-8740?focusedCommentId=16520894&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16520894 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8315) Prevent printing the partition distribution on clients nodes
[ https://issues.apache.org/jira/browse/IGNITE-8315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8315: --- Fix Version/s: (was: 2.6) 2.7 > Prevent printing the partition distribution on clients nodes > > > Key: IGNITE-8315 > URL: https://issues.apache.org/jira/browse/IGNITE-8315 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.6 >Reporter: Vyacheslav Daradur >Assignee: Vyacheslav Daradur >Priority: Major > Fix For: 2.7 > > > The feature of partitions distribution logging has been added recently into > IGNITE-4756. > One of community member [informed that clients nodes now routinely > print|https://issues.apache.org/jira/browse/IGNITE-4756?focusedCommentId=16442633&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16442633]: > {CODE}2018-04-18T14:06:42,963]exchange-worker-#57[GridAffinityAssignmentCache] > Local node affinity assignment distribution is not ideal [cache=data2, > expectedPrimary=256.00, actualPrimary=0, expectedBackups=256.00, > actualBackups=0, warningThreshold=50.00%]{CODE} > Clients nodes shouldn't print partitition distribution since they don't store > data. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6699) Optimize client-side data streamer performance
[ https://issues.apache.org/jira/browse/IGNITE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-6699: --- Fix Version/s: (was: 2.6) 2.7 > Optimize client-side data streamer performance > -- > > Key: IGNITE-6699 > URL: https://issues.apache.org/jira/browse/IGNITE-6699 > Project: Ignite > Issue Type: Task > Components: streaming >Affects Versions: 2.3 >Reporter: Vladimir Ozerov >Assignee: Ivan Fedotov >Priority: Major > Labels: performance > Fix For: 2.7 > > > Currently if a user has several server nodes and a single client node with > single thread pushing data to streamer, he will not be able to load data at > maximum speed. On the other hand, if he start several data loading threads, > throughput will increase. > One of root causes of this is bad data streamer design. Method > {{IgniteDataStreamer.addData(K, V)}} returns new feature for every operation, > this is too fine grained approach. Also it generates a lot of garbage and > causes contention on streamer internals. > Proposed implementation flow: > 1) Compare performance of {{addData(K, V)}} vs {{addData(Collection)}} > methods from one thread in distributed environment. The latter should show > considerably higher throughput. > 2) Users should receive per-batch features, rather than per-key. > 3) Try caching thread data in some collection until it is large enough to > avoid contention and unnecessary allocations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6964) Ignite restart with PDS enabled may cause delays in TTL cleanup worker
[ https://issues.apache.org/jira/browse/IGNITE-6964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-6964: --- Fix Version/s: (was: 2.6) 2.7 > Ignite restart with PDS enabled may cause delays in TTL cleanup worker > -- > > Key: IGNITE-6964 > URL: https://issues.apache.org/jira/browse/IGNITE-6964 > Project: Ignite > Issue Type: Bug > Components: persistence >Reporter: Dmitriy Pavlov >Assignee: Andrew Mashenkov >Priority: Major > Fix For: 2.7 > > > If ignite was restarted and not all TTL entries were evicted, simple restart > does not cause entries to be deleted, even if test waits for some time. > In the same time if some entries were touched by get() TTL eviction starts to > work as it is expected. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8114) Add fail recovery mechanism to tracking pages
[ https://issues.apache.org/jira/browse/IGNITE-8114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8114: --- Fix Version/s: (was: 2.6) (was: 2.5) 2.7 > Add fail recovery mechanism to tracking pages > - > > Key: IGNITE-8114 > URL: https://issues.apache.org/jira/browse/IGNITE-8114 > Project: Ignite > Issue Type: Improvement >Reporter: Eduard Shangareev >Assignee: Eduard Shangareev >Priority: Major > Fix For: 2.7 > > > Now we just assert that last saved tag in tracking page should be not greater > than passed one. > But because of different issues which we don't understand yet, it could > happen. > So, I suggest to handle it by adding new "corruption" state to tracking > state. > If tracking page is in a corrupted state than we would throw an exception on > any querying of the tracking page. Caller will have opportunity to catch the > exception and recover page state. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8266) Remove afterTestsStopped method due to stopAllGrids by default
[ https://issues.apache.org/jira/browse/IGNITE-8266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8266: --- Fix Version/s: (was: 2.6) 2.7 > Remove afterTestsStopped method due to stopAllGrids by default > -- > > Key: IGNITE-8266 > URL: https://issues.apache.org/jira/browse/IGNITE-8266 > Project: Ignite > Issue Type: Sub-task >Affects Versions: 2.5 >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Minor > Labels: test > Fix For: 2.7 > > Attachments: screenshot-1.png > > > Remove this types of method from test in whole ignite-core module. > {code:java} > @Override protected void afterTestsStopped() throws Exception { > super.afterTestsStopped(); > stopAllGrids(); > }{code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8583) DataStorageMetricsMXBean.getOffHeapSize include checkpoint buffer size, this is not obvious
[ https://issues.apache.org/jira/browse/IGNITE-8583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8583: --- Fix Version/s: (was: 2.6) 2.7 > DataStorageMetricsMXBean.getOffHeapSize include checkpoint buffer size, this > is not obvious > --- > > Key: IGNITE-8583 > URL: https://issues.apache.org/jira/browse/IGNITE-8583 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Dmitriy Govorukhin >Assignee: Dmitriy Govorukhin >Priority: Major > Fix For: 2.7 > > > Now DataStorageMetricsMXBean.getOffHeapSize includes checkpoint buffer > inside, on mxbean this is not obvious. > - add new method getUsedCheckpointBufferSize, should show used size. > - should show real size of checkpoint buffer geCheckpointBufferSize -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8751) Possible race on node segmentation.
[ https://issues.apache.org/jira/browse/IGNITE-8751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8751: --- Fix Version/s: (was: 2.6) 2.7 > Possible race on node segmentation. > --- > > Key: IGNITE-8751 > URL: https://issues.apache.org/jira/browse/IGNITE-8751 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Andrew Mashenkov >Assignee: Andrey Gura >Priority: Major > Fix For: 2.7 > > > Segmentation policy may be ignored, probably, due to a race. > See [1] for details. > [1] > [http://apache-ignite-users.70518.x6.nabble.com/Node-pause-for-no-obvious-reason-td21923.html] > Logs from segmented node. > [08:42:42,290][INFO][tcp-disco-sock-reader-#15][TcpDiscoverySpi] Finished > serving remote node connection [rmtAddr=/10.29.42.45:38712, rmtPort=38712 > [08:42:42,290][WARNING][disco-event-worker-#161][GridDiscoveryManager] Local > node SEGMENTED: TcpDiscoveryNode [id=8333aa56-8bf4-4558-a387-809b1d2e2e5b, > addrs=[10.29.42.44, 127.0.0.1], sockAddrs=[sap-datanode1/10.29.42.44:49500, > /127.0.0.1:49500], discPort=49500, order=1, intOrder=1, > lastExchangeTime=1528447362286, loc=true, ver=2.5.0#20180523-sha1:86e110c7, > isClient=false] > [08:42:42,294][SEVERE][tcp-disco-srvr-#2][] Critical system error detected. > Will be handled accordingly to configured handler [hnd=class > o.a.i.failure.StopNodeOrHaltFailureHandler, failureCtx=FailureContext > [type=SYSTEM_WORKER_TERMINATION, err=java.lang.IllegalStateException: Thread > tcp-disco-srvr-#2 is terminated unexpectedly.]] > java.lang.IllegalStateException: Thread tcp-disco-srvr-#2 is terminated > unexpectedly. > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$TcpServer.body(ServerImpl.java:5686) > > at > org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62) > [08:42:42,294][SEVERE][tcp-disco-srvr-#2][] JVM will be halted immediately > due to the failure: [failureCtx=FailureContext > [type=SYSTEM_WORKER_TERMINATION, err=java.lang.IllegalStateException: Thread > tcp-disco-srvr-#2 is terminated unexpectedly.]] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6938) SQL TX: Reads should see own's previous writes
[ https://issues.apache.org/jira/browse/IGNITE-6938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-6938: --- Fix Version/s: (was: 2.6) 2.7 > SQL TX: Reads should see own's previous writes > -- > > Key: IGNITE-6938 > URL: https://issues.apache.org/jira/browse/IGNITE-6938 > Project: Ignite > Issue Type: Task > Components: cache, sql >Reporter: Vladimir Ozerov >Assignee: Igor Seliverstov >Priority: Major > Labels: iep-3 > Fix For: 2.7 > > > If transaction modified a row, subsequent {{SELECT}} statements in the same > TX must return latest pending update instead of last matching committed > version. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8088) Flaky assertion in testJoinClientStaticCacheConfigurationOnJoin for cache presence
[ https://issues.apache.org/jira/browse/IGNITE-8088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8088: --- Fix Version/s: (was: 2.6) 2.7 > Flaky assertion in testJoinClientStaticCacheConfigurationOnJoin for cache > presence > -- > > Key: IGNITE-8088 > URL: https://issues.apache.org/jira/browse/IGNITE-8088 > Project: Ignite > Issue Type: Test >Reporter: Dmitriy Pavlov >Assignee: Pavel Pereslegin >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > > IgniteStandByClusterSuite: > JoinInActiveNodeToActiveCluster.testJoinClientStaticCacheConfigurationOnJoin > (master fail rate 12,8%) > IgniteStandByClusterSuite: > JoinActiveNodeToActiveCluster.testJoinClientStaticCacheConfigurationOnJoin > (master fail rate 10,0%) > Link to test histories: > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-1780719797264285338&branch=%3Cdefault%3E&tab=testDetails > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=5703653634172546268&branch=%3Cdefault%3E&tab=testDetails > {noformat} > java.lang.AssertionError > at org.junit.Assert.fail(Assert.java:86) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.junit.Assert.assertNotNull(Assert.java:621) > at org.junit.Assert.assertNotNull(Assert.java:631) > at > org.apache.ignite.internal.processors.cache.persistence.standbycluster.AbstractNodeJoinTemplate$JoinNodeTestPlanBuilder$9.apply(AbstractNodeJoinTemplate.java:801) > at > org.apache.ignite.internal.processors.cache.persistence.standbycluster.AbstractNodeJoinTemplate$JoinNodeTestPlanBuilder$9.apply(AbstractNodeJoinTemplate.java:791) > at > org.apache.ignite.internal.processors.cache.persistence.standbycluster.AbstractNodeJoinTemplate$JoinNodeTestPlanBuilder$10.run(AbstractNodeJoinTemplate.java:824) > at > org.apache.ignite.internal.processors.cache.persistence.standbycluster.AbstractNodeJoinTemplate$JoinNodeTestPlanBuilder.execute(AbstractNodeJoinTemplate.java:611) > at > org.apache.ignite.internal.processors.cache.persistence.standbycluster.join.JoinInActiveNodeToActiveCluster.testJoinClientStaticCacheConfigurationOnJoin(JoinInActiveNodeToActiveCluster.java:228) > 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:2002) > at > org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133) > at > org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1917) > at java.lang.Thread.run(Thread.java:745) > {noformat} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-4756) Print info about partition distribution to log
[ https://issues.apache.org/jira/browse/IGNITE-4756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-4756: --- Fix Version/s: (was: 2.6) 2.7 > Print info about partition distribution to log > --- > > Key: IGNITE-4756 > URL: https://issues.apache.org/jira/browse/IGNITE-4756 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Taras Ledkov >Assignee: Vyacheslav Daradur >Priority: Minor > Labels: newbie > Fix For: 2.7 > > > Summarize discussions: > Add log message in case partitions distribution is not close to even > distribution: > # Add system property IGNITE_PART_DISTRIBUTION_WARN_THRESHOLD with default > value 0.1 to print warn message only when nodes count differs more then > threshold; > # The statistic is calculated and printed only for the local node; > # Statistic is placed at the {{GridAffinityAssignmentCache#calculate}} and > calculated for new {{idealAssignment}}. > # Message format is > {noformat} > Local node affinity assignment distribution is not ideal [cache=, > expectedPrimary=, > exectedBackups=, > primary=, backups=]. > {noformat} > e.g. for cache with name "test", 2 backups, 4 partition, 3 nodes: > {noformat} > Local node affinity assignment distribution is not ideal [cache=test, > expectedPrimary=1.33 (33.3%), exectedBackups=2.66 (66.66%), primary=1 (25%), > backups=3(75%)]. > {noformat} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8295) Possible deadlock on partition eviction.
[ https://issues.apache.org/jira/browse/IGNITE-8295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8295: --- Fix Version/s: (was: 2.6) 2.7 > Possible deadlock on partition eviction. > > > Key: IGNITE-8295 > URL: https://issues.apache.org/jira/browse/IGNITE-8295 > Project: Ignite > Issue Type: Bug > Components: persistence >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > Fix For: 2.7 > > Attachments: deadlock.stack > > > GridCacheOffheapManager.recreateCacheDataStore() calls > updatePartitionCounter() under partStoreLock which may try to acquire > checkpointReadLock. > recreateCacheDataStore() method can be called with checkpointReadLock (on > GridDhtPartitionsExchangeFuture.updatePartitionFullMap) > or without checkpointReadLock (GridDhtPartitionEvictor thread calls > evictPartitionAsync), > So, checkpoint can cause a deadlock if it happens in between. > Seems, we should acquire checkpointReadLock before partStoreLock. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8401) Assertion error ocurred in JettyRestProcessorAuthenticationWithCredsSelfTest
[ https://issues.apache.org/jira/browse/IGNITE-8401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8401: --- Fix Version/s: (was: 2.6) 2.7 > Assertion error ocurred in JettyRestProcessorAuthenticationWithCredsSelfTest > > > Key: IGNITE-8401 > URL: https://issues.apache.org/jira/browse/IGNITE-8401 > Project: Ignite > Issue Type: Test >Reporter: Dmitriy Pavlov >Assignee: Stanilovsky Evgeny >Priority: Critical > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > Following tests began to fail after merge > https://issues.apache.org/jira/browse/IGNITE-8066 > with assertion added in this ticket. > *IgniteClientTestSuite: > JettyRestProcessorAuthenticationWithCredsSelfTest.testDeactivateActivate[ > (fail rate > 11,1%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=2035731000398727816&branch=%3Cdefault%3E&tab=testDetails]* > *IgniteClientTestSuite: > JettyRestProcessorAuthenticationWithCredsSelfTest.testRemove[ (fail rate > 11,1%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=5513793448643455005&branch=%3Cdefault%3E&tab=testDetails]* > *IgniteClientTestSuite: > JettyRestProcessorAuthenticationWithCredsSelfTest.testRemoveAll[ (fail rate > 11,1%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-1721357182035817455&branch=%3Cdefault%3E&tab=testDetails]* > *IgniteClientTestSuite: > JettyRestProcessorAuthenticationWithCredsSelfTest.testVisorGateway[ (fail > rate > 11,1%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-2028785123619746743&branch=%3Cdefault%3E&tab=testDetails]* > *IgniteClientTestSuite: > JettyRestProcessorAuthenticationWithTokenSelfTest.testDeactivateActivate[ > (fail rate > 11,1%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-334626288130660999&branch=%3Cdefault%3E&tab=testDetails]* > *IgniteClientTestSuite: > JettyRestProcessorAuthenticationWithTokenSelfTest.testRemove[ (fail rate > 11,1%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-5504915680838168777&branch=%3Cdefault%3E&tab=testDetails]* > *IgniteClientTestSuite: > JettyRestProcessorAuthenticationWithTokenSelfTest.testRemoveAll[ (fail rate > 11,1%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=1220211038727255366&branch=%3Cdefault%3E&tab=testDetails]* > > *IgniteClientTestSuite: > JettyRestProcessorAuthenticationWithTokenSelfTest.testVisorGateway[ (fail > rate > 11,1%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=2613252696282859254&branch=%3Cdefault%3E&tab=testDetails]* > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8792) Introduction of TensorFlow integration module
[ https://issues.apache.org/jira/browse/IGNITE-8792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8792: --- Fix Version/s: (was: 2.6) 2.7 > Introduction of TensorFlow integration module > - > > Key: IGNITE-8792 > URL: https://issues.apache.org/jira/browse/IGNITE-8792 > Project: Ignite > Issue Type: New Feature > Components: ml >Reporter: Yury Babak >Assignee: Yury Babak >Priority: Major > Fix For: 2.7 > > > We need module for all code related to this integration. Includes some > patches for TensorFlow. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8781) nio-acceptor threads are indistinguishable in GridNioServer
[ https://issues.apache.org/jira/browse/IGNITE-8781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8781: --- Fix Version/s: (was: 2.6) 2.7 > nio-acceptor threads are indistinguishable in GridNioServer > --- > > Key: IGNITE-8781 > URL: https://issues.apache.org/jira/browse/IGNITE-8781 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Gura >Assignee: Andrey Gura >Priority: Major > Fix For: 2.7 > > > nio-acceptor threads are indistinguishable in {{GridNioServer}}. All threads > have exactly same name. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8708) CacheManagerTest.close_cachesEmpty failed
[ https://issues.apache.org/jira/browse/IGNITE-8708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8708: --- Fix Version/s: (was: 2.6) 2.7 > CacheManagerTest.close_cachesEmpty failed > - > > Key: IGNITE-8708 > URL: https://issues.apache.org/jira/browse/IGNITE-8708 > Project: Ignite > Issue Type: Sub-task >Reporter: Alexander Menshikov >Assignee: Alexander Menshikov >Priority: Major > Labels: iep-21 > Fix For: 2.7 > > > Method {{CacheManager#getCacheNames()}} should throw > {{IllegalStateException}} in case when {{CacheManager}} is closed. But in TCK > 1.0.1 test {{CacheManagerTest.close_cachesEmpty}} expect empty list, which > was incorrect according to spec. > In TCK 1.1.0 test is fixed. > It was known problem, please see comments in {{CacheManager#getCacheNames()}} > on current master. > *But we can't make this test pass in both versions of TCK.* > Also, for the same reason > {{CacheManagerManagementTest#testMultipleCacheManagers}} fails in > {{#teadDown}} section. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-5059) Implement logistic regression
[ https://issues.apache.org/jira/browse/IGNITE-5059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-5059: --- Fix Version/s: (was: 2.6) 2.7 > Implement logistic regression > -- > > Key: IGNITE-5059 > URL: https://issues.apache.org/jira/browse/IGNITE-5059 > Project: Ignite > Issue Type: New Feature > Components: ml >Reporter: Vladisav Jelisavcic >Assignee: Vladisav Jelisavcic >Priority: Major > Labels: important > Fix For: 2.7 > > > Implement logistic regression using ignite ml.math. Model should be able to > incorporate L1 and L2 regularization. > Model should also work with stochastic gradient descent (SGD) as well as > batch and mini-batch gradient descent optimization algorithms. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7249) SQL TX: Commit/rollback active TX before DDL statement processing
[ https://issues.apache.org/jira/browse/IGNITE-7249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-7249: --- Fix Version/s: (was: 2.6) 2.7 > SQL TX: Commit/rollback active TX before DDL statement processing > - > > Key: IGNITE-7249 > URL: https://issues.apache.org/jira/browse/IGNITE-7249 > Project: Ignite > Issue Type: Test > Components: sql >Reporter: Igor Seliverstov >Assignee: Igor Seliverstov >Priority: Major > Labels: sql > Fix For: 2.7 > > > Commit/rollback active TX before DDL statement processing -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6149) Create mvcc prototype application
[ https://issues.apache.org/jira/browse/IGNITE-6149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-6149: --- Fix Version/s: (was: 2.6) 2.7 > Create mvcc prototype application > - > > Key: IGNITE-6149 > URL: https://issues.apache.org/jira/browse/IGNITE-6149 > Project: Ignite > Issue Type: Task > Components: cache >Reporter: Semen Boikov >Assignee: Semen Boikov >Priority: Major > Fix For: 2.7 > > Attachments: MvccTestApp.java > > > Need create simple prototype application to verify major concepts: > - which data should be stored on coordinator and on data nodes > - filtering algorithm for getAll and sql operations > - clean up of committed versions -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7186) SQL TX: Replicated caches support
[ https://issues.apache.org/jira/browse/IGNITE-7186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-7186: --- Fix Version/s: (was: 2.6) 2.7 > SQL TX: Replicated caches support > - > > Key: IGNITE-7186 > URL: https://issues.apache.org/jira/browse/IGNITE-7186 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Igor Seliverstov >Assignee: Sergey Kalashnikov >Priority: Major > Labels: iep-3, sql > Fix For: 2.7 > > > Need to implement query execution and update on a near node. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8789) Add a call to the FailureHandler for an error with meta-data.
[ https://issues.apache.org/jira/browse/IGNITE-8789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8789: --- Fix Version/s: (was: 2.6) 2.7 > Add a call to the FailureHandler for an error with meta-data. > - > > Key: IGNITE-8789 > URL: https://issues.apache.org/jira/browse/IGNITE-8789 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitriy Gladkikh >Assignee: Andrey Gura >Priority: Critical > Fix For: 2.7 > > > This is a critical situation, corresponding exception should be propagated to > handler to make necessary actions. > Need to add a call to the FailureHandler if the specified error occurs. > When processing a message in the GridCacheIoManager#onMessage0 method, an > exception was thrown: Failed to process message > [senderId=f815a46c-8973-4cda-ac77-51325e731cda, messageType=class > o.a.i.i.processors.cache.distributed.near.GridNearTxFinishRequest] > An error occurred during the error logging associated with the meta-data: > Cannot find schema for object with compact footer [typeId=1599442645, > schemaId=-1705721149] > The original exception was lost. > {code:java} > 2018-06-13 > 09:04:01.593[ERROR][sys-stripe-22-#23%DPL_GRID%DplGridNodeName%][o.a.i.i.p.cache.GridCacheIoManager] > Failed to process message [senderId=f815a46c-8973-4cda-ac77-51325e731cda, > messageType=class > o.a.i.i.processors.cache.distributed.near.GridNearTxFinishRequest] > org.apache.ignite.IgniteException: Failed to create string representation of > binary object. > at > org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:1028) > at > org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:826) > at > org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:783) > at > org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxFinishRequest.toString(GridDistributedTxFinishRequest.java:561) > at > org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishRequest.toString(GridNearTxFinishRequest.java:221) > at java.lang.String.valueOf(String.java:2994) > at java.lang.StringBuilder.append(StringBuilder.java:131) > 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:1556) > at > org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184) > 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:1091) > at > org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:511) > at java.lang.Thread.run(Thread.java:745) > Caused by: org.apache.ignite.IgniteException: Failed to create string > representation of binary object. > at > org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:1028) > at > org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:826) > at > org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:783) > at > org.apache.ignite.internal.processors.cache.transactions.IgniteTxStateImpl.toString(IgniteTxStateImpl.java:466) > at java.lang.String.valueOf(String.java:2994) > at > org.apache.ignite.internal.util.GridStringBuilder.a(GridStringBuilder.java:101) > at > org.apache.ignite.internal.util.tostring.SBLimitedLength.a(SBLimitedLength.java:88) > at > org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:939) > at > org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:1005) > ... 18 common frames omitted > Caused by: org.apache.ignite.IgniteException: Failed to create string > representation of binary object. > at > org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl(Gr
[jira] [Updated] (IGNITE-8540) Slow rebalance with asynchronous eviction
[ https://issues.apache.org/jira/browse/IGNITE-8540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8540: --- Fix Version/s: (was: 2.6) 2.7 > Slow rebalance with asynchronous eviction > - > > Key: IGNITE-8540 > URL: https://issues.apache.org/jira/browse/IGNITE-8540 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Major > Fix For: 2.7 > > > Node start eviction after join to grid even it is not in baseline. > If a joining node does not belong to the current grid baseline, we can remove > the local storage because the node will start to evict local partitions > anyway. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8566) Web console: replace extract-text-webpack-plugin with mini-css-extract-plugin
[ https://issues.apache.org/jira/browse/IGNITE-8566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8566: --- Fix Version/s: (was: 2.6) 2.7 > Web console: replace extract-text-webpack-plugin with mini-css-extract-plugin > - > > Key: IGNITE-8566 > URL: https://issues.apache.org/jira/browse/IGNITE-8566 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Andrey Novikov >Priority: Major > Fix For: 2.7 > > > The extract-text-webpack-plugin documentations says that "Since webpack v4 > the extract-text-webpack-plugin should not be used for css. Use > mini-css-extract-plugin instead.", so I think that's what should be done. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7266) SQL TX: Joins return duplicated result when MVCC is disabled
[ https://issues.apache.org/jira/browse/IGNITE-7266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-7266: --- Fix Version/s: (was: 2.6) 2.7 > SQL TX: Joins return duplicated result when MVCC is disabled > > > Key: IGNITE-7266 > URL: https://issues.apache.org/jira/browse/IGNITE-7266 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Vladimir Ozerov >Assignee: Roman Kondakov >Priority: Major > Fix For: 2.7 > > > Affected tests: > {{IgniteCacheJoinQueryWithAffinityKeyTest}} > {{IgniteCacheCrossCacheJoinRandomTest}} > All tests failed for the same reason: {{expected=X, actual=2*X}}. Looks like > we return too much results in some cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8711) IgniteStandByClientReconnectToNewClusterTest#testInactiveClientReconnectToActiveCluster fails in master
[ https://issues.apache.org/jira/browse/IGNITE-8711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8711: --- Fix Version/s: (was: 2.6) 2.7 > IgniteStandByClientReconnectToNewClusterTest#testInactiveClientReconnectToActiveCluster > fails in master > --- > > Key: IGNITE-8711 > URL: https://issues.apache.org/jira/browse/IGNITE-8711 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Chugunov >Assignee: Sergey Chugunov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > Test fails on TC as well as locally. > In master it started failing after this set of changes was applied: > https://ci.ignite.apache.org/viewLog.html?buildId=1323957&tab=buildChangesDiv&buildTypeId=IgniteTests24Java8_ActivateDeactivateCluster -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8696) control.sh utility does not show atomicity mode
[ https://issues.apache.org/jira/browse/IGNITE-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8696: --- Fix Version/s: (was: 2.6) 2.7 > control.sh utility does not show atomicity mode > --- > > Key: IGNITE-8696 > URL: https://issues.apache.org/jira/browse/IGNITE-8696 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Sergey Kosarev >Assignee: Sergey Kosarev >Priority: Minor > Fix For: 2.7 > > > In current implementation cache viewer list function: > ./control.sh --cache list > does not show atomicity mode for caches. Please add this to the output. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8488) Web console: scroll bar doesn't work inside cluster selector component
[ https://issues.apache.org/jira/browse/IGNITE-8488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8488: --- Fix Version/s: (was: 2.6) 2.7 > Web console: scroll bar doesn't work inside cluster selector component > -- > > Key: IGNITE-8488 > URL: https://issues.apache.org/jira/browse/IGNITE-8488 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > > List of clusters can be scrolled by mouse wheel but can't by dragging the > scrollbar. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-5823) Need to remove CacheAtomicUpdateTimeoutException
[ https://issues.apache.org/jira/browse/IGNITE-5823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-5823: --- Fix Version/s: (was: 2.6) 2.7 > Need to remove CacheAtomicUpdateTimeoutException > > > Key: IGNITE-5823 > URL: https://issues.apache.org/jira/browse/IGNITE-5823 > Project: Ignite > Issue Type: Task >Reporter: Yakov Zhdanov >Assignee: Sergey Dorozhkin >Priority: Minor > Labels: newbie > Fix For: 2.7 > > > And releated - CacheAtomicUpdateTimeoutCheckedException > These exceptions are not used any more and can be removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8467) minSize filter for transactions utility control.sh doesn't work
[ https://issues.apache.org/jira/browse/IGNITE-8467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8467: --- Fix Version/s: (was: 2.6) 2.7 > minSize filter for transactions utility control.sh doesn't work > --- > > Key: IGNITE-8467 > URL: https://issues.apache.org/jira/browse/IGNITE-8467 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Dmitry Sherstobitov >Assignee: Alexand Polyakov >Priority: Minor > Fix For: 2.7 > > Attachments: TC 01 recheck.png, TC 02 recheck.png, TC 03 recheck.png, > TC 04-05 recheck.png, TC.png > > > I have following output when define control.sh utility with minSize filter > Looks like it doesn't work. > {code:java} > Control utility --tx minDuration 15 minSize 10 order SIZE > Control utility > 2018 Copyright(C) Apache Software Foundation > User: > > Matching transactions: > [16:52:30][:688] TcpDiscoveryNode [id=02f47e9a-efca-4d8c-a49f-3de4ca82d3ee, > addrs=[0:0:0:0:0:0:0:1%lo, 127.0.0.1, 172.17.0.1, 172.25.1.40], > sockAddrs=[/172.17.0.1:0, /0:0:0:0:0:0:0:1%lo:0, > lab40.gridgain.local/172.25.1.40:0, /127.0.0.1:0], discPort=0, order=5, > intOrder=5, lastExchangeTime=1525960350163, loc=false, > ver=2.5.1#20180427-sha1:48601cbd, isClient=true] > Tx: [xid=0f1d25a4361--0831-2c15--0005, label=tx_5, > state=ACTIVE, duration=16, isolation=REPEATABLE_READ, > concurrency=PESSIMISTIC, timeout=0, size=1, dhtNodes=[63e05a51]] > Tx: [xid=05ad25a4361--0831-2c15--0005, label=tx_6, > state=ACTIVE, duration=15, isolation=REPEATABLE_READ, > concurrency=PESSIMISTIC, timeout=0, size=1, dhtNodes=[473df74e]] > Tx: [xid=7b2b25a4361--0831-2c15--0005, label=tx_1, > state=ACTIVE, duration=20, isolation=REPEATABLE_READ, > concurrency=PESSIMISTIC, timeout=0, size=1, dhtNodes=[63e05a51]] > Tx: [xid=73ab25a4361--0831-2c15--0005, label=tx_2, > state=ACTIVE, duration=19, isolation=REPEATABLE_READ, > concurrency=PESSIMISTIC, timeout=0, size=1, dhtNodes=[473df74e]] > Tx: [xid=47ca25a4361--0831-2c15--0005, label=tx_0, > state=ACTIVE, duration=22, isolation=REPEATABLE_READ, > concurrency=PESSIMISTIC, timeout=0, size=1, dhtNodes=[63e05a51]] > Tx: [xid=b0ac25a4361--0831-2c15--0005, label=tx_4, > state=ACTIVE, duration=17, isolation=REPEATABLE_READ, > concurrency=PESSIMISTIC, timeout=0, size=1, dhtNodes=[473df74e]] > Tx: [xid=3a1c25a4361--0831-2c15--0005, label=tx_3, > state=ACTIVE, duration=18, isolation=REPEATABLE_READ, > concurrency=PESSIMISTIC, timeout=0, size=1, dhtNodes=[0cd15184]]{code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7975) SQL TX: allow batch inserts
[ https://issues.apache.org/jira/browse/IGNITE-7975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-7975: --- Fix Version/s: (was: 2.6) 2.7 > SQL TX: allow batch inserts > --- > > Key: IGNITE-7975 > URL: https://issues.apache.org/jira/browse/IGNITE-7975 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Vladimir Ozerov >Assignee: Alexander Paschenko >Priority: Major > Fix For: 2.7 > > > Need to implement proper handling for batch inserts. It is disabled > currently, see {{DmlStatementsProcessor#updateSqlFieldsBatched}}. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-3479) Coordinator(s) for global transaction ordering
[ https://issues.apache.org/jira/browse/IGNITE-3479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-3479: --- Fix Version/s: (was: 2.6) 2.7 > Coordinator(s) for global transaction ordering > -- > > Key: IGNITE-3479 > URL: https://issues.apache.org/jira/browse/IGNITE-3479 > Project: Ignite > Issue Type: Task > Components: cache >Reporter: Alexey Goncharuk >Assignee: Semen Boikov >Priority: Major > Fix For: 2.7 > > > Current transaction ID will not work for SQL MVCC ordering because two > transaction IDs are not in total order across the cluster. > One of the approaches is to have a dedicated coordinator which will assign a > continuously growing transaction ID for each committed transaction. This ID > must be acquired by each transaction at the last step of PREPARE stage. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8664) Encoding categorical features with One-of-K Encoder
[ https://issues.apache.org/jira/browse/IGNITE-8664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8664: --- Fix Version/s: (was: 2.6) 2.7 > Encoding categorical features with One-of-K Encoder > --- > > Key: IGNITE-8664 > URL: https://issues.apache.org/jira/browse/IGNITE-8664 > Project: Ignite > Issue Type: New Feature > Components: ml >Reporter: Yury Babak >Assignee: Aleksey Zinoviev >Priority: Major > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8798) Move transaction recovery logging to INFO level
[ https://issues.apache.org/jira/browse/IGNITE-8798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8798: --- Fix Version/s: (was: 2.6) 2.7 > Move transaction recovery logging to INFO level > --- > > Key: IGNITE-8798 > URL: https://issues.apache.org/jira/browse/IGNITE-8798 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Assignee: Evgenii Zagumennov >Priority: Major > Fix For: 2.7 > > > Currently we log transaction recovery state changes to {{DEBUG}}, however, > this information is critically important for production deployment and > incident analysis. I suggest to move corresponding logging > ({{GridCacheTxRecoveryFuture}} and surrounding code) to {{INFO}} level. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8657) Simultaneous start of bunch of client nodes may lead to some clients hangs
[ https://issues.apache.org/jira/browse/IGNITE-8657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8657: --- Fix Version/s: (was: 2.6) 2.7 > Simultaneous start of bunch of client nodes may lead to some clients hangs > -- > > Key: IGNITE-8657 > URL: https://issues.apache.org/jira/browse/IGNITE-8657 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Sergey Chugunov >Assignee: Sergey Chugunov >Priority: Major > Fix For: 2.7 > > > h3. Description > PartitionExchangeManager uses a system property > *IGNITE_EXCHANGE_HISTORY_SIZE* to manage max number of exchange objects and > optimize memory consumption. > Default value of the property is 1000 but in scenarios with many caches and > partitions it is reasonable to set exchange history size to a smaller values > around few dozens. > Then if user starts up at once more client nodes than history size some > clients may hang because their exchange information was preempted and no > longer available. > h3. Workarounds > Two workarounds are possible: > * Do not start at once more clients than history size. > * Restart hanging client node. > h3. Solution > Forcing client node to reconnect when server detected loosing its exchange > information prevents client nodes hanging. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7809) Ignite PDS 2 & PDS 2 Direct IO: stable failures of IgniteWalFlushDefaultSelfTest
[ https://issues.apache.org/jira/browse/IGNITE-7809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-7809: --- Fix Version/s: (was: 2.6) 2.7 > Ignite PDS 2 & PDS 2 Direct IO: stable failures of > IgniteWalFlushDefaultSelfTest > > > Key: IGNITE-7809 > URL: https://issues.apache.org/jira/browse/IGNITE-7809 > Project: Ignite > Issue Type: Task > Components: persistence >Affects Versions: 2.4 >Reporter: Dmitriy Pavlov >Assignee: Ilya Lantukh >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > Probably after last WAL default changes 'IGNITE-7594 Fixed performance drop > after WAL optimization for FSYNC' 2 tests in 2 build configs began to fail >Ignite PDS 2 (Direct IO) [ tests 2 ] > IgnitePdsNativeIoTestSuite2: > IgniteWalFlushDefaultSelfTest.testFailAfterStart (fail rate 13,0%) > IgnitePdsNativeIoTestSuite2: > IgniteWalFlushDefaultSelfTest.testFailWhileStart (fail rate 13,0%) >Ignite PDS 2 [ tests 2 ] > IgnitePdsTestSuite2: IgniteWalFlushDefaultSelfTest.testFailAfterStart > (fail rate 8,4%) > IgnitePdsTestSuite2: IgniteWalFlushDefaultSelfTest.testFailWhileStart > (fail rate 8,4%) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6353) Integrate mvcc support in scan query protocol
[ https://issues.apache.org/jira/browse/IGNITE-6353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-6353: --- Fix Version/s: (was: 2.6) 2.7 > Integrate mvcc support in scan query protocol > - > > Key: IGNITE-6353 > URL: https://issues.apache.org/jira/browse/IGNITE-6353 > Project: Ignite > Issue Type: Task > Components: cache >Reporter: Semen Boikov >Assignee: Roman Kondakov >Priority: Major > Fix For: 2.7 > > > Need integrate mvcc support in scan query protocol: > - request current ID and list of active txs from coordinator > - pass this info in query requests and in cache iterators > - notify coordinator after query completed -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8764) Informatica can not connect to a cluster using ODBC driver on Windows
[ https://issues.apache.org/jira/browse/IGNITE-8764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8764: --- Fix Version/s: (was: 2.6) 2.7 > Informatica can not connect to a cluster using ODBC driver on Windows > - > > Key: IGNITE-8764 > URL: https://issues.apache.org/jira/browse/IGNITE-8764 > Project: Ignite > Issue Type: Bug > Components: odbc >Affects Versions: 2.5 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Labels: odbc > Fix For: 2.7 > > > It crashes or returns garbage on attempt to connect to a server node. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8702) Crash in ODBC driver under Informatica connection checker on Linux
[ https://issues.apache.org/jira/browse/IGNITE-8702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8702: --- Fix Version/s: (was: 2.6) 2.7 > Crash in ODBC driver under Informatica connection checker on Linux > -- > > Key: IGNITE-8702 > URL: https://issues.apache.org/jira/browse/IGNITE-8702 > Project: Ignite > Issue Type: Bug > Components: odbc >Affects Versions: 2.4 >Reporter: Ilya Kasnacheev >Assignee: Igor Sapego >Priority: Major > Fix For: 2.7 > > > I'm trying to connect Informatica to Ignite via ODBC. > When I try to specify my connection as a ready-made DSN by its name, it > starts connecting to remote but then fails: > {code} > [ikasnacheev@lab15 ODBC7.1]$ IGNITE_ODBC_LOG_PATH=/home/ikasnacheev/odbc2.log > INFA_HOME=/storage/ssd/ikasnacheev > LD_LIBRARY_PATH=/storage/ssd/ikasnacheev/ODBC7.1/lib:$LD_LIBRARY_PATH:/storage/ssd/ikasnacheev/services/shared/bin > /storage/ssd/ikasnacheev/java/jre/bin/java -d64 -DpwdDecrypt=true > -DconnectionName=Lab -DuserName=lab -Dpassword="nq/Jypc7Q2EhoQ2iAQlOCA==" > -DconnectionString=LABignite -DdataStoreType=ODBC > -DINFA_HOME=/storage/ssd/ikasnacheev -classpath > '.:/storage/ssd/ikasnacheev/services/AdministratorConsole/webapps/administrator/WEB-INF/lib/*:/storage/ssd/ikasnacheev/services/shared/jars/platform/*:/storage/ssd/ikasnacheev/services/shared/jars/thirdparty/*:/storage/ssd/ikasnacheev/plugins/osgi/*:/storage/ssd/ikasnacheev/plugins/infa/*:/storage/ssd/ikasnacheev/plugins/dynamic/*' > com.informatica.adminconsole.app.chain.commands.TestODBCConnection > ... > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x7faeb806d5e4, pid=26471, tid=140392269498112 > # > # JRE version: Java(TM) SE Runtime Environment (8.0_77-b03) (build > 1.8.0_77-b03) > # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.77-b03 mixed mode > linux-amd64 compressed oops) > # Problematic frame: > # C [libignite-odbc.so+0x2c5e4] > ignite::odbc::system::TcpSocketClient::Connect(char const*, unsigned short, > int, ignite::odbc::diagnostic::Diagnosable&)+0x7b4 > {code} > The contents of Ignite driver log file as follows: > {code} > SQLAllocEnv: SQLAllocEnv called > SQLSetEnvAttr: SQLSetEnvAttr called > AddStatusRecord: Adding new record: ODBC version is not supported., rowNum: > 0, columnNum: 0 > SQLAllocConnect: SQLAllocConnect called > SQLGetInfo: SQLGetInfo called: 77 (SQL_DRIVER_ODBC_VER), 7faec08d1450, 6, > 7faf9f5a29ee > GetInfo: SQLGetInfo called: 77 (SQL_DRIVER_ODBC_VER), 7faec08d1450, 6, > 7faf9f5a29ee > SQLSetConnectOption: SQLSetConnectOption called > SQLConnect: SQLConnect called > SQLConnect: DSN: LABignite > Connect: Host: 172.25.1.16, port: 10800 > Connect: Addr: 172.25.1.16 > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8468) Adding and searching UUIDs in index tree produces a lot of garbage
[ https://issues.apache.org/jira/browse/IGNITE-8468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8468: --- Fix Version/s: (was: 2.6) 2.7 > Adding and searching UUIDs in index tree produces a lot of garbage > -- > > Key: IGNITE-8468 > URL: https://issues.apache.org/jira/browse/IGNITE-8468 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > Labels: performance > Fix For: 2.7 > > > Seems, optimization for UUIDs was missed in IGNITE-5918. > PFA patch. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-172) [Test] [Rare] GridTcpCommunicationSpiRecoveryAckSelfTest and IgniteTcpCommunicationRecoveryAckClosureSelfTest
[ https://issues.apache.org/jira/browse/IGNITE-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-172: -- Fix Version/s: (was: 2.6) 2.7 > [Test] [Rare] GridTcpCommunicationSpiRecoveryAckSelfTest and > IgniteTcpCommunicationRecoveryAckClosureSelfTest > - > > Key: IGNITE-172 > URL: https://issues.apache.org/jira/browse/IGNITE-172 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 1.5.0.final >Reporter: Irina Vasilinets >Assignee: Amelchev Nikita >Priority: Major > Labels: MakeTeamcityGreenAgain, Muted_test > Fix For: 2.7 > > > GridTcpCommunicationSpiRecoveryAckSelfTest.testQueueOverflow and > GridTcpCommunicationSpiTcpNoDelayOffSelfTest.testSendToManyNodes > fail sometimes. > IgniteTcpCommunicationRecoveryAckClosureSelfTest.testQueueOverflow - 1 from 10 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8691) Get rid of tests jar artifact in ignite-zookeeper module
[ https://issues.apache.org/jira/browse/IGNITE-8691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8691: --- Fix Version/s: (was: 2.6) 2.7 > Get rid of tests jar artifact in ignite-zookeeper module > > > Key: IGNITE-8691 > URL: https://issues.apache.org/jira/browse/IGNITE-8691 > Project: Ignite > Issue Type: Bug > Components: zookeeper >Affects Versions: 2.5 >Reporter: Pavel Kovalenko >Assignee: Pavel Kovalenko >Priority: Major > Fix For: 2.7 > > > Currently Ignite building process produces > {noformat} > org/apache/ignite/ignite-zookeeper/2.X.X/ignite-zookeeper-2.X.X-tests.jar > {noformat} > artifact which seems to be useless and should be excluded as result of > packaging. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8138) Incorrect uptime in Ignite metrics for long running server node (1+ days)
[ https://issues.apache.org/jira/browse/IGNITE-8138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8138: --- Fix Version/s: (was: 2.6) 2.7 > Incorrect uptime in Ignite metrics for long running server node (1+ days) > - > > Key: IGNITE-8138 > URL: https://issues.apache.org/jira/browse/IGNITE-8138 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.1, 2.4 >Reporter: Max Shonichev >Assignee: Sergey Skudnov >Priority: Major > Fix For: 2.7 > > Attachments: Screenshot from 2018-04-08 23-37-39.png, Screenshot from > 2018-04-16 09-33-24.png > > > Ignite prints a metrics to the log with uptime, formatted as 'XX:YY:ZZ:TTT'. > It looks, like XX corresponds to hours, YY to minutes, ZZ to seconds, however > if we filter uptime metric from a long running server (few days), we would > see that : > {noformat} > ^-- Node [id=684d2761, name=null, uptime=00:01:00:009] > ^-- Node [id=684d2761, name=null, uptime=00:02:00:009] > ^-- Node [id=684d2761, name=null, uptime=00:03:00:009] > ^-- Node [id=684d2761, name=null, uptime=00:04:00:021] > ... > ^-- Node [id=684d2761, name=null, uptime=23:58:08:391] > ^-- Node [id=684d2761, name=null, uptime=23:59:08:393] > ^-- Node [id=684d2761, name=null, uptime=24:00:08:395] > ^-- Node [id=684d2761, name=null, uptime=24:01:08:406] > ... > ^-- Node [id=684d2761, name=null, uptime=59:59:23:542] > ^-- Node [id=684d2761, name=null, uptime=00:00:23:554] > ... > {noformat} > BUG: > 1. hours do not rollover at 23:59:59 > 2. there's no simple means for user to get uptime days, because hours do > actually rollover after 59:59:59 > what is expected: > 1. add a day counter, init with 0 > 2. make hours correctly rollover after full day (24hrs) run > {noformat} > ^-- Node [id=684d2761, name=null, uptime=0:00:01:00:009] > ... > ^-- Node [id=684d2761, name=null, uptime=0:23:59:00:009] > ^-- Node [id=684d2761, name=null, uptime=1:00:00:00:009] > ... > {noformat} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6565) Use long type for size and keySize in cache metrics
[ https://issues.apache.org/jira/browse/IGNITE-6565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-6565: --- Fix Version/s: (was: 2.6) 2.7 > Use long type for size and keySize in cache metrics > --- > > Key: IGNITE-6565 > URL: https://issues.apache.org/jira/browse/IGNITE-6565 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: Ilya Kasnacheev >Assignee: Alexander Menshikov >Priority: Major > Labels: easyfix > Fix For: 2.7 > > > Currently it's int so for large caches there's no way to convey correct value. > Should introduce getSizeLong() and getKeySizeLong() > Also introduce the same in .Net and make sure that compatibility not broken > when passing OP_LOCAL_METRICS and OP_GLOBAL_METRICS. > BTW do we need keySize at all? What's it for? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7280) SQL TX: improve JDBC test coverage
[ https://issues.apache.org/jira/browse/IGNITE-7280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-7280: --- Fix Version/s: (was: 2.6) 2.7 > SQL TX: improve JDBC test coverage > -- > > Key: IGNITE-7280 > URL: https://issues.apache.org/jira/browse/IGNITE-7280 > Project: Ignite > Issue Type: Bug >Reporter: Vladimir Ozerov >Assignee: Alexander Paschenko >Priority: Major > Fix For: 2.7 > > > The following cases must be handled: > 1) Single update stmt in TX > 2) Multiple update stmts in TX > 3) Changes to multiple caches in TX > 4) Mix of both selects and updates (e.g. get data from select and then build > updates based on it) > 5) Different operation types - INSERT, UPDATE, MERGE (take in count various > DML optimizations to ensure that as much code paths are covered as possible) > 6) Batch updates > 7) Joins (both co-located and distributed) > 8) Different cache modes - PARTITIONED, REPLICATED > 9) Different backup counts > 10) Communication with client node vs communication with server node > 11) Both implicit and explicit transactions -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8469) Non-heap memory leak for calling cluster activation multi times
[ https://issues.apache.org/jira/browse/IGNITE-8469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8469: --- Fix Version/s: (was: 2.6) 2.7 > Non-heap memory leak for calling cluster activation multi times > --- > > Key: IGNITE-8469 > URL: https://issues.apache.org/jira/browse/IGNITE-8469 > Project: Ignite > Issue Type: Bug > Components: persistence >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Fix For: 2.7 > > > Calling multiple time cluster (with enabled persistence and started client > nodes) activation {{ig3CB.cluster().active(true);}} leads to non-heap memory > leak. > Line > {{org/apache/ignite/internal/pagemem/impl/PageMemoryNoStoreImpl.java:234}} > looks suspicious because of in case method > {{org.apache.ignite.internal.pagemem.impl.PageMemoryNoStoreImpl#start}} > callled multi times (e.g. activate(true) called multi times) we lost info > about allocated regions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8050) Throw a meaningful exception when user issues TX SQL keyword with MVCC turned off
[ https://issues.apache.org/jira/browse/IGNITE-8050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8050: --- Fix Version/s: (was: 2.6) 2.7 > Throw a meaningful exception when user issues TX SQL keyword with MVCC turned > off > - > > Key: IGNITE-8050 > URL: https://issues.apache.org/jira/browse/IGNITE-8050 > Project: Ignite > Issue Type: Task > Components: jdbc, sql >Reporter: Alexander Paschenko >Assignee: Alexander Paschenko >Priority: Major > Fix For: 2.7 > > > An exception must be thrown when the user issues TX SQL command (BEGIN, > COMMIT, ROLLBACK) in absence of MVCC - ingoring these may be confusing and > can lead to SQL engine behavior to behaving quite differently from what the > user expects, esp. in terms of data consistency. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8544) WAL disabling during rebalance mechanism uses wrong topology version in case of exchanges merge
[ https://issues.apache.org/jira/browse/IGNITE-8544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8544: --- Fix Version/s: (was: 2.6) 2.7 > WAL disabling during rebalance mechanism uses wrong topology version in case > of exchanges merge > --- > > Key: IGNITE-8544 > URL: https://issues.apache.org/jira/browse/IGNITE-8544 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.5 >Reporter: Pavel Kovalenko >Assignee: Pavel Kovalenko >Priority: Critical > Fix For: 2.7 > > > After exchange is done, we're using initial exchange version to determine > topology version on what rebalance should be finished and save it. After > rebalance finishing we check current topology version and saved version and > if they are equal, we enable WAL, own partitions and do checkpoint. In other > case we do nothing, because of topology change. > In case of exchanges merge we're saving old topology version (before merge) > and it leads to ignoring logic of enabling WAL and etc, because check on > topology version will be always false-negative. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8235) Implement execution of selected part of SQL query
[ https://issues.apache.org/jira/browse/IGNITE-8235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8235: --- Fix Version/s: (was: 2.6) 2.7 > Implement execution of selected part of SQL query > - > > Key: IGNITE-8235 > URL: https://issues.apache.org/jira/browse/IGNITE-8235 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Alexander Kalinin >Assignee: Alexey Kuznetsov >Priority: Minor > Fix For: 2.7 > > > If we had 3 SQL rows in the notebook, and selected one and clicked execute. > We should only execute the highlighted row. If no row is highlighted, then > all rows should be executed. That's a standard feature of graphical SQL tools. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8422) Zookeeper discovery split brain detection shouldn't consider client nodes
[ https://issues.apache.org/jira/browse/IGNITE-8422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8422: --- Fix Version/s: (was: 2.6) 2.7 > Zookeeper discovery split brain detection shouldn't consider client nodes > - > > Key: IGNITE-8422 > URL: https://issues.apache.org/jira/browse/IGNITE-8422 > Project: Ignite > Issue Type: Bug > Components: zookeeper >Affects Versions: 2.5 >Reporter: Pavel Kovalenko >Assignee: Pavel Kovalenko >Priority: Major > Fix For: 2.7 > > > Currently Zookeeper discovery checks each splitted cluster on full > connectivity taking into account client nodes. This is not correct, because > server and client nodes may use different networks to connect to each other. > It means that there can be client which sees both parts of splitted cluster > and breaks split brain recovery - full connected part of server nodes will be > never find. > We should exclude client nodes from split brain analysis and improve split > brain tests to make them truly fair. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-5965) Ignite Basic: Flaky failure of GridServiceProcessorMultiNodeConfigSelfTest.testDeployOnEachNodeUpdateTopology
[ https://issues.apache.org/jira/browse/IGNITE-5965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-5965: --- Fix Version/s: (was: 2.6) 2.7 > Ignite Basic: Flaky failure of > GridServiceProcessorMultiNodeConfigSelfTest.testDeployOnEachNodeUpdateTopology > -- > > Key: IGNITE-5965 > URL: https://issues.apache.org/jira/browse/IGNITE-5965 > Project: Ignite > Issue Type: Test >Affects Versions: 2.1 >Reporter: Ivan Rakov >Assignee: Andrew Medvedev >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > Attachments: log.txt > > > Test has 85% success rate in master: > http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests&testNameId=-2642357454043293898&tab=testDetails&branch_Ignite20Tests=%3Cdefault%3E > Flaky failure is reproduced locally with similar success rate (24/30, Win 10). > {noformat} > junit.framework.AssertionFailedError: > Expected :4 > Actual :5 > > at junit.framework.Assert.fail(Assert.java:57) > at junit.framework.Assert.failNotEquals(Assert.java:329) > at junit.framework.Assert.assertEquals(Assert.java:78) > at junit.framework.Assert.assertEquals(Assert.java:234) > at junit.framework.Assert.assertEquals(Assert.java:241) > at junit.framework.TestCase.assertEquals(TestCase.java:409) > at > org.apache.ignite.internal.processors.service.GridServiceProcessorAbstractSelfTest.checkCount(GridServiceProcessorAbstractSelfTest.java:765) > at > org.apache.ignite.internal.processors.service.GridServiceProcessorMultiNodeConfigSelfTest.checkDeployOnEachNodeUpdateTopology(GridServiceProcessorMultiNodeConfigSelfTest.java:287) > at > org.apache.ignite.internal.processors.service.GridServiceProcessorMultiNodeConfigSelfTest.testDeployOnEachNodeUpdateTopology(GridServiceProcessorMultiNodeConfigSelfTest.java:144) > 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:2000) > at > org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132) > at > org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915) > at java.lang.Thread.run(Thread.java:745) > {noformat} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8334) Web console: add ability to show/hide password field value
[ https://issues.apache.org/jira/browse/IGNITE-8334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8334: --- Fix Version/s: (was: 2.6) 2.7 > Web console: add ability to show/hide password field value > -- > > Key: IGNITE-8334 > URL: https://issues.apache.org/jira/browse/IGNITE-8334 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov >Priority: Minor > Fix For: 2.7 > > Attachments: eye-icon-close.svg, eye-icon-open.svg > > > The ability to toggle password inputs value visibility will improve the UX of > several forms. Since most of password inputs are located on sign-in and > profile pages, for now it'll be enough to update inputs used on these pages > only. > The button should: > 1. Has opened eye icon when password value is visible. > 2. Has closed eye icon when password value is hidden (i.e. default dots). > 3. Be placed at the right side of the input and to the right of validation > error message. That means that error message will be place a bit more to the > left compared to text inputs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8795) Add ability to start and maintain TensorFlow cluster on top of Apache Ignite
[ https://issues.apache.org/jira/browse/IGNITE-8795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8795: --- Fix Version/s: (was: 2.6) 2.7 > Add ability to start and maintain TensorFlow cluster on top of Apache Ignite > > > Key: IGNITE-8795 > URL: https://issues.apache.org/jira/browse/IGNITE-8795 > Project: Ignite > Issue Type: New Feature > Components: ml >Reporter: Yury Babak >Assignee: Anton Dmitriev >Priority: Major > Fix For: 2.7 > > > As described in the [design > document|https://docs.google.com/document/d/1jROIahK1rc7bSgOvhJhfpMqIGvht_IE8zn5NAt6x8ks/edit?usp=sharing], > Distributed TensorFlow is based on TensorFlow cluster concept. It's a set of > TensorFlow processes started among the cluster and available througth the > gRPC interfaces. It's assumed that these processes contain heavy operations > that requires data to be stored locally on the nodes where the processes > running. Apache Ignite admits the data to be moved from one node to another > as result of node failure of rebalancing. As result the TensorFlow cluster > should be changed dynamically as well as TensorFlow Cache (follow-the-data > strategy). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6252) Cassandra Cache Store Session does not retry if prepare statement failed
[ https://issues.apache.org/jira/browse/IGNITE-6252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-6252: --- Fix Version/s: (was: 2.6) 2.7 > Cassandra Cache Store Session does not retry if prepare statement failed > > > Key: IGNITE-6252 > URL: https://issues.apache.org/jira/browse/IGNITE-6252 > Project: Ignite > Issue Type: Bug > Components: cassandra >Affects Versions: 2.0, 2.1 >Reporter: Sunny Chan >Assignee: Igor Rudyak >Priority: Major > Fix For: 2.7 > > > During our testing, we have found that certain warning about prepared > statement: > 2017-08-31 11:27:19.479 > org.apache.ignite.cache.store.cassandra.CassandraCacheStore > flusher-0-#265%% WARN CassandraCacheStore - Prepared statement cluster > error detected, refreshing Cassandra session > com.datastax.driver.core.exceptions.InvalidQueryException: Tried to execute > unknown prepared query : 0xc7647611fd755386ef63478ee7de577b. You may have > used a PreparedStatement that was created with another Cluster instance. > We notice that after this warning occurs some of the data didn't persist > properly in cassandra cache. After further examining the Ignite's > CassandraSessionImpl code in method > execute(BatchExecutionAssistance,Iterable), we found that at around [line > 283|https://github.com/apache/ignite/blob/86bd544a557663bce497134f7826be6b24d53330/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L283], > if the prepare statement fails in the asnyc call, it will not retry the > operation as the error is stored in [line > 269|https://github.com/apache/ignite/blob/86bd544a557663bce497134f7826be6b24d53330/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L269] > and cleared in [line > 277|https://github.com/apache/ignite/blob/86bd544a557663bce497134f7826be6b24d53330/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L277] > but it was not checked again after going through the [ResultSetFuture > |https://github.com/apache/ignite/blob/86bd544a557663bce497134f7826be6b24d53330/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L307]. > I believe in line 307 you should check for error != null such that any > failure will be retry. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8013) CPP: Check pending snapshots in BinaryTypeManager::GetHandler
[ https://issues.apache.org/jira/browse/IGNITE-8013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8013: --- Fix Version/s: (was: 2.6) 2.7 > CPP: Check pending snapshots in BinaryTypeManager::GetHandler > - > > Key: IGNITE-8013 > URL: https://issues.apache.org/jira/browse/IGNITE-8013 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.0 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Labels: cpp > Fix For: 2.7 > > > This will improve performance a lot, when using operations like {{PutAll()}} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8257) GridFutureAdapterSelfTest#testChaining flaky-fails on TC (rarely)
[ https://issues.apache.org/jira/browse/IGNITE-8257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8257: --- Fix Version/s: (was: 2.6) 2.7 > GridFutureAdapterSelfTest#testChaining flaky-fails on TC (rarely) > - > > Key: IGNITE-8257 > URL: https://issues.apache.org/jira/browse/IGNITE-8257 > Project: Ignite > Issue Type: Test >Reporter: Vitaliy Biryukov >Assignee: Vitaliy Biryukov >Priority: Minor > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > {code:java} > class org.apache.ignite.internal.IgniteFutureTimeoutCheckedException: Timeout > was reached before computation completed. > at > org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:242) > at > org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:159) > at > org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:151) > at > org.apache.ignite.internal.util.future.GridFutureAdapterSelfTest.checkChaining(GridFutureAdapterSelfTest.java:283) > at > org.apache.ignite.internal.util.future.GridFutureAdapterSelfTest.testChaining(GridFutureAdapterSelfTest.java:237) > 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:2080) > at > org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:140) > at > org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1995) > at java.lang.Thread.run(Thread.java:745) > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7807) SQL TX: Store lock info inside tuples
[ https://issues.apache.org/jira/browse/IGNITE-7807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-7807: --- Fix Version/s: (was: 2.6) 2.7 > SQL TX: Store lock info inside tuples > - > > Key: IGNITE-7807 > URL: https://issues.apache.org/jira/browse/IGNITE-7807 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Vladimir Ozerov >Assignee: Igor Seliverstov >Priority: Major > Fix For: 2.7 > > > We need to store lock info inside tuples. Otherwise, touching a lot of > entries would lead to OOME. Also we should rework our locking logic - instead > of trying to enlist ourselves in every entry, we should stop on the very > first locked entry and wait for it's release. > Suggested fix: > 1) Check for {{lock_id}} field of an entry > 2) If it is empty, CAS own XID > 3) If it is not empty, check fo TX LOG to see if transaction is still active; > if not - CAS itself > 4) If failed to install own version - stop locking and wait for release > 5) When transaction commits, no locks are released explicilty. Instead, it is > responsibility of the next locker to check TX LOG and undesrantnad whether > entry could be locked or not > 6) When lock is acquired, create new version of an entry with lock info -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8602) Add support filter label=null for control.sh tx utility
[ https://issues.apache.org/jira/browse/IGNITE-8602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8602: --- Fix Version/s: (was: 2.6) 2.7 > Add support filter label=null for control.sh tx utility > --- > > Key: IGNITE-8602 > URL: https://issues.apache.org/jira/browse/IGNITE-8602 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Dmitry Sherstobitov >Assignee: Alexand Polyakov >Priority: Major > Fix For: 2.7 > > Attachments: TC 01 recheck.png, TC 02 recheck.png, TC 03 recheck.png, > TC 04 recheck.png, TC.png > > > For now this transactions cannot be separated from other by using filter > "label null" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6439) IgnitePersistentStoreSchemaLoadTest is broken
[ https://issues.apache.org/jira/browse/IGNITE-6439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-6439: --- Fix Version/s: (was: 2.6) 2.7 > IgnitePersistentStoreSchemaLoadTest is broken > - > > Key: IGNITE-6439 > URL: https://issues.apache.org/jira/browse/IGNITE-6439 > Project: Ignite > Issue Type: Bug >Reporter: Dmitriy Govorukhin >Assignee: Denis Garus >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > After start nodes, cluster must be activated explicit. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-4193) SQL TX: ODBC driver support
[ https://issues.apache.org/jira/browse/IGNITE-4193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-4193: --- Fix Version/s: (was: 2.6) 2.7 > SQL TX: ODBC driver support > --- > > Key: IGNITE-4193 > URL: https://issues.apache.org/jira/browse/IGNITE-4193 > Project: Ignite > Issue Type: Task > Components: odbc >Reporter: Denis Magda >Assignee: Igor Sapego >Priority: Major > Labels: iep-3 > Fix For: 2.7 > > > To support execution of DML and SELECT statements inside of a transaction > started from ODBC driver side. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-5977) [Test Failed] IgniteClientDiscoveryDataStructuresTest.testSequence
[ https://issues.apache.org/jira/browse/IGNITE-5977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-5977: --- Fix Version/s: (was: 2.6) 2.7 > [Test Failed] IgniteClientDiscoveryDataStructuresTest.testSequence > --- > > Key: IGNITE-5977 > URL: https://issues.apache.org/jira/browse/IGNITE-5977 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Eduard Shangareev >Assignee: Aleksey Plekhanov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > Fails locally. > Example of failing > http://ci.ignite.apache.org/viewLog.html?buildId=760759&tab=buildResultsDiv&buildTypeId=Ignite20Tests_IgniteDataStrucutures#testNameId2829619862655631000 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8594) Make error messages in validate_indexes command report more informative
[ https://issues.apache.org/jira/browse/IGNITE-8594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8594: --- Fix Version/s: (was: 2.6) 2.7 > Make error messages in validate_indexes command report more informative > --- > > Key: IGNITE-8594 > URL: https://issues.apache.org/jira/browse/IGNITE-8594 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Rakov >Assignee: Vladislav Pyatkov >Priority: Major > Fix For: 2.7 > > > In case index is broken and contains links to missing items in data pages, > validate_indexes command will show "Item not found" messages in report: > {noformat} > IndexValidationIssue [key=null, cacheName=cache_group_1_028, > idxName=_key_PK], class java.lang.IllegalStateException: Item not found: 65 > IndexValidationIssue [key=null, cacheName=cache_group_1_028, > idxName=_key_PK], class java.lang.IllegalStateException: Item not found: 15 > SQL Index [cache=cache_group_1_028, idx=LONG__VAL_IDX] > ValidateIndexesPartitionResult [consistentId=node2, sqlIdxName=LONG__VAL_IDX] > IndexValidationIssue [key=null, cacheName=cache_group_1_028, > idxName=LONG__VAL_IDX], class java.lang.IllegalStateException: Item not > found: 60 > IndexValidationIssue [key=null, cacheName=cache_group_1_028, > idxName=LONG__VAL_IDX], class java.lang.IllegalStateException: Item not > found: 65 > IndexValidationIssue [key=null, cacheName=cache_group_1_028, > idxName=LONG__VAL_IDX], class java.lang.IllegalStateException: Item not > found: 65 > IndexValidationIssue [key=null, cacheName=cache_group_1_028, > idxName=LONG__VAL_IDX], class java.lang.IllegalStateException: Item not > found: 15 > {noformat} > It would be better to explain what is happening: key is present in SQL index, > but is missing in corresponding data page. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8079) Service config variations test has flaky failures in Basic 2 suite: Not serializable
[ https://issues.apache.org/jira/browse/IGNITE-8079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8079: --- Fix Version/s: (was: 2.6) 2.7 > Service config variations test has flaky failures in Basic 2 suite: Not > serializable > > > Key: IGNITE-8079 > URL: https://issues.apache.org/jira/browse/IGNITE-8079 > Project: Ignite > Issue Type: Test >Reporter: Dmitriy Pavlov >Assignee: Alexey Goncharuk >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > > IgniteServiceConfigVariationsFullApiTest.testClusterSingletonDeploy 5 > failures in one build > IgniteServiceConfigVariationsFullApiTest.testDeploy 5 failures in one build > IgniteServiceConfigVariationsFullApiTest.testKeyAffinityDeploy 5 > failures in one build > IgniteServiceConfigVariationsFullApiTest.testMultipleDeploy 5 failures in > one build > IgniteServiceConfigVariationsFullApiTest.testNodeSingletonDeploy > {noformat} > [2018-03-25 > 09:11:24,764][ERROR][test-runner-#15278%service.IgniteServiceConfigVariationsFullApiTest%][GridServiceProcessor] > Failed to marshal service with configured marshaller [name=testService, > srvc=o.a.i.i.processors.service.IgniteServiceConfigVariationsFullApiTest$TestServiceImpl@587a67fa, > marsh=JdkMarshaller [clsFilter=null]] > class org.apache.ignite.IgniteCheckedException: Failed to serialize object: > org.apache.ignite.internal.processors.service.IgniteServiceConfigVariationsFullApiTest$TestServiceImpl@587a67fa > at > org.apache.ignite.marshaller.jdk.JdkMarshaller.marshal0(JdkMarshaller.java:103) > at > org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.marshal(AbstractNodeNameAwareMarshaller.java:70) > at > org.apache.ignite.marshaller.jdk.JdkMarshaller.marshal0(JdkMarshaller.java:117) > at > org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.marshal(AbstractNodeNameAwareMarshaller.java:58) > at > org.apache.ignite.internal.util.IgniteUtils.marshal(IgniteUtils.java:10051) > at > org.apache.ignite.internal.processors.service.GridServiceProcessor.prepareServiceConfigurations(GridServiceProcessor.java:560) > at > org.apache.ignite.internal.processors.service.GridServiceProcessor.deployAll(GridServiceProcessor.java:612) > 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) > at > org.apache.ignite.internal.processors.service.IgniteServiceConfigVariationsFullApiTest$2.run(IgniteServiceConfigVariationsFullApiTest.java:99) > at > org.apache.ignite.internal.processors.service.IgniteServiceConfigVariationsFullApiTest.testService(IgniteServiceConfigVariationsFullApiTest.java:225) > at > org.apache.ignite.internal.processors.service.IgniteServiceConfigVariationsFullApiTest$ServiceTestRunnable.run(IgniteServiceConfigVariationsFullApiTest.java:189) > at > org.apache.ignite.testframework.junits.IgniteConfigVariationsAbstractTest.runInAllDataModes(IgniteConfigVariationsAbstractTest.java:248) > at > org.apache.ignite.internal.processors.service.IgniteServiceConfigVariationsFullApiTest.testClusterSingletonDeploy(IgniteServiceConfigVariationsFullApiTest.java:97) > 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:2002) > at > org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133) > at > org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1917) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.io.NotSerializableException: > org.apache.ignite.testframework.junits.IgniteConfigVariationsAbstractTest$PlaneObject > at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1184) > at > java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548) > at > java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509) >
[jira] [Updated] (IGNITE-8086) Flaky test timeouts in Activate/Deactivate Cluster suite
[ https://issues.apache.org/jira/browse/IGNITE-8086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8086: --- Fix Version/s: (was: 2.6) 2.7 > Flaky test timeouts in Activate/Deactivate Cluster suite > > > Key: IGNITE-8086 > URL: https://issues.apache.org/jira/browse/IGNITE-8086 > Project: Ignite > Issue Type: Test >Reporter: Dmitriy Pavlov >Assignee: Maxim Muzafarov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > # Activate | Deactivate Cluster > IgniteStandByClusterSuite: > CacheBaselineTopologyTest.testPrimaryLeftAndClusterRestart (master fail rate > 37,1%) > > [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=6798733272445954906&branch=%3Cdefault%3E&tab=testDetails] > # IgniteStandByClusterSuite: > CacheBaselineTopologyTest.testBaselineTopologyChangesFromClient (master fail > rate 24,9%) > > [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-9217764610687235146&branch=%3Cdefault%3E&tab=testDetails] > # IgniteStandByClusterSuite: > CacheBaselineTopologyTest.testBaselineTopologyChangesFromServer (master fail > rate 19,8%) > > [https://ci.ignite.apache.org/viewLog.html?buildId=1199624&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_ActivateDeactivateCluster#testNameId-4432469336264773506] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7271) UPDATE and DELETE statements do not work through thin JDBC work in MVCC mode
[ https://issues.apache.org/jira/browse/IGNITE-7271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-7271: --- Fix Version/s: (was: 2.6) 2.7 > UPDATE and DELETE statements do not work through thin JDBC work in MVCC mode > > > Key: IGNITE-7271 > URL: https://issues.apache.org/jira/browse/IGNITE-7271 > Project: Ignite > Issue Type: Bug > Components: jdbc, sql >Reporter: Vladimir Ozerov >Assignee: Igor Seliverstov >Priority: Major > Fix For: 2.7 > > > See relevant failures JDBC suite. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8666) Add ability of filtering data during datasets creation
[ https://issues.apache.org/jira/browse/IGNITE-8666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8666: --- Fix Version/s: (was: 2.6) 2.7 > Add ability of filtering data during datasets creation > -- > > Key: IGNITE-8666 > URL: https://issues.apache.org/jira/browse/IGNITE-8666 > Project: Ignite > Issue Type: New Feature > Components: ml >Reporter: Yury Babak >Assignee: Anton Dmitriev >Priority: Major > Fix For: 2.7 > > > So far we use straightforward strategy to feed data into partition based > dataset. We retrieve all entries from an upstream cache partition, transform > it somehow and write into correspondent dataset partition (data and context). > As result we can't choose the data to be fed into dataset and data to be not > fed. To implement IGNITE-8667 (Splitting of dataset to test and training > sets) and IGNITE-8668 (K-fold cross validation of models) we need to have > such ability. > The goal of this task is to add an ability to filter data that fed from cache > to dataset. It will allow us to create different dataset (training, testing, > k-fold, etc...) based on a single cache. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8491) Add JMX flag: Is the node in baseline or not?
[ https://issues.apache.org/jira/browse/IGNITE-8491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8491: --- Fix Version/s: (was: 2.6) 2.7 > Add JMX flag: Is the node in baseline or not? > - > > Key: IGNITE-8491 > URL: https://issues.apache.org/jira/browse/IGNITE-8491 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Assignee: Vladislav Pyatkov >Priority: Major > Fix For: 2.7 > > > Need to add a baseline flag on JMX. > {code} > public interface IgniteMXBean { > /** > * Gets a flag is node in baseline. > * > * @return Return a baseline flag. > */ > @MXBeanDescription("Baseline node flag.") > public boolean isNodeInBaseline(); > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8413) CacheGroupMetricsMBeanTest.testCacheGroupMetrics fails on master.
[ https://issues.apache.org/jira/browse/IGNITE-8413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8413: --- Fix Version/s: (was: 2.6) 2.7 > CacheGroupMetricsMBeanTest.testCacheGroupMetrics fails on master. > - > > Key: IGNITE-8413 > URL: https://issues.apache.org/jira/browse/IGNITE-8413 > Project: Ignite > Issue Type: Test >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Minor > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > CacheGroupMetricsMBeanTest.testCacheGroupMetrics fails due to a race. > Seems, we should pause rebalance to see expected instant metrics. > {code:java} > junit.framework.AssertionFailedError > at junit.framework.Assert.fail(Assert.java:55) > at junit.framework.Assert.assertTrue(Assert.java:22) > at junit.framework.Assert.assertTrue(Assert.java:31) > at junit.framework.TestCase.assertTrue(TestCase.java:201) > at > org.apache.ignite.internal.processors.cache.CacheGroupMetricsMBeanTest.testCacheGroupMetrics(CacheGroupMetricsMBeanTest.java:262) > 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:2080) > at > org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:140) > at > org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1995) > at java.lang.Thread.run(Thread.java:748){code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6612) Wrap ack methods in their own class
[ https://issues.apache.org/jira/browse/IGNITE-6612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-6612: --- Fix Version/s: (was: 2.6) 2.7 > Wrap ack methods in their own class > --- > > Key: IGNITE-6612 > URL: https://issues.apache.org/jira/browse/IGNITE-6612 > Project: Ignite > Issue Type: Improvement >Affects Versions: None >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Trivial > Labels: refactor > Fix For: 2.7 > > > Several methods in IgniteKernal implement similar functions: “ackAsciiLogo”, > “ackConfigUrl”, “ackDaemon”, “ackOsInfo”, “ackLanguageRuntime”, > “ackRemoteManagement”, “ackVmArguments”, “ackClassPaths”, > “ackSystemProperties”, “ackEnviromentVariables”, “ackMemoryConfiguration”, > “ackCacheConfiguration”, “ackP2PConfiguration”, “ackRebalanceConfiguration”. > These methods should be placed in separate class “AckVariousInformation” and > called from the class instance in IgniteKernal. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8694) SQL JOIN between PARTITIONED and REPLICATED cache fails
[ https://issues.apache.org/jira/browse/IGNITE-8694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8694: --- Fix Version/s: (was: 2.6) 2.7 > SQL JOIN between PARTITIONED and REPLICATED cache fails > --- > > Key: IGNITE-8694 > URL: https://issues.apache.org/jira/browse/IGNITE-8694 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Rakov >Assignee: Ivan Rakov >Priority: Major > Fix For: 2.7 > > > We already have IGNITE-7766 where TC test fails due to the same problem. > Particular case with PARTITIONED and REPLICATED caches will be fixed under > this ticket, while rest of the work will be completed under IGNITE-7766. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8587) High Contention in GridToStringBuilder.toStringImpl
[ https://issues.apache.org/jira/browse/IGNITE-8587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8587: --- Fix Version/s: (was: 2.6) 2.7 > High Contention in GridToStringBuilder.toStringImpl > - > > Key: IGNITE-8587 > URL: https://issues.apache.org/jira/browse/IGNITE-8587 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Sergey Kosarev >Assignee: Sergey Kosarev >Priority: Major > Fix For: 2.7 > > > org.apache.ignite.internal.util.tostring.GridToStringBuilder#classCache > implemented as > ordinal HashMap with all operations syncronised by one ReadWriteLock. > this can trigger high contention as this class widely used in toString() > methods. > For instance it shoots when DEBUG or TRACE logs are enabled as count of > toString() invocations increases in this case extremely. > We need to use ConcurrentHashMap instead and avoid global locks. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8533) Timeout collision in Client Nodes test suite
[ https://issues.apache.org/jira/browse/IGNITE-8533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8533: --- Fix Version/s: (was: 2.6) 2.7 > Timeout collision in Client Nodes test suite > > > Key: IGNITE-8533 > URL: https://issues.apache.org/jira/browse/IGNITE-8533 > Project: Ignite > Issue Type: Bug >Reporter: Andrew Medvedev >Assignee: Andrew Medvedev >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > IGNITE-8085 increased NODE_START_CHECK_LIMIT so "remote" node log is parsed > for longer (set now to 25 * 2000ms) > https://github.com/apache/ignite/blob/fe6e70e3c8d6a6349ea00b7ec99b215945ffce6d/modules/ssh/src/main/java/org/apache/ignite/internal/util/nodestart/StartNodeCallableImpl.java#L85 > > This exceeds total timeout set up for remote node startup in > [https://github.com/apache/ignite/blob/282b334f76479460613f28347d8cea97ba23f795/modules/ssh/src/test/java/org/apache/ignite/internal/IgniteProjectionStartStopRestartSelfTest.java#L1054] > (40 * 1000ms) > > This leads to debug message with ref to remote log file being never shown > because 5 timeout will never be reached > [https://github.com/apache/ignite/blob/fe6e70e3c8d6a6349ea00b7ec99b215945ffce6d/modules/ssh/src/main/java/org/apache/ignite/internal/util/nodestart/StartNodeCallableImpl.java#L285] > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7302) SQL TX: Failed to query INFORMATIONAL_SCHEMA
[ https://issues.apache.org/jira/browse/IGNITE-7302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-7302: --- Fix Version/s: (was: 2.6) 2.7 > SQL TX: Failed to query INFORMATIONAL_SCHEMA > > > Key: IGNITE-7302 > URL: https://issues.apache.org/jira/browse/IGNITE-7302 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Vladimir Ozerov >Assignee: Alexander Paschenko >Priority: Major > Fix For: 2.7 > > > {code} > javax.cache.CacheException: class org.apache.ignite.IgniteException: > Unsupported query: Unexpected Table implementation [cls=MetaTable] > at > org.apache.ignite.internal.processors.query.h2.sql.GridSqlQueryParser.assert0(GridSqlQueryParser.java:1876) > at > org.apache.ignite.internal.processors.query.h2.sql.GridSqlQueryParser.parseTable(GridSqlQueryParser.java:612) > at > org.apache.ignite.internal.processors.query.h2.sql.GridSqlQueryParser.parseTableFilter(GridSqlQueryParser.java:565) > at > org.apache.ignite.internal.processors.query.h2.sql.GridSqlQueryParser.parseSelect(GridSqlQueryParser.java:665) > at > org.apache.ignite.internal.processors.query.h2.sql.GridSqlQueryParser.parseQuery(GridSqlQueryParser.java:1539) > at > org.apache.ignite.internal.processors.query.h2.sql.GridSqlQueryParser.parse(GridSqlQueryParser.java:1490) > at > org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.mvccTracker(IgniteH2Indexing.java:1294) > at > org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryLocalSqlFields(IgniteH2Indexing.java:926) > at > org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryLocalSqlFields(IgniteH2Indexing.java:870) > at > org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryLocalSqlFields(IgniteH2Indexing.java:1163) > at > org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:1951) > at > org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:1936) > at > org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36) > at > org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2521) > at > org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:1968) > at > org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:585) > at > org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:560) > at > org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:382) > at > org.apache.ignite.internal.processors.cache.local.IgniteCacheLocalFieldsQuerySelfTest.testInformationSchema(IgniteCacheLocalFieldsQuerySelfTest.java:49) > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8160) GridCacheAbstractDataStructuresFailoverSelfTest#testAtomicInitialization flaky-fails on TC
[ https://issues.apache.org/jira/browse/IGNITE-8160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8160: --- Fix Version/s: (was: 2.6) 2.7 > GridCacheAbstractDataStructuresFailoverSelfTest#testAtomicInitialization > flaky-fails on TC > -- > > Key: IGNITE-8160 > URL: https://issues.apache.org/jira/browse/IGNITE-8160 > Project: Ignite > Issue Type: Test >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > The test fails because sequence initialization compute is sent to nodes being > stopped. The test should be changed to test: > 1) If the closure may be sent to a stopping node, then NodeStoppingException > should be ignored > 2) Another test should send closures only to stable nodes and should not > tolerate any failures -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7592) Dynamic cache with rebalanceDelay == -1 doesn't trigger late affinity assignment even after explicit rebalance is called on every node
[ https://issues.apache.org/jira/browse/IGNITE-7592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-7592: --- Fix Version/s: (was: 2.6) 2.7 > Dynamic cache with rebalanceDelay == -1 doesn't trigger late affinity > assignment even after explicit rebalance is called on every node > -- > > Key: IGNITE-7592 > URL: https://issues.apache.org/jira/browse/IGNITE-7592 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Ilya Lantukh >Assignee: Maxim Muzafarov >Priority: Major > Fix For: 2.7 > > > Reproducer: > {noformat} > startGrids(NODE_COUNT); > IgniteEx ig = grid(0); > ig.cluster().active(true); > awaitPartitionMapExchange(); > IgniteCache cache = > ig.createCache( > new CacheConfiguration() > .setName(CACHE_NAME) > .setCacheMode(PARTITIONED) > .setBackups(1) > .setPartitionLossPolicy(READ_ONLY_SAFE) > .setReadFromBackup(true) > .setWriteSynchronizationMode(FULL_SYNC) > .setRebalanceDelay(-1) > ); > for (int i = 0; i < NODE_COUNT; i++) > grid(i).cache(CACHE_NAME).rebalance().get(); > awaitPartitionMapExchange(); > {noformat} > Sometimes this code will hang on the last awaitPartitionMapExchange(), though > probability that it will happen is rather low (<10%). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8423) Control utility may block when joining node is watiting for partition map exchange
[ https://issues.apache.org/jira/browse/IGNITE-8423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8423: --- Fix Version/s: (was: 2.6) 2.7 > Control utility may block when joining node is watiting for partition map > exchange > -- > > Key: IGNITE-8423 > URL: https://issues.apache.org/jira/browse/IGNITE-8423 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Alexey Goncharuk >Assignee: Alexei Scherbakov >Priority: Major > Fix For: 2.7 > > > The utility hang because {{GridTcpRestNioListener}} is blocked on the > following piece of code: > {code} > if (marshMapLatch.getCount() > 0) > U.awaitQuiet(marshMapLatch); > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8525) Support for IgniteZeroMqStreamer non-multi-part pub-sub
[ https://issues.apache.org/jira/browse/IGNITE-8525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8525: --- Fix Version/s: (was: 2.6) 2.7 > Support for IgniteZeroMqStreamer non-multi-part pub-sub > --- > > Key: IGNITE-8525 > URL: https://issues.apache.org/jira/browse/IGNITE-8525 > Project: Ignite > Issue Type: Improvement > Components: streaming >Reporter: Roman Shtykh >Assignee: Roman Shtykh >Priority: Major > Fix For: 2.7 > > > Currently only multi-part pub-sub is supported. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-5934) Integrate mvcc support in sql query protocol
[ https://issues.apache.org/jira/browse/IGNITE-5934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-5934: --- Fix Version/s: (was: 2.6) 2.7 > Integrate mvcc support in sql query protocol > > > Key: IGNITE-5934 > URL: https://issues.apache.org/jira/browse/IGNITE-5934 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Semen Boikov >Assignee: Igor Seliverstov >Priority: Major > Fix For: 2.7 > > > Need integrate mvcc support in sql query protocol: > - request current ID and list of active txs from coordinator > - pass this info in sql requests and in sql queries > - notify coordinator after query completed -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8511) [ML] Add support for Multi-Class Logistic Regression
[ https://issues.apache.org/jira/browse/IGNITE-8511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8511: --- Fix Version/s: (was: 2.6) 2.7 > [ML] Add support for Multi-Class Logistic Regression > > > Key: IGNITE-8511 > URL: https://issues.apache.org/jira/browse/IGNITE-8511 > Project: Ignite > Issue Type: New Feature > Components: ml >Reporter: Aleksey Zinoviev >Assignee: Aleksey Zinoviev >Priority: Major > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8437) Control utility fails to connect to cluster if zookeeper discovery used
[ https://issues.apache.org/jira/browse/IGNITE-8437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8437: --- Fix Version/s: (was: 2.6) 2.7 > Control utility fails to connect to cluster if zookeeper discovery used > --- > > Key: IGNITE-8437 > URL: https://issues.apache.org/jira/browse/IGNITE-8437 > Project: Ignite > Issue Type: Improvement > Components: zookeeper >Affects Versions: 2.5 >Reporter: Dmitry Sherstobitov >Assignee: Alexei Scherbakov >Priority: Blocker > Fix For: 2.7 > > > Start cluster with zookeeper discovery and try to run control.sh --tx utility > > {code:java} > 2018-05-03 16:56:36.225 > [ERROR][mgmt-#115268%DPL_GRID%DplGridNodeName%][o.a.i.i.p.r.p.t.GridTcpRestProtocol] > Failed to process client request [ses=GridSelectorNioSessionImpl > [worker=ByteBufferNioClientWorker [readBuf=java.nio.HeapByteBuffer[pos=395 > lim=395 cap=8192], super=AbstractNioClientWorker [idx=0, bytesRcvd=0, > bytesSent=0, bytesRcvd0=0, bytesSent0=0, select=true, super=GridWorker > [name=grid-nio-worker-tcp-rest-0, > igniteInstanceName=DPL_GRID%DplGridNodeName, finished=false, > hashCode=1766410348, interrupted=false, > runner=grid-nio-worker-tcp-rest-0-#48%DPL_GRID%DplGridNodeName%]]], > writeBuf=null, readBuf=null, inRecovery=null, outRecovery=null, > super=GridNioSessionImpl [locAddr=/10.116.158.48:11211, > rmtAddr=/10.78.10.31:55847, createTime=1525355795984, > closeTime=1525355796217, bytesSent=521553, bytesRcvd=461, bytesSent0=521553, > bytesRcvd0=461, sndSchedTime=1525355796217, lastSndTime=1525355796075, > lastRcvTime=1525355796175, readsPaused=false, > filterChain=FilterChain[filters=[GridNioCodecFilter [parser=GridTcpRestParser > [marsh=JdkMarshaller [clsFilter=o.a.i.i.IgniteKernal$5@3e3d1d0d], > routerClient=false], directMode=false]], accepted=true]], > msg=GridClientTaskRequest [taskName=o.a.i.i.v.tx.VisorTxTask, > arg=VisorTaskArgument [debug=false]]] > org.apache.ignite.internal.util.nio.GridNioException: class > org.apache.ignite.IgniteCheckedException: Failed to serialize object: > GridClientResponse [clientId=587ea745-dd1e-4631-aa85-feb5d49acc36, reqId=2, > destId=null, status=0, errMsg=null, result=GridClientTaskResultBean > [res={ZookeeperClusterNode [id=c4cc818d-b29f-427b-86b5-9a625287feb6, > addrs=[10.116.159.100], order=30, loc=false, client=true]=VisorTxTaskResult > []}, error=null, finished=true, id=~a7245b33-a37a-4084-a954-460c31834442]] > at > org.apache.ignite.internal.util.nio.GridNioCodecFilter.onSessionWrite(GridNioCodecFilter.java:100) > at > org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedSessionWrite(GridNioFilterAdapter.java:121) > at > org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onSessionWrite(GridNioFilterChain.java:269) > at > org.apache.ignite.internal.util.nio.GridNioFilterChain.onSessionWrite(GridNioFilterChain.java:192) > at > org.apache.ignite.internal.util.nio.GridNioSessionImpl.send(GridNioSessionImpl.java:110) > at > org.apache.ignite.internal.processors.rest.protocols.tcp.GridTcpRestNioListener$1.apply(GridTcpRestNioListener.java:261) > at > org.apache.ignite.internal.processors.rest.protocols.tcp.GridTcpRestNioListener$1.apply(GridTcpRestNioListener.java:232) > at > org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383) > at > org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347) > at > org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335) > at > org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:495) > at > org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474) > at > org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:451) > at > org.apache.ignite.internal.processors.rest.GridRestProcessor$2$1.apply(GridRestProcessor.java:165) > at > org.apache.ignite.internal.processors.rest.GridRestProcessor$2$1.apply(GridRestProcessor.java:162) > at > org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383) > at > org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347) > at > org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335) > at > org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:495) > at > org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474) > at > org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:451) > at > org.apache.ignite.inte
[jira] [Updated] (IGNITE-8624) Add test coverage for NPE in TTL Manager [IGNITE-7972]
[ https://issues.apache.org/jira/browse/IGNITE-8624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8624: --- Fix Version/s: (was: 2.6) 2.7 > Add test coverage for NPE in TTL Manager [IGNITE-7972] > -- > > Key: IGNITE-8624 > URL: https://issues.apache.org/jira/browse/IGNITE-8624 > Project: Ignite > Issue Type: Test >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Minor > Fix For: 2.7 > > > Add test coverage (reproducer) to the [IGNITE-7972] case. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8763) java.nio.file.AccessDeniedException is not handled with default failure handler
[ https://issues.apache.org/jira/browse/IGNITE-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8763: --- Fix Version/s: (was: 2.6) 2.7 > java.nio.file.AccessDeniedException is not handled with default failure > handler > --- > > Key: IGNITE-8763 > URL: https://issues.apache.org/jira/browse/IGNITE-8763 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Andrey Gura >Assignee: Aleksey Plekhanov >Priority: Major > Fix For: 2.7 > > > java.nio.file.AccessDeniedException is not handled with default failure > handler > 1. Start cluster(4 nodes). > 2. Upload some data. > 3. Make files in metastore read only. > 4. Deactivate grid. > 5. Activate grid. > On this step I see java.nio.file.AccessDeniedException: > {noformat} > [17:55:40,035][INFO][exchange-worker-#62][GridCacheDatabaseSharedManager] > Read checkpoint status > [startMarker=/storage/ssd/avolkov/tiden/iep_14-180517-175425/test_iep_14/ignite.server.1/work/db/node1/cp/1526568907638-46128a87-562a-45fc-8d73-75ccb1490d63-START.bin, > > endMarker=/storage/ssd/avolkov/tiden/iep_14-180517-175425/test_iep_14/ignite.server.1/work/db/node1/cp/1526568907638-46128a87-562a-45fc-8d73-75ccb1490d63-END.bin] > [17:55:40,037][SEVERE][exchange-worker-#62][GridDhtPartitionsExchangeFuture] > Failed to activate node components > [nodeId=bd7115d5-1f95-4673-9f40-47056b0b1a58, client=false, > topVer=AffinityTopologyVersion [topVer=4, minorTopVer=5]] > class org.apache.ignite.IgniteCheckedException: Error while creating file > page store > [file=/storage/ssd/avolkov/tiden/iep_14-180517-175425/test_iep_14/ignite.server.1/work/db/node1/metastorage/part-0.bin]: > at > org.apache.ignite.internal.processors.cache.persistence.file.FileVersionCheckingFactory.createPageStore(FileVersionCheckingFactory.java:98) > at > org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.initDir(FilePageStoreManager.java:463) > at > org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.initializeForMetastorage(FilePageStoreManager.java:234) > at > org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readCheckpointAndRestoreMemory(GridCacheDatabaseSharedManager.java:743) > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest(GridDhtPartitionsExchangeFuture.java:896) > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:643) > at > org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2419) > at > org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2299) > at > org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.nio.file.AccessDeniedException: > /storage/ssd/avolkov/tiden/iep_14-180517-175425/test_iep_14/ignite.server.1/work/db/node1/metastorage/part-0.bin > at > sun.nio.fs.UnixException.translateToIOException(UnixException.java:84) > at > sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102) > at > sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107) > at > sun.nio.fs.UnixFileSystemProvider.newAsynchronousFileChannel(UnixFileSystemProvider.java:196) > at > java.nio.channels.AsynchronousFileChannel.open(AsynchronousFileChannel.java:248) > at > java.nio.channels.AsynchronousFileChannel.open(AsynchronousFileChannel.java:301) > at > org.apache.ignite.internal.processors.cache.persistence.file.AsyncFileIO.(AsyncFileIO.java:57) > at > org.apache.ignite.internal.processors.cache.persistence.file.AsyncFileIOFactory.create(AsyncFileIOFactory.java:53) > at > org.apache.ignite.internal.processors.cache.persistence.file.AsyncFileIOFactory.create(AsyncFileIOFactory.java:41) > at > org.apache.ignite.internal.processors.cache.persistence.file.FileVersionCheckingFactory.createPageStore(FileVersionCheckingFactory.java:78) > ... 9 more > {noformat} > Situation led to NPE exception after AccessDeniedException looks like this: > 1. AccessDeniedException was thrown in ExchangeFuture right before affinity > initialization so affinity was never initialized. > 2. After that node receives PartitionSingleMessage and tries to access > affinity information. Null is returned
[jira] [Updated] (IGNITE-8675) Fix flacky test PdsWithTtlCompatibilityTest.testNodeStartByOldVersionPersistenceData_2_1
[ https://issues.apache.org/jira/browse/IGNITE-8675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8675: --- Fix Version/s: (was: 2.6) 2.7 > Fix flacky test > PdsWithTtlCompatibilityTest.testNodeStartByOldVersionPersistenceData_2_1 > - > > Key: IGNITE-8675 > URL: https://issues.apache.org/jira/browse/IGNITE-8675 > Project: Ignite > Issue Type: Test >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Minor > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > Looks like 2.1 node that is started in separate JVM, fails with OOM. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6430) CacheGroupsMetricsRebalanceTest.testRebalanceEstimateFinishTime test fails periodically.
[ https://issues.apache.org/jira/browse/IGNITE-6430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-6430: --- Fix Version/s: (was: 2.6) 2.7 > CacheGroupsMetricsRebalanceTest.testRebalanceEstimateFinishTime test fails > periodically. > > > Key: IGNITE-6430 > URL: https://issues.apache.org/jira/browse/IGNITE-6430 > Project: Ignite > Issue Type: Bug >Reporter: Andrey Gura >Assignee: Alexander Menshikov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > {{CacheGroupsMetricsRebalanceTest.testRebalanceEstimateFinishTime}} test > fails periodically. > {noformat} > [2017-09-18 15:18:20,073][ERROR][main][root] Test failed. > junit.framework.AssertionFailedError: Expected less 5000, Actual:-100969 > at junit.framework.Assert.fail(Assert.java:57) > at junit.framework.Assert.assertTrue(Assert.java:22) > at junit.framework.TestCase.assertTrue(TestCase.java:192) > at > org.apache.ignite.internal.processors.cache.CacheGroupsMetricsRebalanceTest.testRebalanceEstimateFinishTime(CacheGroupsMetricsRebalanceTest.java:261) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at junit.framework.TestCase.runTest(TestCase.java:176) > at > org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000) > at > org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132) > at > org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915) > at java.lang.Thread.run(Thread.java:745) > {noformat} > After fix test should be unmuted on TC. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8108) .NET: Fix flaky EntityFrameworkCacheInitializationTest.TestConfigurationAndStartup
[ https://issues.apache.org/jira/browse/IGNITE-8108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8108: --- Fix Version/s: (was: 2.6) 2.7 > .NET: Fix flaky > EntityFrameworkCacheInitializationTest.TestConfigurationAndStartup > -- > > Key: IGNITE-8108 > URL: https://issues.apache.org/jira/browse/IGNITE-8108 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.5 >Reporter: Alexey Popov >Assignee: Alexey Popov >Priority: Minor > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > https://ci.ignite.apache.org/viewLog.html?buildId=1171195&buildTypeId=IgniteTests24Java8_IgnitePlatformNetIntegrations&tab=buildLog&_focus=6035 > Test uses multicast ipFinder. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7342) SQL TX: Fix checking whether currently updating row was updated after it pass query filter
[ https://issues.apache.org/jira/browse/IGNITE-7342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-7342: --- Fix Version/s: (was: 2.6) 2.7 > SQL TX: Fix checking whether currently updating row was updated after it pass > query filter > -- > > Key: IGNITE-7342 > URL: https://issues.apache.org/jira/browse/IGNITE-7342 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Igor Seliverstov >Assignee: Igor Seliverstov >Priority: Major > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)