Multiple URLConnection parallele in ambiente tomcat

di il
4 risposte

Multiple URLConnection parallele in ambiente tomcat

Buonasera! Il mio nome è Antonello. E' un piacere essere qui.

Sto sviluppando un web service Rest che in background va ad interrogare una serie di url(tipicamente un centinaio)
ogni tot di secondi per servire costantemente dei dati aggiornati.
Niente di complicato in ambiente locale, ma i problemi iniziano a sorgere dopo aver caricato l'applicazione su Tomcat.
Ovviamente le politiche di gestione dei thread sono differenti e sono consapevole di non poterne utilizzare molti a cuor leggero.
Ho provato con un numero di thread fissi (Executors.newFixedThreadPool) e con una CachedThreadPool().
Le mie attività di lettura sono di breve durata, ma la mia istanza, dopo qualche ora di elaborazione, si blocca.
Qualcuno può suggerirmi un approccio alternativo, oppure una soluzione più snella per tenere aggiornati i miei dati.
Grazie

4 Risposte

  • Re: Multiple URLConnection parallele in ambiente tomcat

    Dovresti chiarire meglio il contesto e magari mostrare anche del codice. È una web app JavaEE pura? O c'è Spring, Spring Boot o altro?
    Poi "si blocca" è un po' vago, servirebbe vedere il codice. Potrebbero esserci dei deadlock o magari per errata/assente sincronizzazione la esecuzione non riesce a proseguire. Non lo posso sapere così ...
  • Re: Multiple URLConnection parallele in ambiente tomcat

    Si, mi aspettavo questa risposta! Contavo sul fatto che ci fosse una implementazione (diversa) standard percorribile.
    Ti ringrazio innanzitutto per la veloce risposta. Provvederò ad aggiornare presto la discussione con alcuni chiarimenti.
  • Re: Multiple URLConnection parallele in ambiente tomcat

    E' una web app JAvaEE pura!

    I modelli vengono costantemente riempiti ed aggiornati seguendo questa logica di base:

    Viene lanciato inizialmente uno ScheduledExecutorService che ogni cinque secondi esegue il seguente processo:

    -legge da uno stream gli url per i dati da memorizzare/aggiornare
    -crea un Executors.newFixedThreadPool(100);
    -crea una {List<Callable<ClasseRaccolta>>()} lista di threads con gli url ottenuti
    -invoca simultaneamente i Threads con un ExewcutorService {executor.invokeAll(ThreadQuote, 5, TimeUnit.SECONDS)}
    -Legge la lista di Future ottenuti dalla chiamata precedente per aggiornare i modelli:
    
    	for (Future<ClasseRaccolta> future : resultList) 
    		{
    			if (!future.isCancelled()) 
    			{
    				ClasseRaccolta x= future.get();
    				//aggiornaModelli(x);
    			}
    		}
    		

    -Chiude l'esecutore: executor.shutdown();


    Aprire e chiudere un ExecutorService a ogni iterazione non è stato il mio approccio iniziale, ma
    cosi facendo riesco a tenere moderato e costante l'utilizzo delle risorse, in ambiente locale perlomeno.
    Appena ho novità circa l'errore ricevuto dal contenitore Tomcat lo inserisco. Sto procedendo alla riattivazione.

    Grazie
  • Re: Multiple URLConnection parallele in ambiente tomcat

    Antonello_88 ha scritto:


    Aprire e chiudere un ExecutorService a ogni iterazione non è stato il mio approccio iniziale, ma
    cosi facendo riesco a tenere moderato e costante l'utilizzo delle risorse, in ambiente locale perlomeno.
    Il thread-pool lo puoi creare una volta sola, non è necessario ri-crearlo ogni volta. E giusto solo come appunto: quelli che passi al invokeAll() non sono thread, sono "task". Tu puoi avere un thread-pool con 20 thread fissi ma sottomettere al pool 400 task, chiaramente solo 20 per volta saranno eseguiti contemporaneamente.

    Riguardo il
    				//aggiornaModelli(x);
    Bisogna vedere cosa viene aggiornato e soprattutto chi usa poi quei dati. Serve la necessaria sincronizzazione per evitare la mancata visibilità delle modifiche da parte di altri thread o peggio la corruzione di valori o di strutture dati.

    Per il resto, finora non vedo nulla di davvero "palesemente" errato o inappropriato. Verifica con strumenti come VisualVM che non ci sia un consumo eccessivo/crescente di risorse (thread, cpu, heap ...).

    (VisualVM era integrato nel JDK fino al JDK 8, poi successivamente separato dal JDK. Quella linkata è la versione ufficiale a sé stante dal JDK).
Devi accedere o registrarti per scrivere nel forum
4 risposte