Giter Site home page Giter Site logo

Comments (11)

jlward avatar jlward commented on July 17, 2024 1

Jobtastic 2.0.0 is on PyPi. It has celery 4.x support

from jobtastic.

winhamwr avatar winhamwr commented on July 17, 2024

Celery 4.0 has lots of good features that I'm excited about. We'd love to accept a pull request for Celery 4.0 support. If nobody is able to to contribute that PR soon, after the first of the year, PolicyStat will probably be able to dedicate some time to putting the PR together to make it happen.

In the meantime, we're happy to accept PR's that make partial progress towards this goal, and we can use a celery_4 branch to aggregate them.

Here's what I think we can do with 4.0 support:

Make sure we support 3.1.25

The first step to upgrading is supporting 3.1.25. Let's bump the requirement for the test suite and then fix all of the deprecation warnings.

Drop support for Celery < 4.0 and bump to Jobtastic 2.0

There are lots of backward compatibility hacks in the Jobtastic codebase that impede maintenance. Celery 4.0 adds several things that will greatly simplify the code base.

Handling Task Connection Errors

The delay_or_FOO methods currently do a lot of work to catch task connection errors, and Celery 4.0 will make this much easier.

Move tests to pytext

Celery 4.0 comes with lots of testing improvements. Lets move to pytest in order to take advantage of those.

User decorator syntax

Subclassing is no longer the hotness, so we should use the decorators.

Deprecations

There are several deprecations that affect us.

from jobtastic.

gabn88 avatar gabn88 commented on July 17, 2024

I'm already using Jobtasting on 3.1.25? It seems to work fine :)

from jobtastic.

jlward avatar jlward commented on July 17, 2024

I have a PR up that handles quite a bit of the changes needed to support celery 4. The problem is, any test with a busted broker in celery 4 hangs. I don't know why. My suspicion is that celery 4 has done a lot of work to prevent broker exceptions from happening. I don't know for certain though. Once I figure that out, I don't think it'll be too difficult to getting tests passing with celery 3/4 support.

from jobtastic.

jlward avatar jlward commented on July 17, 2024

celery/celery#4296

Looks like we'll need to peg the version of kombu for celery 4.x

from jobtastic.

gabn88 avatar gabn88 commented on July 17, 2024

I would love to see this merged, the dependency of celery 3 is going to bite me in the short run.

If you need any help, please ring a bell. Thanks!

from jobtastic.

jlward avatar jlward commented on July 17, 2024

Hello @gabn88 , I am actually in the process of getting my PR for basic celery 4 support code reviewed as we speak. I'm hoping to get a new version up on PyPi today if I can.

from jobtastic.

gabn88 avatar gabn88 commented on July 17, 2024

That's great. I'll keep an eye on it. Thanks!

from jobtastic.

gabn88 avatar gabn88 commented on July 17, 2024

We have upgraded, but now it is not working anymore. Possible because the upgrade also installed the lastest kombu instead of 4.0.2. Will report back after downgrading that.

from jobtastic.

gabn88 avatar gabn88 commented on July 17, 2024

On my development server the new jobtastic (2.0.0) with celery 4.2.1 and kombu 4.2.1 is working fine, however on my production server it is failing. 'Normal' celery tasks are working fine though. Cannot seem to find the issue, but the server runs out with Gateway timeout when the jobtastic job is planned...

The task:

class FillScheduleTask(JobtasticTask):
    """
    Creates a real schedule from a template
    """
    significant_kwargs = []
    # How long should we give a task before assuming it has failed?
    herd_avoidance_timeout = 0  # all tasks of this type within this time are removed... not so nice!
    cache_duration = -1  # No caching

    def calculate_result(self, template_id, horse_ids, amount_of_weeks_to_fill, start_date, delete, 
                         overwrite_existing, set_default_rider, **kwargs):
        """
        """      
        results = []
        scheme = get_object_or_404(TemplateScheme, pk=template_id)
        users = User.objects.filter(pk__in=user_ids)
        additions_to_do = users.count()*amount_of_weeks_to_fill

        
        for user in users:
            results.append(scheme.fill_schedule(user, amount_of_weeks_to_fill, start_date, delete,
                                 overwrite_existing, additions_to_do, self))
    

        return results

Called with:

result = FillScheduleTask.delay_or_eager(
                template_id=template_id, user_ids=list(users.values_list('id', flat=True)), amount_of_weeks_to_fill=amount_of_weeks_to_fill, start_date=start_date, 
                delete=delete, overwrite_existing=overwrite_existing)
       

The weird thing is that it is working fine on dev, but not on production.

The broker is on an external server in production, but like I said it is working fine for regular celery tasks with the same settings.

EDIT2:
I still worked on finding the issue for a full day now, but still haven't found the root cause. I do know now that when I inherit from celery.Task and update def calculate_result to run and remove the task.update_progress calls from the function and then use FillScheduleTask.apply_async() everything is working fine. So it definitely has to do with the 'magic' that Jobtastic adds, whether it is the lock, or the cache, or something else. The weird thing is that it used to work fine before jobtastic 2.0 and on celery 3.x. And that it is still working fine on the development server.

from jobtastic.

gabn88 avatar gabn88 commented on July 17, 2024

I tried again to use Jobtastic with celery 4.3 in production. In development everything works fine, but in production it fails.

I have searched for a day for the issue now, and it seems that the apply_async method on the JobtasticTask is broken. It add an extra caching mechanism, so when the task is executed once, it cannot be executed anymore (even not with different kwargs).

Edit: The problem seems to be that in development I have only one (local) cache. In production I have a cache on the webserver and a seperate cache on the worker. I use the cache on the worker as CELERY_RESULT_BACKEND. But only when I clear the (local) cache on the webserver I can do tasks again.

Edit2: Fixed it by explicitly defining the CELERY_RESULT_BACKEND as a cache on Django, a.k.:

CACHES = {
    'default': env.cache('REDIS_URL'),
    'worker': env.cache('CELERY_RESULT_BACKEND')
}

and adding also in the settings:

JOBTASTIC_CACHE = 'worker'

After restarting the worker and the apache server (I had to stop it and start it again, a restart was not working) it is working! :)

from jobtastic.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.