Surety is performing system maintenance this weekend. Electronic date stamps on new Prior Art Database disclosures may be delayed.
Browse Prior Art Database

A system and method of smart diagnostic data collection on transaction server

IP.com Disclosure Number: IPCOM000237445D
Publication Date: 2014-Jun-18
Document File: 6 page(s) / 94K

Publishing Venue

The IP.com Prior Art Database


In a distributed complex environment, where the tasks are routed by a dynamic selecting method, it's hard to know which system nodes are involved when a problem occurs. And it's hard to determine how many dumps of system nodes are enough to analyze the problem. The disclosure discloses a method to dumps the system nodes by application scope automatically in time. Application dump contains sufficient information for problem analysis for the cross system task. User do not need to take the multiple system nodes' dumps manually, and the time of the dump taken is right after the problem occurs, there will be no risk for the useful debug data gone.For the application trace, user can see the application flow in one single trace file across multiple system nodes, this is very useful that user do not need to browse several file separately.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 44% of the total text.

Page 01 of 6

A system and method of smart diagnostic data collection on transaction server

Nowadays, modern computer software generally follows an academically defined software life cycle. The development of an application begins with the design and functional specification of the application followed by both internal and external testing. Once testing has proven the efficacy of the application, the application can be deployed to the end user for use. Subsequently, modern computer software developers are continually improving and updating software, even after the software is released to users.

In this life cycle, there are 2 steps we need to focus:

1) During application development, it is quite common for developers to use memory dump or system/application trace to debug the application problems. In almost any modern operating system, memory dump is supported which can be triggered by system automatically or user manually. The memory dump allows the software developers to perform investigation into the cause of a crash or a hang(diagnostic).

2) After the software is released to end user, there are possibilities that the run-time and logical errors can be discovered in the software. If the program crashes or hangs, a PMR can be raised to developer side. User needs to send the feedback to the developer in order to find the root. This feedback may include useful information about the operating environment at the time a software program crashes or hangs and allows the software developer to investigate and fix any bugs in the software. The dump and trace are one of most important materials in the feedback.

In these 2 steps, there are problems under the following circumstances:

While it works well under single system environment, it is not so good to work under multi-system(distribute) environment. For example, it is always frustrating to debug under multiple system nodes. when 2 system nodes are established connection and these 2 system nodes are co-working. While one system node(we name it Server) is sending data to another system node(we name it Client), something error happens at this point at Client side, usually, the dump will be taken at Client side only. The Server side didn't aware of this and won't take dump.

Also, when there are lots of system nodes are involved, for example, one transaction is routing among 10 system nodes, all these nodes are connected. It is not easy to understand when and where to take a dump.

So the prior arts limitation is as follows:

1) Not easy to automate. In distribute systems and product environment, since the dump costs too much(resource is critical). Take dumps for all systems connected is not an option.

2) No scopes. In normal circumstances, the software can be divided into several modules. For example, module A(running in system node A) links module B(running in system node B). Module B then links module C(running in system node C). When system node A is only a task node and it is routing requests to syste...