You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ode.apache.org by "Ciaran Jessup (JIRA)" <ji...@apache.org> on 2009/04/08 16:01:15 UTC
[jira] Created: (ODE-575) oAssign$Literal seems to consume an
excessive volume of memory
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
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.
[jira] Updated: (ODE-575) oAssign$Literal seems to consume an
excessive volume of memory
Posted by "Ciaran Jessup (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (ODE-575) oAssign$Literal seems to consume an
excessive volume of memory
Posted by "Karthick Sankarachary (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Karthick Sankarachary updated ODE-575:
--------------------------------------
Attachment: reduce-xml-literal-size.patch
> 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, reduce-xml-literal-size.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.
[jira] Commented: (ODE-575) oAssign$Literal seems to consume an
excessive volume of memory
Posted by "Ciaran Jessup (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12698960#action_12698960 ]
Ciaran Jessup commented on ODE-575:
-----------------------------------
I agree totally, the only reason I didn't do this was because I don't really know the code well enough to introduce semantic changes :) I've never been a fan of swallowing exceptions :) But your changes to my patch look great !
> 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, reduce-xml-literal-size.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.
[jira] Commented: (ODE-575) oAssign$Literal seems to consume an
excessive volume of memory
Posted by "Karthick Sankarachary (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12698958#action_12698958 ]
Karthick Sankarachary commented on ODE-575:
-------------------------------------------
Ciaran,
Thanks for bringing this issue to our attention. The solution you proposed looks good, in general. However, I suggest that we make one minor change to your patch. Instead of swallowing the exception thrown in OAssign.Literal.getXMLLiteral(), I would rather just throw it, so that it causes a selection failure in the Assign statement. I believe that would be the behavior the user might expect to see if there was indeed something fishy about the XML literal. WDYT?
Regards,
Karthick
> 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, reduce-xml-literal-size.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.
[jira] Resolved: (ODE-575) oAssign$Literal seems to consume an
excessive volume of memory
Posted by "Karthick Sankarachary (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Karthick Sankarachary resolved ODE-575.
---------------------------------------
Resolution: Fixed
Ciaran, I have applied the patch based on your proposal at revision 765007. Thanks, Karthick
> 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, reduce-xml-literal-size.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.