Any reason why I would not be permitted to confirm a message using Tibco Rendezvous?

I have a setup in which some applications communicate with each other via Tibco rendezvous. The applications communicate using certified messaging. My problem is that two of my receivers have recently started exhibiting the behavior that they will get an Error 27, Not Permitted when they want to confirm a message (the first message in a certified message exchange isn't certified, we've accounted for that).

I've been looking around the internet to find people with the same error, and I have found many, but they all get the error when trying to create the tibco transport. I can create the transport just fine, but I can't confirm any messages received over it.

Our environment uses both tibco 7.X and 8.X, some times intermingled. This problem appears both when the peers use the same tibco version and when they use different versions. It doesn't show up for all applications, but when it does show up for an application, it remains "broken". Discarding the ledger files for both sender and receiver does nothing. We still get the error. Both sender and receiver have proper permissions to write to (and create the) ledger files. We are connecting to permanently running rvds. The sender and receiver are on different machines. Communication has worked flawlessly in the past, but at some point, it stopped doing so. The application is in java, and we're using the tibrvj.jar auto-native libraries.

The error is

...
Caused by: TibrvException[error=27,message=Not permitted]
  at com.tibco.tibrv.TibrvImplCmTPortC.natConfirmMsg(Native Method)
  at com.tibco.tibrv.TibrvImplCmTPortC.confirmMsg(TibrvImplCmTPortC.java:304)
  at com.tibco.tibrv.TibrvCmListener.confirmMsg(TibrvCmListener.java:88)
....

I know you're going to ask me "what did you do to make it start happening", and my response is "I don't know".

Any input would be appreciated.

Thanks.

Solution

As it turns out, it was a screw-up on the application level. Due to some old code lying around, after having updated a dependency (our messaging layer), we had moved from an application level confirmation to a container level confirmation, but we had forgotten to remove an explicit message confirmation in the application code.

To summarize: We tried to confirm the message twice, and the second time it threw this exception.