link-it
Errori occasionali "Broken pipe" nei log del front-end Apache
Nella mia configurazione di GovWay ho un front-end Apache, che fa reverse proxy a WildFly (sulla stessa macchina) dove è in esecuzione GovWay. Occasionalmente riscontro nei log di Apache l'errore "Broken pipe" durante la comunicazione con GovWay, ne riporto uno:
[Tue May 13 22:13:34.936602 2025] [proxy:error] [pid 5120] (32)Broken pipe: [client 217.175.52.232:26122] AH01084: pass request body failed to 127.0.0.1:8080 (localhost)
Non risulta nulla nei log di Wildfly audit.log, server.log, wildfly.out.
Nella pagina Transazioni di GovWay non risultano errori o fault applicativi in tali orari. Non è attivo rate limiting.
Nell'orario degli errori, SDI ci stava recapitando notifiche di esito, che quindi ci perdiamo; l'errore che riscontrano loro è: org.apache.axis2.AxisFault: WSWS7089I: The connection wait has timed out., abbiamo verificato con l'assistenza SDI.
Il server è una EC2 su AWS. Non ci sono load balancer. Non risultano valori del server anomali in tali orari.
Nei file log di GovWay non c'è nulla in tale orario, aveva fatto alcuni controlli automatici poco prima ma già conclusi al momento degli errori, le allego comunque qui:
/var/log/govway$ grep -r '13-05-2025 22:13:' *
govway_timers.log:INFO <13-05-2025 22:13:18.130> org.openspcoop2.pdd.timers.TimerGestorePuliziaMessaggiAnomaliLib.check(127): Controllo consistenza database in corso... (Prossimo controllo fra 300 secondi, limit=50)
govway_timers.log:INFO <13-05-2025 22:13:18.133> org.openspcoop2.pdd.timers.TimerConsegnaContenutiApplicativi.check(160): Controllo messaggi da riconsegnare verso il modulo ConsegnaContenutiApplicativi in corso... (Prossimo controllo fra 60 secondi, limit=50)
govway_timers.log:INFO <13-05-2025 22:13:18.136> org.openspcoop2.pdd.timers.TimerConsegnaContenutiApplicativi.check(378): Controllo Repository Messaggi (Riconsegna verso ConsegnaContenutiApplicativi) terminato in 3ms
govway_timers.log:INFO <13-05-2025 22:13:18.143> org.openspcoop2.pdd.timers.TimerGestorePuliziaMessaggiAnomaliLib.check(298): Pulizia Messaggi Anomali terminata in 13ms
Dipende da GovWay? Come posso risolvere?
Buongiorno @marcomarsala , l'errore da te riportato dovrebbe indicare che Apache ha tentato di inviare la richiesta al backend (WildFly), ma la connessione è stata chiusa dal backend prima del completamento della trasmissione. La problematica non dovrebbe dipendere da GovWay ma dall'architettura su cui è stato dispiegato.
Tra le cause più comuni ci possono essere:
- se WildFly impiega troppo tempo a rispondere (per esempio per una richiesta lenta o bloccata), potrebbe chiudere la connessione mentre Apache sta ancora tentando di inoltrare la richiesta. Puoi provare a verificare se effettivamente ci sono richieste con latenze alte, magari dovute a messaggi corposi. In tal caso verifica che i parametri di timeout di apache siano consistenti rispetti a tali tempistiche
- Se il client (es. un browser o un altro sistema integrato) chiude la connessione prima che la richiesta sia completamente processata da Apache/WildFly.
- Se WildFly è sotto stress (CPU alta, GC lunghi), può rifiutare le connessioni o impiegare troppo a rispondere.
Dovresti quindi effettuare un'analisi più dettagliata analizzando i punti sopra riportati, magari aggiungendo a WildFly i log del gc e l'access log.
Buongiorno,
Si tratta molto probabilmente del terzo punto, in quanto l'istanza raggiunge picchi di utilizzo CPU >50%, non sapevo che WildFly inizia a droppare le connessioni in questo caso (non riscontriamo rallentamenti), pertanto ho aumentato le risorse dell'istanza EC2, sto tenendo monitorato quotidianamente e se il problema persiste approfondirò attivando i log del garbage collector.
Il timeout di Apache è già a 300 s, così come quello di tutti i sistemi chiamanti. Come dicevo, gli errori si riscontrano durante il recapito delle notifiche di esito da parte di SDI, quindi messaggi piccoli, come conferma anche l'access_log. Nella pagina "Transazioni" di GovWay non ci sono messaggi con latenza alta in quelle fasce orarie (i messaggi per cui c'è l'errore Broken pipe non arrivano proprio a GovWay).
Se può essere utile, ho riscontrato l'errore Broken pipe anche nei log di GovWay durante l'invio fatture. In tali orari non c'è un corrispondente errore Broken pipe nei log di Apache:
Allego qui il log del garbage collector gc.log.0.current.zip Da una prima analisi, il GC non sembra impiegare più di 1/2 secondi.
Ho qualche aggiornamento. Premetto che aumentando il timeout di default di Wildfly (parametro no-timeout-request sul listener in standalone.xml) la situazione sembra migliorata. Nulla di strano nei log del GC. Ho però questo evento nell'error_log di Apache:
[Wed Jun 18 22:48:18.365566 2025] [proxy:error] [pid 11760] (32)Broken pipe: [client 217.175.52.231:33938] AH01084: pass request body failed to 127.0.0.1:8080 (localhost)
Nell'access log a tale orario ho due richieste, una notifica e una fattura ricevuta, quest'ultima in errore (HTTP 502):
217.175.52.232 - - [18/Jun/2025:22:48:18 +0200] "POST /govway/sdi/in/APP/TrasmissioneFatture/v1 HTTP/1.1" 202 -
217.175.52.231 - - [18/Jun/2025:22:48:18 +0200] "POST /govway/sdi/in/APP/RicezioneFatture/v1/ HTTP/1.1" 502 232
Sul Monitoraggio GovWay risulta solo una delle due richieste (la notifica), non c'è traccia della fattura:
Log WildFly vuoti. I log di Govway in /var/log/govway ma ruotano troppo velocemente per il nostro volume di traffico e non ci sono più quelli del giorno 18. Ad ogni modo viste le mie impostazioni:
credo che se l'evento non c'è nel Monitoraggio non lo troverei neanche qui.
Idee?
Tra parentesi, dove trovo la configurazione di questi log? Vedo che li ruota raggiunto 1 MB di dimensione ma non ricordo di averlo configurato io:
Buongiorno @marcomarsala , per aumentare la dimensione dei log puoi creare un file nella configurazione esterna con nome 'govway_local.log4j2.properties' e ridefinire le proprietà opportune per gli appender che desideri modificare rispetto a quelli definiti nel file 'govway.log4j2.properties' all'interno dell'archivio govway.ear.
Ad esempio:
appender.govway_core_rollingFile.policies.size.size=10MB