So, here's what's going on on my site:
{commerce_customer_profile} contains about 30K records with uid = 0;
So, any time I'm clearing cache or doing something that fires commerce_customer_match_customer_profiles(), PHP runs out of memory.
I patched the default $limit argument to 25, and the issues goes away.

Do I need to figure out why/how the profiles are getting created with uid = 0?
Profiles seem to be working fine despite this.

Filing this as a bug, but I will re-post to drupalcommerce.org if you feel it's a support request.

edit: uid = 0, not uid = 1

Files: 
CommentFileSizeAuthor
#2 commerce_customer-limit_profile_loading-1910932.patch1.05 KBaaronbauman
PASSED: [[SimpleTest]]: [MySQL] 3,570 pass(es).
[ View ]

Comments

lol - Yeah, I'd figure out how you got 30k entries. : D

That said, can you share the patch? Sounds like a reasonable fix.

StatusFileSize
new1.05 KB
PASSED: [[SimpleTest]]: [MySQL] 3,570 pass(es).
[ View ]

This site has 2 different profile types, 9K users, and 25K orders.
So, the 30K number is not far from what I expected.
I'm guessing the issue is having 29K of the 30K profiles are assigned to uid 0.
During cache clear, commerce is trying to load customer profiles by uid and obliterating PHP's memory limit.

Quick and dirty patch attached.

So far I haven't noticed any odd behavior, even though all the profiles are assigned to uid 0.
user_load() still assigns the appropriate commerce_profile even though the uid doesn't match.
So I guess my next question is, why bother with uid at all?

Status:Active» Needs review

Ahh, you know, I thought it was 30k for uid 1 for some reason. That said, it's interesting to me that you'd have anonymous customer profiles - they should be getting updated to the uid of the order during the checkout completion process. Have you disabled those rules?

And where is the customer profile match code being called for uid 0?

the original issue i posted said uid 1 (see edits above), but I checked again and it's actually uid 0.

This is making sense now that you bring up rules.
The assignment rules are not disabled, but the orders in question are created programatically using entity_create_stub_entity() and saved via commerce_order_save().

The only checkout rules being invoked (again, programatically) are 'commerce_cart_product_add' and 'commerce_checkout_complete'.
All the orders in question have a matching uid, even though the profiles for those same orders have uid = 0.
Thinking this through, order->uid must already assigned when the rule commerce_checkout_order_convert gets invoked, preventing the uid assignment action from firing.

Anyway, looks like commerce_customer_match_customer_profiles() is getting called when commerce's rules get rebuilt on a cache clear.
Here's the stacktrace.
(This "cc all" is called from drush, but results of clearing cache through the UI were the same.)

    [0] => commerce_customer_match_customer_profiles : 954 : ~/public_html/sites/all/modules/commerce/modules/customer/commerce_customer.module
    [1] => commerce_customer_options_list :  :
    [2] => call_user_func_array : 799 : ~/public_html/includes/module.inc
    [3] => module_invoke : 460 : ~/public_html/sites/all/modules/entity/modules/callbacks.inc
    [4] => entity_metadata_field_options_list :  :
    [5] => call_user_func : 192 : ~/public_html/sites/all/modules/entity/includes/entity.wrapper.inc
    [6] => optionsList : 111 : ~/public_html/sites/all/modules/rules/modules/entity.eval.inc
    [7] => rules_action_entity_create_info_alter :  :
    [8] => call_user_func_array : 123 : ~/public_html/sites/all/modules/rules/includes/faces.inc
    [9] => __call : 293 : ~/public_html/sites/all/modules/rules/includes/rules.core.inc
    [10] => __call : 1405 : ~/public_html/sites/all/modules/rules/includes/rules.core.inc
    [11] => setUp : 1381 : ~/public_html/sites/all/modules/rules/includes/rules.core.inc
    [12] => __construct : 471 : ~/public_html/sites/all/modules/rules/rules.module
    [13] => rules_plugin_factory : 40 : ~/public_html/sites/all/modules/rules/rules.module
    [14] => rules_action : 2200 : ~/public_html/sites/all/modules/rules/includes/rules.core.inc
    [15] => action : 134 : ~/public_html/sites/all/modules/commerce/modules/checkout/commerce_checkout.rules_defaults.inc
    [16] => commerce_checkout_default_rules_configuration :  :
    [17] => call_user_func_array : 799 : ~/public_html/includes/module.inc
    [18] => module_invoke : 771 : ~/public_html/sites/all/modules/entity/entity.module
    [19] => _entity_defaults_rebuild : 749 : ~/public_html/sites/all/modules/entity/entity.module
    [20] => entity_defaults_rebuild : 955 : ~/public_html/sites/all/modules/entity/entity.module
    [21] => entity_flush_caches :  :
    [22] => call_user_func_array : 823 : ~/public_html/includes/module.inc
    [23] => module_invoke_all : 7307 : ~/public_html/includes/common.inc
    [24] => drupal_flush_all_caches : 241 : ~/drush/commands/core/cache.drush.inc
    [25] => drush_cache_clear_both :  :
    [26] => call_user_func_array : 792 : ~/drush/includes/drush.inc
    [27] => drush_op : 79 : ~/drush/commands/core/cache.drush.inc
    [28] => drush_cache_command_clear :  :
    [29] => call_user_func_array : 324 : ~/drush/includes/command.inc
    [30] => _drush_invoke_hooks : 198 : ~/drush/includes/command.inc
    [31] => drush_command :  :
    [32] => call_user_func_array : 165 : ~/drush/includes/command.inc
    [33] => drush_dispatch : 92 : ~/drush/drush.php
    [34] => _drush_bootstrap_and_dispatch : 61 : ~/drush/drush.php
    [35] => drush_main : 16 : ~/drush/drush.php

Status:Needs review» Fixed

I'm not sure of the best solution here, but it seems a limit is in order and doesn't adversely affect any tests at least. I'm going to up it to 50 and commit (with a similar fix to the product matching functions just to be safe), and for your custom code, I generally recommend using our entity specific *_new() functions and would look into why your uids aren't being set properly. Good luck!

Commit: http://drupalcode.org/project/commerce.git/commitdiff/fdce722

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Component:Customer» Product
Status:Closed (fixed)» Needs work

Hi

It took me a while to track this down. But this patch causes an unfortunate result if you have greater than 50 products that can be shown in the product reference field by a product display and you're not using the autocomplete widget.

Perhaps the fix is to amend the function calls in the product reference rather than the limit introduced in product.

Hopefully it'll help other people find this if it's affecting them by adding this text:

drupal commerce product display product reference showing limited 50 products

Component:Product» Customer
Status:Needs work» Closed (fixed)

Issue summary:View changes

edit: uid = 0, not uid = 1