Hi all, On 16/10/2007, Jonathan Chen <[EMAIL PROTECTED]> wrote: > Hi Dave, > > On 16/10/2007, Dave <[EMAIL PROTECTED]> wrote: > > [...] > > I'm not having any problem with my reset hits and turn-over referrers > > tasks. Unfortunately, I don't have much experience with the new task > > management system. I suppose it is possible that your task-lock table > > has become inconsistent -- so you might want to try stopping Roller, > > clearing the roller_tasklock table and then restarting. > > I had a closer look at the logs, and the lease aquisition failure > appears to be happening with *all* the tasks. On clearing the table as > suggested above, the problem goes away. I did have a look at the data > before clearing, and again once the system restarted; I suspect that > the daylight savings changeover (which happened during my upgrade from > 3.1 to 4.0) may have had something to do with the failure to acquire a > valid lease.
Well, I had a dig in the code yesterday, and that hypothesis proved to be incorrect. The problem looks to be either in OpenJPA or the PostgreSQL driver. There appears to be a loss of precision when dealing with Dates and database timestamps when building queries. Timestamps values from roller_tasklock were being read as Dates with millisecond precision from the database; but queries generated using those Dates values only had centisecond precision. This resulted in the rows not being found, and thus not being updated for lease acquisition. This problem raises it head with PostgreSQL, as timestamp database-values are stored to the millisecond. MySQL doesn't store fractional seconds, and so doesn't have the problem. For the time being, I worked around the problem by hacking TaskLock.orm.xml to ignore using roller_tasklock.timeAcquired as a search criteria when updating a row for lease-acquisition; I'll dig into the OpenJPA and/or the PostgreSQL driver later. Cheers. -- Jonathan Chen <[EMAIL PROTECTED]>
