bugCERTI - Bugs: bug #53878, Connection RTIA failed

 
 

bug #53878: Connection RTIA failed

Submitter:  None
Submitted:  Fri 11 May 2018 12:21:21 PM UTC
   
 
Category:  JavaCERTI Severity:  * 3 - Normal
Item Group:  Software error Status:  Fixed
Privacy:  Public Assigned to:  cardoso
Open/Closed:  Open Release:  * GIT-master
Reproducibility:  Intermittent Fixed Release:  Unknown
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 19 Jun 2018 01:35:05 PM UTC, comment #14: 

Considering this one as fixed as patch fix the timing issue.

JbCh <jb_ch>
Group administrator
Thu 24 May 2018 04:54:03 PM UTC, comment #13: 

I added the same fix in a branch derived from the current master branch of jcerti.

--> branch: br_bug_53878
--> commit: a47b68e5f33a

Please and test and report in the savannah issue tracker

JbCh <jb_ch>
Group administrator
Wed 16 May 2018 07:46:36 AM UTC, comment #12: 

Ok, thus I consider this one as fixed.

Fix is:
git -> https://git.savannah.nongnu.org/git/certi/jcerti.git
branch -> br_ptII_bug_53878
commit -> #24cafdcc65ed0

For now, we will keep this bugfix/workaround in this branch


JbCh <jb_ch>
Group administrator
Wed 16 May 2018 06:57:41 AM UTC, comment #11: 

Thank you Eric and Jean-Baptiste for the incredible fast reply to this bug. :)

After update jcerti.jar to the branch #24cafdcc65, as for now the hlacerti demos and tests are passing!

janette cardoso <cardoso>
Group Member
Tue 15 May 2018 09:25:55 AM UTC, comment #10: 

I tested again this morning and it worked fine!

As the error appears only sometimes, we will keep using the commit #24cafdcc65ed0 for continuing the tests.

Anonymous
Mon 14 May 2018 08:25:18 PM UTC, comment #9: 

Hello, Thank you all!
I just made a test. In a sequence of tests models, all models works, but one of them throw the error bellow. I need to investigate for understand why this occurs in this particular model. Could be a problem in our code. I will made more test Tue afternoon.
--------------------
Exception: java.lang.RuntimeException thrown from the UncaughtExceptionHandler in thread "Thread-51"
ptolemy.kernel.util.IllegalActionException: CouldNotOpenFED: Module not found
  in .MultiDataTypesConsumer.HlaManager
Because:
Module not found
(...)
at ptolemy.actor.lib.hoc.ModelReference$1.run(ModelReference.java:626)
Caused by: hla.rti.CouldNotOpenFED: Module not found serial:0
at certi.rti.impl.CertiRtiAmbassador.translateException(CertiRtiAmbassador.java:3832)
at certi.rti.impl.CertiRtiAmbassador.processRequest(CertiRtiAmbassador.java:3773)
at certi.rti.impl.CertiRtiAmbassador.createFederationExecution(CertiRtiAmbassador.java:322)
at org.hlacerti.lib.HlaManager.initialize(HlaManager.java:663)


Anonymous
Mon 14 May 2018 02:03:13 PM UTC, comment #8: 

Agreed...and implemented in commited #24cafdcc65ed0e8411aaab00a751d256e5e53064

Thanks

JbCh <jb_ch>
Group administrator
Mon 14 May 2018 01:56:08 PM UTC, comment #7: 

Jean-Baptiste,

Retry loop in this case is ok but one usually make the wait time greater when number of retry increases.

i.e. I would do something like:

Thread.sleep(nb_retry*50);

this is usually more robust and enables initial small wait time (which is the most common case) and globally longer wait time after 'n' retry. So may be

Thread.sleep(nb_retry*20);

is enough and faster in the average case.


Eric NOULARD <erk>
Group administrator
Mon 14 May 2018 01:41:17 PM UTC, comment #6: 

I have implemented a tiny workaround to avoid timing issue between federate process and rtia process in "br_ptII_bug_53878"

It has been tested with jcerti test case but it needs further test/investigation.

This jcerti version can be cloned with:

>> git clone -b br_ptII_bug_53878 https://git.savannah.nongnu.org/git/certi/jcerti.git

JbCh <jb_ch>
Group administrator
Mon 14 May 2018 10:37:53 AM UTC, comment #5: 

Hi Erk,

Thanks for the update and sharing your point here :)

Indeed the timing issue looks as a good candidate as you described.

Thanks!

JbCh <jb_ch>
Group administrator
Mon 14 May 2018 10:36:02 AM UTC, comment #4: 

Note that this may "simply" be a timing issue.
The java code spawn the RTIA process but may it does not check whether it has already started before trying the TCP connexion.

I bet that in some cases the RTIA process spawned is either not started at all or not ready to accept connexion when the java Ambassador counterpart is trying to open the connection.

Eric NOULARD <erk>
Group administrator
Mon 14 May 2018 10:32:55 AM UTC, comment #3: 

Hi there,

AFAIR, RTIA process always listen on unix socket AND tcp socket.
However RTIambassador (either in HLA 1.3 or 1516) uses unix socket with it unless (C++) certi is compiled with RTIA_USE_TCP.

This is the default on windows platform where unix socket does not exists.

So when using jcerti, the Ambassador is a 100% java process so compiling C++ certi with or without RTIA_USE_TCP shouldn't change anything.

If you "git grep   RTIA_USE_TCP" you shouldn't find any use in RTIA/* files but only in libRTI/* subdirs.

Have a look at:

RTIA/main.cc
RTIA/RTIA.cc
and
RTIA/Communications.cc

So I guess the issue is not there.


Eric NOULARD <erk>
Group administrator
Mon 14 May 2018 10:19:43 AM UTC, comment #2: 

After looking at it, the jcerti is calling the RTIA executable file created per certi compilation. All is done in file "CertiRtiAmbassador.java"

It looks like it is a little confusing here, the jcerti is using a java ServerSocket class which is used to create and handle TCP sockets (see line 131).

See:
https://docs.oracle.com/javase/7/docs/api/java/net/ServerSocket.html

However, standard compilation of CERTI under linux/mac are using Unix sockets for communication between RTIA and federates.

You can try to compile the CERTI and forcing the RTIA_USE_TCP option and see if the error appears again.


JbCh <jb_ch>
Group administrator
Mon 14 May 2018 10:06:45 AM UTC, comment #1: 

Hello,

We have never faced such behavior using CERTI with native C++ federates neither with Python federates (using C++ bindings).

This is why I believe that this behavior is due to jcerti and not certi.

I guess that the jcerti is responsible of creating the RTIA process thus you have to dig a little to find out how the process is created and how it is connected to the federate (using Unix or TCP socket as an example).

Regards,
Jb Ch

JbCh <jb_ch>
Group administrator
Fri 11 May 2018 12:21:21 PM UTC, original submission:  

Hi CERTI Team,

We are working with the projet PTII - HLA/CERTI (co-simulation framework between Ptolemy and HLA/CERTI). In this framework, CERTI_HOME must be set, and the first
federate launches the RTIG.

However, even with CERTI_HOME set, we have noticed (at least) on MacOS Sierra that sometimes when executing a  simulation model we get the "Connection RTIA failed" exception from CERTI. The problem is not yet reproducible, the exception may happen after two, five or ten executions. And when this occurs, launching again the same model works fine. This problem can happen also in automatic tests.

We would like to know in which specific cases such exception may be raised by CERTI, for making more conclusive tests.

Thank you


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 erk (Posted a comment)
  • -email is unavailable- added by jb_ch (Posted a comment)
  •  

    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-06-19 jb_ch StatusReady For Test Fixed
    2018-05-24 jb_ch StatusFixed Ready For Test
    2018-05-16 jb_ch StatusReady For Test Fixed
    2018-05-14 jb_ch StatusNeed Info Ready For Test
        Fixed ReleaseGIT-master Unknown
    2018-05-14 jb_ch CategoryCERTI JavaCERTI
        StatusNone Need Info
        Assigned toNone cardoso

    Back to the top

    Powered by Savane 3.13-cf05.
    Corresponding source code