[
https://issues.apache.org/jira/browse/IGNITE-21800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy updated IGNITE-21800:
---------------------------------------
Description:
java.lang.AssertionError: Expected: <[trailblazer, first, second]> but: was
<[trailblazer, second, first]>
java.lang.AssertionError:
Expected: <[trailblazer, first, second]>
but: was <[trailblazer, second, first]>
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
at
org.apache.ignite.internal.network.scalecube.ItScaleCubeNetworkMessagingTest.messagesQueuedOnFullyClosedOldChannelGetDeliveredAfterReconnection(ItScaleCubeNetworkMessagingTest.java:769)
It seems shaky that NettySender.send() does a direct send if called from a
Netty thread while it puts a sending job to the event loop executor if called
from another thread. Such differences might account for reorderings.
On the other hand, in the production code NettySender.send() calls from a Netty
thread always happen before calls from other threads, and they invoke the send
directly, so this does not to seem to cause reorderings in the production code.
Probably the problem is with the test: 'first' send happens directly through an
established NettySender from the 'main' thread, so it submits a send task; but
'second' send triggers creation of another sender (because first sender is not
yet in the internal maps, so second send does not see it due to this race).
Probably a race happens further. This needs to be investigated.
Also, we should think about making NettySender.send() always submit a task
(even when called from a Netty thread).
> ItScaleCubeNetworkMessagingTest.messagesQueuedOnFullyClosedOldChannelGetDeliveredAfterReconnection(true)
> is flaky
> -----------------------------------------------------------------------------------------------------------------
>
> Key: IGNITE-21800
> URL: https://issues.apache.org/jira/browse/IGNITE-21800
> Project: Ignite
> Issue Type: Bug
> Reporter: Roman Puchkovskiy
> Priority: Major
> Labels: ignite-3
>
> java.lang.AssertionError: Expected: <[trailblazer, first, second]> but: was
> <[trailblazer, second, first]>
> java.lang.AssertionError:
> Expected: <[trailblazer, first, second]>
> but: was <[trailblazer, second, first]>
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
> at
> org.apache.ignite.internal.network.scalecube.ItScaleCubeNetworkMessagingTest.messagesQueuedOnFullyClosedOldChannelGetDeliveredAfterReconnection(ItScaleCubeNetworkMessagingTest.java:769)
>
> It seems shaky that NettySender.send() does a direct send if called from a
> Netty thread while it puts a sending job to the event loop executor if called
> from another thread. Such differences might account for reorderings.
>
> On the other hand, in the production code NettySender.send() calls from a
> Netty thread always happen before calls from other threads, and they invoke
> the send directly, so this does not to seem to cause reorderings in the
> production code.
>
> Probably the problem is with the test: 'first' send happens directly through
> an established NettySender from the 'main' thread, so it submits a send task;
> but 'second' send triggers creation of another sender (because first sender
> is not yet in the internal maps, so second send does not see it due to this
> race). Probably a race happens further. This needs to be investigated.
>
> Also, we should think about making NettySender.send() always submit a task
> (even when called from a Netty thread).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
