[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

R: R: HTTPAPI somitimes Timeout with CommSSL err. 43



Thanks Mike,

no problems reinstalling it, and with timestamp I discovered that in the night the same W.S. call finish in about 110 second, while in the day finish in 20 secs:
----------------------------------------------------------
2014-07-22-06.00.05.064000 recvresp(): entered
...
2014-07-22-06.01.46.171000 SetError() £13: HTTP/1.1 200 OK
2014-07-22-06.01.46.171000 recvresp(): end with 200
2014-07-22-06.01.46.171000 recvdoc parms: identity 382779
2014-07-22-06.01.46.173000 header_load_cookies() entered
2014-07-22-06.01.46.174000 cookie_parse() entered
2014-07-22-06.01.46.174000 cookie =  ASP.NET_SessionId=1vssgy3dvj3; path=/; HttpOnly
2014-07-22-06.01.46.175000 cookie attr ASP.NET_SessionId=1vssgy3dvj3
2014-07-22-06.01.46.175000 cookie attr path=/
2014-07-22-06.01.46.175000 cookie attr HttpOnly=
2014-07-22-06.01.46.177000 recvdoc(): entered
2014-07-22-06.01.46.177000 SetError() £0:
...
2014-07-22-06.01.54.458000 http_close(): entered
-----------------------------------------------------------------
2014-07-22-09.00.36.449000 recvresp(): entered
...
2014-07-22-09.00.48.047000 SetError() £13: HTTP/1.1 200 OK
2014-07-22-09.00.48.047000 recvresp(): end with 200
2014-07-22-09.00.48.047000 recvdoc parms: identity 382779
2014-07-22-09.00.48.047000 header_load_cookies() entered
2014-07-22-09.00.48.048000 cookie_parse() entered
2014-07-22-09.00.48.048000 cookie =  ASP.NET_SessionId=lz41yphvl0je3qw4; path=/; HttpOnly
2014-07-22-09.00.48.048000 cookie attr ASP.NET_SessionId=lz41yphvl0je3qw4
2014-07-22-09.00.48.048000 cookie attr path=/
2014-07-22-09.00.48.048000 cookie attr HttpOnly=
2014-07-22-09.00.48.048000 recvdoc(): entered
2014-07-22-09.00.48.048000 SetError() £0:
...
2014-07-22-09.00.56.294000 http_close(): entered
-----------------------------------------------------------------

So while on my side I'll raise up timeout limit (at least 180secs), I alerted our partner's technicians to find the reason of this gap.

Regards,
Marco Cecchi

-----Messaggio originale-----
Da: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] Per conto di Mike Krebs
Inviato: lunedì 21 luglio 2014 17:24
A: HTTPAPI and FTPAPI Projects
Oggetto: RE: R: HTTPAPI somitimes Timeout with CommSSL err. 43

Once you make the change to the source, you can just call install again and let it recompile everything. No harm will okay.

Mike Krebs

-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Marco Cecchi
Sent: Monday, July 21, 2014 4:31 AM
To: HTTPAPI and FTPAPI Projects
Subject: R: R: HTTPAPI somitimes Timeout with CommSSL err. 43

Hello Scott,

maybe slow server/connections could heavy delay ws responses? I'll try this night...

So, as Mike suggestion do you think it's better to loop calls while timeout errors leaving standard 60secs, than wait response for a longer time (600 secs)?
In that case, how to test timeout error? For ReturnCode=0?

How to recompile HTTPUTILR4 (added timestamp) without cause problems?

Regards,
Marco Cecchi

-----Messaggio originale-----
Da: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] Per conto di Scott Klement
Inviato: sabato 19 luglio 2014 07:55
A: HTTPAPI and FTPAPI Projects
Oggetto: Re: R: HTTPAPI somitimes Timeout with CommSSL err. 43

Marco,

I don't understand why you are asking about 20 second timeouts, when your example had 120 seconds.  120 seconds is much higher than 20 
seconds, isn't it?   120 seconds is two minutes.

You could certainly try setting the timeout to 10 minutes (600 seconds) 
and see if that helps.   Personally, my guess would be that it'd still 
fail with the same timeout error, but it would just take longer to get this error (because now it'll wait 10 minutes instead of 2 minutes before giving up.)

But, that's just a guess...  so you might want to give it a try and see.

-SK

On 7/18/2014 3:29 AM, Marco Cecchi wrote:
> Hello Mike, Scott,
>
> Thanks for you answers.
>
> 20 seconds could be normal for a list of active customers (about 500KB response).
>
> Partner who host WebService told me that some works might be slow until 6:00, but I have the same timeout on 7:00...
> So I think that Scott's conclusions are right, but I cannot find anything strange on my network in the night, and the partner say that the "others" customers haven't this problem...
> In this case could be helpful to set timeout to 600?
>
> However I'd like to follow your suggestion to modify HTTPUTILR4:
> Added timestamp(), but could you explain how should I recompile it, please?
>
> Regards,
> Marco Cecchi
>
>
> -----Messaggio originale-----
> Da: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
> [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] Per conto di Mike Krebs
> Inviato: giovedì 17 luglio 2014 22:01
> A: HTTPAPI and FTPAPI Projects
> Oggetto: RE: HTTPAPI somitimes Timeout with CommSSL err. 43
>
> 20 seconds is normal? Then what is abnormal?
>
> The data you receive back is relatively big for a web service. Maybe it just takes a long time to send? I wonder if the web service server is doing backup at night (consistent time of error?) and causing resource contention. So it might be operating "normally" but extremely slow.
>
> You need to override the timeout to be as long as you think is reasonable. If 120 seconds doesn't get results, try 300 or 600. Whatever you think is reasonable.
>
> If it were me...I'd capture the timeout (to me 30 or 60 seconds is long enough) and resubmit the job after a short wait.
>
> Or, if you wanted to debug a little more, you could do status reporting to see if you are getting data. I don't have 1.24 anymore but EXAMPLE8 of the beta software (http://www.scottklement.com/httpapi/beta/) shows status proc and how to use. You could use http_dmsg to dump the number of bytes received into the debug listing.
>
> If it were me and I was having timeout problems, I would change http_dmsg to include a timestamp so I could see how long everything is taking. Dmsg is in HTTPUTILR4 and you just find and change the wwMSG message like this:
>
> c                   eval      wwMsg = %char(%timestamp()) + ' ' +
> c                                     %trimr(peMsgTxt) + x'0d25'
>
> Recompile and your debug will show timestamps-combined with status proc and you will be closer to understanding what is going on with your web service.
>
>
>
> -----Original Message-----
> From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
> [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Marco 
> Cecchi
> Sent: Thursday, July 17, 2014 3:54 AM
> To: ftpapi@xxxxxxxxxxxxxxxxxxxxxx
> Subject: HTTPAPI somitimes Timeout with CommSSL err. 43
>
> Hello,
>
> thanks in advance for your open source and for your help.
> I installed HTTPAPI v1.24 on my iSeries v5r4, and I build some RPGLE programs seeing at Scott' Examples.
>
> In particular I use http_url_post_xml for consume our partner's WebService, but often (expecially by night) in the log I see this error:
> 43: CommSSL_Read:  time-out
> (I attached the full error log without senible data)
>
> The WS I'm calling isn't very heavy, in about 20 seconds when it works it end successfully (attached success log too for your comparation).
> However, reading previous posts on this mailing list archive, I tried to set this 2 parms:
>
> http_set_100_timeout(0);
> myTimeOut = 120;                   // Substitutes  HTTP_TIMEOUT (60secs)
>
> But still receive timeout error in the night and early morning, while success in the afternoon.
> I notice that when I receive the timeout in the morning, the same timeout I have on SoapUI tool, so I thought the problem was on partner remote server (maybe 2 with different settings ), but from their log they say that when I receive the error, on their side the request end successfully...
>
> If it was a SSL certificate problems I think that it should ever return the error.
> However I only set up the *SYSTEM certificate store in the Digital Certificate Manager. I didn't installed any external digital certificates.
>
> Where and what may be the problem?
>
> Thanks and Regards,
> Marco Cecchi
> DATACOM Srl
> Presso Com-Ital Group
> Via dell'Artigianato, 28
> 59013 Montemurlo (PO)
> Tel +39 0574 653453
> Fax +39 0574 650740
>
> Ai sensi del D. Lgs. 196/03 si precisa che le informazioni contenute in questa e-mail ed eventuali suoi allegati sono riservate e ad uso esclusivo del destinatario. Qualora il messaggio Vi fosse pervenuto per errore, Vi invitiamo ad eliminarlo senza copiarlo e a non inoltrarlo a terzi, dandocene immediata comunicazione. Grazie.
> ----------------------------------------------------------------------
> - 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
> ----------------------------------------------------------------------
> -
>

-----------------------------------------------------------------------
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
-----------------------------------------------------------------------
-----------------------------------------------------------------------
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
-----------------------------------------------------------------------