Forum Discussion

Hoffit's avatar
Hoffit
New Contributor
10 years ago

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.

7 Replies

  • Hoffit's avatar
    Hoffit
    New Contributor
    I've created a ticket: 00050111

    I forgot to specify in the ticket the steps to reproduce so I will do it here.

    Load up the SOAPUI project that I attached to the ticket, and navigate to the form view.

    There is a top level complex type 'principal'. In the form view, there is a drop down to 'Select Content'. Shown is the highest level type in the associated schema file 'Party.xsd'. The drop down contains a number of sub-types that can be selected.

    Select the Company_TO sub-type.

    This is where SOAPUI will spin and consume max memory.

    Thanks!

    David H.
  • Hoffit's avatar
    Hoffit
    New Contributor
    One thing to add. I believe that SOAP UI is adding optional elements, which is what is taking so long and creating a huge request. Our model is recursive in places, and I believe SOAP UI is spinning through that and creating tens of thousands of optional elements.
  • SmartBear_Suppo's avatar
    SmartBear_Suppo
    SmartBear Alumni (Retired)
    Hi,

    I have notified Giscard who is handling this support case with the additional information, thanks.


    Regards,
    Marcus
    SmartBear Support
  • Hoffit's avatar
    Hoffit
    New Contributor
    Any update? I'm at a new client and using the same large models - but before I request a pro license - looking to see if this has been resolved.

    David
    dehull_1@yahoo.com
  • SmartBear_Suppo's avatar
    SmartBear_Suppo
    SmartBear Alumni (Retired)
    Hi,

    In your vmoptions file change xms to 128 instead of 512.
    I am able to create a new request from the operation in 4.6 and there will be a pop-up asking if I want to include optional elements or not (when the option is not set in Preferences/WSDL Settings). That works if I say no to including optional elements.
    And when the option is set in preferences, that's when it creates the request with all the optional elements without prompting to confirm any option. I tried this on 4.6 and it worked. I suggest you backup your project and download our latest release which is version 5.1.2 maintenance build: http://www.soapui.org/Downloads/soapui- ... uilds.html
    Let me know if the option works for you.

    Thanks,
    Jeshtha