[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: http_url_post_stmf question
Hi Michael,
All of HTTPAPI's routines should time-out after a period of (by default)
60 seconds of stalled activity. It should never hang on a function for
hours, unless you're performing a file upload/download that actually
takes hours to complete.
Though, I suppose if you're having network issues, and it's constantly
re-sending the data to recover from errors, it could remain active for a
long time without ever completing...
Whether the site has or doesn't have an XSD is not relevant. HTTPAPI
won't "hang" on a bad XML document. Indeed, the function you're
running, http_url_post_stmf() doesn't have any concept of XML
whatsoever, it's just downloading a string of bytes. IT doesn't know or
care what those bytes mean, or whether they are an XML document. They
could be a SAVF, MP3, JPEG, HTML document or any other conceivable type
of data, and it wouldn't matter even a little bit to HTML. SO I can't
imagine this is related to an XML schema.
But, all I can do is take random stabs in the dark, since I really don't
have any information on what's happening. All I know is that it got
stuck for hours. I don't have any data whatsoever about WHY it got stuck.
But, in any case, this should not happen. No matter what you do to the
server. There's a bug somewhere in HTTPAPI.
Please make sure you're using the current version. I cannot help you
otherwise. Unless you've modified it, upgrading HTTPAPI is easy and a
completely painless process. You don't even have to recompile or rebind
your existing programs, just replace the HTTPAPI objects and they'll
continue to work as before. Completely painless.
and if you can reproduce the problem, please reproduce it with a debug
log and send it to me so I have in-depth information about what's
happening...
Michael wrote:
> Scott-
> Thanks for getting back to me so quickly. First off, no I am using an
> old version. I think it is 1.17. But I don't think I explained the
> situation right, because http_url_post_stmf() isn't returning. The job
> just stays on that function for hours. Now as I said before this has
> only happened once since this new process installed last week. I blame
> the https server we connect to, as they are running an XML process w/o
> an XSD. I assume the socket remains open until it receives connection
> close. Of course I believe the one job that failed sent a lot of data,
> maybe 30MB or more.
> Michael
> --- On Tue, 4/7/09, Scott Klement <sk@xxxxxxxxxxxxxxxx> wrote:
>
> From: Scott Klement <sk@xxxxxxxxxxxxxxxx>
> Subject: Re: http_url_post_stmf question
> To: "HTTPAPI and FTPAPI Projects" <ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
> Date: Tuesday, April 7, 2009, 5:28 PM
>
> Hi Michael,
> It doesn't matter if the remote server "releases" the connection.
> HTTPAPI should disconnect the connection on every call to
> http_url_post_stmf(). If you have connections that are stuck in
> "Established" mode on the client side (the HTTPAPI side) of the
> connection, and you're not calling the http_persist_xxx routines, then
> it'd have to be caused by a bug/problem in HTTPAPI.
> The server does not have the ability to prevent HTTPAPI from
> disconnecting.
> Make sure you're using the current version of HTTPAPI.
> If you are, please send a debug log.
> Michael wrote:
> > I have an application that works really well, API of course does
> most
> > of the work. But every once in a while the remote server does not
> > release the connection, it stays in an "Established" mode, even
> though
> > they claim they have disconnected. I assume the logic that waits
> on
> > the socket is deep in the COMM *MODULE and so I don't want to
> change
> > it. Does anyone have any suggestions on this? Is there another
> > function or option to handle lazy remote servers?
> >
> >
> >
> >
> ----------------------------------------------------------------------
> --
> >
> >
> ----------------------------------------------------------------------
> -
> > This is the FTPAPI mailing list. To unsubscribe, please go to:
> > [1]http://www.scottklement.com/mailman/listinfo/ftpapi
> >
> ----------------------------------------------------------------------
> -
> ----------------------------------------------------------------------
> -
> This is the FTPAPI mailing list. To unsubscribe, please go to:
> [2]http://www.scottklement.com/mailman/listinfo/ftpapi
> ----------------------------------------------------------------------
> -
>
> References
>
> 1. http://www.scottklement.com/mailman/listinfo/ftpapi
> 2. 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
-----------------------------------------------------------------------