How to Help with Problem Investigation

This is the instruction for sending JIRA Client log files to ALM Works. See the end of the topic for long explanation.

To help us investigate the problem:
  • Stop JIRA Client.
  • Start JIRA Client with verbose logging turned on.
  • Reproduce the problem.
  • Send us log files.
Detailed instruction:

First, you need to stop JIRA Client because you have to re-start it with verbose logging enabled. Note that you cannot start a second instance of the application on the same workspace -- it will bring up the already existing instance. Of course, you don't have to restart the application if you are already running with verbose logging turned on.

Second, you need to start JIRA Client with a special script, found in "bin" sub-folder under the program installation folder. The script may be named:
  • debug.bat or debug.sh
  • jiraclient_verbose.bat or jiraclient_verbose.sh
After you start JIRA Client with verbose logging, reproduce the problem, so the related network communications are saved in log files. If the problem is not 100% reproducible, you can run the application in verbose mode until it happens.

Sending log files:
(Address to send log files to: support@almworks.com)

When the problem has been reproduced, please locate and send us log files. They are stored under "log" sub-folder in your workspace folder. By default it is:
  • On JIRA Client for Windows - C:\Documents and Settings\username\.JIRAClient\log (on Windows Vista - C:\Users\username\.JIRAClient\log)
  • On JIRA Client for Linux/Mac - ~username/.JIRAClient/log
Mind the dot before JIRAClient! You can make a ZIP archive of all files in that directory (including sub-folders), and send to support e-mail.

You can also send only relevant log files. The structure of the log files is quite simple:
  • tracker0.log - this is a general log files, please send it always;
  • jira/ - this is a subdirectory that contains dumps of network interaction with JIRA;
  • jira/hostname/ - dumps of interaction with JIRA on the <hostname> server;
  • jira/hostname/date/ - dumps of interaction with JIRA on the <hostname> server during <date> (NB: this is the day when application was launched, not the day when server has been accessed);
Using this information, you can select only relevant log files. When in doubt, send all files.

Network dumps do not contain your passwords: they are obfuscated with asterisks or dropped.


Why we ask you to do it:

Both JIRA Client and Deskzilla (''desktop clients'') have lots of functionality dedicated to exchanging data with JIRA or Bugzilla (''servers'') over the network. Typically, a desktop client uses all available server interfaces to extract and submit data in the most effective way.

Servers are separate products, maintained by other companies. Servers have varying versions, and each server installation may have a unique configuration. We strive to support every possible configuration and every version that's not very old. But it's hardly possible to test desktop clients against every version/configuration.

When a problem that concerns client-server interaction arises, we might be able to reproduce and isolate the issue using only verbal description or screenshots. But since the problem lies beneath the user interface, chances are that information about how exactly did desktop client communicate to server will be required.

This information - message dumps - may be collected by you with little extra effort, and it may provide great help to us in dealing with the problem. Of course you are not obliged to do that, but we will really appreciate your help - it may be the only way to figure out what happened, what are possible workarounds and how to fix the issue.