It appears that when Spring JMS detects the backout threshold has been exceeded and it attempts to put the message in question on the backout queue, the COA bit (if specified by the original producer) is not cleared, resulting in an extra COA report being generated. Since the context of the PUT operation to the backout queue is that of the consuming JMS application, this can result in auth failures when an attempt is made to post the report message to the reply queue (or xmit queue).
Has anyone else observed this behavior and, if so, is there a configurable mechanism for assuring these bits are cleared prior to the attempt to write to the backout queue? Thanks!
- Ken