MySQL server has gone away - Разработка расширений для Joomla 3.x

Доброго времени суток всем!
Есть у меня один парсерчик, который поставлен на cron, чтобы делать всякие скучные дела и записывать данные в БД. До недавнего времени исправно работал, но 3 дня назад стал выдавать ошибки. Запускаю его так

updateStatus() по сути - это усеченная JshoppingControllerOrders::_updateStatus(), а ошибки выдает этот кусок
Но INSERT там не должно быть! Добавил
Пытался увеличить wait_timeout (по-умолчанию у beget: 30) до нормальных 28800

То ли wait_timeout - не причина, то ли я его не там модифицировал (может быть, прямо в ядре надо делать?).
Есть ли у кого-нибудь опыт в борьбе с данным глюком?

Сколько записей то в таблице xs5yt_jshopping_orders ? индексы корректно расставлены?

Немного, @Aleks.Denezh, порядка 11000.
На счет индексирования надо проверить, но я всего лишь делаю точечный UPDATE, а не SELECT. Скрипт выполняется в течение 10 мин и, скорее всего, за это время MySQL-сервер просто отключается.
Пока написал техподдержке и просил изменить настройки. Надеюсь, на этом вопрос решится.

Пока написал техподдержке и просил изменить настройки. Надеюсь, на этом вопрос решится.

Вопрос решился именно таким образом, правда, не без борьбы с хостингом.

Вопрос решился именно таким образом, правда, не без борьбы с хостингом.

И что они сделали?

Все оказалось совсем не так, как я думал, посмотрев на лог работы скрипта.
Вот последние сообщения из истории переписки:
Хост - beget.
Решение вопроса:

то есть получается, что ошибка была в вашем скрипте, по крайней мере на данный момент?

вообще странно - вы говорите у вас примерно 11 000 записей в таблице, а проблема началась с поля ID примерно 30 000.

я хотел вам посоветовать в конфигурационном файле сервера MySQL задать явно max_allowed_packet, но понял что речь о shared hosting.

@capricorn, ошибки в моем скрипте не было и нет, а в данный момент у него нет никаких проблем.
Проблемой было ограничениченное хостингом значение параметра wait_timeout в 30 секунд. Ее я уже решил и выложил решение.
Теперь все понятно?

не совсем понимаю, как вы это сделали. но хорошо, что вы решили проблему.

Вообще удивительно, это какой скрипт нужно создать, чтобы он споткнулся на таблице из всего 11 тысяч строк.

Что такое точечный UPDATE? Наверное речь о том, что MySQL сразу видит что ему обновлять, не проходя базу. Бред.

Я не в обиду говорю, просто х***ю не надо нести.

Ну что с вами делать, @capricorn? Послать в баню? Вы же вроде грозились удалиться, а до сих пор еще надоедаете людям здесь, или это другой @capricorn?
Да перестаньте комплексовать, вы не должны все знать. Не пишите там, где не понимаете суть вопроса, чтобы потом не злиться и хамить.

техподдержка конечно на высоте


непосредственно перед выполнением запросов (в т.ч. табличных методов load, store и т.п.) не помогает?

Код

$db->connect();

непосредственно перед выполнением запросов (в т.ч. табличных методов load, store и т.п.) не помогает?

Возможно, @dmitry_stas, но свое решение уже нашел

Решение вопроса:

Код

$db = JFactory::getDbo();
$db->setQuery('SET SESSION wait_timeout = 28800')->execute();
$order = JTable::getInstance('order', 'jshop', array('dbo' => $db));

, так что экспериментировать дальше не буду.

@robert, та не, я не к тому я просто хотел разобраться где именно ошибка. дело в том, что в методах JDatabaseDriver (например execute, loadObjectList и подобных) перед выполнением всегда вызывается $db->connect(), в котором проверяется живучесть подключения, и при необходимость происходит повторный коннект. а получается что в табличных методах этого видимо не делается. и если так и есть, то это ошибка.

@dmitry_stas, забыл сказать, что у клиента стоит J!2.5 .
Ну конечно, в более свежих версиях ничего этого бы не было .

понял уже проще