Skip to main content
November 13, 2012
Question

GC affects Proxied Shared Object?

  • November 13, 2012
  • 1 reply
  • 724 views

Hi, all

I found sth strange with the Proxied Shared Object when Garbage Collection in FMS 4.0. I have a FMS application 'ProxiedSOApp', in the Application start, it tries to get proxied SO from another FMS application 'MasterSOApp' every 5 seconds, and GC runs every 20 seconds.

application/MasterSOApp/main.asc

application.allowDebug=true;
var so;

application.onAppStart = function( ){
so=SharedObject.get('MasterSO',false);
so.setProperty('Cabinet','Cabinet');
};

application.onAppStop = function(){
trace('Application', 'Stopped.');
};

application/ProxiedSOApp/main.asc

application.allowDebug=true;
var nc;
var soRef;

application.onAppStart = function( ){
trace('Application', 'Started.');
nc = new NetConnection();
nc.connect('rtmp://localhost/MasterSOApp', "console" );

nc.onStatus = function(info) {
  trace(info.code);
};
nc.isAlive = function()
{
  return true;
};
setInterval( updateSORef , 5000 );
setInterval( doGC , 20000 );
};

function doGC(){
trace('GC working');
application.gc();
}

function updateSORef(){
trace('updateSORef');
soRef=SharedObject.get('MasterSO',false,nc);
soRef.onSync=function(list) {
  trace('sync begin');
  for (var i = 0; i < list.length; i++)
  {
   trace('SO status: '+list.code+': '+list.name);
  }
  trace('sync end');
};
}

application.onAppStop = function(){
trace('Application', 'Stopped.');
};

And I found the logs of ProxiedSOApp below

#Fields: date time x-pid x-status x-ctx x-comment

2012-11-13 14:48:26 13316 (s)2641173 ApplicationStarted.  -

2012-11-13 14:48:26 13316 (s)2641173 NetConnection.Connect.Success -

2012-11-13 14:48:31 13316 (s)2641173 updateSORef -

2012-11-13 14:48:31 13316 (s)2641173 sync begin -

2012-11-13 14:48:31 13316 (s)2641173 SO status: clear: undefined -

2012-11-13 14:48:31 13316 (s)2641173 SO status: change: Cabinet -

2012-11-13 14:48:31 13316 (s)2641173 SO status: change: DataRetrieve -

2012-11-13 14:48:31 13316 (s)2641173 SO status: change: User -

2012-11-13 14:48:31 13316 (s)2641173 SO status: change: UserSession -

2012-11-13 14:48:31 13316 (s)2641173 sync end -

2012-11-13 14:48:36 13316 (s)2641173 updateSORef -

2012-11-13 14:48:41 13316 (s)2641173 updateSORef -

2012-11-13 14:48:46 13316 (s)2641173 GC working -

2012-11-13 14:48:46 13316 (s)2641173 sync begin -

2012-11-13 14:48:46 13316 (s)2641173 SO status: clear: undefined -

2012-11-13 14:48:46 13316 (s)2641173 sync end

...

Although the proxied SO is updated during the 1st get, when GC works, the proxied SO is cleared.(the Master SO is unchanged)

So I want to know, when GC, is there sth happened with the unreachable proxied SO reference which will clear the SO?

Thanks!

This topic has been closed for replies.

1 reply

November 13, 2012

When you are calling gc for proxied shared object, it will have no affect on the master shared object as proxied shared object is just a reference to that. The change to master shared object will be reflected only if you change the property using setProperty methoed or clear shared object explicitly.

November 14, 2012

Thanks for your reply!

For the test, I can make sure that, there is no other code to set or clear the MasterSO. Also, before and after the 'clear' event is received in the ProxiedSO, the MasterSO is not changed and the properties are still existing. I've also add another client to monitor the MasterSO status change, and when the proxyiedSOApp get the clear event during GC, no event is received in the added client.

I can see from the FMS console, every time Sharedobject.Get in ProxiedSOApp, the 'Connections' for ProxiedSO will increase by 1, and when GC, the  'Connections' decreases to 1, and from the log, a clear event is thrown.

So I'm still suspect that GCing the unreachable proxied SO reference causes the clear event.

any ideas?

November 14, 2012

The onSync function of the shared object generate code "clear" for proxied shared object when all the properties of a shared object are deleted. This can happen when the server's shared object is out of sync with the master shared object or when the persistent shared object migrates from one instance to another.

Since you are calling gc so, it is deleting all the local objects and references which means that your proxied shared object is out of sync with the master shared object and thus generating onSync event with code "clear".