-
Notifications
You must be signed in to change notification settings - Fork 6
RobustnessTests
TCP/IP was not designed for reliability but for robustness, because the Internet infrastructure does not cooperate. Anytime and anywhere the connections between nodes could go wrong. Since TraceHub is for developers to trace, log and diagnose, it has to be highly robust.
Here are some typical test cases that were used during development, and you can use these to evaluate if TraceHub is suitable for your needs.
You may need some tools to block connections temporarily. Just google "temporarily block internet access windows" you may find many.
You have TestTraceListener.exe running in machine A, and TraceHub Slim running in machine B, with the browser or TraceHub Console running in machine B as well
- In the Command Prompt hosting TestTraceListener.exe, trigger a few traces to prove the operation is OK.
- Block the connection between A and B, then you may see some error message (only in TestTraceListener.exe DEBUG build) displayed in the Command Prompt, and HubTraceListener attempts to connect to TraceHub every 20 seconds.
- Trigger a trace.
- Enable the connection between A and B, and you should see traces appearing in the Browser or TraceHub Console in B within 20 seconds.
- Trigger 5000 traces, and block the connection immediately. You may be seeing a few traces transmitted already.
- Then enable connection. You will see the rest will be transmitted.
Remarks:
It may take less than 1 second to transmit 5000 traces, so your fingers have to be lightening fast. Or, you may use a very slow VM to run TestTraceListener.exe.
You have TestTraceListener.exe running in machine A, and TraceHub Slim running in machine B. The browser and TraceHub Console running in machine C. Make sure they are all operating well.
- Put A and C into sleep.
- After 1 or 2 minutes, wake up C and A.
- Trigger some traces.
Remarks:
If you want to log all traces and had hooked a RollingFileTraceListener or alike to TraceHub Console, you should make sure the machine hosting TraceHub Console never fall into sleep.
If TraceHub is restarted and there are some traces buffered in HubTraceListener during the restart, it could happen that HubTraceListener has re-established connection with TraceHub before TraceHub Console or Javascript scripts in the browser could, then the traces may be sent to TraceHub before TraceHub Console or the browser could receive them.