interrogare una server session occupata

[f.faleschini]

Ciao,

sto provando a spostare in server session alcune parti di codice e mi ritrovo a dover interrogare la session per capire a che punto è.

Usando sessionProgress() ottengo sempre e in modo istantaneo un avanzamento "percentuale", se la session usa startPhase() e trackPhase(), altrimenti sessionProgress() non funziona.

ora se oltre a sessionProgress() voglio chiedere una informazione diversa, ad esempio "dimmi a che fase sei" non so bene come fare.
diciamo che la mia server session fa sleep(1) in un loop, quindi è sempre occupata, se le mando un session Message e aspetto una risposta non mi risponde

probabilmente non si può mandare un messaggio a una session "a tappo", è così?

ho risolto in un modo un po' "workaroundico" facendo in modo che la sesssione occupata scriva lo stato su un file a un percorso preciso e poi chiedo a una altra sesssione di leggermi il file
questo funziona ma mi obbliga a gestire una sessione in più
si fa così o c'è un altro modo?

in effetti un modo migliore è usare una tabella del db e non un file. ma questo comunque non cambia il contenuto...

Grazie!

[r.bianco]

Potresti pensare di fare così: la server session, invece che scrivere da qualche parte, invia un messaggio alla sessione padre (o cmq quella desiderata), che dovrebbe essere in attesa di messaggi dalle altre server session.

[d.termini]

Problema simile a quello che avevo io, ho "risolto" scrivendo un record semaforo in una tabella di gestione (io avevo bisogno che questa server session facesse qualcosa al termine se veniva richiamata ma era già in esecuzione).
Purtroppo come scritto nella documentazione le server session possono svolgere una sola operazione per volta, e dovresti semplicemente attendere che ti invii dei messaggi per indicarti a che punto è, come dice giustamente r.bianco

[f.faleschini]

Grazie, forse mi manca qualche pezzo, ma è possibile mandare un messaggio alla sessione browser?
Oppure devo fare una sessione di "comunciazione" che appunto ascolta le altre sessioni e poi la sessione browser interroga questa sessione di comunicazione.

Ciao!

[r.bianco]

Bella domanda. Non ci sono mai arrivato, ma in qualche modo credo si possa mandare un messaggio a chi ti ha creato...

[smuser]

è possibile mandare un messaggio alla sessione browser?

Che io sappia le sessioni browser non hanno nome quindi non fanno parte delle sessioni server "nominative" alle quali puoi mandare un messaggio.

probabilmente non si può mandare un messaggio a una session "a tappo", è così?

Ogni server session è un thread e nell'ambito del thread l'esecuzione è sequenziale, non c'è concorrenza, e funziona come spiegato qui da Diego https://forum.instantdeveloper.com/viewtopic.php?f=5&t=87892&hilit=timer#p164485:
"Ogni Thread lavora in un ciclo 'infinito', scatta, verifica se è arrivato un messaggio, se è arrivato lo esegue, poi verifica se è scattato un timer, se è scattato esegue la procedura e poi si ferma per un certo tempo.
Quindi ogni sessione ha il suo timer e le sessioni lavorano in maniera concorrente, mentre all'interno della stessa sessione è tutto sequenziale."

Quindi finchè la server session è impegnata a fare cose non può rispondere, ne a messaggi ne a timer (occhio a questa cosa, i timer che scattano vengono comunicati a tutte le sessioni attive, proteggere sempre le procedure eseguite dai timer per capire in quale sessione stanno girando).

Oppure devo fare una sessione di "comunciazione" che appunto ascolta le altre sessioni e poi la sessione browser interroga questa sessione di comunicazione.

L'idea di salvare su file o su db è quella che ho usato in situazioni analoghe alla tua. La sessione browser può fare polling (timer client) oppure on demand (pulsante o altro evento client) interroga il file o il db e aggiorna il risultato all'utente.

Se vuoi lavorare in memoria un'alternativa potrebbe essere un'implementazione di questo tipo (ti serve sempre un server session extra, ma che fa da demone, sempre attiva):

• hai una server session sempre attiva che si chiama GestoreSessioni
• ogni volta che parte una server session si registra sul GestoreSessioni che crea una mappa con (key,value)=(nome sessione, mappa variabili di sessione). Nota: le variabili devono essere tipi primitivi o se sono oggetti devi fare serialize/deserialize
• la server session ma mano che lavora aggiorna i valori delle sue variabili nel GestoreSessioni
• da "fuori" puoi interrogare GestoreSessioni passando nome sessione e nome variabile che ti serve

[f.faleschini]

Grazie!

Alla fine per la app a cui sto lavorando ho fatto come proponi "in memoria".

Una sessione COMMUNICATION a cui mando gli status update dalle sessioni che lavorano e la sessione COMMUNICATION si salva in una idMap lo stato di ogni sessione, le sessioni browser possono chiedere A COMMUNCIATION lo status di una qualsiasi sessione.
Chiaramente non sto gestendo la concorrenza di più utenti, siccome la app a cui sto lavorando è pensata per un mono utente, dovrei magari proteggere l'eventuale concorrenza di più utenti. Siccome è un tool che fa operazioni "una tantum pesanti" limitarlo a un singolo utente è più che ragionevole. Tecnicamente ora se mi fanno login in 2 si rompe tutto.

Grazie!

[r.bianco]

Interessante.
E se per ogni nuova sessione browser crei un GUID e lo metti come prefisso del nome delle server session create da quella sessione browser?
A meno che non sia giusto che di quella sessione ce ne sia una sola.

[smuser]

Ciao Francesco,
bene per la soluzione "in memoria". Per come l'ho capita io (la storia delle server session) e per come hai fatto l'implementazione non vedo problemi di concorrenza:

• la session COMMUNICATION mette in coda in messaggi che riceve e la concorrenza di eventuali messaggi contemporanei da session (e quindi thread) diversi mi aspetto sia gestita da INDE
• le server session che registrano lo stato, oltre ad essere gestite in coda, modificano solo le proprie variabili (accedendo alla mappa con il proprio id) quindi non possono operare su variabili di altre sessioni
• le sessioni utente accedono a COMMUNICATION accodandosi a tutte le altre sessioni (immagino) e accedono in sola lettura

A parte qualche assunto che ho fatto e che potrebbe non essere corretto a quale casistica pernsavi come pericolosa in caso di più utenti?


NOTA: unico problema di questa soluzione è che le server session hanno un timeout e quindi ad un certo punto perdono "memoria".

[f.faleschini]

Ciao Francesco,
bene per la soluzione "in memoria". Per come l'ho capita io (la storia delle server session) e per come hai fatto l'implementazione non vedo problemi di concorrenza:

• la session COMMUNICATION mette in coda in messaggi che riceve e la concorrenza di eventuali messaggi contemporanei da session (e quindi thread) diversi mi aspetto sia gestita da INDE
• le server session che registrano lo stato, oltre ad essere gestite in coda, modificano solo le proprie variabili (accedendo alla mappa con il proprio id) quindi non possono operare su variabili di altre sessioni
• le sessioni utente accedono a COMMUNICATION accodandosi a tutte le altre sessioni (immagino) e accedono in sola lettura

A parte qualche assunto che ho fatto e che potrebbe non essere corretto a quale casistica pernsavi come pericolosa in caso di più utenti?


NOTA: unico problema di questa soluzione è che le server session hanno un timeout e quindi ad un certo punto perdono "memoria".

Ciao, nel mio caso l'utente che avvia l'elaborazione fa partire 2 server session
calcolaPaghe
calcolaPresenze
(si chiamano davvero così)

entrambe le sessioni lavorano "al massimo", come se dentro ci fosse un while con sleep, ogni tanto le sessioni mandano a COMMUNICATION il loro stato. COMMUNICATION salva in una mappa lo stato delle 2 sessioni.

ora per come l'ho fatto io non tengo conto dell'utente loggato nella sessione browser, ma basterebbe che alla sessione aggiugnessi l'id utente e avvierei ad esempio, nel caso di 2 utentei loggati (con id 101 e 223):
calcolaPaghe101
calcolaPresenze101
calcolaPaghe223
calcolaPresenze223

in questo modo il sistema funzionerebbe anche "Multi utente"

Diciamo che il trucco di usare la memoria sta nell'usare una sessione COMMUNICATION che è praticamente sempre idle, tranne per quei pochi millisecondi in cui una sessione le manda il proprio stato (mandato in modo async con sendSessionMessage) o quando una sessione browser la interroga per farsi dare uno stato.

La sessione COMMUNICATION, essendo sempre libera o quasi risponde subito e il trucco funziona, interrogare le sessioni impegnate a fare i conti invece non funziona perché loro sono occupate fino alla fine del loro lavoro.