Why do I get the REGISTRATION.COLLISION error in my CM application?
book
Article ID: KB0078754
calendar_today
Updated On:
Products
Versions
TIBCO Rendezvous
-
Not Applicable
-
Description
Why do I get the REGISTRATION.COLLISION error in my CM application?
============= 2006-11-22 14:17:37 RV: TIB/Rendezvous Error Not Handled by Process: { ADV_CLASS="ERROR" ADV_SOURCE="RVCM" ADV_NAME="REGISTRATION.COLLISION.ABC" name="ABC" confl_inbox="_INBOX.0A694245.8DC4564D2622E2C860.1" confl_addr=10.105.66.69 } =============
What is the likely cause of this problem? It doesn't seem to have a negative effect on the system but doesn't look good in the system log. Should I ignore this error?
Resolution: Question:
A CM transport receives the REGISTRATION.COLLISION advisory when it discovers a newly enabled CM transport that claims the same CM name. This advisory is generated during the discovery process. For example, if you start 2 cm listeners with the same CM name “ABC”, the two CM transports realize that there is another transport out there that has the same cmname, which is illegal. Hence, both instances (old & new with same CM name) will get the REGISTRATION.COLLISION advisory. To stop this advisory from being generated, you need to stop one.
In this particular case, the reusable correspondent name “ABC” is the locus of the collision. You should check if there is a second CM transport using the cmname “ABC”. It may be a second instance on the same machine or somewhere else on the network. From the above error, the conflict is coming from address 10.105.66.69.
Please take a look at the TIBCO Rendezvous Concepts manual, Chapter 11 "Certified Message Delivery", it clealy states that the CM name should be unique, and two CM transports must not bind the same CM name at any moment in time, each reusable name must be unique throughout the network.
Please also note that if you are running pre-RV 7.5 versions, a CM name collision situation could trigger a flood of the CM protocol message _RVCM.SEARCH. The fix is implemented in RV 7.5.
============ 1-3VFB2N 7.5 Fixed a certified message delivery defect in which duplicate CM correspondent names could trigger a race condition accompanied by large number of CM protocol messages. ============
Issue/Introduction
[Article needs review] Why do I get the REGISTRATION.COLLISION error in my CM application
Environment
OS: All
Resolution
A CM transport receives the REGISTRATION.COLLISION advisory when it discovers a newly enabled CM transport that claims the same CM name. This advisory is generated during the discovery process. For example, if you start 2 cm listeners with the same CM name “ABC”, the two CM transports realize that there is another transport out there that has the same cmname, which is illegal. Hence, both instances (old & new with same CM name) will get the REGISTRATION.COLLISION advisory. To stop this advisory from being generated, you need to stop one.
In this particular case, the reusable correspondent name “ABC” is the locus of the collision. You should check if there is a second CM transport using the cmname “ABC”. It may be a second instance on the same machine or somewhere else on the network. From the above error, the conflict is coming from address 10.105.66.69.
Please take a look at the TIBCO Rendezvous Concepts manual, Chapter 11 "Certified Message Delivery", it clearly states that the CM name should be unique, and two CM transports must not bind the same CM name at any moment in time, each reusable name must be unique throughout the network.