Opened 18 years ago
Closed 17 years ago
#697 closed defect (worksforme)
Bug: Acessing status.php causes commflag to fail
| Reported by: | Owned by: | cpinkham | |
|---|---|---|---|
| Priority: | minor | Milestone: | 0.19 |
| Component: | mythweb | Version: | head |
| Severity: | medium | Keywords: | commflag mythweb |
| Cc: | Ticket locked: | no |
Description
Every time I access status.php commercial flagging on a remote host fails immediately. If status.php is not accessed, commercial flagging runs to completion. Please see the attached logs.
Attachments (2)
Change History (6)
Changed 18 years ago by
| Attachment: | backendlog.txt added |
|---|
comment:1 Changed 17 years ago by
| Owner: | changed from xris to Isaac Richards |
|---|
Isaac, since status.php (now linked straight to /status) just calls the backend status page, this is something in the core, not specifically mythweb.
comment:3 Changed 17 years ago by
If something is causing the building of the status webpage to take a long time, then won't it tie up the event queue wince the page is built inside HttpStatus::readClient()? This could cause the flagger to hang if it is trying to read data over the socket connection to the backend.
Can the submitter try to reproduce the problem while running both mythcommflag and mythbackend with "-v network". On the backend, retrieve the status page with wget using "date ; wget -O /dev/null http://localhost:6544/ ; date" so I can see the timestamps of when the wget started and ended.
Please attach the logs of mythcommflag, mythbackend, and the output of wget showing the timestamps from the date commands before and after.
comment:4 Changed 17 years ago by
| Resolution: | → worksforme |
|---|---|
| Status: | new → closed |
3 weeks and no response from the submitter. I'm closing this and assuming it's not an issue anymore. If the problem reoccurs, you can reopen if you provide the logs I asked for previously.
backend log