Announcement Announcement Module
No announcement yet.
Persistent queue channel backed by a transactional jdbc messagestore blocks sender. Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Persistent queue channel backed by a transactional jdbc messagestore blocks sender.


    Persistent queue based channel, backed by a transactional jdbc message-store blocks sending messages to channel when messages are read from the channel.

    A little more explanation:
    I want to do something really simple: I want to send messages asynchronously(in order to not block the sender) and want messages to be persisted. And I want the messages to be retained in channel queue if something goes wrong at the consumer (so I set up transaction).
    Here is my Spring integration configuration:

    <!-- channel description is done via annotations in gateway interface-->
    <int:gateway id="myMailSender" service-interface="com.serkan.MyMailSender"/>

    <int:channel id="mailChannel" >
    <int:queue message-store="messageStore" />

    <int-jdbc:message-store id="messageStore" data-source="myDataSource" />

    <int:service-activator input-channel="mailChannel" ref="myMailManager" method="sendMail">
    <intoller fixed-rate="1000">
    <int:transactional transaction-manager="transactionManager" isolation="READ_COMMITTED" propagation="REQUIRED" timeout="3000"/>

    <bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSou rceTransactionManager">
    <property name="dataSource">
    <ref bean="myDataSource"/>

    This looks like working but there is a problem: When the consumer receives a message and working on it, sender cannot put another message into the channel. It just blocks until the consumer is done. If I remove transaction configuration this problem disappears. I have tried 2 different databases: Oracle and PostgreSQL with almost all possible isolation levels and it is always same.

    Anyone have any idea how I can overcome this?

    Thanks in advance,

  • #2

    We have elevated the following Jira issue to be addressed for 2.2.0.RC3 - I think that Jira fully reflects the issue you are having. We will provide a more detailed update on this later today. Also, take a look at the parent issue as it provides some more details: