taskCERTI - Tasks: task #6896, tagged deleteObjectInstance

 
 

You are not allowed to post comments on this tracker with your current authentication level.

task #6896: tagged deleteObjectInstance

Submitter:  Eric NOULARD <erk>
Submitted:  Tue 15 May 2007 02:19:19 PM UTC
   
 
Should Start On:  Mon 14 May 2007 10:00:00 PM UTC Should be Finished on:  Mon 14 May 2007 10:00:00 PM UTC
Category:  HLA 1.3 compliance Priority:  5 - Normal
Status:  Ready For Test Privacy:  Public
Assigned to:  approx Percent Complete:  20%
Open/Closed:  Closed Planned Release:  None
RTI Service Groups:  Object Management

Jump to the original submission

Sun 23 Mar 2008 11:34:31 AM UTC, comment #20: 

Closed this i shipped inf CERTI 3.2.6

Eric NOULARD <erk>
Group administrator
Fri 29 Feb 2008 08:04:29 AM UTC, comment #19: 

If you are confident about the functionnality
you may set it as Done.

However the task should remain Open until
the next CERTI release.

When someone is preparing a CERTI release
he should follow the release process
http://cvs.savannah.nongnu.org/viewvc/certi/ReleaseProcess.txt?root=certi&view=markup

which contains a step for closing
bugs and tasks which have been Done/ReadyToTest since
last release.

This way it's easier to track versions evolution.

Eric NOULARD <erk>
Group administrator
Thu 28 Feb 2008 09:28:08 PM UTC, comment #18: 

When can I label a task as Done?

I've tested with the attached code and it works now.

But I#m not sure (as I already wrote) with the
generation of some exceptions (e.g. InvalidFederationTime).


Christian Stenzel <approx>
Group Member
Fri 07 Dec 2007 09:51:41 AM UTC, comment #17: 

One more question regarding the exception InvalidFederationtime.

The exception InvalidFederationTime is generated when time regulating federates invoke an rti service with a time stamp less than their own registred time (this is always true I think for a conservative synchronization scheme and true for optimistic federates too between the rollback phases).

I think TARA or NERA toward TAR/NER allow the invocation of rti services with time  stamps equal to their registred time, better to their LBTS (lower bound on the time stamp = time + lookahead).

So I can't find the code snippet where this exceptions are generated for the services updateAttributeValues and sendInteraction. I suppose that my last patch also generates never such an exception. I've not tested the situation yet, but perhaps anyone know.

Next question: I saw that NullMessages are used to synchronize the federation. Is my assumption correct that the conservative synchronization scheme used in CERTI is based on Nullmessages ( Chandy, Misra, Bryant - algorithm ). I ask, because I want to understand how CERTI internally works.

If my assumptions are correct, perhaps I can find a solution to generate the exceptions.


Christian Stenzel <approx>
Group Member
Wed 05 Dec 2007 01:08:19 PM UTC, comment #16: 

Please note that my previous cvs commit contains a little change compared to the attached patch file of the tracker.

I added line 202 in RTIA/RTIA_network.cc. The reason was, that I have got a wrong removeObjectInstance delivery under some circumstances when the boolean flag of the message is still enabled.

Christian Stenzel <approx>
Group Member
Wed 05 Dec 2007 12:32:53 PM UTC, comment #15: 

Okay, I committed the patch.

Thanks for detailed cvs description.

Christian Stenzel <approx>
Group Member
Wed 05 Dec 2007 10:41:51 AM UTC, comment #14: 


>If I write "cvs commit" in my certi directory the procedure is
>aborted because I have no write access.


Yes your certi_edit directory must be an anonymous
checkout.

>I think I'm connected to cvs as anonymous user, that's
>probably the reason.


Yes must be that.
You may check that by looking at the content
of certi_edit/CVS/Root
say:
cat certi_edit/CVS/Root
you will see if you have done your checkout as "anonymous"
or "approx".

> You see, I'm really a cvs newbie.


We are always the newbie of something.
What you can do to effectively commit is the following.

1) get a clean authenticated checkout of certi

cvs -z3 -d:ext:approx@cvs.savannah.nongnu.org:/sources/certi co certi


2) Apply your previous patch to the new tree
   cd certi
   patch -p0 < deleteObjInst.patch

3) Recompile CERTI and redo your previous tests
   in order to be sure your modifs
   are OK.

4) commit in your read/write tree.

I may do this myself but I'd rather let you commit
yourself because you are the author of the patch.
If you find the process is too time-consuming
let me know and I will commit the patch myself.


Eric NOULARD <erk>
Group administrator
Wed 05 Dec 2007 10:18:28 AM UTC, comment #13: 

Hello Eric,

can you tell me how to do it.

If I write "cvs commit" in my certi directory the procedure is aborted because I have no write access.

I think I'm connected to cvs as anonymous user, that's
probably the reason.

You see, I'm really a cvs newbie.

The modified tutorial sources are very dirty. There only the already named tests can be performed. I put it as an attachment to the tracker, but be warned!

(file #14565)

Christian Stenzel <approx>
Group Member
Wed 05 Dec 2007 09:40:34 AM UTC, comment #12: 

Hi Christian,

I've cross-checked with others.

You may commit your modifications regarding
this task and put its state to "Ready-To-Test"
for others.

May be you can attach your modified tutorial source
to this task in order to make the test case available to other.

You may enrich the tutorial source but I think
it would be nice to keep it simple at first
and may be to make separate complex examples.

I think that we may discuss the way to
settle our enriched tests program within
https://savannah.nongnu.org/task/?6909

Thanks again for your contribution.

Eric NOULARD <erk>
Group administrator
Wed 05 Dec 2007 08:02:41 AM UTC, comment #11: 

I tested with modified tutorial federates.

I tested the following cases:

federate1 not time regulating (tr) not time constrained (tc) sends
deleteObjInst without time parameter to federate2 (neither tr or tc). Then federate2 gets the callback removeObjInst without an additional time argument.

federate1 tr sends deleteOPbjInst without time argument to federete2 (not tr or tc). federate2 gets callback removeObjInst without an additional time argument.

federate1 tr sends deleteOPbjInst with time argument to federete2 (not tr or tc). federate2 gets callback removeObjInst without an additional time argument.

federate1 tr sends deleteObjInst to federate2 (tc). federate2 gets callback removeObjInst with a time argument.







Christian Stenzel <approx>
Group Member
Tue 04 Dec 2007 09:26:06 PM UTC, comment #10: 

The patch is nice ;-)

I will check with others tomorrow that we have
no outstanding modification in the same area
of source code.
If they are no conflict pending
I think you should commit the change.
I will confirm that tomorrow.

How did you test the feature?
A) Did you built a "separate" standalone test case?
B) Did you re-use some HLA applications?
C) Did you add the feature usage to the tutorial?


Eric NOULARD <erk>
Group administrator
Tue 04 Dec 2007 05:40:11 PM UTC, comment #9: 

Okay, here comes my first beautiful patch :)

Now deleteObjectInstance with and without additional time argument are supported. Also the appropriate callbacks removeObjectInstance with and without timestamp are called correctly.



(file #14559)

Christian Stenzel <approx>
Group Member
Tue 04 Dec 2007 11:27:45 AM UTC, comment #8: 



But for now, I would say, that the method
deleteObjectInstance with timestamp is not implemented correctly.

Yes you are right.
May be the task is ill-named.
We are missing the timestamped implementation.


If I'm right, I would like to implement the changes.


Go ahead.

Regarding the patch

I attached the new diff created by applying diff -ur against the repository.


Your patch does not looks like that?
It seems like you did compare two different
CVS trees?
It is not easy to use that because you have
spurious CVS administrative files diff.

I don't know how you are working but I think
you are working in "certi_edit" which is
a CVS extracted tree (i.e. cvs checkout)
while 'certi' may be another ?read-only? checkout.

You may generate the patch directly from your
"certi_edit" CVS tree 
using the following CVS command:

cd /path/to/certi_edit
cvs diff -uN . > /tmp/mybeautiful.patch

then the patch is a unified diff between your local tree
and the repository your are linked with.
Don't waste time to regenerate another patch, but
may be you can try the previous method for the next
patch set.

thank you for your work.

Eric NOULARD <erk>
Group administrator
Tue 04 Dec 2007 11:03:07 AM UTC, comment #7: 

Hello,

thanks for your replies.

I attached the new diff created by applying diff -ur against the repository.

The patch changes the file libRTI/RTIambassador.cc. I think, that the new changes are non-critical. Now both versions of deleteObjectInstance are supported.

As I tried to show you with my last post is that the current timestamped version of deleteObjectInstance makes probably no use of the additional time stamped parameter. Because it is not transmitted to the RTIG. See RTIA/RTIA_federate.cc:411 and RTIA/ObjectManagement.cc:402. The time parameter is never transmitted to RTIG in the method deleteObject. A correct implementation is directly above the delteObject method in ObjectManagement.cc. There sendInteraction is overloaded with and without timestamp. So, in my opinion, the task is to implement a correct deleteObjectInstance timestamped service.

I'm very interested in your opinion because perhaps I don't see my mistakes or I understand something completely wrong.

But for now, I would say, that the method deleteObjectInstance with timestamp is not implemented correctly.

If I'm right, I would like to implement the changes.

(file #14557)

Christian Stenzel <approx>
Group Member
Tue 04 Dec 2007 09:09:11 AM UTC, comment #6: 

Hi Christian,

I have _rapidly reviewed your path.

First of all you did great for following
Federate--RTIA--RTIG call forward and return path.

I think JYR answered you directly by mail
(sometime we too forget to go on the tracker)
about timestamped version.


>So first I looked at libRTI/RTIambassador.cc. There are two
>overloaded methods deleteObjectInstance, one throws immediatly
>an exception unimplemented service.


yes 2 methods corresponds to timestamped and not
timestamped methods.
I do not know (lack of history) why the untimestamped one
is not implemented.


>Obviously, the method deleteObject never knows something about
>an additional time parameter. This parameter is not transmitted. >So it seems to me, that the implementation of
>deleteObjectInstance must be the same as without a time
>parameter.


I did not dive into this but we should (as of HLA 1.3 specs)
have both timestamped and not timestamped deleteObject
service.


EventRetractionHandle                 // returned C3
deleteObjectInstance (
        ObjectHandle    ObjectHandle, // supplied C1
  const FedTime&        theTime,      // supplied C4
  const char           *theTag)       // supplied C4


void deleteObjectInstance (
        ObjectHandle    ObjectHandle, // supplied C1
  const char           *theTag)       // supplied C4


A as side note your last patch did not seem to
be a "clean" unified diff.
Could you use cvs/diff with option

-urN

u is for unified format
r is for recursive
N is for putting in new files (if any)


Eric NOULARD <erk>
Group administrator
Tue 04 Dec 2007 09:02:02 AM UTC, comment #5: 

HLA 1.3 needs delete object instance with and without timestamp.
For implementing this, you can see implementation of like servives with optionnal timestamp (send interaction...). We use a variable (boolean) in Message to know if timestamp is needed or not.
You can see call sequense py puting environnement variable GENDOC to G in for rtig and federates.
JY

ROUSSELOT <rousse>
Mon 03 Dec 2007 04:02:10 PM UTC, comment #4: 

Forgot the patch.

(file #14551)

Christian Stenzel <approx>
Group Member
Mon 03 Dec 2007 04:00:05 PM UTC, comment #3: 

Hello,

I'm a little bit confused and I suppose I need some help.

First I describe how I understand some calling mechansims in CERTI, please correct me if I'm wrong.

Okay, the task is to write a tagged deleteObjectInstance service.

So first I looked at libRTI/RTIambassador.cc. There are two overloaded methods deleteObjectInstance, one throws immediatly an exception unimplemented service.

Okay, fine, here we are. Further on, I looked at  libRTI/RTIambPrivateRefs.cc. It sends the message to RTIA. In RTIA/RTIA.cc the method processFederateRequest is invoked. This leads us to the file RTIA/RTIA_federate.cc. Here the message DELETE_OBJECT_INSTANCE causes a call of the method deleteObject of the ObjectManagementClass. Paraemeters are theObject and theTag and e (probably exception).

The method deleteObject in RTIA/ObjectManagement.cc sends the message DELETE_OBJECT to RTIG and waits for an non-exceptional answer.

Okay, at this point, my first question:
Obviously, the method deleteObject never knows something about an additional time parameter. This parameter is not transmitted. So it seems to me, that the implementation of deleteObjectInstance must be the same as without a time parameter.
I tested it and removed the creation of the exception unimplemented service in RTIambassador.cc. This works immediatly. Also I rearranged the callback removeObjectInstance in the way as  in some other overloaded callbacks.
It seems to me, that the time parameter in deleteObjectInstance is not really important.

Okay, now I go on. The method deleteObject of the ObjectManagementClass.cc in RTA sends the message DELETE_OBJECT to RTIG. RTIG processes then the message DELETE_OBJECT in RTIG/RTIG_processing.cc within the method processDeleteObject.

Callbacks are now generated by invoking the destroyObject method of the class FederationsList.cc in RTIG. There the method deleteObject of the class Federation.cc is called. This causes a call of the method deleteObjectInstacne in RootObject.cc. Okay, here I have still some holes, I suppose the the ObjectClasBroadClastList class sends than a message REMOVE_OBJECT to RTIA. Here the messgae is inserted into a queue and finally the callback removeObjectInstance is generated.

Hope to get the most important connections.

So, I attached the described changes of the file RTIambassador.cc in a diff. This is of course not my final solution, but worked for me. I suppose, as I already described, that this task need some further efforts.

Christian Stenzel <approx>
Group Member
Thu 29 Nov 2007 02:00:11 PM UTC, comment #2: 

Ok Christian,
you are welcome.

Go and try this.
I've assigned the bug to you.

When you have a solution please submit a patch
attached to the tracker so that we can try the patch
before committing.

Don't be afraid when discovering CERTI internals :=)

Eric NOULARD <erk>
Group administrator
Thu 29 Nov 2007 01:48:56 PM UTC, comment #1: 

Perhaps I can try it. This would be a good start to learn more about the CERTI implementation.

Christian Stenzel <approx>
Group Member
Tue 15 May 2007 02:19:19 PM UTC, original submission:  

We should implement the tagged version
of

deleteObjectInstance (ObjectHandle, const char *)


Eric NOULARD <erk>
Group administrator

 

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

Attached Files
file #14565:  test.tar.bz2 added by approx (12KiB - application/octet-stream)
file #14559:  deleteObjInst.patch added by approx (31KiB - text/x-patch)
file #14557:  patchRTIambassador added by approx (2KiB - application/octet-stream)
file #14551:  patchRTIambassador added by approx (1KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rousse (Posted a comment)
  • -email is unavailable- added by approx (Posted a comment)
  • -email is unavailable- added by erk (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-03-23 erk Open/ClosedOpen Closed
    2007-12-05 approx StatusNone Ready For Test
    2007-12-05 approx Attached File- Added test.tar.bz2, #14565
    2007-12-04 approx Attached File- Added deleteObjInst.patch, #14559
    2007-12-04 erk Priority1 - Later 5 - Normal
        Percent Complete0% 20%
    2007-12-04 approx Attached File- Added patchRTIambassador, #14557
    2007-12-03 approx Attached File- Added patchRTIambassador, #14551
    2007-11-29 erk Assigned toNone approx

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code