RE: [jotm] Performance problems

["Stephen Fry" <Stephen.Fry@xxxxxxxx>]

Is there a definition of the coding standards somewhere?

-----Original Message-----
From: david.egolf@xxxxxxxxxxxxx [mailto:david.egolf@xxxxxxxxxxxxx] 
Sent: 23 September 2004 01:27
To: jotm@xxxxxxxxxxxxx
Cc: Stephen Fry
Subject: Re: [jotm] Performance problems


Hi again Stephen,

> I have modified my JOTM to explicitly export these objects when it's 
> not running with a local transaction factory (They already implement 
> Remote as both their interfaces extend Remote).

I have heard that there are some Java problems with garbage collection
of 
remote objects.  Perhaps this is what JOTM is causing.

Please send us a patch.  We will examine it, test it, and consider it
for 
inclusion in JOTM.

Thank you,

David Egolf


"Stephen Fry" <Stephen.Fry@xxxxxxxx> wrote on 09/22/2004 04:37:43 AM:

> I have identified a leak that is causing me performance degradation 
> over time in benchmarking tests.
> 
> I am using j2sdk1.4.2_01 from sun on win 2000.
> 
> I am running JOTM embedded with a local transaction factory. In this 
> case the fact that SubCoordinator and TransactionFactoryImpl extend 
> PortableRemoteObject causes leaks.
> 
> What happens in my test case is that it ends up calling
> 
> com.sun.corba.se.internal.util.Utility.loadTie(Remote obj)
> 
> This fails to find it and records a cache miss in it's tieCache. This 
> is a hard reference to our object (SubCoordinator etc.) When the 
> portable remote object is unexported this reference is not cleaned up.

> This is bad!!
> 
> I have modified my JOTM to explicitly export these objects when it's 
> not running with a local transaction factory (They already implement 
> Remote as both their interfaces extend Remote).
> 
> Does this sound like a good solution? It certainly improves my 
> benchmark results.
> 
> It looks like this relates to Bug 100317 SubCoordinator Stubs 
> manadatory for local JOTM.
> 
> Stephen Fry
> 
> 
> The information in this message is confidential and may be legally
> privileged. It may not be disclosed to, or used by, anyone other 
> than the addressee. If you receive this message in error, please 
> advise us immediately.  Internet emails are not necessarily secure. 
> CODA does not accept responsibility for changes to any email which 
> occur after the email has been sent. Attachments to this email may 
> contain software viruses, which could damage your systems. CODA has 
> checked the attachments for viruses before sending, but you should 
> virus-check them before opening. 
> 
> 
> 
> --
> You receive this message as a subscriber of the jotm@xxxxxxxxxxxxx 
> mailing list.
> To unsubscribe: mailto:jotm-unsubscribe@xxxxxxxxxxxxx
> For general help: mailto:sympa@xxxxxxxxxxxxx?subject=help
> ObjectWeb mailing lists service home page:
http://www.objectweb.org/wws




The information in this message is confidential and may be legally 
privileged. It may not be disclosed to, or used by, anyone other than the 
addressee. If you receive this message in error, please advise us 
immediately.  Internet emails are not necessarily secure. CODA does not 
accept responsibility for changes to any email which occur after the email 
has been sent. Attachments to this email may contain software viruses, which 
could damage your systems. CODA has checked the attachments for viruses 
before sending, but you should virus-check them before opening.