Portico Project Forums

Portico Support :: RE: hla.rti.RTIinternalError

eunsol — Mon, 08 Mar 2010 13:12:15 GMT

Author: eunsol
Posted: Mon Mar 08, 2010 11:12 pm (GMT 10)

Hello Tim,

Thank you so much for your helping.
I cannot wait to see new version.

Portico Support :: RE: hla.rti.RTIinternalError

tim — Sat, 06 Mar 2010 08:33:38 GMT

Author: tim
Posted: Sat Mar 06, 2010 6:33 pm (GMT 10)

G'day Sol,

This is an issue that has been seen many times before unfortunately. The joining process is quite flaky with JGroups and it needs sorting out. However, due to other reasons, JGroups is currently being replaced by a custom networking implementation.

The new binding should be ready for the next version of Portico (v1.0.2) coming in May/June. Until then, there is sadly nothing that can be done. My suggestion is to spread out the joining of the federates as long as possible. It's not at all idea, but it will have to do for now sadly

Cheers,
Tim

Portico Support :: hla.rti.RTIinternalError

eunsol — Fri, 05 Mar 2010 19:53:43 GMT

Author: eunsol
Subject: hla.rti.RTIinternalError
Posted: Sat Mar 06, 2010 5:53 am (GMT 10)

Hello,

I am using portico ver. 1.0.1, and there is connection error, and it happens randomly.

Currently, I have one main federate and three federates joined.
Two federates always successfully join to the main federate, but the last federate sometimes fails to join.
This code is from the failed federate.

Code:

DEBUG [c++] Initialize the JVM
DEBUG [c++] Creating a new JVM
INFO [c++] New JVM has been created
INFO [c++] Attempting to load RID file
INFO [c++] RID file processing finished
INFO [c++] newRtiAmbassador: creating new JavaRTI
DEBUG [rti-1] Attaching to JVM
INFO [rti-1] Attached to JVM
DEBUG [rti-1] Creating new instance of ProxyRtiAmbassador
INFO [rti-1] Initialized new JavaRTI (rti-1)
TRACE [rti-1] Caching RTIambassador method ids...
TRACE [rti-1] Cached RTIambassador method ids
TRACE [rti-1] Caching Region method ids
TRACE [rti-1] Cached Region method ids
DEBUG [c++] [Starting] joinFederationExecution(): federationName=Federation, federateName=Federate
ERROR [main] portico.lrc: Waited 5 seconds for RoleCall from federate [3], none received, connection error
org.portico.shared.compat.JRTIinternalError: Waited 5 seconds for RoleCall from federate [3], none received, connection error
at org.portico.lrc.handlers.outgoing.JoinFederationHandler.process(JoinFederationHandler.java:133)
at com.lbf.commons.messaging.MessageSink.process(MessageSink.java:186)
at org.portico.impl.hla13.Impl13Helper.processMessage(Impl13Helper.java:123)
at org.portico.impl.hla13.Rti13Ambassador.processMessage(Rti13Ambassador.java:5732)
at org.portico.impl.hla13.Rti13Ambassador.joinFederationExecution(Rti13Ambassador.java:230)
at org.portico.impl.cpp13.ProxyRtiAmbassador.joinFederationExecution(ProxyRtiAmbassador.java:222)
INFO [rti-1] Exception received: RTIinternalError
INFO [rti-1] hla.rti.RTIinternalError: org.portico.shared.compat.JRTIinternalError
: Waited 5 seconds for RoleCall from federate [3], none received, connectionerror serial:0
at org.portico.impl.hla13.Rti13Ambassador.joinFederationExecution(Rti13Ambassador.java:254)
at org.portico.impl.cpp13.ProxyRtiAmbassador.joinFederationExecution(ProxyRtiAmbassador.java:222)
Caused by: org.portico.shared.compat.JRTIinternalError: Waited 5 seconds for RoleCall from federate [3], none received, connection error
at org.portico.lrc.handlers.outgoing.JoinFederationHandler.process(JoinFederationHandler.java:133)
at com.lbf.commons.messaging.MessageSink.process(MessageSink.java:186)
at org.portico.impl.hla13.Impl13Helper.processMessage(Impl13Helper.java:123)
at org.portico.impl.hla13.Rti13Ambassador.processMessage(Rti13Ambassador.java:5732)
at org.portico.impl.hla13.Rti13Ambassador.joinFederationExecution(Rti13Ambassador.java:230)
... 1 more

It happens really random, is this federate timing issue?

Thank you so much
Regard,
Sol

Portico Support :: RE: org.portico.impl.cpp13.ProxyRTIAmbassador issue

tim — Thu, 04 Mar 2010 01:36:20 GMT

Author: tim
Posted: Thu Mar 04, 2010 11:36 am (GMT 10)

Hmmm, I'm not sure about that particular issue. I haven't seen it before. However, with regard to Portico v0.9, I would skip it and only 1.0.x+

The v0.9 releases were a bit buggy for a number of reasons, so my advice would be to steer clear of them!

Portico Support :: RE: org.portico.impl.cpp13.ProxyRTIAmbassador issue

eunsol — Wed, 03 Mar 2010 20:57:06 GMT

Author: eunsol
Posted: Thu Mar 04, 2010 6:57 am (GMT 10)

Hello Tim,

Thank you for helping me to figure out what's going on.
I retried to set RTII_HOME and PORTICO_DEBUG, and it worked fine.

However, I got another problem, which is running a federate in debug mode is failed in portico version 0.9.

Code:

This application has failed to start because MSVCR80.dll was not found.

In release mode, it works perfectly, but not in debug mode.
Anything that I need to do to run federates in debug mode?
running federates in 0.8 and 1.0.1 versions are working fine.
(both version were got released ones, not from src trunk.)

Moreover, to build portico 0.9, I used

Code:

ant sandbox

and

Code:

ant release -Dbuild.devel=true

Thank you for helping me a lot
Regard,
Sol

Portico Support :: RE: org.portico.impl.cpp13.ProxyRTIAmbassador issue

tim — Wed, 03 Mar 2010 05:19:39 GMT

Author: tim
Posted: Wed Mar 03, 2010 3:19 pm (GMT 10)

G'day Sol,

I've seen this crop up before. What it means is that the C++ side of the Portico bindings can't talk to the Java side. The usual cause for this is that the RTI_HOME environment variable isn't set correctly and so the C++ bindings have no reference to use to track down the portico.jar file.

If you have got RTI_HOME set properly, to find out more about what is happening, you can use the special debug environment variable to turn up C++ side logging. Just set the environment variable PORTICO_DEBUG to TRACE and then run again. Perhaps post that output here.

Hope that helps,
Tim

Portico Support :: org.portico.impl.cpp13.ProxyRTIAmbassador issue

eunsol — Tue, 02 Mar 2010 18:59:23 GMT

Author: eunsol
Subject: org.portico.impl.cpp13.ProxyRTIAmbassador issue
Posted: Wed Mar 03, 2010 4:59 am (GMT 10)

Hello,

Currently, I have three different portico versions, 0.8, 0.9 and 1.0.1.
I was using version 0.8, and it worked perfectly fine.
version 0.9 was built successfully, so I changed RTI_HOME, and the test federate in example folder was worked.
Then, I tried to run two federates, and the following fatal error message shown up on the console.

Code:

RTI connection attempt: 1/50
FATAL [c++] Can't locate the org.portico.impl.cpp13.ProxyRTIAmbassador class
RTI connection failed: Failed to initialize the RTI ambassador: Can't locate org.portico.impl.cpp13.ProxyRTIAmbassador class
RTI connection retry wait.

Exact same thing happens in version 1.0.1.
Can you tell me anything wrong?

Thank you so much for your help
Regard,
Sol

Portico Support :: RE: 1516 evokeMultipleCallbacks(min,max) returns too soon

Lirgo — Wed, 24 Feb 2010 17:51:51 GMT

Author: Lirgo
Posted: Thu Feb 25, 2010 3:51 am (GMT 10)

Hi Tim!

It's probably as you describe it, because I send an interaction from one federate each time it advances the time and an object reflection from another federate also each time it advances the time.

I have done a handler that wraps it all up so that I don't need to copy-paste code on each federate. Both for version 1.3 and 1516. It's quite alot of code (~800 x 2 exluding foms) and it doesn't seem to be a way to attach files here on the forum. I have changed the code so that it handles delays by itself now instead, so it isn't any good test-case anymore, but I can try out an eventual fix by changing it back.

Really appreciate your help.

Cheers,

Johan

Portico Support :: RE: 1516 evokeMultipleCallbacks(min,max) returns too soon

tim — Wed, 24 Feb 2010 11:14:31 GMT

Author: tim
Posted: Wed Feb 24, 2010 9:14 pm (GMT 10)

Note: I've split this off into a separate topic

G'day Johan,

As far as I can tell from the code, evokeMultipleCallbacks(min,max) should wait at least as long as min. Have you got a bit of test code you can post that demonstrates it not waiting long enough?

Wandering through the code, the 1516 RtiAmbassador calls into the 1516 ImplHelper, which itself calls into the LRC. The LRC method looks like so:

Code:

public boolean tick( double minSeconds, double maxSeconds )
throws JRTIinternalError, JConcurrentAccessAttempted
{
// check for a concurrent access issue
state.checkAccess();

// signal that we are not ticking
state.setTicking( true );

try
{
// figure out how long we can tick for under min/max settings
long startTime = System.currentTimeMillis();
long minTime = startTime + (long)(minSeconds*1000);
long maxTime = startTime + (long)(maxSeconds*1000);

// poll until AT LEAST the minimum time
Timestamp minimumTimestamp = new Timestamp( minTime );
PorticoMessage message = state.messageQueue.pollUntil( minimumTimestamp );
if( message == null )
return false;

// process the message we got
tickProcess( message );

// keep processing messages while they are there and we have not exceeded the max time
while( System.currentTimeMillis() <= maxTime )
{
message = state.messageQueue.poll();
if( message == null )
return false;
else
tickProcess( message );
}

// return that there are more messaegs, this could technically be a lie if the message
// we processed before time ran out was the last message available, but it is likely
// that there is more work and that if there had been none we'd have gotten back null
// from poll() and returned false from within the above while()
return true;
}
finally
{
state.setTicking( false );
}
}

What *could* be happening is as follows:

1. It polls the message queue for a message, of which there is one
2. It processes that message
3. It still have time, so it goes back to see if there are more
4. There are not, but in this case, it doesn't wait (as it has already processed a message)
5. It returns, having processed at least one message, even though min might not have been reached yet.

This appears to be wrong according to 1516, but I think it is also being called by 1.3 for some other use. I suspect I'll need to write a separate implementation for 1516 (which shouldn't take too long).

I've filed a Jira issue for this problem here: http://jira.porticoproject.org/browse/PORT-913

Once I've fixed it, I'll get you to verify that it is working as expected for you as well.

Thanks for the bug report!

Cheers,
Tim