getting tons of "Connection to the Server Timed Out" alerts when using imap.



19 years ago
10 years ago


(Reporter: sspitzer, Assigned: mscott)



Windows NT

Firefox Tracking Flags

(Not tracked)


anyone else seeing this?  this is on the tip, about 11:00 pm, tuesday.
adding granrose.  this will probably turn into a blocker tomorrow morning.

Comment 2

19 years ago
at 21:49 a fix for bug 34359 was checked in. Perhaps related?

Comment 3

19 years ago
Yes, the fix for 34359 looks like the highly probably cause for this regression. 
I'll try backing it out in a minute.

Comment 4

19 years ago
The fix just made sure that timeouts are honored when the transport in 
Read/Write state. If it caused the regression - it might be cuz imap handler was 
using nsSocketTransport in unexpected way, like reaving it in the state with 
some outstanding reads in progress.

Comment 5

19 years ago
Is this correcteded for this morning's release builds?

Comment 6

19 years ago
No, ruslan is blaming the imap code, so I guess we have to debug on our end. 
Unfortunately, I can't debug because I can't launch the product.

Comment 7

19 years ago
mark smoketest then since we won't be able to use the product very much with 
this.  (I don't know about the product launching bug.)
Severity: normal → critical
Keywords: smoketest

Comment 8

19 years ago
Is this a Smoketest blocker? I'm able to launch, compose and send, read msg 
using today's build. I do see the "time out" alert sometimes but the mail is 
delivered to the recipient. 

Comment 9

19 years ago
If the error msg does not come up all the time and doesn't prevent from using, 
then no, not a smoketest blocker.  Suresh/Esther - will let you guys make the 
call on this.

Comment 10

19 years ago
sending mail only uses IMAP to put a copy of the sent message in the sent mail 
folder. Opening imap folders, getting new mail, and reading messages would do a 
lot more IMAP stuff. Unfortunately, I can't do anything about this since my 
clobber build still won't run.

Comment 11

19 years ago
It's easy to roll back the fix for timeouts - but I rather not to do it without 
a good reason as I don't see anything wrong with semantic of the socket 
transport. If there're outstanding reads/writes - it has to be able to time out. 
Otherwise if you hit a webpage which never produces any result - the browser 
would sit and wait there forever.

Comment 12

19 years ago
hey ruslan did you see these timeouts when you ran the pre-checkin tests for

If we can't get a lead on what exactly in imap is triggering on this then I
think we need to back out the changes that introduced the regression until we
can figure out what in imap (or in the netwerk socket) needs to change...IMHO.

I'm starting a new build right now and will report back when it's ready to go
since david b. is having trouble with his build.
my win32 rebuild is about 30 minutes away from being done.  I'll help debug / 
resolve this.

Comment 14

19 years ago
Technically we can woraround this in the future by introducing different timeout 
setters (for connect/read/write) on the socket, so each protocol can decide 
whether to use them or not. But it's still be nice to find out what exactly is 
happening in case of imap.

Comment 15

19 years ago
agreed, we should find out what's going on with imap.


19 years ago
Severity: critical → blocker

Comment 16

19 years ago
marking blocker so it shows up on the radar.

Comment 17

19 years ago
Is anybody looking at this?

Comment 18

19 years ago
Scott, comments seem to indicate you're going to handle getting the build
working again.  Send to David for the long term fix when you're done?
Assignee: selmer → mscott
Target Milestone: --- → M15

Comment 19

19 years ago
Steve, Scott is really the king of sockets and channels and mock channels and 
necko interaction.

Comment 20

19 years ago
accepting...I have a build I'm playing with now. But if we don't get traction on
this soon and if this becomes our last blocker keeping the tree closed then we
may need to back out the nsSocketTransport changes out until we can figure this out.

Comment 21

19 years ago
Unless I'm missing something the problem seems pretty obvious. The socket is
initialized with a default time out time which is really small (which is good
for connectionless protocols like http).

The timeout is currently: DEFAULT_SOCKET_TIMEOUT_IN_MS 35*1000

If we don't read or write from the socket within that time period then this
timeout alert is coming up.

This is bogus for connection based protocols like imap where we ALWAYS have an
open connection to the server. Even if we aren't actively reading or writing
something from/to the connection.

This isn't to say imap doesn't have a timeout duration. It does, but it happens
to be a user configured pref that we manage on the protocol side not the socket

We need to expose an interface to allow a protocol to set the timeout field on a
network socket (no such interface exists yet since a protocol talks to a socket
via the nsIChannel interface and it doesn't provide such a call). Then imap can
set the same timeout it is using (which is usually on the order of minutes) and
we shouldn't see this dialog.

For now I'm thinking we need to back out the change to the socket transport
until such an interface is provided.

Comment 22

19 years ago
Ruslan, the only part that we need to back out is the following change to

    if ((mCurrentState  == eSocketState_WaitConnect || mCurrentState ==
        && idleInterval >= gTimeoutInterval)

should be
    if ((mCurrentState  == eSocketState_WaitConnect)
        && idleInterval >= gTimeoutInterval)

Can you please review this so we can get this off the blocker list? Thanks!
this bug is also horking folder discovery the first time I log into my imap 
mscott's fix is working for me.  at least now I can use mailnews again.  are you 
going to check this in?

Comment 25

19 years ago

We already time out connections, so the new code was only for read/write 
timeout. I think you should back out the stuff Ruslan did if he isn't around to 
do it right now. 

If anything, there should be a setter for the timeout value (that http would 
use). Not setting it would == infinite timeout.

Comment 26

19 years ago
I can check it in. But let's not close a bug and have somebody look into it, ok?
*** Bug 34668 has been marked as a duplicate of this bug. ***

Comment 28

19 years ago
I actually already checked it in.

I'd like to mark this one closed and re-open a new one on the socket service to
allow http to set a timeout value on the socket. How does that sound to you?

I really don't believe there is any "hanging AsyncRead" problem here in the imap
case. We maintain a connection to the server and read and write to it all the
timeout. We manage the timeout at the protocol level if we decide to kill a
connection because we think it's timed out (as i said, it's a user controlled
pref for imap).

I agree with warren, if a timeout is set on the socket, we should use it (ala
the http case). If there isn't a timeout set in the read write case, then it
should be an infinite timeout.

I'll mark this fixed and open a new networking bug.
Last Resolved: 19 years ago
*** Bug 34668 has been marked as a duplicate of this bug. ***

Comment 30

19 years ago
Fine by me. I already opened up a bug against myself to add setters? Do you want 
me to quickly put it into M15 or M16 is fine?
*** Bug 34668 has been marked as a duplicate of this bug. ***

Comment 32

19 years ago
It's up to you. if you want http timeouts to work for M15 then I guess it should
be M15 otherwise M16.  I think http would be the consumer of your setter since
it's the only one interested in setting the timeout right now...
*** Bug 34668 has been marked as a duplicate of this bug. ***

Comment 34

19 years ago
Update: Using build 2000-04-05-21 on win98 and 2000-04-06-10 on linux this is 
fixed.  Still need to verify on Mac

Comment 35

19 years ago

Comment 36

19 years ago
I added default timeout of 30 seconds for http connections (Can be changed via 
prefs). If 30 seconds is not enough we can make it bigger.

Comment 37

19 years ago
IMAP connections need to stay alive 30 minutes. But you only changed http 
connections, so that should NOT affect this bug, right?

Comment 38

19 years ago
Right. Sorry. Just updated the wrong bug :-) Imap connections are not affected 
at all.
mid-air collision ? / bugzilla cleanup
Reopening (current State: verfied and no resolution)
Last Resolved: 19 years ago18 years ago
Resolution: --- → FIXED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.