Buongiorno a tutti,
ho configurato i web service su IIS e premetto che sia invio che ricezione delle notifiche funzionano correttamente. Il problema è sulle fatture ricevute, in questo caso se la fattura ricevuta è di piccole dimensioni (fino a circa 15 Kbytes) tutto funziona correttamente, se la dimensione è maggiore nei flussi e su IIS mi da un internal error 500, sembra un limite di IIS ma ho verificati tutti i limiti presenti senza risolvere il problema. Qualcuno ha avuto lo stesso problema?
1 Mi Piace
Buongiorno Roberto, abbiamo riscontrato lo stesso problema durante la fase di test.
Siete riusciti ad andare oltre o avete ancora lo stesso problema?.
Grazie.
Il limite di default di IIS è più alto. Controlla anche eventuali limiti della libreria che usi per esporre il Webservice. Che linguaggio e libreria hai usato?
Buonasera,
purtroppo sto avendo anche io l’errore 500 per file superiori ai 50Kb e non riesco a risolvere in nessun modo.
Qualcuno di voi alla fine c’è riuscito?
Attendo vostre notizie.
Grazie mille.
Il mio primo consiglio se non l’hai già fatto, è quello di cercare su stackoverflow la soluzione (ovviamente in inglese)…essendo utilizzato in tutto il mondo ovviamente si trovano più soluzioni (te lo dico non per risultare saccente, ma perchè ti sia d’aiuto per le prossime volte).
Ti riporto quello che ho trovato io con una breve ricerca (lascio a te la traduzione):
Setting uploadReadAheadSize in applicationHost.config file on IIS7.5 would resolve your issue in both cases. You can modify this value directly in applicationhost.config.
- Select the site under Default Web Site
- Select Configuration Editor
- Within Section Dropdown, select "system.webServer/serverRuntime"
- Enter a higher value for "uploadReadAheadSize" such as 1048576 bytes. Default is 49152 bytes.
During client renegotiation process, the request entity body must be preloaded using SSL preload. SSL preload will use the value of the UploadReadAheadSize metabase property, which is used for ISAPI extensions
spero ti aiuti a risolvere il problema
Scusa hai risolto alla fine? o non era questa la soluzione?
Ciao a tutti. Io ho un problema simile a Roberto76, credo. Siamo in produzione e pensavamo di ricevere le fatture dal SdI senza alcun problema… Senonchè ci siamo poi accorti che diverse fatture, in realtà, non le riceviamo per niente, non troviamo alcuna traccia sul nostro server, ma le ritroviamo nell’area riservata dell’AdE.
Il servizio di assistenza mi ha risposto:
in merito alla Sua richiesta, La informiamo che da verifiche lo SdI ha provato più volte ad inoltare ai vostri sistemi la fattura fino al raggiungimento del numero massimo di tentativi previsti da sistema.
Entrambe le fatture sono dunque nello stato di Ricevuta di impossibilità di recapito
Di seguito l’errore riscontrato nel tentativo di recapitare la fattura ai vostri sistemi:
org.apache.axis2.AxisFault: HTTP ( 500 ) Internal Server Error address : https://26.2.162.231:80
Da notare che, quando proviamo ad importare di nuovo le stesse fatture, scaricate dall’area riservata dell’AdE, l’acquisizione da parte del nostro software funziona regolarmente, quindi non è un problema di codice.
Può dipendere da quanto segnalato da gianluca_c? Qualcun altro ha lo stesso problema? Ad ogni modo abbiamo provato ad impostare il valore di UploadReadAheadSize e stiamo vedendo che succede…
Ciao @robyone1
siete sicuri , sicuri , certi, ma certi al 100% , che non avete un netscaler un F5 o un ha-proxy davanti al web server.
Gli error 500 vengono prodotti da un server e vengono scritti nell’access log
Il punto fondamentare è che, diciamo il 70% o 80% delle fatture le riceviamo regolarmente! E’ solo il rimanente che non riceviamo! Magari fosse un problema fisso… Ecco perchè l’ipotesi della dimensioni dei file poteva essere una soluzione…
Avete ricevuto fatture di dimensioni superiori ai 50kb? se la risposta è ‘No’ …allora dipende da quello.
Se fosse collegato a quello ed avessero usato IIS come web server avrebbero gli error 500 nel file di trace di IIS, mentre loro su IIS non hanno nulla
Purtroppo però abbiamo trovato nell’area riservata anche qualche file inferiore a 50Kb (non ricevuto dal nostro software), e questo sconfesserebbe la nostra teoria…
Ancora, invece, stiamo verificando se riceviamo nel software files superiori ai 50Kb, al momento tutti quelli ricevuti sono inferiori.
Come trace di IIS, intendete Failed Request Log? Esatto, nessuna traccia di errore 500.
Sei proprio sicuro di questa cosa? Anche se l’errore viene generato da .NET?
Io non conosco IIS, ma una volta ho dovuto debuggare un problema su IIS e sono diventato matto perché il server ci restituiva errori 404, mentre nel log non c’era nulla.
Facendo le prove, avevo notato che se facevo una richiesta per un file inesistente pippo.html, l’errore compariva nel log. Se invece chiedevo il file pippo.svc (sempre inesistente) nel log non ce n’era traccia. La mia conclusione era che gli errori generati da .NET non finivano nel log di IIS. Poi non so se c’è qualche opzione da abilitare, ma di default era così.
Gli errori intesi come stacktrace etc… non vanno nell’access.log ,
ma ad una request corrisponde una response, e se il servizio di assitenza gli ha risposto
che vedono i response code 500, qualcuno glieli invia
… a meno che a sua volta l’operatore ADE non abbia mangiato dei funghetti strani…
Ciao,
purtroppo anche la modifica al valore di uploadReadAheadSize non ha risolto.
Continuo ad avere lo stesso errore 500.
Qualcuno ha altri suggerimenti?
Se può aiutare uso IIS con PHP (FastCGI)
Grazie a tutti.
Ciao a tutti,
anche io come elisabetta ho questo problema e non ho mai ricevuto file con dimensioni maggiori di 20 kb, ma avendo alzato tutti i parametri che mi sono venuti in mente o che ho letto sui vari forum non capisco quale sia il problema. Sul trace IIS non ve ne é traccia, l’unica cosa che so é che viene restituito HTTP 500 dopo un tempo molto alto, dell’ordine 75000. I 15 min del timeout di iis direi
Dopo un po’ di ricerche ho capito che il mio problema e’ sicuramente sull’handler php, infatti 15 min é il timeout del cgi.exe.
Purtroppo oggi SDI sembra sia in ferie, infatti ho ricevuto solo una notifica e 2 fatture, a fronte di una ventina di fatture che attendono esito, e non riesco quindi a capire se ho risolto o meno il problema.
C’è un aggiornamento sul nostro problema: continuiamo a non ricevere tutte le fatture ma sono riuscito ad impostare correttamente le “Regole di traccia richieste non riuscite” di IIS e adesso finalmente ho dei log con qualche dettaglio in più. Ecco un estratto:
HTTP Error 500.0 - Internal Server Error
C:\php\php-cgi.exe - The worker process must shutdown now or configuration has changed
Module: FastCgiModule
Notification: ExecuteRequestHandler
Handler: FastCGI PHP
Error Code: 0x800704e7 (oppure 2147943655)
Preciso che i limiti del fastcgi e di php sono “sparati” al massimo…. Almeno quelli più noti, tipo “timeout attività”, “timeout inattività” e “timeout richiesta”.
Qualcuno ha idea di quale possa essere il problema? Grazie.
Ciao roberto, sono nella tua stessa identica situazione!
