Boa tarde Pessoal,
Alguém jah pasosu por isso ?!
Tenho um processo que imprime qto tempo leva cada serviço 24 horas por dia, porém toda vez no período de 12:00 até 12:59 , qdo é executado por threads diferentes, o calculo pra saber o tempo fica bagunçado.
ele acrescenta 43200 na conta.
Por exemplo.
O tempo do serviço foi de 1,456 ele coloca 43201,456, outro exemplo .350 ele coloca 43200.350
Esse código abaixo é um calculo para saber qto tempo terminou um processo, onde time é um long.
Qual a relação com as cadas decimais ?
Você terá um tempo X representado por um número, para ser mais exato, um long.
O que deve ser aplicado é a transformação desse tempo em outro valor que você deseja, por exemplo, horas, minutos e segundos.
Qual a sua real necessidade ? Me parece que o seu problema é na conversão do tempo em long em outra estrutura.
43200 é metade de 86400, que é o número de segundos em um dia - ou seja, 43200s são 12 horas.
Isso não lhe dá uma dica?
O tempo em segundos pode ser calculado, realmente, como:
long inicio = /* tempo de início, que pode ser capturado com System.currentTimeMillis() */;
double segundosTranscorridos = (System.currentTimeMillis() - inicio) / 1000.0;
Só que estou achando é que você está fazendo um pouco de bagunça na hora de converter não sei o quê (é uma string?) para o valor inicial em milissegundos.
Na Verdade não…O que acontece…
Em todos os horarios , esse serviço é acionado e faz a contagem corretamente
Porém no intervalo do 12:00 até 12:59 ele faz a conta errada.
Pq o serviço iria fazer a conta errada somente somente nesse intervalo ?!
o jar está no ambiente linux.
[quote=JavaCore]Na Verdade não…O que acontece…
Em todos os horarios , esse serviço é acionado e faz a contagem corretamente
Porém no intervalo do 12:00 até 12:59 ele faz a conta errada.
Pq o serviço iria fazer a conta errada somente somente nesse intervalo ?!
[/quote]
Como vc obtém “time” ? usando Date ? ou usando System.currentTimeMillis() ?
Se usar Date vai dar problema, porque o Date é sensivel a Locale e TimeZone , System.currentTimeMillis() não é.
O codigo correto é como o entanglement falou. Vc está usando assim ?
Bom, na realidade o correto mesmo seria com System.nanoTime (), mas apenas se o serviço executa em menos de Long.MaxValue nano segundos.
nanoTime não depende do relógio, o que o torna muito mais exacto e sem problemas de timeZone etc…
De onde eu vejo seus números não fazem sentido.
Va fala que "O tempo do serviço foi de 1,456 ele coloca 43201,456, outro exemplo .350 ele coloca 43200.350 "
Se ele coloca 43201,456 então o tempo foi esse. Ou seja, o serviço demora pra caramba (mais de 12 horas como disse o entanglement). Não sei como vc chega na conclusão que deveria ser 1,456 …
Hum… parece que o problema é que o this.time vem de fora do método. E como você citou que pode rodar mais de uma thread, pode estar havendo problema de concorrência.
Esse atributo time, ou melhor, a classe que possue esse atributo é thread-safe?
Só esse trecho de código não é suficiente para avaliar toda a situação. Se puder postar a classe inteira, já ajudaria.
/**
* Variable to store the timer initial value
*/
private long time = 0;
/**
* Initializes the timer that calculates the execution time.
* @return a reference to itself
*/
public ExecutionStatusTag resetTimer() {
return resetTimer(System.currentTimeMillis());
}
/**
* Sets the timer with the given date, that calculates the execution time.
* @return a reference to itself
*/
public ExecutionStatusTag resetTimer(long startTime) {
time = startTime;
timerState = TIMER_RUNNING;
return this;
}
Será que á alguma particularidade ou bug do linux ?!
Sim, ela pode não ser, mas vejo que ela é usada para calcular o tempo, e se uma instância dessa classe estiver sendo compartilhada por várias threads, pode dar problema de dados inconsistentes.
Como você disse que ela pode rodar com mais de uma thread, era importante ver como esse mecanismo de criação de threads está implementada na sua aplicação. Só assim dá para afirmar se o problema é concorrência ou não.
O Problema que esse mecanismo é do Weblogic ==> ESB >> Proxy que chama os serviços…
O que eu fiz foi o seguinte criar duas threads diferentes uma chamando o servico e a outra terminando pra vê se dá o erro, mas o erro não aparece dessa forma de teste.