Re: [certi-dev] Unsubscribing objectclasses on run causes problems

[Timi Tuohenmaa]

2013/12/17 Eric Noulard <address@hidden>:
> 2013/12/11 Timi Tuohenmaa <address@hidden>:
>> Hi,
>>
>> I just noticed a problem when some federate executes unsubscribe to
>> objectclass that it has had subscribed earlier.
>>
>> If that objectclass had named objects when unsubscribe were executed
>> it never heard that object was removed and therefore thinks that
>> selected name was still reserved for later use.
>
> I'm not sure I get it.
> subscribing  is different from registering so name is reserved
> when you do registerObjectInstance not when subscribing/unsubscribing.
>
> I'll check the code for name reservation handling.
> Did you
>
> registerObjectInstance
> and
> deleteObjectInstance

I have a large federation and it contains federate that works as
recorder which also plays recordings.

This recorder worked (before) in a way that it listened interactions
that inform start of simulation and then it did subscribe to selected
object classes and started to record them (actual objects are
registered aka created by another federate). Then there is another
interaction that informs stop for simulation and that is the moment
recorder unsubscribes to those object classes it had subscribed. That
unsubscibe does often happen before owner of objects have called
deleteObjectInstance so my recorder never hears about deletion.

If I do start playback from this recorder program in this situation
then it tries to register objects with same names that it recorded
sooner it just can't do that since it seems to think that those items
already exists. But for other federates it seems that such object just
got created even when this recorder (which is now playing record) gets
exception that name is already in use.

I changed logic in my program so it never unsubscibes and now it works
as it knows those names were freed.

>> Interestingly creating object with such (mistakenly) reserved name
>> causes creation of such object to federation but that single federate
>> thinks create failed.
>
> You mean that other federate can create object with the concerned name
> but the one which was previously subscribing to it?

Only that recorder program thinks the name was taken, but since
registerObjectInstance did actually create such object then I can't
register it by other federates. If I did not try to register object
from that recorder but another program it did work well (as this was
the only program that actually unsubscribes anywere but on program
shutdown).

Simply put unsubscribing objectclass when it has objects seems to be
dangeous if the same federate is going to subscribe same objectclass
again.

It seems to be that RTIA might have local list of used names and it
should clear them on unsubscribe (since it will be filled again after
subscribe automatically). But obviously this is only a guess of what
happens.

>>
>> I had pretty complex program where I noticed this, but from logs it
>> looked like it missed removes even internally. Obviously I can't be
>> sure if this was exactly the problem behind, but it helped that I
>> changed logic that program only unsubscribed on quit.
>>
>> (using new 3.4.2, but problem existed in 3.4.1 too)
>
>
> Would you be kind enough to file a  but report for that please?

I'll do that if you think you understood it. Otherwise I might not be
able to write it clearly enough to make that report useful.

>> Kind regards,
>> Timi Tuohenmaa
>>
>> --
>> CERTI-Devel mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/certi-devel
>
>
>
> --
> Erk
> L'élection n'est pas la démocratie -- http://www.le-message.org
>
> --
> CERTI-Devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/certi-devel