[jira] [Updated] (IGNITE-12033) .Net callbacks from striped pool due to async/await may hang cluster
[
https://issues.apache.org/jira/browse/IGNITE-12033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-12033:
-
Fix Version/s: 2.7.6
> .Net callbacks from striped pool due to async/await may hang cluster
>
>
> Key: IGNITE-12033
> URL: https://issues.apache.org/jira/browse/IGNITE-12033
> Project: Ignite
> Issue Type: Bug
> Components: cache, platforms
>Affects Versions: 2.7.5
>Reporter: Ilya Kasnacheev
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .net
> Fix For: 2.7.6
>
>
> http://apache-ignite-users.70518.x6.nabble.com/Replace-or-Put-after-PutAsync-causes-Ignite-to-hang-td27871.html#a28051
> There's a reproducer project. Long story short, .Net can invoke cache
> operations with future callbacks, which will be invoked from striped pool. If
> such callbacks are to use cache operations, those will be possibly sheduled
> to the same stripe and cause a deadlock.
> The code is very simple:
> {code}
> Console.WriteLine("PutAsync");
> await cache.PutAsync(1, "Test");
> Console.WriteLine("Replace");
> cache.Replace(1, "Testing"); // Hangs here
> Console.WriteLine("Wait");
> await Task.Delay(Timeout.Infinite);
> {code}
> async/await should absolutely not allow any client code to be run from
> stripes.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (IGNITE-10619) Add support files transmission between nodes over connection via CommunicationSpi
[
https://issues.apache.org/jira/browse/IGNITE-10619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16902085#comment-16902085
]
Ignite TC Bot commented on IGNITE-10619:
{panel:title=Branch: [pull/5619/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4472399buildTypeId=IgniteTests24Java8_RunAll]
> Add support files transmission between nodes over connection via
> CommunicationSpi
> -
>
> Key: IGNITE-10619
> URL: https://issues.apache.org/jira/browse/IGNITE-10619
> Project: Ignite
> Issue Type: Sub-task
> Components: persistence
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: iep-28
> Time Spent: 6h
> Remaining Estimate: 0h
>
> Partition preloader must support cache partition file relocation from one
> cluster node to another (the zero copy algorithm [1] assume to be used by
> default). To achieve this, the file transfer machinery must be implemented at
> Apache Ignite over Communication SPI.
> _CommunicationSpi_
> Ignite's Comminication SPI must support to:
> * establishing channel connections to the remote node to an arbitrary topic
> (GridTopic) with predefined processing policy;
> * listening incoming channel creation events and registering connection
> handlers on the particular node;
> * an arbitrary set of channel parameters on connection handshake;
> _FileTransmitProcessor_
> The file transmission manager must support to:
> * using different approaches of incoming data handling – buffered and direct
> (zero-copy approach of FileChannel#transferTo);
> * transferring data by chunks of predefined size with saving intermediate
> results;
> * re-establishing connection if an error occurs and continue file
> upload\download;
> * limiting connection bandwidth (upload and download) at runtime;
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (IGNITE-10337) [TC Bot] Test ticket
[ https://issues.apache.org/jira/browse/IGNITE-10337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-10337: Ignite Flags: (was: Docs Required) > [TC Bot] Test ticket > > > Key: IGNITE-10337 > URL: https://issues.apache.org/jira/browse/IGNITE-10337 > Project: Ignite > Issue Type: Task >Reporter: PetrovMikhail >Priority: Trivial > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (IGNITE-10337) [TC Bot] Test ticket
[ https://issues.apache.org/jira/browse/IGNITE-10337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov resolved IGNITE-10337. - Resolution: Invalid > [TC Bot] Test ticket > > > Key: IGNITE-10337 > URL: https://issues.apache.org/jira/browse/IGNITE-10337 > Project: Ignite > Issue Type: Task >Reporter: PetrovMikhail >Priority: Trivial > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (IGNITE-12049) Allow custom authenticators to use SSL certificates
Ryabov Dmitrii created IGNITE-12049: --- Summary: Allow custom authenticators to use SSL certificates Key: IGNITE-12049 URL: https://issues.apache.org/jira/browse/IGNITE-12049 Project: Ignite Issue Type: Improvement Reporter: Ryabov Dmitrii Add SSL certificates to AuthenticationContext, so, authenticators can make additional checks based on SSL certificates. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (IGNITE-12048) Bugs & tests fixes
[
https://issues.apache.org/jira/browse/IGNITE-12048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Govorukhin updated IGNITE-12048:
Description:
Page replacement can reload invalid page during checkpoint
There is a race between {{writeCheckpointPages}} and page replacement process:
* Checkpointer thread begins a checkpoint
* Checkpointer thread calls {{getPageForCheckpoint()}}, which will copy page
content *and clear dirty flag*
* Page replacement tries to find a page for replacement and chooses this page,
the page is thrown away
* Before the page is written back to the store, the page is acquired again.
As a result, an older copy of the page is brought back to memory, which causes
all kinds of corruption exceptions and assertions.
checkpointReadLock() may hang during node stop
I got this hang during one of PDS (Indexing) runs (thread-dump is attached).
The following code hang:
{code:java}
checkpointer.wakeupForCheckpoint(0, "too many dirty pages").cpBeginFut
.getUninterruptibly();
{code}
It looks like {{wakeupForCheckpoint}} can be called after the checkpointer is
stopped and {{cpBeginFut}} will be never completed.
Fixed
ZookeeperDiscoveryCommunicationFailureTest.testCommunicationFailureResolve_CachesInfo1
Fixed *.testFailAfterStart
Reduce test time execution (scale factor for a long-running tests)
was:
Page replacement can reload invalid page during checkpoint
There is a race between {{writeCheckpointPages}} and page replacement process:
* Checkpointer thread begins a checkpoint
* Checkpointer thread calls {{getPageForCheckpoint()}}, which will copy page
content *and clear dirty flag*
* Page replacement tries to find a page for replacement and chooses this page,
the page is thrown away
* Before the page is written back to the store, the page is acquired again.
As a result, an older copy of the page is brought back to memory, which causes
all kinds of corruption exceptions and assertions.
checkpointReadLock() may hang during node stop
I got this hang during one of PDS (Indexing) runs (thread-dump is attached).
The following code hang:
{code:java}
checkpointer.wakeupForCheckpoint(0, "too many dirty pages").cpBeginFut
.getUninterruptibly();
{code}
It looks like {{wakeupForCheckpoint}} can be called after the checkpointer is
stopped and {{cpBeginFut}} will be never completed.
Fixed
ZookeeperDiscoveryCommunicationFailureTest.testCommunicationFailureResolve_CachesInfo1
Fixed *.testFailAfterStart
> Bugs & tests fixes
> --
>
> Key: IGNITE-12048
> URL: https://issues.apache.org/jira/browse/IGNITE-12048
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.8
>
>
> Page replacement can reload invalid page during checkpoint
> There is a race between {{writeCheckpointPages}} and page replacement process:
> * Checkpointer thread begins a checkpoint
> * Checkpointer thread calls {{getPageForCheckpoint()}}, which will copy page
> content *and clear dirty flag*
> * Page replacement tries to find a page for replacement and chooses this
> page, the page is thrown away
> * Before the page is written back to the store, the page is acquired again.
> As a result, an older copy of the page is brought back to memory, which
> causes all kinds of corruption exceptions and assertions.
>
> checkpointReadLock() may hang during node stop
> I got this hang during one of PDS (Indexing) runs (thread-dump is attached).
> The following code hang:
> {code:java}
> checkpointer.wakeupForCheckpoint(0, "too many dirty pages").cpBeginFut
> .getUninterruptibly();
> {code}
> It looks like {{wakeupForCheckpoint}} can be called after the checkpointer is
> stopped and {{cpBeginFut}} will be never completed.
>
> Fixed
> ZookeeperDiscoveryCommunicationFailureTest.testCommunicationFailureResolve_CachesInfo1
> Fixed *.testFailAfterStart
> Reduce test time execution (scale factor for a long-running tests)
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (IGNITE-12048) Bugs & tests fixes
[
https://issues.apache.org/jira/browse/IGNITE-12048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Govorukhin updated IGNITE-12048:
Description:
Page replacement can reload invalid page during checkpoint
There is a race between {{writeCheckpointPages}} and page replacement process:
* Checkpointer thread begins a checkpoint
* Checkpointer thread calls {{getPageForCheckpoint()}}, which will copy page
content *and clear dirty flag*
* Page replacement tries to find a page for replacement and chooses this page,
the page is thrown away
* Before the page is written back to the store, the page is acquired again.
As a result, an older copy of the page is brought back to memory, which causes
all kinds of corruption exceptions and assertions.
checkpointReadLock() may hang during node stop
I got this hang during one of PDS (Indexing) runs (thread-dump is attached).
The following code hang:
{code:java}
checkpointer.wakeupForCheckpoint(0, "too many dirty pages").cpBeginFut
.getUninterruptibly();
{code}
It looks like {{wakeupForCheckpoint}} can be called after the checkpointer is
stopped and {{cpBeginFut}} will be never completed.
Fixed
ZookeeperDiscoveryCommunicationFailureTest.testCommunicationFailureResolve_CachesInfo1
Fixed *.testFailAfterStart
was:
Page replacement can reload invalid page during checkpoint
There is a race between {{writeCheckpointPages}} and page replacement process:
* Checkpointer thread begins a checkpoint
* Checkpointer thread calls {{getPageForCheckpoint()}}, which will copy page
content *and clear dirty flag*
* Page replacement tries to find a page for replacement and chooses this page,
the page is thrown away
* Before the page is written back to the store, the page is acquired again.
As a result, an older copy of the page is brought back to memory, which causes
all kinds of corruption exceptions and assertions.
-
checkpointReadLock() may hang during node stop
I got this hang during one of PDS (Indexing) runs (thread-dump is attached).
The following code hang:
{code:java}
checkpointer.wakeupForCheckpoint(0, "too many dirty pages").cpBeginFut
.getUninterruptibly();
{code}
It looks like {{wakeupForCheckpoint}} can be called after the checkpointer is
stopped and {{cpBeginFut}} will be never completed.
-
Fixed
ZookeeperDiscoveryCommunicationFailureTest.testCommunicationFailureResolve_CachesInfo1
Fixed *.testFailAfterStart
> Bugs & tests fixes
> --
>
> Key: IGNITE-12048
> URL: https://issues.apache.org/jira/browse/IGNITE-12048
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Priority: Major
>
> Page replacement can reload invalid page during checkpoint
> There is a race between {{writeCheckpointPages}} and page replacement process:
> * Checkpointer thread begins a checkpoint
> * Checkpointer thread calls {{getPageForCheckpoint()}}, which will copy page
> content *and clear dirty flag*
> * Page replacement tries to find a page for replacement and chooses this
> page, the page is thrown away
> * Before the page is written back to the store, the page is acquired again.
> As a result, an older copy of the page is brought back to memory, which
> causes all kinds of corruption exceptions and assertions.
>
> checkpointReadLock() may hang during node stop
> I got this hang during one of PDS (Indexing) runs (thread-dump is attached).
> The following code hang:
> {code:java}
> checkpointer.wakeupForCheckpoint(0, "too many dirty pages").cpBeginFut
> .getUninterruptibly();
> {code}
> It looks like {{wakeupForCheckpoint}} can be called after the checkpointer is
> stopped and {{cpBeginFut}} will be never completed.
>
> Fixed
> ZookeeperDiscoveryCommunicationFailureTest.testCommunicationFailureResolve_CachesInfo1
> Fixed *.testFailAfterStart
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (IGNITE-12048) Bugs & tests fixes
Dmitriy Govorukhin created IGNITE-12048:
---
Summary: Bugs & tests fixes
Key: IGNITE-12048
URL: https://issues.apache.org/jira/browse/IGNITE-12048
Project: Ignite
Issue Type: Bug
Reporter: Dmitriy Govorukhin
Page replacement can reload invalid page during checkpoint
There is a race between {{writeCheckpointPages}} and page replacement process:
* Checkpointer thread begins a checkpoint
* Checkpointer thread calls {{getPageForCheckpoint()}}, which will copy page
content *and clear dirty flag*
* Page replacement tries to find a page for replacement and chooses this page,
the page is thrown away
* Before the page is written back to the store, the page is acquired again.
As a result, an older copy of the page is brought back to memory, which causes
all kinds of corruption exceptions and assertions.
-
checkpointReadLock() may hang during node stop
I got this hang during one of PDS (Indexing) runs (thread-dump is attached).
The following code hang:
{code:java}
checkpointer.wakeupForCheckpoint(0, "too many dirty pages").cpBeginFut
.getUninterruptibly();
{code}
It looks like {{wakeupForCheckpoint}} can be called after the checkpointer is
stopped and {{cpBeginFut}} will be never completed.
-
Fixed
ZookeeperDiscoveryCommunicationFailureTest.testCommunicationFailureResolve_CachesInfo1
Fixed *.testFailAfterStart
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (IGNITE-12048) Bugs & tests fixes
[
https://issues.apache.org/jira/browse/IGNITE-12048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Govorukhin updated IGNITE-12048:
Fix Version/s: 2.8
> Bugs & tests fixes
> --
>
> Key: IGNITE-12048
> URL: https://issues.apache.org/jira/browse/IGNITE-12048
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.8
>
>
> Page replacement can reload invalid page during checkpoint
> There is a race between {{writeCheckpointPages}} and page replacement process:
> * Checkpointer thread begins a checkpoint
> * Checkpointer thread calls {{getPageForCheckpoint()}}, which will copy page
> content *and clear dirty flag*
> * Page replacement tries to find a page for replacement and chooses this
> page, the page is thrown away
> * Before the page is written back to the store, the page is acquired again.
> As a result, an older copy of the page is brought back to memory, which
> causes all kinds of corruption exceptions and assertions.
>
> checkpointReadLock() may hang during node stop
> I got this hang during one of PDS (Indexing) runs (thread-dump is attached).
> The following code hang:
> {code:java}
> checkpointer.wakeupForCheckpoint(0, "too many dirty pages").cpBeginFut
> .getUninterruptibly();
> {code}
> It looks like {{wakeupForCheckpoint}} can be called after the checkpointer is
> stopped and {{cpBeginFut}} will be never completed.
>
> Fixed
> ZookeeperDiscoveryCommunicationFailureTest.testCommunicationFailureResolve_CachesInfo1
> Fixed *.testFailAfterStart
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Assigned] (IGNITE-12048) Bugs & tests fixes
[
https://issues.apache.org/jira/browse/IGNITE-12048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Govorukhin reassigned IGNITE-12048:
---
Assignee: Dmitriy Govorukhin
> Bugs & tests fixes
> --
>
> Key: IGNITE-12048
> URL: https://issues.apache.org/jira/browse/IGNITE-12048
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Major
>
> Page replacement can reload invalid page during checkpoint
> There is a race between {{writeCheckpointPages}} and page replacement process:
> * Checkpointer thread begins a checkpoint
> * Checkpointer thread calls {{getPageForCheckpoint()}}, which will copy page
> content *and clear dirty flag*
> * Page replacement tries to find a page for replacement and chooses this
> page, the page is thrown away
> * Before the page is written back to the store, the page is acquired again.
> As a result, an older copy of the page is brought back to memory, which
> causes all kinds of corruption exceptions and assertions.
>
> checkpointReadLock() may hang during node stop
> I got this hang during one of PDS (Indexing) runs (thread-dump is attached).
> The following code hang:
> {code:java}
> checkpointer.wakeupForCheckpoint(0, "too many dirty pages").cpBeginFut
> .getUninterruptibly();
> {code}
> It looks like {{wakeupForCheckpoint}} can be called after the checkpointer is
> stopped and {{cpBeginFut}} will be never completed.
>
> Fixed
> ZookeeperDiscoveryCommunicationFailureTest.testCommunicationFailureResolve_CachesInfo1
> Fixed *.testFailAfterStart
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (IGNITE-12048) Bugs & tests fixes
[
https://issues.apache.org/jira/browse/IGNITE-12048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Govorukhin updated IGNITE-12048:
Ignite Flags: (was: Docs Required)
> Bugs & tests fixes
> --
>
> Key: IGNITE-12048
> URL: https://issues.apache.org/jira/browse/IGNITE-12048
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.8
>
>
> Page replacement can reload invalid page during checkpoint
> There is a race between {{writeCheckpointPages}} and page replacement process:
> * Checkpointer thread begins a checkpoint
> * Checkpointer thread calls {{getPageForCheckpoint()}}, which will copy page
> content *and clear dirty flag*
> * Page replacement tries to find a page for replacement and chooses this
> page, the page is thrown away
> * Before the page is written back to the store, the page is acquired again.
> As a result, an older copy of the page is brought back to memory, which
> causes all kinds of corruption exceptions and assertions.
>
> checkpointReadLock() may hang during node stop
> I got this hang during one of PDS (Indexing) runs (thread-dump is attached).
> The following code hang:
> {code:java}
> checkpointer.wakeupForCheckpoint(0, "too many dirty pages").cpBeginFut
> .getUninterruptibly();
> {code}
> It looks like {{wakeupForCheckpoint}} can be called after the checkpointer is
> stopped and {{cpBeginFut}} will be never completed.
>
> Fixed
> ZookeeperDiscoveryCommunicationFailureTest.testCommunicationFailureResolve_CachesInfo1
> Fixed *.testFailAfterStart
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (IGNITE-12047) senderNodeId is absent in StatusCheckMessage
[
https://issues.apache.org/jira/browse/IGNITE-12047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901995#comment-16901995
]
Denis Chudov commented on IGNITE-12047:
---
[~akalashnikov] could you review this fix please?
> senderNodeId is absent in StatusCheckMessage
>
>
> Key: IGNITE-12047
> URL: https://issues.apache.org/jira/browse/IGNITE-12047
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Chudov
>Assignee: Denis Chudov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> TcpDiscoveryCoordinatorFailureTest.testClusterFailedNewCoordinatorInitialized
> {code:java}
> [2019-07-29
> 02:42:11,609][ERROR][tcp-disco-sock-reader-[]-#21611%tcp.TcpDiscoveryCoordinatorFailureTest4%][TcpDiscoverySpi]
> Failed to initialize connection (this can happen due to short time network
> problems and can be ignored if does not affect node discovery)
> [sock=Socket[addr=/127.0.0.1,port=44033,localport=47504]]
> java.net.SocketTimeoutException: Read timed out at
> java.net.SocketInputStream.socketRead0(Native Method) at
> java.net.SocketInputStream.socketRead(SocketInputStream.java:116) at
> java.net.SocketInputStream.read(SocketInputStream.java:171) at
> java.net.SocketInputStream.read(SocketInputStream.java:141) at
> java.io.BufferedInputStream.fill(BufferedInputStream.java:246) at
> java.io.BufferedInputStream.read1(BufferedInputStream.java:286) at
> java.io.BufferedInputStream.read(BufferedInputStream.java:345) at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$SocketReader.body(ServerImpl.java:6464)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:60)
> Exception in thread
> "disco-pool-#62924%tcp.TcpDiscoveryCoordinatorFailureTest4%" Exception in
> thread "disco-pool-#62925%tcp.TcpDiscoveryCoordinatorFailureTest4%"
> java.lang.AssertionError at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.pingNode(ServerImpl.java:723)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.access$4000(ServerImpl.java:195)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker$8.run(ServerImpl.java:5598)
> 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) java.lang.AssertionError at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.pingNode(ServerImpl.java:723)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.access$4000(ServerImpl.java:195)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker$8.run(ServerImpl.java:5598)
> 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)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (IGNITE-12047) senderNodeId is absent in StatusCheckMessage
[
https://issues.apache.org/jira/browse/IGNITE-12047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901994#comment-16901994
]
Ignite TC Bot commented on IGNITE-12047:
{panel:title=Branch: [pull/6753/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4472168buildTypeId=IgniteTests24Java8_RunAll]
> senderNodeId is absent in StatusCheckMessage
>
>
> Key: IGNITE-12047
> URL: https://issues.apache.org/jira/browse/IGNITE-12047
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Chudov
>Assignee: Denis Chudov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> TcpDiscoveryCoordinatorFailureTest.testClusterFailedNewCoordinatorInitialized
> {code:java}
> [2019-07-29
> 02:42:11,609][ERROR][tcp-disco-sock-reader-[]-#21611%tcp.TcpDiscoveryCoordinatorFailureTest4%][TcpDiscoverySpi]
> Failed to initialize connection (this can happen due to short time network
> problems and can be ignored if does not affect node discovery)
> [sock=Socket[addr=/127.0.0.1,port=44033,localport=47504]]
> java.net.SocketTimeoutException: Read timed out at
> java.net.SocketInputStream.socketRead0(Native Method) at
> java.net.SocketInputStream.socketRead(SocketInputStream.java:116) at
> java.net.SocketInputStream.read(SocketInputStream.java:171) at
> java.net.SocketInputStream.read(SocketInputStream.java:141) at
> java.io.BufferedInputStream.fill(BufferedInputStream.java:246) at
> java.io.BufferedInputStream.read1(BufferedInputStream.java:286) at
> java.io.BufferedInputStream.read(BufferedInputStream.java:345) at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$SocketReader.body(ServerImpl.java:6464)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:60)
> Exception in thread
> "disco-pool-#62924%tcp.TcpDiscoveryCoordinatorFailureTest4%" Exception in
> thread "disco-pool-#62925%tcp.TcpDiscoveryCoordinatorFailureTest4%"
> java.lang.AssertionError at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.pingNode(ServerImpl.java:723)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.access$4000(ServerImpl.java:195)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker$8.run(ServerImpl.java:5598)
> 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) java.lang.AssertionError at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.pingNode(ServerImpl.java:723)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.access$4000(ServerImpl.java:195)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker$8.run(ServerImpl.java:5598)
> 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)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (IGNITE-12042) Atempt to remove entries from fully populated data region may result in IgineOutOfMemoryException
[ https://issues.apache.org/jira/browse/IGNITE-12042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-12042: - Ignite Flags: (was: Docs Required) > Atempt to remove entries from fully populated data region may result in > IgineOutOfMemoryException > - > > Key: IGNITE-12042 > URL: https://issues.apache.org/jira/browse/IGNITE-12042 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Vyacheslav Koptilin >Assignee: Vyacheslav Koptilin >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Removing entries from non-persistent data region may require allocating a new > data page in order to move a tracked page from one bucket of the free-list to > another one. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Assigned] (IGNITE-12045) [IEP-35] JmxExporterSpi has too broad name.
[
https://issues.apache.org/jira/browse/IGNITE-12045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov reassigned IGNITE-12045:
Assignee: Nikolay Izhikov
> [IEP-35] JmxExporterSpi has too broad name.
> ---
>
> Key: IGNITE-12045
> URL: https://issues.apache.org/jira/browse/IGNITE-12045
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey Gura
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-35
> Fix For: 2.8
>
>
> {{JmxExporterSpi}} has too broad name. It should be renamed to
> {{JmxMetricExporterSpi}}.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (IGNITE-11470) Views don't show in Dbeaver
[
https://issues.apache.org/jira/browse/IGNITE-11470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901943#comment-16901943
]
Ignite TC Bot commented on IGNITE-11470:
{panel:title=Branch: [pull/6456/head] Base: [master] : Possible Blockers
(25)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}MVCC PDS 4{color} [[tests
14|https://ci.ignite.apache.org/viewLog.html?buildId=3764109]]
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_10_500_8_16
- New test duration 101s is more that 1 minute
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_10_10_1_1
- New test duration 101s is more that 1 minute
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_1000_2_8_16
- New test duration 104s is more that 1 minute
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_8000_8000_8_16
- New test duration 114s is more that 1 minute
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_1000_500_1_1
- New test duration 100s is more that 1 minute
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_8000_8000_1_1
- New test duration 111s is more that 1 minute
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_1000_500_8_16
- New test duration 102s is more that 1 minute
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_8000_8000_8_1
- New test duration 106s is more that 1 minute
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_8000_500_8_1
- New test duration 114s is more that 1 minute
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_8000_500_1_1
- New test duration 113s is more that 1 minute
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_1000_2_1_1
- New test duration 104s is more that 1 minute
... and 3 tests blockers
{color:#d04437}Queries 1{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=3767637]]
* IgniteBinaryCacheQueryTestSuite:
IgniteSqlNotNullConstraintTest.testReadThroughRestrictionAlterTable - Test has
low fail rate in base branch 0,0% and is not flaky
* IgniteBinaryCacheQueryTestSuite:
IgniteSqlNotNullConstraintTest.testReadThroughRestrictionCreateTable - Test has
low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Platform .NET{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3764083]]
* exe: PartitionLossTest.TestReadOnlySafe - Test has low fail rate in base
branch 0,0% and is not flaky
{color:#d04437}ZooKeeper (Discovery) 3{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=3764091]]
* ZookeeperDiscoverySpiTestSuite3:
GridEventConsumeSelfTest.testMultithreadedWithNodeRestart - Test has low fail
rate in base branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite3: GridEventConsumeSelfTest.testApiAsync - Test
has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Cache 2{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3767629]]
* IgniteCacheTestSuite2: cache.CacheExchangeMessageDuplicatedStateTest -
History for base branch is absent.
{color:#d04437}MVCC PDS 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3764106]]
* IgnitePdsMvccTestSuite:
IgniteClusterActivateDeactivateTestWithPersistence.testDeactivateDuringEvictionAndRebalance
- Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}[Check Code Style]{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=4475653]]
{color:#d04437}JDBC Driver{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3781208]]
{color:#d04437}~Build Apache Ignite~{color} [[tests 0 Exit Code , Compilation
Error |https://ci.ignite.apache.org/viewLog.html?buildId=4475540]]
{color:#d04437}[Javadoc]{color} [[tests 0 Exit Code , Compilation Error
|https://ci.ignite.apache.org/viewLog.html?buildId=4475591]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4475654buildTypeId=IgniteTests24Java8_RunAll]
> Views don't show in Dbeaver
> ---
>
> Key: IGNITE-11470
> URL: https://issues.apache.org/jira/browse/IGNITE-11470
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority:
[jira] [Updated] (IGNITE-11881) Spark Data Frame examples not working
[ https://issues.apache.org/jira/browse/IGNITE-11881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-11881: -- Fix Version/s: 2.8 > Spark Data Frame examples not working > - > > Key: IGNITE-11881 > URL: https://issues.apache.org/jira/browse/IGNITE-11881 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Blocker > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > # Spark Data Frames examples fail. > # Spark Data Frame examples don't execute on TC. > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (IGNITE-11881) Spark Data Frame examples not working
[ https://issues.apache.org/jira/browse/IGNITE-11881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-11881: -- Ignite Flags: (was: Docs Required) > Spark Data Frame examples not working > - > > Key: IGNITE-11881 > URL: https://issues.apache.org/jira/browse/IGNITE-11881 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Blocker > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > # Spark Data Frames examples fail. > # Spark Data Frame examples don't execute on TC. > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (IGNITE-5714) Implementation of suspend/resume for pessimistic transactions
[
https://issues.apache.org/jira/browse/IGNITE-5714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901936#comment-16901936
]
Ignite TC Bot commented on IGNITE-5714:
---
{panel:title=Branch: [pull/6483/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4471188buildTypeId=IgniteTests24Java8_RunAll]
> Implementation of suspend/resume for pessimistic transactions
> -
>
> Key: IGNITE-5714
> URL: https://issues.apache.org/jira/browse/IGNITE-5714
> Project: Ignite
> Issue Type: Sub-task
> Components: general
>Reporter: Alexey Kuznetsov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: iep-34
> Time Spent: 4.5h
> Remaining Estimate: 0h
>
> Support transaction suspend()\resume() operations for pessimistic
> transactions. Resume can be called in another thread.
>_+But there is a problem+_: Imagine, we started pessimistic transaction in
> thread T1 and then perform put operation, which leads to sending
> GridDistributedLockRequest to another node. Lock request contains thread id
> of the transaction. Then we call suspend, resume in another thread and we
> also must send messages to other nodes to change thread id.
> It seems complicated task.It’s better to get rid of sending thread id to the
> nodes.
> We can use transaction xid on other nodes instead of thread id. Xid is sent
> to nodes in GridDistributedLockRequest#nearXidVer
>_+Proposed solution+_ : On remote nodes instead of thread id of near
> transaction GridDistributedLockRequest#threadId use its xid
> GridDistributedLockRequest#nearXidVer.
> Remove usages of near transaction's thread id on remote nodes.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (IGNITE-5714) Implementation of suspend/resume for pessimistic transactions
[
https://issues.apache.org/jira/browse/IGNITE-5714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901935#comment-16901935
]
Aleksey Plekhanov commented on IGNITE-5714:
---
[~gvvinblade],
As far as I understand {{TxFinishSync}} was introduced to avoid problems with
locks intersection (by {{threadId}} in {{GridCacheMvccCandidate}}) between two
transactions started by the same thread. This problem affects only pessimistic
transactions.
After this patch explicit pessimistic transactions will use locking by
{{GridCacheVersion}} (not by {{threadId}} as before). There is no intersection
by {{threadId}} anymore and {{TxFinishSync}} is not needed.
Implicit pessimistic transactions can only be created if MVCC is enabled. But
when MVCC is enabled another locking mechanism is used (instead of
{{GridCacheMvccCandidate}} a {{DataRow}} is used to store locks information and
there is no intersection by {{threadId}}). For these transaction types
{{TxFinishSync}} is not needed too.
So, {{TxFinishSync}} can be safely removed.
If we will use thread-local {{GridCacheVersion}} for explicit locks we also
need to use the same {{GridCacheVersion}} for implicit transactions. This
brings additional complexity to the code and new risks. I propose to keep
{{threadId}} as holder for explicit lock/implicit tx for now. This doesn't
block anything and can be fixed by another ticket (there is already such
[ticket|https://issues.apache.org/jira/browse/IGNITE-8389] created).
I've removed {{TxFinishSync}} and prepared the new patch, please have a look.
> Implementation of suspend/resume for pessimistic transactions
> -
>
> Key: IGNITE-5714
> URL: https://issues.apache.org/jira/browse/IGNITE-5714
> Project: Ignite
> Issue Type: Sub-task
> Components: general
>Reporter: Alexey Kuznetsov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: iep-34
> Time Spent: 4.5h
> Remaining Estimate: 0h
>
> Support transaction suspend()\resume() operations for pessimistic
> transactions. Resume can be called in another thread.
>_+But there is a problem+_: Imagine, we started pessimistic transaction in
> thread T1 and then perform put operation, which leads to sending
> GridDistributedLockRequest to another node. Lock request contains thread id
> of the transaction. Then we call suspend, resume in another thread and we
> also must send messages to other nodes to change thread id.
> It seems complicated task.It’s better to get rid of sending thread id to the
> nodes.
> We can use transaction xid on other nodes instead of thread id. Xid is sent
> to nodes in GridDistributedLockRequest#nearXidVer
>_+Proposed solution+_ : On remote nodes instead of thread id of near
> transaction GridDistributedLockRequest#threadId use its xid
> GridDistributedLockRequest#nearXidVer.
> Remove usages of near transaction's thread id on remote nodes.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (IGNITE-11899) Fix code style violation
[
https://issues.apache.org/jira/browse/IGNITE-11899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-11899:
--
Fix Version/s: 2.8
> Fix code style violation
>
>
> Key: IGNITE-11899
> URL: https://issues.apache.org/jira/browse/IGNITE-11899
> Project: Ignite
> Issue Type: Bug
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> All the code style issues must be fixed, see the sample below.
> {code}
> [09:38:03][Step 2/2] [ERROR]
> /opt/buildagent/work/69588afcb2ab3382/modules/core/src/main/java/org/apache/ignite/internal/commandline/diagnostic/PageLocksCommand.java:50:
> 'VARIABLE_DEF' should be separated from previous statement.
> [EmptyLineSeparator]
> [09:38:03][Step 2/2] [ERROR]
> /opt/buildagent/work/69588afcb2ab3382/modules/core/src/main/java/org/apache/ignite/internal/commandline/diagnostic/PageLocksCommand.java:183:
> 'VARIABLE_DEF' should be separated from previous statement.
> [EmptyLineSeparator]
> [09:38:03][Step 2/2] [ERROR]
> /opt/buildagent/work/69588afcb2ab3382/modules/core/src/main/java/org/apache/ignite/internal/commandline/diagnostic/PageLocksCommand.java:187:
> 'VARIABLE_DEF' should be separated from previous statement.
> [EmptyLineSeparator]
> [09:38:03][Step 2/2] [ERROR]
> /opt/buildagent/work/69588afcb2ab3382/modules/core/src/main/java/org/apache/ignite/internal/commandline/diagnostic/PageLocksCommand.java:191:
> 'VARIABLE_DEF' should be separated from previous statement.
> [EmptyLineSeparator]
> {code}
> TC log:
> https://ci.ignite.apache.org/viewLog.html?buildId=4062737=IgniteTests24Java8_CheckCodeStyle=buildLog_IgniteTests24Java8=%3Cdefault%3E
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (IGNITE-12026) DOC: JavaDoc for MemoryEventStorageSpi contains incorrect example
[ https://issues.apache.org/jira/browse/IGNITE-12026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-12026: -- Ignite Flags: (was: Docs Required) > DOC: JavaDoc for MemoryEventStorageSpi contains incorrect example > - > > Key: IGNITE-12026 > URL: https://issues.apache.org/jira/browse/IGNITE-12026 > Project: Ignite > Issue Type: Bug > Components: documentation >Affects Versions: 2.7.5 >Reporter: Andrey Aleksandrov >Assignee: Roman Shtykh >Priority: Major > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > h2. Spring Example > MemoryEventStorageSpi can be configured from Spring XML configuration file: > class="org.apache.ignite.configuration.IgniteConfiguration" singleton="true"> > ... > > class="org.apache.ignite.spi.eventStorage.memory.MemoryEventStorageSpi"> > > > > ... > > > But MemoryEventStorageSpi can't be applied to discoverySpi. It should be > "eventStorageSpi" > > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (IGNITE-12004) CacheQueryEntityWithDateTimeApiFieldsTest.testUpdateAllFields is flaky
[ https://issues.apache.org/jira/browse/IGNITE-12004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-12004: -- Ignite Flags: (was: Docs Required) > CacheQueryEntityWithDateTimeApiFieldsTest.testUpdateAllFields is flaky > -- > > Key: IGNITE-12004 > URL: https://issues.apache.org/jira/browse/IGNITE-12004 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.7.5 >Reporter: Ivan Pavlukhin >Assignee: Ivan Pavlukhin >Priority: Major > Fix For: 2.8 > > Time Spent: 40m > Remaining Estimate: 0h > > CacheQueryEntityWithDateTimeApiFieldsTest.testUpdateAllFields fails often > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-4227647830422954979=testDetails -- This message was sent by Atlassian JIRA (v7.6.14#76016)
