M16 2000-04-13-16 linux Tested twice - same result: Ran a query in bugzilla for bugs - all statuses - where i've added comment. The page "please wait" appears. After this it appears the page is loding "forever". Result of the query never appears. (Same query on NS 4.7 takes around 80 sec. via modem) During this time i hear the disk rattle now and then and there was no other activity on the PC that could account for disk activity. Closed moz which then leaked 6 webshells. Filing as "network" cause i suspect something wrong happens to socket listening state and there's been trouble lately. Perhaps a timeout not notified about?

build 2000-041808 Today its slightly changed: The sockets that earlyer were CLOSE_WAIT now vanish. After moz having waited for a couple of minutes there were NO TCP sockets left at all. And the query of course never finished even if it "scrolled on".

modified summary

Don't waste time on this one yet - looks like a WFM-to-be. Bonsai tells ruslan@netscape.com checked in changes 04/19/2000 18:10 "Adjust transport socket timeout everytime it's getting put back into the work queue." I'll check next build and WMF if ok again.

Nope. Still no go. Also noticed: while moz displays the "Please stand by..." msg, and barber-pole spinning, it uses 57% CPU continously. But nothing happens. Hangs like that forever if i let it. (Gave it 9 minutes now)

The last test with 2000-042009 M16 - sorry for the spam.

Note that this bug is very very close related to bug 35150, but an "opposite case". The latest test was done in the currently latest M16 build from public ftp-site.

dark@c2i.net - do you want to confirm this bug? Gerv

with 2000-051210 the specified query worked again. The networking part of it still is different from NC4.7's though: The second IP i normally see never appeared. But the socket didn't time out before query results started transferring. Sure hope this improvement isn't a bugzilla-specific hack. Setting WFM. Will reopen if it surfaces again.

verif. Linux 2000070420

well it seems it's back - i never get a list of all bugs i've commented in. Tried two things: First a query on the verified bugs i'd commented in Then one for all status'es. None of these ever returned any input, and eventually all sockets the query opened had vanished.

still doesn't work. NC4.75 has no problems with the same query. Something is wrong. Reopening.

setting bug status to New.

I'm seeing something similar to this problem with Linux build 2000102612. Everything seems to be fine for even large queries (say 500 bugzilla hits)... its just the really really large queries that get us into trouble. I'm not sure what is going on exactly, but while the one browser window was spinning, I opened another and noticed that the second one seemed to have some trouble making a network connection. It finally worked, but not nearly as smoothly as it should be. Sounds like some of the necko threads may be getting abused...

*** Bug 65404 has been marked as a duplicate of this bug. ***

->darin

mass move, v2. qa to me.

I looked at your attachment. To understand why the netstat output is unclear, we need to find out what is on hosts .38 and .41. Probably to understand why the connects get that way, you need to do a packet trace. I use snoop on Solaris, anyone got a good tool for Linux? (I've also added testing for this problem to my general networking connectivity test case, which is being drafted at: http://www.packetgram.com/pktg/mozilla/nettest.html)

I saw a potential dup of this one some weeks ago but completely lost track of it - something about a "PAUSE" not being honored, in connection with CGI generated pages pulled from a database. The reporter said he frequently generated queries that would take 8-10 minutes to respond to, but mozilla always dropped the connection long before anything returned. Been searching - can't find it :/

Found it. Bug 80716 may be what i'm seeing here.

80716 should be fixed now... just waiting on confirmation from the reporter. in the old world we would drop connections if there wasn't any activity for a long while. since the http rearch branch landing, we no longer do this. i figured the user could always press the STOP button if the load was taking too long. so, the answer to this bug is: please confirm against a recent nightly build, thx!

WFM on a current CVS build, Linux.

VERIFIED: wfm. Mozilla 1.2a, all plats I get long query results everytime I look at Networking :)