Technical Blog Post
Abstract
Troubleshooting steps on Slow transfer files in SBI – What to gather when it is a specific protocol.
Body
In my prior blog entry, I outlined the things to consider and think about when your Sterling B2B Integrator (SBI) application experiences slow file transfers.
This blog will help you with the data points to gather in the event that you have determined that this is related to a specific protocol in SBI. Whether be it a client or server adapter, these data points are necessary for analysis.
- LOGS! The log for the protocol in debug mode which contains the span of time when the file took a long time to process.
For example, if the file transfer is slow during the HTTP client adapter get step, then we’d need the httpclient.log in DEBUG mode (or ON) and ensure the time of the log spans the get step as shown in the business process details. It will also be beneficial to get the Perimeter.log and the PSLogger.log in debug mode as well(if applicable). Note the time! If the step that took a long time started on 10/25/2016 5:00 AM, then please ensure the corresponding log is for the time 10/25/2016 at 5 :00 AM.
The PSLogger is located in the server where the remote Perimeter server is located. If there are multiply remote perimeter servers, then we would need all of the PSLoggers from all the remote Perimeter Servers. - A screenshot of the Business process details steps if a BP is run for this process. This is very relevant because it guides which time to focus on in the log. In production environments, and especially busy production environments, the log may be constantly writing and we may focus on the wrong time while analyzing this issue. The bp details step screenshot will help us determine the times to focus on the logs. If there’s an error in the business process, please also take an additional screenshot
- A screenshot of the Communication Session screen in the event that SBI is the server and there’s no Business Process to look for. Again, the main point of this data point is to focus on the specific time the transfer occurred in the corresponding log.
- Thread dumps while the file transfer is slow. By analyzing multiple thread dumps, we can examine the active business process jvm threads and the server or client threads to gather more information. We recommend taking multiple thread dumps while the file transfer is occurring. Three thread dumps spread about 2 or 3 minutes apart should be good.
- Network traces while the transfer is occurring. The network traces will allow us to see the transfer details at the packet level. This is a bit tricky because not all network traces will have the answer for the slow processing. To start, I would recommend you place the trace where the SBI server is installed. If the protocol in play is using a remote perimeter server, it may be better to place the trace in the server where the remote perimeter server is installed.
- The IP addresses of the SBI server and the remote entity where SBI is connecting. To ensure that the network trace is accurately analyzed, we need to know the IP addresses so we can filter the packets by IP addresses. The DNS name doesn’t show up in a network trace.
- How’s your adapter configured? Go to Deployment -> Services -> Configuration and take a screenshot of the particular adapter configuration.
Data dependencies:
If you are submitting a network trace for analysis, please always submit:
* The corresponding BP Details screenshot or Communication session screenshot
* The IP address information
* The logs in debug mode.
A network trace by itself is difficult to analyze with no reference to a timeframe, log information or IP addresses to focus on.
Notes on Network traces.
I get many questions on how to gather network traces. If SBI is running on a Windows server, then you can gather the traces with a tool called Wireshark(or other equivalent tool) which can be downloaded for free. If SBI runs on a Linux/Unix server, then the root user of that server has access to a command called tcpdump. IBM Support has a good article recommending the use of tcpdump: http://www-01.ibm.com/support/docview.wss?uid=swg21701509
I hope this list helps you anticipate the data points to collect when troubleshooting a slow file transfer related to a protocol issue in Sterling B2B Integrator.
UID
ibm11121367