Announcement Announcement Module
No announcement yet.
Spring Integration deadlock issue - 1.0.3.RELEASE Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring Integration deadlock issue - 1.0.3.RELEASE

    On the my current project we are heavily using Spring Integration to process and transform very large amounts of data. Spring Integration has proved successful except in a rare instance where we find that the system deadlocks after about 7 days of operation. Basically the default poller stops polling for the transformers. A separate multi-threaded poller is still operating as expected.

    <integrationoller id="poller" default="true">
    <integration:interval-trigger interval="100" />

    I have analysed the source code and the issue seems to stem from the main task-scheduler (poller) giving up scheduling after many days of operation. Doing a kill –QUIT on the application suggests that the threads associated with the task scheduler thread pool have been closed down.

    One observation is that the ids for the threads associated with the thread executor are constantly increasing. This was tracked back the fact that we have many polled components needing more than the default 100 threads in the thread pool. Going forward I have introduced our own custom task executor with a pool size of 200 and added debug to all method calls. However, not only does this generate a huge amount of debug, but we also have to wait 7 days for any information!

    Is anyone aware of a known issue with Spring Integration which would help explain this issue?

    Spring Integration Version: 1.0.3.RELEASE

    Many thanks for your support.

  • #2
    Any chance you can upgrade to SI 2.0.1? THere were significant upgrades and improvements with regard to task scheduling (e.g., relying on Spring 3.0 task support).
    Also, you may want to at least upgrade to 1.0.4 since that is the latest release of 1.0 branch


    • #3
      Hi Oleg,

      Many thanks for your prompt reply. Unfortunately upgrading would be non-trivial as we about to go live after many months testing.

      Further, we have some custom changes to the spring aggregator to do with a previous bug with messages timing out and being lost. We also have our own own namespace which is integrated with Spring Integration's bean definition parser so I would expect quite a bit of work for such a major upgrade.

      If there were a known issue I could reference then perhaps I could patch it or would be able to justify the upgrade. The fear is we upgrade and see other issues/the issue is not resolved.

      Many thanks again,



      • #4
        Unfortunately I don't know of any issue and based on your explanation (7 days) it will definitely be a very hard thing to track.

        I would say at least upgrade to 1.0.4 which should be trivial and see if the problem is still there.