bugCERTI - Bugs: bug #21650, Unwanted (or not) behavior for...

 
 

bug #21650: Unwanted (or not) behavior for enableAsynchronousDelivery

Submitted by:  Eric NOULARD <erk>
Submitted on:  Tue 27 Nov 2007 12:52:29 PM UTC  
 
Category: CERTISeverity: 4 - Important
Item Group: HLA compliance errorStatus: Fixed
Privacy: PublicAssigned to: Pierre Siron <siron>
Open/Closed: ClosedRelease: 3.2.5
Reproducibility: IntermittentFixed Release: 3.2.6

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Wed 05 Dec 2007 09:42:02 AM UTC, comment #8:

We consider this bug fixed as
everyone's testcases are OK.

Eric NOULARD <erk>
Project Administrator
Wed 05 Dec 2007 08:51:55 AM UTC, comment #7:

The new version correct my trouble reported by Eric

In Fact I use Mak 1516, PITCH 1516 RTI_NG and CERTI with Same code (RTI is abstracted in LIB) and all over TRTI have the same behaviour. I send An Interaction become asynchronous and tick for receive. All over RTI give all interactions.

Carle <patricecarle>
Project Member
Wed 28 Nov 2007 03:01:10 PM UTC, comment #6:

A new CVS version is available for test ...

Pierre Siron <siron>
Project AdministratorIn charge of this item.
Wed 28 Nov 2007 02:04:54 PM UTC, comment #5:

Hello,
I can agree with the comment of Christian,
but, if I test the sequence proposed by Eric
with my interactive federate, I have a problem
in one case:
sendInteraction without timestamp of an interaction class
which is timestamped in the fed file.

Patrice, penses-tu que tu es-dans ce cas ?

The RTIA manages 3 files of messages: CommandMessage,
FifiMessage and TsoMessage.
We have to look if the good file is chosen
(implementation of the sendInteraction service).

A+

Pierre Siron <siron>
Project AdministratorIn charge of this item.
Wed 28 Nov 2007 12:24:55 PM UTC, comment #4:

Hello.

Time constrained federates have to call enableAsynchronousDelivery before they can get callbacks without invoking timeAdvanceRequest followed by tick.

So they have to call enableAsynchronusDelivery before exchanging any messages which should cause callbacks while calling tick.

In my opinion, point 1 and point 2 in the scenario Eric described have to changed and everything would work.

I think that the question of pending messages can not be answered completely through the HLA standard specification.

In my opinion it is more logical to regard the service enableAsynchronousDelivery as early part of the initialization phase of the federate. Normally, it should be clear before programming the federate if it needs to receive callbacks not only in a time advance phase.

The pending messages Eric described would be received after a time advance call followed by tick. So in this scenario federates have to advance their logical time to get the interaction callback receiveInteraction.

That's why I would say that the calling order described by Eric can be regarded as a possible but wrong handling of the HLA API.

Some RTI implementations handle the situation as Eric described, but this is not a must.

Christian Stenzel <approx>
Project Member
Wed 28 Nov 2007 09:57:08 AM UTC, comment #3:

OK fine.
Thank you Pierre.
I now have another remark from Patrice who said that
his trouble is somehow different:
[Patrice should correct me if I'm wrong]

0) Init state is:
Asynchronous delivery is disabled (default behavior)

1) A constrained federate send an interaction
to another constrained federate.

2) Both federates call
enableAsynchronousDelivery

3) Both federates goes into a ticking loop waiting
for their receiveInteraction callback to be triggered

The interaction are never received.

Patrice thinks that "enableAsynchronousDelivery"
should flush any pending messages that was received
before the "enableAsynchronousDelivery" call.

This is true with RTI-NG and other commercial RTI.
CERTI does not seem to exhibit such behavior.

Pierre can you confirm/infirm this?

Eric NOULARD <erk>
Project Administrator
Wed 28 Nov 2007 09:35:41 AM UTC, comment #2:

I've tested the tutorial now without the invocation of the service enableAsynchronousDelivery. The behaviour is now correct.

Christian Stenzel <approx>
Project Member
Tue 27 Nov 2007 02:44:01 PM UTC, comment #1:

TimeManagement updated.
The asynchronous delivery switch should affect only
the behaviour of constrained federates.
To be tested with the appropriate program.

Pierre Siron <siron>
Project AdministratorIn charge of this item.
Tue 27 Nov 2007 12:52:29 PM UTC, original submission:

As already discussed in:
https://savannah.nongnu.org/task/?6911

As Christian said:

_When invoking the service, ro-messages may be delivered to
the federate during any invocation of tick(). BUt this affects
only time-constrained federates ,to all non-time-constraint federates all messages are always delivered asynchronously._

Thus, we should check whether if the behavior of current
CERTI implementation of
RTI::RTIambassador::enableAsynchronousDelivery()
time service complies to HLA specifications.

Moreover it seems that if one sendInteraction
(or other non command message)
BEFORE
calling enableAsynchronousDelivery the invoking federate
may be blocked in an endless waiting loop.

Eric NOULARD <erk>
Project Administrator

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by patricecarle (Posted a comment)
  • -unavailable- added by approx (Posted a comment)
  • -unavailable- added by siron (Posted a comment)
  • -unavailable- added by erk (Submitted the item)
  • -unavailable- added by erk
  • -unavailable- added by erk
  • -unavailable- added by erk
  •  

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 10 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat 22 Mar 2008 03:54:00 PM UTCerkOpen/ClosedOpen=>Closed
      Fixed ReleaseCVS=>3.2.6
    Wed 05 Dec 2007 09:42:02 AM UTCerkStatusIn Progress=>Fixed
      Fixed ReleaseUnknown=>CVS
    Wed 28 Nov 2007 09:57:08 AM UTCerkStatusReady For Test=>In Progress
    Tue 27 Nov 2007 02:44:01 PM UTCsironStatusNone=>Ready For Test
      Assigned toNone=>siron
    Tue 27 Nov 2007 12:52:29 PM UTCerkCarbon-Copy-=>Added siron
      Carbon-Copy-=>Added approx
      Carbon-Copy-=>Added patricecarle

    Back to the top


    Powered by Savane 3.1-cleanup1