I’m hoping someone may have seen this before and know the answer…
I’m seeing a strange thing when using the AEP SOAP connectors. Whenever I run a protocol I’ve written to call a pipeline pilot protocol via SOAP the longest part is the Start Job (upload data) and Get Results. The more results I have the longer it takes (as expected), however the time taken is exponential to the file size!
For example to return 10000 results generates a 1556Kb sdf file. This take over 3 minutes to return in Get results. However the actual SOAP service calculates the results in under 20 seconds (not dependant on file size)! So the transfer of data via SOAP is most of the time.
Uploading or downloading these files on the server from the client is pretty much instant, so it’s not a bandwidth / network issue as far as I can see.
The time it takes seems to increase exponentially relative to the file size for upload / download. The table below shows doubling the data in / out of the SOAP service creates delays much longer than double the time.
Start job (seconds)
return data (seconds)
File size (Kb) upload
File size (kb) download
During this time the Apache server is taking up an entire CPU core. This doesn’t stop even after start job times out.
Has anyone seen this before? Any thoughts as to what I could try? I’ve attached a protocol showing the steps I can to connect to the SOAP service. You won’t be able to run it, but it gives an overview of what I’m trying to do.
I haven't had a chance to run this yet, but what version of AEP / PP are you using? Also, you're saying that the httpd.exe process (not scisvr.exe) is taking-up the CPU, right?
I'm running aep9.1 HF2 on windows server 2008. My attached protocol won't run for you, but it gives you an idea of the steps and how I've used the soap connectors. You should see the effect if you create a simple soap service that does nothing and use the login and then start job to upload a file. increasing file sizes create a disproportionally large delay. If you don't see the effect I'll mock up a simpler couple of protocols showing the effect that can easily be added and executed on your server.
I've attached 2 more example protocols that you should be able to run. These are much simpler and still show the issue.
-SOAP wrapper issue demo.xml is the target protocol.
-Example for forum2.xml is the protocol that calls the wrapper protocol.
Save the wrapper to the webserices area somewhere, inspect the webservice to get the polling WSDL and then edit the SOAP connectors in the Example for forum2 to point to the WSDL on your server.
Enter your username and password. Then run it with differing number fo records. Again time taken to upload and download a file is exponential compared to the size instead of linear. Some example timings are below (in seconds)
Thanks for your reply on job pooling - thats been very helpful already.
Regarding this SOAP issue. We've done some more testing, calling the same SOAP service from the JAVA SDK. The SDK does not see the exponential like time increase that we are seeing when using the SOAP connectors in Pipeline Pilot. This further makes me beleive there is some kind of bug in the AEP SOAP connectors (or as likely that I'm doing something wrong).
See timings below when using the Java SDK
When you compare these to the ones above, you see the clear difference.
Have you had a chance to look at what's happening?
To close out this thread. There is a problem and its been raised as bug No PPC-6849