[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Truncated replies.
Sender: e.klaasse@xxxxxxxx
Scott, hereby some more information.
With the previous mentioned changes the program still fail sometimes (much
less than before). When I force the program to wait 5 seconds before the
next time gsk_secure_soc_read runs (to get the next part) then the program
ends perfect in all situations. Ofcourse this is not the solution and i
hope you have some suggestions.
Eric
|---------+---------------------------->
| | e.klaasse@xxxxxxx|
| | l |
| | Verzonden door: |
| | owner-ftpapi@xxxx|
| | e.ods.net |
| | |
| | |
| | 08-09-2003 17:42 |
| | Antwoord a.u.b. |
| | aan ftpapi |
| | |
|---------+---------------------------->
>------------------------------------------------------------------------------------------------------------------------------|
| Aan: ftpapi@xxxxxxxxxxxxx |
| cc: |
|Onderwerp: Betr.: Re: |
>------------------------------------------------------------------------------------------------------------------------------|
Sender: e.klaasse@xxxxxxxx
Sorry Scott, due to personal business I was not able to react on your mail.
Meanwhile I continued debugging and found out that the receiving party
sends the reply (only 3,5kb) in 3 parts. After receiving the first part and
trying to get the next part the returncode of gsk_secure_soc_reade (in
procedure ssl_recvdoc) is 406 (GSK_ERROR_IO). If I ignore this returncode
as you did with GSK_WOULD_BLOCK then the program runs great.
I hope you can take a close look to that part of the serviceprogram.
Thanks in advance!
Eric
|---------+---------------------------->
| | Scott Klement |
| | <klemscot@xxxxxxx|
| | s.com> |
| | Verzonden door: |
| | owner-ftpapi@xxxx|
| | e.ods.net |
| | |
| | |
| | 27-08-2003 00:02 |
| | Antwoord a.u.b. |
| | aan ftpapi |
| | |
|---------+---------------------------->
>
------------------------------------------------------------------------------------------------------------------------------|
| Aan: ftpapi@xxxxxxxxxxxxx
|
| cc:
|
|Onderwerp: Re:
|
>
------------------------------------------------------------------------------------------------------------------------------|
Sender: Scott Klement <klemscot@xxxxxxxxxxxx>
I'm not having this problem, but it appears that at least Aaron is having
a similar problem.
So, the real question is, what can I do to solve it? Can you tell me
a way to reliably reproduce the problem? Or should I insert some
diagnostics into HTTPAPIR4, send you a copy, and hope that they can be
used to find the bug?
If nothing else, we could add diagnostics to determine where the problem
is happening in the HTTPAPIR4 code, to narrow things down.
What do you think?
On Tue, 26 Aug 2003 e.klaasse@xxxxxxxx wrote:
>
> I use http-url_post (SSL) for posting a xml-request (stock). The
receiver
> sends directly a reply with the current stock of the requested product.
> This xml-file (reply) is written to the IFS.
>
> When the AS/400 is very busy, something strange happens. The XML file on
> the IFS is truncated, so a part of the file is missing. It feels like a
> timeout, but the default of 300 seconds is used and the program ends
within
> 1 minute as if everything is ok. Under normal circumstances the xml-file
> will be received complete.
>
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubsribe from the list send mail
to majordomo@xxxxxxxxxxxxx with the body: unsubscribe ftpapi mymailaddr
-----------------------------------------------------------------------
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubsribe from the list send mail
to majordomo@xxxxxxxxxxxxx with the body: unsubscribe ftpapi mymailaddr
-----------------------------------------------------------------------
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubsribe from the list send mail
to majordomo@xxxxxxxxxxxxx with the body: unsubscribe ftpapi mymailaddr
-----------------------------------------------------------------------