Forums / Developer / memory leak on content/publish ?

memory leak on content/publish ?

« 
Previous topic
|
Developer
|
Next topic
 »
Author Message

*- pike

Thursday 27 December 2007 4:13:50 am

nope .. sorry.
haven't been able to locate the problem, yet :-(

$2c,
*pike

---------------
The class eZContentObjectTreeNode does.

Olivier Versanne

Tuesday 23 June 2009 6:26:34 am

Hi!

And now? I'm currently having the same problem and I'm loosing a lot of hair to fix this problem...

André R.

Tuesday 23 June 2009 7:03:32 am

See the other thread:
http://ez.no/developer/forum/developer/how_to_build_an_update_cli_script_without_memory_problem#msg187431

eZ Online Editor 5: http://projects.ez.no/ezoe || eZJSCore (Ajax): http://projects.ez.no/ezjscore || eZ Publish EE http://ez.no/eZPublish/eZ-Publish-Enterprise-Subscription
@: http://twitter.com/andrerom

Olivier Versanne

Tuesday 23 June 2009 7:18:00 am

Thanks, but I'm already implementing this solution. That works for a lot of things, but for attribute storage of an object: 

$dataMap = $object->dataMap();
[...] 
$dataMap[$key]->setAttribute( $dataType, $content );
$dataMap[$key]->store(); // here

and for the publication of an object:

eZOperationHandler::execute( 'content', 'publish', array( 'object_id' => $object->attribute( 'id' ), 'version' => $object->attribute( 'current_version' ) ) );

that don't work.

*- pike

Tuesday 23 June 2009 12:59:15 pm

Hi

Just to let you know, I didn't find a solution (or where the leak was) at the time. I haven't tested it lately. We upgraded to 4.x, but it wouldn't surprise me if it still happened. And your post is suggesting $attribute->store() has a similar leak ?

You can test that by hardcoding some debug in moduleOperationInfo::executeBody

Andre R. - that's a nice link. 

unset( $GLOBALS['eZContentObjectContentObjectCache'] );    
unset( $GLOBALS['eZContentObjectDataMapCache'] );    
unset( $GLOBALS['eZContentObjectVersionCache'] );    
unset( $GLOBALS['eZContentClassAttributeCache'] );    
unset( $GLOBALS["eZUserObject_".$node->ContentObjectID] );

I'm not sure if I checked the last one - i did inspect the others, and they didnt make much difference. The memory was lost somewhere else.

*-pike

---------------
The class eZContentObjectTreeNode does.