Hi All,
I have a soap DOC/LITERAL serivce which is all working fine till it comes to a point where we have to check the response times.
My service has the xsd included in the WSDL itself. But the problem is not while receiving the message but more on sending the response back. Somehow Integration Server waits for a constant 15 seconds before actually sending the resposne back.
Now, for our calling service - we are using a java client constructing our own soap message and using the javax.xml.soap.* objects. we connect using SOAPConnection with basic auth over ssl.
Has anyone seen this kind of an issue anytime?
My environement
webMethods 6.5.
Just to check if the response would make a difference we did try both the http and the https with the same results. With the help of our webMthods engg group here at my clinet site we also did see that the message is sitting in the Integration Server server for 15 secs before actually triggering the response back to the calling client.
Now my question is do we have to set anything ont he calling client side to specify to send the response from IS immediately. The reason for this question is if I try an external tool like XRay to send the soap message I get the response back in less than 2 seconds. What is it that XRay is able to tell Integration Server to send the response quickly and my calling client is not?
if anyone could respond to this it would be very help. Even thoughts are welcome as I am running out of ideas.
I don’t know of anything that would make response times slower for one client but not the other besides using HTTP for one client and HTTPS for the other. Network topology differences could also affect this. If neither of these are the issue, then it follows that the performance difference is in the soap client’s handling of the response.
IS (still) does not support HTTP 1.1 so there is no optimization, such as compresson, available at the protocol level that you could turn off or on.
One way to verify that the issue is not in IS is to insert debugLog statements at the start and end of your invoked service or your custom soap processor. Client A and Client B should see the same elapsed times from the invoked service or soap processor assuming they are sending the same request message and all other variables remain the same.
Mark,
Thanks for the quick response. I was expecting one from you. As soon as I posted this the calling client people worked on some things and resolved the issue. Solution that they told me was somehting like this.
-They were testing this performance thing via a main in a java program…kind of standalone…
- They plugged it into the container and it started to give quicker response times.
I am not a Java person but whatever that means it resolved the issue. Whatever you had siad I had tried allt he option and whatever I did the response time on the execution of the service never changed. so I was quite positive that the problem does not exist on the webM side. But since its difficult for pple to accept mistakes it bcomes tough sometime explaining things to them. Anyway thanks again.
I have a situation where i need to make the soap time out once a certain amount of time elapsed after making the soap call. Is there any specific way to implement the time out capability while making soap call.
Essentailly what i am looking is that once i make soap call and do not get the response with in certain period says 15 seconds, then the service through which i making soap call should time and through a specific error code that it has timed out. Any idea experts…!!
Thanks in advance
KK.
Hi Mark,
Here is the enough details.
We make soap calls from webMethods domain (from IS service) to backend domain (BEC- can again be a webMethods service or any other service). If we do not get the soap response from BEC for whatever reason within a stipulated time, then we like the soap call to timed out, give a message to us that response have not arrived in that time period. Which mean we like to configure a value of time out parameter (say 20 seconds), so if we do not get soap response in 20 secs, sopa call should thows a message with error code that sopa has timed out.
You will need to create a set of utility services that allow you to invoke an IS service on its own thread using the Service.doThreadedInvoke() method.
Then create a simple Flow that contains only your pub.client:soapHTTP (or soapRPC) call and returns its results to the calling service using the pub.sync:notify service. In addition to whatever is needed to invoke your web service, your new Flow also need to accept a “key” parameter that it can use in the pub.sync:notify to pass results back to the parent thread.
The parent Flow will call the utility service to invoke your new child Flow on its own thread. It will then use the pub.sync:wait to wait for results for a predetermined period of time. If the timeout limit passes, it will throw an exception containing the string “wait timed out”. You can check the lastError/error variable for this string to handle a timeout differently from other exceptions.
Of course, you should work with the service provider to agree upon the quality of service they will provide. In support of any service level agreement that you negotiate, you should log any event in which the provided service does not meet expectations.