Posted by eyecon on January 23, 2009 at 11:44pm
Jump to:
| Project: | FeedAPI |
| Version: | 6.x-1.6 |
| Component: | Code parser_common |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
Last cron run produced five log pages of the following error messages:
unserialize() [function.unserialize]: Node no longer exists in /var/www/queer/sites/all/modules/feedapi/parser_common_syndication/parser_common_syndication.module on line 127.
serialize() [function.serialize]: Node no longer exists in /var/www/queer/sites/all/modules/feedapi/feedapi.module on line 1125.
Can someone tell me what is going on here?
Comments
#1
I MIGHT have found the problem. Then the question is what caused it in the first place? I did the following:
mysql> delete from feedapi_node_item where not exists (select * from node where feedapi_node_item.nid=node.nid);
Query OK, 134831 rows affected (34.10 sec)
The hypothesis is that deleted nodes did not delete the corresponding feeapi_node_item.
I would note that by raw count the same problem exists in feedapi_node_item_feed but I have not yet figured out the mysql routine to fix it. Does feedapi_node_item_feed.feed_item_nid match to feedapi_node_item.nid?
#2
Anyone out there?
The culprit was probably the views bulk operations module. I have everything back in sync but I am still getting these errors every fifth or sixth cron run.
"Back in sync" means that feedapi_node_item and feedapi_node_item_feed correctly correlate to the node table and to each other. I have also manually refreshed each of the (now about 500) feeds. As expected, the record count feedapi_node_item_feed is greater than feedapi_node_item which accounts for duplicate stories being handled properly by feedapi.
I also think that the refresh rate is no longer "fair." In other words, some feeds seem to be refreshing more frequently than others.
Any suggestions?
#3
I think this is related:
http://drupal.org/node/199337
It might possible to parser common syndication forget to cast something into string in some cases.
Feed URL? :)
#4
#5
I am reopening this issue because it is persistent. Almost all of these errors occur with the common syndication parser.
"Node no longer exists ... /modules/feedapi/parser_common_syndication/parser_common_syndication.module on line 127."
When this occurs, I am getting 242 messages printed to syslog on 150 feeds processed per cron run. But, only 18 are likely to be parsed by CSP (87.5% of my feeds are simplepie parsed). Therefore, a few feeds are causing a great many errors. There doesn't seem to be a way to associate a specific feed or feeds to the error.
/*** Store the parsed feed into the cache
*/
function _parser_common_syndication_cache_set($url, $parsed_feed) {
$cache_file = _parser_common_syndication_sanitize_cache() .'/'. md5($url);
$cache_fp = fopen($cache_file, 'w');
Line 127-> fwrite($cache_fp, serialize($parsed_feed));
fclose($cache_fp);
}
Can you take another look at this?
Thanks
#6
I found this:
http://drupal.org/node/199337
"This object is a built-in object in PHP terminology, and should not be serialized/unserialized. See the discussion here: http://us3.php.net/manual/en/function.serialize.php"
"In my case I was trying to store a string, but unknowingly I was storing an object. I had parsed an RSS feed using SimpleXML and extracted one element like so:"
$status = $statusobject->channel->item[0]->title;The resulting $status was printable as a string but actually, unbeknownst to me, was an object when passed through D6's cache functions. When D6 attempted to unserialize the stored value, PHP threw an error: "Node no longer exists."
A cast fixed the problem:
$status = (string) $statusobject->channel->item[0]->title;#7
It looks like this is fixed with the latest beta release.
#8
It's still there in beta 1.9. Problem exists in parser_common_syndication.inc line 59:
return unserialize((string) $file_content);I commented that line out, so it skips caching -- hocus pocus, everything works.