About debugging a service

There are four ways to debug a service:

  1. Customized service replay debugging
  2. Full service replay debugging
  3. Live service debugging
  4. Ad hoc service debugging
Service replay debugging (customized or full) is best used if you need to test your code under realistic conditions:
  • You do not want to limit the number of service instances (slots) available to your application,
  • You do not want to modify the application configuration other than debugging configuration, and
  • You do not want to modify your service code solely for debugging purposes.

The techniques discussed in this section apply to debugging a service in both IBM® Spectrum Symphony Developer Edition and IBM Spectrum Symphony.

The following diagram describes the overall process to follow to debug a service:
Process to debug a service

Customized service replay debugging

Customized service replay debugging generates service event replay logs (SERLs) upon detection of any error-handling events you customize for that purpose. By default, customized service replay debugging generates files for the following common service problems:
  • The service exits or crashes during the execution of a method.
  • The service throws an exception during the execution of a method.
  • The service times out while executing a method.
  • The service returns from a method with an exit code.

You can use the service event replay logs to try to reproduce your problem; you replay the relevant service events that occurred on the service instance.

You should be able to catch the most common service problems using this mode, particularly problems that are isolated (non-cumulative). If you cannot reproduce your problem in this mode, try debugging your service using the full service replay debugging.

Note: Running your application in customized debug mode uses more memory on the compute host than running with no debugging, or running in full debug mode. You might not be able to use customized service replay debugging if you have large common data or large task input.
Tip: Consider moving your application into production with customized service replay debugging enabled. You can test your service thoroughly in a grid environment until your service no longer produces service event replay logs in testing. Therefore any service replay debug logs generated in production reflect new problems (that is, those that did not arise in testing).

Full service replay debugging

Full service replay debugging generates service event replay logs for every service instance in your cluster, regardless of whether an error occurs in that service instance.

You can use the service event replay logs to try to reproduce your problem; you replay the service events that occurred on the service instance.

You should be able to use this mode to catch problems that are cumulative. For example, this mode might help you to find that your service memory becomes more and more corrupted at each task invocation. You would also use full service replay debugging if your service problem does not generate a SERL in customized mode, or if you cannot reproduce the problem using customized service replay debugging.

Tip: This mode is also useful for unit testing, stepping through your source code under a debugger during normal service execution.

If you cannot reproduce your problem using either customized or full service replay debugging, try debugging your service using live service debugging.

Live service debugging

Live service debugging allows you to debug your service instance as it is running live.

This mode gives you an exact picture of the runtime environment, not just a simulated environment.

If you still cannot reproduce your service problem using this mode, try debugging your service using ad hoc service debugging.

Ad hoc service debugging

If none of these methods help resolve a service problem, try logging, experimentation, or other techniques familiar to you.