ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ciaran Jessup (JIRA)" <j...@apache.org>
Subject [jira] Updated: (ODE-575) oAssign$Literal seems to consume an excessive volume of memory
Date Wed, 08 Apr 2009 14:09:12 GMT

     [ https://issues.apache.org/jira/browse/ODE-575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Ciaran Jessup updated ODE-575:

    Attachment: AssignLiteralMemoryRedux.patch

The attached patch attempts to reduce the memory footprint of a BPEL process that contains
large numbers of literal assigns.   It does this by removing the reference to the 'cached/pre-built'
document held internally, and adds a string in place of it.  

>From the outside, the only semantic difference should be when it now hydrates the object
it no longer 'validates' that XML object, this happens when the literal is requested, I *think*
that this should be ok as the CBP file should have validated when it was created???  

As an example this reduced the memory footprint of one of my processes from >2.4Gb to ~400Mb

If the speed of creating the literal objects is an issue perhaps a weakly-referenced cache
of them could be constructed at runtime on an ad-hoc basis?.. I'm not quite sure how the speed
will have changed in relation to  the previous code as that created a new document each time
anyway..but not from a raw string.

> oAssign$Literal seems to consume an excessive volume of memory
> --------------------------------------------------------------
>                 Key: ODE-575
>                 URL: https://issues.apache.org/jira/browse/ODE-575
>             Project: ODE
>          Issue Type: Improvement
>          Components: BPEL Runtime
>         Environment: n/a
>            Reporter: Ciaran Jessup
>         Attachments: AssignLiteralMemoryRedux.patch
> Our BPEL workflows contain a large number of literal assigns, these are stored as Document
instances in the BPEL runtime, which are cloned each time they are referenced, this appears
to consume an immense amount of memory :( making it un-workable for my current BPEL flows

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message