0

Another question about coment.c in gwan.
In a browser, open many pages of csp_comet.html, start same feed with same freq. of 1 sec.
All ajax calls to comet.c with a timestamp.
But, when there are too many pages(about six pages), the newly opened page keep opening without any data displaying.

At this moment, even by other browser, other scripts and static pages of the same vhost cannot be accessed. The browsers display nothing. I tried to visit other vhosts( of same listener in gwan), it works fine but with latency.

I tried to kill some pages, and found that some had been dead(0 OK shown instead of the GMT time in csp_comet.html, and stop updating).
Keep on killing pages, the last hanging request became responsing to show data. At this state, there are about 6 active comet-feeding.

Who can tell what happened?
Or, can it be reproduced in your side?

My gwan version is 4.3.14
Ubuntu 12.04.2 LTS \n \l (3.2.0-49) 64-bit

result of ../?report ---------------------------
Requests
All: 39 (76.92% of Cache misses)
HTTP: 13 (33.33% of all requests)
Errors: 1 (2.56% of all requests) CSP: 50 (128.21% of all requests) Exceptions: 0

Connections Accepted: 36 (1.08 requests per connection)
Closed: 30
Timeouts: 9 (25.00%) Accept:9 Read:0 Slow:0 Build:0 Send:0 Close:0
Busy: 1 (Waiting: 0 Reading: 0 Replying: 1 Sending: 0 Pushing: 5 Relaying: 0 Closing: 0)

thread socket alive lastread timeout sent ip:port state request
1 19 00:26:42 00:00:00 00:00:00 0 127.0.0.1:22182 rSEND
1 20 00:26:27 00:00:00 00:00:00 0 127.0.0.1:22694 rSEND
1 22 00:26:19 00:00:00 00:00:00 0 127.0.0.1:23206 rSEND
0 18 00:01:09 00:00:00 00:00:00 0 127.0.0.1:48294 rSEND
0 23 00:00:00 00:00:00 00:00:04 0 127.0.0.1:49830 SEND GET /?report
0 27 00:00:53 00:00:00 00:00:00 0 127.0.0.1:48806 rSEND

k.k. lou
  • 1,805
  • 2
  • 13
  • 16

1 Answers1

0

I assume that your problem is different from the one presented here: "comet.c cannot work with more than one page opened in browser" ... and that you are using your own 'fix' (a random URI argument).

First question that comes to mind: did you try with 6 distinct clients (using 6 different IP addresses)?

The data you provide:

Timeouts:9 (25.00%)

...suggests that the client might not play well with concurrency, and if requests are delayed too much then you will have to ease the default G-WAN timeouts.

Community
  • 1
  • 1
Gil
  • 3,279
  • 1
  • 15
  • 25
  • thanks for your guidance. Will try many clients with different IP. – k.k. lou Jul 12 '13 at 04:40
  • If it is a client problem, why other browser cannot access the page when the same page is hanging in other browser? – k.k. lou Jul 12 '13 at 12:02
  • In the dead page, there is a `0 OK` replacing the GMT time. It should be sent by server to terminate that connection. If so, it may not be a client problem. The page stop updating may be triggered by the server, not by the client. – k.k. lou Jul 12 '13 at 12:05
  • That's what happens when a client timeouts. – Gil Jul 13 '13 at 08:25