Zend Framework 1.12 + Crontab + odbc query — Неустранимая ошибка: допустимый объем памяти

в настоящее время у меня есть разработанное приложение в Zend Zend Framework 1.12 на сервере Ubuntu 14.04.2 с 64-битным драйвером ODBC iSeries Access

Когда я вручную выполняю следующий запрос от контроллера, я правильно получаю результат:

class MaestrosController extends Zend_Controller_Action {

public function indexAction() {
$this->_query("SELECT OKCUNO AS VALUE, OKCUNM AS OPTION FROM OCUSMA WHERE OKCONO = 1");
}

private function _query($query) {
try {
$conexion = $this->_connect();
$result = odbc_exec($conexion, $query);
}catch (Exception $e){
die($e->getMessage());
}
$salida = array();
while( ($row = odbc_fetch_array($result)) !== false ) {
array_push($salida, $row);
}
$this->_disconect($conexion);
return $salida;
}

private function _connect()
{
$objConnect =  odbc_connect('EXPO', $this->odbc_user,$this->odbc_calve) or die('Connect: '.odbc_errormsg()."\n");
return $objConnect;
}

private function _disconect($conexion)
{
odbc_close($conexion);
}
}

Однако, когда я выполняю это через контрабанду:

php /var/www/vhosts/core.lan/application/cronjobs/cronjob.php >> /tmp/logcron.log

cronjob.php

define("_CRONJOB_",true);
require_once('/var/www/vhosts/core.lan/httpdocs/index.php');

(...)

$this->_query("SELECT OKCUNO AS VALUE, OKCUNM AS OPTION FROM OCUSMA WHERE OKCONO = 1");

(...)

Появляется следующее сообщение об ошибке:

Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 16815550472902410251 bytes) in /var/www/vhosts/core.lan/application/models/DbTable/M3.php on line 259.

Строка 259 соответствует $result = odbc_exec($conexion, $query);

Для выполнения через cron мой индекс был настроен следующим образом:

(...)

$application->bootstrap();

//Cronjobs don't need all the extra's so we don't execute the bootstrap
if(!defined('_CRONJOB_') || _CRONJOB_ == false){
$application->bootstrap()->run();
}

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


В поисках решения я обнаружил, что если я выполню следующий запрос через контрабанду:

SELECT OKCUNO AS VALUE, OKCUNM AS OPTION FROM OCUSMA WHERE OKCONO = 1 FETCH FIRST 14 ROWS ONLY

Это прекрасно работает:

+-----------+-------------------------------------+
| VALUE     | OPTION                              |
+-----------+-------------------------------------+
| 0000001   | ANIBAL                              |
| 0000002   | MODAS                               |
| 0000003   | NOVIAS                              |
| 0000004   | ROSA                                |
| 0000005   | RC                                  |
| 0000006   | BELLAESPOSA                         |
| 0000007   | RICARDO                             |
| 0000008   | YOLANDA                             |
| 0000009   | HUELVA .                            |
| 0000010   | DROP                                |
| 0000011   | DOBADOCA                            |
| 0000013   | MARIA                               |
| 0000014   | MODA                                |
| 0000015   | HABITUS                             |
+-----------+-------------------------------------+

тем не менее, если я выполню следующее, появится фатальная ошибка:

SELECT OKCUNO AS VALUE, OKCUNM AS OPTION FROM OCUSMA WHERE OKCONO = 1 FETCH FIRST 15 ROWS ONLY

Если я хочу видеть, что информация отображается в этой строке, я выполняю isql -v EXPO и я получаю следующий результат

+-----------+-------------------------------------+
| VALUE     | OPTION                              |
+-----------+-------------------------------------+
| 0000001   | ANIBAL                              |
| 0000002   | MODAS                               |
| 0000003   | NOVIAS                              |
| 0000004   | ROSA                                |
| 0000005   | JON                                 |
| 0000006   | BELLAESPOSA                         |
| 0000007   | CHARLES                             |
| 0000008   | YOLANDA                             |
| 0000009   | HUELVA                              |
| 0000010   | DROP                                |
| 0000011   | DOBADOCA                            |
| 0000013   | MARIA                               |
| 0000014   | MODA                                |
| 0000015   | HABITUS                             |
| 0000016   | Mª ANGELES                          |
+-----------+-------------------------------------+

Я считаю, что проблема может исходить от характера ª,


Я прочитал следующую статью на сайте IBM https://www-01.ibm.com/support/knowledgecenter/ssw_ibm_i_61/rzatv/rzatvlanguageodbc.htm:

Набор символов приложения ODBC

Набор символов приложения ODBC определяется текущей локалью
набор символов.

$ locale верните следующее:

LANG=es_ES.UTF-8
LANGUAGE=
LC_CTYPE="es_ES.UTF-8"LC_NUMERIC="es_ES.UTF-8"LC_TIME="es_ES.UTF-8"LC_COLLATE="es_ES.UTF-8"LC_MONETARY="es_ES.UTF-8"LC_MESSAGES="es_ES.UTF-8"LC_PAPER="es_ES.UTF-8"LC_NAME="es_ES.UTF-8"LC_ADDRESS="es_ES.UTF-8"LC_TELEPHONE="es_ES.UTF-8"LC_MEASUREMENT="es_ES.UTF-8"LC_IDENTIFICATION="es_ES.UTF-8"LC_ALL=

Но команда $ sudo /opt/ibm/iSeriesAccess/bin64/cwbnltbl дает мне это:

cwbnltbl - Download conversion table utility
Usage: cwbnltbl source-code-page target-code-page [host] [uid] [pwd]
Linux locale codeset=UTF-8 ccsid=1208

и я не знаю что с этим делать.

Единственная информация, которую я смог найти и которая более или менее похожа на мою проблему, — это сообщение: Linux odbc Неустранимая ошибка: допустимый объем памяти, Однако предложенное решение не может помочь мне вообще.

Я прошу кого-нибудь оказать мне поддержку в этом вопросе.

Спасибо!

0

Решение

Вы, вероятно, бежите в этот проблема со старым драйвером ODBC iSeries Access для Linux. Поскольку 64-битный ABI изменился в unixODBC 2.2.13 для поддержки 64-битных параметров, драйвер iSeries Access 7.1 (и более ранних версий) будет давать неверные результаты при использовании с приложениями, созданными для unixODBC 2.2.13 или более поздней версии.

Решение состоит в том, чтобы использовать новый драйвер ODBC IBM i Access, который является частью Клиентские решения IBM i Access — Пакет приложений Linux, который был обновлен для использования нового ABI.

0

Другие решения

Проблема была связана с языком среды, в которой выполняется скрипт php.

Запустив следующее утверждение, я смог это исправить:

LANG = es_ES;

Если я запускаю следующее через crontab, у меня нет проблем:

LANG = es_ES; php -f /var/www/vhosts/core.lan/application/cronjobs/cronjob.php >> /tmp/logcron.log

Таким образом, решение состоит в том, чтобы исправить язык php.

0

По вопросам рекламы [email protected]