Base solution for your next web application
Open Closed

BackgroundJob goes straight to "IsAbandoned" and no logs #10731

User avatar
0
hra created

AspNetZero 10.0.0

I have paired down my backgroundjob to something very, very simple - but most of the time, it goes straight to "Abandoned" and never executes.

I have found the only way I can get one to execute is to:

  1. delete all abandoned background jobs
  2. refresh my browser which is calling the Application Service to enqueue the job
  3. then call the application service to enqueue the job

Then what happens is, it will queue a single job - but if I click the button to queue a second one, it goes into abandoned. Why is this? Why is there no logging when it chooses to abandon a job? I have also registered on the bus for error callbacks - and none come through.

Thanks,

Go to accepted answer
3 Answer(s)
  • User Avatar
    0
    ismcagdas created
    Support Team

    Hi @hra

    Could you also share your ABP NuGet package version ?

    Thanks,

  • User Avatar
    0
    hra created

    Hi @ismcagdas,

    Thanks for responding. I kept digging and I actually figured it out. It was my fault.

    I had adapted the Abp dbcontext conventions such that all changes within a UOW that are saved at the same time, will share the same timestamp. That's been working great for us, up until now, when I've started using the BackgroundJob infrastructure.

    It appears to have effectively set the "CreationDate" and "TimeOfNextExecution" (I think thats the field name) to the exact same value. For some reason this makes the background worker process chase a date/time that never arrives (well, almost never - very unreliable). I have altered my UOW modification such that I only turn it on for UOW scopes that I need it, rather than across the board.

    Thanks please consider closed.

  • User Avatar
    0
    thegrowthteam created

    Hi @ismcagdas,

    Thanks for responding. I kept digging and I actually figured it out. It was my fault.

    I had adapted the Abp dbcontext conventions such that all changes within a UOW that are saved at the same time, will share the same timestamp. That's been working great for us, up until now, when I've started using the BackgroundJob infrastructure.

    It appears to have effectively set the "CreationDate" and "TimeOfNextExecution" (I think thats the field name) to the exact same value. For some reason this makes the background worker process chase a date/time that never arrives (well, almost never - very unreliable). I have altered my UOW modification such that I only turn it on for UOW scopes that I need it, rather than across the board.

    Thanks please consider closed.

    I'm having the same issue with the background job, and the CreationTime and NextTryTime are the same in my case too. I haven't altered anything in the db context as you mentioned, though. What could be the issue @ismcagdas

Assignee
No one
Labels
Non yet