bugCERTI - Bugs: bug #55036, Kill the rtig process after all...

 
 

bug #55036: Kill the rtig process after all federations have been destroyed

Submitter:  None
Submitted:  Fri 16 Nov 2018 01:45:10 PM UTC
   
 
Category:  CERTI Severity:  * 3 - Normal
Item Group:  Feature request Status:  Fixed
Privacy:  Public Assigned to:  jb_ch
Open/Closed:  Closed Release:  * GIT-master
Reproducibility:  Every Time Fixed Release:  GIT-master
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 01 Mar 2019 08:42:32 AM UTC, comment #7: 

It is a very specific feature need dedicated to the usage of ptolemy which was fixed directly on ptII sources.

Closing this one as fixed.

JbCh <jb_ch>
Group administrator
Mon 28 Jan 2019 04:57:47 PM UTC, comment #6: 

This issue was fixed in commit d75f236f1429ab4 https://github.com/icyphy/ptII

A Ptolemy federate has 2 parameters: launchRTIG and killRTIG.
If launchRTIG is set, the federate will automatically launch the rtig (if it is not launched yet).
If killRTIG is set, the federate will kill the rtig if it was the one that launched it.

Other fixes were done, and the framework works at commit ebf84cbfd2523.

janette cardoso <cardoso>
Group Member
Fri 30 Nov 2018 08:54:55 PM UTC, comment #5: 

It is not a Ptolemy requirement. But for making the life of user easier, the first launched federation launches the rtig.
A possible change is put a boolean parameter allowing the user to choose to launch the rtig or not.

Anyway, as for now, this is what is done:

            if (_stringBuffer.toString()
                    .matches(".*SocketUDP:\\sBind:\\sAddress\\s"
                            + "already\\sin\\suse\n.*")) {
                _isAlreadyLaunched = true;

Do you know a better way to know "if-not-running"?
Or isAlreadyLaunched ?

janette cardoso <cardoso>
Group Member
Wed 28 Nov 2018 10:18:25 AM UTC, comment #4: 

Thank you guys for the discussion.
We will try to find a good design solution and also a good implementation.
Janette

janette cardoso <cardoso>
Group Member
Mon 26 Nov 2018 10:13:33 AM UTC, comment #3: 

I wasn't aware that this was a Ptolemy requirement.

I can understand the need for a "transparent" launch of RTIG (which is debatable though) but if this is an accepted requirement then another solution would be to add a specific launch flags to RTIG to be used by Ptolemy.

Something like:

rtig --start-if-not-running

that would make RTIG start if not other RTIG process is running and silently stop if another RTIG is running.

That wouldn't break current behavior and probably help PT federate not to care too much about who is launching rtig.

Eric NOULARD <erk>
Group administrator
Mon 26 Nov 2018 10:02:38 AM UTC, comment #2: 

Hello,

I agree with Erk, I don't wan't to implement a RTIG process which can kill himself, that's a strange behavior. It will totally hide the structure of CERTI to user.

I think this issue comes from the usage of ptolemy where the rtig process is launched per the federate if not already existing (running). To me that can be also error prone as the user is not aware that the RTI gateway has been launched per its application.

Maybe it can be further discussed and argued but as of now my opinion is that it is not good to implement such behavior for RTIG.


JbCh <jb_ch>
Group administrator
Fri 16 Nov 2018 01:57:50 PM UTC, comment #1: 

A small note to express my opinion on this.
This is a bad idea.
RTIG lifecycle has never meant to be suicidal. RTIG was meant to run forever.

First:
Automation tests can perfectly handle RTIG life cycle as already done in current dtest scripts:
http://git.savannah.nongnu.org/cgit/certi.git/tree/test/Billard/dtest_billard.py

the testing script itself is responsible for starting/stopping RTIG.

Second:
I can imagine scenarii where we precisely want to CFE/JFE/RFE/DFE
then redo that sequence without stopping RTIG.

And finally
Asking RTIG to count-down some bounded time after the last federation is destroyed is adding a lot of time dependant complexity.


From my experience, problem of everlasting RTIG with student (or myself) was the fact that either my federate were poorly written and did not Resign & Destroy properly.

Once this "bug" is fixed I am not aware of any issue having a everlasting RTIG.

This is my point of view though :-)


Eric NOULARD <erk>
Group administrator
Fri 16 Nov 2018 01:45:10 PM UTC, original submission:  

In order to ease the automation of tests and federation execution, it would be nice to have the rtig process exited automatically after all federations have been destroyed, and a give timeout has elapsed. May be using FederatesCurrentlyJoined and FederationExecutionDoesNotExist.

For example, when using by students, they forget most of the time to kill the rtig. Not only students, we also can forget...

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by cardoso (Posted a comment)
  • -email is unavailable- added by jb_ch (Posted a comment)
  • -email is unavailable- added by erk (Posted a comment)
  •  

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-03-01 jb_ch StatusNeed Info Fixed
        Open/ClosedOpen Closed
    2018-11-26 jb_ch StatusNone Need Info
        Assigned toNone jb_ch

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code