|
AWS + Digital Ocean + Cloudflare + Google Workspace (para o n00b como eu)
|
|
2
|
686
|
5 de Fevereiro de 2024
|
|
Problemas de conectividade durante a instalação
|
|
14
|
954
|
5 de Fevereiro de 2024
|
|
Morto ao executar bundle exec rake themes:update assets:precompile
|
|
6
|
443
|
5 de Fevereiro de 2024
|
|
Docker implantar versão específica do Discourse
|
|
1
|
475
|
5 de Fevereiro de 2024
|
|
Impossível iniciar o discourse da origem ao executar "bin/ember-cli -u"
|
|
3
|
566
|
4 de Fevereiro de 2024
|
|
O Discourse hosting usa docker para todas as instâncias de clientes?
|
|
6
|
486
|
2 de Fevereiro de 2024
|
|
Máquina inteira trava durante a atualização
|
|
32
|
908
|
2 de Fevereiro de 2024
|
|
ISO ou Imagem com Discourse pronta para boot de servidor
|
|
5
|
360
|
2 de Fevereiro de 2024
|
|
Impedir /shared/log/rails/production.log
|
|
7
|
359
|
2 de Fevereiro de 2024
|
|
Qual é uma estrutura de arquivos típica? Tentando restaurar a partir do snapshot
|
|
1
|
235
|
2 de Fevereiro de 2024
|
|
Restaurando uma instância com snapshot
|
|
2
|
601
|
2 de Fevereiro de 2024
|
|
Tamanho mínimo do servidor baseado no backup?
|
|
6
|
381
|
1 de Fevereiro de 2024
|
|
Movendo o servidor
|
|
8
|
442
|
1 de Fevereiro de 2024
|
|
Falha ao atualizar de 3.1.1 para 3.2.0
|
|
3
|
442
|
1 de Fevereiro de 2024
|
|
Clarificação do Discourse 3.2.0 - recursos limitados para auto-hospedeiros?
|
|
1
|
523
|
1 de Fevereiro de 2024
|
|
501 5.5.4 Você não tem permissão para enviar deste endereço
|
|
2
|
836
|
1 de Fevereiro de 2024
|
|
Atualizando quando o espaço parece baixo: parar o app, depois limpar, depois reconstruir o app?
|
|
5
|
482
|
31 de Janeiro de 2024
|
|
Pré-compilação de assets leva 20 minutos
|
|
18
|
1444
|
31 de Janeiro de 2024
|
|
Construir e executar em uma máquina diferente?
|
|
2
|
349
|
31 de Janeiro de 2024
|
|
Discourse instalado em VM Ubuntu Server UNRAID atrás de NPM reverse proxy não resolvendo hostname
|
|
10
|
984
|
30 de Janeiro de 2024
|
|
Implantar repositório Discourse personalizado via docker
|
|
6
|
553
|
30 de Janeiro de 2024
|
|
Falha na atualização
|
|
2
|
237
|
30 de Janeiro de 2024
|
|
Problema de inicialização do Discourse
|
|
5
|
620
|
30 de Janeiro de 2024
|
|
502 gateway inválido
|
|
4
|
970
|
29 de Janeiro de 2024
|
|
Job exception: getaddrinfo: Falha temporária na resolução de nomes
|
|
1
|
351
|
29 de Janeiro de 2024
|
|
Suporte de endpoint Azure da OpenAI para gpt-4-32k?
|
|
8
|
1043
|
29 de Janeiro de 2024
|
|
Falha no backup ao mover o arquivo de backup temporário para o diretório backups/default
|
|
4
|
464
|
29 de Janeiro de 2024
|
|
Erro "Net::ReadTimeout com # This is a common error in Ruby on Rails applications, specifically when dealing with network requests. Let's break down what it means and how to fix it.
**Understanding the Error:**
* **`Net::ReadTimeout`**: This is a standard Ruby exception that indicates a network socket has timed out while waiting for a read operation to complete. In simpler terms, your application tried to read data from a remote server, but the server didn't respond within the expected timeframe.
* **`#<TCPSocket:(closed)>`**: This part tells you that the connection being used for the read operation was a `TCPSocket` and it was already closed. This means the connection was either closed by the remote server (perhaps due to inactivity, an error on their end, or a network issue) or by your application itself before the read operation could complete.
**Common Causes:**
1. **Slow or Unresponsive Server:** The most frequent cause is that the external service or API your Rails app is trying to communicate with is slow to respond, overloaded, or temporarily unavailable.
2. **Network Issues:** Intermittent network problems between your server and the external service can cause read timeouts. This could be on your end, the external service's end, or somewhere in between (like a firewall or proxy).
3. **Long-Running Requests:** If your application is making a request that takes a very long time to process on the server side, the connection might time out before the response is fully received.
4. **Incorrect Configuration:** Sometimes, the timeout settings in your application or in network infrastructure (like load balancers or firewalls) might be too short for the expected response time of the external service.
5. **Connection Closed Prematurely:** Your application might be closing the connection before the response is fully read, although this is less common for standard HTTP libraries unless there's custom connection management involved.
**How to Fix It:**
Here's a systematic approach to troubleshooting and resolving this error:
1. **Increase Timeout Settings:**
* **HTTP Client Libraries:** If you're using libraries like `Net::HTTP` (which is often used by default or by other gems), you can explicitly set the read timeout. For example:
```ruby
require 'net/http'
require 'uri'
uri = URI.parse('http://example.com/slow_endpoint')
http = Net::HTTP.new(uri.host, uri.port)
http.read_timeout = 300 # Set timeout to 300 seconds (5 minutes)
request = Net::HTTP::Get.new(uri.request_uri)
response = http.request(request)
```
* **Gems like Faraday:** If you're using Faraday, you can configure timeouts like this:
```ruby
Faraday.new(url: 'http://example.com') do |faraday|
faraday.options.timeout = 10 # seconds
faraday.options.open_timeout = 5 # seconds
# ... other configurations
end
```
* **Other Gems:** Check the documentation for the specific HTTP client gem you are using (e.g., `httparty`, `rest-client`) for how to configure timeouts.
2. **Check the External Service:**
* **Status Page:** Look for a status page or status updates from the service you are trying to connect to. They might be experiencing issues.
* **API Documentation:** Review the API documentation for expected response times and any rate limits that might be causing throttling.
* **Contact Support:** If the service is consistently slow or unresponsive, reach out to their support team.
3. **Investigate Network Connectivity:**
* **`ping` and `traceroute`:** From your server, try to `ping` the host of the external service and use `traceroute` (or `mtr`) to identify any network latency or packet loss.
* **Firewalls/Proxies:** Ensure that no firewalls or proxy servers are interfering with or have overly aggressive timeout settings for the connection.
4. **Implement Retries and Circuit Breakers:**
* **Retries:** For transient network issues or slow responses, implement a retry mechanism. Be careful not to retry too aggressively, as this can worsen the problem for the external service.
* **Circuit Breaker Pattern:** For services that are consistently failing, consider implementing a circuit breaker pattern to stop making requests to the failing service for a period, preventing your application from being overwhelmed.
5. **Asynchronous Processing:**
* If the external request is inherently long-running, consider performing it asynchronously using background job systems like Sidekiq, Delayed Job, or Resque. This prevents your web requests from timing out and improves user experience.
6. **Review Your Code:**
* Ensure you aren't accidentally closing the connection prematurely in your code, especially if you have custom network handling.
**Example using `Net::HTTP` in a Rails context:**
If you have a service object or a model method making the call:
```ruby
# app/services/external_api_service.rb
require 'net/http'
require 'uri'
class ExternalApiService
def fetch_data(resource_path)
uri = URI.parse("https://api.example.com/#{resource_path}")
http = Net::HTTP.new(uri.host, uri.port)
http.use_ssl = true # If the API uses HTTPS
http.read_timeout = 120 # Set a reasonable timeout, e.g., 120 seconds
http.open_timeout = 10 # Set a shorter timeout for establishing the connection
request = Net::HTTP::Get.new(uri.request_uri)
# Add any necessary headers, e.g., authentication tokens
# request['Authorization'] = "Bearer YOUR_API_KEY"
begin
response = http.request(request)
if response.is_a?(Net::HTTPSuccess)
JSON.parse(response.body)
else
# Handle non-success responses (e.g., 4xx, 5xx errors)
Rails.logger.error "API Error: #{response.code} - #{response.message}"
nil
end
rescue Net::ReadTimeout => e
Rails.logger.error "API Read Timeout Error: #{e.message}"
nil
rescue Net::OpenTimeout => e
Rails.logger.error "API Open Timeout Error: #{e.message}"
nil
rescue StandardError => e
Rails.logger.error "Unexpected API Error: #{e.message}"
nil
end
end
end
```
**In summary:** The `Net::ReadTimeout` with `TCPSocket:(closed)` error usually points to a problem with the external service's responsiveness or network conditions. The most common solution is to increase the timeout values in your HTTP client configuration, but it's also crucial to investigate the external service and network path for underlying issues.
|
|
7
|
3096
|
28 de Janeiro de 2024
|
|
CDN removido, mas o discourse ainda aponta para ele no cache do navegador?
|
|
2
|
460
|
28 de Janeiro de 2024
|
|
Instalando outros sites em subdomínios
|
|
1
|
287
|
26 de Janeiro de 2024
|