Geek Answers Handbook

Any reason why I would not be allowed to acknowledge a message using a Rank?

I have a setting in which some applications communicate with each other through a Tibco rendezvous. Applications interact using certified messaging. My problem is that my two receivers have recently begun to demonstrate the behavior that they will receive with error 27, and not allowed when they want to confirm the message (the first message in certified messaging is not certified, we took into account that).

I searched the Internet to find people with the same error, and I found a lot, but they all get an error when trying to create a tibco transport. I can create the transport very well, but I can not confirm the received messages over it.

In our environment both tibco 7.X and 8.X are used, mixed several times. This problem occurs when peers use the same version of tibco and when they use different versions. It is not displayed for all applications, but when it appears for the application, it remains “broken”. Canceling the registrar files for both the sender and the recipient does nothing. We are still getting an error. Both the sender and the recipient have the correct permissions to write to (and create) register files. We connect to constantly working rvds. Sender and receiver are on different machines. Communication worked flawlessly in the past, but at some point she stopped doing it. The application is in java, and we use the tibrvj.jar auto-native libraries.

Error

  ...
 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 that you ask me: “What have you done to get this started,” and my answer is “I don’t know.”

Any input would be appreciated.

Thanks.

+4
source share
4 answers

As it turned out, it was application level screwdriving. Due to the fact that some old code lay around updating the dependency (our messaging level), we switched from confirming the application level to confirming the container level, but we forgot to remove the explicit confirmation of the message in the application code.

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

+1
source

TCP connections between the two RVD servers may not be possible. Can you check if you can connect from one to another (connect from the subscriber’s host to the publisher)? In my experience, CMs are processed via TCP (please take this with salt, as I am more an end user than a Middleware support guy).

+1
source

Recently, I came across the same exception - the application worked for several months, suddenly throwing an exception. In my case, some maintenance was performed on the Windows server on which the application was running, and the directories were marked as read-only. After it was cleared, the exception disappeared.

This was discovered after problems with other potential causes were discovered.

+1
source

Just my two cents: this exception also occurs when you try to explicitly acknowledge a message on a transport other than CM.

0
source

More articles:


All Articles