View source for Debugging the Janus Debugger

__TOC__
<span class="f_Para">Whenever your browser sends a web request to a </span><var>Janus Web Server</var><span class="f_Para"> that has been configured for debugging, this sequence of events unfolds: </span>

1. <span class="f_ListNum1">Before sending your web request, the Client on the workstation, which is [[Configure web browser (Janus Debugger only)|defined]] as your proxy server, connects to the Debugger Server port on the online (configured during [[Define and start the Debugger Server port|installation]]). The Debugger Server starts a thread whose default user ID is SOCKUSER. </span>

2. <span class="f_ListNum1">The Debugger Server communicates over a socket connection with the Client and creates a worker thread for this debugging session. The connection handshake contains a unique ID from the Client for this debugging session. The Server worker thread uses AUDIT statements to report its activities to the </span><var>Model 204</var><span class="f_ListNum1"> audit trail. </span>
: The following <var>SirScan</var><span class="f_ListContinue"> audit trail lines for user SOCKUSER report the Debugger Server activity described thus far. The session ID is encircled. Subsequent worker thread lines are shown [[Debugging the Janus Debuggerl#worker_audit_lines|later]]: </span>

[[File:workeraudit2b_zoom65.gif|692x166px|workerAudit2b]]<span class="f_ListContinue"> </span>

3. <span class="f_ListNum1">The worker thread is directed by the Debugger Client (based on user interface actions), and the worker thread maintains an internal master/slave, post/wait relationship with the Web Server thread being debugged. The initial action of the worker thread is to announce itself to the Debugger Client in the </span><span class="f_GUIlabel">Audit Trail</span><span class="f_ListNum1"> page: </span>

[[File:worker2cli2a_zoom75.gif|848x360px|worker2cli2a]]<span class="f_ListContinue"> </span>

4. <span class="f_ListNum1">The worker then continues in a loop/dialogue with the Client, reporting its state and latest activity to the Client, and receiving XML requests from the Client (commands that are based on what the Debugger GUI user is invoking). If the normal Web Server response to your web request is to include a </span><var>Model 204</var><span class="f_ListNum1"> procedure, for example, the Client sends the worker a command to have the Web Server continue, the worker posts that command to the Web Server, the worker sends AUDIT lines about this exchange, and the worker waits. </span>

5. <span class="f_ListNum1">While the worker thread waits, the Client sends your web request to the Janus Web Server. The worker's wait limit is two minutes, so it will time out and end if the request fails for any reason. Otherwise, the Web Server recognizes the  debugging session ID, so sends its response to the worker. In this example, the response is procedure code, which is sent to the worker instead of being run. The worker wakes up, sends the procedure code in an XML document to the Client, and the Client displays the procedure code in the Debugger </span><span class="f_GUIlabel">Source Code</span><span class="f_ListNum1"> page: </span>

[[File:clisource2b_zoom75.gif|599x411px|cliSource2b]]<span class="f_ListContinue">  </span>
: The worker thread reports its actions thus far in the lines below that begin with three asterisks (<span class="f_Monospace">***</span><span class="f_ListContinue">). </span><span class="f_ListNum1">The worker refers to the Web Server thread as the &quot;debuggee&quot;</span><span class="f_ListContinue">: </span>

[[File:workeraudit2_zoom65.gif|692x235px|workerAudit2]]<span class="f_ListContinue"> <span id="worker_audit_lines" class="hmanchor"></span> </span>

6. <span class="f_ListNum1">The Client-worker-Web Server communication continues in this fashion according to the commands invoked by the Client GUI user. The Client user initiates the next round of activity by invoking an operation on the source code, say, stepping to the next statement. The Client signals the worker, and the worker instructs the Web Server thread. The worker reports a sequence of audit lines similar to the previous ones (the ending </span><span class="f_Monospace">N</span><span class="f_ListNum1">'s below mean &quot;run to </span>'''''N'''''<span class="f_ListNum1">ext statement&quot; and &quot;</span>'''''N'''''<span class="f_ListNum1">ext statement executed&quot;):</span>

[[File:workeraudit3_zoom65.gif|558x81px|workerAudit3]]<span class="f_ListContinue"> </span>

7. <span class="f_ListNum1">In case you need to debug the Debugger, you can access the XML traffic exchanged between the worker and Debugger Client. To do so, use the JANUS TRACE command (described in the </span>'''''N'''''<span class="f_ListNum1">) to increase the tracing on the Debugger Server port (in this example, DEBUGSERVER3355), and use </span><var>SirScan</var><span class="f_ListNum1"> to view the traffic. The JANUS DISPLAYTRACE command reveals the current trace value. </span>
: Since a high tracing value, say <span class="f_Monospace">15</span><span class="f_ListContinue">, can capture huge amounts of data, remember to return the tracing setting to its former value when you no longer need so much detail.</span>
: Also of possible use in a debugging situation, the Debugger Client installation folder is the [[Changing the location of Client work files|default location]] for a text log (<span class="f_Monospace">log.txt</span><span class="f_ListContinue">) that includes the Client and workstation browser activity that is captured by the Client. <span id="log_client_jd" class="hmanchor"></span> </span>

[[Category:Debugger Home]]