Announcement Announcement Module
Collapse
No announcement yet.
HA Cluster Setup with Shared Message Store Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • HA Cluster Setup with Shared Message Store

    Hi everbody,

    I'm using Spring Intergration in a HA setup with 2 or more nodes. Each one runs the same configuration. All nodes share the same message store (internal JdbcMessageStore running on mysql).

    When using channels with queues and pollers it seems that there is no synchronization at all even if the pollers are marked to work transactional.

    There is a good chance that one message is polled by two nodes at the same time and processed on each node.

    This behaviour isnt really what I want ;-)

    What is the recommended way running a spring integration app and get high availability?

    I experimented a little and introduced row level locking on the database on the polled message group.

    And suprise: it worked. So why is this missing in the shipped implementation?

    Even the in memory message store locks on message group (ok the in memory store cant be shared across jvm boundaries).

    So what is best practice for HA setup?

    Regards Steve

  • #2
    Hi!

    To achieve this purpose there was introduced new JdbcChannelMessageStore in the 2.2: http://static.springsource.org/sprin...store-channels

    For MySQL-becked MS there is MySqlChannelMessageStoreQueryProvider.

    Take care,
    Artem

    Comment


    • #3
      Thanks for your answer Artem,

      but the question was more than one node in a cluster environment. The JdbcChannelMessageStore does some synchronization with its idCache when used from more than one thread.

      But my setup is more the one jvm on different machines. As far as I can see the JdbcChannelMessageStore in such a scenario can not do any synchronzation to prevent the same message being poll from two different nodes at the same time.

      Even if the poller itself works transactional.

      Thx Steve

      Comment


      • #4
        Yes, you're right.
        Have you read Gunnar's important paragraph in the Manual http://static.springsource.org/sprin...tore-channels?

        It's not my suggestion, but I agree and say it one more time: avoid DB-backed queuing and use some external MQ: e.g. JMS or AMQP.
        http://static.springsource.org/sprin...e/#jms-channel
        http://static.springsource.org/sprin...ingle/#d4e4435

        BTW: I use Oracle and everything works well thanks to FOR UPDATE SKIP LOCKED.

        Comment


        • #5
          Yes I read it. And I aware of the problems handling queues on DBMS. But with external MQs you lose some nice operational aspects / features.

          We have developed a more specialized implementation of a message store and the datebase gives us a transparent view of how many messages are in which queue, how long messages are waiting, to which customer a message belongs and so. Even an adminstrative task like "please retry the order for customer x" is just a simple sql update.

          I'm not sure if one can get features like that with MQ solutions, even if you render your messages in XML on the store. The possibilities to
          query and manipulate messages are limited.

          At the moment we are using mysql innodb with row level locking by doing a select .. for update.

          One thing that causes trouble is updating the last modified timestamp on message groups all the time. Is that really nessesary?

          Regards Steve

          Comment


          • #6
            Even an adminstrative task like "please retry the order for customer x" is just a simple sql update.
            It's not a task of MessageStore: don't mix concerns. You simply can't do the same with other business tables and so on.
            One thing that causes trouble is updating the last modified timestamp on message groups all the time
            But if you swith to JdbcChannelMessageStore you get only one table and there is no any group UPDATE.
            And, of course, you can overwrite MySqlChannelMessageStoreQueryProvider for 'select .. for update'.

            And a advice: think more about level of responsibility and loosely-coupling.

            Comment

            Working...
            X