Re: Apache server returns early before process is complete
Joseph He <[email protected]> Tue, 13 May 2025 13:27:34 -0500
| Newsgroups | gmane.comp.apache.mod-perl |
|---|---|
| Message-ID | <CAD16sHt_4d0PqzkG3TEKCzmaw0xkowqxhm6bMyM9FoB8UwZYMQ@mail.gmail.com> |
--000000000000cc94590635089661 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Andreas, I add sleep 300 to the server code to simulate the stall SFTP and I set the server Timeout to be 150. Then I run curl command with different timeout 25, 50, 100, 150, 200, 250, the curl command always timeout accordingly. The behavior of curl is exactly the same as that of changing LWP::UserAgent timeout, which verifies the timeout option on the client side indeed works as desired. But no matter how I treak the server side Apache config, it just does not do anything. Cheers, Joe On Tue, May 13, 2025 at 10:49=E2=80=AFAM Andreas Mock <[email protected]>= wrote: > Hallo Joe, > > try to reduce the problem. > > Make the call to your SFTP-Service via curl or some other http(s) client > to see whether you get the same timeout. If yes, than the server side is > closing the connection. If not then you have to investigate the > LWP::UserAgent part. > > Another hint in combination with SSL: > https://stackoverflow.com/questions/9400068/make-timeout-work-for-lwpuser= agent-https > > Best regards > Andreas > > > Am 13.05.2025 um 17:22 schrieb Joseph He: > > Andreas, thank you. > > On the client side, I set the timeout at LWP::UserAgent request to 600, > and I can verify that it indeed works on my QA and DEV environment. If I > change it to 120, then it can timeout at 120. > So on my production server, the client side receives a timeout from the > server after 5 minutes, so I still think the server Timeout plays a role > here. I just don't know what config I can change to test it out. > > Joe > > On Tue, May 13, 2025 at 10:07=E2=80=AFAM Andreas Mock <[email protected]= e> wrote: > >> Hi Joe, >> >> when you send a request via LWP::UserAgent to the Server which does the >> long lasting SFTP calls, then I'm pretty sure that you get a timout in t= he >> LWP::UserAgent code. >> >> I'm pretty sure the client (LWP::UserAgent) is not waiting long enough >> for the answer: https://metacpan.org/pod/LWP::UserAgent#timeout >> >> After having here a long timeout you have to be sure that the very first >> client which sent the very first request also waits long enough to let t= he >> application server make severals tries, therefore n * timeout. >> >> Best wishes >> Andreas >> >> >> Am 13.05.2025 um 16:46 schrieb Joseph He: >> >> Many thanks to you all. >> >> I am still trying to figure out the issue. Let me re-explain the problem >> I experienced with some details. >> >> The environment is Ubuntu 22.04, Apache2, ModPerl. >> I run a Http::request with LWP::UserAgent, the server receives the >> request and starts to process it. >> But it takes much longer due to a stalled SFTP call to the remote server= , >> the Apache server timeout and sends back failure, meanwhile,* the server >> actually is still trying to process this request*. >> On the calling side, after receiving the failure status, it initiates >> another http::request and the load balancer redirects this call to anoth= er >> server for processing. >> It turns out this same http::request is processed twice. >> >> On my production server the timeout happens at 300 seconds mark. On my Q= A >> and Dev server, the timeout happens at 600 seconds. I have not changed >> anything on my production server yet. >> But on my QA and DEV servers, I have tried to change Timeout in >> apache2.conf, have tried to add Timeout to the virtualhost config, also >> have tried to add SetPerlEnv MOD_PERL_TIMEOUT to the virtualhost config, >> none of them change the timeout behavior of my QA and DEV servers. >> >> So what exactly controls the Timeout? I am totally lost. >> >> Cheers, >> Joe >> >> >> On Wed, Apr 23, 2025 at 5:17=E2=80=AFPM Mithun Bhattacharya <mithnb@gmai= l.com> >> wrote: >> >>> Okay agreed that is a valid time out basically it is saying that a >>> client has established tcp/ip connection but has not put its request ei= ther >>> a get put or a post >>> >>> On Wed, Apr 23, 2025, 3:38=E2=80=AFPM Joseph He <[email protected]= om> >>> wrote: >>> >>>> On Apache2 doc, I found this. How does this timeout work? It looks lik= e >>>> it can only wait for 300 seconds before failing a request. >>>> >>>> https://httpd.apache.org/docs/2.0/mod/core.html#timeout >>>> Description: >>>> <https://httpd.apache.org/docs/2.0/mod/directive-dict.html#Description= > Amount >>>> of time the server will wait for certain events before failing a reque= st >>>> Syntax: >>>> <https://httpd.apache.org/docs/2.0/mod/directive-dict.html#Syntax> >>>> TimeOut seconds >>>> Default: >>>> <https://httpd.apache.org/docs/2.0/mod/directive-dict.html#Default> Ti= meOut >>>> 300 >>>> Context: >>>> <https://httpd.apache.org/docs/2.0/mod/directive-dict.html#Context> se= rver >>>> config, virtual host >>>> Status: >>>> <https://httpd.apache.org/docs/2.0/mod/directive-dict.html#Status> Cor= e >>>> Module: >>>> <https://httpd.apache.org/docs/2.0/mod/directive-dict.html#Module> cor= e >>>> >>>> The TimeOut directive currently defines the amount of time Apache will >>>> wait for three things: >>>> >>>> 1. The total amount of time it takes to receive a GET request. >>>> 2. The amount of time between receipt of TCP packets on a POST or >>>> PUT request. >>>> 3. The amount of time between ACKs on transmissions of TCP packets >>>> in responses. >>>> >>>> We plan on making these separately configurable at some point down the >>>> road. The timer used to default to 1200 before 1.2, but has been lower= ed to >>>> 300 which is still far more than necessary in most situations. It is n= ot >>>> set any lower by default because there may still be odd places in the = code >>>> where the timer is not reset when a packet is sent. >>>> >>>> On Wed, Apr 23, 2025 at 3:07=E2=80=AFPM Mithun Bhattacharya <mithnb@gm= ail.com> >>>> wrote: >>>> >>>>> You configure timeout at the client side. Apache is at the server >>>>> side. Server doesn't have a concept of time it could take days to run= and >>>>> not care. >>>>> >>>>> mod_perl code is where you are sending the http return status to make >>>>> sure the client doesn't timeout waiting for the server to respond. >>>>> >>>>> On Wed, Apr 23, 2025, 2:19=E2=80=AFPM Joseph He <joseph.he.2008@gmail= .com> >>>>> wrote: >>>>> >>>>>> Thanks, all. >>>>>> Is that Apache timeout controlled by its configuration "Timeout"? >>>>>> I don't think it has anything to do with modPerl. Am I missing >>>>>> something? >>>>>> Thanks. >>>>>> >>>>>> On Wed, Apr 23, 2025 at 1:41=E2=80=AFPM Mithun Bhattacharya <mithnb@= gmail.com> >>>>>> wrote: >>>>>> >>>>>>> Timeout happens because of how we handle the request. Timeout is >>>>>>> basically no response came back. Why that happens is because we thi= nk we >>>>>>> want to have a correct response. Unfortunately for long running req= uests >>>>>>> the correct response shouldn't be via http response code or we face >>>>>>> situations like this. Instead reply with a 200 OK immediately and t= hen >>>>>>> provide correct status in the message body. Once a response code/he= ader has >>>>>>> been sent timeout won't trigger and you could potentially hold the >>>>>>> connection for hours without a problem. >>>>>>> >>>>>>> On Wed, Apr 23, 2025, 9:32=E2=80=AFAM Andreas Mock <andreas.mock@we= b.de> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Joseph, >>>>>>>> >>>>>>>> your description is very vague, so can only answer on some >>>>>>>> assumptions: >>>>>>>> >>>>>>>> It sounds like a timeout is fired somewhere. >>>>>>>> >>>>>>>> Best advice in these situations: Log as many steps as you can. Kee= p >>>>>>>> your >>>>>>>> eyes open on TCP/IP and higher level timeouts. >>>>>>>> >>>>>>>> Declare only ONE instance responsible for a retry: Either the app >>>>>>>> server >>>>>>>> calling the dispatcher with several tries or the dispatcher trying >>>>>>>> for >>>>>>>> himself. Not both. >>>>>>>> >>>>>>>> Best regards >>>>>>>> Andreas >>>>>>>> >>>>>>>> >>>>>>>> Am 23.04.2025 um 16:21 schrieb Joseph He: >>>>>>>> > All, good day. >>>>>>>> > >>>>>>>> > Here is the issue I have. >>>>>>>> > My entire application is running on ModPerl/Apache environment. >>>>>>>> > I send Http::Request with data load from my App server to a >>>>>>>> dispatch >>>>>>>> > server thru LWP::UserAgent, I set the timeout 600 seconds. >>>>>>>> > >>>>>>>> > The dispatch server is supposed to manipulate the data and send >>>>>>>> the >>>>>>>> > data to an external SFTP server. Because the SFTP can fail, it >>>>>>>> will >>>>>>>> > keep trying up to 4 times with 30 seconds sleep in case that SFT= P >>>>>>>> > connection fails. >>>>>>>> > >>>>>>>> > Recently, I found that I uploaded the file twice sometimes. I >>>>>>>> figured >>>>>>>> > out the root cause is that my Dispatch server returns 'failure' >>>>>>>> at 6 >>>>>>>> > minutes while it keeps trying to do the SFTP. The App server >>>>>>>> > received HTTP::Response with error status so it issued another >>>>>>>> call to >>>>>>>> > send data. It turns out I uploaded the identified file twice. >>>>>>>> > >>>>>>>> > Anybody has this sort of experience? Why does the dispatch serve= r >>>>>>>> > return 'error' while it still processes the data? >>>>>>>> > >>>>>>>> > Thanks a lot, >>>>>>>> > Joseph >>>>>>>> > >>>>>>>> >>>>>>> --000000000000cc94590635089661 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Andreas,<div><br><div>I add sleep 300 to the server code t= o simulate the stall SFTP and I set the server Timeout to be 150.=C2=A0</di= v><div>Then I run curl command with different timeout 25, 50, 100, 150, 200= , 250, the curl command always timeout accordingly. The behavior of curl is= exactly the same as that of changing LWP::UserAgent timeout, which verifie= s the timeout option on the client side indeed works as desired.</div><div>= But no matter how I treak=C2=A0the server side Apache config, it just does = not do anything.</div></div><div><br></div><div>Cheers,</div><div>Joe</div>= </div><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr"= class=3D"gmail_attr">On Tue, May 13, 2025 at 10:49=E2=80=AFAM Andreas Mock= <<a href=3D"mailto:[email protected]">[email protected]</a>> wro= te:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px = 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u> =20 =20 =20 <div> <p>Hallo Joe,</p> <p>try to reduce the problem.</p> <p>Make the call to your SFTP-Service via curl or some other http(s) client to see whether you get the same timeout. If yes, than the server side is closing the connection. If not then you have to investigate the LWP::UserAgent part.</p> <p>Another hint in combination with SSL: <a href=3D"https://stackoverflow.com/questions/9400068/make-timeout-work-fo= r-lwpuseragent-https" target=3D"_blank">https://stackoverflow.com/questions= /9400068/make-timeout-work-for-lwpuseragent-https</a></p> <p>Best regards<br> Andreas</p> <p><br> </p> <div>Am 13.05.2025 um 17:22 schrieb Joseph He:<br> </div> <blockquote type=3D"cite"> =20 <div dir=3D"ltr">Andreas, thank you. <div><br> <div>On the client side, I set the timeout at LWP::UserAgent request to 600, and I can verify that it indeed works on my QA and DEV environment. If I change=C2=A0it to 120, then it can timeout at 120.</div> <div>So on my production=C2=A0server, the client=C2=A0side receiv= es a timeout from the server after 5 minutes, so I still think the server Timeout plays a role here. I just don't know wha= t config I can change to test it out.</div> <div><br> </div> <div>Joe</div> </div> </div> <br> <div class=3D"gmail_quote"> <div dir=3D"ltr" class=3D"gmail_attr">On Tue, May 13, 2025 at 10:07=E2=80=AFAM Andreas Mock <<a href=3D"mailto:andreas.mock@= web.de" target=3D"_blank">[email protected]</a>> wrote:<br> </div> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex= ;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div> <p>Hi Joe,</p> <p>when you send a request via LWP::UserAgent to the Server which does the long lasting SFTP calls, then I'm pretty sure that you get a timout in the LWP::UserAgent code.</p> <p>I'm pretty sure the client (LWP::UserAgent) is not waiting long enough for the answer: <a href=3D"https://metacp= an.org/pod/LWP::UserAgent#timeout" target=3D"_blank">https://metacpan.org/p= od/LWP::UserAgent#timeout</a></p> <p>After having here a long timeout you have to be sure that the very first client which sent the very first request also waits long enough to let the application server make severals tries, therefore n * timeout.</p> <p>Best wishes<br> Andreas</p> <p><br> </p> <div>Am 13.05.2025 um 16:46 schrieb Joseph He:<br> </div> <blockquote type=3D"cite"> <div dir=3D"ltr">Many thanks to you all. <div><br> <div>I am still trying to figure out the issue. Let me re-explain the problem I experienced with some details.</div> <div><br> The environment is=C2=A0Ubuntu 22.04, Apache2,=C2=A0Mod= Perl.<br> I run a Http::request with LWP::UserAgent, the server receives the request and starts to process it.</div> <div>But it takes much longer due=C2=A0to a stalled SFTP call to the remote server, the Apache server timeout and sends back failure, meanwhile,<b> the server actually=C2=A0is still trying to process this request= </b>.<br> On the calling side, after receiving the failure status, it initiates another http::request=C2=A0and the load balancer redirects this call to another server for processing.=C2=A0</div> <div>It turns out this same http::request is processed twice.</div> <div><br> </div> <div>On my production=C2=A0server the timeout happens at 300 seconds mark. On my QA and Dev server, the timeout happens at 600 seconds. I have not changed anything on my production server yet.=C2=A0</div> <div>But on my QA and DEV servers, I have tried to change Timeout in apache2.conf, have tried to add Timeout to the virtualhost config, also have tried to add SetPerlEnv MOD_PERL_TIMEOUT to the virtualhost config, none of them change the timeout behavior of my QA and DEV servers.<br> <br> So what exactly controls the Timeout? I am totally lost.</div> <div><br> </div> <div>Cheers,</div> <div>Joe=C2=A0</div> <div><br> </div> </div> </div> <br> <div class=3D"gmail_quote"> <div dir=3D"ltr" class=3D"gmail_attr">On Wed, Apr 23, 2025 at 5:17=E2=80=AFPM Mithun Bhattacharya <<a href=3D"mai= lto:[email protected]" target=3D"_blank">[email protected]</a>> wrote:<br> </div> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0= px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir=3D"auto">Okay agreed that is a valid time out basically it is saying that a client has established tcp/ip connection but has not put its request either a get put or a post</div> <br> <div class=3D"gmail_quote"> <div dir=3D"ltr" class=3D"gmail_attr">On Wed, Apr 23, 2025, 3:38=E2=80=AFPM Joseph He <<a href=3D"mailto= :[email protected]" target=3D"_blank">[email protected]</a>&g= t; wrote:<br> </div> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0= px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir=3D"ltr">On Apache2 doc, I found this. How does this timeout work? It looks like it can only wait for 300 seconds before failing a request.=C2=A0 <div><br> </div> <div><a href=3D"https://httpd.apache.org/docs/2.0/m= od/core.html#timeout" rel=3D"noreferrer" target=3D"_blank">https://httpd.ap= ache.org/docs/2.0/mod/core.html#timeout</a><br> <div> <table style=3D"font-size:14px;border:1px solid= rgb(170,170,170);border-collapse:collapse;padding:2px;margin-top:0.5em;mar= gin-bottom:1em;color:rgb(0,51,102)"> <tbody> <tr> <th style=3D"empty-cells:show;padding:0.1= em 0.2em;vertical-align:top;text-align:left;line-height:1.3em"><a href=3D"h= ttps://httpd.apache.org/docs/2.0/mod/directive-dict.html#Description" style= =3D"color:rgb(0,115,199);background-color:inherit" rel=3D"noreferrer" targe= t=3D"_blank">Description:</a></th> <td style=3D"empty-cells:show;padding:0.1= em 0.2em;vertical-align:top;line-height:1.3em">Amount of time the server will wait for certain events before failing a request</td> </tr> <tr> <th style=3D"empty-cells:show;padding:0.1= em 0.2em;vertical-align:top;text-align:left;line-height:1.3em"><a href=3D"h= ttps://httpd.apache.org/docs/2.0/mod/directive-dict.html#Syntax" style=3D"c= olor:rgb(0,115,199);background-color:inherit" rel=3D"noreferrer" target=3D"= _blank">Syntax:</a></th> <td style=3D"empty-cells:show;padding:0.1= em 0.2em;vertical-align:top;line-height:1.3em"><code style=3D"font-family:&= quot;Courier New",Courier,monospace;font-size:1em">TimeOut=C2=A0<var>s= econds</var></code></td> </tr> <tr> <th style=3D"empty-cells:show;padding:0.1= em 0.2em;vertical-align:top;text-align:left;line-height:1.3em"><a href=3D"h= ttps://httpd.apache.org/docs/2.0/mod/directive-dict.html#Default" style=3D"= color:rgb(0,115,199);background-color:inherit" rel=3D"noreferrer" target=3D= "_blank">Default:</a></th> <td style=3D"empty-cells:show;padding:0.1= em 0.2em;vertical-align:top;line-height:1.3em"><code style=3D"font-family:&= quot;Courier New",Courier,monospace;font-size:1em">TimeOut 300</code></td> </tr> <tr> <th style=3D"empty-cells:show;padding:0.1= em 0.2em;vertical-align:top;text-align:left;line-height:1.3em"><a href=3D"h= ttps://httpd.apache.org/docs/2.0/mod/directive-dict.html#Context" style=3D"= color:rgb(0,115,199);background-color:inherit" rel=3D"noreferrer" target=3D= "_blank">Context:</a></th> <td style=3D"empty-cells:show;padding:0.1= em 0.2em;vertical-align:top;line-height:1.3em">server config, virtual host</td> </tr> <tr> <th style=3D"empty-cells:show;padding:0.1= em 0.2em;vertical-align:top;text-align:left;line-height:1.3em"><a href=3D"h= ttps://httpd.apache.org/docs/2.0/mod/directive-dict.html#Status" style=3D"c= olor:rgb(0,115,199);background-color:inherit" rel=3D"noreferrer" target=3D"= _blank">Status:</a></th> <td style=3D"empty-cells:show;padding:0.1= em 0.2em;vertical-align:top;line-height:1.3em">Core</td> </tr> <tr> <th style=3D"empty-cells:show;padding:0.1= em 0.2em;vertical-align:top;text-align:left;line-height:1.3em"><a href=3D"h= ttps://httpd.apache.org/docs/2.0/mod/directive-dict.html#Module" style=3D"c= olor:rgb(0,115,199);background-color:inherit" rel=3D"noreferrer" target=3D"= _blank">Module:</a></th> <td style=3D"empty-cells:show;padding:0.1= em 0.2em;vertical-align:top;line-height:1.3em">core</td> </tr> </tbody> </table> <p style=3D"line-height:1.3em;margin:0px 0px 1e= m;padding:0px;color:rgb(0,51,102);font-size:14px">The=C2=A0<code style=3D"f= ont-family:"Courier New",Courier,monospace;font-size:1em;color:rg= b(40,127,0);background-color:inherit">TimeOut</code>=C2=A0directive currently defines the amount of time Apache will wait for three things:</p> <ol style=3D"color:rgb(0,51,102);font-size:14px= "> <li style=3D"line-height:1.3em;margin-top:0.5= em">The total amount of time it takes to receive a GET request.</li> <li style=3D"line-height:1.3em;margin-top:0.5= em">The amount of time between receipt of TCP packets on a POST or PUT request.</li> <li style=3D"line-height:1.3em;margin-top:0.5= em">The amount of time between ACKs on transmissions of TCP packets in responses.</li> </ol> <p style=3D"line-height:1.3em;margin:0px 0px 1e= m;padding:0px;color:rgb(0,51,102);font-size:14px">We plan on making these separately configurable at some point down the road. The timer used to default to 1200 before 1.2, but has been lowered to 300 which is still far more than necessary in most situations. It is not set any lower by default because there may still be odd places in the code where the timer is not reset when a packet is sent.</p> </div> </div> </div> <br> <div class=3D"gmail_quote"> <div dir=3D"ltr" class=3D"gmail_attr">On Wed, Apr 23, 2025 at 3:07=E2=80=AFPM Mithun Bhattacharya &= lt;<a href=3D"mailto:[email protected]" rel=3D"noreferrer" target=3D"_blank"= >[email protected]</a>> wrote:<br> </div> <blockquote class=3D"gmail_quote" style=3D"margin:0= px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir=3D"auto"> <p dir=3D"ltr">You configure timeout at the client side. Apache is at the server side. Server doesn't have a concept of time it could take days to run and not care.</p> <p dir=3D"ltr">mod_perl code is where you are sending the http return status to make sure the client doesn't timeout waiting for the server to respond.</p> </div> <br> <div class=3D"gmail_quote"> <div dir=3D"ltr" class=3D"gmail_attr">On Wed, Apr 23, 2025, 2:19=E2=80=AFPM Joseph He <<= a href=3D"mailto:[email protected]" rel=3D"noreferrer" target=3D"_bl= ank">[email protected]</a>> wrote:<br> </div> <blockquote class=3D"gmail_quote" style=3D"marg= in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e= x"> <div dir=3D"ltr">Thanks, all. <div>Is that Apache timeout controlled by its configuration=C2=A0"Timeout&q= uot;?=C2=A0</div> <div>I don't think it has anything to d= o with modPerl. Am I=C2=A0missing something= ?</div> <div>Thanks.</div> </div> <br> <div class=3D"gmail_quote"> <div dir=3D"ltr" class=3D"gmail_attr">On Wed, Apr 23, 2025 at 1:41=E2=80=AFPM Mith= un Bhattacharya <<a href=3D"mailto:mithnb= @gmail.com" rel=3D"noreferrer noreferrer" target=3D"_blank">[email protected]= m</a>> wrote:<br> </div> <blockquote class=3D"gmail_quote" style=3D"= margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef= t:1ex"> <div dir=3D"auto">Timeout happens because of how we handle the request. Timeout is basically no response came back. Why that happens is because we think we want to have a correct response. Unfortunately for long running requests the correct response shouldn't be via http response code or we face situations like this. Instead reply with a 200 OK immediately and then provide correct status in the message body. Once a response code/header has been sent timeout won't trigger and you could potentially hold the connection for hours without a problem.</div> <br> <div class=3D"gmail_quote"> <div dir=3D"ltr" class=3D"gmail_attr">O= n Wed, Apr 23, 2025, 9:32=E2=80=AFAM An= dreas Mock <<a href=3D"mailto:andreas.mo= [email protected]" rel=3D"noreferrer noreferrer" target=3D"_blank">andreas.mock@web= .de</a>> wrote:<br> </div> <blockquote class=3D"gmail_quote" style= =3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding= -left:1ex">Hi Joseph,<br> <br> your description is very vague, so can only answer on some assumptions:<br> <br> It sounds like a timeout is fired somewhere.<br> <br> Best advice in these situations: Log as many steps as you can. Keep your <br> eyes open on TCP/IP and higher level timeouts.<br> <br> Declare only ONE instance responsible for a retry: Either the app server <br> calling the dispatcher with several tries or the dispatcher trying for <br> himself. Not both.<br> <br> Best regards<br> Andreas<br> <br> <br> Am 23.04.2025 um 16:21 schrieb Joseph He:<br> > All, good day.<br> ><br> > Here is the issue I have.<br> > My entire application is running on ModPerl/Apache environment.<br> > I send Http::Request with data load from my App server to a dispatch <br> > server thru LWP::UserAgent, I set the timeout 600 seconds.<br> ><br> > The dispatch server is supposed to manipulate the data and send the <br> > data to an external SFTP server. Because the SFTP can fail, it will <br> > keep trying up to 4 times with 30 seconds sleep in case that SFTP <br> > connection fails.<br> ><br> > Recently, I found that I uploaded the file twice sometimes. I figured <br> > out the root cause is that my Dispatch server returns 'failure&= #39; at 6 <br> > minutes while it keeps trying to do the SFTP. The App server <br> > received=C2=A0HTTP::Response wit= h error status so it issued another call to <br> > send data. It turns out I uploaded the identified file twice.<br> ><br> > Anybody has this sort of experience? Why does the dispatch=C2=A0server <br> > return 'error' while it = still processes the data?<br> ><br> > Thanks a lot,<br> > Joseph<br> ><br> </blockquote> </div> </blockquote> </div> </blockquote> </div> </blockquote> </div> </blockquote> </div> </blockquote> </div> </blockquote> </div> </blockquote> </div> </blockquote> </div> </blockquote></div> --000000000000cc94590635089661--