[jira] [Commented] (IGNITE-7993) Striped pool can't be disabled
[
https://issues.apache.org/jira/browse/IGNITE-7993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519954#comment-16519954
]
Roman Guseinov commented on IGNITE-7993:
Hi [~vkulichenko] ,
Based on Yakov's requirements, I updated fix and created a new PR
https://github.com/apache/ignite/pull/4235 . Could you please take a look?
TC results:
https://ci.ignite.apache.org/viewLog.html?buildId=1410307=queuedBuildOverviewTab
I've checked 16 new failed tests. Almost all of them were failing on the master
branch or on other PRs with the same errors. Just one test was green before my
PR test:
IgniteWalFormatFileFailoverTest.testFailureHandlerTriggeredFsync [1]
I checked the log and it looks like this fail is not related to my changes.
Thanks in advance.
[1]
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-635689296996716497=testDetails
> Striped pool can't be disabled
> --
>
> Key: IGNITE-7993
> URL: https://issues.apache.org/jira/browse/IGNITE-7993
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.4
>Reporter: Valentin Kulichenko
>Assignee: Roman Guseinov
>Priority: Major
> Fix For: 2.6
>
>
> Javadoc for {{IgniteConfiguration#setStripedPoolSize}} states that striped
> pool can be disabled by providing value less or equal than zero:
> {noformat}
> If set to non-positive value then requests get processed in system pool.
> {noformat}
> However, doing that prevents node from startup, it fails with the following
> exception:
> {noformat}
> Caused by: class org.apache.ignite.IgniteCheckedException: Invalid
> stripedPool thread pool size (must be greater than 0), actual value: 0
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.validateThreadPoolSize(IgnitionEx.java:2061)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1799)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1716)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1144)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:664)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:589)
> at org.apache.ignite.Ignition.start(Ignition.java:322)
> ... 7 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7993) Striped pool can't be disabled
[
https://issues.apache.org/jira/browse/IGNITE-7993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519942#comment-16519942
]
ASF GitHub Bot commented on IGNITE-7993:
Github user gromtech closed the pull request at:
https://github.com/apache/ignite/pull/3860
> Striped pool can't be disabled
> --
>
> Key: IGNITE-7993
> URL: https://issues.apache.org/jira/browse/IGNITE-7993
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.4
>Reporter: Valentin Kulichenko
>Assignee: Roman Guseinov
>Priority: Major
> Fix For: 2.6
>
>
> Javadoc for {{IgniteConfiguration#setStripedPoolSize}} states that striped
> pool can be disabled by providing value less or equal than zero:
> {noformat}
> If set to non-positive value then requests get processed in system pool.
> {noformat}
> However, doing that prevents node from startup, it fails with the following
> exception:
> {noformat}
> Caused by: class org.apache.ignite.IgniteCheckedException: Invalid
> stripedPool thread pool size (must be greater than 0), actual value: 0
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.validateThreadPoolSize(IgnitionEx.java:2061)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1799)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1716)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1144)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:664)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:589)
> at org.apache.ignite.Ignition.start(Ignition.java:322)
> ... 7 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8850) Add a GA example that solves 'Traveling Salesman Problem'
Turik Campbell created IGNITE-8850: -- Summary: Add a GA example that solves 'Traveling Salesman Problem' Key: IGNITE-8850 URL: https://issues.apache.org/jira/browse/IGNITE-8850 Project: Ignite Issue Type: New Feature Components: ml Reporter: Turik Campbell Assignee: Turik Campbell Fix For: 2.6 The Travelling Salesman Problem (TSP) asks the following question: "Given a list of cities and the distances between each pair of cities, what is the shortest possible route that visits each city and returns to the origin city? Additional Information: https://en.wikipedia.org/wiki/Travelling_salesman_problem -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7782) Thin Client lib: Python
[ https://issues.apache.org/jira/browse/IGNITE-7782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kosenchuk reassigned IGNITE-7782: Assignee: Dmitry Melnichuk (was: Alexey Kosenchuk) > Thin Client lib: Python > --- > > Key: IGNITE-7782 > URL: https://issues.apache.org/jira/browse/IGNITE-7782 > Project: Ignite > Issue Type: New Feature > Components: thin client >Reporter: Alexey Kosenchuk >Assignee: Dmitry Melnichuk >Priority: Major > > Implement Thin (lightweight) Client lib in Python programming language for > Ignite Binary Client Protocol > https://apacheignite.readme.io/v2.4/docs/binary-client-protocol > Prototype: > https://github.com/skozlov-gridgain/apache-ignite-python-thin-client > Example - NodeJS client - IGNITE- > https://github.com/nobitlost/ignite/tree/master/modules/platforms/nodejs > --- > Location of the lib: > .../modules/platforms/python > Python version: > 3.4+ > Spec autogeneration: > Sphinx + Autodoc + Readthedocs > Test framework: > pytest -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7163) Validate connection from a pre-previous node
[ https://issues.apache.org/jira/browse/IGNITE-7163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519630#comment-16519630 ] Dmitriy Pavlov commented on IGNITE-7163: [~sergey-chugunov] [~dkarachentsev] I've found several suspicious tests with 0% fail rate in master, so I've retriggered these builds. > Validate connection from a pre-previous node > > > Key: IGNITE-7163 > URL: https://issues.apache.org/jira/browse/IGNITE-7163 > Project: Ignite > Issue Type: Sub-task > Components: general >Affects Versions: 2.3 >Reporter: Alexandr Kuramshin >Assignee: Dmitry Karachentsev >Priority: Major > Labels: discovery > Fix For: 2.6 > > > If some pre-previous node connects to the local node with the previous node > in the message's failed nodes collection additional steps should be done: > # Connection with the previous node should be validated. > # If a message from the previous node was not received a long time ago, the > previous node should be considered as failed and the pre-previous node > connection accepted. > # If the previous node connection is alive then different scenarios possible > ## Answer with a new result code causing the pre-previous node to try to > reconnect to the previous node > ## Break connection with the pre-previous node causing to continue the > possible cluster split. > ## Check connections with nodes after pre-previous node and delay decision by > answering RES_WAIT to get more predictable split and stable topology. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8831) MarshallerMappingFileStore: Incorrect locks on files
[ https://issues.apache.org/jira/browse/IGNITE-8831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519580#comment-16519580 ] Dmitriy Pavlov commented on IGNITE-8831: [~Jokser], [~astelmak], I've retriggered a number of suites. A lot of tests has 0% failure rate in master, so I would like to re-check. > MarshallerMappingFileStore: Incorrect locks on files > > > Key: IGNITE-8831 > URL: https://issues.apache.org/jira/browse/IGNITE-8831 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Stelmak >Assignee: Alexey Stelmak >Priority: Major > Fix For: 2.6 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8846) Optimize entry transform operations.
[ https://issues.apache.org/jira/browse/IGNITE-8846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519565#comment-16519565 ] ASF GitHub Bot commented on IGNITE-8846: GitHub user ascherbakoff opened a pull request: https://github.com/apache/ignite/pull/4241 IGNITE-8846 Optimize entry transform operations. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-8846 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4241.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4241 commit cf12c78b4f87469d0f7c2a234b9e1f4dc34c10f4 Author: Aleksei Scherbakov Date: 2018-06-21T16:34:40Z IGNITE-8846 Optimize entry transform operations. > Optimize entry transform operations. > > > Key: IGNITE-8846 > URL: https://issues.apache.org/jira/browse/IGNITE-8846 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Alexei Scherbakov >Assignee: Alexei Scherbakov >Priority: Major > Fix For: 2.6 > > > 1. For pessimistic transactions entryProcessor is invoked twice if tx entry > is already exists in [1] > and after lock acquistion in [2] > Actually this is enough to do it only once in postLockWrite. > 2. Cache entry value is not needed on near node if EntryProcessor declares > Void return type. > We should try to detect this in runtime or provide some kind of annotation to > mark EntryProcessor not caring about return value. This will bring huge > performance benefit for transactions updating large values using > transformations. > [1] > org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal#enlistWriteEntry > [2] > org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter#postLockWrite -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8699) ZookeeperDiscoverySpiTest#testDisconnectOnServersLeft flaky fails (rarely)
[
https://issues.apache.org/jira/browse/IGNITE-8699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519561#comment-16519561
]
ASF GitHub Bot commented on IGNITE-8699:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4161
> ZookeeperDiscoverySpiTest#testDisconnectOnServersLeft flaky fails (rarely)
> --
>
> Key: IGNITE-8699
> URL: https://issues.apache.org/jira/browse/IGNITE-8699
> Project: Ignite
> Issue Type: Bug
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
> Attachments: thread-dump-fail-before-local-join
>
>
> *Affected tests:*
> testDisconnectOnServersLeft_1
> testDisconnectOnServersLeft_2
> testDisconnectOnServersLeft_3
> testDisconnectOnServersLeft_4
> testDisconnectOnServersLeft_5
> {noformat}
> junit.framework.AssertionFailedError: Failed to wait for disconnect/reconnect
> event.
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.TestCase.fail(TestCase.java:227)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.waitReconnectEvent(ZookeeperDiscoverySpiTest.java:4685)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.disconnectOnServersLeft(ZookeeperDiscoverySpiTest.java:3541)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testDisconnectOnServersLeft_4(ZookeeperDiscoverySpiTest.java:3476)
> 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:2086)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:140)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2001)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8699) ZookeeperDiscoverySpiTest#testDisconnectOnServersLeft flaky fails (rarely)
[
https://issues.apache.org/jira/browse/IGNITE-8699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519560#comment-16519560
]
Dmitriy Pavlov commented on IGNITE-8699:
[~VitaliyB], [~sergey-chugunov], I've added several changes related to code
style and merged change.
Changes were Idea inspections proposals, such as naming of ignored exception
'e' to 'ignored', space line between semantic blocks.
> ZookeeperDiscoverySpiTest#testDisconnectOnServersLeft flaky fails (rarely)
> --
>
> Key: IGNITE-8699
> URL: https://issues.apache.org/jira/browse/IGNITE-8699
> Project: Ignite
> Issue Type: Bug
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
> Attachments: thread-dump-fail-before-local-join
>
>
> *Affected tests:*
> testDisconnectOnServersLeft_1
> testDisconnectOnServersLeft_2
> testDisconnectOnServersLeft_3
> testDisconnectOnServersLeft_4
> testDisconnectOnServersLeft_5
> {noformat}
> junit.framework.AssertionFailedError: Failed to wait for disconnect/reconnect
> event.
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.TestCase.fail(TestCase.java:227)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.waitReconnectEvent(ZookeeperDiscoverySpiTest.java:4685)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.disconnectOnServersLeft(ZookeeperDiscoverySpiTest.java:3541)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testDisconnectOnServersLeft_4(ZookeeperDiscoverySpiTest.java:3476)
> 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:2086)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:140)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2001)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8699) ZookeeperDiscoverySpiTest#testDisconnectOnServersLeft flaky fails (rarely)
[
https://issues.apache.org/jira/browse/IGNITE-8699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-8699:
---
Fix Version/s: 2.7
> ZookeeperDiscoverySpiTest#testDisconnectOnServersLeft flaky fails (rarely)
> --
>
> Key: IGNITE-8699
> URL: https://issues.apache.org/jira/browse/IGNITE-8699
> Project: Ignite
> Issue Type: Bug
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
> Attachments: thread-dump-fail-before-local-join
>
>
> *Affected tests:*
> testDisconnectOnServersLeft_1
> testDisconnectOnServersLeft_2
> testDisconnectOnServersLeft_3
> testDisconnectOnServersLeft_4
> testDisconnectOnServersLeft_5
> {noformat}
> junit.framework.AssertionFailedError: Failed to wait for disconnect/reconnect
> event.
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.TestCase.fail(TestCase.java:227)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.waitReconnectEvent(ZookeeperDiscoverySpiTest.java:4685)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.disconnectOnServersLeft(ZookeeperDiscoverySpiTest.java:3541)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testDisconnectOnServersLeft_4(ZookeeperDiscoverySpiTest.java:3476)
> 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:2086)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:140)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2001)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
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=16519555#comment-16519555
]
Alexey Stelmak commented on IGNITE-8780:
PR: https://github.com/apache/ignite/pull/4240
> 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.6
>
>
> 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] [Commented] (IGNITE-8849) Split suites to achieve 1 hour per suite run
[ https://issues.apache.org/jira/browse/IGNITE-8849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519554#comment-16519554 ] ASF GitHub Bot commented on IGNITE-8849: GitHub user EdShangGG opened a pull request: https://github.com/apache/ignite/pull/4239 IGNITE-8849 Signed-off-by: EdShangGG You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-8849 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4239.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4239 commit 89632e637831c7cc8f79e73a9d9f35663d0454d6 Author: EdShangGG Date: 2018-06-21T16:13:58Z Split PDS suites Signed-off-by: EdShangGG > Split suites to achieve 1 hour per suite run > > > Key: IGNITE-8849 > URL: https://issues.apache.org/jira/browse/IGNITE-8849 > Project: Ignite > Issue Type: Improvement >Reporter: Eduard Shangareev >Assignee: Eduard Shangareev >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8849) Split suites to achieve 1 hour per suite run
[ https://issues.apache.org/jira/browse/IGNITE-8849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduard Shangareev reassigned IGNITE-8849: - Assignee: Eduard Shangareev > Split suites to achieve 1 hour per suite run > > > Key: IGNITE-8849 > URL: https://issues.apache.org/jira/browse/IGNITE-8849 > Project: Ignite > Issue Type: Improvement >Reporter: Eduard Shangareev >Assignee: Eduard Shangareev >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8849) Split suites to achieve 1 hour per suite run
Eduard Shangareev created IGNITE-8849: - Summary: Split suites to achieve 1 hour per suite run Key: IGNITE-8849 URL: https://issues.apache.org/jira/browse/IGNITE-8849 Project: Ignite Issue Type: Improvement Reporter: Eduard Shangareev -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8462) DataStreamerImpl.close(true) should throw exception
[ https://issues.apache.org/jira/browse/IGNITE-8462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Fedotov updated IGNITE-8462: - Description: DataStreamerImpl.close(true) should throw CacheException in case if there was addition data to DataStreamerImpl. Future, returned by DataStreamerImpl.addData() also should be done after close streamer. Update. New design for this ticket is described in comments. was: DataStreamerImpl.close(true) should throw CacheException in case if there was addition data to DataStreamerImpl. Future, returned by DataStreamerImpl.addData() also should be done after close streamer. Update. New design for this ticket: > DataStreamerImpl.close(true) should throw exception > --- > > Key: IGNITE-8462 > URL: https://issues.apache.org/jira/browse/IGNITE-8462 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > > DataStreamerImpl.close(true) should throw CacheException in case if there was > addition data to DataStreamerImpl. Future, returned by > DataStreamerImpl.addData() also should be done after close streamer. > Update. New design for this ticket is described in comments. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8462) DataStreamerImpl.close(true) should throw exception
[ https://issues.apache.org/jira/browse/IGNITE-8462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Fedotov updated IGNITE-8462: - Description: DataStreamerImpl.close(true) should throw CacheException in case if there was addition data to DataStreamerImpl. Future, returned by DataStreamerImpl.addData() also should be done after close streamer. Update. New design for this ticket: was:DataStreamerImpl.close(true) should throw CacheException in case if there was addition data to DataStreamerImpl. Future, returned by DataStreamerImpl.addData() also should be done after close streamer. > DataStreamerImpl.close(true) should throw exception > --- > > Key: IGNITE-8462 > URL: https://issues.apache.org/jira/browse/IGNITE-8462 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > > DataStreamerImpl.close(true) should throw CacheException in case if there was > addition data to DataStreamerImpl. Future, returned by > DataStreamerImpl.addData() also should be done after close streamer. > Update. New design for this ticket: -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8462) DataStreamerImpl.close(true) should throw exception
[ https://issues.apache.org/jira/browse/IGNITE-8462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519490#comment-16519490 ] Ivan Fedotov commented on IGNITE-8462: -- According to [~avinogradov] corrections this ticket has a new design. It's necessary to done all futures from thread buffer in DataStreamerImpl.close(true) case. Also I implement inner class in DataStreamerImpl to make work with IgniteCacheFuture, List pair easier and prevent null values. > DataStreamerImpl.close(true) should throw exception > --- > > Key: IGNITE-8462 > URL: https://issues.apache.org/jira/browse/IGNITE-8462 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > > DataStreamerImpl.close(true) should throw CacheException in case if there was > addition data to DataStreamerImpl. Future, returned by > DataStreamerImpl.addData() also should be done after close streamer. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8848) Introduce new split-brain tests when topology is under load
Pavel Kovalenko created IGNITE-8848: --- Summary: Introduce new split-brain tests when topology is under load Key: IGNITE-8848 URL: https://issues.apache.org/jira/browse/IGNITE-8848 Project: Ignite Issue Type: Improvement Components: cache, zookeeper Affects Versions: 2.5 Reporter: Pavel Kovalenko Assignee: Pavel Kovalenko Fix For: 2.6 We should check following cases: 1) Primary node of transaction located at a part of a cluster that will survive, while backup doesn't. 2) Backup node of transaction located at a part of a cluster that will survive, while primary doesn't. 3) A client has a connection to both split-brained parts. 4) A client has a connection to only 1 part of a split cluster. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7526) SQL: Introduce memory region for reducer merge results with disk offload
[ https://issues.apache.org/jira/browse/IGNITE-7526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519424#comment-16519424 ] ASF GitHub Bot commented on IGNITE-7526: GitHub user tledkov-gridgain opened a pull request: https://github.com/apache/ignite/pull/4238 IGNITE-7526 SQL: Introduce memory region for reducer merge results with disk offload You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-7526 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4238.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4238 commit 47232c571d1efcad9017286ba10d6ec362eae100 Author: devozerov Date: 2018-06-13T13:01:12Z It works! commit 199b93202848a2e87bc4ba82f584ed51cca67b43 Author: tledkov-gridgain Date: 2018-06-19T15:03:28Z Merge branch '_master' into ignite-7526 commit 85dbca4d0f68202769aeae163f59bb2cd2698920 Author: tledkov-gridgain Date: 2018-06-20T11:59:50Z IGNITE-7526: minor commit c02ba93abc953fe7c39b2d0b0d4a093c351504f5 Author: tledkov-gridgain Date: 2018-06-21T14:07:44Z IGNITE-7526: save the progress commit 2d66389cc1a70cff0765cf3967651fe4994c280e Author: tledkov-gridgain Date: 2018-06-21T14:10:41Z Merge branch '_master' into ignite-7526 > SQL: Introduce memory region for reducer merge results with disk offload > > > Key: IGNITE-7526 > URL: https://issues.apache.org/jira/browse/IGNITE-7526 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Vladimir Ozerov >Assignee: Taras Ledkov >Priority: Major > > Currently all results received from map nodes are stored inside reducer's > heap memory. What is worse, in case of complex queries, such as having sorts > or groupings, need to collect all results from mappers first before final > processing could be applied. In case of big results set (or intermediate > results) this could easily lead to OOME on reducer. > To mitigate this we should introduce special memory area where intermediate > results could be stored. All final processing should be stored in the same > area as well. This area should be of limited size and should be able to > offload results to disk in case of overflow. > We could start with our B+Tree and free list and store results in some K-V > form. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8847) Node doesn't stop on node verification failure
[ https://issues.apache.org/jira/browse/IGNITE-8847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov updated IGNITE-8847: -- Fix Version/s: 2.6 > Node doesn't stop on node verification failure > -- > > Key: IGNITE-8847 > URL: https://issues.apache.org/jira/browse/IGNITE-8847 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.5 >Reporter: Mikhail Cherkasov >Assignee: Mikhail Cherkasov >Priority: Major > Fix For: 2.6 > > > Node doesn't stop on verification failure -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8847) Node doesn't stop on node verification failure
Mikhail Cherkasov created IGNITE-8847: - Summary: Node doesn't stop on node verification failure Key: IGNITE-8847 URL: https://issues.apache.org/jira/browse/IGNITE-8847 Project: Ignite Issue Type: Bug Components: general Reporter: Mikhail Cherkasov Assignee: Mikhail Cherkasov Node doesn't stop on verification failure -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8847) Node doesn't stop on node verification failure
[ https://issues.apache.org/jira/browse/IGNITE-8847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov updated IGNITE-8847: -- Affects Version/s: 2.5 > Node doesn't stop on node verification failure > -- > > Key: IGNITE-8847 > URL: https://issues.apache.org/jira/browse/IGNITE-8847 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.5 >Reporter: Mikhail Cherkasov >Assignee: Mikhail Cherkasov >Priority: Major > > Node doesn't stop on verification failure -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8846) Optimize entry transform operations.
[ https://issues.apache.org/jira/browse/IGNITE-8846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexei Scherbakov updated IGNITE-8846: -- Affects Version/s: 2.5 Fix Version/s: 2.6 > Optimize entry transform operations. > > > Key: IGNITE-8846 > URL: https://issues.apache.org/jira/browse/IGNITE-8846 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Alexei Scherbakov >Assignee: Alexei Scherbakov >Priority: Major > Fix For: 2.6 > > > 1. For pessimistic transactions entryProcessor is invoked twice if tx entry > is already exists in [1] > and after lock acquistion in [2] > Actually this is enough to do it only once in postLockWrite. > 2. Cache entry value is not needed on near node if EntryProcessor declares > Void return type. > We should try to detect this in runtime or provide some kind of annotation to > mark EntryProcessor not caring about return value. This will bring huge > performance benefit for transactions updating large values using > transformations. > [1] > org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal#enlistWriteEntry > [2] > org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter#postLockWrite -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8189) Improve ZkDistributedCollectDataFuture#deleteFutureData implementation
[ https://issues.apache.org/jira/browse/IGNITE-8189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita reassigned IGNITE-8189: --- Assignee: Amelchev Nikita > Improve ZkDistributedCollectDataFuture#deleteFutureData implementation > -- > > Key: IGNITE-8189 > URL: https://issues.apache.org/jira/browse/IGNITE-8189 > Project: Ignite > Issue Type: Improvement > Components: zookeeper >Reporter: Sergey Chugunov >Assignee: Amelchev Nikita >Priority: Major > > Three issues need to be improved in implementation: > * two more deleteIfExists methods within the *deleteFutureData* to be > included in batching *deleteAll* operation; > * if request exceeds ZooKeeper max size limit fallback to one-by-one deletion > should be used (related ticket IGNITE-8188); > * ZookeeperClient#deleteAll implementation may throw NoNodeException is case > of concurrent operation removing the same nodes, in this case fallback to > one-by-one deletion should be used too. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8846) Optimize entry transform operations.
Alexei Scherbakov created IGNITE-8846: - Summary: Optimize entry transform operations. Key: IGNITE-8846 URL: https://issues.apache.org/jira/browse/IGNITE-8846 Project: Ignite Issue Type: Improvement Reporter: Alexei Scherbakov Assignee: Alexei Scherbakov 1. For pessimistic transactions entryProcessor is invoked twice if tx entry is already exists in [1] and after lock acquistion in [2] Actually this is enough to do it only once in postLockWrite. 2. Cache entry value is not needed on near node if EntryProcessor declares Void return type. We should try to detect this in runtime or provide some kind of annotation to mark EntryProcessor not caring about return value. This will bring huge performance benefit for transactions updating large values using transformations. [1] org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal#enlistWriteEntry [2] org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter#postLockWrite -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8752) Deadlock when registering binary metadata while holding topology read lock
[
https://issues.apache.org/jira/browse/IGNITE-8752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519353#comment-16519353
]
Ilya Lantukh commented on IGNITE-8752:
--
https://ci.ignite.apache.org/viewQueued.html?itemId=1410836
> Deadlock when registering binary metadata while holding topology read lock
> --
>
> Key: IGNITE-8752
> URL: https://issues.apache.org/jira/browse/IGNITE-8752
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Assignee: Ilya Lantukh
>Priority: Critical
> Fix For: 2.6
>
> Attachments: DeadlockTest.java
>
>
> The following deadlock was reproduced on ignite-2.4 version:
> {code}
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.MarshallerContextImpl.registerClassName(MarshallerContextImpl.java:284)
> at
> org.apache.ignite.internal.binary.BinaryContext.registerUserClassName(BinaryContext.java:1191)
> at
> org.apache.ignite.internal.binary.BinaryContext.registerUserClassDescriptor(BinaryContext.java:773)
> at
> org.apache.ignite.internal.binary.BinaryContext.registerClassDescriptor(BinaryContext.java:751)
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForClass(BinaryContext.java:622)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:164)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:147)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:134)
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.marshal(GridBinaryMarshaller.java:251)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.marshalToBinary(CacheObjectBinaryProcessorImpl.java:396)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.marshalToBinary(CacheObjectBinaryProcessorImpl.java:381)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.toBinary(CacheObjectBinaryProcessorImpl.java:875)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.toCacheObject(CacheObjectBinaryProcessorImpl.java:825)
> at
> org.apache.ignite.internal.processors.cache.GridCacheContext.toCacheObject(GridCacheContext.java:1783)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.runEntryProcessor(GridCacheMapEntry.java:5264)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:4667)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:4484)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.invokeClosure(BPlusTree.java:3083)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.access$6200(BPlusTree.java:2977)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(BPlusTree.java:1732)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1610)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1270)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:370)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:1769)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2420)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:1883)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1736)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1628)
> at
>
[jira] [Commented] (IGNITE-8752) Deadlock when registering binary metadata while holding topology read lock
[
https://issues.apache.org/jira/browse/IGNITE-8752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519347#comment-16519347
]
ASF GitHub Bot commented on IGNITE-8752:
GitHub user ilantukh opened a pull request:
https://github.com/apache/ignite/pull/4237
IGNITE-8752 : Ensure that binary metadata is registered outside of topology
lock.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-8752
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4237.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #4237
commit 2553084ac7e02c68000b001d065103249bdc2bca
Author: Ilya Lantukh
Date: 2018-06-21T13:11:16Z
IGNITE-8752 : Ensure that binary metadata is registered outside of topology
lock.
> Deadlock when registering binary metadata while holding topology read lock
> --
>
> Key: IGNITE-8752
> URL: https://issues.apache.org/jira/browse/IGNITE-8752
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Assignee: Ilya Lantukh
>Priority: Critical
> Fix For: 2.6
>
> Attachments: DeadlockTest.java
>
>
> The following deadlock was reproduced on ignite-2.4 version:
> {code}
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.MarshallerContextImpl.registerClassName(MarshallerContextImpl.java:284)
> at
> org.apache.ignite.internal.binary.BinaryContext.registerUserClassName(BinaryContext.java:1191)
> at
> org.apache.ignite.internal.binary.BinaryContext.registerUserClassDescriptor(BinaryContext.java:773)
> at
> org.apache.ignite.internal.binary.BinaryContext.registerClassDescriptor(BinaryContext.java:751)
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForClass(BinaryContext.java:622)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:164)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:147)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:134)
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.marshal(GridBinaryMarshaller.java:251)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.marshalToBinary(CacheObjectBinaryProcessorImpl.java:396)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.marshalToBinary(CacheObjectBinaryProcessorImpl.java:381)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.toBinary(CacheObjectBinaryProcessorImpl.java:875)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.toCacheObject(CacheObjectBinaryProcessorImpl.java:825)
> at
> org.apache.ignite.internal.processors.cache.GridCacheContext.toCacheObject(GridCacheContext.java:1783)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.runEntryProcessor(GridCacheMapEntry.java:5264)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:4667)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:4484)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.invokeClosure(BPlusTree.java:3083)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.access$6200(BPlusTree.java:2977)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(BPlusTree.java:1732)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1610)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1270)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:370)
> at
>
[jira] [Updated] (IGNITE-8715) Problems with Closeable objects from Factory
[ https://issues.apache.org/jira/browse/IGNITE-8715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Menshikov updated IGNITE-8715: Description: According to specification Cache#close() should clean up all Closeable objects (CacheLoader, CacheWriter, CacheEntryListener, ExpiryPolicy) created by factories. And in TCK 1.0.1 there are no such tests. But in TCK 1.1.0 there are checks for it. And Ignite fails it because hasn't such functionality. So this task about improvement. Please see links for details. was: According to spec Cache#close() should clean up all Closeable objects (CacheLoader, CacheWriter, CacheEntryListener, ExpiryPolicy) created by factories. And in TCK 1.0.1 there are no such tests. But in TCK 1.1.0 there are checks for it. And Ignite fails it because hasn't such functionality. So this task about improvement. Please see links for details. > Problems with Closeable objects from Factory > > > Key: IGNITE-8715 > URL: https://issues.apache.org/jira/browse/IGNITE-8715 > Project: Ignite > Issue Type: Sub-task >Reporter: Alexander Menshikov >Priority: Major > Labels: iep-21 > Fix For: 2.6 > > > According to specification Cache#close() should clean up all Closeable > objects (CacheLoader, CacheWriter, CacheEntryListener, ExpiryPolicy) created > by factories. > And in TCK 1.0.1 there are no such tests. But in TCK 1.1.0 there are checks > for it. And Ignite fails it because hasn't such functionality. > So this task about improvement. > Please see links for details. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8845) GridUnsafe.allocateMemory throws OutOfMemoryError which isn't handled
Mikhail Cherkasov created IGNITE-8845: - Summary: GridUnsafe.allocateMemory throws OutOfMemoryError which isn't handled Key: IGNITE-8845 URL: https://issues.apache.org/jira/browse/IGNITE-8845 Project: Ignite Issue Type: Bug Components: general Affects Versions: 2.5 Reporter: Mikhail Cherkasov Fix For: 2.6 Attachments: Main.java If there's no more native memory then Unsafe.allocateMemor throws java.lang.OutOfMemoryError. Errors - is type of exception after which you can't restore application and you need to close it and restart. I think in this case we can handle it and throw IgniteOOM instead. Reproducer is attached, it throws the following exception: Exception in thread "main" java.lang.OutOfMemoryError at sun.misc.Unsafe.allocateMemory(Native Method) at org.apache.ignite.internal.util.GridUnsafe.allocateMemory(GridUnsafe.java:1068) at org.apache.ignite.internal.mem.unsafe.UnsafeMemoryProvider.nextRegion(UnsafeMemoryProvider.java:80) at org.apache.ignite.internal.pagemem.impl.PageMemoryNoStoreImpl.addSegment(PageMemoryNoStoreImpl.java:612) at org.apache.ignite.internal.pagemem.impl.PageMemoryNoStoreImpl.allocatePage(PageMemoryNoStoreImpl.java:287) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (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:all-tabpanel ] Alexander Gerus reassigned IGNITE-8740: --- Assignee: Amir Akhmedov (was: Alexander Gerus) > 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] [Assigned] (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:all-tabpanel ] Alexander Gerus reassigned IGNITE-8740: --- Assignee: Alexander Gerus (was: Amir Akhmedov) > 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: Alexander Gerus >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] [Comment Edited] (IGNITE-8699) ZookeeperDiscoverySpiTest#testDisconnectOnServersLeft flaky fails (rarely)
[
https://issues.apache.org/jira/browse/IGNITE-8699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519330#comment-16519330
]
Sergey Chugunov edited comment on IGNITE-8699 at 6/21/18 12:53 PM:
---
[~VitaliyB],
I triggered *ZooKeeper (Discovery) 2* suite, results look good to me: [TC
link|https://ci.ignite.apache.org/viewLog.html?buildId=1374005=IgniteTests24Java8_ZooKeeperDiscovery1=buildResultsDiv]
We can proceed with merging.
was (Author: sergey-chugunov):
[~VitaliyB],
I triggered ZooKeeper (Discovery) 2 suite, results look good to me: [TC
link|https://ci.ignite.apache.org/viewLog.html?buildId=1374005=IgniteTests24Java8_ZooKeeperDiscovery1=buildResultsDiv]
We can proceed with merging.
> ZookeeperDiscoverySpiTest#testDisconnectOnServersLeft flaky fails (rarely)
> --
>
> Key: IGNITE-8699
> URL: https://issues.apache.org/jira/browse/IGNITE-8699
> Project: Ignite
> Issue Type: Bug
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Attachments: thread-dump-fail-before-local-join
>
>
> *Affected tests:*
> testDisconnectOnServersLeft_1
> testDisconnectOnServersLeft_2
> testDisconnectOnServersLeft_3
> testDisconnectOnServersLeft_4
> testDisconnectOnServersLeft_5
> {noformat}
> junit.framework.AssertionFailedError: Failed to wait for disconnect/reconnect
> event.
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.TestCase.fail(TestCase.java:227)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.waitReconnectEvent(ZookeeperDiscoverySpiTest.java:4685)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.disconnectOnServersLeft(ZookeeperDiscoverySpiTest.java:3541)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testDisconnectOnServersLeft_4(ZookeeperDiscoverySpiTest.java:3476)
> 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:2086)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:140)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2001)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8699) ZookeeperDiscoverySpiTest#testDisconnectOnServersLeft flaky fails (rarely)
[
https://issues.apache.org/jira/browse/IGNITE-8699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519330#comment-16519330
]
Sergey Chugunov commented on IGNITE-8699:
-
[~VitaliyB],
I triggered ZooKeeper (Discovery) 2 suite, results look good to me: [TC
link|https://ci.ignite.apache.org/viewLog.html?buildId=1374005=IgniteTests24Java8_ZooKeeperDiscovery1=buildResultsDiv]
We can proceed with merging.
> ZookeeperDiscoverySpiTest#testDisconnectOnServersLeft flaky fails (rarely)
> --
>
> Key: IGNITE-8699
> URL: https://issues.apache.org/jira/browse/IGNITE-8699
> Project: Ignite
> Issue Type: Bug
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Attachments: thread-dump-fail-before-local-join
>
>
> *Affected tests:*
> testDisconnectOnServersLeft_1
> testDisconnectOnServersLeft_2
> testDisconnectOnServersLeft_3
> testDisconnectOnServersLeft_4
> testDisconnectOnServersLeft_5
> {noformat}
> junit.framework.AssertionFailedError: Failed to wait for disconnect/reconnect
> event.
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.TestCase.fail(TestCase.java:227)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.waitReconnectEvent(ZookeeperDiscoverySpiTest.java:4685)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.disconnectOnServersLeft(ZookeeperDiscoverySpiTest.java:3541)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testDisconnectOnServersLeft_4(ZookeeperDiscoverySpiTest.java:3476)
> 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:2086)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:140)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2001)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8188) Batching operations should perform check for ZooKeeper request max size
[ https://issues.apache.org/jira/browse/IGNITE-8188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519275#comment-16519275 ] ASF GitHub Bot commented on IGNITE-8188: GitHub user NSAmelchev opened a pull request: https://github.com/apache/ignite/pull/4236 IGNITE-8188 - split into batches "createAll" and "deleteAll" operations if request size overflow - added tests You can merge this pull request into a Git repository by running: $ git pull https://github.com/NSAmelchev/ignite ignite-8188 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4236.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4236 commit df075b8ef16f528c7029dfd01c7aeb7489000b74 Author: NSAmelchev Date: 2018-06-21T12:02:00Z Fix for ignite-8188 > Batching operations should perform check for ZooKeeper request max size > --- > > Key: IGNITE-8188 > URL: https://issues.apache.org/jira/browse/IGNITE-8188 > Project: Ignite > Issue Type: Improvement > Components: zookeeper >Reporter: Sergey Chugunov >Assignee: Amelchev Nikita >Priority: Major > > As ZooKeeper documentation > [says|https://zookeeper.apache.org/doc/r3.4.3/api/org/apache/zookeeper/ZooKeeper.html#multi(java.lang.Iterable)] > batching *multi* operation has a limit for size of a single request. > ZookeeperClient batching methods *createAll* and *deleteAll* should check > this limit and fall back to execute operations one by one. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8752) Deadlock when registering binary metadata while holding topology read lock
[
https://issues.apache.org/jira/browse/IGNITE-8752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519273#comment-16519273
]
ASF GitHub Bot commented on IGNITE-8752:
Github user ilantukh closed the pull request at:
https://github.com/apache/ignite/pull/4215
> Deadlock when registering binary metadata while holding topology read lock
> --
>
> Key: IGNITE-8752
> URL: https://issues.apache.org/jira/browse/IGNITE-8752
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Assignee: Ilya Lantukh
>Priority: Critical
> Fix For: 2.6
>
> Attachments: DeadlockTest.java
>
>
> The following deadlock was reproduced on ignite-2.4 version:
> {code}
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.MarshallerContextImpl.registerClassName(MarshallerContextImpl.java:284)
> at
> org.apache.ignite.internal.binary.BinaryContext.registerUserClassName(BinaryContext.java:1191)
> at
> org.apache.ignite.internal.binary.BinaryContext.registerUserClassDescriptor(BinaryContext.java:773)
> at
> org.apache.ignite.internal.binary.BinaryContext.registerClassDescriptor(BinaryContext.java:751)
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForClass(BinaryContext.java:622)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:164)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:147)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:134)
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.marshal(GridBinaryMarshaller.java:251)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.marshalToBinary(CacheObjectBinaryProcessorImpl.java:396)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.marshalToBinary(CacheObjectBinaryProcessorImpl.java:381)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.toBinary(CacheObjectBinaryProcessorImpl.java:875)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.toCacheObject(CacheObjectBinaryProcessorImpl.java:825)
> at
> org.apache.ignite.internal.processors.cache.GridCacheContext.toCacheObject(GridCacheContext.java:1783)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.runEntryProcessor(GridCacheMapEntry.java:5264)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:4667)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:4484)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.invokeClosure(BPlusTree.java:3083)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.access$6200(BPlusTree.java:2977)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(BPlusTree.java:1732)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1610)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1270)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:370)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:1769)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2420)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:1883)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1736)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1628)
> at
>
[jira] [Commented] (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:comment-tabpanel=16519271#comment-16519271 ] ASF GitHub Bot commented on IGNITE-8795: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4214 > 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.6 > > > 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] [Assigned] (IGNITE-8817) Web Console: Remove red links everywhere and do all links blue
[ https://issues.apache.org/jira/browse/IGNITE-8817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vica Abramova reassigned IGNITE-8817: - Assignee: Alexey Kuznetsov (was: Vica Abramova) > Web Console: Remove red links everywhere and do all links blue > -- > > Key: IGNITE-8817 > URL: https://issues.apache.org/jira/browse/IGNITE-8817 > Project: Ignite > Issue Type: Improvement > Components: UI, wizards >Reporter: Vica Abramova >Assignee: Alexey Kuznetsov >Priority: Major > Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png, > screenshot-4.png > > > * Do this on Admin Panel screen (period control and Email column) > * Do this in all modal windows, where we have the links. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8817) Web Console: Remove red links everywhere and do all links blue
[ https://issues.apache.org/jira/browse/IGNITE-8817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519269#comment-16519269 ] Vica Abramova commented on IGNITE-8817: --- Everything is okey! > Web Console: Remove red links everywhere and do all links blue > -- > > Key: IGNITE-8817 > URL: https://issues.apache.org/jira/browse/IGNITE-8817 > Project: Ignite > Issue Type: Improvement > Components: UI, wizards >Reporter: Vica Abramova >Assignee: Vica Abramova >Priority: Major > Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png, > screenshot-4.png > > > * Do this on Admin Panel screen (period control and Email column) > * Do this in all modal windows, where we have the links. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8844) Provide example how to implement auto-activation policy when cluster is activated first time
Pavel Kovalenko created IGNITE-8844: --- Summary: Provide example how to implement auto-activation policy when cluster is activated first time Key: IGNITE-8844 URL: https://issues.apache.org/jira/browse/IGNITE-8844 Project: Ignite Issue Type: Improvement Components: cache Affects Versions: 2.5, 2.4 Reporter: Pavel Kovalenko Fix For: 2.6 Some of the our users which use Ignite embedded face with the problem how to activate cluster first time, when no first baseline established. We should provide an example of such policy as we did it with BaselineWatcher. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8774) Daemon moves cluster to compatibility mode when joins
[
https://issues.apache.org/jira/browse/IGNITE-8774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov reassigned IGNITE-8774:
-
Assignee: Aleksey Plekhanov
> Daemon moves cluster to compatibility mode when joins
> -
>
> Key: IGNITE-8774
> URL: https://issues.apache.org/jira/browse/IGNITE-8774
> Project: Ignite
> Issue Type: Bug
>Reporter: Stanislav Lukyanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Fix For: 2.6
>
>
> When a daemon node joins the cluster seems to switch to compatibility mode
> (allowing nodes without baseline support). It prevents baseline nodes from
> being restarted.
> Example:
> {code}
> Ignite ignite1 =
> IgnitionEx.start("examples/config/persistentstore/example-persistent-store.xml",
> "srv1");
> Ignite ignite2 =
> IgnitionEx.start("examples/config/persistentstore/example-persistent-store.xml",
> "srv2");
> ignite2.cluster().active(true);
> IgnitionEx.setClientMode(true);
> IgnitionEx.setDaemon(true);
> Ignite daemon =
> IgnitionEx.start("examples/config/persistentstore/example-persistent-store.xml",
> "daemon");
> IgnitionEx.setClientMode(false);
> IgnitionEx.setDaemon(false);
> ignite2.close();
> IgnitionEx.start("examples/config/persistentstore/example-persistent-store.xml",
> "srv2");
> {code}
> The attempt to restart ignite2 throws an exception:
> {code}
> [2018-06-11 18:45:25,766][ERROR][tcp-disco-msg-worker-#39%srv2%][root]
> 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=class
> o.a.i.IgniteException: Node with BaselineTopology cannot join mixed cluster
> running in compatibility mode]]
> class org.apache.ignite.IgniteException: Node with BaselineTopology cannot
> join mixed cluster running in compatibility mode
> at
> org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.onGridDataReceived(GridClusterStateProcessor.java:714)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$5.onExchange(GridDiscoveryManager.java:883)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:1939)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddedMessage(ServerImpl.java:4354)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2744)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2536)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6775)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2621)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8819) Web Console: Edit everywhere the export buttons (2 types of design)
[ https://issues.apache.org/jira/browse/IGNITE-8819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov reassigned IGNITE-8819: Assignee: Alexey Kuznetsov (was: Ilya Borisov) > Web Console: Edit everywhere the export buttons (2 types of design) > --- > > Key: IGNITE-8819 > URL: https://issues.apache.org/jira/browse/IGNITE-8819 > Project: Ignite > Issue Type: Improvement > Components: UI, wizards >Reporter: Vica Abramova >Assignee: Alexey Kuznetsov >Priority: Major > Attachments: New Export.png > > > See the attachment, the goal is to make "export to CSV" button more subdued. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8819) Web Console: Edit everywhere the export buttons (2 types of design)
[ https://issues.apache.org/jira/browse/IGNITE-8819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov updated IGNITE-8819: - Description: See the attachment, the goal is to make "export to CSV" button more subdued. (was: See attached) > Web Console: Edit everywhere the export buttons (2 types of design) > --- > > Key: IGNITE-8819 > URL: https://issues.apache.org/jira/browse/IGNITE-8819 > Project: Ignite > Issue Type: Improvement > Components: UI, wizards >Reporter: Vica Abramova >Assignee: Ilya Borisov >Priority: Major > Attachments: New Export.png > > > See the attachment, the goal is to make "export to CSV" button more subdued. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8819) Web Console: Edit everywhere the export buttons (2 types of design)
[ https://issues.apache.org/jira/browse/IGNITE-8819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519203#comment-16519203 ] Ilya Borisov commented on IGNITE-8819: -- Places to check: * List of registered users. > Web Console: Edit everywhere the export buttons (2 types of design) > --- > > Key: IGNITE-8819 > URL: https://issues.apache.org/jira/browse/IGNITE-8819 > Project: Ignite > Issue Type: Improvement > Components: UI, wizards >Reporter: Vica Abramova >Assignee: Ilya Borisov >Priority: Major > Attachments: New Export.png > > > See attached -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7993) Striped pool can't be disabled
[
https://issues.apache.org/jira/browse/IGNITE-7993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519193#comment-16519193
]
ASF GitHub Bot commented on IGNITE-7993:
GitHub user gromtech opened a pull request:
https://github.com/apache/ignite/pull/4235
IGNITE-7993 Striped pool can't be disabled
Restored the capability to disable striped pool
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-7993-lite
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4235.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #4235
commit ff68b9dbb12d80c7fdd5c0d5e81680d97bd7d5f9
Author: Roman Guseinov
Date: 2018-06-21T10:12:08Z
IGNITE-7993 Striped pool can't be disabled
> Striped pool can't be disabled
> --
>
> Key: IGNITE-7993
> URL: https://issues.apache.org/jira/browse/IGNITE-7993
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.4
>Reporter: Valentin Kulichenko
>Assignee: Roman Guseinov
>Priority: Major
> Fix For: 2.6
>
>
> Javadoc for {{IgniteConfiguration#setStripedPoolSize}} states that striped
> pool can be disabled by providing value less or equal than zero:
> {noformat}
> If set to non-positive value then requests get processed in system pool.
> {noformat}
> However, doing that prevents node from startup, it fails with the following
> exception:
> {noformat}
> Caused by: class org.apache.ignite.IgniteCheckedException: Invalid
> stripedPool thread pool size (must be greater than 0), actual value: 0
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.validateThreadPoolSize(IgnitionEx.java:2061)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1799)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1716)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1144)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:664)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:589)
> at org.apache.ignite.Ignition.start(Ignition.java:322)
> ... 7 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8819) Web Console: Edit everywhere the export buttons (2 types of design)
[ https://issues.apache.org/jira/browse/IGNITE-8819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov reassigned IGNITE-8819: Assignee: Ilya Borisov (was: Alexey Kuznetsov) > Web Console: Edit everywhere the export buttons (2 types of design) > --- > > Key: IGNITE-8819 > URL: https://issues.apache.org/jira/browse/IGNITE-8819 > Project: Ignite > Issue Type: Improvement > Components: UI, wizards >Reporter: Vica Abramova >Assignee: Ilya Borisov >Priority: Major > Attachments: New Export.png > > > See attached -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8768) JVM crash in PDS1 suite in master branch
[ https://issues.apache.org/jira/browse/IGNITE-8768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Kovalenko reassigned IGNITE-8768: --- Assignee: Pavel Kovalenko Affects Version/s: 2.4 2.5 Fix is ready. Now PartitionsEvictor is stopped explicitly during cache group stop. TC link: https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8_IgniteTests24Java8=pull%2F4227%2Fhead > JVM crash in PDS1 suite in master branch > > > Key: IGNITE-8768 > URL: https://issues.apache.org/jira/browse/IGNITE-8768 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.5, 2.4 >Reporter: Sergey Chugunov >Assignee: Pavel Kovalenko >Priority: Blocker > Labels: MakeTeamcityGreenAgain > Fix For: 2.6 > > > JVM crash in latest build: [TC > link|https://ci.ignite.apache.org/viewLog.html?buildId=1372456=buildResultsDiv=IgniteTests24Java8_Pds1] > It is the first crash is latest 15 builds: [TC > link|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Pds1_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-4939) Receive event before cache initialized
[
https://issues.apache.org/jira/browse/IGNITE-4939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519179#comment-16519179
]
Evgenii Zhuravlev commented on IGNITE-4939:
---
I've checked team city:
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_RunAll_IgniteTests24Java8=pull%2F4226%2Fhead=buildTypeStatusDiv
- it contains some test failures, some of them are not reproducible, other
were failed even before this fix.
Pr for this issue have test SystemCacheNotConfiguredTest, it reproduces this
error on 2.4, but it looks like it was a race and it was somehow changed in 2.5
and it's not so easily reproducible. However, this issue still exists in master
and should be properly fixed.
> Receive event before cache initialized
> --
>
> Key: IGNITE-4939
> URL: https://issues.apache.org/jira/browse/IGNITE-4939
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.9
>Reporter: Nikolay Tikhonov
>Assignee: Evgenii Zhuravlev
>Priority: Blocker
> Fix For: 2.7
>
>
> Receive event before cache initialized that leads to the following:
> {noformat}
> Exception in thread "sys-#755%Default%" java.lang.IllegalArgumentException:
> Cache is not configured: ignite-sys-cache
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.jcache(GridCacheProcessor.java:3343)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.handleEvent(CacheContinuousQueryHandler.java:719)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.notifyCallback0(CacheContinuousQueryHandler.java:691)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.notifyCallback(CacheContinuousQueryHandler.java:650)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.processNotification(GridContinuousProcessor.java:1086)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.access$2000(GridContinuousProcessor.java:97)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$8.onMessage(GridContinuousProcessor.java:741)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1082)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1600(GridIoManager.java:102)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2332)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1042)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1900(GridIoManager.java:102)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$6.run(GridIoManager.java:1011)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8842) Web console: Wrong start screen on start of demo mode
[ https://issues.apache.org/jira/browse/IGNITE-8842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-8842: - Description: On start of demo mode screen with "SQL demo" notebook should be opened. Also on "Notebooks" screen "SQL demo" notebook should be available. On demo start "SQL demo" should be recreated if needed. was:On start of demo mode screen with "SQL demo" notebook should be opened. > Web console: Wrong start screen on start of demo mode > - > > Key: IGNITE-8842 > URL: https://issues.apache.org/jira/browse/IGNITE-8842 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Vasiliy Sisko >Priority: Minor > > On start of demo mode screen with "SQL demo" notebook should be opened. > Also on "Notebooks" screen "SQL demo" notebook should be available. > On demo start "SQL demo" should be recreated if needed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8843) Web console: Actualize "Getting started" content
Vasiliy Sisko created IGNITE-8843: - Summary: Web console: Actualize "Getting started" content Key: IGNITE-8843 URL: https://issues.apache.org/jira/browse/IGNITE-8843 Project: Ignite Issue Type: Bug Components: wizards Reporter: Vasiliy Sisko Assignee: Vasiliy Sisko -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8818) Web Console: Reduce the height of head of all tables and change the location of the content
[ https://issues.apache.org/jira/browse/IGNITE-8818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov reassigned IGNITE-8818: Assignee: Alexey Kuznetsov (was: Ilya Borisov) > Web Console: Reduce the height of head of all tables and change the location > of the content > --- > > Key: IGNITE-8818 > URL: https://issues.apache.org/jira/browse/IGNITE-8818 > Project: Ignite > Issue Type: Improvement > Components: UI, wizards >Reporter: Vica Abramova >Assignee: Alexey Kuznetsov >Priority: Major > Attachments: Table-header.png > > > New height: 64px -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8613) Web console: investigate E2E tests on Node.js 10
[ https://issues.apache.org/jira/browse/IGNITE-8613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519099#comment-16519099 ] Ilya Borisov commented on IGNITE-8613: -- A simple workaround until the issue gets resolved: download Node.js 9.x binary, rename it to node9, add to PATH, run E2E tests with node9. > Web console: investigate E2E tests on Node.js 10 > > > Key: IGNITE-8613 > URL: https://issues.apache.org/jira/browse/IGNITE-8613 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Andrey Novikov >Priority: Minor > > Web console E2E tests fail spontaneously when run under Node.js 10. We should > investigate what causes it: Testcafe incompatibility or something in the web > console code. If new, compatible version of Testcafe becomes available, let's > update to it as a part of this issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8820) Add ability to accept changing txTimeoutOnPartitionMapExchange while waiting for pending transactions.
[ https://issues.apache.org/jira/browse/IGNITE-8820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519056#comment-16519056 ] Alexei Scherbakov commented on IGNITE-8820: --- [~ivandasch], Looks good for me. Please ask a committer to do final review and merge changes. > Add ability to accept changing txTimeoutOnPartitionMapExchange while waiting > for pending transactions. > -- > > Key: IGNITE-8820 > URL: https://issues.apache.org/jira/browse/IGNITE-8820 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Minor > Fix For: 2.6 > > > Currently, if ExchangeFuture waits whith old value of > txTimeoutOnPartitionMapExchange, new value is not accepted until next > exchange starts. Sometimes it's very usefull (while timeout is too long and > must be shorter applied immediatelly) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8818) Web Console: Reduce the height of head of all tables and change the location of the content
[ https://issues.apache.org/jira/browse/IGNITE-8818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov reassigned IGNITE-8818: Assignee: Ilya Borisov (was: Alexey Kuznetsov) > Web Console: Reduce the height of head of all tables and change the location > of the content > --- > > Key: IGNITE-8818 > URL: https://issues.apache.org/jira/browse/IGNITE-8818 > Project: Ignite > Issue Type: Improvement > Components: UI, wizards >Reporter: Vica Abramova >Assignee: Ilya Borisov >Priority: Major > Attachments: Table-header.png > > > New height: 64px -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8840) Random Forest
[ https://issues.apache.org/jira/browse/IGNITE-8840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Platonov reassigned IGNITE-8840: --- Assignee: Alexey Platonov > Random Forest > - > > Key: IGNITE-8840 > URL: https://issues.apache.org/jira/browse/IGNITE-8840 > Project: Ignite > Issue Type: New Feature > Components: ml >Reporter: Yury Babak >Assignee: Alexey Platonov >Priority: Major > Fix For: 2.6 > > > We want to implement random forest algorithm. It should be based on our > implementation of decision trees. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8842) Web console: Wrong start screen on start of demo mode
[ https://issues.apache.org/jira/browse/IGNITE-8842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko updated IGNITE-8842: -- Summary: Web console: Wrong start screen on start of demo mode (was: Web console: Wrong start screed in start of demo mode) > Web console: Wrong start screen on start of demo mode > - > > Key: IGNITE-8842 > URL: https://issues.apache.org/jira/browse/IGNITE-8842 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Vasiliy Sisko >Priority: Minor > > On start of demo mode screen with "SQL demo" notebook should be opened. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8842) Web console: Wrong start screed in start of demo mode
Vasiliy Sisko created IGNITE-8842: - Summary: Web console: Wrong start screed in start of demo mode Key: IGNITE-8842 URL: https://issues.apache.org/jira/browse/IGNITE-8842 Project: Ignite Issue Type: Bug Components: wizards Reporter: Vasiliy Sisko Assignee: Vasiliy Sisko On start of demo mode screen with "SQL demo" notebook should be opened. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8817) Web Console: Remove red links everywhere and do all links blue
[ https://issues.apache.org/jira/browse/IGNITE-8817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov reassigned IGNITE-8817: Assignee: Vica Abramova (was: Ilya Borisov) [~vabramova] please review the changes, did I miss anything? > Web Console: Remove red links everywhere and do all links blue > -- > > Key: IGNITE-8817 > URL: https://issues.apache.org/jira/browse/IGNITE-8817 > Project: Ignite > Issue Type: Improvement > Components: UI, wizards >Reporter: Vica Abramova >Assignee: Vica Abramova >Priority: Major > Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png, > screenshot-4.png > > > * Do this on Admin Panel screen (period control and Email column) > * Do this in all modal windows, where we have the links. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
