Announcement Announcement Module
Collapse
No announcement yet.
Deadlock polling on QueueChannels backed by the same messagestore Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Deadlock polling on QueueChannels backed by the same messagestore

    Hi,

    I'm starting to get some DeadlockLoserDataAccessException when two bridges polls on theirs respective queue channels, backed by the same message store.

    Excerpt from the application context:

    Code:
    <!-- === Message Store === -->
    
    <int-jdbc:message-store
    	id="message-store" 
    	data-source="dataSource" 
    	region="${integration.messagestore.region}" />
    
    
    <!-- === Channels === -->
    
    <int:channel id="documentation-channel">
        <int:queue message-store="message-store" />
    </int:channel>
    
    <int:channel id="business-outbound-clienteconfermato-notification-channel">
    	<int:queue message-store="message-store" />
    </int:channel>
    
    <!-- === Bridges === -->
    
    <int:bridge 
        id="documentationBridge"
        input-channel="documentation-channel"
        output-channel="kfiles-channel"
        auto-startup="${integration.sap...bridge.auto-startup}">
    	
        <int:poller 
            cron="${integration.sap...bridge.poller.cron}"
            max-messages-per-poll="${integration.sap...bridge.poller.max-messages-per-poll}">
            <int:transactional transaction-manager="transactionManager" />
        </int:poller>
    
    </int:bridge>
    
    <int:bridge 
        id="clienteconfermatoNotificationBridge"
        input-channel="business-outbound-clienteconfermato-notification-channel"
        output-channel="business-outbound-clienteconfermato-prepare-channel"
        auto-startup="${integration.business...bridge.auto-startup}">
    	
        <int:poller 
            cron="${integration.business...bridge.poller.cron}"
            max-messages-per-poll="${integration.business...bridge.poller.max-messages-per-poll}">
            <int:transactional transaction-manager="transactionManager" />
        </int:poller>
    
    </int:bridge>
    This is setup plain wrong or dangerous? I'm tempted to define a new message store with its own region or its own table, but I would like to understand the context.

    Any help or suggestion will be deeply appreciated.

    Thank you,
    Maurizio

  • #2
    What version of Spring Integration you are using?
    Also, is it possible for you to upgrade to the latest snapshot (2.2.0.BUILD-SNAPSHOT) just to see if you are still getting this problem. A lot has been changed there (new schemas and lots of optimizations especially for polling of messages)

    Comment


    • #3
      Hi,
      we're currently using Spring Integration 2.1.0 and upgrading to 2.1.1 with the next deploy.

      We could re-create the workload the caused the deadlock with 2.1.1 and then try with the latest snapshot of 2.2.0 release. I'll post here the results.

      Maurizio

      Comment


      • #4
        I say skip 2.1.1. The changes I am referring to were just committed yesterday and are available in 2.2.0.BUILD-SNAPSHOT and are directly related to message polling from JdbcMessageStore

        Comment


        • #5
          Just to clarify, if you are using this in a production app, please do NOT use the milestone or snapshot. If on the other hand you are still in development, we would highly recommend using 2.2 as it evolves so you can provide feedback along the way.

          Comment


          • #6
            That is essentially what I meant. The JdbcMessageStore refactoring changes just went in and will be available with M2 coming out in few weeks. However M2 would still not be a production grade release, but giving it a try now will give us immediate feedback if it addressed your issue.

            Comment


            • #7
              We are now in production with 2.1.x stable series and I will stick to the stable releases, for sure! ;-)

              I would try the 2.2.x development release to prepare the future iterations of the app. I can confirm that the 2.2.0 M1 release is still affected, and I'm going to try the snapshot build.

              I'll report the result here, thank you!

              Use different message stores and tables is the way to go to mitigate the problem?

              Comment


              • #8
                I think if you just use two different regions for tow instances of MS you should be fine for the time being. But please let us now if you still see the same problem with snapshot.

                Comment


                • #9
                  The problem seems gone away with the 2.2.0 snapshot build. I've pulled the latest snapshot from master and built from source today.

                  Two instances of the message store with different regions are working fine with 2.1.1 also.

                  Thank you!

                  Comment


                  • #10
                    That's a great news and fist validation that what we did in 2.2 is the right thing, so Thank you!

                    Comment

                    Working...
                    X