0
I have an app in Laravel that runs with Docker inside an Azure VM in production. As a development environment, I use the same Docker structure locally, on an Ubuntu.
There is a feature that performs a POST through CURL to another server, passing an SQL as parameter for that server to perform the query in the database and return the response. Currently the answer is only the file path generated with the results of the query.
Problem: When running this CURL in production (Laravel + Docker + Azure), if the query in the database takes longer than 4min on average, the timeout that is defined at the time of CURL occurs, even if the REAL request (tested via Insmonia, or development environment) take less time than the timeout set.
Important remarks: 1. The problem occurs only in production (Laravel + Docker + Azure), running in the local development environment works. 2. Using any Rest client tool (Insomnia, Postman), it works normally. 3. Running a native URL (command line) works in the production environment. Ex:
curl --request POST \
--url http://ip:port/route \
--data '{"sql": "select 1 from dual"}'
- Running this native command line URL within a php "exec()" function in the production environment also works.
- The CURL library Guzzlehttp, version 6.x is being used
- Tested with native php Curl
curl()
also does not work in production
Comparison of executions of the same command
Production: Timeout set: 600 seconds, run interrupted by timeout
+-------------------------------------------+
| [04/03/2020 11:44:15] Executando consulta |
+-------------------------------------------+
* Trying IP...
* TCP_NODELAY set
* Connected to IP (IP) port PORT (#0)
> POST /consultas/csv HTTP/1.1
Host: IP:PORT
User-Agent: GuzzleHttp/6.2.1 curl/7.52.1 PHP/7.0.33
Authorization: CUSTOM TOKEN
Content-Type: application/json
Content-Length: 956
* upload completely sent off: 956 out of 956 bytes
* Operation timed out after 600001 milliseconds with 0 bytes received
* Curl_http_done: called premature == 1
* stopped the pause stream!
* Closing connection 0
Dev: Timeout set: 600 seconds, run completed after 5min48s.
+-------------------------------------------+
| [04/03/2020 11:59:33] Executando consulta |
+-------------------------------------------+
* Trying IP...
* TCP_NODELAY set
* Connected to IP (IP) port PORT (#0)
> POST /consultas/csv HTTP/1.1
Host: IP:PORT
User-Agent: GuzzleHttp/6.2.1 curl/7.52.1 PHP/7.0.33
Authorization: CUSTOM TOKEN
Content-Type: application/json
Content-Length: 956
* upload completely sent off: 956 out of 956 bytes
< HTTP/1.1 200 OK
< Date: Wed, 04 Mar 2020 14:59:01 GMT
< Content-Type: application/json
< X-Powered-By: :-)
< Content-Length: 52
< Server: Jetty(9.2.z-SNAPSHOT)
<
* Curl_http_done: called premature == 0
* Connection #0 to host IP left intact
+-------------------------------------------+
| [04/03/2020 12:05:14] Processando retorno |
+-------------------------------------------+
| consultas/importacao/importacao1.csv |
+-------------------------------------------+
+-------------------------------------------+
| [04/03/2020 12:05:16] Inserindo registros |
+-------------------------------------------+
41946/41946 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓] 100%
+---------------------+---------------------+----------------------+-----------+-----------+----------+
| Inicio | Fim | Tarefa | Tenant | Registros | Duração |
+---------------------+---------------------+----------------------+-----------+-----------+----------+
| 04/03/2020 11:59:33 | 04/03/2020 12:05:21 | importa_movimentacao | tenant | 41946 | 00:05:48 |
+---------------------+---------------------+----------------------+-----------+-----------+----------+
Try to get the error log and put it here, so we can help you better.
– Kayo Bruno
I added at the end of the question the logs.
– Anderson Rosa
If you are having problems only with timeout and you know how long approximately the request takes, try to define such value as Guzzle configuration parameter
– Bruno Augusto
The problem is not the timeout, the issue is that in production, if the timeout is not set, the request continues indefinitely, even if the endpoint has already finished the execution. In this production case, the timeout was set at 10 minutes, so it stopped after that time, I have tested up to 60 minutes, and it was the time that it took for the timeout to occur.
– Anderson Rosa