Ciao,

adesso è tutto più chiaro. Faccio un rapido controllo e ti posto più avanti nella giornata (adesso sono un po' incasinato con un lavoro). Su due piedi, comunque, ti suggerirei di dividere il tuo WebMethod (AvviaConversione) in due parti: la prima determina il valore di "bCanConverter", la seconda, invece, esegue il processo di conversione e potresti definire il metodo aggiungendo l'attributo "SoapRpcMethod(OneWay := True)" in modo tale che il client non resti in attesa del processo nel server.

P.S. Ok per il componente. Se noti qualche post fa ti avevo chiesto la versione di .NET che utilizzi proprio per capire quale tecnica stavi impiegando. La mia domanda su WS come componente si riferiva semplicemente al modo in cui dichiaravi e istanziavi la variabile WS (cosa che non si evince dal codice postato) per il quale ti avrei eventualmente chiesto di verificare l'uso di WithEvents.

Ciao.

Ciao,
non sono riuscito ad approfondire l'agomento come avrei voluto. Provo però ad ipotizzare una possibile risposta con il beneficio del dubbio. Secondo me il problema sta nel fatto che la thread che serve la seconda chiamata è figlia della stessa thread del metodo web principale. Prima che il webmethod termini, quindi, è necessario che tutte le thread ad esso associate terminino. Usando OneWay (=True) il client dichiara che non è interessato alla risposta (esito) da parte del servizio WEB. In IIS tale chiamata provoca l'invio immediato al client di una risposta HTTP 202 (202 significa che il server ha iniziato a processare il servizio web). In questa situazione il client non può ricevere nessun parametro di ritorno dal server e nel server il processo viene eseguito come avviene normalmente (diciamo in modo sincrono rispetto alle threads create).

La prima soluzione che ti ho suggerito (separare in due parti il servizio web) scavalca il problema però implica che sia il client ad invocare il secondo metodo web. In scenari simili al tuo io utilizzo un'altra tecnica descritta da diversi design patterns. In pratica nel server creo un processo/un servizio (servizio di Windows) che esegue la seconda parte del lavoro (nel tuo caso decodificare/convertire il file): una speciei di schedulatore di processi.

Il servizio web, quindi, si limita a segnalare al servizio principale che c'è un nuovo file da processare (operazione estremamente veloce). Questa tecnica può essere applicata in diversi modi: (A) usando una tabella in un database (il servizio web inserisce un record per indicare che c'è un nuovo file - il servizio windows legge la tabella ad intervalli regolari per verificare se ci sono nuovi file da processare); (B) usando dei file di segnalazione nel filesystem (questa tecnica evita l'uso di un database qualora non fosse presente nella tua soluzione); (C) altre tecniche basate su IPC o SOCKET.

Tra l'altro disporre di uno schedulatore esterno di processi rende la tua soluzione molto più robusta svincolando il processo da IIS (cosa accade al tuo sistema se nel bel mezzo della conversione del file IIS si pianta o viene riavviato? - come te ne accorgi?) e consentendoti di gestire in modo ottimale problematiche di sincronismo delle operazioni, gestione dei criteri di sicurezza associati al processo, sospensioni temporanee del servizio principale (es. per manutenzione/aggiornamento), esecuzione distribuita dei processi, ecc. ecc.

Ciao e buon proseguimento con il tuo lavoro.