Announcement Announcement Module
No announcement yet.
Some problem about transaction Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Some problem about transaction

    when I set true to channelTransacted ,the application cannot send ack automatically.Though , I have process these messages ,the server still show the messages sended through the channel are unAck .So What is the problem?

  • #2
    Are you using the current release? (1.1.2).

    Please show your configuration.


    • #3
      This is my configuration,and I am using 1.1.1 release
             <bean id="rabbitTransactionManager"
      		<property name="connectionFactory" ref="rabbitConnectionFactory" />
      	<rabbit:listener-container id="ocrWorker"
      		concurrency="20" connection-factory="rabbitConnectionFactory" prefetch="20"
      		transaction-size="5" auto-startup="false" message-converter="orcMessageConvert">
      		<rabbit:listener method="doMessageQueueWork"
      			queue-names="#{sendOcrRequestQueue}" ref="ocrListener" transaction-manager="rabbitTransactionManager" />
      and as soon as the application start, my a service will execute ocrWorker.setChannelTransacted(true),the ocrWorker is the container Listener
      Last edited by Gary Russell; Oct 25th, 2012, 09:29 AM.


      • #4
        Please use [ code ] ... [ /code ] tags when posting code/config (no spaces inside brackets - I have edited your post).

        It's too late to set it after the container has started.

        The 'channel-transacted' attribute was added to the listener containe in 1.1.2; there were also some other fixes related to transactions.

        Please upgrade to 1.1.2 and let us know if you are still having problems.


        • #5
          I have set the container not automatically start up , you can find that the auto-startup's value in the configuration is false.My service will execute ocrWorker.setChannelTransacted(true) first ,then start up the container. What your meaning is that the problem may be is a bug in 1.1.1 release? I guess that the ack model may be changed and I need to commit and send ack by myself instead of sending automatically,but how could I do to commit or send ack by myself ? thanks


          • #6
            Please use 1.1.2 and let us know if you still have a problem.


            • #7
              I have used the 1.1.2 released and there is no these problem,but I also have a problem that in the testing of transaction , some of messages can always occur a exception ,but at last these failure messages can not be found in queue, what is the problem ? I surmise that StatefulRetryOperationsInterceptor try some times to execute the message,if it can not execute successfully after many times ,it will send ack to queue?


              • #8
                As stated in the documentation...


                ...(last paragraph) the default recoverer simply logs a WARN message when the retries are exhausted (default maxAttempts=3); this causes the message to be acked.

                You can either write a custom MessageRecoverer and send the bad message someplace else, or you can use the RejectAndDontRequeueRecoverer in conjunction with a Dead Letter Exchange to send the bad message to a Dead Letter Queue.