While in general I agree that deprecating interfaces is the way to go, for something which feels like such an implementation detail I think we should consider just fixing it straight off.
Anyone else have any thoughts? Anyone using this outside of Axis2? Cheers, David On 16/07/07, Ann Robinson <[EMAIL PROTECTED]> wrote:
Hi, David, I agree that (c) would be the best solution for the long term. As I look at this problem more, I think it will be necessary to do (b) in the short-term because the WSDLDefinition can be accessed via a Parameter on the AxisService - this is effectively an interface and I want to avoid changing interfaces. Doing (b) would allow this interface to continue to be supported until we can deprecate it and replace it with (c). Ann On 07/16/2007 04:07 AM "David Illsley" <[EMAIL PROTECTED]> wrote (c) sounds like the best long term solution to me. It looks like the objects are just used to serve up ?wsdl and MEX requests, which only requires the host/port to be modified. We'd probably get better performance if we just wrote the definitions to a temporary file and used a templating solution to modify the address on each request. David On 15/07/07, Ann Robinson <[EMAIL PROTECTED]> wrote: > > > Hi, all, > I've been investigating an out-of-memory error that happens on the server > in some environments. In analyzing the java heap dumps, one of the biggest > consumers of memory is with the wsdl4j WSDLDefinition objects. The heap > dump indicates that the WSDLDefinition uses the xerces dom for underlying > support, particularly for schemas. This makes the WSDLDefinition very > heavy-weight. > > The heap dump also shows that the WSDLDefinition objects of concern are the > ones being saved in the AxisService's ParameterInclude list. Comments in > the code (WSDL11ToAxisServiceBuilder) indicate that this is done so that, if > some component needs to utilize the WSDLDefinition, the component can access > it via a Parameter in the AxisService. > > Is it possible to reduce the utilization of the WSDLDefinition? > Some ideas are: > (a) releasing it when it is no longer needed > - this might not be possible to determine > > (b) putting a wrapper on the WSDLDefinition object > > - so that the WSDLDefinition,or a portion of the WSDLDefinition, > can be released > - but if the WSDLDefinition is accessed after it was released, > the wrapper can reload the WSDLDefinition transparently to the > user > > (c) create a layer for caching wsdl-related information > - this would allow for releasing memory based on some algorithm > and/or interface that could indicate what's no longer needed > > Ann -- David Illsley - IBM Web Services Development
-- David Illsley - IBM Web Services Development --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
