Using ipmDump

Top Previous Next

The ipmDump attribute of the <service> and <method> elements determines whether SOAP/AM Server will create an "interprocess message dump" when a service method is called. An interprocess message dump shows the content of the 'request' interprocess message SOAP/AM Server sent to your Pathway or Guardian server as a result of the method call and the reply interprocess message that was returned. The dump shows the messages in hexadecimal and ASCII formats. An interprocess message dump is useful for troubleshooting or debugging your client application or Service Definition File (SDF).

Syntax

A value of "0" indicates that no interprocess message dump should take place. A value of "1" indicates that an interprocess message dump should take place. If ipmDump is specified on <service>, its value becomes the default for all <method>s within the service. ipmDump specified on a <method> affects only that method.

The ipmDump is stored in the Virtual File System folder /logs/diagnostics in a file named

Dump-servicename-methodname.txt

where servicename and methodname are the names of your service and method, respectively. If the file exists at the time of the dump, it is appended to the existing content. Here's a sample generated from the cpuStatusService sample service (/services/samples/cpuStatus/cpuStatus.sdf):

--------------------------------------------------------------------------------

Start of Dump

--------------------------------------------------------------------------------

Service: CpuStatusService

Method: GetCpuStatus

Time: Tue, 1 Apr 2003 00:00:00 GMT

Client IP: 192.168.168.66

SOAP/AM User: Anonymous

Guardian User: 1.1

(if wireDump was also enabled, you'd find its output here)

Server Request

----------------------------------------

ProcessName: $scpu

ServerClass: (not specified)

RequestSize: 12

0x0000: 0000 0000 0000 0000 0000 0000 00000: ............

Server Reply

----------------------------------------

File System Result: 0

Pathesend Result: 0

ReplySize: 260

0x0000: 0000 0002 0000 0000 4e53 522d 5700 0000 00000: ........NSR-W...

0x0010: 0000 0004 0001 0000 4e53 522d 5700 0000 00016: ........NSR-W...

0x0020: 0000 0001 0000 0000 0000 0000 0000 0000 00032: ................

0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 00048: ................

0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 00064: ................

0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 00080: ................

0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 00096: ................

0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 00112: ................

0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 00128: ................

0x0090: 0000 0000 0000 0000 0000 0000 0000 0000 00144: ................

0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 00160: ................

0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 00176: ................

0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 00192: ................

0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 00208: ................

0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 00224: ................

0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 00240: ................

0x0100: 0000 0000 00256: ....

(if wireDump was also enabled, you'd find its output here)

--------------------------------------------------------------------------------

End of dump

--------------------------------------------------------------------------------

The dump begins with a "start of dump" header which includes the service and method names, the time of the dump, client IP address, authenticated user name and Guardian user identity under which the I/O was performed. Following the dump header are the server process name and serverclass. Next you'll find the server request and reply interprocess messages formatted in hex (to the left) with hex offsets and in ASCII (to the right) with decimal offsets. Finally, there's an "end of dump" trailer.

Also refer to Using wireDump for information about the wireDump feature for troubleshooting.