For reasons touched upon here:

http://lists.horde.org/archives/dev/Week-of-Mon-20050509/017803.html

The read-only patches mentioned by Chuck should not be applied as they 
do not fix this problem and create additional problems.

Hey guys, I just wanted to add that I'm seeing the same thing mostly 
with "Requested message not found" on an older cvs-head installation 
(maybe a month old, could be little more). I've been following head 
lazily and have seen this the first time about a week ago. The 
original report is great, and I too noticed all the same things, like 
that Cyrus is fine and it seems that when I click on the message to 
read it, the request never even goes to cyrus. Anyway, you know all 
this and I just wanted to add that I'm using PostgreSQL for sessions, 
with a "Use PEAR's DB abstraction layer" driver, if that helps. I have 
a new cvs-head server that I can use for testing, I've tested the 
patch from day or two ago (via cvs up) and it didn't make much 
difference, I still see errors, usually when I log in and click on any 
message (new or old). As reported, using file-based session handling 
makes it work better. Thats it, if I can help test this I will, thanks 
for making Horde way cool. :)

Thanks - will install on a test install on Monday and use that 
throughout the day.



Thanks for taking the time to update this ticket too, since I don't 
have an easy way to track the parent.



I think having a concurrent-session safe mechanism in place is still 
the best solution, but I think this workaround should resolve the 
issue for the bulk of normal Horde users.  I'm probably being 
simplistic but the only situation I could think of that would still be 
problematic  was having multiple tabs or windows open at the same time 
(which ironically was mentioned early on for this ticket, but it 
didn't click that having two frames was essentially the same kind of 
situation :)

Does not fix the underlying issue, but may help:



http://lists.horde.org/archives/cvs/Week-of-Mon-20050502/044320.html



Try the two patches (to sidebar.php and base.php) - they make the 
sidebar use readonly sessions.

I think there's enough evidence now to mark this as a duplicate of bug 1580.

Yes - message indices (as well as the current mailbox, search results, 
etc) are all stored in the session.  This is the whole purpose of 
using session storage - namely, so you don't have to tote this (vast) 
amount of information around via either form data or insanely long URLs.

Been reading through about 300 log messages in one folder - no 
problems since switching to file-based sessions on a test server.  I 
was asking simply to confirm that message indexes are stored as a 
session variable.  If they are not, them I'm going on a wild-goose 
chase.  Reading through those messages without error doesn't prove 
that MySQL-based sessions are the cause of the problem, because it 
could be some other lurking influence causes the index problem.  But 
there's enough circumstantial evidence to leave me to believe we have 
a MySQL race condition, if using that type of session to store session 
info.



My comment earlier on this ticket about reloading the left frame, 
which caused the "Requested message not found" error to go away in my 
INBOX I think contributes to my believe that this boils down to a 
MySQL-based session race issue.



A discussion that I think talks about this issue, in general, is at:



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



Since sites that use multiple web servers for load-balancing and 
failover would likely used a shared session mechanism, such as 
database-based, I think this is important to fix (of course, assuming 
it is a race condition - I could be quite wrong about that).

If you can reproduce this behaviour, why don't you try it out?

Is there any chance that problems with indexes could trace back to the 
same issue that I think exists in bug 1801, namely that things work 
great with PHP file-based sessions but there are quirks when using 
MySQL-based sessions?  I can't say when I started noticing this 
behavior but if indexes are part of session data, I'm wondering if 
this ticket and 1801 aren't really the same issue..

I moved a test installation to a new server, which is running RHEL 4 
(PHP 4.3.9 and c-client 2002e; previous was PHP 4.3.2 and c-client 
2002d).



The problems follow.  Here's another case that I can reproduce on a 
reliable basis:



Go into a folder with a couple hundred messages of mail.  Start 
reading mail and deleting it as you go onto the next message.  At some 
point, the overall message count doesn't decrement by one, and you 
jump up on place in the folder.



Specific example:



Reading administrative logs in admin folder (260 unread messages, 1 
read message)



In message list screen - reads 1-100 of 260 (and message 1 is read, 
all others unread).

Begin by reading message 2.  Delete it,  Displays "2 of 259".  You're 
now on the original message 3, which is now message 2, Delete it.   
Display "2 of 258".  Repeat this for awhile.  At some random (or not, 
I'm sure there's  pattern but I can't put my finger on it), the "2 of 
X" jumps to "3 of Y", where Y is the same as the previous X (i.e if 
you saw 2 of 204, deleted a message, the next message said 3 of 204).   
Interestingly enough, immediately after this happens, if you go back 
to the message list in the folder, you see the total # of messages to 
be only 203, which is what it should have been.



So I'm left scratching my head - bug in Cyrus, bug in c-client, bug in 
Horde/IMP?  I was doing vardumps of the imp_mailbox object, but that 
gets painful to scroll through if you have thousands of messages in a 
folder.



No IMAP proxy in place.  There are more recent c-client releases 
(2004a-d) releases - I"m curious what versions the developers may be 
using, as well as what Cyrus IMAP version you are using Jan, since 
you've never had this problem.  Since I'm running this on a test 
server, I'm inclined to run PHP and c-client up to the latest 
revisions, to see if I can elminate or finger them as the cause of 
this issue.  Can't really do anything about the mail server at this 
point.

Some more wackiness this morning:



I selected a message in my INBOX, for deleting.  I clicked on the 
Delete link (/imp/mailbox.php?mailbox=INBOX) and instead of deleting 
the message and returning me to my INBOX, I get dropped into my Trash 
folder, which is the last folder I had used before my INBOX.



I've pretty much ruled out the mail server as the problem, since 
requests to IMP that generated a "Requested message not found" aren't 
even generating an IMAP connection.  So, as you move up the stack, the 
source of the problem could be with PHP, with the version of c-client 
that PHP is compiled with, with Horde, or with IMP.  I can get 
telemetry logs from Cyrus, as well as packet captures to the mail 
server.  But I need some help on how to extract useful debug 
information from IMP, as it relates to the internal states of folder 
and message indices (or just tracing IMAP calls in IMP in general).

No. We use IMAP UIDs, that are unique in one folder and don't change 
if another message is added to the mailbox.

How's this for a possible explanation:



I have the refresh time set to one minute for the left frame and the 
IMP refresh time set to five minutes.  I experienced the "Requested 
message not found" error about two minutes ago, received another 
message, couldn't read that, left clicked and force reloaded the left 
menu frame and could then read the messages.



So could that be the root cause of this?  A new message arrives, or 
the state of the INBOX or folder changes.  The internal IMP indexes 
get updated by the refresh of the left menu frame and after a short 
while, the main IMP screen indexes would come into sync with that.     
But any access attempts in the meantime, without a refresh of the IMP 
screen, will cause the "Requested message not found" error.  Or if the 
folder indexes are changed, you'd be dropped into the wrong folder 
periodically.  Makes sense?  Or a wild stab in the dark?



Kevin

I'm only using one browser tab/window, as I noted the same issues you 
did when using multiple tabs/windows.  I'm at a loss on how to get 
more debugging info out of IMP - turrning debug all the way up doesn't 
generate any IMAP connection logs, so I'm stuck knowing there is a 
problem somewhere on the webserver side but thats it.  The message 
index link numbers are right - /imp/message.php?index=61590 does 
indeed correctly correspond to message #61590 in my IMAP INBOX.   
Subject, sender, date are all correct but clicking on that link 
generates the error message...



My c-client is version 2002d but thats not easily upgradeable at this point.

Just for the records: I have never seen this happening on Cyrus that I 
am using as the only mail server for years now in several versions. 
This only happens if I accidentally switch to a different folder in a 
second tab/browser window.

Web server - latest version of Tier 1 Horde components (Horde, IMP, 
Turba, Ingo, Mnemo, Nag)

Red Hat Enterprise Linux 3 with latest errata



Mail server - Cyrus IMAP 2.1.18, using IMAP with TLS (although problem 
occurs with plaintext as well)



After using IMP for awhile, message indexes start to behave erraticly. 
  There are two types of problems:



1)  "Requested message not found" when clicking on a message

2)  Clicking on a folder or a link to a previous set of messages takes 
you to the wrong folder



Situation #1 seems to be exacerbated when you are reading messages and 
when new mail arrives, although it is not limited to this situation.   
A fairly reproducible situation (although not always) is to do the 
following:



1) Login to Horde/IMP (we are using LDAP authentication, and our IMAP 
server uses saslauthd with passthrough to the same LDAP directory 
server)

2)  Read a message in your INBOX

3)  Do a search for messages that returns a few pages of results.

4)  Return to the INBOX and choose a message

5)  "Requested message not found" is returned and you're dropped back 
into the search results page, instead of the INBOX page.



Today, I'm not seeing the "Requested message not found" message as 
much but I am getting dropped into the wrong folder when switching 
between folders, on a somewhat frequent basis.



While POP access is available to our mail server, there is no POP 
activity on my account.



I have done packet captures for non-TLS IMAP connections as well.   
When the "Requested message not found" message is kicked up by IMP, 
there is zero IMAP connection traffic, so its not as if the IMAP 
server is returning an error.



Perhaps totally unrelated but worth noting is that the occurrence of 
the wrong folder being returned is worsened when using an IMAP proxy 
running on the web server.  I am not currently using that setup in 
production, for that reason, but I can do tests on a test site if 
needed.



I am using Thread mode, but I see the "Requested message not found" 
error in other sorting modes as well.