Feature #1406

Host response and UI actions should be available for later study

Added by drbits almost 11 years ago. Updated over 7 years ago.

Status:ClosedStart date:03/07/2010
Priority:NormalDue date:
Assignee:raztoki% Done:


Category:GeneralEstimated time:4.00 hours
Target version:020 - Next Release 2.0


The log (with Log Level=ALL) is only a brief summary and does not include any of the UI activity, very little about the host interaction (and inconsistent at that), and this makes debugging into guesswork. It would be useful if a zipped text file were saved for each session containing the HTTP level interactions (with a Java timestamp for each header), including the HTML. The file would also contain log entries of user actions (such as changing settings, adding links, and so on). When a TCP error or termination or connection (syn, syn ack, ack) occurs, these should also be recorded in some simple way.

The main log should include most of the program settings and a log entry when a setting changes. It should also include the GC statistical data (total physical memory, program size, heap size, heap usage %, heap fragmentation) about once per hour. When the statistics are reported, bytes transferred. transfer time and so on should be recorded. Currently, there is still not enough information in the main log to be sure which threads are part of a single host session.

Some examples of problems we are seeing that this would help:
1) Connection lost (usually misreported and Server Problem) at the start of a transfer may mean a closed port problem (if it occurs at the very start of transfer) or a connection speed problem. Connection speed problems are usually due to overload on the local computer causing a break in communications for 2 seconds or longer. Other programs can do this, but most often it is a large total number of connections (Max. Con. times Max. Dls. times 10KBps > maximum download rate).
We could distinguish these cases if we had a view at a slightly lower level.
2) Program stops responding to the keyboard and mouse. Or does it? Maybe it is just slow in updating the display. Maybe a modal thread is stuck in a system call (for example, opening a browse dialog or presenting a Captcha challenge that happens to be hidden).
3) We currently do not have the full set of error indicators (Plugin state in the FSM, HTTP status, problem status code, status string). Errors are often misreported because they occur in a different plugin state.

This is related to the endeavor to standardize the status reporting.

Related issues

Related to Feature #2350: Voluntary statistics reporting Closed 09/05/2010

Also available in: Atom PDF