You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@roller.apache.org by "Dick Davies (JIRA)" <ji...@apache.org> on 2008/12/09 11:16:19 UTC

[jira] Commented: (ROL-1761) tasks will not run more often than leaseTime minutes

    [ https://issues.apache.org/roller/browse/ROL-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14475#action_14475 ] 

Dick Davies commented on ROL-1761:
----------------------------------

My workaround for the time being is to add this to roller-custom.properties:

# drop leasetime to 5 minutes to work around
# https://issues.apache.org/roller/browse/ROL-1762
tasks.ScheduledEntriesTask.leaseTime=5
tasks.ResetHitCountsTask.leaseTime=5
tasks.TurnoverReferersTask.leaseTime=5
tasks.PingQueueTask.leaseTime=5
tasks.SyncWebsitesTask.leaseTime=5
tasks.RefreshRollerPlanetTask.leaseTime=5
tasks.TechnoratiRankingsTask.leaseTime=5

it's not perfect , but I think it should mitigate the problem until 4.1 ships.

> tasks will not run more often than leaseTime minutes
> ----------------------------------------------------
>
>                 Key: ROL-1761
>                 URL: https://issues.apache.org/roller/browse/ROL-1761
>             Project: Roller
>          Issue Type: Bug
>          Components: Database Access & Data Model
>    Affects Versions: 4.0
>         Environment: solaris 10, oracle 10g, glassfishv2
>            Reporter: Dick Davies
>            Assignee: Anil Gangolli
>             Fix For: 4.1
>
>         Attachments: ROL-1761.patch
>
>
> We're finding that our tasks won't run more often than every leaseTime minutes. 
> After a bit more digging, we found our JPAThreadManagerImpl.unregisterLease() method is not updating the database,
> so any lease that is successfully taken out are kept , blocking that task from running, until they expire.
> In this case , the JPA-generated SQL looks ok, but the roller logs show what looks like a transaction rolling back:
> DEBUG 2008-11-21 11:47:00,097 CommonsLogFactory$LogAdapter:trace - Executing query: [UPDATE TaskLock t SET t.timeLeased=?1 WHERE t.
> name=?2 AND t.clientId=?3] with parameters: {3=ScheduledEntriesTask, 2=0, 1=devel-roller01}
> DEBUG 2008-11-21 11:47:00,097 CommonsLogFactory$LogAdapter:trace - <t 6810846, conn 4959010> executing prepstmnt 20488940 UPDATE ro
> ller_tasklock t0 SET timeleased = ? WHERE (t0.name = ? AND t0.client = ?) [params=(int) 0, (String) ScheduledEntriesTask, (String)
> devel-roller01]
> DEBUG 2008-11-21 11:47:00,098 CommonsLogFactory$LogAdapter:trace - <t 6810846, conn 4959010> [0 ms] spent
> DEBUG 2008-11-21 11:47:00,098 RollerTaskWithLeasing:run - ScheduledEntriesTask: Lease released, task finished
> DEBUG 2008-11-21 11:47:00,109 CommonsLogFactory$LogAdapter:trace - <t 6810846, conn 4959010> [10 ms] rollback  *******
> DEBUG 2008-11-21 11:47:00,109 CommonsLogFactory$LogAdapter:trace - <t 6810846, conn 4959010> [0 ms] close
> Is the line flagged '******' a transaction rolling back? 
> If so, does anyone have any clue where I start looking to find out why JPA did that?
> I suppose I could work around this by setting interval == leaseTime, but this is a multi-server cluster
> and I've got enough headaches without adding race conditions into the mix :)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.