[jboss-jira] [JBoss JIRA] (JGRP-1644) NAKACK2 violates FIFO property

[Vadim Tsesko (JIRA)]

    [ https://issues.jboss.org/browse/JGRP-1644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781733#comment-12781733 ] 

Vadim Tsesko commented on JGRP-1644:
------------------------------------

Unfortunately, I couldn't reproduce the issue using MPerf with 4MB messages. It appears only in the production code. The bug is reproduced about once per 20-30 minutes: exactly two messages are reordered. 2 producers and 3 consumers are located in separate datacenters.
I used to tag messages as OOB, but quickly fixed it. Yes, I am sending messages from one dedicated thread -- this idea also came to my mind. With `NAKACK` the problem can't be reproduced (I am monitoring the system all day long).
By the way, I have managed to notice the same bug using {{NAKACK2}} and TCP-based transport with the following config:
{code:xml}
<config xmlns="urn:org:jgroups"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/JGroups-3.3.xsd">
    <TCP bind_addr="$ip"
         bind_port="$port"
         client_bind_addr="$ip"

         singleton_name="tcp-transport"/>

    <TCPGOSSIP initial_hosts="$seed"/>

    <MERGE3/>

    <FD_SOCK/>

    <FD/>

    <VERIFY_SUSPECT/>

    <BARRIER/>

    <pbcast.NAKACK2 use_mcast_xmit="false"/>

    <UNICAST3/>

    <pbcast.STABLE/>

    <pbcast.GMS/>

    <FRAG2/>
</config>
{code}
But it appeared only once in the production cluster with 40 machines in 3 datacenters.
                
> NAKACK2 violates FIFO property
> ------------------------------
>
>                 Key: JGRP-1644
>                 URL: https://issues.jboss.org/browse/JGRP-1644
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3.1
>         Environment: Ubuntu 12.04 LTS, kernel 3.2.0-24-generic #39-Ubuntu SMP Mon May 21 16:52:17 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux, Java 1.7.0_21
>            Reporter: Vadim Tsesko
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> In the [documentation documentation|http://www.jgroups.org/manual/html/protlist.html#ReliableMessageTransmission] it is stated that:
> {quote}
> NAKACK provides reliable delivery and FIFO (= First In First Out) properties for messages sent to all nodes in a cluster.
> {quote}
> and
> {quote}
> NAKACK2 was introduced in 3.1 and is a successor to NAKACK (at some point it will replace NAKACK). It has the same properties as NAKACK, but its implementation is faster and uses less memory, plus it creates fewer tasks in the timer.
> {quote}
> I have observed that sometimes multicast messages are received out of order.
> We use the following protocol stack configuration:
> {code:xml}
> <config xmlns="urn:org:jgroups"
>         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>         xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/JGroups-3.3.xsd">
>     <UDP bind_addr="match-interface:$interface"
>          bind_interface="$interface"
>          bind_port="$unicastPort"
>          ip_ttl="128"
>          mcast_addr="$multicastGroup"
>          mcast_port="$multicastPort"
>          singleton_name="udp-transport"/>
>     <PING return_entire_cache="true"
>           break_on_coord_rsp="false"/>
>     <MERGE3/>
>     <FD_SOCK/>
>     <FD_ALL/>
>     <VERIFY_SUSPECT/>
>     <BARRIER/>
>     <pbcast.NAKACK print_stability_history_on_failed_xmit="true"/>
>     <pbcast.STABLE/>
>     <pbcast.GMS/>
>     <MFC max_credits="8M"/>
>     <FRAG2/>
>     <RSVP/>
> </config>
> {code}
> As you can see, mostly we use the defaults.
> The messages are being sent from a single thread using the following code:
> {code:java}
> channel.send(new Message(null, msg))
> {code}
> Each message has size from 300 KB up to 4 MB. The message rate is 1-5 messages per second.
> We have a sequential counter inside each message being sent. Sometimes the messages are received out of order, for instance:
> {code}
> #1198
> #1199
> #1200
> #1202
> #1201
> #1203
> #1204
> {code}
> If we replace {{NAKACK2}} by {{NAKACK}} the problem disappears -- everything works as expected (FIFO).
> If we replace JGroups-based transport by ZeroMQ-based transport (actually running over EPGM and being used for a year) everything works as expected (FIFO) -- just to let you know, that there are no bugs in out message numbering logic.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira