Uploaded image for project: 'Spring Framework'
  1. Spring Framework
  2. SPR-7883

DefaultMessageListenerContainer loses messages

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Invalid
    • Affects Version/s: 2.5.6
    • Fix Version/s: None
    • Component/s: JMS
    • Labels:
      None
    • Last commented by a User:
      false

      Description

      When using a transaction manager with a non-durable subscription, messages are lost. Because the consumer isn't cached, Spring is opening/closing the subscription continually, in essence creating new subscriptions each time.

      An overview of what's happening:
      -DefaultmessageListenerContainer.initalize(): with a transaction manager, the cache level is set to CACHE_NONE
      -AbstractJmsListeningContainer.doStart() - does not create shared connections based on cache level
      -DefaultMessageListenerContainer.executeOngoingLoop() - controlling loop that executes while the container is active
      -AbstractPollingMessageListenerContainer.doReceiveAndExecute() - attempts to receive a single message from the topic, calls the listener, and returns.

      Because of the cache level, AbstractPollingMessageListenerContainer.doReceiveAndExecute() creates a new connection and new session before polling the messaging platform. After receiving a message (and calling the listener) or timing out (no message available), the session and connection are closed and the method returns. Only a single message is read in any one call.

      Because the subscription ceases to exist once everything is closed, there are two possible scenarios for lost messages:
      1) Additional messages are published while the listener is executing. Once the listener consumers the message, the session/connection are closed. When a non-durable subscription is closed, any messages unconsumed are lost, and therefore lost.
      2) Additional messages published while the listener is not subscribed (i.e., between calls to doReceiveAndExecute()). There is no subscription and therefore the published messages just go to the bit bucket.

        Activity

        Hide
        scsosna Scott C. Sosna added a comment -

        Same results with ActiveMQ

        Show
        scsosna Scott C. Sosna added a comment - Same results with ActiveMQ
        Hide
        mzruya Matan Zruya added a comment -

        seeing a similar behavior in high loads, using apollomq,
        letting DMLC manage it's own JMS transaction, in high loads, a broker get's an ack for a msg, but the container doesn't dispatch it to it's listener

        Show
        mzruya Matan Zruya added a comment - seeing a similar behavior in high loads, using apollomq, letting DMLC manage it's own JMS transaction, in high loads, a broker get's an ack for a msg, but the container doesn't dispatch it to it's listener
        Hide
        snicoll Stéphane Nicoll added a comment -

        I think you basically found the answer yourself: if you chose to avoid caching you essentially get that issue because the container acts as a JMS client that connects over and over again (vs. a cached connection that is reused). It seems to be a documentation problem mostly.

        Would you agree or is there something that I am missing?

        Show
        snicoll Stéphane Nicoll added a comment - I think you basically found the answer yourself: if you chose to avoid caching you essentially get that issue because the container acts as a JMS client that connects over and over again (vs. a cached connection that is reused). It seems to be a documentation problem mostly. Would you agree or is there something that I am missing?
        Hide
        snicoll Stéphane Nicoll added a comment -

        Updated the documentation to reflect what can happen when cache is disabled on a non durable topic subscriber.

        Show
        snicoll Stéphane Nicoll added a comment - Updated the documentation to reflect what can happen when cache is disabled on a non durable topic subscriber.

          People

          • Assignee:
            snicoll Stéphane Nicoll
            Reporter:
            scsosna Scott C. Sosna
            Last updater:
            Stéphane Nicoll
          • Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              Days since last comment:
              3 years, 35 weeks, 1 day ago