Re: [certi-dev] TAG and transient message

[Eric Noulard]

2015-06-29 20:18 GMT+02:00 David Come <address@hidden>:

Hi

I'll try to see if can I reproduce the issue with some C++ code to scope a bit more the issue.

Ok fine.

That way we may be able to reproduce the error.

 

There is not so much doc about that beside the code itself.
The letter was meant to "categorize" the message (D = debug, C = Communication, etc... sse more in PrettyDebug.hh)
whereas the name of the env var was about a "portion of service/code" in CERTI, like "RTIG, RTIA, etc..."

In the end the vast majority of logs uses the "D" letter and a specifically named env var.

You may seek for PrettyDebug object instance in the code in order to find all of them.

That is how I discovered the that mechanism in the first place.

Moreover, what is wrong in this sequence?

B does not see the UAV(3) from A and  is granted time 100. It should be granted time 3 and have that UAV message delivered to him.

Yes that's true. The only way to really know what happen is to trace NULL Message on the RTIG side.

RTIG is  the one deciding to send TAG(100) to both A & B.

When you are at it B send two **UAVs** and A only received one **RAV**.

In order to avoid java thread mix in the log may be you can configure log4j to timestamp your log entry.

I'm just running 2 applications.

Yes Ok, but I was thinking more of a multi-threaded Java application calling jcerti simultaneously from

different path (in the same application). I'm not sure jcerti is ready for that so I was wondering whether

the trace of A federate could me intermixed or not.

--

Eric