Clean up code

Hello,

I need to do some clean up code in the instance which implements the
remoting interface. I tried overriding the Destructor and the
BeforeDestruction methods but it looks like they are never executed.
What am I missing?


--
fmsanchezb

Best regards,
Francisco Sanchez

fmsanchezb wrote:

>
> Hello,
>
> I need to do some clean up code in the instance which implements the
> remoting interface. I tried overriding the Destructor and the
> BeforeDestruction methods but it looks like they are never executed.
> What am I missing?

If you have correctly implemented them (e.g. not forgotten to use override) and
they are not called, then there still must be outstanding references somewhere.

If you have multiple objects that reference each other using interfaces, make
sure you do not end up with closed loops, otherwise these objects will keep
each other alive indefinitely.

Ok, I have fixed that. But now I've found that when the client losses
the connexion, the server is not correctly destroying the instance. Can
you confirm that? Is there any workaround?


--
fmsanchezb

Best regards,
Francisco Sanchez

fmsanchezb wrote:

> Ok, I have fixed that. But now I've found that when the client losses
> the connexion, the server is not correctly destroying the instance. Can
> you confirm that? Is there any workaround?

Have you waited the required time for the transport to detect the lost
connection?

It depends on heartbeat interval on the client and watchdog interval on the
server.

The client is sending a heartbeat message every HeartbeatInterval msecs
(default 10000). The server is checking for how many heartbeats are missing
every WatchdogInterval msecs (default 10000).

If, at that time, 3 or more heartbeats are missing, the connection is declared
dead, all it's sessions are cleaned up, and this will then release all
references held by the closed sessions.

Absolutely worst case, that is, the client dies just in the msec after having
sent it's last heartbeat, and the offset between when the heartbeats are sent
and when the watchdog runs is so that it always checks just an msec before the
next heartbeat should arrive, it would take 49.999 seconds for the server to
release the references.

Best case, the client dies just before sending the next heartbeat, and the
offset between heartbeat and watchdog is so that it always checks the
heartbeats just after they arrive, it will take 30.001 seconds for the server
to release the references.

If either of the 2 intervals (one at the client, one at the server) is set to
0, the whole heartbeat system is disabled (either for that client or for the
whole server) and dead clients are never cleaned up.

'Thorsten Engler [NDA Wrote:
> ;101082']
> Have you waited the required time for the transport to detect the lost
> connection?
>
Yes, the session is cleaned up correctly, but the instance which
implements the remoting interface is not being destroyed. I have
verified this in your remoting basic example. If I disconnect the client
then it works fine, but if I kill the client process within the task
server it doesn't.


--
fmsanchezb

Best regards,
Francisco Sanchez

fmsanchezb wrote:

> Yes, the session is cleaned up correctly, but the instance which
> implements the remoting interface is not being destroyed. I have
> verified this in your remoting basic example. If I disconnect the client
> then it works fine, but if I kill the client process within the task
> server it doesn't.

It used to work correctly. I'll have to run some tests and get back to you on
this.

fmsanchezb wrote:

> Yes, the session is cleaned up correctly, but the instance which
> implements the remoting interface is not being destroyed. I have
> verified this in your remoting basic example. If I disconnect the client
> then it works fine, but if I kill the client process within the task
> server it doesn't.

I'm not seeing this.

I've added extensive codesite logging to the remoting core now and it is clear
that, when using the Basic example, the TnxCalc object is correctly released
after killing the client.

The following trace contains the relevant methods from both the client and
server side:

TnxCalc.Create
TnxCalc.Create
TnxClassStub.Create
InstanceID = {034E2FB0-2FD4-034D-AD0A-C403C90AC703}
TnxClassStub.Create
TnxChannelExit.Create
chServerID = {F5481F23-28AF-45B6-9EFE-C265C385B4A0}
chChannelID = {03542FAC-2FF8-034E-AD0A-C403F90ADE03}
TnxChannelExit.Create
TnxChannelEntrance.Create
chServerID = {465A8E5E-36B9-45E7-AE5F-EC57B02FBCBC}
chChannelID = {03542FAC-2FF8-034E-AD0A-C403F90ADE03}
TnxChannelEntrance.Create
TnxClassProxy.Create
cpChannel.ChannelID = {03542FAC-2FF8-034E-AD0A-C403F90ADE03}
cpClassID = {AA97D66D-F493-4267-95B7-48D166E8B43D}
TnxClassProxy.Create
TnxClassProxy.Create
TnxClassProxy.Create
TnxClassProxy.Process
TnxChannelEntrance.Process
chServerID = {465A8E5E-36B9-45E7-AE5F-EC57B02FBCBC}
chChannelID = {03542FAC-2FF8-034E-AD0A-C403F90ADE03}
TnxChannelExit.Process
TnxClassStub.Process
InstanceID = {034E2FB0-2FD4-034D-AD0A-C403C90AC703}
aChannel.ServerID = {F5481F23-28AF-45B6-9EFE-C265C385B4A0}
aChannel.ChannelID = {03542FAC-2FF8-034E-AD0A-C403F90ADE03}
TnxClassStub.Process
TnxChannelExit.Process
TnxChannelEntrance.Process
TnxClassProxy.Process
TnxClassProxy.Process
TnxChannelEntrance.Process
chServerID = {465A8E5E-36B9-45E7-AE5F-EC57B02FBCBC}
chChannelID = {03542FAC-2FF8-034E-AD0A-C403F90ADE03}
TnxChannelExit.Process
TnxClassStub.Process
InstanceID = {034E2FB0-2FD4-034D-AD0A-C403C90AC703}
aChannel.ServerID = {F5481F23-28AF-45B6-9EFE-C265C385B4A0}
aChannel.ChannelID = {03542FAC-2FF8-034E-AD0A-C403F90ADE03}
TnxClassStub.Process
TnxChannelExit.Process
TnxChannelEntrance.Process
TnxClassProxy.Process

--- Client killed ---

TnxChannelExit.Disconnected
chServerID = {F5481F23-28AF-45B6-9EFE-C265C385B4A0}
chChannelID = {03542FAC-2FF8-034E-AD0A-C403F90ADE03}
TnxClassStub.Disconnected
InstanceID = {034E2FB0-2FD4-034D-AD0A-C403C90AC703}
aChannel.ServerID = {F5481F23-28AF-45B6-9EFE-C265C385B4A0}
aChannel.ChannelID = {03542FAC-2FF8-034E-AD0A-C403F90ADE03}
TnxClassStub.Disconnected
TnxChannelExit.Disconnected
TnxClassStub.Destroy
InstanceID = {034E2FB0-2FD4-034D-0000-000064000300}
TnxClassStub.Destroy
TnxCalc.Destroy
TnxCalc.Destroy
TnxChannelExit.Destroy
chServerID = {F5481F23-28AF-45B6-9EFE-C265C385B4A0}
chChannelID = {03542FAC-2FF8-034E-AD0A-C403F90ADE03}
TnxChannelExit.Disconnected
chServerID = {F5481F23-28AF-45B6-9EFE-C265C385B4A0}
chChannelID = {03542FAC-2FF8-034E-AD0A-C403F90ADE03}
TnxChannelExit.Disconnected
TnxChannelExit.Destroy

'Thorsten Engler [NDA Wrote:
> ;101088']
> I've added extensive codesite logging to the remoting core now and it is
> clear
> that, when using the Basic example, the TnxCalc object is correctly
> released
> after killing the client.
I'm using v3.04 on Delphi 2010. Are you using the same?


--
fmsanchezb

Best regards,
Francisco Sanchez

fmsanchezb wrote:

> I'm using v3.04 on Delphi 2010. Are you using the same?

Current development codebase on D2010.

fmsanchezb wrote:

>
> 'Thorsten Engler [NDA Wrote:
> > ;101088']
> > I've added extensive codesite logging to the remoting core now and it is
> > clear
> > that, when using the Basic example, the TnxCalc object is correctly
> > released
> > after killing the client.
> I'm using v3.04 on Delphi 2010. Are you using the same?

Please try again with 3.05 and let me know if you still see the problem.

I assume this fix: http://www.nexusdb.com/mantis/view.php?id=575

is the reason why I wasn't able to reproduce the problem.