6.0.0-git
2021-01-18

[#1580] Horde SessionHandler drivers do not serialize session access
Summary Horde SessionHandler drivers do not serialize session access
Queue Horde Framework Packages
Type Bug
State Resolved
Priority 3. High
Owners Horde Developers (at)
Requester windhamg (at) email (dot) arizona (dot) edu
Created 2005-03-18 (5785 days ago)
Due
Updated 2005-07-21 (5660 days ago)
Assigned 2005-06-23 (5688 days ago)
Resolved 2005-06-26 (5685 days ago)
Milestone
Patch No

History
2005-07-21 21:34:03 kevin_myer (at) iu13 (dot) org Comment #22 Reply to this comment
I just got a "Requested message not found" error, using the native 
(i.e. non-PEAR DB) MySQL session driver.  Left sidebar had updated 
with new message count in a folder, click the folder, mailbox view 
shows proper list of messages, with one unread message.  Click on the 
message, "Requested message not found".



MySQL 4.1.X, InnoDB tables.  Horde install is a fresh HEAD checkout, 
I'm the only user on this install and hitting the new database server.
2005-07-19 16:18:23 liamr (at) umich (dot) edu Comment #21 Reply to this comment
We tried switching to MyISAM to get around the 2GB per process memory 
limit were were encountering with InnoDB, but the application became 
unusably slow.   We had hundreds of DB connections blocked as MyISAM 
only does table level locking.



We've pretty much decided that MyISAM is not a suitable table type for 
large installations.
2005-07-12 17:06:43 kevin_myer (at) iu13 (dot) org Comment #20 Reply to this comment
And are you using one of the db-specific handlers, instead of the
PEAR ("sql") one? DB doesn't provide reliable transaction support
that we can use in a db-neutral way.
MySQL, however I've realized its moot anyway, because I'm not running
against a transacation-aware table type.  Time to fast track that
MySQL server upgrade...
I should qualify that and say that unless MySQL does something to 
create pseudo-transactions, we're NTST, because we are using MyISAM 
tables.  But per Marko's response to Liam's query about table types, 
it appears Marko is running with MyISAM tables with lots of concurrent 
sessions and no problems?
2005-07-12 16:58:35 kevin_myer (at) iu13 (dot) org Comment #19 Reply to this comment
And are you using one of the db-specific handlers, instead of the
PEAR ("sql") one? DB doesn't provide reliable transaction support
that we can use in a db-neutral way.
MySQL, however I've realized its moot anyway, because I'm not running 
against a transacation-aware table type.  Time to fast track that 
MySQL server upgrade...
2005-07-12 16:09:20 Chuck Hagenbuch Comment #18 Reply to this comment
And are you using one of the db-specific handlers, instead of the PEAR 
("sql") one? DB doesn't provide reliable transaction support that we 
can use in a db-neutral way.
2005-07-12 16:05:04 kevin_myer (at) iu13 (dot) org Comment #17 Reply to this comment
I'm starting to get bug report submissions about "Requested message 
not found", following the 3.0.5-RC1 upgrade this morning...  More 
details if I can track them down.
2005-06-26 04:28:53 Chuck Hagenbuch Comment #16
State ⇒ Resolved
Reply to this comment
Okay, it's all merged.
2005-06-24 10:57:26 kevin_myer (at) iu13 (dot) org Comment #15 Reply to this comment
It would be helpful if it was in a RC.  I'll be glad to run that in an 
early production environment but its not easy to put HEAD code through 
heavy testing when your production environment is FRAMEWORK_3.



Also, as an aside, when RC's drop, it would be helpful to have a patch 
drop along with them, so that when an official point release comes 
out, the RC patch(s) can be reversed and the official point release 
easily installed.  Or in the case of a meltdown, it would be easier to 
revert to the previous point release.
2005-06-24 08:50:17 Jan Schneider Comment #14 Reply to this comment
Well, the current code is obviously causing problems, so it probably 
can't get worse. I guess we'll get more feedback (or none if works 
flawlessly) if the new code is in the next RC.
2005-06-23 17:37:47 Chuck Hagenbuch Comment #13 Reply to this comment
If we're confident in the changes, sure. With no one testing them, I 
wasn't going to put them into a stable release.
2005-06-23 09:02:06 Jan Schneider Comment #12
State ⇒ Feedback
Reply to this comment
Shouldn't this be merged to 3.0.5?
2005-05-30 20:52:27 Jan Schneider State ⇒ Resolved
 
2005-05-30 19:24:54 Chuck Hagenbuch Comment #11 Reply to this comment
No feedback, so I have to assume it works now.
2005-05-23 21:09:58 Chuck Hagenbuch Comment #10 Reply to this comment
So, hello? Anyone going to test this?
2005-05-18 04:31:11 kevin_myer (at) iu13 (dot) org Comment #9 Reply to this comment
I should mention that this is using just the PHP files-based sessions 
too.  Might be a totally separate issue :/  Too late to diagnose..
2005-05-18 04:26:28 kevin_myer (at) iu13 (dot) org Comment #8 Reply to this comment
I'm not able to login at all anymore on my HEAD install.  Slightly 
different setup than at work, using IMP for authentication but it 
passes me through to the imp/login.php and reprompts me for my 
password again.



Here's all that's logged:



May 18 00:14:58 HORDE [notice] [imp] 192.168.1.8  [on line 31 of 
"/htdocs/horde/imp/login.php"]
2005-05-16 20:01:53 Chuck Hagenbuch Comment #7
State ⇒ Feedback
Reply to this comment
Can the people seeing problems related to this please try the latest 
SessionHandler commits?



http://cvs.horde.org/framework/SessionHandler/SessionHandler/



(HEAD branch, download from there if you can).



I fear that the PEAR DB driver won't work, but if you can use the 
straight mysql.php one, it should.
2005-05-05 18:13:08 Chuck Hagenbuch Comment #5
Priority ⇒ 3. High
Reply to this comment
Upping the priority since this seems to be the root cause of bug 1801 
and bug 1819.
2005-03-18 14:33:50 Chuck Hagenbuch Comment #4 Reply to this comment
We already do that.
2005-03-18 09:12:27 Jan Schneider Comment #3 Reply to this comment
Given that we don't write session data in the javascript files, 
wouldn't it be sufficient to open the session in javascript.php 
read-only? It's only a workaround, but a quick one.
2005-03-18 03:31:32 Chuck Hagenbuch Comment #2
State ⇒ Assigned
Assigned to Horde DevelopersHorde Developers
Reply to this comment
Still should be solved, and still somewhat true for javascript, but no 
longer true at all for CSS, and a bunch of javascript is loaded 
directly now.
2005-03-18 03:24:58 windhamg (at) email (dot) arizona (dot) edu Comment #1
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 2. Medium
Summary ⇒ Horde SessionHandler drivers do not serialize session access
Queue ⇒ Horde Framework Packages
Reply to this comment
None of the Horde Framework SessionHandler drivers address session 
serialization.  This is problematic because many Horde application PHP 
scripts (e.g., imp/mailbox.php) generate output that includes 
Javascript code that results in multiple reconnects from the browser 
(to retrieve CSS files, Javascript code libraries, etc).  If the 
original PHP script hasn't written its session state before these 
subsequent accesses occur, the session state is corrupted, due to the 
lack of serialized access.  This can be visualized as two interleaved 
threads of execution--B starting subsequent to A, and each accessing 
the same session state (x):



   A(t0)-->session_read(x)-->session_write(x)

       B(t0+delta)-->session_read(x)-->session_write(x)



In this scenario, the PHP script represented by thread A believes that 
it has committed its session state, which it has, but which is 
subsequently overwritten by the (earlier) session state contained in 
thread B.  Therefore, the output generated by A is no longer 
consistent with the session cache--resulting in "message not found" 
errors, and other oddities.  Proper serialization of session access in 
the SessionHandler drivers would alleviate this condition.


Saved Queries