[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=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=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] [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=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-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] [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=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16520894 -- 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] [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=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=-1780719797264285338=%3Cdefault%3E=testDetails
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=5703653634172546268=%3Cdefault%3E=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=2035731000398727816=%3Cdefault%3E=testDetails]* > *IgniteClientTestSuite: > JettyRestProcessorAuthenticationWithCredsSelfTest.testRemove[ (fail rate > 11,1%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=5513793448643455005=%3Cdefault%3E=testDetails]* > *IgniteClientTestSuite: > JettyRestProcessorAuthenticationWithCredsSelfTest.testRemoveAll[ (fail rate > 11,1%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-1721357182035817455=%3Cdefault%3E=testDetails]* > *IgniteClientTestSuite: > JettyRestProcessorAuthenticationWithCredsSelfTest.testVisorGateway[ (fail > rate > 11,1%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-2028785123619746743=%3Cdefault%3E=testDetails]* > *IgniteClientTestSuite: > JettyRestProcessorAuthenticationWithTokenSelfTest.testDeactivateActivate[ > (fail rate > 11,1%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-334626288130660999=%3Cdefault%3E=testDetails]* > *IgniteClientTestSuite: > JettyRestProcessorAuthenticationWithTokenSelfTest.testRemove[ (fail rate > 11,1%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-5504915680838168777=%3Cdefault%3E=testDetails]* > *IgniteClientTestSuite: > JettyRestProcessorAuthenticationWithTokenSelfTest.testRemoveAll[ (fail rate > 11,1%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1220211038727255366=%3Cdefault%3E=testDetails]* > > *IgniteClientTestSuite: > JettyRestProcessorAuthenticationWithTokenSelfTest.testVisorGateway[ (fail > rate > 11,1%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=2613252696282859254=%3Cdefault%3E=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
>
[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=buildChangesDiv=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=-2642357454043293898=testDetails_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=buildResultsDiv=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-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-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=6798733272445954906=%3Cdefault%3E=testDetails] > # IgniteStandByClusterSuite: > CacheBaselineTopologyTest.testBaselineTopologyChangesFromClient (master fail > rate 24,9%) > > [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-9217764610687235146=%3Cdefault%3E=testDetails] > # IgniteStandByClusterSuite: > CacheBaselineTopologyTest.testBaselineTopologyChangesFromServer (master fail > rate 19,8%) > > [https://ci.ignite.apache.org/viewLog.html?buildId=1199624=buildResultsDiv=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-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
>
[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-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=IgniteTests24Java8_IgnitePlatformNetIntegrations=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)
[jira] [Updated] (IGNITE-8134) Services can't be deployed on servers outside of baseline topology
[
https://issues.apache.org/jira/browse/IGNITE-8134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-8134:
---
Fix Version/s: (was: 2.6)
2.7
> Services can't be deployed on servers outside of baseline topology
> --
>
> Key: IGNITE-8134
> URL: https://issues.apache.org/jira/browse/IGNITE-8134
> Project: Ignite
> Issue Type: Bug
> Components: managed services, persistence
>Affects Versions: 2.4
>Reporter: Stanislav Lukyanov
>Assignee: Denis Mekhanikov
>Priority: Major
> Fix For: 2.7
>
>
> If a node is not a part of the baseline topology, the services will never be
> deployed on it. In particular, if that node calls a synchronous deploy*
> method, the method will hang.
> After the node is added to the baseline, all previously initiated
> deployments succeed (and deploy* methods return).
> It seems that the issue is with the continuous query started by the
> GridServiceProcessor on the ignite-sys-cache.
> Example:
> =
> {code}
> public class BltServicesBug {
> public static void main(String[] args) {
> // start one node
> IgniteConfiguration cfg1 = new IgniteConfiguration()
> .setIgniteInstanceName("node1")
> .setDataStorageConfiguration(
> new DataStorageConfiguration()
> .setDefaultDataRegionConfiguration(
> new DataRegionConfiguration()
> .setPersistenceEnabled(true)
> )
> );
> try (Ignite ignite1 = Ignition.start(cfg1)) {
> // activate and set baseline topology
> ignite1.cluster().active(true);
> // start another node
> IgniteConfiguration cfg2 = new IgniteConfiguration(cfg1)
> .setIgniteInstanceName("node2");
> try (Ignite ignite2 = Ignition.start(cfg2)) {
> // try to deploy a service;
> // this call hangs until the second node is added to the BLT
> (e.g. externally via control.sh)
> ignite2.services().deployNodeSingleton("myService", new
> MyServiceImpl()); System.out.println("> Deployed"); }
> }
> }
> private static class MyServiceImpl implements Service {
> @Override public void cancel(ServiceContext ctx) { }
> @Override public void init(ServiceContext ctx) { }
> @Override public void execute(ServiceContext ctx) { }
> }
> }
> }
> {code}
> =
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
