6.0.0-git
2019-06-16

[#13463] Horde_Core-2.13.1 breaks SQL database access
Summary Horde_Core-2.13.1 breaks SQL database access
Queue Horde Framework Packages
Queue Version Git master
Type Bug
State Resolved
Priority 1. Low
Owners slusarz (at) horde (dot) org
Requester arjen+horde (at) de-korte (dot) org
Created 2014-08-22 (1759 days ago)
Due
Updated 2015-01-08 (1620 days ago)
Assigned 2014-08-22 (1759 days ago)
Resolved 2015-01-08 (1620 days ago)
Milestone
Patch No

History
2015-01-08 15:58:01 jcblanco (at) fi (dot) upm (dot) es Comment #24 Reply to this comment
Hello, the problem still exists, as you can see in my comment #20
continue having problems after the commit.
2015-01-08 03:24:35 Michael Slusarz Comment #23
Assigned to Michael Slusarz
State ⇒ Resolved
Reply to this comment
Marking as resolved as nobody has complained since the commit was added.
2014-09-05 11:36:11 jcblanco (at) fi (dot) upm (dot) es Comment #22 Reply to this comment

[Show Quoted Text - 10 lines]
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

2014-09-05 11:08:16 arjen+horde (at) de-korte (dot) org Comment #21 Reply to this comment
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
2014-09-04 09:27:08 jcblanco (at) fi (dot) upm (dot) es Comment #20 Reply to this comment
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
2014-09-03 23:29:49 Michael Slusarz Comment #19
Priority ⇒ 1. Low
Reply to this comment
Maybe this helps.

FWIW - from a performance perspective, nobody should be using SQL as a 
session handler.
2014-09-03 23:28:48 Git Commit Comment #18 Reply to this comment
Changes have been made in Git (master):

commit 664063d11ea9d30bd9e9f66d13203bb4a521b7ce
Author: Michael M Slusarz <slusarz@horde.org>
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
2014-09-03 08:58:06 jcblanco (at) fi (dot) upm (dot) es Comment #17 Reply to this comment
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
2014-09-03 08:25:19 Michael Slusarz Comment #16 Reply to this comment
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?)
2014-09-02 14:41:41 jcblanco (at) fi (dot) upm (dot) es Comment #15
New Attachment: Db.php Download
Reply to this comment
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.
2014-09-02 05:50:59 arjen+horde (at) de-korte (dot) org Comment #14 Reply to this comment
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.
2014-09-01 19:56:35 Michael Slusarz Comment #13 Reply to this comment
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.
2014-09-01 19:54:53 Git Commit Comment #12 Reply to this comment
Changes have been made in Git (master):

commit 0688cd531929ffab5a0f44dd2a6e3f7efd7c2abb
Author: Michael M Slusarz <slusarz@horde.org>
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
2014-08-29 10:27:26 jcblanco (at) fi (dot) upm (dot) es Comment #11 Reply to this comment
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
2014-08-28 07:13:35 jcblanco (at) fi (dot) upm (dot) es Comment #10 Reply to this comment
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?
2014-08-25 19:04:15 Michael Slusarz Comment #9 Reply to this comment
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.

2014-08-25 09:16:08 arjen+horde (at) de-korte (dot) org Comment #8 Reply to this comment
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.
2014-08-25 09:13:54 arjen+horde (at) de-korte (dot) org Comment #7 Reply to this comment
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.
2014-08-24 23:36:54 Michael Slusarz Comment #6 Reply to this comment
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.
2014-08-22 16:57:31 Jan Schneider Comment #5 Reply to this comment
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/

2014-08-22 16:55:31 Jan Schneider Comment #4 Reply to this comment
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.
2014-08-22 15:35:07 arjen+horde (at) de-korte (dot) org Comment #3 Reply to this comment
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.


2014-08-22 10:25:18 Jan Schneider Comment #2
State ⇒ Feedback
Reply to this comment
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.
2014-08-22 06:58:06 arjen+horde (at) de-korte (dot) org Comment #1
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 2. Medium
Summary ⇒ Horde_Core-2.13.1 breaks SQL database access
Queue ⇒ Horde Framework Packages
Milestone ⇒
Patch ⇒ No
Reply to this comment
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).

Saved Queries