Portico Project Forums

Portico Support :: RE: Problem loading C++ federates on Turkish Locale Machines

tim — Fri, 05 Feb 2010 03:10:11 GMT

Author: tim
Posted: Fri Feb 05, 2010 1:10 pm (GMT 10)

Right, I hope I've fixed this in the latest SVN version. If you want to check it out and give it a try for me, that'd be fantastic!

Portico Support :: RE: Problem loading C++ federates on Turkish Locale Machines

tim — Fri, 05 Feb 2010 02:14:18 GMT

Author: tim
Posted: Fri Feb 05, 2010 12:14 pm (GMT 10)

I've split this off into a different topic so that it's easier to find. I've also registered the following Jira issue to fix the underlying problem:

http://jira.porticoproject.org/browse/PORT-910

Portico Support :: RE: Problem loading C++ federates on Turkish Locale Machines

tim — Fri, 05 Feb 2010 01:50:44 GMT

Author: tim
Posted: Fri Feb 05, 2010 11:50 am (GMT 10)

Well there you go. You learn something new every day! I shall attempt to put in a fix for this (as mentioned in the article - specifically specifying the English locale) for v1.0.2. Thanks for the heads up!

Portico Support :: Problem loading C++ federates on Turkish Locale Machines

qubeuc — Thu, 04 Feb 2010 12:31:10 GMT

Author: qubeuc
Posted: Thu Feb 04, 2010 10:31 pm (GMT 10)

Hi

In case any one hits same problem, I want to give my solution.
Our problem was related with operating system name that is taken by
system.getProperties function. When os.name is converted to uppercase
because of some language mismatch my os.name is converted to "W|NDOWS" instead of "WINDOWS". So that, jvm tries to load .so libraries.
I just change this check for now.

For more information, this link can be useful.
http://java.sys-con.com/node/46241

regards

Tc

Portico Support :: RE: problem of synchronization point

tim — Wed, 03 Feb 2010 01:33:34 GMT

Author: tim
Posted: Wed Feb 03, 2010 11:33 am (GMT 10)

The C++ federates have been tested with VC6, VC7 and GCC 4.2.1

I'm personally using Java 1.6.0_17 for development, but all code is compiled for and designed to run with anything down to Java 1.5.

The most current Portico version I've tested with is 1.0.1

There are no special settings required for the JVM

Portico Support :: RE: Unable to have synch callback in c++

tim — Wed, 03 Feb 2010 01:30:36 GMT

Author: tim
Posted: Wed Feb 03, 2010 11:30 am (GMT 10)

I'd suggest trying it again, but only turn up the Portico logging, not the JGroups logging. It's a bit hard to sift through that much unrelated output.

As for the C++ problem, is your RTI_HOME environment variable set properly? There is documentation on the website to help you getting started with C++ http://www.porticoproject.org/index.php?title=Getting_Started_With_Portico_C%2B%2B

Portico Support :: RE: Portico Simple Java Demo - Update Attribute

BillD — Tue, 02 Feb 2010 17:49:30 GMT

Author: BillD
Subject: RE: Portico Simple Java Demo - Update Attribute
Posted: Wed Feb 03, 2010 3:49 am (GMT 10)

Okay, read in different post that a federate does not receive its own data.

I created a new federate and tested it and the values seemed to be reflected just fine.

Thanks,
Bill

Portico Support :: Portico Simple Java Demo - Update Attribute

BillD — Tue, 02 Feb 2010 17:28:49 GMT

Author: BillD
Subject: Portico Simple Java Demo - Update Attribute
Posted: Wed Feb 03, 2010 3:28 am (GMT 10)

Hello,
I have been able to run the simple Java demo that is included with portico, and everything works fine without error, but in my output I do not see any logging of the UpdateAttribute callbacks. (Although I do get all of the Time Advance Notices)

It seems that because the Federate subscribes to its own object type, it should receive the call-backs in ReflectAttributeValues when the updates are sent, and then log the values.

I found a "testfom.fed" file on the Portico website that was much much longer than the included "fed" file, describing things like 'Manager' etc. Could this be the reason?

Thanks,
Bill

Portico Support :: RE: Unable to have synch callback in c++

qubeuc — Tue, 02 Feb 2010 11:08:08 GMT

Author: qubeuc
Posted: Tue Feb 02, 2010 9:08 pm (GMT 10)

G'day Tim

Thanks for your response.

When I try to run federate example on java, it is running properly using JAVA 1.6.
However, when I used C++ with JAVA 1.6, callback function never informs federate about initialization.
I have also tried jre given with Portico package, this jre throws an exception at jvm.dll as �Access violation reading location 0x0000000� at registerFederationSynchronizationPoint.
I am using VC++8.

Also I am getting following erros although I am using Windows

ERROR Could not locate Portico C++ library (libRTI-NG.so/librti13.so)
ERROR Make sure $RTI_HOME is set and $RTI_HOME/lib is on you

I have already defined _WIN32 macro.

As I see, whenever I used JAVA1.6 with C++ either federation thread (thread that is responsible from callbacks)
Hangs on one of the jni calls or exit abnormally without any notification or error.

My current configuration is :
Compiler : VC++8, Microsoft Visual Studio 2005
Java : JRE1.6
Portico : 1.0.1

My debug output is as following :

Portico.log

INFO [main] portico.lrc: Creating new LRC [default]
TRACE [main] portico.lrc: Provided connection implementation is "org.portico.bindings.jgroups.LrcConnection"
TRACE [main] portico.lrc: Trying to load connection class: org.portico.bindings.jgroups.LrcConnection
INFO [main] portico.lrc.jgroups: Starting JGroups LrcConnection...
INFO [main] portico.lrc: LRC [default] initialized (HLA version: HLA13)
DEBUG [main] portico.lrc: Parsing FED file (format=hla13): file:/d:/Tc/projects/TTT/codes/HLA/portico_/portico/portico/testfom.fed
DEBUG [main] portico.lrc: ATTEMPT Create federation execution [ExampleFederation]
TRACE [main] portico.lrc.jgroups: REQUEST createFederation: name=ExampleFederation
TRACE [main] portico.lrc.jgroups: ATTEMPT connecting to channel [ExampleFederation]
DEBUG [main] portico.lrc.jgroups: SUCCESS connected to channel [ExampleFederation]
TRACE [main] portico.lrc.jgroups: (outgoing) {OOB|MSG_CREATE} channel=ExampleFederation, size=17173
TRACE [Incoming-5,ExampleFederation,195.87.YYY.XXX:4249] portico.lrc.jgroups: (incoming) synchronous, channel=ExampleFederation, size=17173, source=195.87.YYY.XXX:4249
TRACE [Incoming-5,ExampleFederation,195.87.YYY.XXX:4249] portico.lrc.jgroups: Received federation creation notification: federation=ExampleFederation, fomSize=17173, source=195.87.YYY.XXX:4249
INFO [Incoming-5,ExampleFederation,195.87.YYY.XXX:4249] portico.lrc.jgroups: Federation [ExampleFederation] has been created
INFO [main] portico.lrc.jgroups: SUCCESS createFederation: name=ExampleFederation
INFO [main] portico.lrc: SUCCESS Created federation execution [ExampleFederation]
DEBUG [main] portico.lrc: ATTEMPT Join federate [exampleFederate] to federation [ExampleFederation]
TRACE [main] portico.lrc.jgroups: REQUEST joinFederation: federate=exampleFederate, federation=ExampleFederation
TRACE [main] portico.lrc.jgroups: (outgoing) {OOB|MSG_JOINED} channel=ExampleFederation, size=15
TRACE [Incoming-6,ExampleFederation,195.87.YYY.XXX:4249] portico.lrc.jgroups: (incoming) synchronous, channel=ExampleFederation, size=15, source=195.87.YYY.XXX:4249
TRACE [Incoming-6,ExampleFederation,195.87.YYY.XXX:4249] portico.lrc.jgroups: Received federate join notification: federate=exampleFederate, federation=ExampleFederation, source=195.87.YYY.XXX:4249
INFO [Incoming-6,ExampleFederation,195.87.YYY.XXX:4249] portico.lrc.jgroups: Federate [exampleFederate] joined federation [ExampleFederation]
TRACE [main] portico.lrc: Created Mom.Federation object, added to Repository (undiscovered)
TRACE [main] portico.lrc: Created Mom.Federate(exampleFederate), queued discovery notification
TRACE [main] portico.lrc.jgroups: (outgoing) payload=RoleCall, size=562, channel=ExampleFederation
TRACE [Incoming-5,ExampleFederation,195.87.YYY.XXX:4249] portico.lrc.jgroups: (incoming) asynchronous, channel=ExampleFederation, size=562, source=195.87.YYY.XXX:4249
TRACE [main] portico.lrc: joined federation, waiting for RoleCalls from [1]
INFO [main] portico.lrc: SUCCESS Joined federate [exampleFederate] to federation [ExampleFederation]: handle=1
DEBUG [main] portico.lrc: ATTEMPT Register sync point [ReadyToRun] by [exampleFederate]
DEBUG [main] portico.lrc: PENDING Register synchronization point [ReadyToRun] by [exampleFederate]
TRACE [main] portico.lrc.jgroups: (outgoing) payload=SyncRegistrationRequest, size=370, channel=ExampleFederation
TRACE [Incoming-6,ExampleFederation,195.87.YYY.XXX:4249] portico.lrc.jgroups: (incoming) synchronous, channel=ExampleFederation, size=370, source=195.87.YYY.XXX:4249
TRACE [main] portico.lrc.jgroups: (outgoing) payload=SyncPointAnnouncement, size=402, channel=ExampleFederation
INFO [main] portico.lrc: SUCCESS Registered sync point [ReadyToRun] by [exampleFederate]
TRACE [Incoming-6,ExampleFederation,195.87.YYY.XXX:4249] portico.lrc.jgroups: (incoming) asynchronous, channel=ExampleFederation, size=402, source=195.87.YYY.XXX:4249
TRACE [main] portico.lrc: @REMOTE Received MOM object discovery for federate [MOM.Federate(exampleFederate)]
DEBUG [main] portico.lrc: DISCARD Discovery of object (not subscribed): object=<unknown>
TRACE [main] portico.lrc: CALLBACK synchronizationPointRegistrationSucceeded(label=ReadyToRun)

All console output

ERROR Could not locate Portico C++ library (libRTI-NG.so/librti13.so)
ERROR Make sure $RTI_HOME is set and $RTI_HOME/lib is on you $LD_LIBRARY_PATH
INFO [main] portico.lrc: Creating new LRC [default]
TRACE [main] portico.lrc: Provided connection implementation is "org.portico.bindings.jgroups.LrcConnection"
TRACE [main] portico.lrc: Trying to load connection class: org.portico.bindings.jgroups.LrcConnection
INFO [main] portico.lrc.jgroups: Starting JGroups LrcConnection...
INFO [main] portico.lrc: LRC [default] initialized (HLA version: HLA13)
DEBUG [main] portico.lrc: Parsing FED file (format=hla13): file:/d:/Tc/projects/TTT/codes/HLA/portico_/portico/portico/testfom.fed
DEBUG [main] portico.lrc: ATTEMPT Create federation execution [ExampleFederation]
TRACE [main] portico.lrc.jgroups: REQUEST createFederation: name=ExampleFederation
TRACE [main] portico.lrc.jgroups: ATTEMPT connecting to channel [ExampleFederation]
INFO [main] org.jgroups.JChannel: JGroups version: 2.6.9.GA
DEBUG [main] org.jgroups.conf.ClassConfigurator: mapping is:
1: class org.jgroups.stack.IpAddress
2: class org.jgroups.protocols.CAUSAL$CausalHeader
3: class org.jgroups.protocols.FD$FdHeader
6: class org.jgroups.protocols.FD_SOCK$FdHeader
7: class org.jgroups.protocols.FragHeader
13: class org.jgroups.protocols.PingHeader
14: class org.jgroups.protocols.TcpHeader
19: class org.jgroups.protocols.TunnelHeader
20: class org.jgroups.protocols.UdpHeader
21: class org.jgroups.protocols.UNICAST$UnicastHeader
22: class org.jgroups.protocols.VERIFY_SUSPECT$VerifyHeader
24: class org.jgroups.protocols.pbcast.GMS$GmsHeader
25: class org.jgroups.protocols.pbcast.NakAckHeader
27: class org.jgroups.protocols.pbcast.STABLE$StableHeader
28: class org.jgroups.protocols.pbcast.STATE_TRANSFER$StateHeader
29: class org.jgroups.protocols.SMACK$SmackHeader
30: class org.jgroups.Message
31: class org.jgroups.View
32: class org.jgroups.ViewId
34: interface org.jgroups.Address
35: class org.jgroups.blocks.RequestCorrelator$Header
36: class org.jgroups.protocols.PingRsp
38: class java.util.Vector
39: class org.jgroups.protocols.pbcast.JoinRsp
40: class org.jgroups.util.Digest
41: class java.util.Hashtable
53: class org.jgroups.protocols.COMPRESS$CompressHeader
54: class org.jgroups.protocols.FC$FcHeader
56: class org.jgroups.protocols.TpHeader
57: class org.jgroups.protocols.ENCRYPT$EncryptHeader
58: class org.jgroups.protocols.SEQUENCER$SequencerHeader
59: class org.jgroups.protocols.FD_SIMPLE$FdHeader
60: class org.jgroups.protocols.VIEW_SYNC$ViewSyncHeader
61: class org.jgroups.protocols.FD_ALL$Header
62: class org.jgroups.protocols.SFC$Header
63: class org.jgroups.mux.MuxHeader
64: class org.jgroups.protocols.pbcast.FLUSH$FlushHeader
65: class org.jgroups.protocols.pbcast.STREAMING_STATE_TRANSFER$StateHeader
66: class org.jgroups.blocks.PullPushAdapter$PullHeader
67: class org.jgroups.protocols.AuthHeader
68: class org.jgroups.protocols.MERGE3$CoordAnnouncement

DEBUG [main] org.jgroups.protocols.pbcast.GMS: changed role to org.jgroups.protocols.pbcast.ClientGmsImpl
DEBUG [main] org.jgroups.protocols.FRAG2: frag_size=63000, overhead=200, new frag_size=62800
DEBUG [main] org.jgroups.protocols.FRAG2: received CONFIG event: {bind_addr=ZZZZZZZ-d2/195.87.YYY.XXX}
DEBUG [main] org.jgroups.protocols.UDP: received CONFIG event: {bind_addr=ZZZZZZZ-d2/195.87.YYY.XXX}
TRACE [main] org.jgroups.protocols.pbcast.STABLE: stable task started
DEBUG [main] org.jgroups.protocols.UDP: creating sockets and starting threads
DEBUG [main] org.jgroups.protocols.UDP: sockets will use interface 195.87.YYY.XXX
TRACE [FD_SOCK server socket acceptor-1] org.jgroups.protocols.FD_SOCK: waiting for client connections on ZZZZZZZ-d2/195.87.YYY.XXX:4248
DEBUG [main] org.jgroups.protocols.UDP: socket information:
local_addr=195.87.YYY.XXX:4249, mcast_addr=228.10.10.10:20913, bind_addr=ZZZZZZZ-d2/195.87.YYY.XXX, ttl=2
sock: bound to 195.87.YYY.XXX:4249, receive buffer size=20000000, send buffer size=640000
mcast_sock: bound to 195.87.YYY.XXX:20913, send buffer size=640000, receive buffer size=25000000
TRACE [main] org.jgroups.blocks.MessageDispatcher$ProtocolAdapter: setting local_addr (null) to 195.87.YYY.XXX:4249
DEBUG [main] org.jgroups.protocols.UDP: created unicast receiver thread Thread[UDP ucast-3,ExampleFederation,195.87.YYY.XXX:4249,5,JGroups]
DEBUG [main] org.jgroups.protocols.UDP: created multicast receiver thread Thread[UDP mcast-4,ExampleFederation,195.87.YYY.XXX:4249,10,JGroups]
TRACE [Timer-1,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UDP: sending msg to null, src=195.87.YYY.XXX:4249, headers are PING: [PING: type=GET_MBRS_REQ, arg=null], UDP: [channel_name=ExampleFederation]
TRACE [Timer-1,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UDP: looping back message [dst: <null>, src: 195.87.YYY.XXX:4249 (2 headers), size=0 bytes, flags=OOB]
TRACE [Incoming-5,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UDP: message is [dst: <null>, src: 195.87.YYY.XXX:4249 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, arg=null], UDP: [channel_name=ExampleFederation]
TRACE [UDP mcast-4,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UDP: received (mcast) 55 bytes from 195.87.YYY.XXX:20913
TRACE [Timer-1,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UDP: sending msg to null, src=195.87.YYY.XXX:4249, headers are PING: [PING: type=GET_MBRS_REQ, arg=null], UDP: [channel_name=ExampleFederation]
TRACE [Timer-1,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UDP: looping back message [dst: <null>, src: 195.87.YYY.XXX:4249 (2 headers), size=0 bytes, flags=OOB]
TRACE [Incoming-5,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UDP: message is [dst: <null>, src: 195.87.YYY.XXX:4249 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, arg=null], UDP: [channel_name=ExampleFederation]
TRACE [UDP mcast-4,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UDP: received (mcast) 55 bytes from 195.87.YYY.XXX:20913
TRACE [main] org.jgroups.protocols.PING: discovery took 2000 ms: responses: 0 total (0 servers (0 coord), 0 clients)
DEBUG [main] org.jgroups.protocols.pbcast.GMS: initial_mbrs are []
DEBUG [main] org.jgroups.protocols.pbcast.GMS: no initial members discovered: creating group as first member
DEBUG [main] org.jgroups.protocols.pbcast.GMS: [local_addr=195.87.YYY.XXX:4249] view is [195.87.YYY.XXX:4249|0] [195.87.YYY.XXX:4249]
DEBUG [Timer-1,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.FD_SOCK: VIEW_CHANGE received: [195.87.YYY.XXX:4249]
TRACE [main] org.jgroups.protocols.pbcast.STABLE: resetting digest from NAKACK: [195.87.YYY.XXX:4249#0]
TRACE [main] org.jgroups.protocols.FC: new membership: [195.87.YYY.XXX:4249]
TRACE [main] org.jgroups.protocols.FC: creditors are []
DEBUG [main] org.jgroups.protocols.pbcast.GMS: 195.87.YYY.XXX:4249 changed role to org.jgroups.protocols.pbcast.CoordGmsImpl
DEBUG [main] org.jgroups.protocols.pbcast.GMS: created group (first member). My view is [195.87.YYY.XXX:4249|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
DEBUG [main] portico.lrc.jgroups: SUCCESS connected to channel [ExampleFederation]
TRACE [main] portico.lrc.jgroups: (outgoing) {OOB|MSG_CREATE} channel=ExampleFederation, size=17173
TRACE [main] org.jgroups.blocks.MessageDispatcher: real_dests=[195.87.YYY.XXX:4249]
TRACE [main] org.jgroups.blocks.GroupRequest: sending request (id=1265104507477)
TRACE [main] org.jgroups.protocols.pbcast.NAKACK: sending 195.87.YYY.XXX:4249#1
TRACE [main] org.jgroups.protocols.UDP: sending msg to null, src=195.87.YYY.XXX:4249, headers are MsgDisp: [Header: name=MsgDisp, type=REQ, id=1265104507477, rsp_expected=true], dest_mbrs=[195.87.YYY.XXX:4249], NAKACK: [MSG, seqno=1], UDP: [channel_name=ExampleFederation]
TRACE [main] org.jgroups.protocols.UDP: looping back message [dst: <null>, src: 195.87.YYY.XXX:4249 (3 headers), size=17173 bytes, flags=OOB|HIGH_PRIO]
TRACE [Incoming-5,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UDP: message is [dst: <null>, src: 195.87.YYY.XXX:4249 (3 headers), size=17173 bytes, flags=OOB|HIGH_PRIO], headers are MsgDisp: [Header: name=MsgDisp, type=REQ, id=1265104507477, rsp_expected=true], dest_mbrs=[195.87.YYY.XXX:4249], NAKACK: [MSG, seqno=1], UDP: [channel_name=ExampleFederation]
TRACE [Incoming-5,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.pbcast.NAKACK: [195.87.YYY.XXX:4249: received 195.87.YYY.XXX:4249#1
TRACE [Incoming-5,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.FC: sender 195.87.YYY.XXX:4249 minus 17173 credits, 982827 remaining
TRACE [Incoming-5,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.FC: sender 195.87.YYY.XXX:4249 minus 17173 credits, 982827 remaining
TRACE [Incoming-5,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.blocks.RequestCorrelator: calling (org.jgroups.blocks.MessageDispatcher) with request 1265104507477
TRACE [Incoming-5,ExampleFederation,195.87.YYY.XXX:4249] portico.lrc.jgroups: (incoming) synchronous, channel=ExampleFederation, size=17173, source=195.87.YYY.XXX:4249
TRACE [Incoming-5,ExampleFederation,195.87.YYY.XXX:4249] portico.lrc.jgroups: Received federation creation notification: federation=ExampleFederation, fomSize=17173, source=195.87.YYY.XXX:4249
TRACE [UDP mcast-4,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UDP: received (mcast) 17289 bytes from 195.87.YYY.XXX:20913
INFO [Incoming-5,ExampleFederation,195.87.YYY.XXX:4249] portico.lrc.jgroups: Federation [ExampleFederation] has been created
TRACE [Incoming-5,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.blocks.RequestCorrelator: sending rsp for 1265104507477 to 195.87.YYY.XXX:4249
TRACE [Incoming-5,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.FC: sender 195.87.YYY.XXX:4249 minus 7 credits, 982820 remaining
TRACE [Incoming-5,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UNICAST: 195.87.YYY.XXX:4249: created new connection for dst 195.87.YYY.XXX:4249
TRACE [Incoming-5,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UNICAST: 195.87.YYY.XXX:4249 --> DATA(195.87.YYY.XXX:4249: #1
TRACE [Incoming-5,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UDP: sending msg to 195.87.YYY.XXX:4249, src=195.87.YYY.XXX:4249, headers are MsgDisp: [Header: name=MsgDisp, type=RSP, id=1265104507477, rsp_expected=false], UNICAST: [UNICAST: DATA, seqno=1], UDP: [channel_name=ExampleFederation]
TRACE [Incoming-5,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UDP: looping back message [dst: 195.87.YYY.XXX:4249, src: 195.87.YYY.XXX:4249 (3 headers), size=7 bytes, flags=OOB]
TRACE [Incoming-6,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UDP: message is [dst: 195.87.YYY.XXX:4249, src: 195.87.YYY.XXX:4249 (3 headers), size=7 bytes, flags=OOB], headers are MsgDisp: [Header: name=MsgDisp, type=RSP, id=1265104507477, rsp_expected=false], UNICAST: [UNICAST: DATA, seqno=1], UDP: [channel_name=ExampleFederation]
TRACE [Incoming-6,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UNICAST: 195.87.YYY.XXX:4249 <DATA> ACK(195.87.YYY.XXX:4249: #1)
TRACE [main] org.jgroups.blocks.GroupRequest: received all responses: [req_id=1265104507477
caller=195.87.YYY.XXX:4249
entries:
195.87.YYY.XXX:4249: sender=195.87.YYY.XXX:4249, retval=ACK, received=true, suspected=false

TRACE [Incoming-6,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UDP: sending msg to 195.87.YYY.XXX:4249, src=195.87.YYY.XXX:4249, headers are UNICAST: [UNICAST: ACK, seqno=1], UDP: [channel_name=ExampleFederation]
TRACE [Incoming-6,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UDP: looping back message [dst: 195.87.YYY.XXX:4249, src: 195.87.YYY.XXX:4249 (2 headers), size=0 bytes, flags=OOB]
TRACE [Incoming-5,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UDP: message is [dst: 195.87.YYY.XXX:4249, src: 195.87.YYY.XXX:4249 (2 headers), size=0 bytes, flags=OOB], headers are UNICAST: [UNICAST: ACK, seqno=1], UDP: [channel_name=ExampleFederation]
TRACE [Incoming-5,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UNICAST: 195.87.YYY.XXX:4249 <-- ACK(195.87.YYY.XXX:4249: #1)
INFO [main] portico.lrc.jgroups: SUCCESS createFederation: name=ExampleFederation
INFO [main] portico.lrc: SUCCESS Created federation execution [ExampleFederation]
Created Federation
DEBUG [main] portico.lrc: ATTEMPT Join federate [exampleFederate] to federation [ExampleFederation]
TRACE [main] portico.lrc.jgroups: REQUEST joinFederation: federate=exampleFederate, federation=ExampleFederation
TRACE [main] portico.lrc.jgroups: (outgoing) {OOB|MSG_JOINED} channel=ExampleFederation, size=15
TRACE [main] org.jgroups.blocks.MessageDispatcher: real_dests=[195.87.YYY.XXX:4249]
TRACE [main] org.jgroups.blocks.GroupRequest: sending request (id=1265104507508)
TRACE [main] org.jgroups.protocols.pbcast.NAKACK: sending 195.87.YYY.XXX:4249#2
TRACE [main] org.jgroups.protocols.UDP: sending msg to null, src=195.87.YYY.XXX:4249, headers are MsgDisp: [Header: name=MsgDisp, type=REQ, id=1265104507508, rsp_expected=true], dest_mbrs=[195.87.YYY.XXX:4249], NAKACK: [MSG, seqno=2], UDP: [channel_name=ExampleFederation]
TRACE [main] org.jgroups.protocols.UDP: looping back message [dst: <null>, src: 195.87.YYY.XXX:4249 (3 headers), size=15 bytes, flags=OOB|HIGH_PRIO]
TRACE [Incoming-6,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UDP: message is [dst: <null>, src: 195.87.YYY.XXX:4249 (3 headers), size=15 bytes, flags=OOB|HIGH_PRIO], headers are MsgDisp: [Header: name=MsgDisp, type=REQ, id=1265104507508, rsp_expected=true], dest_mbrs=[195.87.YYY.XXX:4249], NAKACK: [MSG, seqno=2], UDP: [channel_name=ExampleFederation]
TRACE [Incoming-6,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.pbcast.NAKACK: [195.87.YYY.XXX:4249: received 195.87.YYY.XXX:4249#2
TRACE [Incoming-6,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.FC: sender 195.87.YYY.XXX:4249 minus 15 credits, 982805 remaining
TRACE [Incoming-6,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.FC: sender 195.87.YYY.XXX:4249 minus 15 credits, 982805 remaining
TRACE [UDP mcast-4,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UDP: received (mcast) 131 bytes from 195.87.YYY.XXX:20913
TRACE [Incoming-6,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.blocks.RequestCorrelator: calling (org.jgroups.blocks.MessageDispatcher) with request 1265104507508
TRACE [Incoming-6,ExampleFederation,195.87.YYY.XXX:4249] portico.lrc.jgroups: (incoming) synchronous, channel=ExampleFederation, size=15, source=195.87.YYY.XXX:4249
TRACE [Incoming-6,ExampleFederation,195.87.YYY.XXX:4249] portico.lrc.jgroups: Received federate join notification: federate=exampleFederate, federation=ExampleFederation, source=195.87.YYY.XXX:4249
INFO [Incoming-6,ExampleFederation,195.87.YYY.XXX:4249] portico.lrc.jgroups: Federate [exampleFederate] joined federation [ExampleFederation]
TRACE [Incoming-6,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.blocks.RequestCorrelator: sending rsp for 1265104507508 to 195.87.YYY.XXX:4249
TRACE [Incoming-6,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.FC: sender 195.87.YYY.XXX:4249 minus 7 credits, 982798 remaining
TRACE [Incoming-6,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UNICAST: 195.87.YYY.XXX:4249 --> DATA(195.87.YYY.XXX:4249: #2
TRACE [Incoming-6,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UDP: sending msg to 195.87.YYY.XXX:4249, src=195.87.YYY.XXX:4249, headers are MsgDisp: [Header: name=MsgDisp, type=RSP, id=1265104507508, rsp_expected=false], UNICAST: [UNICAST: DATA, seqno=2], UDP: [channel_name=ExampleFederation]
TRACE [Incoming-6,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UDP: looping back message [dst: 195.87.YYY.XXX:4249, src: 195.87.YYY.XXX:4249 (3 headers), size=7 bytes, flags=OOB]
TRACE [Incoming-5,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UDP: message is [dst: 195.87.YYY.XXX:4249, src: 195.87.YYY.XXX:4249 (3 headers), size=7 bytes, flags=OOB], headers are MsgDisp: [Header: name=MsgDisp, type=RSP, id=1265104507508, rsp_expected=false], UNICAST: [UNICAST: DATA, seqno=2], UDP: [channel_name=ExampleFederation]
TRACE [Incoming-5,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UNICAST: 195.87.YYY.XXX:4249 <DATA> ACK(195.87.YYY.XXX:4249: #2)
TRACE [Incoming-5,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UDP: sending msg to 195.87.YYY.XXX:4249, src=195.87.YYY.XXX:4249, headers are UNICAST: [UNICAST: ACK, seqno=2], UDP: [channel_name=ExampleFederation]
TRACE [Incoming-5,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UDP: looping back message [dst: 195.87.YYY.XXX:4249, src: 195.87.YYY.XXX:4249 (2 headers), size=0 bytes, flags=OOB]
TRACE [Incoming-6,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UDP: message is [dst: 195.87.YYY.XXX:4249, src: 195.87.YYY.XXX:4249 (2 headers), size=0 bytes, flags=OOB], headers are UNICAST: [UNICAST: ACK, seqno=2], UDP: [channel_name=ExampleFederation]
TRACE [Incoming-6,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UNICAST: 195.87.YYY.XXX:4249 <-- ACK(195.87.YYY.XXX:4249: #2)
TRACE [main] portico.lrc: Created Mom.Federation object, added to Repository (undiscovered)
TRACE [main] portico.lrc: Created Mom.Federate(exampleFederate), queued discovery notification
TRACE [main] portico.lrc.jgroups: (outgoing) payload=RoleCall, size=562, channel=ExampleFederation
TRACE [main] org.jgroups.protocols.pbcast.NAKACK: sending 195.87.YYY.XXX:4249#3
TRACE [main] org.jgroups.protocols.UDP: sending msg to null, src=195.87.YYY.XXX:4249, headers are NAKACK: [MSG, seqno=3], UDP: [channel_name=ExampleFederation]
TRACE [main] org.jgroups.protocols.UDP: looping back message [dst: <null>, src: 195.87.YYY.XXX:4249 (2 headers), size=562 bytes]
TRACE [Incoming-5,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UDP: message is [dst: <null>, src: 195.87.YYY.XXX:4249 (2 headers), size=562 bytes], headers are NAKACK: [MSG, seqno=3], UDP: [channel_name=ExampleFederation]
TRACE [Incoming-5,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.pbcast.NAKACK: [195.87.YYY.XXX:4249: received 195.87.YYY.XXX:4249#3
TRACE [Incoming-5,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.FC: sender 195.87.YYY.XXX:4249 minus 562 credits, 982236 remaining
TRACE [Incoming-5,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.FC: sender 195.87.YYY.XXX:4249 minus 562 credits, 982236 remaining
TRACE [Incoming-5,ExampleFederation,195.87.YYY.XXX:4249] portico.lrc.jgroups: (incoming) asynchronous, channel=ExampleFederation, size=562, source=195.87.YYY.XXX:4249
TRACE [main] portico.lrc: joined federation, waiting for RoleCalls from [1]
INFO [main] portico.lrc: SUCCESS Joined federate [exampleFederate] to federation [ExampleFederation]: handle=1
Joined Federation as exampleFederate
initialized
DEBUG [main] portico.lrc: ATTEMPT Register sync point [ReadyToRun] by [exampleFederate]
DEBUG [main] portico.lrc: PENDING Register synchronization point [ReadyToRun] by [exampleFederate]
TRACE [main] portico.lrc.jgroups: (outgoing) payload=SyncRegistrationRequest, size=370, channel=ExampleFederation
TRACE [main] org.jgroups.blocks.MessageDispatcher: real_dests=[195.87.YYY.XXX:4249]
TRACE [main] org.jgroups.blocks.GroupRequest: sending request (id=1265104507524)
TRACE [main] org.jgroups.protocols.pbcast.NAKACK: sending 195.87.YYY.XXX:4249#4
TRACE [main] org.jgroups.protocols.UDP: sending msg to null, src=195.87.YYY.XXX:4249, headers are MsgDisp: [Header: name=MsgDisp, type=REQ, id=1265104507524, rsp_expected=true], dest_mbrs=[195.87.YYY.XXX:4249], NAKACK: [MSG, seqno=4], UDP: [channel_name=ExampleFederation]
TRACE [main] org.jgroups.protocols.UDP: looping back message [dst: <null>, src: 195.87.YYY.XXX:4249 (3 headers), size=370 bytes]
TRACE [Incoming-6,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UDP: message is [dst: <null>, src: 195.87.YYY.XXX:4249 (3 headers), size=370 bytes], headers are MsgDisp: [Header: name=MsgDisp, type=REQ, id=1265104507524, rsp_expected=true], dest_mbrs=[195.87.YYY.XXX:4249], NAKACK: [MSG, seqno=4], UDP: [channel_name=ExampleFederation]
TRACE [Incoming-6,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.pbcast.NAKACK: [195.87.YYY.XXX:4249: received 195.87.YYY.XXX:4249#4
TRACE [Incoming-6,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.FC: sender 195.87.YYY.XXX:4249 minus 370 credits, 981866 remaining
TRACE [Incoming-6,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.FC: sender 195.87.YYY.XXX:4249 minus 370 credits, 981866 remaining
TRACE [Incoming-6,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.blocks.RequestCorrelator: calling (org.jgroups.blocks.MessageDispatcher) with request 1265104507524
TRACE [Incoming-6,ExampleFederation,195.87.YYY.XXX:4249] portico.lrc.jgroups: (incoming) synchronous, channel=ExampleFederation, size=370, source=195.87.YYY.XXX:4249
TRACE [Incoming-6,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.blocks.RequestCorrelator: sending rsp for 1265104507524 to 195.87.YYY.XXX:4249
TRACE [Incoming-6,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.stack.ProtocolStack: released lock held by Thread[Incoming-6,ExampleFederation,195.87.YYY.XXX:4249,10,JGroups]
TRACE [Incoming-6,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.FC: sender 195.87.YYY.XXX:4249 minus 1 credits, 981865 remaining
TRACE [Incoming-6,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UNICAST: 195.87.YYY.XXX:4249 --> DATA(195.87.YYY.XXX:4249: #3
TRACE [Incoming-6,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UDP: sending msg to 195.87.YYY.XXX:4249, src=195.87.YYY.XXX:4249, headers are MsgDisp: [Header: name=MsgDisp, type=RSP, id=1265104507524, rsp_expected=false], UNICAST: [UNICAST: DATA, seqno=3], UDP: [channel_name=ExampleFederation]
TRACE [Incoming-6,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UDP: looping back message [dst: 195.87.YYY.XXX:4249, src: 195.87.YYY.XXX:4249 (3 headers), size=1 bytes, flags=OOB]
TRACE [Incoming-5,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UDP: message is [dst: 195.87.YYY.XXX:4249, src: 195.87.YYY.XXX:4249 (3 headers), size=1 bytes, flags=OOB], headers are MsgDisp: [Header: name=MsgDisp, type=RSP, id=1265104507524, rsp_expected=false], UNICAST: [UNICAST: DATA, seqno=3], UDP: [channel_name=ExampleFederation]
TRACE [Incoming-5,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UNICAST: 195.87.YYY.XXX:4249 <DATA> ACK(195.87.YYY.XXX:4249: #3)
TRACE [Incoming-5,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UDP: sending msg to 195.87.YYY.XXX:4249, src=195.87.YYY.XXX:4249, headers are UNICAST: [UNICAST: ACK, seqno=3], UDP: [channel_name=ExampleFederation]
TRACE [Incoming-5,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UDP: looping back message [dst: 195.87.YYY.XXX:4249, src: 195.87.YYY.XXX:4249 (2 headers), size=0 bytes, flags=OOB]
TRACE [Incoming-6,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UDP: message is [dst: 195.87.YYY.XXX:4249, src: 195.87.YYY.XXX:4249 (2 headers), size=0 bytes, flags=OOB], headers are UNICAST: [UNICAST: ACK, seqno=3], UDP: [channel_name=ExampleFederation]
TRACE [Incoming-6,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UNICAST: 195.87.YYY.XXX:4249 <-- ACK(195.87.YYY.XXX:4249: #3)
TRACE [Timer-4,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UDP: sending 2 msgs (1112 bytes (1,77% of max_bundle_size), collected in 15ms) to 1 destination(s)
TRACE [UDP mcast-4,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UDP: received (mcast) 1129 bytes from 195.87.YYY.XXX:20913
TRACE [main] org.jgroups.blocks.GroupRequest: timed out waiting for responses
TRACE [main] org.jgroups.blocks.GroupRequest: call did not execute correctly, request is [req_id=1265104507524
caller=195.87.YYY.XXX:4249
entries:
195.87.YYY.XXX:4249: sender=195.87.YYY.XXX:4249, retval=null, received=false, suspected=false

TRACE [main] portico.lrc.jgroups: (outgoing) payload=SyncPointAnnouncement, size=402, channel=ExampleFederation
TRACE [main] org.jgroups.protocols.pbcast.NAKACK: sending 195.87.YYY.XXX:4249#5
TRACE [main] org.jgroups.protocols.UDP: sending msg to null, src=195.87.YYY.XXX:4249, headers are NAKACK: [MSG, seqno=5], UDP: [channel_name=ExampleFederation]
TRACE [main] org.jgroups.protocols.UDP: looping back message [dst: <null>, src: 195.87.YYY.XXX:4249 (2 headers), size=402 bytes]
INFO [main] portico.lrc: SUCCESS Registered sync point [ReadyToRun] by [exampleFederate]
isAnnounded
TRACE [Incoming-6,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UDP: message is [dst: <null>, src: 195.87.YYY.XXX:4249 (2 headers), size=402 bytes], headers are NAKACK: [MSG, seqno=5], UDP: [channel_name=ExampleFederation]
TRACE [Incoming-6,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.pbcast.NAKACK: [195.87.YYY.XXX:4249: received 195.87.YYY.XXX:4249#5
TRACE [Incoming-6,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.FC: sender 195.87.YYY.XXX:4249 minus 402 credits, 981463 remaining
TRACE [Incoming-6,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.FC: sender 195.87.YYY.XXX:4249 minus 402 credits, 981463 remaining
TRACE [Incoming-6,ExampleFederation,195.87.YYY.XXX:4249] portico.lrc.jgroups: (incoming) asynchronous, channel=ExampleFederation, size=402, source=195.87.YYY.XXX:4249
TRACE [main] portico.lrc: @REMOTE Received MOM object discovery for federate [MOM.Federate(exampleFederate)]
DEBUG [main] portico.lrc: DISCARD Discovery of object (not subscribed): object=<unknown>
TRACE [main] portico.lrc: CALLBACK synchronizationPointRegistrationSucceeded(label=ReadyToRun)
TRACE [Timer-1,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UDP: sending 1 msgs (469 bytes (0,74% of max_bundle_size), collected in 31ms) to 1 destination(s)
TRACE [UDP mcast-4,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UDP: received (mcast) 486 bytes from 195.87.YYY.XXX:20913
TRACE [Timer-3,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.pbcast.STABLE: setting latest_local_digest from NAKACK: [195.87.YYY.XXX:4249#5]
TRACE [Timer-3,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.pbcast.STABLE: sending stable msg [195.87.YYY.XXX:4249#5]
TRACE [Timer-1,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.pbcast.NAKACK: sending 195.87.YYY.XXX:4249#6
TRACE [Timer-1,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UDP: sending msg to null, src=195.87.YYY.XXX:4249, headers are STABLE: [STABLE_GOSSIP]: digest is 195.87.YYY.XXX:4249: [0 : 5 (5)], NAKACK: [MSG, seqno=6], UDP: [channel_name=ExampleFederation]
TRACE [Timer-1,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UDP: looping back message [dst: <null>, src: 195.87.YYY.XXX:4249 (3 headers), size=0 bytes, flags=OOB]
TRACE [Incoming-6,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UDP: message is [dst: <null>, src: 195.87.YYY.XXX:4249 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABLE_GOSSIP]: digest is 195.87.YYY.XXX:4249: [0 : 5 (5)], NAKACK: [MSG, seqno=6], UDP: [channel_name=ExampleFederation]
TRACE [Incoming-6,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.pbcast.NAKACK: [195.87.YYY.XXX:4249: received 195.87.YYY.XXX:4249#6
TRACE [UDP mcast-4,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UDP: received (mcast) 119 bytes from 195.87.YYY.XXX:20913
TRACE [Incoming-6,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.pbcast.STABLE: [195.87.YYY.XXX:4249] handling digest from 195.87.YYY.XXX:4249 (0 votes):
mine: [195.87.YYY.XXX:4249#0]
other: [195.87.YYY.XXX:4249#5]
result: [195.87.YYY.XXX:4249#0]

TRACE [Incoming-6,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.pbcast.STABLE: sending stability msg (in 569 ms) [195.87.YYY.XXX:4249#0] (copy=27697575)
TRACE [Timer-4,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.pbcast.STABLE: sending stability msg [195.87.YYY.XXX:4249#0] (copy=27697575)
TRACE [Timer-4,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.pbcast.NAKACK: sending 195.87.YYY.XXX:4249#7
TRACE [Timer-4,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UDP: sending msg to null, src=195.87.YYY.XXX:4249, headers are STABLE: [STABILITY]: digest is 195.87.YYY.XXX:4249: [0 : 0 (5)], NAKACK: [MSG, seqno=7], UDP: [channel_name=ExampleFederation]
TRACE [Timer-4,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UDP: looping back message [dst: <null>, src: 195.87.YYY.XXX:4249 (3 headers), size=0 bytes, flags=OOB]
TRACE [Incoming-5,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UDP: message is [dst: <null>, src: 195.87.YYY.XXX:4249 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABILITY]: digest is 195.87.YYY.XXX:4249: [0 : 0 (5)], NAKACK: [MSG, seqno=7], UDP: [channel_name=ExampleFederation]
TRACE [Incoming-5,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.pbcast.NAKACK: [195.87.YYY.XXX:4249: received 195.87.YYY.XXX:4249#7
TRACE [Incoming-5,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.pbcast.STABLE: received stability msg from 195.87.YYY.XXX:4249: [195.87.YYY.XXX:4249#0]
TRACE [Incoming-5,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.pbcast.STABLE: resetting digest from NAKACK: [195.87.YYY.XXX:4249#6]
TRACE [UDP mcast-4,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.UDP: received (mcast) 119 bytes from 195.87.YYY.XXX:20913
TRACE [Incoming-5,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.pbcast.NAKACK: received stable digest 195.87.YYY.XXX:4249: [0 : 0 (5)]
TRACE [Incoming-5,ExampleFederation,195.87.YYY.XXX:4249] org.jgroups.protocols.pbcast.NAKACK: deleting msgs <= 0 from 195.87.YYY.XXX:4249

Thanks in advance

Tc

Portico Support :: RE: problem of synchronization point

qubeuc — Tue, 02 Feb 2010 11:00:54 GMT

Author: qubeuc
Posted: Tue Feb 02, 2010 9:00 pm (GMT 10)

Hi

I have also problems while running portico with C++.
Can you tell me
your compiler
your java version
your portico version?
Also can you tell me if you apply any special setting for jmv?
regards

Portico Support :: RE: WAN Federation

Chris — Tue, 02 Feb 2010 10:52:23 GMT

Author: Chris
Posted: Tue Feb 02, 2010 8:52 pm (GMT 10)

Tim,

That's perfect help, thanks for your advice. I'll be looking into all these possibilities. I'll be sure to post the best option on here.

A VPN would be good for security but it would be better if anyone from around the world could just log in and connect to the federation. I will have to see.

Cheers,

Chris

Portico Support :: RE: Unable to have synch callback in c++

tim — Tue, 02 Feb 2010 02:09:09 GMT

Author: tim
Posted: Tue Feb 02, 2010 12:09 pm (GMT 10)

G'day qubeuc,

As per the documentation, perhaps try turning up the logging through the RID file to find out what is happening inside the federate. That'll help in diagnosing the problem.

Also, note that sometimes you have to hit enter twice in the initial federate when using C++ I've noticed. No idea why this is the case, I've just noticed it from time to time.

Cheers,
Tim

Portico Support :: RE: WAN Federation

tim — Tue, 02 Feb 2010 02:07:10 GMT

Author: tim
Posted: Tue Feb 02, 2010 12:07 pm (GMT 10)

G'day Chris,

Unfortunately at the moment, this isn't supported. Well, mostly.

JGroups (the underlying comms library used) provides *some* support for this (see description below) but that is only suitable in some situations. I am currently working on a Multisite Connector component that will work as a plugin to Portico and allow many sites to be connected into one federation, but this is Calytrix funded and not core-Portico work. As such, it available to those groups who have an active support contract for Portico through Calytrix.

That said, depending on how you want Portico to be configured and how averse you are to hacking it yourself, it may work.

JGroups WAN Support

In my head, the example I use is that I have two networks, each with three clients: A{1,2,3} and B{4,5,6}. JGroups allows remote clients to join a group in which other clients are using multicast, but it requires that each remote client have a direct point-to-point connection into the original group.

For example, if the clients 4, 5 and 6 wanted to join the group running in A, they would have to each have a point-to-point connection into A. They use this point-to-point connection *in place* of the multicast connection, which means that any communication between 4, 5 and 6 goes via the network A.

To enable this, there needs to be a thing called a GossipRouter running on the same network as A. This is a standard JGroups component and can easily be started. Further, the JGroups configuration for 4, 5 and 6 needs to be told to use the TUNNEL protocol to talk to the GossipRouter located on network A.

At the moment, the JGroups configuration is pretty much static and defined in a file within the Portico jar. To make any changes here, you'd have to get a checkout of the latest version of Portico, change that file, rebuild Portico and use that rebuilt version. I can provide some pointers to do this, but it is heavyweight and I have only a conceptual understanding of what the GossipRouter does, not any actual experience with it. The JGroups website and documentation is probably the best place to start for this.

Other Options

The only other options are to provide some sort of network-level facility to allow multicast traffic to pass between networks (perhaps a VPN or something). Again, I have no experience here.

Finally, you could try using the old Portico v0.8 stream, which you would have to check out of Subversion and build. It is no longer supported in any way, but it was a purely client/server solution and works happily across a WAN. That said, it is horrifically slow compared to Portico v1.0.

Sorry I can't be of more help!

Cheers,
Tim

Portico Support :: RE: Register Instances

tim — Tue, 02 Feb 2010 01:55:26 GMT

Author: tim
Posted: Tue Feb 02, 2010 11:55 am (GMT 10)

Hi gvivcer,

You don't call the discover method directly, it is called by the RTI. When the RTI determines there is an object that a federate can discover, it calls the FederateAmbassador that was given to it when the federate called joinFederation(). You provide an implementation of this FederateAmbassador and handle the discover callback when the RTI calls it, providing you the instance handle.

This is standard HLA stuff. Unfortunately I don't have the time to provide basic HLA support. If you need a primer, I suggest you try Googling for something like "RTI-NG Programmer's Guide" for any resources that may be available. Some links are also provided in this thread: http://forums.porticoproject.org/viewtopic.php?p=1118

Cheers,
Tim

Portico Support :: RE: problem of synchronization point

tim — Tue, 02 Feb 2010 01:43:56 GMT

Author: tim
Posted: Tue Feb 02, 2010 11:43 am (GMT 10)

The attribute and parameter handles are the same for each loop because they are meant to uniquely identify an attribute or parameter in a FOM. These numbers are assigned at startup and don't change so that when one federate sends an update for attribute "34", all receiving federates know which attribute the update refers to. This is standard HLA. If you need help with that stuff, some links are generally provided in this thread: http://forums.porticoproject.org/viewtopic.php?p=1118

Portico Support :: Unable to have synch callback in c++

qubeuc — Mon, 01 Feb 2010 15:39:28 GMT

Author: qubeuc
Subject: Unable to have synch callback in c++
Posted: Tue Feb 02, 2010 1:39 am (GMT 10)

hi everyone i am a new user of Portico,

i am using portico with VC8 c++ in windows xp.

my problem is when i execute example code it prints this:

Code:

Created Federation
Joined Federation as exampleFederate2

program will not continue.

however, if i run example at java in same machine, program continue to flow.
So i thought problem is not my configuration.

any help or idea will appreciated so much???

thx

Portico Support :: RE: General HLA Documentation

Chris — Mon, 01 Feb 2010 13:52:44 GMT

Author: Chris
Subject: Federation development
Posted: Mon Feb 01, 2010 11:52 pm (GMT 10)

I have a few files that may help people get to grips with HLA

Understanding DIS is a good way to understand how HLA came about
www.hepburn3d.com/The_DIS_Find_It_Fast_Guide_07_Jun_06[1].doc

The FEDEP is really good for developing your FOM
www.hepburn3d.com/FEDEP_process.pdf
www.hepburn3d.com/FEDEP_process_checklists.pdf

Here is the example Reaper FOM stencil
www.hepburn3d.com/RPR-FOM.fed

I found these all through the web, so I'm pretty sure I'm allowed to put them up for download. If I'm not, please let me know and I'll take them down

Portico Support :: WAN Federation

Chris — Mon, 01 Feb 2010 13:45:13 GMT

Author: Chris
Subject: WAN Federation
Posted: Mon Feb 01, 2010 11:45 pm (GMT 10)

I understand that if you try running the example federates within the same network it just works.

If I want to run a federation over a WAN, what would I need to look into? Do I need to create a server that all federates subscribe to?

Portico Support :: Register Instances

gvivcer — Mon, 01 Feb 2010 11:41:56 GMT

Author: gvivcer
Subject: Register Instances
Posted: Mon Feb 01, 2010 9:41 pm (GMT 10)

I am working with poRTIco in my research master, and I have found problems. I have two federates that have published one object each one, both of them have subscribed their own object and have registered, and now I am trying to update attributes (with federate A) of the instance of the federate B.

The problem is when I try to discover the B instance with A federate, the function requires the Instance Attribute, and A federate does not know it.

How can I obtain it?

Thanks a lot

Portico Support :: RE: problem of synchronization point

tombolya — Mon, 01 Feb 2010 10:01:54 GMT

Author: tombolya
Posted: Mon Feb 01, 2010 8:01 pm (GMT 10)

G'day tim
sorry for my english, thanks you for the explanations , it is working.i have as the results for the 2 federates:
federates C:

ExampleFederate : Created Federation
ExampleFederate : Joined Federation as C_Federate
FederateAmbassador: Successfully registered sync point: ReadyToRun
FederateAmbassador: Synchronization point announced: ReadyToRun
ExampleFederate : Press Enter to Continue
ExampleFederate : Achieved sync point: ReadyToRun, waiting for federation...
FederateAmbassador: Federation Synchronized: ReadyToRun
ExampleFederate : Time Policy Enabled
ExampleFederate : Published and Subscribed
ExampleFederate : Registered Object, handle=2
FederateAmbassador: Discoverd Object: handle=2097153, classHandle=508, name=HLA2097153
FederateAmbassador: Reflection for object: handle=2097153, tag=126501749848, time=1.0, attributeCount=3
attributeHandle=509, attributeValue=aa:1.0
attributeHandle=510, attributeValue=ab:1.0
attributeHandle=511, attributeValue=ac:1.0

FederateAmbassador: Interaction Received: handle=518, tag=126501749848, time=1.0, parameterCount=2
paramHandle=519, paramValue=xa:1.0
paramHandle=520, paramValue=xb:1.0

ExampleFederate : Time Advanced to 1.0
FederateAmbassador: Reflection for object: handle=2097153, tag=126501749851, time=2.0, attributeCount=3
attributeHandle=509, attributeValue=aa:2.0
attributeHandle=510, attributeValue=ab:2.0
attributeHandle=511, attributeValue=ac:2.0

FederateAmbassador: Interaction Received: handle=518, tag=126501749851, time=2.0, parameterCount=2
paramHandle=519, paramValue=xa:2.0
paramHandle=520, paramValue=xb:2.0

ExampleFederate : Time Advanced to 2.0
FederateAmbassador: Reflection for object: handle=2097153, tag=126501749857, time=3.0, attributeCount=3
attributeHandle=509, attributeValue=aa:3.0
attributeHandle=510, attributeValue=ab:3.0
attributeHandle=511, attributeValue=ac:3.0

FederateAmbassador: Interaction Received: handle=518, tag=126501749857, time=3.0, parameterCount=2
paramHandle=519, paramValue=xa:3.0
paramHandle=520, paramValue=xb:3.0

ExampleFederate : Time Advanced to 3.0
FederateAmbassador: Reflection for object: handle=2097153, tag=126501749857, time=4.0, attributeCount=3
attributeHandle=509, attributeValue=aa:4.0
attributeHandle=510, attributeValue=ab:4.0
attributeHandle=511, attributeValue=ac:4.0

FederateAmbassador: Interaction Received: handle=518, tag=126501749858, time=4.0, parameterCount=2
paramHandle=519, paramValue=xa:4.0
paramHandle=520, paramValue=xb:4.0

ExampleFederate : Time Advanced to 4.0
ExampleFederate : Deleted Object, handle=2
ExampleFederate : Resigned from Federation
ExampleFederate : Destroyed Federation

federates B:
ExampleFederate : Joined Federation as B_Federate
ExampleFederate :
>>>>>>>>>> Press Enter to Continue <<<<<<<<<<

ExampleFederate : Achieved sync point: ReadyToRun, waiting for federation...
FederateAmbassador: Federation Synchronized: ReadyToRun
ExampleFederate : Time Policy Enabled
ExampleFederate : Published and Subscribed
ExampleFederate : Registered Object, handle=2097153
FederateAmbassador: Discoverd Object: handle=2, classHandle=508, name=HLA2
FederateAmbassador: Interaction Received: handle=518, tag=1265017498460, time=1.0, parameterCount=2
paramHandle=519, paramValue=xa:1.0
paramHandle=520, paramValue=xb:1.0

FederateAmbassador: Reflection for object: handle=2, tag=1265017498457, time=1.0, attributeCount=3
attributeHandle=509, attributeValue=aa:1.0
attributeHandle=510, attributeValue=ab:1.0
attributeHandle=511, attributeValue=ac:1.0

ExampleFederate : Time Advanced to 1.0
FederateAmbassador: Reflection for object: handle=2, tag=1265017498538, time=2.0, attributeCount=3
attributeHandle=509, attributeValue=aa:2.0
attributeHandle=510, attributeValue=ab:2.0
attributeHandle=511, attributeValue=ac:2.0

FederateAmbassador: Interaction Received: handle=518, tag=1265017498539, time=2.0, parameterCount=2
paramHandle=519, paramValue=xa:2.0
paramHandle=520, paramValue=xb:2.0

ExampleFederate : Time Advanced to 2.0
FederateAmbassador: Reflection for object: handle=2, tag=1265017498542, time=3.0, attributeCount=3
attributeHandle=509, attributeValue=aa:3.0
attributeHandle=510, attributeValue=ab:3.0
attributeHandle=511, attributeValue=ac:3.0

FederateAmbassador: Interaction Received: handle=518, tag=1265017498543, time=3.0, parameterCount=2
paramHandle=519, paramValue=xa:3.0
paramHandle=520, paramValue=xb:3.0

ExampleFederate : Time Advanced to 3.0
ExampleFederate : Time Advanced to 4.0
ExampleFederate : Deleted Object, handle=2097153
ExampleFederate : Resigned from Federation
ERROR [main] portico.lrc: org.portico.shared.compat.JFederationExecutionDoesNotExist: federation: ExampleFederation
ExampleFederate : No need to destroy federation, it doesn't exist

but i don't understand why the paramHandle and attributeHandle are same for each main simulation loop.

thanks
cheers

Portico Support :: RE: Building Fed Files from Scratch and OMDT

tim — Sat, 30 Jan 2010 02:39:51 GMT

Author: tim
Posted: Sat Jan 30, 2010 12:39 pm (GMT 10)

Firstly, yes, the A->B stuff is there intentionally. The provided FOM is meant to be really small and simple so as to keep the focus of the example federates on how to pub/sub, register objects and send updates.

People do often use an OMT tool to generate their FOM, but I've always just written them by hand. That said, in most cases I'm using a pre-defined FOM such as the RPR FOM. This is a standard FOM, maintained by the Simulation Interoperability and Standards Organization (SISO) http://www.sisostds.org and is used extensively throughout the armed services for their simulation needs.

As for defining the typing of an attribute: the RTI does not enforce any of this at all. It will take your opaque byte[]'s and just pass them around. The responsibility for making sure they contain valid attribute data is left to the federates themselves. The OMT format does allow for providing type information, but this is used for either documentation purposes, or can be fed into automated tools that might spit out boilerplate code that you can use. The actual FED file (the runtime file given to the RTI) doesn't contain this information as the RTI doesn't care about it.

*NOTE* This is all for HLA 1.3. For the IEEE-1516 version, there is an XML fed file format that DOES contain typing, however, again, the RTI doesn't care about that information and just ignores it. Again, It is there for documentation purposes or use by automated tools.

Hope that helps. Don't hesitate to ask questions. I'm happy to help out where I can.

Cheers,
Tim

Portico Support :: RE: Difference between jlc and rti13.java1

tim — Sat, 30 Jan 2010 02:34:08 GMT

Author: tim
Posted: Sat Jan 30, 2010 12:34 pm (GMT 10)

G'day fdorbon,

These are different versions of the HLA interface.

The hla.rti.jlc package contains the extra parts of the interface as defined by the HLA 1.3 Dynamic Link Compatibility specification (managed by SISO http://www.sisostds.org). It provides extra classes for use with those that already exist in the hla.rti package.

The classes in the hla.rti13.java1 package are there for backwards compatibility with the old DMSO RTI-NG package. A lot of people used this RTI before it was removed from being freely available. In their Java interface, they had a sub-package where they put a lot of stuff. Many people just referenced the classes in this sub-package rather than the standard interface, and for this reason, Portico provides implementation of it.

The hla.rti1516 package is the IEEE-1516 interface. It is as yet incomplete and use of it is *not* recommended.

I'd stick with the hla.rti and hla.rti.jlc packages if I were you.

Cheers,
Tim

Portico Support :: RE: Federate working with RPR-FOM.fed

tim — Sat, 30 Jan 2010 02:29:47 GMT

Author: tim
Posted: Sat Jan 30, 2010 12:29 pm (GMT 10)

We have had many reports of Portico working happily with the RPR FOM. Calytrix Technologies LVCGame product works happily using Portico with various flavours of the RPR FOM. I've also had JSAF running happily with Portico using a RPR FOM variant.

It should be as easy as joining a federation and subscribing to the bits you are interested in. Providing there is something somewhere else pumping updates for various RPR FOM entities out, you should be able to interact with them.

Portico Support :: RE: poRTIco Chat federate

tim — Sat, 30 Jan 2010 02:27:50 GMT

Author: tim
Posted: Sat Jan 30, 2010 12:27 pm (GMT 10)

I believe the chat example has been used elsewhere, but I can't recall where. I'm surprised they don't provide the source for their federate, as I'm pretty sure they use it as an example. Sorry I can't offer any more help

Portico Support :: Building Fed Files from Scratch and OMDT

fdorbon — Fri, 29 Jan 2010 20:08:05 GMT

Author: fdorbon
Subject: Building Fed Files from Scratch and OMDT
Posted: Sat Jan 30, 2010 6:08 am (GMT 10)

A question about building my own FED file, I have read some things online that say people usually generate FED files using a freely available Object Model Development Tool (like an IDL generator I guess?) Is this actually the case?

Regarding the example java FED file included with Portico, it seems that class "A" actually contains a sub-class "B". Is this the intended design? Also, how are attribute types defined in the FED file? Is any type simply accepted, and then an error is thrown eventually if it is wrong?

Thanks a million, I realize this is a lot of questions.