See http://trac.roundcube.net/trac.cgi/ticket/1484339#comment:4
I know this ticket has been spammed recently, so I just wanted to make sure that illegitimate posts don't prevent it from getting the attention it deserves. I think this is a really big problem. There's no way a web client looking at a mailbox should cause the server to bog down so completely.
Hey David,
On 6/24/07, David Abrahams dave@boost-consulting.com wrote:
See http://trac.roundcube.net/trac.cgi/ticket/1484339#comment:4
since it's been opened 2 month ago - can you test again against rc0.1 ?
For sure I'll look into the quoting issues etc. which are outlined on the ticket - in regard to using what is advertised on login. That is a great idea of course, but I am not sure if sorting is actually part of the standard, I tried to find appropriate RFCs but were not too successful. If it is not part of it I personally wouldn't want to support something like that.
On a sidenote - I've heard many complaints about Dovecot and large mailboxes. Which is why I personally use Courier.
Regards, Till
till wrote:
great idea of course, but I am not sure if sorting is actually part of the standard, I tried to find appropriate RFCs but were not too successful. If it is not part of it I personally wouldn't want to support something like that.
It's a draft extension: http://tools.ietf.org/html/draft-ietf-imapext-sort-19
The Internet mail consortium keeps a list of IMAP extensions at: http://www.imc.org/ietf-imapext/
Bob
on Sun Jun 24 2007, till <klimpong-AT-gmail.com> wrote:
Hey David,
On 6/24/07, David Abrahams dave@boost-consulting.com wrote:
See http://trac.roundcube.net/trac.cgi/ticket/1484339#comment:4
since it's been opened 2 month ago - can you test again against rc0.1 ?
Sorry, do you mean rc1.1
http://downloads.sourceforge.net/roundcubemail/roundcubemail-0.1-rc1.1.tar.g...
or something else?
For sure I'll look into the quoting issues etc. which are outlined on the ticket - in regard to using what is advertised on login. That is a great idea of course, but I am not sure if sorting is actually part of the standard, I tried to find appropriate RFCs but were not too successful. If it is not part of it I personally wouldn't want to support something like that.
On a sidenote - I've heard many complaints about Dovecot and large mailboxes. Which is why I personally use Courier.
I'm using Cyrus (which I hate). However, reconfiguring the whole mail system is unacceptable to me, and my mail clients other than roundcube have no problems with those huge mailboxes, so it really can't be the server's fault.
On 6/24/07, David Abrahams dave@boost-consulting.com wrote:
on Sun Jun 24 2007, till <klimpong-AT-gmail.com> wrote:
Hey David,
On 6/24/07, David Abrahams dave@boost-consulting.com wrote:
See http://trac.roundcube.net/trac.cgi/ticket/1484339#comment:4
since it's been opened 2 month ago - can you test again against rc0.1 ?
Sorry, do you mean rc1.1
http://downloads.sourceforge.net/roundcubemail/roundcubemail-0.1-rc1.1.tar.g...
or something else?
0.1-rc1.1 ;-)
Yes, that's what I mean - please give it a try. Also if you can, test against trunk.
You want, you could also test against branches/devel-vnext.
For sure I'll look into the quoting issues etc. which are outlined on the ticket - in regard to using what is advertised on login. That is a great idea of course, but I am not sure if sorting is actually part of the standard, I tried to find appropriate RFCs but were not too successful. If it is not part of it I personally wouldn't want to support something like that.
On a sidenote - I've heard many complaints about Dovecot and large mailboxes. Which is why I personally use Courier.
I'm using Cyrus (which I hate). However, reconfiguring the whole mail system is unacceptable to me, and my mail clients other than roundcube have no problems with those huge mailboxes, so it really can't be the server's fault.
I understand your frustration.
Cheers, Till
on Sun Jun 24 2007, till <klimpong-AT-gmail.com> wrote:
Sorry, do you mean rc1.1
http://downloads.sourceforge.net/roundcubemail/roundcubemail-0.1-rc1.1.tar.g...
or something else?
0.1-rc1.1 ;-)
Yes, that's what I mean - please give it a try. Also if you can, test against trunk.
yes, with both those versions, httpd starts to chew up a steadily increasing percentage of CPU (it was at 98% within 30 sec). Firefox locks up and needs to be killed. After killing firefox, httpd *very* gradually reduces its CPU load, then seems to hover around 50% for a while, then finally gives up and goes back close to zero... so I don't have to kill my server; I do have to kill FireFox.
It looks from the outside like roundcube's JavaScript is trying to ask the server some big question before it will allow the browser display to update.
David Abrahams wrote:
0.1-rc1.1 ;-)
Yes, that's what I mean - please give it a try. Also if you can, test against trunk.
yes, with both those versions, httpd starts to chew up a steadily increasing percentage of CPU (it was at 98% within 30 sec). Firefox locks up and needs to be killed. After killing firefox, httpd *very* gradually reduces its CPU load, then seems to hover around 50% for a while, then finally gives up and goes back close to zero... so I don't have to kill my server; I do have to kill FireFox.
It looks from the outside like roundcube's JavaScript is trying to ask the server some big question before it will allow the browser display to update.
It might be somewhat hard to pick out the traffic, but have you tried watching the connection with a tool such as tcpflow? It would let you monitor what exactly is being communicated back and forth while the CPU load is high and FF is locked up.
I wonder if it's held up waiting on something, or if it is actually transferring data at that point. Either way you should be able to capture the last (few?) request(s) up to the point where it fails. That may go a long way toward figuring out where the problem lies...
I also wonder if this is related to the others who are seeing high CPU usage. You might check the recent thread about "100% CPU" to see if you might also have similar symptoms.
Jim
Jim
on Fri Jul 06 2007, Jim Pingle <lists-AT-pingle.org> wrote:
David Abrahams wrote:
0.1-rc1.1 ;-)
Yes, that's what I mean - please give it a try. Also if you can, test against trunk.
yes, with both those versions, httpd starts to chew up a steadily increasing percentage of CPU (it was at 98% within 30 sec). Firefox locks up and needs to be killed. After killing firefox, httpd *very* gradually reduces its CPU load, then seems to hover around 50% for a while, then finally gives up and goes back close to zero... so I don't have to kill my server; I do have to kill FireFox.
It looks from the outside like roundcube's JavaScript is trying to ask the server some big question before it will allow the browser display to update.
It might be somewhat hard to pick out the traffic, but have you tried watching the connection with a tool such as tcpflow? It would let you monitor what exactly is being communicated back and forth while the CPU load is high and FF is locked up.
There's hardly any traffic at all during the hang.
I wonder if it's held up waiting on something, or if it is actually transferring data at that point.
Clearly the former.
Either way you should be able to capture the last (few?) request(s) up to the point where it fails. That may go a long way toward figuring out where the problem lies...
Unfortunately it's an SSL connection so I can't see what's in the data. I may have to enable an insecure connection temporarily in order to debug this.
I also wonder if this is related to the others who are seeing high CPU usage. You might check the recent thread about "100% CPU" to see if you might also have similar symptoms.
Well the symptoms are similar but I don't think our situations are similar at all. This only happens to me when viewing very large mailboxes.
On Fri, 06 Jul 2007 15:14:41 -0400, Jim Pingle lists@pingle.org wrote:
David Abrahams wrote:
0.1-rc1.1 ;-)
Yes, that's what I mean - please give it a try. Also if you can, test against trunk.
yes, with both those versions, httpd starts to chew up a steadily increasing percentage of CPU (it was at 98% within 30 sec). Firefox locks up and needs to be killed. After killing firefox, httpd *very* gradually reduces its CPU load, then seems to hover around 50% for a while, then finally gives up and goes back close to zero... so I don't have to kill my server; I do have to kill FireFox.
It looks from the outside like roundcube's JavaScript is trying to ask the server some big question before it will allow the browser display to update.
It might be somewhat hard to pick out the traffic, but have you tried watching the connection with a tool such as tcpflow? It would let you monitor what exactly is being communicated back and forth while the CPU load is high and FF is locked up.
I wonder if it's held up waiting on something, or if it is actually transferring data at that point. Either way you should be able to capture the last (few?) request(s) up to the point where it fails. That may go a long way toward figuring out where the problem lies...
I also wonder if this is related to the others who are seeing high CPU usage. You might check the recent thread about "100% CPU" to see if you might also have similar symptoms.
Hi all,
I have similar issue today! But roundcube wasn't the source of error. It was my dovecot imap server. After thunderbird stopped with an error during connecting to my imap server I get doubtfully. I take a look at the imap logs ->
dovecot: Jul 07 14:01:11 Error: imap-login: No authentication sockets found dovecot: Jul 07 14:01:11 Error: child 6373 (login) returned error 89
As workaround I restart the imap server. Now I have no errors.
Regards ks
on Fri Jul 06 2007, Jim Pingle <lists-AT-pingle.org> wrote:
David Abrahams wrote:
0.1-rc1.1 ;-)
Yes, that's what I mean - please give it a try. Also if you can, test against trunk.
yes, with both those versions, httpd starts to chew up a steadily increasing percentage of CPU (it was at 98% within 30 sec). Firefox locks up and needs to be killed. After killing firefox, httpd *very* gradually reduces its CPU load, then seems to hover around 50% for a while, then finally gives up and goes back close to zero... so I don't have to kill my server; I do have to kill FireFox.
It looks from the outside like roundcube's JavaScript is trying to ask the server some big question before it will allow the browser display to update.
It might be somewhat hard to pick out the traffic, but have you tried watching the connection with a tool such as tcpflow? It would let you monitor what exactly is being communicated back and forth while the CPU load is high and FF is locked up.
I wonder if it's held up waiting on something, or if it is actually transferring data at that point. Either way you should be able to capture the last (few?) request(s) up to the point where it fails. That may go a long way toward figuring out where the problem lies...
There's hardly any traffic during that period. Unfortunately it's a bit hard to see what's going on over an https:// connection by looking at tcpflow. :(
I also wonder if this is related to the others who are seeing high CPU usage. You might check the recent thread about "100% CPU" to see if you might also have similar symptoms.
Their symptoms (100% cpu, browser lockup) look like mine, but their circumstances seem to be mostly different. It only happens to me when viewing really large folders. I'm using Cyrus and not Dovecot. The IMAP server is on the same machine as the webserver.
David Abrahams wrote:
I wonder if it's held up waiting on something, or if it is actually transferring data at that point. Either way you should be able to capture the last (few?) request(s) up to the point where it fails. That may go a long way toward figuring out where the problem lies...
There's hardly any traffic during that period. Unfortunately it's a bit hard to see what's going on over an https:// connection by looking at tcpflow. :(
I wonder if SSL might be part of the equation? Have you had a chance to try this on a plain http connection? I tried mine with SSL turned on and had no problems, but it's still something to try...
I also wonder if this is related to the others who are seeing high CPU usage. You might check the recent thread about "100% CPU" to see if you might also have similar symptoms.
Their symptoms (100% cpu, browser lockup) look like mine, but their circumstances seem to be mostly different. It only happens to me when viewing really large folders. I'm using Cyrus and not Dovecot. The IMAP server is on the same machine as the webserver.
Ah, ok. How large? I tried with folders of between 1500 and 3000 messages, and the highest I could get apache to go with SSL was 72% for a second or two, and the folders still loaded, albeit a little slow.
Jim
on Sat Jul 07 2007, Jim Pingle <lists-AT-pingle.org> wrote:
David Abrahams wrote:
I wonder if it's held up waiting on something, or if it is actually transferring data at that point. Either way you should be able to capture the last (few?) request(s) up to the point where it fails. That may go a long way toward figuring out where the problem lies...
There's hardly any traffic during that period. Unfortunately it's a bit hard to see what's going on over an https:// connection by looking at tcpflow. :(
I wonder if SSL might be part of the equation? Have you had a chance to try this on a plain http connection? I tried mine with SSL turned on and had no problems, but it's still something to try...
I also wonder if this is related to the others who are seeing high CPU usage. You might check the recent thread about "100% CPU" to see if you might also have similar symptoms.
Their symptoms (100% cpu, browser lockup) look like mine, but their circumstances seem to be mostly different. It only happens to me when viewing really large folders. I'm using Cyrus and not Dovecot. The IMAP server is on the same machine as the webserver.
Ah, ok. How large? I tried with folders of between 1500 and 3000 messages, and the highest I could get apache to go with SSL was 72% for a second or two, and the folders still loaded, albeit a little slow.
Probably more than 10K messages. If there's a big-O problem in one of the JavaScript algorithms, a couple of seconds could turn into a "hang" when you increase the dataset by an order of magnitude.
On 7/7/07, David Abrahams dave@boost-consulting.com wrote:
(...) Probably more than 10K messages. If there's a big-O problem in one of the JavaScript algorithms, a couple of seconds could turn into a "hang" when you increase the dataset by an order of magnitude.
Can you exactly point out the problem/method/function which's responsible?
Thanks again!
Till
on Sun Jul 08 2007, till <klimpong-AT-gmail.com> wrote:
On 7/7/07, David Abrahams dave@boost-consulting.com wrote:
(...) Probably more than 10K messages. If there's a big-O problem in one of the JavaScript algorithms, a couple of seconds could turn into a "hang" when you increase the dataset by an order of magnitude.
Can you exactly point out the problem/method/function which's responsible?
Not yet. Even though I have Firebug, I don't know how to break into running JavaScript and find out what's happening. If you can tell me, I'll be happy to try.
On 7/7/07, David Abrahams dave@boost-consulting.com wrote:
on Fri Jul 06 2007, Jim Pingle <lists-AT-pingle.org> wrote:
David Abrahams wrote:
0.1-rc1.1 ;-)
Yes, that's what I mean - please give it a try. Also if you can, test against trunk.
yes, with both those versions, httpd starts to chew up a steadily increasing percentage of CPU (it was at 98% within 30 sec). Firefox locks up and needs to be killed. After killing firefox, httpd *very* gradually reduces its CPU load, then seems to hover around 50% for a while, then finally gives up and goes back close to zero... so I don't have to kill my server; I do have to kill FireFox.
It looks from the outside like roundcube's JavaScript is trying to ask the server some big question before it will allow the browser display to update.
It might be somewhat hard to pick out the traffic, but have you tried watching the connection with a tool such as tcpflow? It would let you monitor what exactly is being communicated back and forth while the CPU load is high and FF is locked up.
I wonder if it's held up waiting on something, or if it is actually transferring data at that point. Either way you should be able to capture the last (few?) request(s) up to the point where it fails. That may go a long way toward figuring out where the problem lies...
There's hardly any traffic during that period. Unfortunately it's a bit hard to see what's going on over an https:// connection by looking at tcpflow. :(
Of course you would need to turn off SSL. :-) So maybe set up a second RC version (from SVN) and see if it behaves the same.
I've seen some issues too when you have plenty of folders, large mailboxes - but I never ever had to restart Firefox. Sometimes there is a little "hang" when the folders are scanned for unread but aside from that, nothing major.
Till
on Sun Jul 08 2007, till <klimpong-AT-gmail.com> wrote:
There's hardly any traffic during that period. Unfortunately it's a bit hard to see what's going on over an https:// connection by looking at tcpflow. :(
Of course you would need to turn off SSL. :-) So maybe set up a second RC version (from SVN) and see if it behaves the same.
I've seen some issues too when you have plenty of folders, large mailboxes - but I never ever had to restart Firefox. Sometimes there is a little "hang" when the folders are scanned for unread but aside from that, nothing major.
OK, I get a "little hang" of over a minute. I consider that major. And then what roundcube shows me looks as though there are no messages in the floder.
The tcpflow results are enclosed. If you do ls --full-time on the resulting directory you can see the exact times when the packets were sent/received.
If roundcube is asking the server to sort the mailbox before RC will display anything, maybe that's the problem. You might consider sorting messages by message-ID initially. message-IDs tend to increase monotonically with time of receipt.
on Sun Jul 08 2007, David Abrahams <dave-AT-boost-consulting.com> wrote:
on Sun Jul 08 2007, till <klimpong-AT-gmail.com> wrote:
There's hardly any traffic during that period. Unfortunately it's a bit hard to see what's going on over an https:// connection by looking at tcpflow. :(
Of course you would need to turn off SSL. :-) So maybe set up a second RC version (from SVN) and see if it behaves the same.
I've seen some issues too when you have plenty of folders, large mailboxes - but I never ever had to restart Firefox. Sometimes there is a little "hang" when the folders are scanned for unread but aside from that, nothing major.
OK, I get a "little hang" of over a minute. I consider that major. And then what roundcube shows me looks as though there are no messages in the floder.
The tcpflow results are enclosed. If you do ls --full-time on the resulting directory you can see the exact times when the packets were sent/received.
Not to rush you, but is anyone looking at these results? I went to considerable trouble to produce them, so a simple acknowledgement would make me feel better about having done it :)
Thanks,
On 7/11/07, David Abrahams dave@boost-consulting.com wrote:
on Sun Jul 08 2007, David Abrahams <dave-AT-boost-consulting.com> wrote:
on Sun Jul 08 2007, till <klimpong-AT-gmail.com> wrote:
There's hardly any traffic during that period. Unfortunately it's a bit hard to see what's going on over an https:// connection by looking at tcpflow. :(
Of course you would need to turn off SSL. :-) So maybe set up a second RC version (from SVN) and see if it behaves the same.
I've seen some issues too when you have plenty of folders, large mailboxes - but I never ever had to restart Firefox. Sometimes there is a little "hang" when the folders are scanned for unread but aside from that, nothing major.
OK, I get a "little hang" of over a minute. I consider that major. And then what roundcube shows me looks as though there are no messages in the floder.
The tcpflow results are enclosed. If you do ls --full-time on the resulting directory you can see the exact times when the packets were sent/received.
Not to rush you, but is anyone looking at these results? I went to considerable trouble to produce them, so a simple acknowledgement would make me feel better about having done it :)
Pong!
I can't provide you with an ETA on when I will look. Probably on the weekend. Maybe others will look earlier - or later.
Cheers, Till
on Wed Jul 11 2007, till <klimpong-AT-gmail.com> wrote:
Not to rush you, but is anyone looking at these results? I went to considerable trouble to produce them, so a simple acknowledgement would make me feel better about having done it :)
Pong!
I can't provide you with an ETA on when I will look. Probably on the weekend. Maybe others will look earlier - or later.
Thanks for the ACK
-
B. Johannessen -
David Abrahams -
Jim Pingle -
mailist＠sokol.dynalias.net -
till