Uploaded image for project: 'JBoss Enterprise Application Platform'
  1. JBoss Enterprise Application Platform
  2. JBEAP-4225

Possible lost message over Failover/Failback using regular JMS Transactions

    Details

    • Target Release:
    • Steps to Reproduce:
      Hide

      run tests from JBEAP-3998 over and over.. it can fail randomly taking up to 50 runs to be replicated. (what would happen in around 3 hours)

      Show
      run tests from JBEAP-3998 over and over.. it can fail randomly taking up to 50 runs to be replicated. (what would happen in around 3 hours)
    • Affects:
      Release Notes
    • Release Notes Docs Status:
      Documented as Known Issue
    • Sprint:
      EAP 7.0.1

      Description

      We found this issue over repeated tests on JBEAP-3998:

      The Message Consumer has a list of delivered messages on both client and server.

      When the message is received, the client will send an ACK to the server.

      This ACK could ACK any previously received message.

      Apparently that is making a previously received message to be acked and committed on the server as it was stored normally on the journal.

      For some reason when using a LargeMessage over Paging and during a failback this list got out of sync and the client acknowledged more messages than it actually received, leading to a possible loss.

      Notice that this doesn't affect MDBs since MDBs are always using individual ack, so scenarios where XA and MDBs are involved wouldn't be affected.

      Also, this is not exclusive to replication, and it's not exclusive to Artemis. I can see the same issue happening on HornetQ and EAP6 as well.

      Expected state: JMS standalone client can ACK messages in batches and no message is lost.
      Actual state: When JMS standalone client ACK messages in batches some messages can be lost.
      Customer impact: Usage of JMS standalone client with acking in batches can lead to lost messages.

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  clebert.suconic Clebert Suconic
                  Reporter:
                  clebert.suconic Clebert Suconic
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  4 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: