Horde_Core-2.13.1 breaks SQL database access

After upgrading to Horde_Core-2.13.1, every attempt to displ

Fri, 22 Aug 2014 06:58:06 +0000

After upgrading to Horde_Core-2.13.1, every attempt to display an e-mail or agenda event fails and results in the following error message being logged: [22-Aug-2014 08:47:14] WARNING: [pool www] child 16880 said into stderr: "NOTICE: PHP message: PHP Fatal error: Call to a member function commit() on a non-object in /usr/share/php5/PEAR/Horde/Db/Adapter/Pdo/Base.php on line 268" Downgrading to Horde_Core-2.13.0 immediately fixes things. I'm using SQL for pretty much everything, except for the Horde_Cache (which uses the filesystem).

I don't see any issues, and have a similar setup. Is this wi

Fri, 22 Aug 2014 10:25:18 +0000

I don't see any issues, and have a similar setup. Is this with any action or only those two? And please provide a backtrace.

> I don't see any issues, and have a similar setup. Is this

Fri, 22 Aug 2014 15:35:07 +0000

> I don't see any issues, and have a similar setup. Is this with any > action or only those two? And please provide a backtrace. The latter probably means placing 'Horde::debug' somewhere strategically around line 268 in /usr/share/php5/PEAR/Horde/Db/Adapter/Pdo/Base.php? Having said that, I probably already found the culprit. I use the 'SQL' session handler. When I switch to 'Filesystem storage', there is no problem. Switching back to 'SQL' and the problem is back.

>> I don't see any issues, and have a similar setup. Is this

Fri, 22 Aug 2014 16:55:31 +0000

>> I don't see any issues, and have a similar setup. Is this with any >> action or only those two? And please provide a backtrace. > > The latter probably means placing 'Horde::debug' somewhere > strategically around line 268 in > /usr/share/php5/PEAR/Horde/Db/Adapter/Pdo/Base.php? Setting the log level to DEBUG is sufficient. > Having said that, I probably already found the culprit. I use the > 'SQL' session handler. When I switch to 'Filesystem storage', there > is no problem. Switching back to 'SQL' and the problem is back. Confirmed, though I only see this in Kronolith's Ajax requests.

Could be some shutdown order race condition: [Fri Aug 22

Fri, 22 Aug 2014 16:57:31 +0000

Could be some shutdown order race condition: [Fri Aug 22 18:55:33.865966 2014] [:error] [pid 5172] [client 192.168.60.176:57606] PHP Fatal error: Call to a member function commit() on a non-object in /home/jan/horde-develop/framework/Db/lib/Horde/Db/Adapter/Pdo/Base.php on line 268, referer: http://neo.wg.de/headhorde/kronolith/ [Fri Aug 22 18:55:33.866062 2014] [:error] [pid 5172] [client 192.168.60.176:57606] PHP Stack trace:, referer: http://neo.wg.de/headhorde/kronolith/ [Fri Aug 22 18:55:33.866091 2014] [:error] [pid 5172] [client 192.168.60.176:57606] PHP 1. {main}() /home/jan/horde-develop/horde/services/ajax.php:0, referer: http://neo.wg.de/headhorde/kronolith/ [Fri Aug 22 18:55:33.866126 2014] [:error] [pid 5172] [client 192.168.60.176:57606] PHP 2. Horde_Core_Ajax_Application->send() /home/jan/horde-develop/horde/services/ajax.php:70, referer: http://neo.wg.de/headhorde/kronolith/ [Fri Aug 22 18:55:33.866160 2014] [:error] [pid 5172] [client 192.168.60.176:57606] PHP 3. Horde_Core_Ajax_Response->sendAndExit() /home/jan/horde-develop/framework/Core/lib/Horde/Core/Ajax/Application.php:241, referer: http://neo.wg.de/headhorde/kronolith/ [Fri Aug 22 18:55:33.866193 2014] [:error] [pid 5172] [client 192.168.60.176:57606] PHP 4. Horde_SessionHandler->__destruct() /home/jan/horde-develop/framework/SessionHandler/lib/Horde/SessionHandler.php:0, referer: http://neo.wg.de/headhorde/kronolith/ [Fri Aug 22 18:55:33.866260 2014] [:error] [pid 5172] [client 192.168.60.176:57606] PHP 5. session_write_close() /home/jan/horde-develop/framework/SessionHandler/lib/Horde/SessionHandler.php:115, referer: http://neo.wg.de/headhorde/kronolith/ [Fri Aug 22 18:55:33.866293 2014] [:error] [pid 5172] [client 192.168.60.176:57606] PHP 6. Horde_SessionHandler->close() /home/jan/horde-develop/framework/SessionHandler/lib/Horde/SessionHandler.php:115, referer: http://neo.wg.de/headhorde/kronolith/ [Fri Aug 22 18:55:33.866325 2014] [:error] [pid 5172] [client 192.168.60.176:57606] PHP 7. Horde_SessionHandler_Storage_Sql->close() /home/jan/horde-develop/framework/SessionHandler/lib/Horde/SessionHandler.php:150, referer: http://neo.wg.de/headhorde/kronolith/ [Fri Aug 22 18:55:33.866358 2014] [:error] [pid 5172] [client 192.168.60.176:57606] PHP 8. Horde_Db_Adapter_Pdo_Base->commitDbTransaction() /home/jan/horde-develop/framework/SessionHandler/lib/Horde/SessionHandler/Storage/Sql.php:77, referer: http://neo.wg.de/headhorde/kronolith/

I made some changes in the DB factory that fixed an issue wi

Sun, 24 Aug 2014 23:36:54 +0000

I made some changes in the DB factory that fixed an issue with infinite looping if SQL was being used as a cache driver. But I don't see anything wrong with that code that would cause this issue directly.

Is there anything else I can/need to do to resolve this? Do

Mon, 25 Aug 2014 09:13:54 +0000

Is there anything else I can/need to do to resolve this? Do I need to post another backtrace like Jan already did? I see this happening with the SQL sessionhandler.

>> Having said that, I probably already found the culprit. I

Mon, 25 Aug 2014 09:16:08 +0000

>> Having said that, I probably already found the culprit. I use the >> 'SQL' session handler. When I switch to 'Filesystem storage', there >> is no problem. Switching back to 'SQL' and the problem is back. > > Confirmed, though I only see this in Kronolith's Ajax requests. This could be due to the fact that I'm using SQL for IMAP caching, which might trigger similar behavior as the SQL sessionhandler.

> Is there anything else I can/need to do to resolve this? D

Mon, 25 Aug 2014 19:04:15 +0000

> Is there anything else I can/need to do to resolve this? Do I need to > post another backtrace like Jan already did? I see this happening > with the SQL sessionhandler. I have no idea, but I'm not really the SQL guy. I would tend to agree with Jan - this was a preexisting bug that just recently manifested itself because of the way things are setup/torn down. Changing factories triggered the bug, but didn't cause it. From the SQL driver: /* Close any open transactions. */ if ($this->_db->transactionStarted()) { try { $this->_db->commitDbTransaction(); } catch (Horde_Db_Exception $e) { return false; } } Seems like a issue in the DB adapter. Because if $this->_db->transactionStarted() is true, that assumes that there is an active connection.

I don't know if this may help. In previous version 5.2.0

Thu, 28 Aug 2014 07:13:35 +0000

I don't know if this may help. In previous version 5.2.0 If got the same error but in that moment the problem was caused by a problem accessing the horde log file (Was changed to file instead syslog and after upgrade the apache user did not have write access to the file). Solving the problem the SQL error stopped. Strange?

I've been debugging the problem and determined that the prob

Fri, 29 Aug 2014 10:27:26 +0000

I've been debugging the problem and determined that the problem is in the changes changes in the file Horde/Core/Factory/Db.php If I revert only this file to the one of the previous version of Horde_Core all seems to work fine again. Looking at the changes I think I've found that the problem is caused doing the call to $ob->setCache after $ob->setLogger I've changed the code to look more like the old version and calling $ob->setCache prior to $ob->setLogger and works fine If you need the changed code let me know

Changes have been made in Git (master): commit 0688cd531929

Mon, 01 Sep 2014 19:54:53 +0000

Changes have been made in Git (master): commit 0688cd531929ffab5a0f44dd2a6e3f7efd7c2abb Author: Michael M Slusarz Date: Mon Sep 1 13:54:18 2014 -0600 Bug #13463: Possible fix framework/Core/lib/Horde/Core/Factory/Db.php | 10 ++++++---- 1 files changed, 6 insertions(+), 4 deletions(-) http://github.com/horde/horde/commit/0688cd531929ffab5a0f44dd2a6e3f7efd7c2abb

Does this patch fix? I don't have time right now to track

Mon, 01 Sep 2014 19:56:35 +0000

Does this patch fix? I don't have time right now to track down why this fixes so this is not fixing the underlying problem - only the initiation of the problem.

> Does this patch fix? Yes. I replaced the version from P

Tue, 02 Sep 2014 05:50:59 +0000

> Does this patch fix? Yes. I replaced the version from PEAR of Horde/Core/Factory/Db.php by the one from Git (there are more changes in it than just this) and after that, the SQL session handler can be used again.

Sorry, doesn't work for me, I've replace the Db.php file an

Tue, 02 Sep 2014 14:41:41 +0000

Sorry, doesn't work for me, I've replace the Db.php file and got the same error. The attached file dows work but this is only a test and don't know if is a valid solution for the other bug.

> Sorry, doesn't work for me, I've replace the Db.php file

Wed, 03 Sep 2014 08:25:19 +0000

> Sorry, doesn't work for me, I've replace the Db.php file and got the > same error. If that is true, then this is some kind of very obscure bug that involves execution order. (Do you use a split read/write setup? Do you use DB for logging?)

Yes I have split read/write since we have two servers qith t

Wed, 03 Sep 2014 08:58:06 +0000

Yes I have split read/write since we have two servers qith the same URL I use SQL SessionHandler and no I don´t have SQL Logging, now I'm using SYSLOG Regards

Changes have been made in Git (master): commit 664063d11ea9

Wed, 03 Sep 2014 23:28:48 +0000

Changes have been made in Git (master): commit 664063d11ea9d30bd9e9f66d13203bb4a521b7ce Author: Michael M Slusarz Date: Wed Sep 3 17:28:12 2014 -0600 Don't attach logger to base split read object Bug #13463 framework/Core/lib/Horde/Core/Factory/Db.php | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) http://github.com/horde/horde/commit/664063d11ea9d30bd9e9f66d13203bb4a521b7ce

Maybe this helps. FWIW - from a performance perspective,

Wed, 03 Sep 2014 23:29:49 +0000

Maybe this helps. FWIW - from a performance perspective, nobody should be using SQL as a session handler.

No, sorry. With de new Db.php the error is the same. I th

Thu, 04 Sep 2014 09:27:08 +0000

No, sorry. With de new Db.php the error is the same. I think that the problem is caused by calling setLogger without a prior SetCache when you pass $cache as false. Without knowing if this is not the intended behaviour or if this my break some other thing with this change: if ($cache && !isset($config['logger'])) { $ob->setLogger($this->_injector->getInstance('Horde_Log_Logger')); } the error goes away, I know that in this situation the logger instance is not atached to the individual read and write db objects I know that the performance is worse with SQL Session Handler but we have Horde installed in two diffent systems and if we use Standard PHP Session files we have locking problems, and we haven't been able of getting the "Distribute Cache Table" option to work

> I know that the performance is worse with SQL Session Hand

Fri, 05 Sep 2014 11:08:16 +0000

> I know that the performance is worse with SQL Session Handler but we > have Horde installed in two diffent systems and if we use Standard > PHP Session files we have locking problems, and we haven't been able > of getting the "Distribute Cache Table" option to work. If you manage to setup a Distributed Hashtable and use it for session storage, you'll probably find that in some cases it will perform worse than the SQL sessionhandler. If you update the calender view in Kronolith for instance, in Firefox up to six listEvent processes will run concurrently. But since they will all try to lock the session at the same time and have identical backoff intervals, it will require at least 500 ms before they finish. The SQL sessionhandler will run these processes in parallel, without having to wait for a lock. In my system, the SQL session handler is noticeably faster. See also http://bugs.horde.org/ticket/13231

> If you manage to setup a Distributed Hashtable and use it

Fri, 05 Sep 2014 11:36:11 +0000

> If you manage to setup a Distributed Hashtable and use it for session > storage, you'll probably find that in some cases it will perform > worse than the SQL sessionhandler. If you update the calender view in > Kronolith for instance, in Firefox up to six listEvent processes will > run concurrently. But since they will all try to lock the session at > the same time and have identical backoff intervals, it will require > at least 500 ms before they finish. The SQL sessionhandler will run > these processes in parallel, without having to wait for a lock. In my > system, the SQL session handler is noticeably faster. OK, tanks for de advise, we are reasonably satisfied with de SQL Session Handler, even if the native PHP Session Handler was faster for an independent system

Marking as resolved as nobody has complained since the commi

Thu, 08 Jan 2015 03:24:35 +0000

Marking as resolved as nobody has complained since the commit was added.

Hello, the problem still exists, as you can see in my commen

Thu, 08 Jan 2015 15:58:01 +0000

Hello, the problem still exists, as you can see in my comment #20 I continue having problems after the commit.