Hi all (and happy new year).
I’m currently facing some difficulties in Integration Server (technicals reference later in this post).
In only one session, i realise the following :
begin loop over 3 Xmls (let’s name it “A”)
Hi all (and happy new year).
I’m currently facing some difficulties in Integration Server (technicals reference later in this post).
In only one session, i realise the following :
begin loop over 3 Xmls (let’s name it “A”)
Here are some add-on upon the error.
In fact, the TransformSerialXml service seems to take a look at all the parameters in the pipeline.
The problem was coming from a quite complex document that was in the pipeline (it’s the return value of the second WS call, not dropped for some personal purpose.)
If this document (not parameter in or out, nor with a name that could be “reserved” → “traiterPTEReturn”) is present in the input pipeline, the Integration Server become unstable, and this often leads to the crash of the IS
We are able to reproduce this problem, and will soon drop a Case on this particular point.
But it seems quite awful that a simple parameter (even an “alien” one) in pipeline leads to a crash/stalling of the entire application.
Does anybody have similar experiences, or comments to share?
Regards
Jean-Marc LE TOUX
PS: excuse my poor english skill
You are correct that a StackOverFlow should not be happening.
It sounds like the problem is in the serialization of the pipeline when creating the SOAP message for the second call.
Is it possible to send a re-create of this problem to webMethods Support?
If you add a pub.flow:savePipelineToFile after the first call, then all that should be needed to recreate the problem is a pub.flow:restorePipelineFromFile, the call to the second service and the Web Service Connector service and input and output documents that the Web Service Connector uses.
I perhaps missed something in my explanation, but first loop is OK : the beginning of the second one leads to a crash, not the first one.
I have saved (with quite some IS reboots ) the
But it seem to be quite… BIG :
-rw-rw-r-- 1 user group 149315584 Jan 14 11:03 coreProducerPipeline
As the previous one (first loop) was only 37873, i think “Houston, we’ve got a problem”
This will be send to support as soon as i’ll be authorized to.
Thank for your help Fred, and if anybody got comments or help, feel free to respond my post.
JeanMarc LE TOUX
PS: i’m currently waiting for being added to my company’s “support request authorized” list.
As usual, please excuse my poor english.