I have a module which implements token_replace. It is used to display a proper phone number in the banner depending on a customer type with a default value in place if we don't know, and is used for some data in e-mails along with the previewable email template module.

Occasionally the tags for tokens are left in place instead of being replaced. This only occurs during high volume as we can not reproduce the issue in a staging environment. Have any of you encountered token_replace intermittently being not called at all?

Clearing the class registry cache appears to resolve the issue temporarily but eventually it occurs again.

A Coworker did a write up of the issue for some people which I am including below in case his words are clearer:

Domain: Drupal has a token replacement system in place, where it will replace [revel_soap:phone_number] with the phone number. We have a module, revel_soap, which contains a drupal "hook", for tokens. revel_soap_tokens is the function name. This is located in revel_soap.module. A module's files are included in the module.info file, files[] array. The .module file is supposed to be automatically included, where the bulk of the definitions for the module are included.

It is running either on one or two servers, with both configurations going through the load balancer, just either with one or two servers to choose from.


We observed that when the site is running on one server, it is not having any issues. When we put the site on two servers, it works fine for up to 40-50 minutes, but then the replace_tokens function will not work, it doesn't call our method "revel_soap_tokens" to find values for the tokens. For the phone number, this isn't a big issue, but the main problem is that emails go out that depend on tokens, for activating a user. They will receive emails with broken links that would normally bring them back to the site and activate their account.

For the phone number issue, if the code is called, if the session values aren't present, it will fall through to the default case which returns a hard coded phone number. This leads us away from the diagnosis of a session issue, and towards a class registry issue.

The temporary fix to this is to clear the Drupal Class Registry. Phone numbers show up, and emails get generated correctly (more importantly). We left the phone number issue in place so we can easily see when the problem occurs, through tools that we use / wrote.

During the time that this is happening, SOAP calls are still being made. Here is the files array for our .info file

files[] = "revel_soap_calls.inc" files[] = "revel_soap.test"

The second one contains test calls and is not used otherwise.

When a module is included, the .module file should also be included. Our tokens hook should be present. However, on the two server environment, it appears that the tokens hook disappears.

I've added our .module file to the files[] array and watched it show up in the registry_files table after a Drupal cache clear. I've seen some modules include the .module file and others that didn't. I have not had a chance to test this on the load balanced environment.

We are running drupal 7.14.

Any ideas would be appreciated!

  • I'd look at what's in the registry when the problem exists versus what's there when it isn't. It sounds as though under some circumstances it's getting partially rebuilt and the difference may provide a clue as to how that can occur. Commented Apr 4, 2013 at 16:36
  • searching for information about said registry yields lots of information about rebuilding it but I can not find out where to find it to simply view it. Could you tell me where to find it?
    – lathomas64
    Commented Apr 4, 2013 at 17:57
  • It's two database tables: registry and registry_file. There's also a series of entries in the cache_bootstrap table, which I think I'd look at first. If you are using memcached or some other alternative cache it may be more difficult to diagnose the issue but the keys you need to check in that cache are bootstrap_modules, hook_info, lookup_cache, module_implements, system_list, variables. The most likely culprits being hook_info, lookup_cache, module_implements. Commented Apr 5, 2013 at 7:48
  • getting it to occur is problematic though as it is only happening on live and when it does we need to quickly get the registry rebuilt to avoid any of our client's customer's receiving a bad activation e-mail.
    – lathomas64
    Commented Apr 5, 2013 at 18:07
  • All I can suggest is that you write a custom script to dump the current registry to a file then rebuild it. You can then inspect its content at your leisure. Commented Apr 7, 2013 at 10:16


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.