Borland Delphi 7 Studio Enterprise delivers new, fully integrated technologies for increased developer productivity. Get your applications ready for the path to the Microsoft.NET Framework with the Delphi 7 Studio Migration Kit for.NET.
No review
Indy for Delphi is a Shareware software in the category Miscellaneous developed by Atozed Software. The latest version of Indy for Delphi is 10.0, released on. It was initially added to our database on. Indy for Delphi runs on the following operating systems: Windows. Indy for Delphi has not been rated by our users yet. Compiled Indy Packages for Delphi (Delphi 7 - Rad Studio 10.4).
No VideoPlease select a download mirror:External Mirror 1External Mirror 2Borland Delphi™ Studio Enterprise provides an advanced programming environment for development of Windows applications, featuring new technologies for increased efficiency and productivity. Delphi Enterprise delivers all the tools necessary...full software details
If you encounter any problems in accessing the download mirrors for Delphi 7 Enterprise, please check your firewall settings or close your download manager.
Delphi 7 Enterprise is offered as a free download
Faster PC? Get Advanced SystemCare and optimize your PC.
Download Delphi 7 Free
| Subject: | Re: idHTTP problems (Indy 10 and Delphi 7 Ent) |
| Posted by: | Peter Maddin (petermadd…@aapt.net.au) |
| Date: | Thu, 08 Mar 2007 |
Remy Lebeau (Indy Team) wrote:
> 'Peter Maddin' <petermadd…@aapt.net.au> wrote in message
> news:611CFA92901DE340petermadd…@aapt.net.au...
>
>> I can no longer use the component to do additional gets.
>> I get an exception.
>
> Please be more specific. What does your code look like? What
> exception is being raised exactly?
I have modifed my code so that it instantiates a idHTTP object before it
uses it and then frees it when completed. To replicate the problem I
would have to back out all my code changes.
The logic is thus
Check that the server is working (use a get to obtain a simple web page)
Get a list of files to download (using a get with the files returned in
a web page)
For each file
download it (using a get)
acknowledge the download by creating, closing and then posting a small
file
delete the downloaded server file via a get command
delete the local acknowlegment file previously posted
>
>> Also once I post a file to the server, it remains open and I
>> cannot delete the local file just uploaded.
>
> Are you freeing the TIdMultiPartFormDataStream? The file is not
> released until the cooresponding TIdFormDataField in the
> TIdMultipartFormDataStream.FFields collection is freed.
I am freeing the TIdMultiPartFormDataStream.
My logic is similar to this (I do use try try except finally but I did
not repeat it here to avoid code bloat)
Data := TIdMultiPartFormDataStream.Create;
// set up the multipart data stream to post
Data.AddFormField('Account',dmHttpTransport.Account);
.. other form fields as required
// Add the generated file to upload
Data.AddFile('FILE',LocalFile,'text/xml');
// Post the file to the server, WebUpload is a TidHTTP.
// dmHttpTransport.UploadConnection is a string with the complete URL
dmHttpTransport.WebBuffer :=
dmHttpTransport.WebUpload.post(dmHttpTransport.UploadConnection,Data);
// processes the returned web page to make sure it was uploaded ok
// Code for WebUploadTransferOk simply parses the string
// dmHttpTransport.WebBuffer
if dmHttpTransport.WebUploadTransferOk then Result := True;
// do something with idHTTP so I can delete the uploaded file but ????
dmHttpTransport.WebUpload.Disconnect; // Does not enable me to delete
my local file - Grrrrr
Data.Free;
After sucessfully uploading the file via the above code, then doing a
get to delete to delete the file on the server I do FileDelete on the
local file.
If the return is false (it failed) I wait 500 milliseconds and try
again. After 5 attempts I give up that is 2 and 1/2 seconds which is
pretty long.
By freeing the idHttp instance the problem is fixed.
>
>> From experimenting, if I use post to upload another file, I
>> can then delete the previous local file.
>
> Again, please show your actual code.
>
>> Is there a way to force idHTTP to close the file.
>
> Free the stream after posting it.
Done but the problem persisted until I freed the WebUpload (idHTTP) object.
>
>> Also I have a problem with using a get to trigger a file delete
>> on the IIS server. The server gets two get requests to delete
>> the file. One of which suceeds and the other fails. I cannot see
>> how this occurs.
>
> The only way would be if the server is sending a redirect reply back
> for the first request, or if authorization was needed. Use a packet
> sniffer, such as Ethereal, to verify that.
>
A good idea.
Ok I have used Ethereal to diagnose a problem with ftp and checkpoint1
where the firewall was dropping packets after data port re-negotiation.
The application just hung. Not even a timeout returned. MS's cmd line
FTP untility also hung. This usually only occurred after several hundred
or more get requests.
Re-instantitaing the idHTTP object before doing every get or post
appears to have fixed the problem.
If it re-occurs I will certainly use it again.
>> I am considering creating an instance of IdHTTP just prior to each
> get
>> or post and freeing that instance after it has completed its task or
> an
>> exception has occured. This might well fix the most recently
> uploaded
>> file remaining open
>
> TIdHTTP has nothing to do with the openness of the files being
> uploaded. That is all inside of TIdMultipartFormDataStream only.
It has fixed the problem. Freeing Data (IdMultiPartFormDataStream
object) did not close the file.
>
>> or getting two delete requests from what appears to be a single get
> call.
>
> Recreating the TIdHTTP object each time will not address that issue.
> The only time TIdHTTP sends multiple requests is when the server tells
> it to.
>
>> 1. Use get to check the server is alive (returns simple web page)
>> 2. Use get to return a list of files to be downloaded (returned as a
>> simple page)
>
> Why do step #1 at all? You could just download your list directly and
> check for any errors.
I do this because downloading is via 4 selectable protocols, ftp, http,
mapi and smtp/pop3. Each download option is suported by a different dll
that is dynamically loaded as run time. My dlls all export the same
functions. Step 1 mimics user authentiction even though its really a non
authenticated stateless connection.
>
>> Step 6 sometimes results in the get request being handled by
>> two instances of the isapi dll (logging within this dll writes out
>> the thread id of the isapi dll instance).
>
> Like I said, a packet sniffer will tell you why that is happening.
will do this if the problem recurs. It happens only very infrequently
and somewhat randomly i.e. for 400 waiting files after 300 have
downloaded. the next time I get 900 out of 900.
Since my most recent changes the problem has not re-occured.
I another interesting error a 501 responsefrom the server but my log is
self truncating and I lost it.
I have downloaded 2994 files in one session without a problem. It is a
bit slower than before but stablity is more important.
>
>> Step 7 A DeleteFile on the local acknowledgement file just posted
> fails
>> 100% of the time. Previously posted files can be deleted.
>
> You are probably not freeing the TIdMultipartFormDataStream before
> deleting the file, or are not giving the OS enough time to finish
> fully releasing the file.
>
I tried a DeleteFile which when it failed the application waited 500
milliseconds then tried again. I do this retry a total of five times
before it gives up.
To my way of thinking 6 attempts with 500 milliseconds should be enough.
(possibly not).
Any the problem seems to have gone away now.
Thanks very much for your detailed recommendations.
Delphi Indy Examples
> Gambit
Replies
- Re: idHTTP problems (Indy 10 and Delphi 7 Ent) posted by Remy Lebeau (Indy Team) on Thu, 8 Mar 2007
In response to
Delphi 10 Download
Re: idHTTP problems (Indy 10 and Delphi 7 Ent) posted by Remy Lebeau (Indy Team) on Wed, 7 Mar 2007
Indy 10 Delphi Download
Newsgroups.Archived.At is © Copyright 2009-2021, A B Cryer, All Rights Reserved.