Dynamically adjusting a log level of a transaction

Patent metadata

Field	Value
Publication number	US-9891979-B2
Application number	US-201615270124-A
Country	US
Kind code	B2
Filing date	Sep 20, 2016
Priority date	Jun 29, 2012
Publication date	Feb 13, 2018
Grant date	Feb 13, 2018

Abstract

A method dynamically adjusts a log level of a transaction. The method includes: buffering the most detailed logs of a transaction having highest log level into a memory; checking if all dependency-defined transactions within a dependency list/tree for the transaction are completed; and, in response to the completion of all dependency-defined transactions within the dependency list/tree for the transaction, obtaining a log filter level for the transaction in association with the transaction results (success/failure) of dependency-defined transactions, wherein the log filter level is a new log level for the transaction.

First claim

What is claimed is:

1. A processor-implemented method for dynamically adjusting a log level of a transaction, the method comprising:
in response to receiving notice of a transaction being completed in a data processing system, buffering a log of the transaction at a highest log level into a memory of the data processing system;
maintaining a dependency list for the transaction and dependency-defined transactions of the transaction;
determining, from the dependency list, whether all dependency-defined transactions for the transaction have completed; and
in response to determining all of the dependency-defined transactions within the dependency list have completed;
retrieving, from the memory, the log of the transaction and a log of each of the dependency-defined transactions; and
calculating a log filter level for the transaction, in association with transaction results within the logs of the dependency-defined transactions.

2. The method of claim 1 , further comprising, in response to a failure of one of (i) the transaction and (ii) any dependency-defined transaction, changing the log filter levels of all related dependency-defined transactions to the highest log filter level.

3. The method of claim 1 , further comprising selecting the highest log filter level from among the log filter level of the transaction and the log filter levels of the dependency-defined transactions.

4. The method of claim 1 , further comprising:
determining whether there is a transaction failure; and
in response to an absence of a transaction failure, establishing a new log filter level of the transaction to a highest log filter level from among the current transaction and the log filter levels of the dependency-defined transactions.

5. The method of claim 1 , further comprising:
determining whether there is a transaction failure; and
in response to an absence of transaction failure, determining a new log filter level of the transaction as the highest log filter level among the log filter level of the transaction and the log filter level of a dependency-defined transaction having direct dependency with the transaction.

6. The method of claim 1 , further comprising:
creating a filtered log according to a new log filter level of the transaction and writing the filtered log to a permanent storage.

7. The method of claim 1 , further comprising:
creating the dependency list according to the time of arrival of the transaction with reference to a dependency factor shared by two transactions; and
in response to there being only one dependency factor between the transaction and another transaction, creating a dependency list that enumerates the transaction dependency of the transaction, wherein the dependency list is created according to a time of arrival of the transaction with reference to a dependency factor shared by the transaction and another transaction from among the dependency-defined transactions.

8. The method of claim 7 , wherein the dependency factor is an attribute, resource or feature shared by the transaction and the other transaction and wherein the dependency factor is a thread, a TCP port, or a virtual memory address.

9. The method of claim 1 , further comprising:
dynamically adjusting a length of the dependency list based on availability in the memory.

10. The method of claim 1 , further comprising:
in response to there being multiple dependency factors between the transaction and the dependency-defined transactions, creating a dependency tree that enumerates the transaction dependency of the transaction, wherein a dependency factor is one of an attribute, a resource, and feature shared by the transaction and another transaction from among the dependency-defined transactions, wherein the dependency factor is one of a thread, a TCP port, and a virtual memory address, and wherein the dependency list is the dependency tree.

11. The method of claim 3 , wherein highest log filter level is a debug log level.

12. The method of claim 1 , wherein each dependency-defined transaction that has completed is associated with a log in the memory which has a log filter level that identifies a success or failure of a corresponding dependency-defined transaction.

13. The method of claim 1 , further comprising: in response to an absence of a transaction failure from among the transaction and any dependency-defined transaction, establishing a new log filter level of the transaction to a highest log filter level from among the current transaction and the log filter levels of the dependency-defined transactions.

14. The method of claim 1 , further comprising:
in response to there being only one dependency factor between the transaction and another transaction, creating a dependency list that enumerates the transaction dependency of the transaction, wherein the dependency list is created according to a time of arrival of the transaction with reference to a dependency factor shared by the transaction and another transaction from among the dependency-defined transactions.

15. The method of claim 6 , wherein the permanent storage includes an external log server.

16. The method of claim 6 , wherein writing the filtered log to the permanent storage further comprises, flushing the log of the transaction and the log of each of the dependency-defined transactions from the memory of the data processing system.

17. The method of claim 1 , further comprising:
tracking a status of the transaction and each dependency-defined transaction to the dependency list, wherein the status of a tracked transaction indicates at least one of: (1) the tracked transaction is in process, (2) the tracked transaction has completed, and (3) a log flush of the tracked transaction has been completed.

18. The method of claim 1 , further comprising:
generating the dependency list at a time of arrival of the transaction.

Assignees

• IBM

Inventors

• Liu Jeffrey C H
• Su Chih Wen
• Nestlerode Ivan
• Chiang Johnson Y S
• Tu Giant H M

Classifications

• G06F11/1471

  involving logging of persistent data for recovery · CPC title

• G06F9/466 Primary

  Transaction processing · CPC title

• G06F11/0745

  in an input/output transactions management context (input/output processing in general G06F13/00) · CPC title

• G06F11/0775 Primary

  Content or structure details of the error report, e.g. specific table structure, specific error fields · CPC title

• G06F11/079

  Root cause analysis, i.e. error or fault diagnosis (in a hardware test environment G06F11/22; in a software test environment G06F11/36) · CPC title