The Responder step is churning away but never sends a response before an HTTP Timeout occurs.
The logic that is killing your performance is located in the VSI response.
Here's a trick to help you see what is occurring:
- Stop Workstation
- Access your c:\users\<yourId>\lisatmp_10.1.0 directory
- Delete workstation.log then start your Workstation
- Start your VSM in ITR Mode (Single Step Mode) on your Workstation
- Send your request from SoapUI to your Workstation
- Allow Listen & VSI Selection Steps to fire (2 CLICKs)
- Access LISA_HOME\logging.properties and set the logger to DEBUG mode
- Go back to Workstation and CLICK next to cause Responder Step to execute
The Responder Step should start clocking. Let this step run for a couple of minutes and return to LH\logging.properties and set the logger back to INFO mode -- this will stop spewing out detailed log entries into Workstation.log.
You will notice that each of the elements in the response has displays in the log. DevTest does not start magic string {{ }} logic until data is about to 'go on the wire'.
The log displays will look something like this (abbreviated here for clarity):
2017-09-07 13:55:53,020Z (08:55) [thread] DEBUG com.itko.lisa.history.NodeExecHistory - notifyPropUsed: lisa.scripting.default.language value null
2017-09-07 13:55:53,026Z (08:55) [thread] DEBUG com.ca.sv.devtest.util.GenerateString - forRegex: regex=[A-Za-z0-9]{5,15} --generated random string=i7652VC
The generated string for the first element in my response started at:
2017-09-07 13:46:42,156Z (08:46)
I waited for a while and the response on the wire occurred at:
2017-09-07 13:56:58,507Z (08:56)
This tells me the beanshell logic and the forRegex method took approximately 10+ minutes to complete.
Looking back at the VSI, you will see that each of the elements contains beanshell with a call to GenerateString forRegex. Each of these {{ }} fragments is compiled and processed one at a time.
{{=%beanshell% com.ca.sv.devtest.util.GenerateString.forRegex("[A-Za-z {{=request_updateBillingAccountConfigurationInput_Payload_Customer_CustomerDetails_Party_Individual_IndividualIdentification_BirthCertificateIdentification_PartyIdentification_issuer_isLegalEntity;/*0*/}}-9]{5,{{=request_updateBillingAccountConfigurationInput_Payload_Customer_customerRank;/*1*/}}5}");}}
Was this code generated by DevTest when the service was created from WSDL?
Does the random data have to be based off a different field in the XML?
EDIT:
Normally, the regex that is generated for WSDL (using the vinlink-decoder.wsdl in the 10_1 examples folder, generates a regex that looks like this:
{{=%beanshell% com.ca.sv.devtest.util.GenerateString.forRegex("[A-Za-z0-9]{5,15}");}}
What had me concerned is the injection of the {{=request_<inputArgVal>}} into the regex which seems to be a double whammy.
EDIT, EDIT: (sorry, still looking at the response XML)
I see this sort of stuff in the response XML and it does not make sense to me. Assuming DevTest did a substitution, it appears that an invalid XML would be generated.
<ValidFor>
{{=request_updateBillingAccountConfigurationInput_Payload_CustomerAccountPartyRole_Party_Individual_IndividualIdentification_PartyIdentification_issuer_OrganizationIdentification;/*
*/}}<!--startDate is nillable and optional-->
{{=request_updateBillingAccountConfigurationInput_Payload_CustomerAccountPartyRole_Party_Individual_IndividualIdentification_PartyIdentification_issuer_OrganizationIdentification;/*
*/}}<startDate>{{=[:startDate:2000-01-01T00\:00\:00]}}</startDate>
{{=request_updateBillingAccountConfigurationInput_Payload_CustomerAccountPartyRole_Party_Individual_IndividualIdentification_PartyIdentification_issuer_OrganizationIdentification;/*
*/}}<!--endDate is nillable and optional-->
{{=request_updateBillingAccountConfigurationInput_Payload_CustomerAccountPartyRole_Party_Individual_IndividualIdentification_PartyIdentification_issuer_OrganizationIdentification;/*
*/}}<endDate>{{=[:endDate:2000-01-01T00\:00\:00]}}</endDate>
</ValidFor>
If we substitute a pretend value of "ABCD", the resulting XML would look like this:
<ValidFor>ABCD
<!--startDate is nillable and optional-->
ABCD
<startDate>{{=[:startDate:2000-01-01T00\:00\:00]}}</startDate>
ABCD
<!--endDate is nillable and optional-->
ABCD
<endDate>{{=[:endDate:2000-01-01T00\:00\:00]}}</endDate>
</ValidFor>
Perhaps the incoming request arg value is <blanks> which would not negate XML, but it is still very strange.
I removed all of the extraneous substitution and the response took about 14+ seconds to complete.
Attached is the VSI I used after replacing some of the magic string logic -- which may foul up the XML as I was going for a response not valid XML.