not really. the exception is the solution - telling you that the
transaction rolled back and it has no idea if it was a success or
failure.
This is the commit reply lost scenario. The client can't distinguish a
missing reply from a remote request that did not complete.
This is a situation where you may get a duplicate message delivery.
There is the option to persist the redeliveryFlag and make it a
reliable indication of replay. In that case, your app would do some
extra work to suppress duplicates if the redelivery flag is set. The
reliable redelivery flag ensures that you take the hit of duplicate
detection when necessary. However, the broker takes a hit by
persisting the message on first delivery attempt.
there is no free lunch :-)
On 4 March 2015 at 14:03, noone100 <mr.someb...@gmx.ch> wrote:
> Hi
>
> In a transacted session I try to receive a message again after a failover
> using the failover protocol (see code below). The fail on the broker is
> triggered using a Byteman script, which kills the jvm right after the method
> org.apache.activemq.transaction.LocalTransaction.commit(). After failover a
> JMSException is thrown which is catched and handled by the consumer. The
> problem is, that the message is not resent due to the fact that it is
> already removed and committed from the broker's database. Is there any
> solution for that problem?
>
> public void onMessage(Message msg) {
> try {
> System.out.println("count: " + counter.incrementAndGet() + ", received
> message " + msg.toString());
> session.commit(); // let amq broker jvm die
> System.out.println("after commit"); // won't happen
> } catch (JMSException e1) {
> System.out.println("undo changes");
> try {
> session.rollback();
> } catch (JMSException e) {
> e.printStackTrace();
> }
> }
> }
>
> Thanks for your help!
> Michael
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Transactional-Message-Lost-On-Failover-tp4692426.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
