We had a strange bug in our application (VAST 8.0, Headless, Win Server) where I needed almost two days to find the solution.
I just want to share ou findings about the effect. Maybe somebody runs into a similar problem and can profit from this information.
The effect was that some Delays needed a lot more time to complete than they were actually setup, so e.g.
- Code: Select all
(Delay forSeconds: 900) wait
needed almost an hourto complete.
As we also "tweak" the system at a lot of other places, at first it was not obvious, that the problem was in the Delay class. (Actually we needed to fire a heartbeat to another server every 15 minutes, so I assumed the problem to be somhow socket related)
The problem was in some code setting the resumptionTime: of a Delay object which was already in the delayedTasks list of the class Delay. The class Delay pops out every 100ms the first object and compares it to the elapsed time. As the delayedTasks are a SortedCollection, the first-to-end object should be first in the list. So just consider the following code
- Code: Select all
| t t1 t2 d1 d2 |
t := Time millisecondClockValue.
d1 := Delay forMilliseconds: 2000.
[
t1 := Time millisecondClockValue.
d1 wait.
Transcript show: ('Duration 1 = ' , (Time millisecondClockValue - t1) printString); cr.
] fork.
d2 := Delay forMilliseconds: 3000.
[
t2 := Time millisecondClockValue.
d2 wait.
Transcript show: ('Duration 2 = ' , (Time millisecondClockValue - t2) printString); cr.
] fork.
[
d1 resumptionTime: t + 5000
] fork.
Copy the code to the transcript and execute it. The Delay d2 will also last for 5 seconds even as nothing is changed in the object.
Solution:
1. Do a resort of the Delay delayedTasks SortedCollecton if the resumptionTime of a Delay object is changed
2. Delete the code and use the Delay class approbiately.
We did number 2
Best regards
Thomas
