I forum Ricerca FAQ
Fai una domanda
Ultimo messaggio
Gargano10041983
Gargano10041983
il 10 ottobre 2018 alle 22:46
81 messaggi dal 12 settembre 2010
Ciao a tutti,
lato applicativo effettuo una chiamata ad una webapi che si occupa di:
1) - effettuare l’upload di un file
2) - aggiornare il db con il nome del file appena caricato
3) - inviare una notifica email

Parliamo mediamente di file di grandi dimensioni (indicativamente un minimo di 100Mb ed un massimo di 1Gb).

Le operazioni indicate sopra vengono effettuate correttamente.

Il problema è il seguente:
- terminata la chiamata alla webapi l’utente loggato (quindi in sessione a livello applicativo) viene automaticamente buttato fuori dalla sessione

Ho provato ad inserire dentro il “session_end” del global.asax la scrittura di un file txt e questo viene creato quando la chiamata alla webapi ha concluso le sue elaborazioni.

In ambiente di sviluppo il tutto funziona correttamente mentre in ambiente di produzione (webapp di Azure) ho questo problema.

Nel file di configurazione dell’applicazione (web.config) ho effettuato dei settaggi sul timeout del sessionState ma continuo sempre ad avere lo stesso problema.

Durante la chiamata alla weapi (in ambiente di produzione) a livello di strumenti di sviluppo del browser non noto nulla di strano che possa far fastidio alla sessione dell’applicazione.

Spero che qualcuno possa darmi qualche consiglio utile al riguardo.

Saluti,
Alessio.
RispondiQuoting
BrightSoul
BrightSoul
l'11 ottobre 2018 alle 14:32
11.886 messaggi dal 09 febbraio 2002
Contributi
Ciao Alessio,
la sessione non è una buona scelta per mantenere i dati dell'utente loggato, anche in virtù del fatto che stai mettendo l'applicazione su Azure. Se l'applicazione scala orizzontalmente su più istanze, la sessione non sarà condivisa tra le istranze perché i suoi dati sono memorizzati nella RAM della singola istanza in cui era stata creata.

Il modo corretto per riconoscere un utente in tutte le sue richieste è usare un cookie persistente di autenticazione, che sopravvivrà anche un riavvio del browser e fino alla data di scadenza che gli hai impostato quando l'hai creato.

Il cookie non va creato a mano ma bisogna usare FormsAuthentication.SetAuthCooke (se vuoi usare la forms authentication) oppure SignInManager.SignIn (se vuoi usare ASP.NET Identity). Questo ti assicurerà un cookie crittograficamente sicuro e che non può essere alterato dal client.
A proposito: si tratta di un'applicazione ASP.NET tradizionale o di ASP.NET Core? Se è ASP.NET Core dovresti usare ASP.NET Core Identity.

Se proprio devi usare la Session perché ormai l'hai usata in ogni dove puoi se non altro ricorrere a un provider che ti permetta di condividerla sulle varie istanze, ad esempio quello per Sql Server.

ciao,
Moreno
Enjoy learning and just keep making
RispondiQuoting
Gargano10041983
Gargano10041983
l'11 ottobre 2018 alle 16:06
81 messaggi dal 12 settembre 2010
Ciao Moreno,
l'applicazione è in ASP.NET tradizionale...in realtà il framework è C# mentre la parte di view è realizzata con Razor.

A questo punto non posso apportare troppe modifiche perchè l'applicazione è nata e pensata per funzionare con la sessione gestita in questo modo (purtroppo), quindi:
1) intanto volevo capire come mai sulla macchina di test non ho questo tipo di problema mentre in produzione sulla webapp di Azure improvvisamente si verifica questo comportamento?
2) non ho ben capito la soluzione che mi hai proposto e come va implementata?

Grazie,
Alessio.
RispondiQuoting
BrightSoul
BrightSoul
l'11 ottobre 2018 alle 19:14
11.886 messaggi dal 09 febbraio 2002
Contributi
Ciao Alessio,
1) Non ne sono sicuro. Come dicevo prima, il problema potrebbero essere le molteplici istanze che non riescono a condividersi la sessione. Tu quante istanze hai predisposto?
2) L'oggetto Session si appoggia ad un provider sottostante per leggere/scrivere i valori. Per default viene usato un provider che usa la memoria RAM che non è adatto in multi-istanza ma tu lo puoi sostituire facilmente da web.config con un provider che scrive su Sql Server o su Azure Redis Cache. Entrambi questi sistemi, dato che sono accessibili da tutte le istanze, ti permetteranno la condivisione della sessione.

Usare il provider di Sql Server:
https://support.microsoft.com/en-us/help/317604/how-to-configure-sql-server-to-store-asp-net-session-state

Usare il provider di Azure Redis Cache:
https://docs.microsoft.com/it-it/azure/redis-cache/cache-aspnet-session-state-provider

ciao,
Moreno
Enjoy learning and just keep making
RispondiQuoting
Gargano10041983
Gargano10041983
l'11 ottobre 2018 alle 21:27
81 messaggi dal 12 settembre 2010
Ciao Moreno,
seguendo le tue indicazioni ho iniziato a fare qualche ricerca e mi sono imbattuto in questo link:
https://mariodivece.com/blog/2017/02/17/sql-azure-session-state
potrebbe essere adatto?
Una cosa non capisco se configuro il tutto come viene indicato, a livello applicativo non devo fare nessuna modifica al codice?

Grazie,
Alessio.
RispondiQuoting
BrightSoul
BrightSoul
l'11 ottobre 2018 alle 22:07
11.886 messaggi dal 09 febbraio 2002
Contributi

potrebbe essere adatto?

Sì, prova.

Una cosa non capisco se configuro il tutto come viene indicato, a livello applicativo non devo fare nessuna modifica al codice?

Esatto. La Session, così come altre API di ASP.NET, possono lavorare con vari tipi di provider sottostanti senza che tu in superficie debba cambiar nulla.
Enjoy learning and just keep making
RispondiQuoting
Gargano10041983
Gargano10041983
il 12 ottobre 2018 alle 08:15
81 messaggi dal 12 settembre 2010
Ciao Moreno,
per rispondere alla tua domanda sul numero di istanze volevo dirti che l'istanza è unica e dedicata esclusivamente a questa applicazione, pensi che il problema possa essere comunque che su Azure il sessionState non lavori bene se questo è configurato di default su modalità "In-Proc"?

Grazie,
Alessio.
RispondiQuoting
BrightSoul
BrightSoul
il 12 ottobre 2018 alle 09:50
11.886 messaggi dal 09 febbraio 2002
Contributi
Ciao Alessio,


per rispondere alla tua domanda sul numero di istanze volevo dirti che l'istanza è unica e dedicata esclusivamente a questa applicazione

Se l'istanza è unica il problema non dovrebbe esistere. Penso che la sessione stia scadendo naturalmente dopo un periodo di inattività. Prova a impostare un timeout più alto così, dal web.config.
<system.web>
 <sessionState mode="InProc" cookieless="false" timeout="80" />
</system.web>


Se non funziona, prova comunque a usare Sql Server o Azure Redis Cache come provider per vedere se la situazione migliora.

A proposito della singola istanza: sarebbe meglio procurarsene due più piccole che una unica, almeno riesci a ottenere l'alta disponibilità del servizio. Comunque, non conoscendo la tua applicazione non posso consigliarti di farlo perché non so se oltre alla Session ci sono altri problemi che impediscono all'applicazione di scalare (es. file in upload salvati sul disco locale anziché su uno storage condiviso).

ciao,
Moreno
Enjoy learning and just keep making
RispondiQuoting

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.