[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[certi-dev] Bug report
From: |
Yaomin Fu |
Subject: |
[certi-dev] Bug report |
Date: |
Thu, 19 Aug 2010 16:53:44 -0300 |
User-agent: |
Internet Messaging Program (IMP) H3 (4.3.4) |
Eric,
It has been a long time I haven't touch the CERTI stuff, but find a
note of a bug worked out previously. I am not sure whether it is
submitted and have forget my password to access the CERTI development
page. So pass it to you here:
Buggy behavour:
A federate that does not publish and only subscribes receives
incorrect object class handle as a result of querying rti by object
handle if it joins the federation execution after other federates.
Expected behavour:
As a result of invoking rti ambassador service
getObjectClass(ObjectHandle), the returned value is a handle of a
class of which the object is. The class should be at the same level of
the object in the class hierarchy tree, not the super class of the
object.
Cause:
RTIA rootObject->Objects has a std::map contains (object handle,
object*) pairs for published objects.
The map is populated as a consequence of message process of either
register object instance or subscribe object class.
In the situation described above only the later occurs and the map is
populated incorrectly.
The method call chain of message process:
RTIA sends NetworkMessage::SUBSCRIBE_OBJECT_CLASS message to RTIG
RTIG to process NetworkMessage::SUBSCRIBE_OBJECT_CLASS message:
RTIG::processSubscribeObjectClass()->FederationsList::subscribeObject()->Federation::subscribeObject()->ObjectClassSet::subscribe()->ObjectClass::subscribe()
If the last method returns as it is a new federate, the caller will
invoke a discover process to send NM_Discover_Object messages to RTIA
for all published objects of the subscribed class, as well as those of
all its sub classes.
ObjectClassSet::subscribe()->ObjectClass::recursiveDiscovering()->ObjectClass::sendDiscoverMessages()
In the sent out message, the handle of the subscribed object class is
then assigned to the objects of the subscribed class and also those of
the sub class.
In other word, an object may be assigned with multiple handles of its
super classes.
RTIA to process DISCOVER_OBJECT message:
TimeManagement::executeFederateService()->ObjectManagement::discoverObject()->RootObject::registerObjectInstance()->ObjectSet::registerObjectInstance()
The last method stores a (object handle, object*) pair in the object
map in rootObject->Objects container.
If a DISCOVER_OBJECT mesaage with (object handle, super class handle)
comes first, the object->class is set to the super class handle, and
prevent the correct one coming late from being stored.
Then if RTIA is queried for class handle by object handle, incorrect
answer is returned.
Fixing:
change one line of code in ObjectClass::sendDiscoverMessages() to
associate correct class handle to the object,
message.objectClass = (*o)->getClass();
Note:
NetworkMessage DISCOVER_OBJECT only from RTIG to RTIA
Upon receiving REGISTER_OBJECT_INSTANCE message from federate, RTIA
sends NetworkMessage::REGISTER_OBJECT message to RTIG
RTIG to process NetworkMessage::REGISTER_OBJECT message:
RTIG::chooseProcessingMethod()->RTIG::processRegisterObject()->FederationsList::registerObject()->Federation::registerObject()->RootObject::registerObjectInstance()->ObjectSet::registerObjectInstance()
Stores (object handle, class handle) correctly
If succeeded, RTIA receives REGISTER_OBJECT back from RTIG and stores
(object handle, class handle) pair:
ObjectManagement::registerObject()->RootObject::registerObjectInstance()->ObjectSet::registerObjectInstance()
DISCOVER_OBJECT is also processed in:
ObjectClassSet::registerObjectInstance()->ObjectClass::registerObjectInstance()
RTIG to process UPDATE_ATTRIBUTE_VALUES message
RTIG::chooseProcessingMethod()->RTIG::processUpdateAttributeValues()->FederationsList::updateAttribute()->Federation::updateAttributeValues()->ObjectClassSet::updateAttributeValues()
Best,
Yaomin