Clearing the wsdl cache in /tmp

Hi Dave, a patch would be welcome. Thanks!

Tracking for 7.x-2.x.

+1 for a fix here. I traced a series of confusing problems (related to object/field access, etc.) to this same issue - namely the wsdl cache was not being cleared even though the suite was reporting that it had been. I've marked my previous issue as a dup: #1332260: Missing fields in retrieve() and query() calls. (SOLVED - wsdl cache in tmp not being emptied).

Dave's points make sense, and it seems that this bug could be a notable source of confusion for some users... at least those that use an enterprise wsdl and do any importing. It's also looking like there is no conditional logic wrapping the "Drupal cache emptied and WSDL files removed from temp directory" statement. So even if the 'rm -f ' . $tmp_dir . 'some_wsdl_file_match_expression' line fails, the user is still lead to believe that their cache has been cleared. As part of a fix perhaps it's also worth running a check of the temp dir after attempting to remove any cached wsdl data, and only show the "cache emptied" message if no cache remnants are found? Barring this, it would be useful to just state that "An attempt was made to remove wsdl files from the temp dir, though manual confirmation may be required if any authentication or field-mapping errors are later encountered....".

You should NOT user the soap library cache at all if the WSDL is already on disk.

In our version of the a module that integrates with SalesForce we do:

  // This caches the WSDL in memory only.
  ini_set('soap.wsdl_cache', '2');

An alternative (maybe even better) is:

ini_set('soap.wsdl_cache_enabled', '0');
ini_set('soap.wsdl_cache_ttl', '0'); 

you could also pass the $options array to when instantiating the SOAP client:

array('cache_wsdl' => WSDL_CACHE_NONE)

One problem with rm -f ' . $tmp_dir . 'some_wsdl_file_match_expression is that you may destroy other applications' WSDL cache files that you did not intend to.

If the cache is going to be set to disk, then we should probably store it in /tmp/salesforce via

ini_set('soap.wsdl_cache_dir', '/tmp/salesforce'); 

That would be simple enough to clean up.

It would probably also be good to present an option to admins as to caching the WSDL in memory, disk, or both; and if cache is set to disk it would be nice to show the timestamp for the cached WSDL file.

So, as I see it a patch is needed to:

• Set the WSDL cache dir to /tmp/salesforce
• Show the admin the timestamp for the cached Salesforce WSDL
• Properly clear /tmp/salesforce/* when Clear Cached Object Data button is clicked, and report on the success or failure of that operation
• Provide an option to cache the WSDL in memory, disk, or both

Why do you want to cache at all? There is not benefit if the file is local, only if you are pulling it down from a URL

Hi @pwolanin,

My understanding was based on comment #2 here #473822: Need a "Clear Cache" option for Salesforce/SOAP cache which suggested there was a significant performance issues with not caching the WSDL. Are you proposing to cache in memory only or not to cache the WSDL at all?

My understanding is that the caching feature is only useful when the WSDL is at a remote URL. If it's already on disk locally, there should be no gain from caching, and it causes unneeded pain and confusion as this issue suggests.

It would be interesting to know more about the value of WSDL caching. I've been working with a handful of Drupal/SF integration projects and this issues has tripped me up, in one way or another, on nearly all of them.

As pwolanin noted, having php cache the wsdl in a tmp directory makes sense if the alternative is to fetch it from a remote location, but in this case the salesforce_api is managing a local wsdl copy of it's own at variable_get('salesforce_api_dir_wsdl', FALSE). It looks like this Drupal-specific wsdl file is passed as part of every connection attempt via $sf->client->createConnection($wsdl, $proxy), and my guess is that it's only used if wsdl caching is disabled in php settings (or the cache is being refreshed).

So if wsdl caching is enabled in php settings, the wsdl would be grabbed from the temp directory (on disk), and if it's disabled, the wsdl would be grabbed via variable_get('salesforce_api_dir_wsdl', FALSE) (also on disk). As both these locations are on disk, is there actually any advantage to enabling the php caching? It seems like there is not, at least in "disk" caching mode (the default), but I may certainly still be missing something.

However, if the caching mode is "memory", perhaps having the caching on does still offer an advantage by potentially eliminating a disk read on every connection?

Anyway, my current experience has been that the wsdl in /tmp is always the one that is referenced, and inevitably the only way to refresh this file is to do it by hand, as the logic in salesforce_api_update_wsdl_form_submit() seems to frequently break down, as does disabling and re-enabling the cache.

So perhaps it's safe to say that disabling the cache will not result in any performance costs, and is probably worth doing. However, there may be yet unrealized performance benefits by keeping the cache active if, and only if, switching to "memory" caching mode. Is that a correct analysis?

I think memory caching might help if you are making multiple SOAP calls in one page load, but I'm not sure.

Ok, if we don't want caching, which seems fine to me, then basically the only thing to be done here is to update the README to tell users of the module to not turn caching on. I don't see anywhere in the 6.x-2.x module code where caching is enabled for the WSDL file.

caching is on by default.

@pwolanin ok. So where would be the best place to disable caching, something like this?

No, I would do it less globally. Perhaps there is some other SOAP integration that wants it active.

My suggestion would be to do it in salesforce_api_connect(), or oterhwise as close as possible to where you load the WSDL.

Updated patch, this one is for 7.x-2.x-dev although it would apply to 6.x branch as well.

Committed to 7.x-2.x http://drupalcode.org/project/salesforce.git/commit/590ecb8 and 6.x-2.x http://drupalcode.org/project/salesforce.git/commit/303950f

Is there an extra way to clear the cache besides with the patch? in settings.php? I don´t know what goes on with my installation, but almost nothing works properly and maybe this thread puts me in the right path.

Every cron run sends me this messages:

Notice: Undefined index: student_user in _sf_import_process_records() (line 207 of /home/theveryl/public_html/kings/sites/all/modules/salesforce/sf_import/sf_import.module).
Notice: Trying to get property of non-object in _sf_import_process_records() (line 207 of /home/theveryl/public_html/kings/sites/all/modules/salesforce/sf_import/sf_import.module).
...
Warning: array_keys() expects parameter 1 to be array, null given in salesforce_api_retrieve() (line 1754 of /home/theveryl/public_html/kings/sites/all/modules/salesforce/salesforce_api/salesforce_api.module).
Warning: implode() [function.implode]: Invalid arguments passed in salesforce_api_retrieve() (line 1756 of /home/theveryl/public_html/kings/sites/all/modules/salesforce/salesforce_api/salesforce_api.module).
Notice: Trying to get property of non-object in salesforce_api_retrieve() (line 1756 of /home/theveryl/public_html/kings/sites/all/modules/salesforce/salesforce_api/salesforce_api.module).

PS:student_user doesn´t exist anymore in the site, there is no mapping, no leftover from it... could it be because the cache is not cleared?

hope someone can help me

thanks in advance

i´m willing to pay someone that can help me solve my salesforce case.

Thanks

Hi pwolanin, I'm not a great coder, but this array is to place it in settings.php too?

thanks

@nicodv please file a new issue for this and use the issue summary template please https://drupal.org/node/1155816