Hi,
We have a web service consumer that is behaving strangely. We generated the web service consumer from a WSDL provided by the client.
It generally works fine until they switch to their DR environment. When they do, it appears we are still trying to connect to there Prod environment, even though the web service references the host name and not the IP address.
A simple restart of the IS fixes the issue. My question is, how do I fix this without a restart of the IS?
Thanks
In order to understand what’s really going on, I think you’d need to get some assistance from your network team to trace the routes taken after the provider of the web services switches to their DR site.
The fact that a restart of IS correct the issue points to something holding onto the previous IP address.
The hostname used in IS for the service URL should be associated with the load balancer or virtual IP address of the service provider and not the endpoint. Make sure that is a fully qualified domain name that is valid regardless of the physical server hosting the provided service.
Lastly, is the call to the provided service in some type of a retry block that attempts to reconnect on a network error or timeout? If not, it would be interesting to see whether a restart of IS is really required or just a retry of the same call.
So, in summary, get your network team to help ensure that your server or its operating system is not caching IP addresses when it shouldn’t and that a load balancer along the path to the service is not doing so either.
Mark
Thanks for the reply. My understanding is that the network team see the old IP address on the requests comign out of webMethods. The fully qualified host name we are using does point to their load balancer as well.
The default JVM behavior is to cache name lookup resolutions forever. Change that and the cutover to DR will work.
Ahhhh, I was hoping it was something like that. Is it a parameter to the JVM?
The provider should be using a Global Service Load Balancer (GSLB) whose IP address does not change when failover occurs to a backup site. The whole point is to make such transitions a non-event for the clients.
IMHO, if clients have to restart servers or change config files, the implementation of the failover strategy is faulty.
Mark
I agree with you Mark. Alas not every provider implements a client-friendly failover approach. 
Do a search of the web for “jvm inetaddress caching.” Confirm that the JVM you’re using supports the config changes.