I see, thank you Graham for the explanation.

Regards,
Ash

On Saturday, April 29, 2023 at 9:34:52 PM UTC-7 Graham Dumpleton wrote:

> Having to set these timeouts to be very large values is generally 
> indicative of a poor design.
>
> For these sorts of long running operations you are usually better of using 
> a background task queuing system like Celery to handle running of the job. 
> Your front end then just queues the job and polls to see if the task is 
> finished and get the response.
>
> In the worst case for these very long running requests a synchronous type 
> web system like WSGI may not be a good idea and you are better off using an 
> async web server.
>
> That all said, likely what is happening is that because Timeout is 300, 
> the Apache child process is giving up on waiting for a response from the 
> mod_wsgi daemon process before request-timeout could even kick in.
>
> You can try overriding socket-timeout option on WSGIDaemonProcess to a 
> larger value that 300 (inherited from Timeout), but as I said, using large 
> timeouts like this is generally not a good idea.
>
> Graham
>
> On 30 Apr 2023, at 2:27 pm, Aash <[email protected]> wrote:
>
> I never changed it. It shows 300. Should I make it to 600?
>
> On Saturday, April 29, 2023 at 9:21:15 PM UTC-7 Graham Dumpleton wrote:
>
>> What is the Timeout directive set to in your main Apache configuration?
>>
>> On 30 Apr 2023, at 2:18 pm, Aash <[email protected]> wrote:
>>
>> Hello Graham, Thanks for the quick response.
>>
>> The API response depends on how many items are sent in a batch so for a 
>> long list it can take a long time (It is taking a list of domains and 
>> returns a list). I am using the Python Requests library and requests.post 
>> to call the API. 
>> This error occurs only when there is a long list which might need a 
>> minute or two to get response from the API. The error occurs on all the 
>> requests that are having longer lists. 
>>
>> On Saturday, April 29, 2023 at 9:10:01 PM UTC-7 Graham Dumpleton wrote:
>>
>>> How long does it usually take for the remote API to respond? Does it 
>>> always respond quickly, or can it take a very long time? Does this error 
>>> occur on every request, or only after your web application has been running 
>>> for a while?
>>>
>>> On 30 Apr 2023, at 2:04 pm, Aash <[email protected]> wrote:
>>>
>>> I am trying to host my Flask app on a Linux server. My app connects to 
>>> an API and waits for a response. It is giving me this error.
>>>
>>> [Sun Apr 30 05:57:30.091150 2023] [wsgi:error] [pid 524703:tid 
>>> 140623501117184] [client *someIp*:62319] Timeout when reading response 
>>> headers from daemon process 'webApp': /var/www/webApp/webapp.wsgi, referer: 
>>> http://*serverIP*/
>>>
>>> My conf file looks like this:
>>>
>>>
>>>    1. <VirtualHost *:80>
>>>    2.     ServerName *serverIp*
>>>    3.     ServerAdmin [email protected]
>>>    4. 
>>>    5.     WSGIDaemonProcess webApp processes=4 threads=5 
>>>    maximum-requests=1000 request-timeout=600
>>>    6.     WSGIProcessGroup webApp
>>>    7. 
>>>    8.     WSGIScriptAlias / /var/www/webApp/webapp.wsgi 
>>>    process-group=webApp application-group=%{GLOBAL}
>>>    9. 
>>>    10.     <Directory /var/www/webApp/webApp/>
>>>    11.         Order allow,deny
>>>    12.         Allow from all
>>>    13.     </Directory>
>>>    14. 
>>>    15.     Alias /static /var/www/webApp/webApp/static
>>>    16.     <Directory /var/www/webApp/webApp/static/>
>>>    17.         Order allow,deny
>>>    18.         Allow from all
>>>    19.     </Directory>
>>>    20. 
>>>    21.     ErrorLog ${APACHE_LOG_DIR}/error.log
>>>    22.     LogLevel warn
>>>    23.     CustomLog ${APACHE_LOG_DIR}/access.log combined
>>>    24. </VirtualHost>
>>>
>>> The error on user-side is 
>>> *Gateway Timeout*
>>>
>>> *The gateway did not receive a timely response from the upstream server 
>>> or application.*
>>>
>>>
>>>
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "modwsgi" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to [email protected].
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/modwsgi/94c43590-df3c-4a93-8cd9-d2afb965a631n%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/modwsgi/94c43590-df3c-4a93-8cd9-d2afb965a631n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>>
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "modwsgi" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to [email protected].
>>
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/modwsgi/e0bccec9-53a2-41af-a9e5-edcb1229ef80n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/modwsgi/e0bccec9-53a2-41af-a9e5-edcb1229ef80n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>>
>>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "modwsgi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected].
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/modwsgi/a71d2462-ee92-465d-9b37-d07ed3cd603en%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/modwsgi/a71d2462-ee92-465d-9b37-d07ed3cd603en%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"modwsgi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/modwsgi/9e7aa0fb-82e0-437a-9610-e645f5f9590an%40googlegroups.com.

Reply via email to