[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: FW: FW: Help - HTTP_URL_POST_XML recvresp hanging
You are the expert Scott. I will defer to your greatness and not chime in on this subject again.
What have you to offer to Paul?
He can't share the code/website he uses so he is left to try to figure something out on his own. IBM pointed him to that parameter.
-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Friday, January 15, 2016 4:31 PM
To: HTTPAPI and FTPAPI Projects
Subject: Re: FW: FW: Help - HTTP_URL_POST_XML recvresp hanging
Mike,
GSK_IBMI_READ_TIMEOUT is for blocking sockets. HTTPAPI, however, uses non-blocking sockets. Non-blocking means that calling any API like
gsk_secure_soc_read() will always return immediately -- if there is data available from the network, it will return it, otherwise it'll return an error could that means "API had to return control back to the program, otherwise it would block". (Block means the API sits and waits without returning control.)
The select() API lets you sit and wait until network data appears, so it works like this:
1) Call gsk_secure_soc_read() to see if there's any data.
2) If there was data, process it.
3) If there wasn't data, use select() to wait for more data. (Select() provides a timeout.)
3) IF there should now be data, go back to step 1 to retrieve/process it.
This is the way HTTPAPI has worked for 15 years, and it has been timing out without problems. Now I'm being told to change to use GSK_IBM_READ_TIMEOUT, which the API docs say is for blocking sockets near the end of this page:
http://www-01.ibm.com/support/knowledgecenter/ssw_ibm_i_72/apis/gsk_secure_soc_read.htm
This means that you're looking for me to rewrite COMMSSLR4 to use blocking sockets. I don't see the point, as this has worked properly for 15 years.
Is there something wrong with the way I'm doing it? I don't have any way to tell that, since I can't reproduce the problem, I can't troubleshoot the current code at all.
If I spend the time rewriting it, will it solve the problem? Again, I don't have any way of testing that, because I can't reproduce the problem.
If we want to explore this further, step 1 is to reproduce the problem. This is key, because frankly all that you and Paul are doing is taking wild guesses. Unless I'm misjudging the situation, I am the one who is the expert, here? I don't know much about your background, but I have 20+ years of experience with this stuff, and I get the impression that neither you nor Paul has any. So, I think I'm the best person to take a look at what is going on. Then I can make a determination of what is the right way to proceed with either fixing what I have or rewriting it a different way.
-SK
On 1/14/2016 6:07 PM, Mike Krebs wrote:
> I have not made it that far into GSK understanding to know how it works the same or differently than using a select() timeout. But in the SSL communication mode, it appears that COMMSSL_READ is being used which uses gsk_secure_soc_read which does not include a timeout value. So, it seems that the timeout value would be from someplace else. Would that match your understanding?
>
> When I was looking up this "new" value, I saw in the documentation page for the gsk_attribute_set_numeric_value that there is handshake timeout, a v2 session timeout, a v3 session timeout and a receive timeout. Since the OP seems to be having a timeout problem, maybe the GSKit uses its own timeout values unless you specify a different one? And both the 24 hours and wait forever seem to fit the scenario as posted by the OP. We know his timeout value is the default and yet the program appears to be waiting beyond 60 seconds. And since COMMSSLR4 already implements the handshake timeout, it seems like an easy thing to try for the OP.
>
> The description of this operation
> GSK_IBMI_READ_TIMEOUT (6993) - numValue is the receive time-out for the secure session or the SSL environment.
> Also seems to fit. It doesn't preclude select() timeout from influencing it but it does seem to indicate the receive time-out for SSL should be set using this operation.
>
> If that resolves the issue, then maybe the OP can lend some further evidence to whether the GSK_IBMI_READ_TIMEOUT matters or not.
>
> -----Original Message-----
> From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
> [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Scott
> Klement
> Sent: Thursday, January 14, 2016 4:26 PM
> To: HTTPAPI and FTPAPI Projects
> Subject: Re: FW: FW: Help - HTTP_URL_POST_XML recvresp hanging
>
> Mike,
>
> Timeouts in HTTPAPI are implemented with the select() API. I am not using the GSK_OS400_READ_TIMEOUT (or GSK_IBMI_READ_TIMEOUT which is
> exactly the same thing). Are you saying that you can't have timeouts
> in GSKit unless you set GSK_OS400_READ_TIMEOUT?
>
> -SK
>
>
> On 1/14/2016 3:41 PM, Mike Krebs wrote:
>> In HTTPAPI, this value is only defined as a constant and the value of the constant does not appear to have changed. I don't think that is the exact issue.
>>
>> However, I don't see the read timeout being set the same way GSK_HANDSHAKE_TIMEOUT is being set. In COMMSSLR4 there is:
>>
>> eval rc = gsk_attribute_set_numeric_value(
>> wwSSLh: GSK_HANDSHAKE_TIMEOUT: peTimeout)
>> if rc <> GSK_OK
>> callp SetError(HTTP_SSSNTO: 'Setting timeout: ' +
>> ssl_error(rc))
>> callp close(s)
>> callp gsk_secure_soc_close(wwsslh)
>> return *OFF
>> endif
>>
>> The default timeout values are probably not what should be used. They are:
>>
>> GSK_V2_SESSION_TIMEOUT set to 100 seconds.
>> GSK_V3_SESSION_TIMEOUT set to 86400 seconds (24 hours).
>> GSK_HANDSHAKE_TIMEOUT set to 0 (wait forever).
>> GSK_IBMI_RECEIVE_TIMEOUT set to 0 (wait forever).
>>
>> Since the GSK_IBMI_RECEIVE_TIMEOUT is not set to peTimeout, is it waiting forever on a problem after the handshake or during the handshake when reading data from the server?
>>
>> To test this since you are having the problem, change COMMSSLR4. Right after the section of code above do the same thing but substitute GSK_OS400_READ_TIMEOUT for the GSK_HANDSHAKE_TIMEOUT. Change the error message slightly to indicate problem setting read timeout and recompile. The timeout value is supposed to be in milliseconds. You might want to hardcode a reasonable millisecond INT value. This part is little confusing to me as peTimeout is defined as packed(10:3) and it looks like it should be an INT. I also believe peTimeout is in seconds.
>>
>> If this doesn't resolve maybe you have to set the GSK_V3_SESSION_TIMEOUT to a more reasonable number than 24 hours. That value is in seconds.
>>
>> https://www-01.ibm.com/support/knowledgecenter/ssw_ibm_i_72/apis/gsk_
>> a
>> ttribute_set_numeric_value.htm
>>
>> Give it a whirl and see what happens.
>>
>> -----Original Message-----
>> From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
>> [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Paul
>> Kenosky
>> Sent: Thursday, January 14, 2016 1:31 PM
>> To: HTTPAPI and FTPAPI Projects
>> Subject: RE: FW: FW: Help - HTTP_URL_POST_XML recvresp hanging
>>
>> Hey Scott,
>>
>> Still trying to figure out why this is happening to the pgm...
>> I just got a response from IBM about this issue which I attached below..
>> Any idea?
>>
>> //** email snip-it from IBM **//
>> CUSTOMER REP: Paul
>> ACTION TAKEN: I sent him:
>>
>> In the V7R2 documentation for GSK Toolkit the parameter name changed
>> from GSK_OS400_READ_TIMEOUT to GSK_IBMI_READ_TIMEOUT, but it was not
>> marked as "new" in the v7r2 documentation. Check your code to see if
>> you are using the old parameter name.
>>
>> Bob
>> //** END of email snip-it from IBM **//
>>
>>
>>
>> Thanks,
>> Paul John Kenosky
>>
>>
>> -----Original Message-----
>> From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
>> [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Scott
>> Klement
>> Sent: Monday, January 11, 2016 8:52 PM
>> To: HTTPAPI and FTPAPI Projects
>> Subject: Re: FW: FW: Help - HTTP_URL_POST_XML recvresp hanging
>>
>> Paul,
>>
>> The web service provider shouldn't be able to prevent HTTPAPI from timing out. Likewise, HTTPAPI should time out, no matter what your CHGTCPA network settings are.
>>
>> Aside from a bug in HTTPAPI or the IBM i operating system, there shouldn't be anything that would prevent it from timing out.
>>
>> Unfortunately, without being able to reproduce it on my own system, there's very little I can do.
>>
>> -SK
>>
>> On 1/11/2016 8:01 AM, Paul Kenosky wrote:
>>> Hello Scott,
>>>
>>> I am having trouble re-creating the problem myself now... It has not happened lately(about a week) since I been trying to catch it in debug... and hasn't happened on its nightly run... Unfortunately, I don't think I can share the code to the web service.
>>>
>>> This is a new pgm connecting to a new web service, so I wonder if it could be something on their end that is not/was not setup correctly?
>>>
>>> I am going to setup a loop on this pgm so it makes a call to the web service every 30mins, so hopefully I can catch it in debug.
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
>>> [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Scott
>>> Klement
>>> Sent: Saturday, January 09, 2016 2:27 AM
>>> To: HTTPAPI and FTPAPI Projects
>>> Subject: Re: FW: Help - HTTP_URL_POST_XML recvresp hanging
>>>
>>> Paul Kenosky,
>>>
>>> TCPKEEPALV is not a time-out value. The default of two hours means that it'll send a packet every 2 hours to test the line and check if it's still active. This shouldn't have any impact on HTTPAPI at all.
>>>
>>> HTTPAPI should be doing it's own time out code. And with all of the people using it (and there are a LOT) I've not run into this timeout code getting "stuck" not timing out. Of course, that doesn't mean that you couldn't be unlucky and hit a bug that nobody else has, that's always possible...
>>>
>>> In order to help further, I need to know how to reproduce the
>>> problem you're seeing. Basically, I need to be able to run your program on my own machine where I can debug/troubleshoot it. Is that possible?
>>> Unfortunately, a code snippet isn't good enough, I need something that I can actually run.
>>>
>>> -SK
>>>
>>>
>>> On 1/8/2016 12:50 PM, Paul Kenosky wrote:
>>>> Thanks for helping me through this...
>>>>
>>>> I will look into CHGTCPA TCPKEEPALV(1) and see if that leads me anywhere... however you mention the default is 2 hours... I have left one of the hanging jobs run for about 6 hours before cancelling it....
>>>>
>>>> As for the TimeOut value I am using default CONST which is I believe 60secs...
>>>>
>>>> I am setting ccsids which im not really sure what it does or if I even need it...
>>>> (someone started the program and it was in there when I got it)
>>>>
>>>> //** below is RPG code that is making the call **//
>>>>
>>>> HTTP_SETCCSIDS ( 1208: 0);
>>>>
>>>> //'Call service to check address
>>>> returnCode = HTTP_URL_POST_XML
>>>> ( %trim(POSTLINK)
>>>> : %addr(soapParms) + 2
>>>> : %len(soapParms)
>>>> : *null
>>>> : %paddr(response)
>>>> : %addr(returnUserData)
>>>> : HTTP_TIMEOUT
>>>> : HTTP_USERAGENT
>>>> : 'text/xml; charset=utf-8'
>>>> : %trim(ACTIONLINK)
>>>> );
>>>>
>>>> if (returnCode <> 1);
>>>> outError = 'Validation Call Failed';
>>>> endif;
>>>> //** end RPG code that is making the call **//
>>>>
>>>>
>>> --------------------------------------------------------------------
>>> -
>>> -
>>> - This is the FTPAPI mailing list. To unsubscribe, please go to:
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.scottklement.
>>> c
>>> om_mailman_listinfo_ftpapi&d=CwIF-g&c=rxuyg758I4Zd3CDHNny_Hw&r=JkfuZ
>>> 4
>>> E
>>> 665mlFfpIfGYhkELl0BTRh7r_Gm0xUf-MqYc&m=JwWl0MErlXxRxXTt91ybq7HSdHmCQ
>>> R
>>> - KoiEe3mjB4gY&s=kqjXKsptSkcVv9bZp_7FwyWVrT6q9GeIl8YpGbDycVE&e=
>>> --------------------------------------------------------------------
>>> -
>>> -
>>> -
>>> --------------------------------------------------------------------
>>> -
>>> -
>>> - This is the FTPAPI mailing list. To unsubscribe, please go to:
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.scottklement.
>>> c
>>> om_mailman_listinfo_ftpapi&d=CwICAg&c=rxuyg758I4Zd3CDHNny_Hw&r=JkfuZ
>>> 4
>>> E
>>> 665mlFfpIfGYhkELl0BTRh7r_Gm0xUf-MqYc&m=bYC1AHVFwN-aCe00qOW-lM4f3p8Gv
>>> W W K0DljtsChZGo&s=wemwSnW4VpfHXMkUmL_15w1XbOROGJRWi963Acp6Jl8&e=
>>> --------------------------------------------------------------------
>>> -
>>> -
>>> -
>>>
>> ---------------------------------------------------------------------
>> -
>> - This is the FTPAPI mailing list. To unsubscribe, please go to:
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.scottklement.
>> c
>> om_mailman_listinfo_ftpapi&d=CwICAg&c=rxuyg758I4Zd3CDHNny_Hw&r=JkfuZ4
>> E
>> 665mlFfpIfGYhkELl0BTRh7r_Gm0xUf-MqYc&m=bYC1AHVFwN-aCe00qOW-lM4f3p8GvW
>> W K0DljtsChZGo&s=wemwSnW4VpfHXMkUmL_15w1XbOROGJRWi963Acp6Jl8&e=
>> ---------------------------------------------------------------------
>> -
>> -
>> ---------------------------------------------------------------------
>> -
>> - 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
-----------------------------------------------------------------------