Serialize/Unserialize Errors

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?

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?

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

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;

It looks like this is fixed with the latest beta release.