4

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.

Markus Jevring
  • 832
  • 1
  • 11
  • 17

4 Answers4

1

It may be possible that TCP connections between the two RVD servers is not possible. Can you check if you can connect from one to the other (connect from the subscriber host back to the publisher)? In my experience, CM acknowledgments are handled over TCP (please take this with a grain of salt as I'm more an end user than a Middleware support guy).

AnArcticPuffin
  • 111
  • 3
1

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.

Markus Jevring
  • 832
  • 1
  • 11
  • 17
1

I recently encountered the same exception - application had been working for months, suddenly was throwing exception. In my case some maintenance had been done on the Windows server the application ran on and directories had been marked read-only. Once that was cleared the exception went away.

Discovered this after trouble-shooting hours worth of other potential causes.

pdmoore
  • 11
  • 1
0

Just my two cents: This exception also occurs when you try to explicitly confirm message on non-CM transport.

Jan Zyka
  • 17,460
  • 16
  • 70
  • 118