RE: [jotm] Performance problems

[david.egolf@xxxxxxxxxxxxx]

Stephen,

I couldn't find standards on either JOTM or on the objectweb site.  I am 
also sending this to Philippe who referred to existing standards in a 
forum entry earlier this summer.  Hopefully, he can point us any relevant 
documentation.

Lacking that, I would suggest that you attempt to match the code you are 
modifying and note that spaces are employed instead of <tab>s.  Otherwise, 
we'll review your submission for appropriateness and fix style errors 
before we commit the changes.

-- David Egolf

"Stephen Fry" <Stephen.Fry@xxxxxxxx> wrote on 09/23/2004 07:59:03 AM:

> 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. 
>