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.

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.

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?

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...

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.

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.

Okay, it's all merged.

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.

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.

If we're confident in the changes, sure. With no one testing them, I 
wasn't going to put them into a stable release.

Shouldn't this be merged to 3.0.5?

No feedback, so I have to assume it works now.

So, hello? Anyone going to test this?

I should mention that this is using just the PHP files-based sessions 
too.  Might be a totally separate issue :/  Too late to diagnose..

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"]

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.

potentially related writeup: 
http://www.issociate.de/board/post/184369/warning_&_question_about_mysql_sessions_&_concurrency.html

Upping the priority since this seems to be the root cause of bug 1801 
and bug 1819.

We already do that.

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.

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.

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.