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

[Eric Noulard]

2013/12/17 Timi Tuohenmaa <address@hidden>:
> 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.


Current description is clear.
You can copy/paste it into the newley created bug report or
simply refer to ML archived message:
http://lists.nongnu.org/archive/html/certi-devel/2013-12/msg00006.html


-- 
Erk
L'élection n'est pas la démocratie -- http://www.le-message.org