Digging deeper into this, that problem
may be related to the one that Christoph Roth reported last time.
The crashing federate receives a reflectAttributeValues()
message which causes an ObjectNotKnown Exception.
Looking into the code, CERTI looks for
the appropriate object handle and throws the exception if it cannot be
found.
Could this be an ordering problem? For
what I can see the appropriate DISCOVER_OBJECT message is received before
RAV message, but it goes immediatly to some queue.
When RAV arrives, DO message is probably
not processed. Therefore the object referenced by RAV is not known. Just
a guess!!!
Eric, could that be the problem?
Best regards,
Michael
Dipl.-Inf. Michael Raab
Fraunhofer-Institut für Fabrikbetrieb und -automatisierung IFF
Virtuell Interaktives Training
Sandtorstr. 22, 39106 Magdeburg, Germany
Telefon +49 (0) 391/ 40 90 122
Telefax +49 (0) 391/ 40 90 115
address@hidden http://www.iff.fraunhofer.de
oder http://www.vdtc.de
Von:
Michael Raab <address@hidden>
An:
CERTI development discussions
<address@hidden>
Datum:
11/08/2010 01:28 PM
Betreff:
[certi-dev]
Federation startup crash
Gesendet von:
address@hidden
Hi all,
I have again problems with CERTI. This time the start up of my federation
crashes. For testing purposes I have only two federates.
The start up procedures look like this:
They get started both in sync, each federate waits for my reaction (with
a MessageBox :-)) after line 7 (queryFederateTime), to be sure that none
of them advances time before the other has joined and configured. This
worked well with DMSO RTI for several years.
After I permit advancement for both, Federate 1 throws an exception during
the process of publishment of one of its interaction classes. But not always
for the same interaction class :-(. Apparently the errors occurs during
getParamterHandle() function call. The Exception message is: libRTI: Network
Read Error waiting RTI reply.
Has someone an idea what may cause this behaviour?