Background​

Sometimes, an application may exhibit symptoms which are hard to understand without having information about the internal state, the workflow and timing of operations. This was not an issue with desktop applications as these basically follow the action->reaction principle. Anybody who has developed and debugged multithreaded or distributed applications knows what a mess it is to debug these type of applications. In fact, debugging also changes behavior due to the timing difference introduced with the debugger interaction. Because of the latter, it is very often impossible to analyse a problem in these types of applications.

Thanks to logging, we can record the workflow, timing and internal state of an application and its threads.

The Xbase++ WebHandler() and HttpEndpoint() support the Xbase++ XppRtFileLogger() which greatly contributes to the anaysis of workflow and state of existing WebHandler/HttpEndpoint-based applications. This way, we can gain information about:
  • is the endpoint listening and receiving requests at the configured port and proper IP address?
  • is the end point processing all the requests, or are there requests which are hanging?
  • is there a problem with the http protocol?
  • are all incoming requests properly scheduled as a job for processing?
  • do the jobs complete successfully, or is there a thread which is hanging?
  • are the jobs being executed in a timely fashion, or is there an unexplained lag in processing?

Controlling what goes into the log​

However, generating logging information all the time would polute the harddisk and create a lot of sensitive information which is not always required. So there must be a fine-grained way to control the information which goes into the log. This concept is called named logging. It allows the application to be configured for logging different aspects isolated or together depending on your specific needs.

Generally, errors and warnings are always logged into the log file. However info-level information or so-called trace information needs to be explicitly enabled using the xpp.logger environment variable. To enable logging of a specific facet of an application, named loggers need to be enabled as shown below. For example, a named logger for getting information about the data exchanged on the TCP-level may be enabled for the end point in the example above.

​

The xpp.logger environment variable selects logger objects for aggregating logging information:
set xpp.logger=[<loggername>][;<loggername>]

Example:
set xpp.logger=webhandler
or
set xpp.logger=webhandler;tcp
Click to expand...

Named loggers supported​

Subsystem: HttpEndPoint / WebHandler​


Logger Name
Purpose/Information Provided
webhandlerLogs information about the internal listener thread and the scheduling of jobs for processing requests
tcpLogs information on the TCP-level (socket communication)
tcp.dataLogs the data exchanged with the client(s) on the TCP-level


Log file location​

By default, an application's log is written to a certain location in the system's PROGRAMDATA folder. An separate log file is created for every day the application is being executed.

Location of the log file: c:\programdata\alaska software\logfiles\<appname.exe>\<yyyy-mm-dd-appname.exe.log>
Click to expand...