Hi Gaurav, First about the duplicate resulting an exception, I think there is an issue reported for this. I have to take a look at it. It's ugly but unless this happens on the last message, it is not critical, as the message will or (should have been) acknowledged and the retransmission to terminate. But in any case, I'll look into it.
For the ack behavior setting, there are complicate combinations of the property setting that influence the behavior and I might have got it wrong. Someone can correct me in that case. Property intraMessageThreshold represents the message traffic rate (#msg/min) threshold and it is used to control how often the ack sending is scheduled (if the actual message rate goes higher than this rate, their acks are not scheduled this way). If this threshold value is set to zero, their acks are all scheduled this way with a delay of acknowledgementInterval. However, if acknowledgmentInterval is set to zero, the acks are not scheduled this way but with a delay of ImmediateAckTimeout value which is 1 sec in default. regards, aki 2012/9/19 gauravd <[email protected]>: > Aki, > > Thank you for the response. I tried the delivery assurance policies - > ExactlyOnce and AtmostOnce, but in each of the cases, I get an message > already delivered exception. > > However, if I comment out the destination policy section as mentioned below > at the service end - the issue is solved. > > <wsrm-mgr:destinationPolicy> > <wsrm-mgr:acksPolicy intraMessageThreshold="0"/> > </wsrm-mgr:destinationPolicy> > > What is the significance and meaning of intraMessageThreshold please? Am I > setting up WS-RM correctly? > > > > -- > View this message in context: > http://cxf.547215.n5.nabble.com/WS-RM-AcknowledgementInterval-leads-to-duplicates-tp5714148p5714168.html > Sent from the cxf-user mailing list archive at Nabble.com.
