[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Web Service Request - Response Delay
Dhanushka,
You are welcome and there is no need for saying sorry. I am happy that
WSDL2RPG is not part of the problem.
At least I think that it is a good idea to add some timestamps to the
debug log and I am going to change the WSDL2RPG templates with the
next version.
Regards,
Thomas.
Dhanushka Manjula <dhanushkamanjula@xxxxxxxxx> hat am 23. September
2011 um 08:07 geschrieben:
> Hi Thomas & Mike,
>
> I found the reason for the delay!!!!!!!!
> It was my fault...!!
> I had a small procedure in my stub to leaving an XML element empty
in case
> of RPG send a NULL values. It was discuss with you early.
>
> The function was something like this
>
> d SearchR pr 65535a
> d DATA 65535a varying
> d SEARCHFOR 100a
> d REPLACEWITH 100a
>
> I searched the 0.00 value in "request" variable & replaced with
empty XML
> tag
> The code is something like this....
>
> Marshaller_toString(
> curZualBapiacap09_A2.ProfitCtr
> ) +
> '</ProfitCtr>' +
> '</item>' +
> '';
>
> Search_word = '<DsctDays1>0.00</DsctDays1>';
> replace_word = '<DsctDays1/>' ;
> request = SearchR(request:search_word:replace_word);
>
>
> It replace empty tag as i want but with 65353 with space.
>
> Then I %trim() the return value of the function.
>
> request = %trim(SearchR(request:search_word:replace_word));
>
> the speed of dramatically change... 3miunte to 10second
>
> I'm really sorry & I really appreciate for taking your valuable time
to help
> me
>
> Thanks all
> Dhanushka
>
>
>
> On Thu, Sep 22, 2011 at 5:17 PM, <thomas.raddatz@xxxxxx> wrote:
>
> >
> > HTTP_receiveResponse() is called after HTTPAPI received the
complete
> > response message or a chunk of the response message from the
server.
> > It then passes the received data to the SAX parser (actually
eXpat) to
> > pick up the return values.
> > What I want to know is how long does it takes to parse the xml
message
> > and to transfer the return values of the message into the return
data
> > structure. Therefore I asked you to add the debug statements to
> > HTTP_receiveResponse.
> > The attached zip files contains a sample test program (stub and
test
> > program) and a sample debug log. Please look at the stub module
and
> > search for '//RADDAT'. Add the same debug statements to your
program
> > and call your web service. As a result you should get log
statements
> > similar to:
> > WSDL2RPG Ver 1.13 released 2011-01-21
> > ** Start producing request message at:
2011-09-22-13.32.30.663000
> > ** Finished producing request message at:
2011-09-22-13.32.31.583000
> > ** Sending request message at: 2011-09-22-13.32.31.583000
> > ...
> > ** Entering HTTP_receiveResponse() at:
2011-09-22-13.32.31.941000
> > ** Start parsing response message at: 2011-09-22-13.32.31.941000
> > ** Finished parsing response message at:
2011-09-22-13.32.31.945000
> > ...
> > ** Entering HTTP_receiveResponse() at:
2011-09-22-13.32.32.123000
> > ** Start parsing response message at: 2011-09-22-13.32.32.123000
> > ** Finished parsing response message at:
2011-09-22-13.32.32.131000
> > http_close(): entered
> > Please do not forget to change the name of the debug file if you
want
> > to call the INEWS003T sample program. Most likely you also have
to
> > specify a proxy server if you want to call INEWS003T.
> > Thomas
> > ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx schrieb am 22.09.2011
11:30:37:
> > > Von: dhanushkamanjula@xxxxxxxxx
> > > An: ftpapi@xxxxxxxxxxxxxxxxxxxxxx
> > > Datum: 22.09.2011 11:43
> > > Betreff: Re: Web Service Request - Response Delay
> > > Gesendet von: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
> > >
> > > Hi again,
> > >
> > > My WSDL2RPG version is v1.13 and HTTPAPI Ver 1.23
> > > I did the traceroute from AS400 & Windows machine and
identified
> > that it is
> > > goes with same path.
> > > so i don't think this is a network issue.
> > > I'm using MemoryManager_createArray() methods as well.
> > > I'm really confuse what Mike is telling, can you please
explain to
> > how to do
> > > this.
> > > Thomas, What is the expected result of debug the procedure
> > > HTTP_receiveResponse()
> > >
> > > The second scenario, I have to send the few request message
to the
> > server -
> > > all are almost similar to attached response.
> > > I'm trying to send two message at once & I exectue my attached
> > webService
> > > client program in different jobq in one subsystem
> > > I hope in this case, the both execution will end up with 3
minutes,
> > but it
> > > doesn't gives any response.
> > > any idea please..
> > >
> > > Thanks
> > > Dhanushka
> > >
> > > On Wed, Sep 21, 2011 at 11:08 PM, Thomas Raddatz
> > <thomas.raddatz@xxxxxxxxxxx
> > > > wrote:
> > >
> > > > Dhanushka,
> > > >
> > > > Dynamic arrays might be an issue in case the arrays must be
> > extended too
> > > > often or if you use symbolic names instead of the array
handle.
> > > >
> > > > Because you use dynamic arrays I assume that you do not use
> > WSDL2RPG 1.3
> > > > but v1.13, right?
> > > >
> > > > Background information:
> > > >
> > > > If you use symbolic names instead of the array handles,
WSDL2RPG
> > has to get
> > > > the handle from a "Map" each time you access the array. For
that
> > it uses
> > > > the binary search algorithm. I wished I had a true index to
get
> > rid of the
> > > > binary search to increase performance.
> > > >
> > > > When creating a dynamic array the array allocates storage
for 256
> > elements.
> > > > Each time the array is full it reallocates storage for
another 256
> > > > elements. So for extremely huge arrays time to reallocate
storage
> > can
> > > > dramatically slow down performance. If you use very huge
arrays,
> > you should
> > > > specify a reasonable initial size at each
> > MemoryManager_createArray()
> > > > statement:
> > > >
> > > > MemoryManager_createArray(
> > > > serviceUUID: elemSize: name: ensureUniqueName:
increment)
> > > >
> > > > Do not use Array_new() directly!
> > > >
> > > > You may also add debug statements to procedure
> > HTTP_receiveResponse() of
> > > > your stub module:
> > > >
> > > > else;
> > > >
http_DebugLog_appendText('anyDebugText-StartParser');
> > > > if (XMLSAXParser_parse(g_hSAXParser: i_data:
i_length) =
> > cTrue);
> > > >
> > http_DebugLog_appendText('anyDebugText-EndParser-Success');
> > > > return i_length;
> > > > else;
> > > >
> > http_DebugLog_appendText('anyDebugText-EndParser-Failure');
> > > > return -1;
> > > > // return i_length;
> > > > endif;
> > > > endif;
> > > >
> > > > /end-free
> > > > *
> > > > P HTTP_receiveResponse...
> > > > P E
> > > >
> > > >
> > > > http_DebugLog_appendText
> > > >
> > > > Last but not least it might be an idea to set up a soapUI
mock web
> > service
> > > > to debug the problem inside the local network.
> > > >
> > > > Thomas
> > > >
> > > > Am 21.09.2011 18:43, schrieb Dhanushka Manjula:
> > > > >
> > > > > @ Mike
> > > > > I'll try to do it tomorrow...
> > > > > @ Thomas,
> > > > > One thing I forgot to mention, I use dynamic arrays in
order
> > to get
> > > > > around the 64k barrier..
> > > > > and processor utilization in our system is not more
than 65%
> > > > > I'll ask network guys to look into the firewall
again..
> > > > >
> > > > > On Wed, Sep 21, 2011 at 9:30 AM, Thomas Raddatz
> > > > > <[1]thomas.raddatz@xxxxxxxxxxx> wrote:
> > > > >
> > > > > Good idea, Mike!
> > > > > It is hard to believe that WSDL2RPG consumes the
> > additional time. I
> > > > > assume
> > > > > that one of the following things is true:
> > > > > 1. Network connection is different for the System i
and
> > his PC.
> > > > > 2. Too much workload on the System i.
> > > > > 3. soapUI does not parse the response, hence it must
be
> > faster (but
> > > > > not
> > > > > that much)
> > > > > If Dhanushka really uses WSDL2RPG 1.3 then WSDL2RPG
uses
> > simple
> > > > > string
> > > > > operations to create the request message. That
should not
> > take that
> > > > > much
> > > > > time. Then is calls http_post_xml() to send the
request,
> > receive
> > > > > the
> > > > > response and parse the response message.
> > > > > Thomas.
> > > > > Am [2]21.09.2011 18:01, schrieb Mike Krebs:
> > > > >
> > > > > > Let's narrow it down a bit. Are you experiencing
the
> > delay in
> > > > > transmission, receipt, or parsing. I don't know or use
> > WSDL2RPG but
> > > > > you can insert a couple of TIME statements to see the
time
> > of things
> > > > > in your debug log. Edit member HTTPAPIR4 and change
the
> > following
> > > > > lines (from current beta):
> > > > > >
> > > > > > About 354 (find entered)
> > > > > > c callp http_dmsg( 'do_oper('
+
> > peOper + '):
> > > > '
> > > > > > c + 'entered
at ' +
> > > > > %char(%time()))
> > > > > >
> > > > > > About 904 (find comm_blockread)
> > > > > > c callp http_dmsg('calling
> > comm_blockread at
> > > > '
> > > > > +
> > > > > > c %char(%time()))
> > > > > >
> > > > > > Recompile the service program by calling the
INSTALL
> > routine again
> > > > > or by following the instructions in the program
source.
> > > > > >
> > > > > > If WSDL2RPG has some similar debug points, do the
same
> > there so
> > > > you
> > > > > can see progression as it prepares/parses the XML.
> > > > > >
> > > > > > So then you can look at your debug file and see how
long
> > each part
> > > > > takes. Narrows down where to look for issues.
> > > > > >
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: [3]ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
> > > > > [mailto:[4]ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On
Behalf
> > Of
> > > > > Dhanushka Manjula
> > > > > > Sent: Wednesday, September 21, 2011 6:34 AM
> > > > > > To: [5]ftpapi@xxxxxxxxxxxxxxxxxxxxxx
> > > > > > Subject: Web Service Request - Response Delay
> > > > > >
> > > > > > Hello,
> > > > > >
> > > > > > I'm using WSDL2RPG 1.3 + scott's LIBHTTP to send
the
> > attached
> > > > > request
> > > > > > message to the server in remote location via 2MB E1
line.
> > > > > > it takes around 3 minutes to receive the attached
> > response
> > > > message.
> > > > > > Then, I used the SOAP-UI from my windows machine&
> > execute the
> > > > same
> > > > > request
> > > > > > & it takes around 10 seconds to complete the
process.
> > > > > > what will be the reason for this delay?
> > > > > >
> > > > > > Thank you
> > > > > > Dhanushka
> > > > > >
> > > > >
> > > >
> >
----------------------------------------------------------------------
> > > > > -
> > > > > > This is the FTPAPI mailing list. To unsubscribe,
please
> > go to:
> > > > > >
[6][1]http://www.scottklement.com/mailman/listinfo/ftpapi
> > > > > >
> > > > >
> > > >
> >
----------------------------------------------------------------------
> > > > > -
> > > > > >
> > > > >
> > > >
> >
----------------------------------------------------------------------
> > > > > -
> > > > > This is the FTPAPI mailing list. To unsubscribe,
please go
> > to:
> > > > >
[7][2]http://www.scottklement.com/mailman/listinfo/ftpapi
> > > > >
> > > >
> >
----------------------------------------------------------------------
> > > > > -
> > > > >
> > > > > References
> > > > >
> > > > > 1. [3]mailto:thomas.raddatz@xxxxxxxxxxx
> > > > > 2. tel:21.09.2011%2018
> > > > > 3. [4]mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
> > > > > 4. [5]mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
> > > > > 5. [6]mailto:ftpapi@xxxxxxxxxxxxxxxxxxxxxx
> > > > > 6.
[7]http://www.scottklement.com/mailman/listinfo/ftpapi
> > > > > 7.
[8]http://www.scottklement.com/mailman/listinfo/ftpapi
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> >
----------------------------------------------------------------------
> > -
> > > > > This is the FTPAPI mailing list. To unsubscribe, please
go to:
> > > > > [9]http://www.scottklement.com/mailman/listinfo/ftpapi
> > > > >
> >
----------------------------------------------------------------------
> > -
> > > >
> >
----------------------------------------------------------------------
> > -
> > > > This is the FTPAPI mailing list. To unsubscribe, please go
to:
> > > > [10]http://www.scottklement.com/mailman/listinfo/ftpapi
> > > >
> >
----------------------------------------------------------------------
> > -
> > > >
> > > [Anhang "SAP0010TN.txt" gel�t von Thomas Raddatz/OBI/DE]
> > >
> >
----------------------------------------------------------------------
> > -
> > > This is the FTPAPI mailing list. To unsubscribe, please go
to:
> > > [11]http://www.scottklement.com/mailman/listinfo/ftpapi
> > >
> >
----------------------------------------------------------------------
> > -
> >
> > --
> > IMPORTANT NOTICE:
> > This email is confidential, may be legally privileged, and is
for the
> > intended recipient only. Access, disclosure, copying,
distribution, or
> > reliance on any of it by anyone else is prohibited and may be a
> > criminal
> > offence. Please delete if obtained in error and email
confirmation to
> > the sender.
> >
> > References
> >
> > 1. http://www.scottklement.com/mailman/listinfo/ftpapi
> > 2. http://www.scottklement.com/mailman/listinfo/ftpapi
> > 3. mailto:thomas.raddatz@xxxxxxxxxxx
> > 4. mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
> > 5. mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
> > 6. mailto:ftpapi@xxxxxxxxxxxxxxxxxxxxxx
> > 7. http://www.scottklement.com/mailman/listinfo/ftpapi
> > 8. http://www.scottklement.com/mailman/listinfo/ftpapi
> > 9. http://www.scottklement.com/mailman/listinfo/ftpapi
> > 10. http://www.scottklement.com/mailman/listinfo/ftpapi
> > 11. http://www.scottklement.com/mailman/listinfo/ftpapi
> >
> >
----------------------------------------------------------------------
-
> > This is the FTPAPI mailing list. To unsubscribe, please go to:
> > http://www.scottklement.com/mailman/listinfo/ftpapi
> >
----------------------------------------------------------------------
-
> >
> >
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------