Re: Eclipse RCP apps and Tuscany
Rajini Sivaram wrote: [snip] I dont know the code well enough to understand how these contributions are used/loaded/resolved etc. But yes, it will be good to stop manipulating URLs to locate contributions. +1, if I understand correctly, the scenario discussed here is like this: Bob, application developer, writes Java code to bootstrap Tuscany and load some SCA contributions into it, before starting his composites. With the current API, Bob's code needs to do something like: TuscanySomething.addContribution() Bob can't seriously hardcode the location of the contribution: - C:\Bob's Dir\aContribution.jar is only going to work on Bob's machine. - At development time the location is also different, something like C:\Bob's IDE workspace\aProject\bin. - When Bob builds with Maven the location is probably different again C:\Bob's build Dir\target\classes. Bob didn't want to have to write 3 different classes for these 3 cases, so he put his SCA contribution on his classpath and wrote (almost) portable code to locate it (by looking for a known resource on the classpath and getting the location of the contribution from the resource's URL). This is a hack around an inconvenient Tuscany bootstrap API which requires the app developer to give the location of his contributions. How about trying to attack the real problems IMO: - Bob shouldn't have to specify a location in the first place, he should be able to identify his contributions by contribution logical URI. - or even better, Bob should not have to write any code to bootstrap the runtime and list contributions in the first place. - and Bob shouldn't have to put his SCA contributions on his VM's classpath either (see the Store tutorial for an example, where the store contribution references the assets contribution without a classpath dependency on it). Thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany SDO Memory Leaks in Production Server Environment
Hi Kelvin, Thanks for researching this for us. We'll go ahead and try your breakpoint suggestion and let you know our results. - Ron - Original Message From: kelvin goodson <[EMAIL PROTECTED]> To: tuscany-user@ws.apache.org Sent: Friday, January 11, 2008 12:02:06 PM Subject: Re: Tuscany SDO Memory Leaks in Production Server Environment Ron, I talked to Ed Merks about this, and here's a summary of what he said. He was referencing the EMF 2.4 code, but aside from the generics he thought it was the same as 2.2.3. The key diagnostic would be to see whether calls to getPrinter() and releasePrinter(XMLString) are made in pairs. He suspects that something must be creating printers directly and releasing them, thereby never reusing printers that have been released. The one call to getPrinter seems to be made in XMLSaveImpl: protected void init(XMLResource resource, Map options) and the corresponding releae is made in endSave(List contents) throws IOException Both calls are guarded by the useCache guard. So to track it Ed suggested setting a breakpoint in the getPrinter and setPrinter methods. You should never get a release call that didn't give back what was given by a getPrinter call. So one might keep a list of all the things that were given away and when a release happens, check that it's really one that was given away. If not, that code path is a bad one. If this doesn't bear fruit I guess we're going to need a test case that replicates the problem and post it to the EMF list. He says hell be happy to take a look. Regards, Kelvin. On 10/01/2008, Ron Gavlin <[EMAIL PROTECTED]> wrote: > > Greetings, > > We are using Tuscany SDO 1.0 in a production server environment. During > application execution, we see the XMLStrings contained in the EMF > org.eclipse.emf.ecore.xmi.impl.ConfigurationCache.printers[] array growing > without bound until eventually we are forced to restart the application. > There exists a ConfigurationCache.release() method which appears designed > to release this cache. However, we never see this method being invoked > during the life-cycle of our application. Any suggestions for resolving this > problem? Your prompt assistance with this matter is appreciated. > > - Ron > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany SDO Memory Leaks in Production Server Environment
Ron, I talked to Ed Merks about this, and here's a summary of what he said. He was referencing the EMF 2.4 code, but aside from the generics he thought it was the same as 2.2.3. The key diagnostic would be to see whether calls to getPrinter() and releasePrinter(XMLString) are made in pairs. He suspects that something must be creating printers directly and releasing them, thereby never reusing printers that have been released. The one call to getPrinter seems to be made in XMLSaveImpl: protected void init(XMLResource resource, Map options) and the corresponding releae is made in endSave(List contents) throws IOException Both calls are guarded by the useCache guard. So to track it Ed suggested setting a breakpoint in the getPrinter and setPrinter methods. You should never get a release call that didn't give back what was given by a getPrinter call. So one might keep a list of all the things that were given away and when a release happens, check that it's really one that was given away. If not, that code path is a bad one. If this doesn't bear fruit I guess we're going to need a test case that replicates the problem and post it to the EMF list. He says hell be happy to take a look. Regards, Kelvin. On 10/01/2008, Ron Gavlin <[EMAIL PROTECTED]> wrote: > > Greetings, > > We are using Tuscany SDO 1.0 in a production server environment. During > application execution, we see the XMLStrings contained in the EMF > org.eclipse.emf.ecore.xmi.impl.ConfigurationCache.printers[] array growing > without bound until eventually we are forced to restart the application. > There exists a ConfigurationCache.release() method which appears designed > to release this cache. However, we never see this method being invoked > during the life-cycle of our application. Any suggestions for resolving this > problem? Your prompt assistance with this matter is appreciated. > > - Ron > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Eclipse RCP apps and Tuscany
On Jan 11, 2008 2:16 PM, Simon Laws <[EMAIL PROTECTED]> wrote: > Hi Rajini > > > > But the code that I have run into problems with are in > > > > > > > org.apache.tuscany.sca.node.util.SCAContributionUtil.findContributionFromResource > > (ClassLoader > > classLoader, String compositeString) > > > > which only works with file:// or jar:// URLs (it is very similar to the > > code > > used by the old DefaultSCADomain). > > > I've always been skeptical about this method. It was included as a > convenience to allow the location of a contribution to be determined from > some well know file, for example, the composite file that is being tested. > Handy for testing but it seems back to front to me. As a user you either > have a contribution or you don't. Seems a strange thing to ask a runtime > to > find a contribution based on what is known to be inside it. > +1 to that. ...ant
Re: Eclipse RCP apps and Tuscany
Simon, On 1/11/08, Simon Laws <[EMAIL PROTECTED]> wrote: > > Hi Rajini > > > > But the code that I have run into problems with are in > > > > > > > org.apache.tuscany.sca.node.util.SCAContributionUtil.findContributionFromResource > > (ClassLoader > > classLoader, String compositeString) > > > > which only works with file:// or jar:// URLs (it is very similar to the > > code > > used by the old DefaultSCADomain). > > > I've always been skeptical about this method. It was included as a > convenience to allow the location of a contribution to be determined from > some well know file, for example, the composite file that is being tested. > Handy for testing but it seems back to front to me. As a user you either > have a contribution or you don't. Seems a strange thing to ask a runtime > to > find a contribution based on what is known to be inside it. Yes, it will be good if the code can be changed, but since many of the samples and tests find their contributions based on the composites/sca- contribution.xml, I am not sure if it is feasible to get rid of it altogether after it has been around for so long. > > > This method is invoked from > > > > 1. SCADomainImpl to find the folder/jar containing domain.composite > > 2. SCADomainProxyImpl to find the folder/jar containing node.composite > > 3. SCANodeFactory.createNodeWithComposite(String composite) > > 4. SCANodeLauncher.main() > > > > 1) and 2) in particular need to be fixed properly since they are > internal > > to > > > > Tuscany and it doesn't seem appropriate to expect applications to > > override resource loading for the Tuscany runtime when Tuscany is > > installed > > into OSGi. > > > For 1 and 2 I'm sure we can find a better solution that using this method, > for example, some alternatives > Have the runtime implementations that Ant is thinking about specify a well > know location for these system contributions > Have the assemblies for these contributions generated programatically > rather than read from the file system When Tuscany is running under OSGi, we will require these contributions to be installed into OSGi. I dont know the code well enough to understand how these contributions are used/loaded/resolved etc. But yes, it will be good to stop manipulating URLs to locate contributions. . > Simon > Thank you... Regards, Rajini
Re: Eclipse RCP apps and Tuscany
Hi Rajini > But the code that I have run into problems with are in > > > org.apache.tuscany.sca.node.util.SCAContributionUtil.findContributionFromResource > (ClassLoader > classLoader, String compositeString) > > which only works with file:// or jar:// URLs (it is very similar to the > code > used by the old DefaultSCADomain). I've always been skeptical about this method. It was included as a convenience to allow the location of a contribution to be determined from some well know file, for example, the composite file that is being tested. Handy for testing but it seems back to front to me. As a user you either have a contribution or you don't. Seems a strange thing to ask a runtime to find a contribution based on what is known to be inside it. > > This method is invoked from > > 1. SCADomainImpl to find the folder/jar containing domain.composite > 2. SCADomainProxyImpl to find the folder/jar containing node.composite > 3. SCANodeFactory.createNodeWithComposite(String composite) > 4. SCANodeLauncher.main() > > 1) and 2) in particular need to be fixed properly since they are internal > to > Tuscany and it doesn't seem appropriate to expect applications to > override resource loading for the Tuscany runtime when Tuscany is > installed > into OSGi. For 1 and 2 I'm sure we can find a better solution that using this method, for example, some alternatives Have the runtime implementations that Ant is thinking about specify a well know location for these system contributions Have the assemblies for these contributions generated programatically rather than read from the file system . Simon
Re: Eclipse RCP apps and Tuscany
Simon, There is code used by the new domain/node APIs as well which manipulate URLs returned by classloader.getResource() to open a directory or jar file corresponding to a contribution. There are still some outstanding issues with classloading in the new domain code, so I haven't been able to fully test it under OSGi. But the code that I have run into problems with are in org.apache.tuscany.sca.node.util.SCAContributionUtil.findContributionFromResource(ClassLoader classLoader, String compositeString) which only works with file:// or jar:// URLs (it is very similar to the code used by the old DefaultSCADomain). This method is invoked from 1. SCADomainImpl to find the folder/jar containing domain.composite 2. SCADomainProxyImpl to find the folder/jar containing node.composite 3. SCANodeFactory.createNodeWithComposite(String composite) 4. SCANodeLauncher.main() 1) and 2) in particular need to be fixed properly since they are internal to Tuscany and it doesn't seem appropriate to expect applications to override resource loading for the Tuscany runtime when Tuscany is installed into OSGi. Thank you... Regards, Rajini On 1/11/08, Simon Nash <[EMAIL PROTECTED]> wrote: > > The SCADomain.newInstance() method and the DefaultSCADomain class in > host-embedded have been replaced by the domain and node APIs in > domain-api and node-api. However, most samples have not yet been > converted to the new APIs. For examples of samples that use the > new APIs, see callback-ws-client, callback-ws-service and > calculator-distributed. > > Do the same issues apply to the new APIs, or only when the old > DefaultSCADomain class is used? > > Simon > > Rajini Sivaram wrote: > > > SCADomain.newInstance(compositeName), which is used in many of the > Tuscany > > samples to create a DefaultSCADomain works only if > > contextClassLoader.getResource(compositeName) returns a file:// or > jar:// > > URL. This is broken when Tuscany is run under OSGi, since Apache Felix > > returns a bundle:// URL and Equinox returns a bundleresource:// URL for > the > > composite. At the moment, existing samples can be run under an OSGi > based > > Tuscany only by using a custom classloader as the thread context > > classloader, which returns file:// or jar:// URLs from its getResource > > method, like Jason described( > > http://marc.info/?l=tuscany-user&m=119559170431301&w=2). > > > > DefaultSCADomain determines the location of the SCA contribution > relative to > > the composite or sca-contribution.xml. This file is first loaded using > > applicationClassLoader.getResource(), and root of the contribution > folder or > > jar file is determined from the resource URL. Since bundle:// URLs dont > > correspond to a folder or jar file, they are not correctly processed by > > Tuscany. To fix this in Tuscany, we need a BundleContributionProcessor > > similar to JarContributionProcessor (at the moment, artifacts from > bundle > > contributions are read using the JarContributionProcessor). The bundle > > contribution processor should either 1) read the stream using the bundle > URL > > and use OSGi bundle API to read its artifacts or 2) find the actual file > > location corresponding to the bundle and read it using the > > JarContributionProcessor. Unfortunately, both of these require OSGi > specific > > code in the contribution processing logic. > > > > addContribution() methods for SCANode and SCADomain work with file:// > URLs > > which specify bundle contributions, and these are resolved correctly > using > > OSGi. But at the moment, they cannot process bundle:// URLs. A proper > fix > > for DefaultSCADomain will also enable bundle:// or bundleresource:// > URLs to > > be used in addContribution(). > > > > Since this is a problem only when Tuscany is run under OSGi, and any fix > > would require adding OSGi specific code into the contribution processing > > code in Tuscany, I am not sure if this needs fixing in Tuscany, or the > > workaround of overriding the context classloader is sufficient. > > > > Thoughts? > > > > > > > > > > On 11/23/07, Peter Kriens <[EMAIL PROTECTED]> wrote: > > > >>I think it sounds very much like Felix Meschberger's conclusion. > >>Converting URLs to strings and then back to URLs, which is not > >>necessary and not guaranteed to work. > >> > >>Anyway, I'd like to know why someone needs to escape to Equinox hooks > >>when it should work on standard OSGi level ... > >> > >>Kind regards, > >> > >>Peter Kriens > >> > >>RS> Hi, > >> > >>RS> Tuscany supports OSGi bundle contributions which are currently > loaded > >>using > >>RS> the Apache Felix OSGi runtime by default. These contributions can > >>contain > >>RS> composite files and other meta-data which are loaded using OSGi and > >>RS> passed around as URLs. Tests for OSGi contributions are run under > >>Felix with > >>RS> urlhandlers set, so we dont have any trouble with bundle:// URLs > >>returned by > >>RS> resources located using Felix (Tuscany calls
Re: Tuscany SDO Memory Leaks in Production Server Environment
Hi Ron, the SDO code never touches ConfigurationCache directly, and the EMF JavaDoc says it is an internal API [1]. I guess this is one to raise with EMF. A google on ConfigurationCache reveals very little in terms of anyone having hit this issue before. Are you happy to raise this on the EMF newsgroup? I'm happy to support you as best I can, but I think direct communication between you and them is going to be the easiest way to resolve this. Kelvin. http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse.emf.doc/references/javadoc/org/eclipse/emf/ecore/xmi/impl/ConfigurationCache.html On 10/01/2008, Ron Gavlin <[EMAIL PROTECTED]> wrote: > > Greetings, > > We are using Tuscany SDO 1.0 in a production server environment. During > application execution, we see the XMLStrings contained in the EMF > org.eclipse.emf.ecore.xmi.impl.ConfigurationCache.printers[] array growing > without bound until eventually we are forced to restart the application. > There exists a ConfigurationCache.release() method which appears designed > to release this cache. However, we never see this method being invoked > during the life-cycle of our application. Any suggestions for resolving this > problem? Your prompt assistance with this matter is appreciated. > > - Ron > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Eclipse RCP apps and Tuscany
The SCADomain.newInstance() method and the DefaultSCADomain class in host-embedded have been replaced by the domain and node APIs in domain-api and node-api. However, most samples have not yet been converted to the new APIs. For examples of samples that use the new APIs, see callback-ws-client, callback-ws-service and calculator-distributed. Do the same issues apply to the new APIs, or only when the old DefaultSCADomain class is used? Simon Rajini Sivaram wrote: SCADomain.newInstance(compositeName), which is used in many of the Tuscany samples to create a DefaultSCADomain works only if contextClassLoader.getResource(compositeName) returns a file:// or jar:// URL. This is broken when Tuscany is run under OSGi, since Apache Felix returns a bundle:// URL and Equinox returns a bundleresource:// URL for the composite. At the moment, existing samples can be run under an OSGi based Tuscany only by using a custom classloader as the thread context classloader, which returns file:// or jar:// URLs from its getResource method, like Jason described( http://marc.info/?l=tuscany-user&m=119559170431301&w=2). DefaultSCADomain determines the location of the SCA contribution relative to the composite or sca-contribution.xml. This file is first loaded using applicationClassLoader.getResource(), and root of the contribution folder or jar file is determined from the resource URL. Since bundle:// URLs dont correspond to a folder or jar file, they are not correctly processed by Tuscany. To fix this in Tuscany, we need a BundleContributionProcessor similar to JarContributionProcessor (at the moment, artifacts from bundle contributions are read using the JarContributionProcessor). The bundle contribution processor should either 1) read the stream using the bundle URL and use OSGi bundle API to read its artifacts or 2) find the actual file location corresponding to the bundle and read it using the JarContributionProcessor. Unfortunately, both of these require OSGi specific code in the contribution processing logic. addContribution() methods for SCANode and SCADomain work with file:// URLs which specify bundle contributions, and these are resolved correctly using OSGi. But at the moment, they cannot process bundle:// URLs. A proper fix for DefaultSCADomain will also enable bundle:// or bundleresource:// URLs to be used in addContribution(). Since this is a problem only when Tuscany is run under OSGi, and any fix would require adding OSGi specific code into the contribution processing code in Tuscany, I am not sure if this needs fixing in Tuscany, or the workaround of overriding the context classloader is sufficient. Thoughts? On 11/23/07, Peter Kriens <[EMAIL PROTECTED]> wrote: I think it sounds very much like Felix Meschberger's conclusion. Converting URLs to strings and then back to URLs, which is not necessary and not guaranteed to work. Anyway, I'd like to know why someone needs to escape to Equinox hooks when it should work on standard OSGi level ... Kind regards, Peter Kriens RS> Hi, RS> Tuscany supports OSGi bundle contributions which are currently loaded using RS> the Apache Felix OSGi runtime by default. These contributions can contain RS> composite files and other meta-data which are loaded using OSGi and RS> passed around as URLs. Tests for OSGi contributions are run under Felix with RS> urlhandlers set, so we dont have any trouble with bundle:// URLs returned by RS> resources located using Felix (Tuscany calls openConnection and openStream RS> on these urls). RS> Are the Eclipse RCP apps run without an URL stream handler to handle RS> bundleresource:// URLs? RS> Thank you... RS> Regards, RS> Rajini RS> On 11/23/07, Felix Meschberger <[EMAIL PROTECTED]> wrote: Hi all, I don't think it is a bug in eclipse (just from the likeliness point of view). What I do not know is, what Tuscany does with the URLs returned. If they would just open a stream on the URL, there would be no issue at all, because the URls are backed by handlers supporting opening the streams. If on the other they convert the URls to Strings and later want to create URLs from the strings again, they are hosed. But I assume, this is then a bug/issue in Tuscany rather than in Eclipse. In fact, they might run into the same troubles with Felix or just about any framework... Regards Felix Am Freitag, den 23.11.2007, 08:55 + schrieb Rob Walker: Peter On a very quick read thru this - tbh - it sounds like a bug/feature of their OSGi implementation. I'm 99% sure we use classloader getResource() calls under Felix, and the felix classloaders correctly resolve them to bundle URL references which can then be used in a normal way. Pretty sure you need the URL handler feature enabled, since I think as Jason points out the URL returned has a custom protocol type that the specific framework implementation needs to handle. A possible alternative may be for them to use getResourceAsStream() if viable
