I Created a Solr server with a index
then I edit fields and select:

Multiterm - taxonomie field (made from Autocomplete term widget (comma seperated tagging))

Ten I get a PDOException when I enable such a field and flush caches or open views (overview page)

Single terms seem to work perfect.

Additional uncaught exception thrown while handling exception.
Original

PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away: INSERT INTO {watchdog} (uid, type, message, variables, severity, link, location, referer, hostname, timestamp) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9); Array ( [:db_insert_placeholder_0] => 1 [:db_insert_placeholder_1] => menu [:db_insert_placeholder_2] => %type: !message in %function (line %line of %file). [:db_insert_placeholder_3] => a:6:{s:5:"%type";s:12:"PDOException";s:8:"!message";s:215:"SQLSTATE[HY000]: General error: 2006 MySQL server has gone away: SELECT filename FROM {registry} WHERE name = :name AND type = :type; Array ( [:name] => views_plugin_access_none [:type] => interface ) ";s:9:"%function";s:22:"_registry_check_code()";s:5:"%file";s:36:"/var/www/html/includes/bootstrap.inc";s:5:"%line";i:2800;s:14:"severity_level";i:3;} [:db_insert_placeholder_4] => 3 [:db_insert_placeholder_5] => [:db_insert_placeholder_6] => http://www.solr-deplate.be/admin_menu/flush-cache?destination=alle-museu... [:db_insert_placeholder_7] => http://www.solr-deplate.be/alle-museum-items [:db_insert_placeholder_8] => 178.116.195.171 [:db_insert_placeholder_9] => 1302955021 ) in dblog_watchdog() (line 155 of /var/www/html/modules/dblog/dblog.module).
Additional

PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away: SELECT lid, location FROM {locales_source} WHERE source = :source AND textgroup = 'default'; Array ( [:source] => An AJAX HTTP error occurred. ) in _locale_parse_js_file() (line 1326 of /var/www/html/includes/locale.inc).
Uncaught exception thrown in shutdown function.

PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away: DELETE FROM {semaphore} WHERE (value = :db_condition_placeholder_0) ; Array ( [:db_condition_placeholder_0] => 14145872564da9841161e0c9.79836988 ) in lock_release_all() (line 247 of /var/www/html/includes/lock.inc).

Comments

drunken monkey’s picture

Title: PDOException when enabling a Autocomplete term widget » PDOException when enabling a taxonomy term field with multiple values
Issue tags: -PDOException, -Search API

Doesn't seem to be connected to the Search API:
#1014172: General error: 2006 MySQL server has gone away in _drupal_session_write() when max_allowed_packet is not set high enough
#1082864: Taxonomy module MySQL errors w/XAMPP - "MySQL server has gone away" + "Additional uncaught exception"
#984112: Not setting max_allowed_packet in MySQL according to installation requirements can lead to PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away

However, now that I think about it, this might be caused, or at least triggered, by the Facets module wanting to save all facet names. For a free tagging field, there might be huge amounts of different terms, which could result in a timeout.
Please check how many terms you have in the vocabulary, and what your MySQL timeout limit is. If this really leads to such issues, we'll have to fix this either in Entity API or Search API Facets.

IT100’s picture

I've set the timeout to 600 seconds but the pdo exception shows immediately so I guess the issue doesn't have to do with timeouts.

But:

If I select a field in the index of the solr config wich contains only 10 or so tax terms = no problem.

But if the Vocabulary contains 2000 terms then I get the PDO exeption.
(after a few seconds - so no timeout issue - I guess)

There are more than 130000 tax - terms in about 25 vocabulary's in the system in total. This amount is going to grow when I import a few more databases from different systems in the near future.

drunken monkey’s picture

Really the MySQL timeout (wait_timeout MySQL session variable), and not PHP's script execution timeout or the connection timeout? Other causes for such errors seem to be highly uncommon.

In any case, please help me confirm the place where the error occurs. I guess it occurs when _search_api_facets_refresh_type() (search_api_facets.module:929) is called for that field – but now that I think about it, if you just enabled the field, there won't be a facet for it, yet. Or did you already index the field and enable a facet for it some time previously?
Assuming, that is, that you have even enabled the Facets module and are using facets for this index.
In any case, it would be great if you could find out (by inserting debug statements or using a debugger) how far script execution gets before the exception is thrown. (Maybe it would even be enough to catch the exception and print its stack trace. But I don't know whether or how that works with those nested exceptions.)

IT100’s picture

The wait_timeout MySQL session variable is at default with 28800 seconds (not ms, but seconds)

I'll set up the debugging session as you suggest. Thanks for pointing me in the direction to look for. Keep you posted!!

Regards,
C.

IT100’s picture

A little debugging shows this has nothing to do with facets. ( the breakpoint in the suggested function isn't reached)

To simulate this error you have to:

go to search api -> index -> enable 'indexed' for field type 'taxonomy term'

If the taxonomy term enabled is linked to a vocabulary with a lot of terms*
and you flush caches (in this example) or go to views you'll get:
-----------------------------------------------------------------------------------------------------------
Additional uncaught exception thrown while handling exception.
Original

PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away: INSERT INTO {watchdog} (uid, type, message, variables, severity, link, location, referer, hostname, timestamp) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9); Array ( [:db_insert_placeholder_0] => 1 [:db_insert_placeholder_1] => menu [:db_insert_placeholder_2] => %type: !message in %function (line %line of %file). [:db_insert_placeholder_3] => a:6:{s:5:"%type";s:12:"PDOException";s:8:"!message";s:217:"SQLSTATE[HY000]: General error: 2006 MySQL server has gone away: SELECT filename FROM {registry} WHERE name = :name AND type = :type; Array ( [:name] => SearchApiViewsHandlerField [:type] => interface ) ";s:9:"%function";s:22:"_registry_check_code()";s:5:"%file";s:36:"/var/www/html/includes/bootstrap.inc";s:5:"%line";i:2800;s:14:"severity_level";i:3;} [:db_insert_placeholder_4] => 3 [:db_insert_placeholder_5] => [:db_insert_placeholder_6] => http://www.solr-deplate.be/admin_menu/flush-cache?destination=node [:db_insert_placeholder_7] => http://www.solr-deplate.be/ [:db_insert_placeholder_8] => 178.116.195.171 [:db_insert_placeholder_9] => 1303533858 ) in dblog_watchdog() (line 155 of /var/www/html/modules/dblog/dblog.module).
Additional

PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away: SELECT lid, location FROM {locales_source} WHERE source = :source AND textgroup = 'default'; Array ( [:source] => An AJAX HTTP error occurred. ) in _locale_parse_js_file() (line 1326 of /var/www/html/includes/locale.inc).
Uncaught exception thrown in shutdown function.

PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away: DELETE FROM {semaphore} WHERE (value = :db_condition_placeholder_0) ; Array ( [:db_condition_placeholder_0] => 5207681474db25925b195b4.04305377 ) in lock_release_all() (line 247 of /var/www/html/includes/lock.inc).

-----------------------------------------------------------------------------------------------------------
* containing from about 450 terms in the vocabulary trows the error in my system

drunken monkey’s picture

StatusFileSize
new776 bytes

Views? Well, that could also be a cause, now that I think about it … Please try if the attached patch fixes your problem.
It would be interesting to know, though, if the Facets module can have the same problem, and if we should therefore fix it there, too. Or, as said, in the Entity API module, which maybe shouldn't return options lists in such cases.
Should the patch not work, could you test whether the EntityMetadataWrapper::optionsList() method (in the Entity API) is the culprit? Since the error probably doesn't occur there directly, please do this by testing whether hardcoding the method to return FALSE solves this.

I myself couldn't reproduce this, though, not even with 1500+ terms.
And the specific exceptions don't really help in this case, as they just say that the MySQL connection was terminated (although we still don't know the reason – maybe a too large request, is that possible?) and that this of course lead to Drupal dying miserably. Sadly, they don't tell us which request was the culprit.

But hey, maybe the MySQL log will tell us? Could you inspect that log, right after triggering the bug? Maybe that specifies what problem there was with which request.

IT100’s picture

great, this is the right direction. Although i haven't looked at your patch file method change, uploading it removed the pdoexeption and made the fields available in the facets sections. Enabling them as facets didn't give any problems.

I can flush caches and open views.

maybe you couldn't reproduce this error because the total amount of all terms of all vocabularies isn't > 100000 items like I have?

I shall commit further tests, search results, etc. have to reindex first, etc. Reindexing > 2000 items at a time doesn't seem to behave, anyway still better than the default search method provided by drupal. Keep you posted! Great work!

Regards,

chris.

drunken monkey’s picture

Ah, great! When now everything works, this could at least be a great step forward in fixing this (until someone else shows up, for whom this still causes problems).
Hm, on the other hand, I think this removes the possibility to have select lists as filters for taxonomy terms, which is a problem. I'll talk with fago, maybe we can fix this in Entity API.

drunken monkey’s picture

drunken monkey’s picture

So, is this fixed for you now? Please mark as "fixed" if this is the case.

IT100’s picture

Status: Active » Fixed

Works for me. Thanks.

Status: Fixed » Closed (fixed)

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

IT100’s picture

Sorry for reopening this, but this error has returned after installing the latest dev.

Not sure were Fago changed #9, can't trace it anyway. I'm willing to look for a solution if you guys can point me in the right direction.

Additional uncaught exception thrown while handling exception.
Original

PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away: INSERT INTO {watchdog} (uid, type, message, variables, severity, link, location, referer, hostname, timestamp) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9); Array ( [:db_insert_placeholder_0] => 1 [:db_insert_placeholder_1] => menu [:db_insert_placeholder_2] => %type: !message in %function (line %line of %file). [:db_insert_placeholder_3] => a:6:{s:5:"%type";s:12:"PDOException";s:8:"!message";s:217:"SQLSTATE[HY000]: General error: 2006 MySQL server has gone away: SELECT filename FROM {registry} WHERE name = :name AND type = :type; Array ( [:name] => SearchApiViewsHandlerField [:type] => interface ) ";s:9:"%function";s:22:"_registry_check_code()";s:5:"%file";s:36:"/var/www/html/includes/bootstrap.inc";s:5:"%line";i:2800;s:14:"severity_level";i:3;} [:db_insert_placeholder_4] => 3 [:db_insert_placeholder_5] => [:db_insert_placeholder_6] => http://www.solr-deplate.be/admin_menu/flush-cache?destination=admin [:db_insert_placeholder_7] => http://www.solr-deplate.be/?q=admin [:db_insert_placeholder_8] => 178.116.192.250 [:db_insert_placeholder_9] => 1306076890 ) in dblog_watchdog() (line 155 of /var/www/html/modules/dblog/dblog.module).
Additional

PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away: SELECT lid, location FROM {locales_source} WHERE source = :source AND textgroup = 'default'; Array ( [:source] => An AJAX HTTP error occurred. ) in _locale_parse_js_file() (line 1326 of /var/www/html/includes/locale.inc).
Uncaught exception thrown in shutdown function.

PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away: DELETE FROM {semaphore} WHERE (value = :db_condition_placeholder_0) ; Array ( [:db_condition_placeholder_0] => 14277394dd926e3e27650.49141803 ) in lock_release_all() (line 247 of /var/www/html/includes/lock.inc).
IT100’s picture

Issue tags: +solved

Adding some extra info in case somebody has similar issues, I've increased the allowed packet size in my.cnf ( centos 5.5) - (or my.ini on some other OS's)

[mysqld]
max_allowed_packet = 512M

This has removed the "PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away" completely.

Shadlington’s picture

Issue tags: -solved
elgarch’s picture

Hello,

I had a little bit the same problem, changed the max_allowed_packet to 512 solved it .

Thanks a lot
Viva Community :)

El garch