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

[Timi Tuohenmaa]

I decided to refer to link to mailing list.

https://savannah.nongnu.org/bugs/index.php?40936

I have avoided to chance subscriptions on the run so this is not too
big issue, but I thought it is better to tell about it...
I'll be back with more bug reports (and if necessary with fixes too).
Thanks for your reply.

-Timi


2013/12/17 Eric Noulard <address@hidden>:
> 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
>
> --
> CERTI-Devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/certi-devel