[jira] [Assigned] (IGNITE-3917) Web console: Demo project for web console demo not working out of the box.
[ https://issues.apache.org/jira/browse/IGNITE-3917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-3917: Assignee: Vasiliy Sisko (was: Alexey Kuznetsov) [~vsisko], Could you investigate and fix this issue. Or close if it is not reproduced any more. > Web console: Demo project for web console demo not working out of the box. > -- > > Key: IGNITE-3917 > URL: https://issues.apache.org/jira/browse/IGNITE-3917 > Project: Ignite > Issue Type: Bug > Components: wizards >Affects Versions: 1.8 >Reporter: Vasiliy Sisko >Assignee: Vasiliy Sisko >Priority: Major > Labels: web-console-demo > > # Generate default url: jdbc:h2:mem:example;DB_CLOSE_DELAY=-1 > # Not work with aliases. > # Demo should print '>> Demo started' and '>> Demo finished' and H2 server > and Ignite should be stopped. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10324) Disallow fallback to Scanner in control.sh when asking password
[ https://issues.apache.org/jira/browse/IGNITE-10324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16724758#comment-16724758 ] Sergey Chugunov commented on IGNITE-10324: -- [~a-polyakov], [~voropava], Pavel, I think your comment is valid: we should thrown an exception in else branch. I left a comment in the PR as well with my arguments about why we should do this. Could you guys take a look? > Disallow fallback to Scanner in control.sh when asking password > --- > > Key: IGNITE-10324 > URL: https://issues.apache.org/jira/browse/IGNITE-10324 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Voronkin >Assignee: Alexand Polyakov >Priority: Major > > After implementing IGNITE-9990 we still can fallback to Scanner in case of > Console is not allowed, user can easily fallback to non-secure mode by using > some java agent. We should not allow this, cause otherwise all efforts in > IGNITE-9990 are useless. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-5115) Investigation of failing tests of coordinator node failure
[
https://issues.apache.org/jira/browse/IGNITE-5115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16724730#comment-16724730
]
Anton Kalashnikov commented on IGNITE-5115:
---
[~NSAmelchev] thanks, looks good. [~agoncharuk] could you help with merge,
please.
> Investigation of failing tests of coordinator node failure
> ---
>
> Key: IGNITE-5115
> URL: https://issues.apache.org/jira/browse/IGNITE-5115
> Project: Ignite
> Issue Type: Bug
> Components: messaging
>Reporter: Sergey Chugunov
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> Tests *customEventCoordinatorFailure1/2* from *TcpDiscoverySelfTest* are
> flaky on TC and sometimes hang with the following assertion in logs:
> {code}
> Exception in thread "tcp-disco-msg-worker-#5245%tcp.TcpDiscoverySelfTest0%"
> java.lang.AssertionError
> at
> org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing.removeNode(TcpDiscoveryNodesRing.java:353)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeFailedMessage(ServerImpl.java:4670)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2567)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2366)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6485)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2456)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {code}
> It seems that this happens because tests' implementation drops connections of
> *TcpCommunicatonSpi* on coordinator node with *simulateNodeFailure* method.
> At the same time tests leave *TcpDiscoverySpi* operational; it receives
> subsequent NodeFailed message and throws the assertion error shown above.
> The whole situation looks legitimate as it is possible to imagine a situation
> when CommSPI connections on coordinator fail for some reason while DiscoSPI
> connections are healthy.
> It is needed to investigate the situation deeper, figure out whether the root
> cause is using of *simulateNodeFailure* or not and propose a solution if the
> error may happen in the real life.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8131) ZookeeperDiscoverySpiTest#testClientReconnectSessionExpire* tests fail on TC
[
https://issues.apache.org/jira/browse/IGNITE-8131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16724728#comment-16724728
]
Stanilovsky Evgeny commented on IGNITE-8131:
guys, but why lines :
fail("https://issues.apache.org/jira/browse/IGNITE-8131;); still present and
ticket in Resolved state ?
> ZookeeperDiscoverySpiTest#testClientReconnectSessionExpire* tests fail on TC
>
>
> Key: IGNITE-8131
> URL: https://issues.apache.org/jira/browse/IGNITE-8131
> Project: Ignite
> Issue Type: Bug
> Components: zookeeper
>Reporter: Sergey Chugunov
>Assignee: Denis Garus
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
> Attachments: ZK_client_reconnect_failure.log,
> ZK_client_reconnect_success.log
>
>
> Two tests always fail on TC with the assertion
> {noformat}
> junit.framework.AssertionFailedError: Failed to wait for disconnect/reconnect
> event.
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.waitReconnectEvent(ZookeeperDiscoverySpiTest.java:4221)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.reconnectClientNodes(ZookeeperDiscoverySpiTest.java:4183)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.clientReconnectSessionExpire(ZookeeperDiscoverySpiTest.java:2231)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testClientReconnectSessionExpire1_1(ZookeeperDiscoverySpiTest.java:2206)
> {noformat}
> from client disconnect/reconnect events check. Obviously client doesn't
> generate these events as it supposed to do.
> (TC runs can be found
> [here|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgniteZooKeeperDiscovery_IgniteTests24Java8=pull%2F3730%2Fhead=buildTypeStatusDiv]).
> It is possible to reproduce test failure locally as well, but with low
> probability: one failure for 50 or even 300 successful executions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10736) Update tabs rendering in page-queries
[ https://issues.apache.org/jira/browse/IGNITE-10736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kalinin updated IGNITE-10736: --- Summary: Update tabs rendering in page-queries (was: Update tabs in) > Update tabs rendering in page-queries > - > > Key: IGNITE-10736 > URL: https://issues.apache.org/jira/browse/IGNITE-10736 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Alexander Kalinin >Assignee: Alexander Kalinin >Priority: Major > > Now tabs in page-queries home is hardcoded in template, but one should be set > dinamically in controller and iterated in template. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10736) Update tabs in
Alexander Kalinin created IGNITE-10736: -- Summary: Update tabs in Key: IGNITE-10736 URL: https://issues.apache.org/jira/browse/IGNITE-10736 Project: Ignite Issue Type: Improvement Components: wizards Reporter: Alexander Kalinin Assignee: Alexander Kalinin Now tabs in page-queries home is hardcoded in template, but one should be set dinamically in controller and iterated in template. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10735) Web console: use rxjs EMPTY instead of empty
Ilya Borisov created IGNITE-10735: - Summary: Web console: use rxjs EMPTY instead of empty Key: IGNITE-10735 URL: https://issues.apache.org/jira/browse/IGNITE-10735 Project: Ignite Issue Type: Improvement Components: wizards Reporter: Ilya Borisov Assignee: Ilya Borisov RxJS 6 [has deprecated|https://rxjs-dev.firebaseapp.com/api/index/function/empty] empty, EMPTY constant should be used instead, so let's do that. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9839) Web Console: update to RxJS 6
[ https://issues.apache.org/jira/browse/IGNITE-9839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-9839: Resolution: Fixed Assignee: Pavel Konstantinov (was: Alexey Kuznetsov) Looks good to me. Merged to master. > Web Console: update to RxJS 6 > - > > Key: IGNITE-9839 > URL: https://issues.apache.org/jira/browse/IGNITE-9839 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Pavel Konstantinov >Priority: Major > Fix For: 2.8 > > Time Spent: 6h 47m > Remaining Estimate: 0h > > Since RxJS 6 is required by latest version of Angular, we won't be able to > proceed with UI framework migration without it. To do: update import paths, > convert to pipe API. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9839) Web Console: update to RxJS 6
[ https://issues.apache.org/jira/browse/IGNITE-9839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-9839: Assignee: Alexey Kuznetsov (was: Pavel Konstantinov) > Web Console: update to RxJS 6 > - > > Key: IGNITE-9839 > URL: https://issues.apache.org/jira/browse/IGNITE-9839 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.8 > > Time Spent: 6h 47m > Remaining Estimate: 0h > > Since RxJS 6 is required by latest version of Angular, we won't be able to > proceed with UI framework migration without it. To do: update import paths, > convert to pipe API. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10734) Add documentation for the list of operations that should be retried in case of cluster topology changes
[ https://issues.apache.org/jira/browse/IGNITE-10734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev updated IGNITE-10734: --- Component/s: documentation > Add documentation for the list of operations that should be retried in case > of cluster topology changes > --- > > Key: IGNITE-10734 > URL: https://issues.apache.org/jira/browse/IGNITE-10734 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Evgenii Zhuravlev >Assignee: Artem Budnikov >Priority: Major > > Some of the operations, like get or getAll would throw > ClusterTopologyException if primary node left topology, while other > operations not. So, some operations should be re-tried from user code, while > some operation will do it internally. We should prepare documentation for the > list of these operations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10734) Add documentation for the list of operations that should be retried in case of cluster topology changes
Evgenii Zhuravlev created IGNITE-10734: -- Summary: Add documentation for the list of operations that should be retried in case of cluster topology changes Key: IGNITE-10734 URL: https://issues.apache.org/jira/browse/IGNITE-10734 Project: Ignite Issue Type: Improvement Reporter: Evgenii Zhuravlev Assignee: Artem Budnikov Some of the operations, like get or getAll would throw ClusterTopologyException if primary node left topology, while other operations not. So, some operations should be re-tried from user code, while some operation will do it internally. We should prepare documentation for the list of these operations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-5115) Investigation of failing tests of coordinator node failure
[
https://issues.apache.org/jira/browse/IGNITE-5115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16724491#comment-16724491
]
Amelchev Nikita commented on IGNITE-5115:
-
[~akalashnikov], I have added one more node to the test and added checks for
the failed event and new discovery ring size. TC tests look good. Please, take
a look one more time.
> Investigation of failing tests of coordinator node failure
> ---
>
> Key: IGNITE-5115
> URL: https://issues.apache.org/jira/browse/IGNITE-5115
> Project: Ignite
> Issue Type: Bug
> Components: messaging
>Reporter: Sergey Chugunov
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> Tests *customEventCoordinatorFailure1/2* from *TcpDiscoverySelfTest* are
> flaky on TC and sometimes hang with the following assertion in logs:
> {code}
> Exception in thread "tcp-disco-msg-worker-#5245%tcp.TcpDiscoverySelfTest0%"
> java.lang.AssertionError
> at
> org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing.removeNode(TcpDiscoveryNodesRing.java:353)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeFailedMessage(ServerImpl.java:4670)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2567)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2366)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6485)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2456)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {code}
> It seems that this happens because tests' implementation drops connections of
> *TcpCommunicatonSpi* on coordinator node with *simulateNodeFailure* method.
> At the same time tests leave *TcpDiscoverySpi* operational; it receives
> subsequent NodeFailed message and throws the assertion error shown above.
> The whole situation looks legitimate as it is possible to imagine a situation
> when CommSPI connections on coordinator fail for some reason while DiscoSPI
> connections are healthy.
> It is needed to investigate the situation deeper, figure out whether the root
> cause is using of *simulateNodeFailure* or not and propose a solution if the
> error may happen in the real life.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-5115) Investigation of failing tests of coordinator node failure
[
https://issues.apache.org/jira/browse/IGNITE-5115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16724489#comment-16724489
]
Ignite TC Bot commented on IGNITE-5115:
---
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2574612buildTypeId=IgniteTests24Java8_RunAll]
> Investigation of failing tests of coordinator node failure
> ---
>
> Key: IGNITE-5115
> URL: https://issues.apache.org/jira/browse/IGNITE-5115
> Project: Ignite
> Issue Type: Bug
> Components: messaging
>Reporter: Sergey Chugunov
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> Tests *customEventCoordinatorFailure1/2* from *TcpDiscoverySelfTest* are
> flaky on TC and sometimes hang with the following assertion in logs:
> {code}
> Exception in thread "tcp-disco-msg-worker-#5245%tcp.TcpDiscoverySelfTest0%"
> java.lang.AssertionError
> at
> org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing.removeNode(TcpDiscoveryNodesRing.java:353)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeFailedMessage(ServerImpl.java:4670)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2567)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2366)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6485)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2456)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {code}
> It seems that this happens because tests' implementation drops connections of
> *TcpCommunicatonSpi* on coordinator node with *simulateNodeFailure* method.
> At the same time tests leave *TcpDiscoverySpi* operational; it receives
> subsequent NodeFailed message and throws the assertion error shown above.
> The whole situation looks legitimate as it is possible to imagine a situation
> when CommSPI connections on coordinator fail for some reason while DiscoSPI
> connections are healthy.
> It is needed to investigate the situation deeper, figure out whether the root
> cause is using of *simulateNodeFailure* or not and propose a solution if the
> error may happen in the real life.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10733) CassandraStore in write behind mode loses data when back-pressure is active
[ https://issues.apache.org/jira/browse/IGNITE-10733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Konstantinov updated IGNITE-10733: - Ignite Flags: (was: Docs Required) > CassandraStore in write behind mode loses data when back-pressure is active > --- > > Key: IGNITE-10733 > URL: https://issues.apache.org/jira/browse/IGNITE-10733 > Project: Ignite > Issue Type: Bug > Components: cache, cassandra >Affects Versions: 2.5, 2.6, 2.7 >Reporter: Dmitry Konstantinov >Priority: Critical > > When WriteBehindStore writes data synchronously to an underline store using > back-pressure logic (storeSingleValue) - the operation is happened in a > transaction. CassandraStore uses presence of transaction to clarify is it a > atomicity needed: if there is a transaction - CassandraStore accumulates data > in a session-local attribute. When transaction is committed WriteBehindStore > is notified about the related session end but CassandraStore is not notified > (and not subscribed using a session listener), as a result CassandraStore > does not flush the accumulated values in this cases and they are lost. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10733) CassandraStore in write behind mode loses data when back-pressure is active
[ https://issues.apache.org/jira/browse/IGNITE-10733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Konstantinov updated IGNITE-10733: - Description: When WriteBehindStore writes data synchronously to an underline store using back-pressure logic (storeSingleValue) - the operation is happened in a transaction. CassandraStore uses presence of transaction to clarify is a atomicity needed: if there is a transaction - CassandraStore accumulates data in a session-local attribute to flush at the end of the transaction using Cassandra batches. When transaction is committed WriteBehindStore is notified about the related session end but underline CassandraStore is not notified (and not subscribed using a session listener), as a result CassandraStore does not flush the accumulated values written via storeSingleValue and they are lost. (was: When WriteBehindStore writes data synchronously to an underline store using back-pressure logic (storeSingleValue) - the operation is happened in a transaction. CassandraStore uses presence of transaction to clarify is it a atomicity needed: if there is a transaction - CassandraStore accumulates data in a session-local attribute. When transaction is committed WriteBehindStore is notified about the related session end but CassandraStore is not notified (and not subscribed using a session listener), as a result CassandraStore does not flush the accumulated values in this cases and they are lost.) > CassandraStore in write behind mode loses data when back-pressure is active > --- > > Key: IGNITE-10733 > URL: https://issues.apache.org/jira/browse/IGNITE-10733 > Project: Ignite > Issue Type: Bug > Components: cache, cassandra >Affects Versions: 2.5, 2.6, 2.7 >Reporter: Dmitry Konstantinov >Priority: Critical > > When WriteBehindStore writes data synchronously to an underline store using > back-pressure logic (storeSingleValue) - the operation is happened in a > transaction. CassandraStore uses presence of transaction to clarify is a > atomicity needed: if there is a transaction - CassandraStore accumulates data > in a session-local attribute to flush at the end of the transaction using > Cassandra batches. When transaction is committed WriteBehindStore is notified > about the related session end but underline CassandraStore is not notified > (and not subscribed using a session listener), as a result CassandraStore > does not flush the accumulated values written via storeSingleValue and they > are lost. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10733) CassandraStore in write behind mode loses data when back-pressure is active
[ https://issues.apache.org/jira/browse/IGNITE-10733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Konstantinov updated IGNITE-10733: - Description: When GridCacheWriteBehindStore writes data synchronously to an underline store using back-pressure logic (flushSingleValue) - the operation is happened in a transaction. CassandraCacheStore uses presence of transaction to clarify is a atomicity needed: if there is a transaction - CassandraCacheStore accumulates data in a session-local attribute to flush at the end of the transaction using Cassandra batches. When transaction is committed GridCacheWriteBehindStore is notified about the related session end but underline CassandraCacheStore is not notified (and not subscribed using a session listener), as a result CassandraStore does not flush the accumulated values written via flushSingleValue and they are lost. (was: When WriteBehindStore writes data synchronously to an underline store using back-pressure logic (storeSingleValue) - the operation is happened in a transaction. CassandraStore uses presence of transaction to clarify is a atomicity needed: if there is a transaction - CassandraStore accumulates data in a session-local attribute to flush at the end of the transaction using Cassandra batches. When transaction is committed WriteBehindStore is notified about the related session end but underline CassandraStore is not notified (and not subscribed using a session listener), as a result CassandraStore does not flush the accumulated values written via storeSingleValue and they are lost.) > CassandraStore in write behind mode loses data when back-pressure is active > --- > > Key: IGNITE-10733 > URL: https://issues.apache.org/jira/browse/IGNITE-10733 > Project: Ignite > Issue Type: Bug > Components: cache, cassandra >Affects Versions: 2.5, 2.6, 2.7 >Reporter: Dmitry Konstantinov >Priority: Critical > > When GridCacheWriteBehindStore writes data synchronously to an underline > store using back-pressure logic (flushSingleValue) - the operation is > happened in a transaction. CassandraCacheStore uses presence of transaction > to clarify is a atomicity needed: if there is a transaction - > CassandraCacheStore accumulates data in a session-local attribute to flush at > the end of the transaction using Cassandra batches. When transaction is > committed GridCacheWriteBehindStore is notified about the related session end > but underline CassandraCacheStore is not notified (and not subscribed using a > session listener), as a result CassandraStore does not flush the accumulated > values written via flushSingleValue and they are lost. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10733) CassandraStore in write behind mode loses data when back-pressure is active
[ https://issues.apache.org/jira/browse/IGNITE-10733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Konstantinov updated IGNITE-10733: - Description: When WriteBehindStore writes data synchronously to an underline store using back-pressure logic (storeSingleValue) - the operation is happened in a transaction. CassandraStore uses presence of transaction to clarify is it a atomicity needed: if there is a transaction - CassandraStore accumulates data in a session-local attribute. When transaction is committed WriteBehindStore is notified about the related session end but CassandraStore is not notified (and not subscribed using a session listener), as a result CassandraStore does not flush the accumulated values in this cases and they are lost. (was: Whe) > CassandraStore in write behind mode loses data when back-pressure is active > --- > > Key: IGNITE-10733 > URL: https://issues.apache.org/jira/browse/IGNITE-10733 > Project: Ignite > Issue Type: Bug > Components: cache, cassandra >Affects Versions: 2.5, 2.6, 2.7 >Reporter: Dmitry Konstantinov >Priority: Critical > > When WriteBehindStore writes data synchronously to an underline store using > back-pressure logic (storeSingleValue) - the operation is happened in a > transaction. CassandraStore uses presence of transaction to clarify is it a > atomicity needed: if there is a transaction - CassandraStore accumulates data > in a session-local attribute. When transaction is committed WriteBehindStore > is notified about the related session end but CassandraStore is not notified > (and not subscribed using a session listener), as a result CassandraStore > does not flush the accumulated values in this cases and they are lost. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10733) CassandraStore in write behind mode loses data when back-pressure is active
Dmitry Konstantinov created IGNITE-10733: Summary: CassandraStore in write behind mode loses data when back-pressure is active Key: IGNITE-10733 URL: https://issues.apache.org/jira/browse/IGNITE-10733 Project: Ignite Issue Type: Bug Components: cache, cassandra Affects Versions: 2.7, 2.6, 2.5 Reporter: Dmitry Konstantinov Whe -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10719) [ML] LearningEnvironmentBuilder is not passed in makeBagged
[ https://issues.apache.org/jira/browse/IGNITE-10719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Babak updated IGNITE-10719: Ignite Flags: (was: Docs Required) > [ML] LearningEnvironmentBuilder is not passed in makeBagged > --- > > Key: IGNITE-10719 > URL: https://issues.apache.org/jira/browse/IGNITE-10719 > Project: Ignite > Issue Type: Bug > Components: ml >Reporter: Artem Malykh >Assignee: Artem Malykh >Priority: Major > Fix For: 2.8 > > > During TrainerTrainsformers#makeBagged learning environment builder is not > passed from trainer which is made bagged -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10719) [ML] LearningEnvironmentBuilder is not passed in makeBagged
[ https://issues.apache.org/jira/browse/IGNITE-10719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16724381#comment-16724381 ] ASF GitHub Bot commented on IGNITE-10719: - Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/5684 > [ML] LearningEnvironmentBuilder is not passed in makeBagged > --- > > Key: IGNITE-10719 > URL: https://issues.apache.org/jira/browse/IGNITE-10719 > Project: Ignite > Issue Type: Bug > Components: ml >Reporter: Artem Malykh >Assignee: Artem Malykh >Priority: Major > Fix For: 2.8 > > > During TrainerTrainsformers#makeBagged learning environment builder is not > passed from trainer which is made bagged -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10719) [ML] LearningEnvironmentBuilder is not passed in makeBagged
[ https://issues.apache.org/jira/browse/IGNITE-10719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16724380#comment-16724380 ] Yury Babak commented on IGNITE-10719: - reviewed and merged > [ML] LearningEnvironmentBuilder is not passed in makeBagged > --- > > Key: IGNITE-10719 > URL: https://issues.apache.org/jira/browse/IGNITE-10719 > Project: Ignite > Issue Type: Bug > Components: ml >Reporter: Artem Malykh >Assignee: Artem Malykh >Priority: Major > Fix For: 2.8 > > > During TrainerTrainsformers#makeBagged learning environment builder is not > passed from trainer which is made bagged -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10371) [ML] Add multiple metrics calculation for Binary Classification Evaluation process
[ https://issues.apache.org/jira/browse/IGNITE-10371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16724378#comment-16724378 ] ASF GitHub Bot commented on IGNITE-10371: - Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/5612 > [ML] Add multiple metrics calculation for Binary Classification Evaluation > process > -- > > Key: IGNITE-10371 > URL: https://issues.apache.org/jira/browse/IGNITE-10371 > Project: Ignite > Issue Type: New Feature > Components: ml >Affects Versions: 2.8 >Reporter: Aleksey Zinoviev >Assignee: Aleksey Zinoviev >Priority: Critical > Fix For: 2.8 > > > Add ability to get map of metrics to evaluate binary classification. > Try to implement: All implemented metrics should be calculated for one > iteration cycle along the data > Naive implementation: compose all passed metrics and calculate them separatly -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10371) [ML] Add multiple metrics calculation for Binary Classification Evaluation process
[ https://issues.apache.org/jira/browse/IGNITE-10371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Babak updated IGNITE-10371: Summary: [ML] Add multiple metrics calculation for Binary Classification Evaluation process (was: [ML] Add multiple metrics calculation fo Binary Classification Evaluation process) > [ML] Add multiple metrics calculation for Binary Classification Evaluation > process > -- > > Key: IGNITE-10371 > URL: https://issues.apache.org/jira/browse/IGNITE-10371 > Project: Ignite > Issue Type: New Feature > Components: ml >Affects Versions: 2.8 >Reporter: Aleksey Zinoviev >Assignee: Aleksey Zinoviev >Priority: Critical > Fix For: 2.8 > > > Add ability to get map of metrics to evaluate binary classification. > Try to implement: All implemented metrics should be calculated for one > iteration cycle along the data > Naive implementation: compose all passed metrics and calculate them separatly -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10645) SQL properties ownership flag should be set at configuration parsing, not query execution.
[
https://issues.apache.org/jira/browse/IGNITE-10645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16724346#comment-16724346
]
Ignite TC Bot commented on IGNITE-10645:
{panel:title=- Run :: SQL: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform C++ (Linux){color} [[tests 479 JVM CRASH , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2584805]]
* IgniteOdbcTest: SslQueriesTestSuite: TestConnectionSslSuccess - 3,3% fails in
last 887 master runs.
* IgniteOdbcTest: SqlNumericFunctionTestSuite: TestNumericFunctionFloor - 1,2%
fails in last 887 master runs.
* IgniteOdbcTest: TransactionTestSuite: TransactionVersionMismatchError - 1,2%
fails in last 887 master runs.
* IgniteOdbcTest: SqlNumericFunctionTestSuite: TestNumericFunctionLog - 1,2%
fails in last 887 master runs.
* IgniteOdbcTest: SqlDateTimeFunctionTestSuite: TestCurrentDate - 1,2% fails in
last 887 master runs.
* IgniteCoreTest: CacheQueryTestSuite: TestFieldsQueryByteArrayInsertSelect -
1,2% fails in last 887 master runs.
* IgniteCoreTest: ContinuousQueryTestSuite: TestBasic - 1,2% fails in last 887
master runs.
* IgniteCoreTest: ContinuousQueryTestSuite: TestInitialQueryScan - 1,2% fails
in last 887 master runs.
* IgniteOdbcTest: ApiRobustnessTestSuite: TestSQLGetStmtAttr - 1,2% fails in
last 887 master runs.
* IgniteOdbcTest: StreamingTestSuite: TestStreamingManyObjects - 1,2% fails in
last 887 master runs.
* IgniteCoreTest: ContinuousQueryTestSuite: TestInitialQuerySql - 1,2% fails in
last 887 master runs.
* IgniteThinClientTest: AuthTestSuite: AuthSuccess - 1,2% fails in last 887
master runs.
* IgniteCoreTest: ContinuousQueryTestSuite: TestInitialQueryText - 1,2% fails
in last 887 master runs.
* IgniteThinClientTest: CacheClientTestSuite: CacheClientGetCacheExisting -
1,2% fails in last 887 master runs.
* IgniteOdbcTest: ApiRobustnessTestSuite: TestSQLSetStmtAttr - 1,2% fails in
last 887 master runs.
* IgniteOdbcTest: ApiRobustnessTestSuite: TestSQLPrimaryKeys - 1,2% fails in
last 887 master runs.
* IgniteOdbcTest: ApiRobustnessTestSuite: TestSQLNumParams - 1,2% fails in last
887 master runs.
* IgniteCoreTest: ContinuousQueryTestSuite: TestBasicNoExcept - 1,2% fails in
last 887 master runs.
* IgniteOdbcTest: ApiRobustnessTestSuite: TestSQLGetDiagField - 1,2% fails in
last 887 master runs.
* IgniteOdbcTest: SqlNumericFunctionTestSuite: TestNumericFunctionLog10 - 1,2%
fails in last 887 master runs.
* IgniteOdbcTest: ApiRobustnessTestSuite: TestSQLGetDiagRec - 1,2% fails in
last 887 master runs.
* IgniteOdbcTest: ApiRobustnessTestSuite: TestSQLGetData - 1,2% fails in last
887 master runs.
* IgniteOdbcTest: ApiRobustnessTestSuite: TestSQLGetEnvAttr - 1,2% fails in
last 887 master runs.
* IgniteOdbcTest: SqlNumericFunctionTestSuite: TestNumericFunctionMod - 1,2%
fails in last 887 master runs.
* IgniteCoreTest: ContinuousQueryTestSuite: TestInitialQueryScanNoExcept - 1,2%
fails in last 887 master runs.
* IgniteOdbcTest: ApiRobustnessTestSuite: TestSQLSpecialColumns - 1,2% fails in
last 887 master runs.
* IgniteOdbcTest: SqlNumericFunctionTestSuite: TestNumericFunctionPi - 1,2%
fails in last 887 master runs.
* IgniteCoreTest: ContinuousQueryTestSuite: TestInitialQuerySqlNoExcept - 1,2%
fails in last 887 master runs.
* IgniteOdbcTest: ApiRobustnessTestSuite: TestFetchScrollLast - 1,2% fails in
last 887 master runs.
* IgniteOdbcTest: SqlNumericFunctionTestSuite: TestNumericFunctionPower - 1,2%
fails in last 887 master runs.
* IgniteOdbcTest: ApiRobustnessTestSuite: TestFetchScrollPrior - 1,2% fails in
last 887 master runs.
* IgniteOdbcTest: SqlNumericFunctionTestSuite: TestNumericFunctionRadians -
1,2% fails in last 887 master runs.
* IgniteOdbcTest: ApiRobustnessTestSuite: TestFetchScrollFirst - 1,2% fails in
last 887 master runs.
* IgniteOdbcTest: SqlNumericFunctionTestSuite: TestNumericFunctionRand - 1,2%
fails in last 887 master runs.
* IgniteOdbcTest: SqlNumericFunctionTestSuite: TestNumericFunctionRound - 1,2%
fails in last 887 master runs.
* IgniteOdbcTest: SqlNumericFunctionTestSuite: TestNumericFunctionSign - 1,2%
fails in last 887 master runs.
* IgniteOdbcTest: SqlNumericFunctionTestSuite: TestNumericFunctionSin - 1,2%
fails in last 887 master runs.
* IgniteOdbcTest: SqlNumericFunctionTestSuite: TestNumericFunctionSqrt - 1,2%
fails in last 887 master runs.
* IgniteOdbcTest: SqlNumericFunctionTestSuite: TestNumericFunctionTan - 1,2%
fails in last 887 master runs.
* IgniteOdbcTest: SqlNumericFunctionTestSuite: TestNumericFunctionTruncate -
1,2% fails in last 887 master runs.
* IgniteThinClientTest: CacheClientTestSuite: CacheClientGetCacheNonxisting -
1,2% fails in last 887 master runs.
* IgniteOdbcTest: SqlSystemFunctionTestSuite: TestSystemFunctionDatabase - 1,2%
fails in last 887 master runs.
* IgniteThinClientTest: CacheClientTestSuite:
[jira] [Commented] (IGNITE-10264) MVCC: Enlist request failure on backup can cause grid hanging.
[
https://issues.apache.org/jira/browse/IGNITE-10264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16724267#comment-16724267
]
Roman Kondakov commented on IGNITE-10264:
-
[~gvvinblade], please review and merge to master. The problem was solved in
IGNITE-9828. So, the fix is trivial: test was unmuted.
> MVCC: Enlist request failure on backup can cause grid hanging.
> --
>
> Key: IGNITE-10264
> URL: https://issues.apache.org/jira/browse/IGNITE-10264
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Andrew Mashenkov
>Assignee: Roman Kondakov
>Priority: Critical
> Labels: Hanging
>
> See stacktrace below, runtime ClusterTopologyException has not been catched
> and causes transaction hanging.
> Seems, we should throws some meaningful checked exception and thow it onto
> primary node.
> Reproducer is IgniteCacheIncrementTxTest running in Mvcc mode.
>
> {noformat}
> [2018-11-14
> 22:26:37,099][ERROR][sys-stripe-3-#10280%cache.IgniteCacheIncrementTxTest7%][GridCacheIoManager]
> Failed to process message [senderId=3774798b-3cbc-4ae1-95d1-745dd371,
> messageType=class
> o.a.i.i.processors.cache.distributed.dht.GridDhtTxQueryFirstEnlistRequest]
> class org.apache.ignite.cluster.ClusterTopologyException: Can not reserve
> partition. Please retry on stable topology.
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.mvccEnlistBatch(IgniteTxHandler.java:1865)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processDhtTxQueryEnlistRequest(GridDhtTransactionalCacheAdapter.java:2301)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.access$1100(GridDhtTransactionalCacheAdapter.java:112)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$17.apply(GridDhtTransactionalCacheAdapter.java:250)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$17.apply(GridDhtTransactionalCacheAdapter.java:248)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1054)
> 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:100)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1$2$1.run(GridCacheIoManager.java:274)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:505)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748){noformat}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9774) CacheMvccTransactionsTest.testPutAllGetAll_ClientServer_Backups1_Restart_Scan hangs
[
https://issues.apache.org/jira/browse/IGNITE-9774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16724263#comment-16724263
]
Roman Kondakov commented on IGNITE-9774:
[~gvvinblade], please review. There is a trivial patch: test was remuted with
the proper ticket.
> CacheMvccTransactionsTest.testPutAllGetAll_ClientServer_Backups1_Restart_Scan
> hangs
> ---
>
> Key: IGNITE-9774
> URL: https://issues.apache.org/jira/browse/IGNITE-9774
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Ivan Pavlukhin
>Assignee: Roman Kondakov
>Priority: Major
> Labels: Hanging
>
> Test
> {{CacheMvccTransactionsTest#testPutAllGetAll_ClientServer_Backups1_Restart_Scan
> hangs}} and can freeze a whole suite. Investigation is needed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10474) MVCC: IgniteCacheConnectionRecovery10ConnectionsTest.testConnectionRecovery fails.
[ https://issues.apache.org/jira/browse/IGNITE-10474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16724262#comment-16724262 ] Roman Kondakov commented on IGNITE-10474: - [~amashenkov], [~gvvinblade] I wasn't able to reproduce this hang locally, so I've unmuted this test. Please, review and merge if needed. > MVCC: IgniteCacheConnectionRecovery10ConnectionsTest.testConnectionRecovery > fails. > -- > > Key: IGNITE-10474 > URL: https://issues.apache.org/jira/browse/IGNITE-10474 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Andrew Mashenkov >Assignee: Roman Kondakov >Priority: Major > Labels: Hanging > > IgniteCacheConnectionRecovery10ConnectionsTest.testConnectionRecovery fails > due to hanging. > We have to investigate and fix this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10474) MVCC: IgniteCacheConnectionRecovery10ConnectionsTest.testConnectionRecovery fails.
[ https://issues.apache.org/jira/browse/IGNITE-10474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16724261#comment-16724261 ] ASF GitHub Bot commented on IGNITE-10474: - GitHub user rkondakov opened a pull request: https://github.com/apache/ignite/pull/5698 IGNITE-10474: Unmuted IgniteCacheConnectionRecovery10ConnectionsTest.estConnectionRecovery. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10474 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5698.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 #5698 commit 65aad379c2310a9972e89131faa4e76d11d93291 Author: rkondakov Date: 2018-12-18T16:53:40Z IGNITE-10474: Unmuted IgniteCacheConnectionRecovery10ConnectionsTest.testConnectionRecovery. > MVCC: IgniteCacheConnectionRecovery10ConnectionsTest.testConnectionRecovery > fails. > -- > > Key: IGNITE-10474 > URL: https://issues.apache.org/jira/browse/IGNITE-10474 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Andrew Mashenkov >Assignee: Roman Kondakov >Priority: Major > Labels: Hanging > > IgniteCacheConnectionRecovery10ConnectionsTest.testConnectionRecovery fails > due to hanging. > We have to investigate and fix this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10474) MVCC: IgniteCacheConnectionRecovery10ConnectionsTest.testConnectionRecovery fails.
[ https://issues.apache.org/jira/browse/IGNITE-10474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Kondakov reassigned IGNITE-10474: --- Assignee: Roman Kondakov > MVCC: IgniteCacheConnectionRecovery10ConnectionsTest.testConnectionRecovery > fails. > -- > > Key: IGNITE-10474 > URL: https://issues.apache.org/jira/browse/IGNITE-10474 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Andrew Mashenkov >Assignee: Roman Kondakov >Priority: Major > Labels: Hanging > > IgniteCacheConnectionRecovery10ConnectionsTest.testConnectionRecovery fails > due to hanging. > We have to investigate and fix this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10732) Incorrect file.encoding leads to inconsistent SqlFieldsQuery results between nodes
[
https://issues.apache.org/jira/browse/IGNITE-10732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev updated IGNITE-10732:
-
Affects Version/s: 2.4
> Incorrect file.encoding leads to inconsistent SqlFieldsQuery results between
> nodes
> --
>
> Key: IGNITE-10732
> URL: https://issues.apache.org/jira/browse/IGNITE-10732
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.4
>Reporter: Ilya Kasnacheev
>Priority: Critical
> Labels: windows
>
> When doing
> {code}
> cache.query(new SqlFieldsQuery("SELECT _key FROM Cache"))
> {code}
> resulting Unicode values may be different when coming from Windows or Linux
> node.
> Linux nodes will mostly use UTF-8 but Windows nodes will use local Cp
> encoding to encode query results, as bizzare as it may sound.
> Windows <-> Windows and Linux <-> Linux will get correct result but Windows
> <-> Linux will get broken strings.
> Note that if cluster has Windows and Linux nodes and cache is REPLICATED,
> results will be different for subsequent queries!
> There is a workaround for this: set -Dfile.encoding=UTF-8 JVM arg on Windows.
> There is probably an underlying problem in H2 but since non-UTF-8
> file.encoding is dangerous (it affects String.getBytes()) I think we should
> peg it to UTF-8.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-10732) Incorrect file.encoding leads to inconsistent SqlFieldsQuery results between nodes
[
https://issues.apache.org/jira/browse/IGNITE-10732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev reassigned IGNITE-10732:
Assignee: (was: Ilya Kasnacheev)
> Incorrect file.encoding leads to inconsistent SqlFieldsQuery results between
> nodes
> --
>
> Key: IGNITE-10732
> URL: https://issues.apache.org/jira/browse/IGNITE-10732
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.4
>Reporter: Ilya Kasnacheev
>Priority: Critical
> Labels: windows
>
> When doing
> {code}
> cache.query(new SqlFieldsQuery("SELECT _key FROM Cache"))
> {code}
> resulting Unicode values may be different when coming from Windows or Linux
> node.
> Linux nodes will mostly use UTF-8 but Windows nodes will use local Cp
> encoding to encode query results, as bizzare as it may sound.
> Windows <-> Windows and Linux <-> Linux will get correct result but Windows
> <-> Linux will get broken strings.
> Note that if cluster has Windows and Linux nodes and cache is REPLICATED,
> results will be different for subsequent queries!
> There is a workaround for this: set -Dfile.encoding=UTF-8 JVM arg on Windows.
> There is probably an underlying problem in H2 but since non-UTF-8
> file.encoding is dangerous (it affects String.getBytes()) I think we should
> peg it to UTF-8.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10732) Incorrect file.encoding leads to inconsistent SqlFieldsQuery results between nodes
[
https://issues.apache.org/jira/browse/IGNITE-10732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev updated IGNITE-10732:
-
Labels: windows (was: )
> Incorrect file.encoding leads to inconsistent SqlFieldsQuery results between
> nodes
> --
>
> Key: IGNITE-10732
> URL: https://issues.apache.org/jira/browse/IGNITE-10732
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.4
>Reporter: Ilya Kasnacheev
>Priority: Critical
> Labels: windows
>
> When doing
> {code}
> cache.query(new SqlFieldsQuery("SELECT _key FROM Cache"))
> {code}
> resulting Unicode values may be different when coming from Windows or Linux
> node.
> Linux nodes will mostly use UTF-8 but Windows nodes will use local Cp
> encoding to encode query results, as bizzare as it may sound.
> Windows <-> Windows and Linux <-> Linux will get correct result but Windows
> <-> Linux will get broken strings.
> Note that if cluster has Windows and Linux nodes and cache is REPLICATED,
> results will be different for subsequent queries!
> There is a workaround for this: set -Dfile.encoding=UTF-8 JVM arg on Windows.
> There is probably an underlying problem in H2 but since non-UTF-8
> file.encoding is dangerous (it affects String.getBytes()) I think we should
> peg it to UTF-8.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10732) Incorrect file.encoding leads to inconsistent SqlFieldsQuery results between nodes
[
https://issues.apache.org/jira/browse/IGNITE-10732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16724237#comment-16724237
]
Ilya Kasnacheev commented on IGNITE-10732:
--
Seems to be broken in 2.4, was pegged to be UTF-8 before.
> Incorrect file.encoding leads to inconsistent SqlFieldsQuery results between
> nodes
> --
>
> Key: IGNITE-10732
> URL: https://issues.apache.org/jira/browse/IGNITE-10732
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Critical
>
> When doing
> {code}
> cache.query(new SqlFieldsQuery("SELECT _key FROM Cache"))
> {code}
> resulting Unicode values may be different when coming from Windows or Linux
> node.
> Linux nodes will mostly use UTF-8 but Windows nodes will use local Cp
> encoding to encode query results, as bizzare as it may sound.
> Windows <-> Windows and Linux <-> Linux will get correct result but Windows
> <-> Linux will get broken strings.
> Note that if cluster has Windows and Linux nodes and cache is REPLICATED,
> results will be different for subsequent queries!
> There is a workaround for this: set -Dfile.encoding=UTF-8 JVM arg on Windows.
> There is probably an underlying problem in H2 but since non-UTF-8
> file.encoding is dangerous (it affects String.getBytes()) I think we should
> peg it to UTF-8.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10709) New inspections introduced in 2018+ IntelliJ IDEA version must be disabled on TC configuration
[
https://issues.apache.org/jira/browse/IGNITE-10709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16724215#comment-16724215
]
ASF GitHub Bot commented on IGNITE-10709:
-
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/5680
> New inspections introduced in 2018+ IntelliJ IDEA version must be disabled on
> TC configuration
> --
>
> Key: IGNITE-10709
> URL: https://issues.apache.org/jira/browse/IGNITE-10709
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: inspections
> Fix For: 2.8
>
>
> IntelliJ IDEA since 2018.1 version has new inspection rules enabled by
> default. This leads to the {{[Inspections] Core}} suite fail as these rules
> are not fixed in the Apache Ignite project code.
> # We need to add and disable them in {{ignite_inspections_teamcity.xml}}
> configuration file.
> # Remove unnecessary suppression according to {{Redundant suppression}} rule
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10508) Need to support the new checkpoint feature not wait for the previous operation to complete
[ https://issues.apache.org/jira/browse/IGNITE-10508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16724206#comment-16724206 ] ASF GitHub Bot commented on IGNITE-10508: - GitHub user dgovorukhin opened a pull request: https://github.com/apache/ignite/pull/5697 IGNITE-10508 Need to support the new checkpoint feature not wait for the previous operation to complete You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10508 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5697.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 #5697 commit 0c59c46a148d06da4000ae5c0a5e6df2d7c752f2 Author: Dmitriy Govorukhin Date: 2018-12-03T23:17:41Z IGNITE-10508 wip Signed-off-by: Dmitriy Govorukhin commit 42d83fbc4f7e57144f91ce7f07c758266d4cd825 Author: Dmitriy Govorukhin Date: 2018-12-04T08:12:49Z IGNITE-10508 wip Signed-off-by: Dmitriy Govorukhin commit 7abe223e4cbafa1c00d82deca6a4186af11e38cc Author: Dmitriy Govorukhin Date: 2018-12-04T09:03:39Z IGNITE-10508 wip Signed-off-by: Dmitriy Govorukhin commit 1b9193fb58ef3da361321c43801fffde31509cf4 Author: Dmitriy Govorukhin Date: 2018-12-04T11:52:49Z IGNITE-10508 wip Signed-off-by: Dmitriy Govorukhin commit 4278834c65a8bb440d55bcdec30a81a31ead120b Author: Dmitriy Govorukhin Date: 2018-12-04T12:08:42Z IGNITE-10508 wip Signed-off-by: Dmitriy Govorukhin commit fc5a46b4c10bdc675527c2da46e3ef333c52226c Author: Dmitriy Govorukhin Date: 2018-12-04T12:40:01Z IGNITE-10508 java doc Signed-off-by: Dmitriy Govorukhin commit 3476b3f1f6fd2b17c8ded0c3922ba6efb7d3c3ee Author: Dmitriy Govorukhin Date: 2018-12-04T14:30:54Z IGNITE-10508 wip Signed-off-by: Dmitriy Govorukhin commit a7beb754d20cdc46383053c08f9d0f1195a6f72f Author: Dmitriy Govorukhin Date: 2018-12-04T14:36:38Z IGNITE-10508 wip Signed-off-by: Dmitriy Govorukhin commit a46fb15833c7be62be8c47bae3d92d5796ec0aea Author: Dmitriy Govorukhin Date: 2018-12-04T15:38:47Z IGNITE-10508 wip Signed-off-by: Dmitriy Govorukhin commit 4f8f05239c62fda9730825f1aa7c2095b6f6e3ee Author: Dmitriy Govorukhin Date: 2018-12-04T22:21:55Z IGNITE-10508 wip Signed-off-by: Dmitriy Govorukhin commit 9a78d95e3203df949ef3db32d42a17432be10cf6 Author: Dmitriy Govorukhin Date: 2018-12-09T18:23:35Z IGNITE-10508 wip Signed-off-by: Dmitriy Govorukhin commit 804d4c90523ed2abf53df152b8b65d83a7167208 Author: Dmitriy Govorukhin Date: 2018-12-09T21:36:10Z IGNITE-10508 wip Signed-off-by: Dmitriy Govorukhin commit 8e9582e71fd82b4d83f6705a8b6ea6be943690d2 Author: Dmitriy Govorukhin Date: 2018-12-09T21:54:42Z IGNITE-10508 wip Signed-off-by: Dmitriy Govorukhin commit 6677e3c8e0f64895d3dc7d7acefad31abe967260 Author: Dmitriy Govorukhin Date: 2018-12-10T08:16:08Z IGNITE-10508 wip Signed-off-by: Dmitriy Govorukhin commit 7c000f04dd8672f7afa236ad14e65cd5858e257c Author: Dmitriy Govorukhin Date: 2018-12-10T08:34:47Z IGNITE-10508 wip Signed-off-by: Dmitriy Govorukhin commit 7290d07f313245800aabb98ce17dda9e1a810de4 Author: Dmitriy Govorukhin Date: 2018-12-10T08:39:57Z IGNITE-10508 wip Signed-off-by: Dmitriy Govorukhin commit b6babe3e813eaea9c91dd5752930d8db07c9d508 Author: Dmitriy Govorukhin Date: 2018-12-10T09:06:30Z IGNITE-10508 wip Signed-off-by: Dmitriy Govorukhin commit a545f744a9141c03f3678cda7ffcee6b7e40763b Author: Dmitriy Govorukhin Date: 2018-12-10T09:18:54Z IGNITE-10508 wip Signed-off-by: Dmitriy Govorukhin commit ace8cdafaee862228738d4d3b1a456f0c673ad7c Author: Dmitriy Govorukhin Date: 2018-12-10T12:55:34Z IGNITE-10508 wip Signed-off-by: Dmitriy Govorukhin commit ae65f5ca2c30c0ca5db0a531ccf8f5eb0ad06f90 Author: Dmitriy Govorukhin Date: 2018-12-10T15:13:29Z IGNITE-10508 wip Signed-off-by: Dmitriy Govorukhin commit 74e91270474d50f3472db75a12ca569fbc0a16a3 Author: Dmitriy Govorukhin Date: 2018-12-10T15:14:08Z IGNITE-10508 wip Signed-off-by: Dmitriy Govorukhin commit 07d565b87af4602d64159b7c21c34dc8c10b7440 Author: Dmitriy Govorukhin Date: 2018-12-10T17:15:59Z IGNITE-10508 wip Signed-off-by: Dmitriy Govorukhin commit 1ef72210b8608c51782464cf13d496edca7e4877 Author: Dmitriy Govorukhin Date: 2018-12-10T17:54:31Z IGNITE-10508 wip Signed-off-by: Dmitriy Govorukhin commit effb37b99e9004ebe17ae067b75c97c5d7633144 Author: Dmitriy Govorukhin Date: 2018-12-11T12:56:40Z IGNITE-10508 merge checkpoint pages
[jira] [Commented] (IGNITE-10421) MVCC: Assertion in checkpointer thread.
[
https://issues.apache.org/jira/browse/IGNITE-10421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16724197#comment-16724197
]
ASF GitHub Bot commented on IGNITE-10421:
-
GitHub user AMashenkov opened a pull request:
https://github.com/apache/ignite/pull/5696
IGNITE-10421: Fix TxLog initialization.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-10421
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/5696.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 #5696
commit 4cdfa606f5a508ba8503d7cea560946163d2cd67
Author: Andrey V. Mashenkov
Date: 2018-12-18T16:02:39Z
IGNITE-10421: Fix TxLog initialization.
> MVCC: Assertion in checkpointer thread.
> ---
>
> Key: IGNITE-10421
> URL: https://issues.apache.org/jira/browse/IGNITE-10421
> Project: Ignite
> Issue Type: Bug
> Components: mvcc, persistence
>Reporter: Roman Kondakov
>Assignee: Andrew Mashenkov
>Priority: Major
>
> Reproducers:
> * {{WalModeChangeAdvancedSelfTest#testJoin}} with enabled MVCC.
> * {{IgniteDynamicCacheStartFailWithPersistenceTest}}
> {noformat}
> [2018-11-27
> 14:56:47,548][ERROR][db-checkpoint-thread-#358%srv_3%][IgniteTestResources]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=SingletonSet [SYSTEM_WORKER_BLOCKED]]],
> failureCtx=FailureContext [type=CRITICAL_ERROR, err=class
> o.a.i.IgniteCheckedException: Compound exception for CountDownFuture.]]
> class org.apache.ignite.IgniteCheckedException: Compound exception for
> CountDownFuture.
> at
> org.apache.ignite.internal.util.future.CountDownFuture.addError(CountDownFuture.java:72)
> at
> org.apache.ignite.internal.util.future.CountDownFuture.onDone(CountDownFuture.java:46)
> at
> org.apache.ignite.internal.util.future.CountDownFuture.onDone(CountDownFuture.java:28)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.run(GridCacheDatabaseSharedManager.java:3957)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Suppressed: java.lang.AssertionError: off=3000,
> allocated=1000, pageId=00020002,
> file=/home/gridgain/Documents/work/incubator-ignite/work/db/node02-20092321-f30d-498f-8609-21ff87e4d104/TxLog/index.bin
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.write(FilePageStore.java:550)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.writeInternal(FilePageStoreManager.java:520)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.writePages(GridCacheDatabaseSharedManager.java:4022)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.run(GridCacheDatabaseSharedManager.java:3930)
> ... 3 more
> Suppressed: java.lang.AssertionError: off=4000,
> allocated=1000, pageId=00020003,
> file=/home/gridgain/Documents/work/incubator-ignite/work/db/node02-20092321-f30d-498f-8609-21ff87e4d104/TxLog/index.bin
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.write(FilePageStore.java:550)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.writeInternal(FilePageStoreManager.java:520)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.writePages(GridCacheDatabaseSharedManager.java:4022)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.run(GridCacheDatabaseSharedManager.java:3930)
> ... 3 more
> Suppressed: java.lang.AssertionError: off=2000,
> allocated=1000, pageId=00020001,
> file=/home/gridgain/Documents/work/incubator-ignite/work/db/node02-20092321-f30d-498f-8609-21ff87e4d104/TxLog/index.bin
> at
>
[jira] [Commented] (IGNITE-4111) Communication fails to send message if target node did not finish join process
[ https://issues.apache.org/jira/browse/IGNITE-4111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16724191#comment-16724191 ] ASF GitHub Bot commented on IGNITE-4111: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/5650 > Communication fails to send message if target node did not finish join process > -- > > Key: IGNITE-4111 > URL: https://issues.apache.org/jira/browse/IGNITE-4111 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Semen Boikov >Assignee: Amelchev Nikita >Priority: Minor > Fix For: 2.8 > > Attachments: test onFirstMessage hang.log > > > Currently this scenario is possible: > - joining node sent join request and waits for > TcpDiscoveryNodeAddFinishedMessage inside ServerImpl.joinTopology > - others nodes already see this node and can send messages to it (for example > try to run compute job on this node) > - joining node can not receive message: TcpCommunicationSpi will hang inside > 'onFirstMessage' on 'getSpiContext' call, so sending node will get error > trying to establish connection > Possible fix: if in onFirstMessage() spi context is not available, then > TcpCommunicationSpi should send special response which indicates that this > node is not ready yet, and sender should retry after some time. > Also need check internal code for places where message can be unnecessarily > sent to node: one such place is > GridCachePartitionExchangeManager.refreshPartitions - message is sent to all > known nodes, but here we can filter by node order / finished exchage version. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10289) [ML] Import models from XGBoost
[ https://issues.apache.org/jira/browse/IGNITE-10289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16724169#comment-16724169 ] ASF GitHub Bot commented on IGNITE-10289: - Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/5533 > [ML] Import models from XGBoost > --- > > Key: IGNITE-10289 > URL: https://issues.apache.org/jira/browse/IGNITE-10289 > Project: Ignite > Issue Type: New Feature > Components: ml >Affects Versions: 2.8 >Reporter: Yury Babak >Assignee: Anton Dmitriev >Priority: Major > Fix For: 2.8 > > > We want to have the ability of import model from 3rd part ml libraries into > Apache Ignite. We could start this process from XGBoost library for trees and > GDB. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-5115) Investigation of failing tests of coordinator node failure
[
https://issues.apache.org/jira/browse/IGNITE-5115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16724140#comment-16724140
]
Amelchev Nikita commented on IGNITE-5115:
-
[~akalashnikov] , thanks for taking a look at changes!
I'll add a one more node to test and I'll notify on done.
> Investigation of failing tests of coordinator node failure
> ---
>
> Key: IGNITE-5115
> URL: https://issues.apache.org/jira/browse/IGNITE-5115
> Project: Ignite
> Issue Type: Bug
> Components: messaging
>Reporter: Sergey Chugunov
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> Tests *customEventCoordinatorFailure1/2* from *TcpDiscoverySelfTest* are
> flaky on TC and sometimes hang with the following assertion in logs:
> {code}
> Exception in thread "tcp-disco-msg-worker-#5245%tcp.TcpDiscoverySelfTest0%"
> java.lang.AssertionError
> at
> org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing.removeNode(TcpDiscoveryNodesRing.java:353)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeFailedMessage(ServerImpl.java:4670)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2567)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2366)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6485)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2456)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {code}
> It seems that this happens because tests' implementation drops connections of
> *TcpCommunicatonSpi* on coordinator node with *simulateNodeFailure* method.
> At the same time tests leave *TcpDiscoverySpi* operational; it receives
> subsequent NodeFailed message and throws the assertion error shown above.
> The whole situation looks legitimate as it is possible to imagine a situation
> when CommSPI connections on coordinator fail for some reason while DiscoSPI
> connections are healthy.
> It is needed to investigate the situation deeper, figure out whether the root
> cause is using of *simulateNodeFailure* or not and propose a solution if the
> error may happen in the real life.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10731) ZookeeperDiscoverySpiTestSuite4: IgniteCacheReplicatedQuerySelfTest.testNodeLeft fails
[
https://issues.apache.org/jira/browse/IGNITE-10731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Biryukov updated IGNITE-10731:
--
Description:
{noformat}
junit.framework.AssertionFailedError:
Expected :0
Actual :312
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.cache.distributed.replicated.IgniteCacheReplicatedQuerySelfTest.testNodeLeft(IgniteCacheReplicatedQuerySelfTest.java:348)
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.access$001(GridAbstractTest.java:151)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.evaluate(GridAbstractTest.java:2102)
at
org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2117)
at java.lang.Thread.run(Thread.java:745)
{noformat}
was:junit.framework.AssertionFailedError: Expected :0 Actual :312 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.cache.distributed.replicated.IgniteCacheReplicatedQuerySelfTest.testNodeLeft(IgniteCacheReplicatedQuerySelfTest.java:348)
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.access$001(GridAbstractTest.java:151)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.evaluate(GridAbstractTest.java:2102)
at
org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2117)
at java.lang.Thread.run(Thread.java:745)
> ZookeeperDiscoverySpiTestSuite4:
> IgniteCacheReplicatedQuerySelfTest.testNodeLeft fails
> --
>
> Key: IGNITE-10731
> URL: https://issues.apache.org/jira/browse/IGNITE-10731
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.7
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> {noformat}
> junit.framework.AssertionFailedError:
> Expected :0
> Actual :312
>
> 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.cache.distributed.replicated.IgniteCacheReplicatedQuerySelfTest.testNodeLeft(IgniteCacheReplicatedQuerySelfTest.java:348)
> 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.access$001(GridAbstractTest.java:151)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.evaluate(GridAbstractTest.java:2102)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2117)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10645) SQL properties ownership flag should be set at configuration parsing, not query execution.
[ https://issues.apache.org/jira/browse/IGNITE-10645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16724144#comment-16724144 ] Pavel Kuznetsov commented on IGNITE-10645: -- Fixed test. Issued visa comment. [~vozerov], could you please take a look at the patch? > SQL properties ownership flag should be set at configuration parsing, not > query execution. > -- > > Key: IGNITE-10645 > URL: https://issues.apache.org/jira/browse/IGNITE-10645 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > > At processing time, query entities are transformed and validated, table > descriptors with properties are created. > Now in some case (thre's no keyFields and key is of complex non-sql type), > ownership flag of query property is calculated at execution time (for example > at first put()): > https://github.com/apache/ignite/blob/dcdb27a24a450f63487290360b265e1570534629/modules/core/src/main/java/org/apache/ignite/internal/processors/query/property/QueryBinaryProperty.java#L132 > So we can't access metadata, that uses this not-yet-initialized field before > we put the data. > But we already have all necessary info to set this field at processing time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10257) Control.sh utility should request a SSL keystore password and SSL truststore password if necessary
[ https://issues.apache.org/jira/browse/IGNITE-10257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16724138#comment-16724138 ] ASF GitHub Bot commented on IGNITE-10257: - Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/5647 > Control.sh utility should request a SSL keystore password and SSL truststore > password if necessary > -- > > Key: IGNITE-10257 > URL: https://issues.apache.org/jira/browse/IGNITE-10257 > Project: Ignite > Issue Type: New Feature >Affects Versions: 2.6 >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Major > Fix For: 2.8 > > > Using passwords (–ssl_key_strore_password and --ssl_trust_store_password) in > command line parametrs is not safe. We must request them if necessary. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10731) ZookeeperDiscoverySpiTestSuite4: IgniteCacheReplicatedQuerySelfTest.testNodeLeft fails
[
https://issues.apache.org/jira/browse/IGNITE-10731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16724136#comment-16724136
]
ASF GitHub Bot commented on IGNITE-10731:
-
GitHub user BiryukovVA opened a pull request:
https://github.com/apache/ignite/pull/5694
IGNITE-10731
IgniteCacheReplicatedQuerySelfTest.testNodeLeft fixed.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/BiryukovVA/ignite IGNITE-10731
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/5694.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 #5694
commit d8c73230e2262aa548adb5cf60a0d1c31692c254
Author: Vitaliy Biryukov
Date: 2018-12-18T14:44:34Z
IGNITE-10731: IgniteCacheReplicatedQuerySelfTest.testNodeLeft fixed.
> ZookeeperDiscoverySpiTestSuite4:
> IgniteCacheReplicatedQuerySelfTest.testNodeLeft fails
> --
>
> Key: IGNITE-10731
> URL: https://issues.apache.org/jira/browse/IGNITE-10731
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.7
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> {noformat}
> junit.framework.AssertionFailedError:
> Expected :0
> Actual :312
>
> 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.cache.distributed.replicated.IgniteCacheReplicatedQuerySelfTest.testNodeLeft(IgniteCacheReplicatedQuerySelfTest.java:348)
> 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.access$001(GridAbstractTest.java:151)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.evaluate(GridAbstractTest.java:2102)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2117)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-10581) Document new flag to filter cache types in control.sh
[ https://issues.apache.org/jira/browse/IGNITE-10581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov reassigned IGNITE-10581: --- Assignee: Artem Budnikov > Document new flag to filter cache types in control.sh > - > > Key: IGNITE-10581 > URL: https://issues.apache.org/jira/browse/IGNITE-10581 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Alexey Goncharuk >Assignee: Artem Budnikov >Priority: Major > Fix For: 2.8 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9902) ScanQuery doesn't take lost partitions into account
[ https://issues.apache.org/jira/browse/IGNITE-9902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16724128#comment-16724128 ] ASF GitHub Bot commented on IGNITE-9902: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/5464 > ScanQuery doesn't take lost partitions into account > --- > > Key: IGNITE-9902 > URL: https://issues.apache.org/jira/browse/IGNITE-9902 > Project: Ignite > Issue Type: Bug >Reporter: Stanislav Lukyanov >Assignee: Alexey Platonov >Priority: Major > Fix For: 2.8 > > Time Spent: 8h > Remaining Estimate: 0h > > Same as IGNITE-9841, but about scan queries. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-9902) ScanQuery doesn't take lost partitions into account
[ https://issues.apache.org/jira/browse/IGNITE-9902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk resolved IGNITE-9902. -- Resolution: Fixed [~aplatonov], since IGNITE-10044 merge is delayed, merging this one. Thanks for the contribution! > ScanQuery doesn't take lost partitions into account > --- > > Key: IGNITE-9902 > URL: https://issues.apache.org/jira/browse/IGNITE-9902 > Project: Ignite > Issue Type: Bug >Reporter: Stanislav Lukyanov >Assignee: Alexey Platonov >Priority: Major > Fix For: 2.8 > > Time Spent: 8h > Remaining Estimate: 0h > > Same as IGNITE-9841, but about scan queries. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10731) ZookeeperDiscoverySpiTestSuite4: IgniteCacheReplicatedQuerySelfTest.testNodeLeft fails
[
https://issues.apache.org/jira/browse/IGNITE-10731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Biryukov updated IGNITE-10731:
--
Environment: (was: {noformat}
junit.framework.AssertionFailedError:
Expected :0
Actual :312
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.cache.distributed.replicated.IgniteCacheReplicatedQuerySelfTest.testNodeLeft(IgniteCacheReplicatedQuerySelfTest.java:348)
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.access$001(GridAbstractTest.java:151)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.evaluate(GridAbstractTest.java:2102)
at
org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2117)
at java.lang.Thread.run(Thread.java:745)
{noformat})
> ZookeeperDiscoverySpiTestSuite4:
> IgniteCacheReplicatedQuerySelfTest.testNodeLeft fails
> --
>
> Key: IGNITE-10731
> URL: https://issues.apache.org/jira/browse/IGNITE-10731
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.7
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> junit.framework.AssertionFailedError: Expected :0 Actual :312 difference> 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.cache.distributed.replicated.IgniteCacheReplicatedQuerySelfTest.testNodeLeft(IgniteCacheReplicatedQuerySelfTest.java:348)
> 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.access$001(GridAbstractTest.java:151)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.evaluate(GridAbstractTest.java:2102)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2117)
> at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10731) ZookeeperDiscoverySpiTestSuite4: IgniteCacheReplicatedQuerySelfTest.testNodeLeft fails
Vitaliy Biryukov created IGNITE-10731:
-
Summary: ZookeeperDiscoverySpiTestSuite4:
IgniteCacheReplicatedQuerySelfTest.testNodeLeft fails
Key: IGNITE-10731
URL: https://issues.apache.org/jira/browse/IGNITE-10731
Project: Ignite
Issue Type: Improvement
Affects Versions: 2.7
Environment: {noformat}
junit.framework.AssertionFailedError:
Expected :0
Actual :312
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.cache.distributed.replicated.IgniteCacheReplicatedQuerySelfTest.testNodeLeft(IgniteCacheReplicatedQuerySelfTest.java:348)
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.access$001(GridAbstractTest.java:151)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.evaluate(GridAbstractTest.java:2102)
at
org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2117)
at java.lang.Thread.run(Thread.java:745)
{noformat}
Reporter: Vitaliy Biryukov
Assignee: Vitaliy Biryukov
Fix For: 2.8
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10731) ZookeeperDiscoverySpiTestSuite4: IgniteCacheReplicatedQuerySelfTest.testNodeLeft fails
[
https://issues.apache.org/jira/browse/IGNITE-10731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Biryukov updated IGNITE-10731:
--
Description: junit.framework.AssertionFailedError: Expected :0 Actual :312
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.cache.distributed.replicated.IgniteCacheReplicatedQuerySelfTest.testNodeLeft(IgniteCacheReplicatedQuerySelfTest.java:348)
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.access$001(GridAbstractTest.java:151)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.evaluate(GridAbstractTest.java:2102)
at
org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2117)
at java.lang.Thread.run(Thread.java:745)
> ZookeeperDiscoverySpiTestSuite4:
> IgniteCacheReplicatedQuerySelfTest.testNodeLeft fails
> --
>
> Key: IGNITE-10731
> URL: https://issues.apache.org/jira/browse/IGNITE-10731
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.7
> Environment: {noformat}
> junit.framework.AssertionFailedError:
> Expected :0
> Actual :312
>
> 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.cache.distributed.replicated.IgniteCacheReplicatedQuerySelfTest.testNodeLeft(IgniteCacheReplicatedQuerySelfTest.java:348)
> 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.access$001(GridAbstractTest.java:151)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.evaluate(GridAbstractTest.java:2102)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2117)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> junit.framework.AssertionFailedError: Expected :0 Actual :312 difference> 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.cache.distributed.replicated.IgniteCacheReplicatedQuerySelfTest.testNodeLeft(IgniteCacheReplicatedQuerySelfTest.java:348)
> 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.access$001(GridAbstractTest.java:151)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.evaluate(GridAbstractTest.java:2102)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2117)
> at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10730) MVCC TX: Batch WAL datarecords
Igor Seliverstov created IGNITE-10730: - Summary: MVCC TX: Batch WAL datarecords Key: IGNITE-10730 URL: https://issues.apache.org/jira/browse/IGNITE-10730 Project: Ignite Issue Type: Improvement Components: mvcc Reporter: Igor Seliverstov on MVCC updates we make changes one by one and WAL records are written straight after successful update under the same checkpoint lock. This produces contention on wal flush operations and harm overall performance. But we need only one guarantee - all the records have to be written into the log before prepare start. That means we free to batch such writes (for example 10 rows in one data record) it shouldn't cause memory issues but will resolve contention. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9290) Make remove explicit locks async when node left.
[
https://issues.apache.org/jira/browse/IGNITE-9290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16724100#comment-16724100
]
Andrey Gura commented on IGNITE-9290:
-
There is no such way. You can use {{GridWorker.updateHeartbeat()}} method or
use {{GridWorker.blockingSectionBegin()/GridWorker.blockingSectionEnd()}} for
blocking operations if you implement own worker. In general, if your code could
be invoked from different threads you should check that thread is runner of
{{GridWorker}} and this particular {{GridWroker}} instance is registered in
{{WorkersRegistry}}.
> Make remove explicit locks async when node left.
>
>
> Key: IGNITE-9290
> URL: https://issues.apache.org/jira/browse/IGNITE-9290
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>Priority: Critical
> Labels: deadlock, iep-25
> Fix For: 2.8
>
>
> GridCacheMvccManager.removeExplicitNodeLocks() run synchronously in discovery
> and exchange threads. This introduce unnecessary delays in discovery and
> exchange process.
> Also, this may cause a deadlock on node stop if user transaction holds an
> entry lock and awaits some Ignite manager response (e.g. cache store or DR or
> CQ), as manager stops right after last exchange has finished so managers
> can't detect node is stopping.
>
> [1]
> [http://apache-ignite-developers.2346864.n4.nabble.com/Synchronous-tx-entries-unlocking-in-discovery-exchange-threads-td33827.html]
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10709) New inspections introduced in 2018+ IntelliJ IDEA version must be disabled on TC configuration
[
https://issues.apache.org/jira/browse/IGNITE-10709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16724103#comment-16724103
]
Dmitriy Pavlov commented on IGNITE-10709:
-
Blockers came from https://issues.apache.org/jira/browse/IGNITE-10723 fix, not
related to this issue.
> New inspections introduced in 2018+ IntelliJ IDEA version must be disabled on
> TC configuration
> --
>
> Key: IGNITE-10709
> URL: https://issues.apache.org/jira/browse/IGNITE-10709
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: inspections
> Fix For: 2.8
>
>
> IntelliJ IDEA since 2018.1 version has new inspection rules enabled by
> default. This leads to the {{[Inspections] Core}} suite fail as these rules
> are not fixed in the Apache Ignite project code.
> # We need to add and disable them in {{ignite_inspections_teamcity.xml}}
> configuration file.
> # Remove unnecessary suppression according to {{Redundant suppression}} rule
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10709) New inspections introduced in 2018+ IntelliJ IDEA version must be disabled on TC configuration
[
https://issues.apache.org/jira/browse/IGNITE-10709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16724102#comment-16724102
]
Ignite TC Bot commented on IGNITE-10709:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Spring{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2576097]]
* CacheJdbcBlobStoreFactorySelfTest.testIncorrectBeanConfiguration (last
started)
{color:#d04437}Queries 1{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2576099]]
* IgniteSqlSchemaIndexingTest.testCustomSchemaMultipleCachesTablesCollision
(last started)
{color:#d04437}Hibernate 2{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2576101]]
* CacheHibernateStoreFactorySelfTest.testIncorrectBeanConfiguration (last
started)
{color:#d04437}Hibernate 1{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2576103]]
* CacheHibernateStoreFactorySelfTest.testIncorrectBeanConfiguration (last
started)
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2574212buildTypeId=IgniteTests24Java8_RunAll]
> New inspections introduced in 2018+ IntelliJ IDEA version must be disabled on
> TC configuration
> --
>
> Key: IGNITE-10709
> URL: https://issues.apache.org/jira/browse/IGNITE-10709
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: inspections
> Fix For: 2.8
>
>
> IntelliJ IDEA since 2018.1 version has new inspection rules enabled by
> default. This leads to the {{[Inspections] Core}} suite fail as these rules
> are not fixed in the Apache Ignite project code.
> # We need to add and disable them in {{ignite_inspections_teamcity.xml}}
> configuration file.
> # Remove unnecessary suppression according to {{Redundant suppression}} rule
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10262) MVCC: Some client operation may hangs if all data nodes left the grid.
[ https://issues.apache.org/jira/browse/IGNITE-10262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16724101#comment-16724101 ] ASF GitHub Bot commented on IGNITE-10262: - GitHub user rkondakov opened a pull request: https://github.com/apache/ignite/pull/5693 IGNITE-10262: MVCC: Some client operation may hangs if all data nodes left the grid. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10262 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5693.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 #5693 commit 7ed04f947983236fbce41a8c083fb109cf103f77 Author: rkondakov Date: 2018-12-18T13:42:08Z IGNITE-10262: MVCC: Some client operation may hangs if all data nodes left the grid. > MVCC: Some client operation may hangs if all data nodes left the grid. > -- > > Key: IGNITE-10262 > URL: https://issues.apache.org/jira/browse/IGNITE-10262 > Project: Ignite > Issue Type: Bug > Components: mvcc >Affects Versions: 2.7 >Reporter: Andrew Mashenkov >Assignee: Roman Kondakov >Priority: Major > Labels: Hanging > Fix For: 2.8 > > > IgniteClientCacheStartFailoverTest.testClientStartLastServerFailsMvccTx() > hangs forever. > Client put\remove operation should throws CacheServerNotFoundException if > there is no data server in the grid, but can hangs in some cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10279) Control.sh utility unify options naming format
[
https://issues.apache.org/jira/browse/IGNITE-10279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16724099#comment-16724099
]
Ignite TC Bot commented on IGNITE-10279:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (Inspections){color} [[tests 0
BuildFailureOnMetric
|https://ci.ignite.apache.org/viewLog.html?buildId=2583097]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2583108buildTypeId=IgniteTests24Java8_RunAll]
> Control.sh utility unify options naming format
> --
>
> Key: IGNITE-10279
> URL: https://issues.apache.org/jira/browse/IGNITE-10279
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.6
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.8
>
>
> Now we have options in several styles:
> {noformat}
> --ping-interval
> {noformat}
> {noformat}
> --skipZeros
> {noformat}
> I think, we must unify options naming format and we should use linux like
> format, i.e. {{--word1-word2}}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10729) MVCC TX: Improvements.
Igor Seliverstov created IGNITE-10729: - Summary: MVCC TX: Improvements. Key: IGNITE-10729 URL: https://issues.apache.org/jira/browse/IGNITE-10729 Project: Ignite Issue Type: Improvement Components: mvcc Reporter: Igor Seliverstov Currently there are several problems: 1) vacuum doesn't have change set, this means it travers all data to find invisible entries; hanse it breaks read statistics and make all data set "hot" - we should travers data entries instead, and only those entries, which was updated (linked to newer versions), moreover, vacuum should travers only those data pages, which were updated after last successful vacuum (at least one entry on the data page was linked to a never one) 2) vacuum travers over partitions instead of data entries, so, there possible some races like: reader checks an entry; updater removes this entry from partition; vacuum doesn't see the entry and clean TxLog -> reader cannot check the entry state with TxLog and gets an exception. This race prevents an optimization when all entries, older than last successful vacuum version, are considered as COMMITTED (see previous suggestion) 3) all entry versions are placed in BTrees, so, we cannot do updates like PG - just adding a new version and linking the old one to it. Having only one unversioned item per row in all indexes making possible fast invoke operations on such indexes in MVCC mode. Also it let us not to update all indexes on each update operation (partition index isn't updated at all, only SQL indexes, built over changed fields need to be updated) - this dramatically reduces write operations, hence it reduces amount of pages to be "checkpointed" and reduces checkpoint mark phase. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10279) Control.sh utility unify options naming format
[
https://issues.apache.org/jira/browse/IGNITE-10279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16724077#comment-16724077
]
Ignite TC Bot commented on IGNITE-10279:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}ZooKeeper{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2583044]]
* ZookeeperIpFinderTestSuite:
ZookeeperIpFinderTest.testFourNodesWithDuplicateRegistrations - 0,0% fails in
last 406 master runs.
{color:#d04437}Platform .NET (Inspections){color} [[tests 0
BuildFailureOnMetric
|https://ci.ignite.apache.org/viewLog.html?buildId=2583097]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2583108buildTypeId=IgniteTests24Java8_RunAll]
> Control.sh utility unify options naming format
> --
>
> Key: IGNITE-10279
> URL: https://issues.apache.org/jira/browse/IGNITE-10279
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.6
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.8
>
>
> Now we have options in several styles:
> {noformat}
> --ping-interval
> {noformat}
> {noformat}
> --skipZeros
> {noformat}
> I think, we must unify options naming format and we should use linux like
> format, i.e. {{--word1-word2}}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10728) CPP: Move networking into separate library
Igor Sapego created IGNITE-10728: Summary: CPP: Move networking into separate library Key: IGNITE-10728 URL: https://issues.apache.org/jira/browse/IGNITE-10728 Project: Ignite Issue Type: Improvement Components: platforms Affects Versions: 2.7 Reporter: Igor Sapego Assignee: Igor Sapego Fix For: 2.8 Currently, there are two very similar parts in ODBC and C++ Thin Client, which implement networking functionality. We need to move this functionality into separate library. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-1094) Ignite.createCache(CacheConfiguration) hangs if some exception occurs during cache initialization
[ https://issues.apache.org/jira/browse/IGNITE-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16724058#comment-16724058 ] ASF GitHub Bot commented on IGNITE-1094: GitHub user sk0x50 opened a pull request: https://github.com/apache/ignite/pull/5692 muted test related to IGNITE-1094 (revert e3d63621b02e0015aa98fabdffaa27b9a12b) the tests should be analyzed and enabled under https://issues.apache.org/jira/browse/IGNITE-10723 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-1094-mute-tests Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5692.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 #5692 commit 2d914e852b3f1ca51477ca83fed0ccb57c98be3f Author: Slava Koptilin Date: 2018-12-18T13:15:06Z mute tests (revert e3d63621b02e0015aa98fabdffaa27b9a12b) > Ignite.createCache(CacheConfiguration) hangs if some exception occurs during > cache initialization > - > > Key: IGNITE-1094 > URL: https://issues.apache.org/jira/browse/IGNITE-1094 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Sergey Evdokimov >Assignee: Vyacheslav Koptilin >Priority: Major > Labels: Muted_test > Fix For: 2.7 > > > User can pass broken configuration, for example, store factory that throws > exception from create() method. I created test to demonstrate the problem. > See IgniteDynamicCacheStartSelfTest#testBrokenStoreFactory in 'ignite-1094' > branch -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-1094) Ignite.createCache(CacheConfiguration) hangs if some exception occurs during cache initialization
[ https://issues.apache.org/jira/browse/IGNITE-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16724065#comment-16724065 ] ASF GitHub Bot commented on IGNITE-1094: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/5692 > Ignite.createCache(CacheConfiguration) hangs if some exception occurs during > cache initialization > - > > Key: IGNITE-1094 > URL: https://issues.apache.org/jira/browse/IGNITE-1094 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Sergey Evdokimov >Assignee: Vyacheslav Koptilin >Priority: Major > Labels: Muted_test > Fix For: 2.7 > > > User can pass broken configuration, for example, store factory that throws > exception from create() method. I created test to demonstrate the problem. > See IgniteDynamicCacheStartSelfTest#testBrokenStoreFactory in 'ignite-1094' > branch -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10718) [ML] Merge XGBoost and Ignite ML trees together
[ https://issues.apache.org/jira/browse/IGNITE-10718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16724050#comment-16724050 ] ASF GitHub Bot commented on IGNITE-10718: - GitHub user dmitrievanthony opened a pull request: https://github.com/apache/ignite/pull/5691 IGNITE-10718: Merge XGBoost and Ignite ML trees together You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10718 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5691.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 #5691 commit 1991fea7d9f83f78f4accb62aacfc8f81406febe Author: dmitrievanthony Date: 2018-11-29T13:38:18Z IGNITE-10289: First version of XGBoost model parser. commit e23241ee42146b98140f8071f300fd37c6ce7c01 Author: dmitrievanthony Date: 2018-11-29T15:51:38Z IGNITE-10289: Add licence header into XGBoostModel.g4. commit 4b004fc6b8400f70d7b4665c488602abf524f827 Author: dmitrievanthony Date: 2018-11-29T16:11:28Z IGNITE-10289: Add example for XGBoostModelParser. commit ec4efd2e736f4fcad5db553cb3eee47e74656295 Author: dmitrievanthony Date: 2018-11-30T09:45:12Z IGNITE-10289: Fix queue issue in IgniteDistributedInfModelBuilder. commit b95dee0029ffa60565bd8068c8e2bd610025461a Author: dmitrievanthony Date: 2018-11-30T09:55:13Z IGNITE-10289: Exclude model files from licence check scope. commit a36537d3ba0ee733a5c678f5dc9adf8334e1d577 Author: dmitrievanthony Date: 2018-11-30T15:49:25Z IGNITE-10289: Update TensorFlow examples after move models into models directory. commit b2822c861066e36b5c3e620f9ffa601190cdaed6 Author: dmitrievanthony Date: 2018-12-17T09:17:38Z IGNITE-10289: Move XGBoost lexer/parser generated by ANTLR into source tree. commit db03e38f398729c3efa9c12cb5e9537c3d2dc50c Author: dmitrievanthony Date: 2018-12-17T09:21:15Z Merge branch 'master' into ignite-10289 commit 10dea555a7edaa8e4af53c81c9b7a9838d2361b6 Author: dmitrievanthony Date: 2018-12-17T09:28:43Z IGNITE-10289: Add test suite into xgboost-model-parser module. commit fcbe24710eb0b432dd563b6267c74ae40dbdc502 Author: dmitrievanthony Date: 2018-12-17T09:31:19Z IGNITE-10289: Revert changes in example-default.xml. commit 4c7d5e2c7ddf8709b8465f4db53737f40e33e416 Author: dmitrievanthony Date: 2018-12-17T11:37:01Z IGNITE-10289: Fix TC errors. commit a8a07dac6ea6ea2379990ac3f6b2614d22b7b3b3 Author: dmitrievanthony Date: 2018-12-17T12:26:52Z IGNITE-10289: Fix TC errors and add ANTLR grammar into javadoc commit 8adbb6d90f0d47cd27a2bc4bd1539f8fada15676 Author: dmitrievanthony Date: 2018-12-17T14:18:33Z IGNITE-10289: Add todo, merge XGBoost and Ignite ML trees together. commit d7da5b4c43e43b890de358bea40c73378a01c40f Author: dmitrievanthony Date: 2018-12-17T16:13:54Z Merge remote-tracking branch 'origin/master' into ignite-10289 commit 33fa5b010dc60719b4adaa363eb56b62fb0ce373 Author: dmitrievanthony Date: 2018-12-18T13:04:55Z IGNITE-10718: Replace XGBoost trees by Ignite ML trees, initial version. > [ML] Merge XGBoost and Ignite ML trees together > --- > > Key: IGNITE-10718 > URL: https://issues.apache.org/jira/browse/IGNITE-10718 > Project: Ignite > Issue Type: Improvement > Components: ml >Affects Versions: 2.8 >Reporter: Anton Dmitriev >Assignee: Anton Dmitriev >Priority: Major > Fix For: 2.8 > > > Currently we have two similar hierarchy of trees: XGBoost trees and Ignite ML > trees. Would be great to merge them together. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9747) [ML] Add Bernoulli Naive Bayes classifier
[ https://issues.apache.org/jira/browse/IGNITE-9747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16724024#comment-16724024 ] ASF GitHub Bot commented on IGNITE-9747: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/5204 > [ML] Add Bernoulli Naive Bayes classifier > - > > Key: IGNITE-9747 > URL: https://issues.apache.org/jira/browse/IGNITE-9747 > Project: Ignite > Issue Type: Sub-task > Components: ml >Reporter: Ravil Galeyev >Assignee: Ravil Galeyev >Priority: Major > Fix For: 2.8 > > > Naive Bayes classifiers are a family of simple probabilistic classifiers > based on applying Bayes' theorem with strong (naive) independence assumptions > between the features. > So we want to add this algorithm to Apache Ignite ML module. > [Bernoulli Naive > Bayes|http://scikit-learn.org/stable/modules/naive_bayes.html#bernoulli-naive-bayes] > implements the naive Bayes training and classification algorithms for data > that is distributed according to multivariate Bernoulli distributions; i.e., > there may be multiple features but each one is assumed to be a binary-valued > (Bernoulli, boolean) variable. > Requirements for successful PR: > # PartitionedDataset usage > # Trainer-Model paradigm support > # Tests for Model and for Trainer (and other stuff) > # Example of usage with small, but famous dataset like IRIS, Titanic or > House Prices > # Javadocs/codestyle according guidelines -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10262) MVCC: Some client operation may hangs if all data nodes left the grid.
[ https://issues.apache.org/jira/browse/IGNITE-10262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Kondakov reassigned IGNITE-10262: --- Assignee: Roman Kondakov > MVCC: Some client operation may hangs if all data nodes left the grid. > -- > > Key: IGNITE-10262 > URL: https://issues.apache.org/jira/browse/IGNITE-10262 > Project: Ignite > Issue Type: Bug > Components: mvcc >Affects Versions: 2.7 >Reporter: Andrew Mashenkov >Assignee: Roman Kondakov >Priority: Major > Labels: Hanging > Fix For: 2.8 > > > IgniteClientCacheStartFailoverTest.testClientStartLastServerFailsMvccTx() > hangs forever. > Client put\remove operation should throws CacheServerNotFoundException if > there is no data server in the grid, but can hangs in some cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9303) PageSnapshot can contain wrong pageId tag when not dirty page is recycling
[
https://issues.apache.org/jira/browse/IGNITE-9303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16724012#comment-16724012
]
Ignite TC Bot commented on IGNITE-9303:
---
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (Inspections){color} [[tests 0
BuildFailureOnMetric
|https://ci.ignite.apache.org/viewLog.html?buildId=2583006]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2575894buildTypeId=IgniteTests24Java8_RunAll]
> PageSnapshot can contain wrong pageId tag when not dirty page is recycling
> --
>
> Key: IGNITE-9303
> URL: https://issues.apache.org/jira/browse/IGNITE-9303
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Aleksey Plekhanov
>Assignee: Ilya Lantukh
>Priority: Major
> Fix For: 2.8
>
>
> When page is recycling (for example in {{BPlusTree.Remove#freePage()}} ->
> {{DataStructure#recyclePage()}}) tag of {{pageId}} is modified, but original
> {{pageId}} is passed to {{writeUnlock()}} method and this passed {{pageId}}
> is stored to PageSnapshot WAL record.
> This bug may lead to errors in WAL applying during crash recovery.
> Reproducer (ignite-indexing module must be in classpath):
> {code:java}
> public class WalFailReproducer extends AbstractWalDeltaConsistencyTest {
> @Override protected boolean checkPagesOnCheckpoint() {
> return true;
> }
> public final void testPutRemoveCacheDestroy() throws Exception {
> CacheConfiguration ccfg = new
> CacheConfiguration<>("cache0");
> ccfg.setIndexedTypes(Integer.class, Integer.class);
> IgniteEx ignite = startGrid(0);
> ignite.cluster().active(true);
> IgniteCache cache0 = ignite.getOrCreateCache(ccfg);
> for (int i = 0; i < 5_000; i++)
> cache0.put(i, i);
> forceCheckpoint();
> for (int i = 1_000; i < 4_000; i++)
> cache0.remove(i);
> forceCheckpoint();
> stopAllGrids();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10434) MVCC: Transaction asynchronous rollback bug.
[
https://issues.apache.org/jira/browse/IGNITE-10434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723952#comment-16723952
]
Igor Seliverstov commented on IGNITE-10434:
---
[~vozerov], please look at.
> MVCC: Transaction asynchronous rollback bug.
>
>
> Key: IGNITE-10434
> URL: https://issues.apache.org/jira/browse/IGNITE-10434
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Igor Seliverstov
>Priority: Major
>
> There is some bug in mvcc tx asynchronous rollback flow. Sometimes
> transaction is not rolled back completely: Remote transactions remain alive
> while Near and Dht transactions are terminated locally and on MVCC
> coordinator.
> Reproducer: {{MvccTxRollbackAsyncTest#testMixedAsyncRollbackTypes}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10434) MVCC: Transaction asynchronous rollback bug.
[
https://issues.apache.org/jira/browse/IGNITE-10434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723943#comment-16723943
]
Ignite TC Bot commented on IGNITE-10434:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2539895buildTypeId=IgniteTests24Java8_RunAll]
> MVCC: Transaction asynchronous rollback bug.
>
>
> Key: IGNITE-10434
> URL: https://issues.apache.org/jira/browse/IGNITE-10434
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Igor Seliverstov
>Priority: Major
>
> There is some bug in mvcc tx asynchronous rollback flow. Sometimes
> transaction is not rolled back completely: Remote transactions remain alive
> while Near and Dht transactions are terminated locally and on MVCC
> coordinator.
> Reproducer: {{MvccTxRollbackAsyncTest#testMixedAsyncRollbackTypes}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (IGNITE-9308) Add baseline topology command to REST API
[ https://issues.apache.org/jira/browse/IGNITE-9308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Novikov closed IGNITE-9308. -- Merged to master. > Add baseline topology command to REST API > -- > > Key: IGNITE-9308 > URL: https://issues.apache.org/jira/browse/IGNITE-9308 > Project: Ignite > Issue Type: Bug > Components: rest >Affects Versions: 2.6 >Reporter: ARomantsov >Assignee: Andrey Novikov >Priority: Major > Fix For: 2.8 > > > Not found in https://apacheignite.readme.io/docs/rest-api info about baseline > command https://apacheignite.readme.io/docs/baseline-topology -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9308) Add baseline topology command to REST API
[ https://issues.apache.org/jira/browse/IGNITE-9308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723919#comment-16723919 ] ASF GitHub Bot commented on IGNITE-9308: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/5019 > Add baseline topology command to REST API > -- > > Key: IGNITE-9308 > URL: https://issues.apache.org/jira/browse/IGNITE-9308 > Project: Ignite > Issue Type: Bug > Components: rest >Affects Versions: 2.6 >Reporter: ARomantsov >Assignee: Andrey Novikov >Priority: Major > Fix For: 2.8 > > > Not found in https://apacheignite.readme.io/docs/rest-api info about baseline > command https://apacheignite.readme.io/docs/baseline-topology -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10721) Documentation: Fix UUID thin client format description
[ https://issues.apache.org/jira/browse/IGNITE-10721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723904#comment-16723904 ] Alexey Kosenchuk commented on IGNITE-10721: --- In this case, the content/meaning of these two longs should be clarified. Eg. if the supported UUID is RFC-4122 UUID, then how it's fields (time_low, time_mid,...) should be located in that two longs. > Documentation: Fix UUID thin client format description > -- > > Key: IGNITE-10721 > URL: https://issues.apache.org/jira/browse/IGNITE-10721 > Project: Ignite > Issue Type: Task > Components: documentation, thin client >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.8 > > > UUID thin client format description [1] need to be fixed. The actual format > of the UUID should be two longs, not a single 128-bit value. Two longs > written in little-endian are not equal to one 128-bit number. > [1] - > https://apacheignite.readme.io/docs/binary-client-protocol-data-format#section-uuid-guid- -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10721) Documentation: Fix UUID thin client format description
[ https://issues.apache.org/jira/browse/IGNITE-10721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego reassigned IGNITE-10721: Assignee: Igor Sapego > Documentation: Fix UUID thin client format description > -- > > Key: IGNITE-10721 > URL: https://issues.apache.org/jira/browse/IGNITE-10721 > Project: Ignite > Issue Type: Task > Components: documentation, thin client >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.8 > > > UUID thin client format description [1] need to be fixed. The actual format > of the UUID should be two longs, not a single 128-bit value. Two longs > written in little-endian are not equal to one 128-bit number. > [1] - > https://apacheignite.readme.io/docs/binary-client-protocol-data-format#section-uuid-guid- -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10086) CPP: Update documentation stating Clang compiler as a supported
[ https://issues.apache.org/jira/browse/IGNITE-10086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego reassigned IGNITE-10086: Assignee: (was: Igor Sapego) > CPP: Update documentation stating Clang compiler as a supported > --- > > Key: IGNITE-10086 > URL: https://issues.apache.org/jira/browse/IGNITE-10086 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Igor Sapego >Priority: Major > > Need to check all relevant documentation files (readme.io, > modules/platforms/cpp/README.txt, modules/platforms/cpp/DEVNOTES.txt, > modules/platforms/cpp/odbc/README.txt) and add Clang as a supported compiler > if applicable. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10178) change tests that fail("Ignite JIRA ticket URL") to @Ignore("Ignite JIRA ticket URL")
[
https://issues.apache.org/jira/browse/IGNITE-10178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10178:
Description:
Change tests that use {{fail("Ignite JIRA ticket URL")}} to {{@Ignore("Ignite
JIRA ticket URL")}}. Do the same change for tests that fail by
{{@IgniteIgnore("Ignite JIRA ticket URL")}}, like for example
[S3CheckpointSpiStartStopSelfTest.testStartStop|https://github.com/apache/ignite/blob/master/modules/aws/src/test/java/org/apache/ignite/spi/checkpoint/s3/S3CheckpointSpiStartStopSelfTest.java].
Also, use [Ignore|http://junit.sourceforge.net/javadoc/org/junit/Ignore.html]
to annotate empty test classes in examples that were discovered and re-muted
per IGNITE-10174.
If needed, refer parent task for more details.
Note this step would better be coordinated with Teamcity and TC bot maintainers
because it may substantially impact them.
-
Note that tests that are expected to be ignored depending on runtime conditions
should be rewritten to use {{Assume}} instead of {{fail}}. So that old code...
{code}if (someRuntimeCondition())
fail("Ignite JIRA ticket URL");{code}
...will change to
{code}Assume.assumeFalse("Ignite JIRA ticket URL",
someRuntimeCondition());{code}
(this change can be "extracted" into separate JIRA task if it is more
convenient). Readers interested to find more details about how {{Assume}} works
can find more details and code snippet [in comments
here|https://issues.apache.org/jira/browse/IGNITE-10178?focusedCommentId=16723863=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16723863].
was:
Change tests that use {{fail("Ignite JIRA ticket URL")}} to {{@Ignore("Ignite
JIRA ticket URL")}}. Do the same change for tests that fail by
{{@IgniteIgnore("Ignite JIRA ticket URL")}}, like for example
[S3CheckpointSpiStartStopSelfTest.testStartStop|https://github.com/apache/ignite/blob/master/modules/aws/src/test/java/org/apache/ignite/spi/checkpoint/s3/S3CheckpointSpiStartStopSelfTest.java].
Also, use [Ignore|http://junit.sourceforge.net/javadoc/org/junit/Ignore.html]
to annotate empty test classes in examples that were discovered and re-muted
per IGNITE-10174.
If needed, refer parent task for more details.
Note this step would better be coordinated with Teamcity and TC bot maintainers
because it may substantially impact them
> change tests that fail("Ignite JIRA ticket URL") to @Ignore("Ignite JIRA
> ticket URL")
> -
>
> Key: IGNITE-10178
> URL: https://issues.apache.org/jira/browse/IGNITE-10178
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Oleg Ignatenko
>Assignee: PetrovMikhail
>Priority: Major
>
> Change tests that use {{fail("Ignite JIRA ticket URL")}} to {{@Ignore("Ignite
> JIRA ticket URL")}}. Do the same change for tests that fail by
> {{@IgniteIgnore("Ignite JIRA ticket URL")}}, like for example
> [S3CheckpointSpiStartStopSelfTest.testStartStop|https://github.com/apache/ignite/blob/master/modules/aws/src/test/java/org/apache/ignite/spi/checkpoint/s3/S3CheckpointSpiStartStopSelfTest.java].
> Also, use
> [Ignore|http://junit.sourceforge.net/javadoc/org/junit/Ignore.html] to
> annotate empty test classes in examples that were discovered and re-muted per
> IGNITE-10174.
> If needed, refer parent task for more details.
> Note this step would better be coordinated with Teamcity and TC bot
> maintainers because it may substantially impact them.
> -
> Note that tests that are expected to be ignored depending on runtime
> conditions should be rewritten to use {{Assume}} instead of {{fail}}. So that
> old code...
> {code}if (someRuntimeCondition())
> fail("Ignite JIRA ticket URL");{code}
> ...will change to
> {code}Assume.assumeFalse("Ignite JIRA ticket URL",
> someRuntimeCondition());{code}
> (this change can be "extracted" into separate JIRA task if it is more
> convenient). Readers interested to find more details about how {{Assume}}
> works can find more details and code snippet [in comments
> here|https://issues.apache.org/jira/browse/IGNITE-10178?focusedCommentId=16723863=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16723863].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-10086) CPP: Update documentation stating Clang compiler as a supported
[ https://issues.apache.org/jira/browse/IGNITE-10086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego reassigned IGNITE-10086: Assignee: Igor Sapego > CPP: Update documentation stating Clang compiler as a supported > --- > > Key: IGNITE-10086 > URL: https://issues.apache.org/jira/browse/IGNITE-10086 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > > Need to check all relevant documentation files (readme.io, > modules/platforms/cpp/README.txt, modules/platforms/cpp/DEVNOTES.txt, > modules/platforms/cpp/odbc/README.txt) and add Clang as a supported compiler > if applicable. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10178) change tests that fail("Ignite JIRA ticket URL") to @Ignore("Ignite JIRA ticket URL")
[
https://issues.apache.org/jira/browse/IGNITE-10178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723863#comment-16723863
]
Oleg Ignatenko edited comment on IGNITE-10178 at 12/18/18 9:44 AM:
---
(i) Note that in JUnit 4 an idiomatic way to ignore tests depending on runtime
conditions is by using
[Assume|https://junit.org/junit4/javadoc/4.12/org/junit/Assume.html] API.
See code snippet demonstrating how it works: {code}
import org.junit.Test;
import static org.junit.Assume.assumeTrue;
public class AssumeDemo {
@Test
public void assume1() {
assumeTrue("assumption explanation", runtimeCondition(1));
System.out.println("assume 1");
}
@Test
public void assume2() {
assumeTrue("assumption explanation", runtimeCondition(2));
System.out.println("assume 2");
}
private boolean runtimeCondition(int val) {
boolean res = (val & 1) == 0;
System.out.println("Runtime condition holds: " + res);
return res;
}
}{code}
The output when executing this code is as follows: {noformat}
Runtime condition holds: false
org.junit.internal.AssumptionViolatedException: assumption explanation
at org.junit.Assume.assumeTrue(Assume.java:59)
at org.apache.ignite.ml.common.AssumeDemo.assume1(AssumeDemo.java:10)
...
Runtime condition holds: true
assume 2{noformat}
was (Author: oignatenko):
(i) Note that in JUnit 4 an idiomatic way to ignore tests depending on runtime
conditions is by using
[Assume|https://junit.org/junit4/javadoc/4.12/org/junit/Assume.html] API.
See code snippet demonstrating how it works: {code}
import org.junit.Test;
import static org.junit.Assume.assumeTrue;
public class AssumeDemo {
@Test
public void assume1() {
assumeTrue("", runtimeCondition(1));
System.out.println("assume 1");
}
@Test
public void assume2() {
assumeTrue("", runtimeCondition(2));
System.out.println("assume 2");
}
private boolean runtimeCondition(int val) {
boolean res = (val & 1) == 0;
System.out.println("Runtime condition holds: " + res);
return res;
}
}{code}
The output when executing this code is as follows: {noformat}
Runtime condition holds: false
Test ignored.
org.junit.internal.AssumptionViolatedException:
at org.junit.Assume.assumeTrue(Assume.java:59)
at org.apache.ignite.ml.common.AssumeDemo.assume1(AssumeDemo.java:10)
...
Runtime condition holds: true
assume 2{noformat}
> change tests that fail("Ignite JIRA ticket URL") to @Ignore("Ignite JIRA
> ticket URL")
> -
>
> Key: IGNITE-10178
> URL: https://issues.apache.org/jira/browse/IGNITE-10178
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Oleg Ignatenko
>Assignee: PetrovMikhail
>Priority: Major
>
> Change tests that use {{fail("Ignite JIRA ticket URL")}} to {{@Ignore("Ignite
> JIRA ticket URL")}}. Do the same change for tests that fail by
> {{@IgniteIgnore("Ignite JIRA ticket URL")}}, like for example
> [S3CheckpointSpiStartStopSelfTest.testStartStop|https://github.com/apache/ignite/blob/master/modules/aws/src/test/java/org/apache/ignite/spi/checkpoint/s3/S3CheckpointSpiStartStopSelfTest.java].
> Also, use
> [Ignore|http://junit.sourceforge.net/javadoc/org/junit/Ignore.html] to
> annotate empty test classes in examples that were discovered and re-muted per
> IGNITE-10174.
> If needed, refer parent task for more details.
> Note this step would better be coordinated with Teamcity and TC bot
> maintainers because it may substantially impact them.
> -
> Note that tests that are expected to be ignored depending on runtime
> conditions should be rewritten to use {{Assume}} instead of {{fail}}. So that
> old code...
> {code}if (someRuntimeCondition())
> fail("Ignite JIRA ticket URL");{code}
> ...will change to
> {code}Assume.assumeFalse("Ignite JIRA ticket URL",
> someRuntimeCondition());{code}
> (this change can be "extracted" into separate JIRA task if it is more
> convenient). Readers interested to find more details about how {{Assume}}
> works can find more details and code snippet [in comments
> here|https://issues.apache.org/jira/browse/IGNITE-10178?focusedCommentId=16723863=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16723863].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10178) change tests that fail("Ignite JIRA ticket URL") to @Ignore("Ignite JIRA ticket URL")
[
https://issues.apache.org/jira/browse/IGNITE-10178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723863#comment-16723863
]
Oleg Ignatenko commented on IGNITE-10178:
-
(i) Note that in JUnit 4 an idiomatic way to ignore tests depending on runtime
conditions is by using
[Assume|https://junit.org/junit4/javadoc/4.12/org/junit/Assume.html] API.
See code snippet demonstrating how it works: {code}
import org.junit.Test;
import static org.junit.Assume.assumeTrue;
public class AssumeDemo {
@Test
public void assume1() {
assumeTrue("", runtimeCondition(1));
System.out.println("assume 1");
}
@Test
public void assume2() {
assumeTrue("", runtimeCondition(2));
System.out.println("assume 2");
}
private boolean runtimeCondition(int val) {
boolean res = (val & 1) == 0;
System.out.println("Runtime condition holds: " + res);
return res;
}
}{code}
The output when executing this code is as follows: {noformat}
Runtime condition holds: false
Test ignored.
org.junit.internal.AssumptionViolatedException:
at org.junit.Assume.assumeTrue(Assume.java:59)
at org.apache.ignite.ml.common.AssumeDemo.assume1(AssumeDemo.java:10)
...
Runtime condition holds: true
assume 2{noformat}
> change tests that fail("Ignite JIRA ticket URL") to @Ignore("Ignite JIRA
> ticket URL")
> -
>
> Key: IGNITE-10178
> URL: https://issues.apache.org/jira/browse/IGNITE-10178
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Oleg Ignatenko
>Assignee: PetrovMikhail
>Priority: Major
>
> Change tests that use {{fail("Ignite JIRA ticket URL")}} to {{@Ignore("Ignite
> JIRA ticket URL")}}. Do the same change for tests that fail by
> {{@IgniteIgnore("Ignite JIRA ticket URL")}}, like for example
> [S3CheckpointSpiStartStopSelfTest.testStartStop|https://github.com/apache/ignite/blob/master/modules/aws/src/test/java/org/apache/ignite/spi/checkpoint/s3/S3CheckpointSpiStartStopSelfTest.java].
> Also, use
> [Ignore|http://junit.sourceforge.net/javadoc/org/junit/Ignore.html] to
> annotate empty test classes in examples that were discovered and re-muted per
> IGNITE-10174.
> If needed, refer parent task for more details.
> Note this step would better be coordinated with Teamcity and TC bot
> maintainers because it may substantially impact them
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10695) MVCC: Fix cache API conditional update operations.
[ https://issues.apache.org/jira/browse/IGNITE-10695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-10695: -- Fix Version/s: (was: 2.8) > MVCC: Fix cache API conditional update operations. > -- > > Key: IGNITE-10695 > URL: https://issues.apache.org/jira/browse/IGNITE-10695 > Project: Ignite > Issue Type: Improvement > Components: mvcc >Affects Versions: 2.7 >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > > Operation like putIfAbsent and replace now tries to transfer Predicate > instance (filter) to remote node. > # Predicates are transferred to remote node with each update. > # Predicate should be transferred only for "replace" operation if certain > entry provided, otherwise we should send a correct operation code and use > corresponding static filter on remote side. > # This change will break protocol compatibility. Should we bother about it? > Let's fix protocol and add tests. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-5115) Investigation of failing tests of coordinator node failure
[
https://issues.apache.org/jira/browse/IGNITE-5115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723853#comment-16723853
]
Anton Kalashnikov commented on IGNITE-5115:
---
Changes and tests looks good for me. I think it can be merged. I have only one
minor notes - perhaps it makes sense will add one more node to tests for
checking ring closing after coordinator segmented.
> Investigation of failing tests of coordinator node failure
> ---
>
> Key: IGNITE-5115
> URL: https://issues.apache.org/jira/browse/IGNITE-5115
> Project: Ignite
> Issue Type: Bug
> Components: messaging
>Reporter: Sergey Chugunov
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> Tests *customEventCoordinatorFailure1/2* from *TcpDiscoverySelfTest* are
> flaky on TC and sometimes hang with the following assertion in logs:
> {code}
> Exception in thread "tcp-disco-msg-worker-#5245%tcp.TcpDiscoverySelfTest0%"
> java.lang.AssertionError
> at
> org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing.removeNode(TcpDiscoveryNodesRing.java:353)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeFailedMessage(ServerImpl.java:4670)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2567)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2366)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6485)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2456)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {code}
> It seems that this happens because tests' implementation drops connections of
> *TcpCommunicatonSpi* on coordinator node with *simulateNodeFailure* method.
> At the same time tests leave *TcpDiscoverySpi* operational; it receives
> subsequent NodeFailed message and throws the assertion error shown above.
> The whole situation looks legitimate as it is possible to imagine a situation
> when CommSPI connections on coordinator fail for some reason while DiscoSPI
> connections are healthy.
> It is needed to investigate the situation deeper, figure out whether the root
> cause is using of *simulateNodeFailure* or not and propose a solution if the
> error may happen in the real life.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10591) MVCC: Incorrect data region metrics.
[
https://issues.apache.org/jira/browse/IGNITE-10591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723843#comment-16723843
]
ASF GitHub Bot commented on IGNITE-10591:
-
GitHub user AMashenkov opened a pull request:
https://github.com/apache/ignite/pull/5690
IGNITE-10591: Fix region metrics test.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-10591
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/5690.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 #5690
commit 74db58b07594d5cb580550e7443d98330592d628
Author: Andrey V. Mashenkov
Date: 2018-12-18T08:58:05Z
IGNITE-10591: Fix region metrics test.
> MVCC: Incorrect data region metrics.
>
>
> Key: IGNITE-10591
> URL: https://issues.apache.org/jira/browse/IGNITE-10591
> Project: Ignite
> Issue Type: Bug
> Components: mvcc, persistence
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>Priority: Major
>
> IgnitePdsDataRegionMetricsTest.testMemoryUsageSingleNode failed.
> {noformat}
> junit.framework.AssertionFailedError: Number of allocated pages is different
> than in metrics for [node=db.IgnitePdsDataRegionMetricsTest0, cache=default]
> expected:<13542> but was:<13881>
> 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:159)
> at junit.framework.TestCase.assertEquals(TestCase.java:316)
> at
> org.apache.ignite.internal.processors.cache.persistence.db.IgnitePdsDataRegionMetricsTest.checkMetricsConsistency(IgnitePdsDataRegionMetricsTest.java:337)
> at
> org.apache.ignite.internal.processors.cache.persistence.db.IgnitePdsDataRegionMetricsTest.testMemoryUsageSingleNode(IgnitePdsDataRegionMetricsTest.java:155){noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-10697) [ML] Add Frequency Encoding
[ https://issues.apache.org/jira/browse/IGNITE-10697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Platonov reassigned IGNITE-10697: Assignee: Aleksey Zinoviev (was: Alexey Platonov) > [ML] Add Frequency Encoding > --- > > Key: IGNITE-10697 > URL: https://issues.apache.org/jira/browse/IGNITE-10697 > Project: Ignite > Issue Type: New Feature > Components: ml >Affects Versions: 2.8 >Reporter: Aleksey Zinoviev >Assignee: Aleksey Zinoviev >Priority: Critical > Fix For: 2.8 > > > Encode the values to a fraction of all the labels. Can work with linear > models if the frequency is correlated with the target value. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10697) [ML] Add Frequency Encoding
[ https://issues.apache.org/jira/browse/IGNITE-10697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Platonov reassigned IGNITE-10697: Assignee: Alexey Platonov (was: Aleksey Zinoviev) > [ML] Add Frequency Encoding > --- > > Key: IGNITE-10697 > URL: https://issues.apache.org/jira/browse/IGNITE-10697 > Project: Ignite > Issue Type: New Feature > Components: ml >Affects Versions: 2.8 >Reporter: Aleksey Zinoviev >Assignee: Alexey Platonov >Priority: Critical > Fix For: 2.8 > > > Encode the values to a fraction of all the labels. Can work with linear > models if the frequency is correlated with the target value. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10314) Spark dataframe will get wrong schema if user executes add/drop column DDL
[ https://issues.apache.org/jira/browse/IGNITE-10314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723826#comment-16723826 ] Nikolay Izhikov commented on IGNITE-10314: -- Hello, [~ldz] Thanks for the PR update. I left comment in your PR, please, take a look. > Spark dataframe will get wrong schema if user executes add/drop column DDL > -- > > Key: IGNITE-10314 > URL: https://issues.apache.org/jira/browse/IGNITE-10314 > Project: Ignite > Issue Type: Bug > Components: spark >Affects Versions: 2.3, 2.4, 2.5, 2.6, 2.7 >Reporter: Ray >Assignee: Ray >Priority: Critical > Fix For: 2.8 > > > When user performs add/remove column in DDL, Spark will get the old/wrong > schema. > > Analyse > Currently Spark data frame API relies on QueryEntity to construct schema, but > QueryEntity in QuerySchema is a local copy of the original QueryEntity, so > the original QueryEntity is not updated when modification happens. > > Solution > Get the latest schema using JDBC thin driver's column metadata call, then > update fields in QueryEntity. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10643) GridCacheContextInfo should not use isCacheContextInited() method to calculate constant properties
[
https://issues.apache.org/jira/browse/IGNITE-10643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723801#comment-16723801
]
ASF GitHub Bot commented on IGNITE-10643:
-
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/5641
> GridCacheContextInfo should not use isCacheContextInited() method to
> calculate constant properties
> --
>
> Key: IGNITE-10643
> URL: https://issues.apache.org/jira/browse/IGNITE-10643
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Labels: iep-24
> Fix For: 2.8
>
>
> This appears to be a regression from IGNITE-6173. Current method
> {{isCacheContextInited}} is used to determine several properties (config,
> name, customAffinityMapper, groupId, cacheId, affinityNode). This is wrong,
> as all of these properties are "constant" and can be deduced form
> configuration.
> One specific case when it breaks Ignite is {{customAffinityMapper}}. It is
> used to determine affinity key field in {{GridH2Table}} which will be used
> later on for partition pruning. However, when table is created on a client
> node and context is not initialized yet, it will return "false", and
> incorrect affinity key will be calculated in
> {{QueryUtils.typeForQueryEntity}} and in {{GridH2Table}} later on. Finally,
> when query is executed, incorrect partition might be derived from it leading
> to incorrect query result.
> Solution: make all mentioned methods independent of cache state.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10643) GridCacheContextInfo should not use isCacheContextInited() method to calculate constant properties
[
https://issues.apache.org/jira/browse/IGNITE-10643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723798#comment-16723798
]
ASF GitHub Bot commented on IGNITE-10643:
-
Github user devozerov closed the pull request at:
https://github.com/apache/ignite/pull/5649
> GridCacheContextInfo should not use isCacheContextInited() method to
> calculate constant properties
> --
>
> Key: IGNITE-10643
> URL: https://issues.apache.org/jira/browse/IGNITE-10643
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Labels: iep-24
> Fix For: 2.8
>
>
> This appears to be a regression from IGNITE-6173. Current method
> {{isCacheContextInited}} is used to determine several properties (config,
> name, customAffinityMapper, groupId, cacheId, affinityNode). This is wrong,
> as all of these properties are "constant" and can be deduced form
> configuration.
> One specific case when it breaks Ignite is {{customAffinityMapper}}. It is
> used to determine affinity key field in {{GridH2Table}} which will be used
> later on for partition pruning. However, when table is created on a client
> node and context is not initialized yet, it will return "false", and
> incorrect affinity key will be calculated in
> {{QueryUtils.typeForQueryEntity}} and in {{GridH2Table}} later on. Finally,
> when query is executed, incorrect partition might be derived from it leading
> to incorrect query result.
> Solution: make all mentioned methods independent of cache state.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10643) GridCacheContextInfo should not use isCacheContextInited() method to calculate constant properties
[
https://issues.apache.org/jira/browse/IGNITE-10643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723789#comment-16723789
]
Vladimir Ozerov commented on IGNITE-10643:
--
TC run is OK (verified manually).
> GridCacheContextInfo should not use isCacheContextInited() method to
> calculate constant properties
> --
>
> Key: IGNITE-10643
> URL: https://issues.apache.org/jira/browse/IGNITE-10643
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Labels: iep-24
> Fix For: 2.8
>
>
> This appears to be a regression from IGNITE-6173. Current method
> {{isCacheContextInited}} is used to determine several properties (config,
> name, customAffinityMapper, groupId, cacheId, affinityNode). This is wrong,
> as all of these properties are "constant" and can be deduced form
> configuration.
> One specific case when it breaks Ignite is {{customAffinityMapper}}. It is
> used to determine affinity key field in {{GridH2Table}} which will be used
> later on for partition pruning. However, when table is created on a client
> node and context is not initialized yet, it will return "false", and
> incorrect affinity key will be calculated in
> {{QueryUtils.typeForQueryEntity}} and in {{GridH2Table}} later on. Finally,
> when query is executed, incorrect partition might be derived from it leading
> to incorrect query result.
> Solution: make all mentioned methods independent of cache state.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
