On Mon, Mar 30, 2009 at 10:38 PM, Karthick Sankarachary < sankarach...@intalio.com> wrote:
> Hi Ciaran, > > The issue <http://issues.apache.org/jira/browse/ODE-561> you're referring > to aims to limit the total number and/or size of processes in the server's > in-memory cache. That work is currently under review and testing, and I > expect it to be released anyday now. > > As far as the process size (i.e., memory footprint) is concerned, I've a > patch in the works that seems to be able to reduce the size of the BPEL > objects by as much as 70% under certain circumstances. Note that there's not > a whole lot we can do about reducing the size of the WSDL objects, since > that is allocated by Axis2. I will create an issue to track that work > shortly. The BPEL objects are our issue, the WSDL is nothing, we're not worried about those :) V. interested in this patch, if you have it available, would be interested in testing it seperately (won't hold you too it or ask you to fix it ;) !) if that is possible? > > > As far as the re-deploy issue is concerned, that was resolved a while ago. > The patch for the same can be found > here<http://issues.apache.org/jira/browse/ODE-538>. > Please give it a shot and let me know how it goes. We're on SVN HEAD of the 1_XX branch and experiencing the re-deploy issue FWIW ? :( Hope this helps a little... -cj. > > Regards, > Karthick > > > On 3/30/09, Ciaran <ciar...@gmail.com> wrote: >> >> Hiyah, I've heard good things about your progress on the CBP memory >> footprints, the memory usage of the workflows for us is a current concern >> and I'm interested in any progress that you've managed to make so far ? >> >> I hope you don't mind, but because the memory was looking to be an issue >> to me, I did a brief investigation into what I might be able to do to >> improve things ;) (from what I've heard my improvements weren't a touch on >> what you've been looking at!) >> >> We kept running out of memory during Deploy+Un-deploy cycles, a lot of >> memory was being used up by both the ObjectInputStream and by Xerces/DOM. >> One simple thing I noticed for us was the cost of Literal Assigns during >> re-hydration, the stringToDom seemed to allocate a lot of memory when I >> shifted this to the first time the assign was resolved the re-hydration time >> was substantially faster, but obviously any errors in the XML weren't caught >> at that point. >> >> The other thing we noted was that memory used by the initial deploy of a >> workflow didn't seem to be freed up when an un-deploy occurred (the memory >> used by the hydration process was given up, but not the memory used by the >> compilation phase.) A v. brief profile suggested that the Process object >> may be hanging around, I think one instance was in the 'stack' thats used >> within the compiler, but I suspect others. Also for us the _services map >> in ODEServer seemed to contain objects referenced by a MultiValueKey which >> took a 'namespaced' PortType when it was put into the map, but when the >> destroy was trying to remove the service it wasn't using the namespace so it >> was never being removed from the map. I haven't yet worked out if thats >> just some issue with our WSDL but it seems strange that the ODEServer would >> behave differently on a deploy and on an un-deploy... >> >> I hope these comments help in someway, but I appreciate they're not much >> use without a patch or repeatable test-case, so sorry, just not enough time >> to do everything I oughta do :( >> - cj. >> >
