Hoffit
11 years agoNew Contributor
Using Form and specifying XSI type results in huge request
Hi,
This could be a bug, or perhaps a feature request.
I am running Windows 7 with 8GB ram. I've configured vm options with a min of 512mb and a max of 4gb. I am using SOAP UI Pro 5.1.0.
I have WSDL and schema files that represent large complex business models. Often times an element must specify an xsi type from a list of 20 or so sub-types. Each subtype may add some number of additional elements, as you'd expect.
I have specified the following WSDL and Pro preferences, in an attempt to minimize memory usage:
What I've observed is that when I select some sub-type form a Form view xsi type drop down, the memory usage will jump in seconds from a total machine usage of about 2gb to 6gb. It will then spin for a long time. Sometimes it will come back, and sometimes it never does. When it does come back, and I enter some random element value in a field, and then switch to the XML view, I discover that my 15 row request or response has blown up to 100,000 rows.
My WSDL/schema contains all optional elements, with the exception of three mandatory strings in the header.
I've been using a work around, where I manually enter the xsi type in the XML view, and then switch to the Form view. This works well, but requires I manually parse schema files to figure out the type hierarchy, in order to enter a correct xsi type.
Any suggestions?
Thanks - David H.
This could be a bug, or perhaps a feature request.
I am running Windows 7 with 8GB ram. I've configured vm options with a min of 512mb and a max of 4gb. I am using SOAP UI Pro 5.1.0.
I have WSDL and schema files that represent large complex business models. Often times an element must specify an xsi type from a list of 20 or so sub-types. Each subtype may add some number of additional elements, as you'd expect.
I have specified the following WSDL and Pro preferences, in an attempt to minimize memory usage:
What I've observed is that when I select some sub-type form a Form view xsi type drop down, the memory usage will jump in seconds from a total machine usage of about 2gb to 6gb. It will then spin for a long time. Sometimes it will come back, and sometimes it never does. When it does come back, and I enter some random element value in a field, and then switch to the XML view, I discover that my 15 row request or response has blown up to 100,000 rows.
My WSDL/schema contains all optional elements, with the exception of three mandatory strings in the header.
I've been using a work around, where I manually enter the xsi type in the XML view, and then switch to the Form view. This works well, but requires I manually parse schema files to figure out the type hierarchy, in order to enter a correct xsi type.
Any suggestions?
Thanks - David H.