You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Jim Gomes (JIRA)" <ji...@apache.org> on 2011/06/14 22:40:47 UTC

[jira] [Resolved] (AMQNET-243) failover causes duplicate messages

     [ https://issues.apache.org/jira/browse/AMQNET-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jim Gomes resolved AMQNET-243.
------------------------------

    Resolution: Won't Fix

Resolving this issue, since what the broker sends down to the client is outside the domain of client code, and an idempotent pattern is easily layered on top of NMS to achieve the desired effect.  While it would be nice to be able to publish the pattern for others to use, the attached sample code does not have a license grant to the ASF, so it can't be re-used.

Regarding the NMS blow-up mentioned in step 5 of the original Steps to Reproduce, this can be entered as a new issue if it is still a problem in the latest NMS.

> failover causes duplicate messages
> ----------------------------------
>
>                 Key: AMQNET-243
>                 URL: https://issues.apache.org/jira/browse/AMQNET-243
>             Project: ActiveMQ .Net
>          Issue Type: Bug
>          Components: ActiveMQ
>    Affects Versions: 1.1.0
>            Reporter: Mark Gellings
>            Assignee: Jim Gomes
>             Fix For: 1.6.0
>
>         Attachments: IdempotentConsumer.zip
>
>
> Reference https://issues.apache.org/activemq/browse/AMQ-2627 for specifics on problem.
> Attached to that issue is a zip file which is password protected with password "fridaytest".
> We're using ActiveMQ v5.2, jdbc master/slave MSSQL 2008. Attached is an NMS v1.2 RC4 consumer with a transacted session as well as activemq.xml.
> To replicate:
> 1) Work through the console prompts and produce 50 msgs.
> 2) Restart console and start consuming those 50 msgs.
> 3) In the middle of the consumer processing, restart broker
> 4) The last message consumer was processing will be resent and not marked as redelivered. (this is the idempotent msg problem. Ex. - instead of $500 getting deposited into your account, $1000 does)
> 5) Then NMS blows up which seems like a different problem?
> From what I understand this shouldn't be the case if you use a transacted session, however the attached console app can prove it is a problem.
> Bottomline--I thought this was why the camel idempotent consumer pattern [1] existed which can be leveraged by java clients.
> [1] http://fusesource.com/docs/router/1.6/eip/MsgEnd-Idempotent.html
> Regards,
> Mark

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira