Re: [certi-dev] CERTI deadlock

[Eric Noulard]

2012/6/5 Michael Raab <address@hidden>:
> Hi,
>
> I have a problem using CERTI. I'm running a federation of 6 federates, 5 of
> them are active (regulating and constrained) and 1 is passive (just querying
>  current LBTS over time).
> Up to now we were running either smaller federations and ones that have less
> data traffic in terms of object updates and interactions.
> When running the federation mentioned above, at some point in time (which is
> varying) the progress of simulation time stops. The communication between
> the federates and the rtig process looks still ok,

In order to be sure of that,
you shall either use wireshark in order to capture the network traffic or set

RTIA_MSG=D
and/or
RTIG_MSG=D

which will make the message sent from/to RTIA or RTIG be displayed on
the console
of the concerned process (federate or RTIG).

You can try
RTIA_TM=D
as well, this should time management related action on the RTIA side.

> but no further time advancement is granted. At the moment I have no real
> idea what the reason may be. I was thinking about some kind the network
> problem or limitation, probably a network stack/buffer overflow as
> we are running the whole federation on one machine.

This shouldn't be a problem.
We do that all the time.

> Does someone has an idea
> how to debug if there was an overflow or a message loss?

Overflow is theoretically possible even if we never encounter the situation.
Message loss is impossible if RELIABLE transport is selected.

RELIABLE transport is mapped to TCP which cannot lose data
(at user level API) so at most socket buffer will be fill-up to the point
where the sender is blocked (in the send call).


Which version of CERTI are you currrently using?
Do you compile it with CERTI_USE_NULL_PRIME_MESSAGE_PROTOCOL set to ON or OFF?

On which platform are you running?
Would you be able to share the code of the offending federation?



-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org