as a patch for that I would propose
to extend both RTIAmbassador and RTI1516Ambassador destructor as follows:
{
certi::M_Close_Connexion req, rep ;
G.Out(pdGendoc,"
====>executeService CLOSE_CONNEXION");
privateRefs->executeService(&req,
&rep);
// after the response is received, the
privateRefs->socketUn must not be used
// Terminate RTIA, if not already
TerminateProcess(privateRefs->handle_RTIA,
0);
delete privateRefs;
}
This works like a charm on windows.
What do you think?
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:
Eric Noulard <address@hidden>
An:
CERTI development discussions
<address@hidden>
Datum:
12/01/2010 08:56 PM
Betreff:
Re: [certi-dev]
RTIA shutdown
Gesendet von:
address@hidden
2010/12/1 Michael Raab <address@hidden>:
> Hi all,
>
> I'm wondering what is causing the RTIA process to shutdown.
> At the moment I call ResignFed and DestroyFed at the end of the simulation
> in each federate and then exit the appropriate simulation system.
> Sometimes RTIA quits, sometimes not. Ideas? Best practices?
The RTIA quits when it receives the CLOSE_CONNEXION message
from its federate, because of the endless loop in RTIA::execute()
which check for the
fm->_connection_state != FederationManagement::CONNECTION_FIN
condition.
Since there is no "Close Connection Service" in HLA 1.3 nor in
IEEE-1516-200
(it comes in 1516-2010) currently we send this message in the
RTIambassador destructor.
The RTIA may finish itself if it detects a "NetworkError" when
reading message
from its federate or RTIG. In that case it put itself in the
FederationManagement::CONNECTION_FIN state without receiving the
CLOSE_CONNEXION message.
So I see two possible reasons to the non-termination of RTIA:
1) The federate cannot/did not send the message because the
destructor is not properly called ?
Is your RTIambassador a plain object or do you do something
like:
RTI::RTIambassador* myRTIA = new RTI::RTIambassador();
and [sometimes] forgot to call
delete myRTIA;
Note that even in case of crash or not nice termination
of the Federate RTIA should properly stop because
it must detect the network error on the Federate socket.
2) There is a race inside the RTIA endless loop which leads
to a state where execute() is in a blocking state.
There may be some difference on Windows platform because the
socket used between RTIA and its Federate is a TCP
(its an Unix Socket on Unix :-]) so TCP socket may have some builtin
"delay" before being closed.
If you wait says 3-5 minutes after federate stopped
does the dangling RTIA terminates itself ?
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org