Another quick post relating to developing script packages for IBM Workload Deployer, but also applicable to anyone using wsadmin. If one of your commands in a wsadmin script takes a long time to complete, you might receive a timeout from wsadmin which looks something like this:
org.apache.soap.SOAPException: [SOAPException: faultCode=SOAP-ENV:Client; msg=Read timed out; targetException=java.net.SocketTimeoutException: Read timed out]
What is happening here is you're running into com.ibm.SOAP.requestTimeout, a property which is defined in <PROFILE_ROOT>/properties/soap.client.props and defaults to 180 seconds. The "easy" fix for this is to just directly edit the soap.client.props file directly, but if you're trying to create a self-contained script package or working with a clustered environment - this is a messy solution. Unfortunately, the answer is not as simple as passing -javaoption "-Dcom.ibm.SOAP.requestTimeout=1800" into wsadmin, but there is a lovely neat solution:
- Copy the soap.client.props file from <PROFILE_ROOT>/properties and give it a new name such as mysoap.client.props.
- Edit mysoap.client.props and update the value of com.ibm.SOAP.requestTimeout as required
- Create a new Java properties file soap_override.props and enter the following line:
- Pass soap_override.props into wsadmin using the -p option: wsadmin -p soap_override.props...
This will cause your mysoap.client.props to be loaded in preference to the version shipped with the product, whilst enabling you to keep your scripts self-contained and not reliant on any nasty bits of sed.