[Java] eseguire n azioni in un determinato arco temporale

[ndakota]

Ciao ragazzi, mi è stato assegnato un lavoro ma non so come gestire una parte di questo. L'utente configurerà una percentuale, di una determinata azione da compiere, non è importante credo, per ogni fascia oraria, qualcosa del genere

8.00-9.00 : 7%
9.00-10.00: 8%
10.00-11.00: 7%

e via dicendo insomma. Sarebbe anche carino se per esempio quel 7% di azioni da compiere nella prima ora sia più o meno spalmato lungo tutti i 60 minuti e non tutte nel primo minuto per dire

Qualcuno ha mai avuto a che fare con cose schedulate nel tempo?
Se qualcuno ha qualche suggerimento da darmi e/o ha qualche framework utile al caso da consigliarmi gliene sarei molto grato. Grazie

[GByTe87]

Si tratta sempre della stessa operazione?

Quello che mi viene in mente così, al volo è una classe della famiglia Executors.

[ndakota]

Originariamente inviato da GByTe87

Si tratta sempre della stessa operazione?

Quello che mi viene in mente così, al volo è una classe della famiglia Executors.

Sì, l'azione è sempre la stessa. Grazie, ci do un'occhiata

Edit: mmm, l'azione è sempre la stessa ma con parametri differenti diciamo.

[BrutalBass]

Inserisci un timer e ad ogni millisecondo controlli l'ora del computer e dopo vai di condizioni if...

if(ora del computer == ora)
{
fai questo quello e quell'altro.
}

[WarDuck]

Originariamente inviato da BrutalBass

Inserisci un timer e ad ogni millisecondo controlli l'ora del computer e dopo vai di condizioni if...

if(ora del computer == ora)
{
fai questo quello e quell'altro.
}

Difficilmente hai bisogno di una risoluzione temporale così alta (1ms)... o meglio dipende dalle esigenze. Può andarti bene anche una precisione di mezzo secondo (500ms), in questo modo consumi meno cicli macchina e la precisione è comunque accettabile.

Ad ogni modo parliamo di percentuale di tempo o di azione, perché tra le due può esserci una differenza abissale.

Nel primo caso per spalmare basta calcolarsi una sleep opportuna .
Nel secondo caso invece devi quantificare quanto sia l'1% di qualcosa.

[U-Boat]

Premetto che non ho capito cosa rappresenta la percentuale, quando io ho a che fare con problemi del genere ricorro alle classi Timer e TimerTask che servono proprio per eseguire "qualcosa" dopo un determinato periodo di tempo.

Se riesci ad essere un po' più chiaro, magari posso darti qualche idea in più

[ndakota]

Dunque si tratta di inviare campagna di sms(insieme di sms con una data di invio comune). In particolare, gli utenti per ogni nuova campagna imposteranno delle percentuali. Per esempio.

8.00 - 9.00: 7%
9.00 -10.00: 8%
10.00-11.00: 8%
11.00-12.00: 7%

E via dicendo per un intera giornata. Il totale degli sms della campagna è risaputo quindi non c'è nessun problema a calcolare le percentuali. Il problema è come inviarne il 7% tra le 8 e le 9 ecc? E' più chiaro ora? Anche se non penso sia molto importante sapere che si tratta dell'invio di messaggi.

[Dan__88]

Immagino che conosci la quantità totale di sms per giornata no?
Quindi sai anche il numero effettivo di sms equivalente al 7%.
Allora dovresti anche poterti calcolare l'intervallo di tempo tra un sms e l'altro.

Così puoi utilizzare un ciclo, molto banalmente
Per esempio:

while(inviati < totali)
{
invia sms();
sleep(tempoCalcolato);
}

[Dan__88]

anche se la cosa migliore sarebbe schedulare le azioni su Cron!
Ogni qual volta l'utente sceglie le percentuali e tutto il resto,
il programma dovrebbe effettuare i calcoli suddetti e modificare la tabella di Cron

[U-Boat]

Adesso è decisamente più chiaro

Così a naso direi che col Timer te la puoi cavare tranquillamente.

Un'ipotesi è quella di usare un unico task di invio che scheduli come ricorrente ogni X minuti: sapendo che ore sono e quanti task all'ora vengono eseguiti, puoi sapere quanti e quali messaggi inviare.
Un'altra ipotesi è quella di schedulare tanti task nel momento in cui l'utente dà l'ok, passando al costruttore del task stesso i messaggi da inviare.

La parte su cui bisogna riflettere di più riguarda però quanto spesso e in che modo ti vengono modificate le impostazioni temporali e, soprattutto, l'elenco dei numeri di telefono a cui inviare i messaggi, per essere certo di non "perdere pezzi" per strada

[VICIUS]

Che io sappia la classe Timer è deprecata e l'uso è sconsigliato. Dovrebbe essere più facile usare uno ScheduledExecutorService e aggiungere un Runnable tramite scheduleAtFixedRate. Sapendo percentuale e numero di sms da inviare è banale calcolare ogni quanti ms deve chiamare la run().

[ndakota]

Per adesso il problema è rientrato. Per pagare meno riciclano la vecchia soluzione, anche se non fa esattamente quello che vogliono. Probabilmente in futuro riupperò il thread

[Dan__88]

Spilorci!
Qual'era la vecchia soluzione?

[VICIUS]

Originariamente inviato da Dan__88

Spilorci!
Qual'era la vecchia soluzione?

Si chiama schi... ehm stagista con cellulare

[GByTe87]

Originariamente inviato da VICIUS

Si chiama schi... ehm stagista con cellulare

Tutto ciò mi ricorda uno dei miei primi lavori: geocodifica degli indirizzi (circa 2000) presenti in un file excel; ovviamente all'epoca (16 anni) ero un totale ignorante (e il committente mi disse di fare così) quindi li cercavo un Google Maps (o un analogo) e riportavo le coordinate in excel.

[U-Boat]

Originariamente inviato da VICIUS

Che io sappia la classe Timer è deprecata e l'uso è sconsigliato. Dovrebbe essere più facile usare uno ScheduledExecutorService [...]

Ho cercato un pochino e non ho trovato nessuna informazione sul fatto che Timer sia deprecato, l'unico riferimento nella javadoc riguarda ScheduledThreadPoolExecutor che dice

A ThreadPoolExecutor that can additionally schedule commands to run after a given delay, or to execute periodically. This class is preferable to Timer when multiple worker threads are needed, or when the additional flexibility or capabilities of ThreadPoolExecutor (which this class extends) are required.

Da quello che mi pare di capire dice solo che è consigliabile usare l'executor in quei casi, ma che il timer continui a rimanere una classe "attuale".

[banryu79]

Originariamente inviato da U-Boat

Ho cercato un pochino e non ho trovato nessuna informazione sul fatto che Timer sia deprecato, l'unico riferimento nella javadoc riguarda ScheduledThreadPoolExecutor che dice

Da quello che mi pare di capire dice solo che è consigliabile usare l'executor in quei casi, ma che il timer continui a rimanere una classe "attuale".

java.util.Timer non è deprecata infatti, semplicemente nei javadoc di Timer, Java 7, è consigliato l'uso di ScheduledThreadPoolExecutor.

Originariamente inviato da Timer javadoc in Java 7

...
This class does not offer real-time guarantees: it schedules tasks using the Object.wait(long) method.

Java 5.0 introduced the java.util.concurrent package and one of the concurrency utilities therein is the ScheduledThreadPoolExecutor which is a thread pool for repeatedly executing tasks at a given rate or delay. It is effectively a more versatile replacement for the Timer/TimerTask combination, as it allows multiple service threads, accepts various time units, and doesn't require subclassing TimerTask (just implement Runnable). Configuring ScheduledThreadPoolExecutor with one thread makes it equivalent to Timer.

[VICIUS]

Originariamente inviato da U-Boat

Ho cercato un pochino e non ho trovato nessuna informazione sul fatto che Timer sia deprecato, l'unico riferimento nella javadoc riguarda ScheduledThreadPoolExecutor che dice

Da quello che mi pare di capire dice solo che è consigliabile usare l'executor in quei casi, ma che il timer continui a rimanere una classe "attuale".

Me lo ricordavo diverso il messaggio sui docs.
Chiedo venia.

[ndakota]

Semplicemente la vecchia soluzione non fa la spartizione nelle varie ore. Quindi i clienti chiamano tutti insieme e il call center si intasa. E continuerà a intasarsi a quanto pare

[Dan__88]

Non hanno mai sentito parlare di efficienza evidentemente