This article applies to:

  • JIRA Client version 1.0 or later

To help with diagnosing 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. 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 verbose logging turned on. This is done by running a special script, found in "bin" sub-folder under the program installation folder. The script may be named:

  • debug.bat or debug.sh
  • verbose_jiraclient.bat or verbose_jiraclient.sh

On Mac OS X you'll need to use the Terminal to locate and run the script. Open Terminal and issue the following commands:

  • cd "/path/to/JIRA Client.app"
    (e.g. cd "/Applications/JIRA Client.app")
  • ./verbose_jiraclient.sh

Then, 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.

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 JIRA Client for Linux/Mac - ~username/.JIRAClient/log

Mind the dot before JIRAClient! You can make ZIP archive of all files in that directory (including sub-folders), and send to our support address.

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;

Folder "jira" has a sub-folder for each JIRA host that you work with, which in turn have a subfolder for each day (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:

JIRA Client (desktop client) has lots of functionality dedicated to exchanging data with JIRA (server) 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