35844 - TCP sockets vanish: can't perform long queries in bugzilla

Status: VERIFIED WORKSFORME

(Core :: Networking, defect, P3)

Description

[R.K.Aa.]

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?

Comment 1

[R.K.Aa.]

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

Comment 2

[R.K.Aa.]

modified summary

Comment 3

[R.K.Aa.]

Don't waste time on this one yet - looks like a WFM-to-be.
Bonsai tells [e-mail] 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.

Comment 4

[R.K.Aa.]

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)

Comment 5

[R.K.Aa.]

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

Comment 6

[R.K.Aa.]

Attachment: socket status differences between NC4.7 and Mozilla

Comment 7

[R.K.Aa.]

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.

Comment 8

[Gervase Markham [:gerv]]

[e-mail] - do you want to confirm this bug?

Gerv

Comment 9

[R.K.Aa.]

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.

Comment 10

[Tom Everingham]

verif.
Linux 2000070420

Comment 11

[R.K.Aa.]

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.

Comment 12

[R.K.Aa.]

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

Comment 13

[Asa Dotzler [:asa]]

setting bug status to New.

Comment 14

[Darin Fisher]

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

Comment 15

[hirata masakazu]

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

Comment 16

[Gagan]

->darin

Comment 17

[benc]

mass move, v2.
qa to me.

Comment 18

[benc]

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)

Comment 19

[R.K.Aa.]

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 :/

Comment 20

[R.K.Aa.]

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

Comment 21

[Darin Fisher]

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!

Comment 22

[R.K.Aa.]

WFM on a current CVS build, Linux.

Comment 23

[benc]

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