Issue 1:
Checklist

I have included the output of celery -A proj report in the issue.

I have included all related issues and possible duplicate issues in this issue.

I have included the contents of pip freeze in the issue.

I have verified that the issue exists against the master branch of Celery.

I have tried reproducing the issue on more than one message broker and/or result backend.

I have tried reproducing the issue on more than one workers pool.

I have tried reproducing the issue with retries, ETA/Countdown & rate limits disabled.

Related Issues and Possible Duplicates

Related Issues

None

Possible Duplicates

#2727 - symptoms are similar, however that issue doesn't originally mention the transport and at least one user there mentioned transport:redis, for which I can't reproduce the problem.

Environment & Settings

Celery version:

celery report Output:

software -> celery:4.2.2 (windowlicker) kombu:4.3.0 py:2.7.16
billiard:3.5.0.5 qpid:N/A
platform -> system:Linux arch:64bit imp:CPython
loader -> celery.loaders.app.AppLoader
settings -> transport:qpid results:rpc:///

broker_url: u'qpid://localhost:5672//'
result_backend: u'rpc:///'

Steps to Reproduce

Required Dependencies

Minimal Python Version: Unknown

Minimal Broker Version: Unknown

Minimal Result Backend Version: Unknown

Minimal OS and/or Kernel Version: Unknown

Minimal Broker Client Version: Unknown

Minimal Result Backend Client Version: Unknown

Must use qpid transport (not reproducible on rabbitmq or redis transports)

Python Packages

pip freeze Output:

amqp==2.4.2
billiard==3.5.0.5
celery==4.2.2
kombu==4.3.0
pytz==2018.9
qpid-python==1.36.0.post1
qpid-tools==1.36.0.post1
redis==3.2.1
vine==1.3.0

Minimally Reproducible Test Case

The following gist has testcases for revoking a task in progress:

https://gist.github.com/rohanpm/78480b28b6c3e26fd9e33e999c899ee8

Expected Behavior

When task2.revoke(terminate=True) is called, task2 is terminated. The worker continues to execute subsequent tasks.

Actual Behavior

When task2.revoke(terminate=True) is called, one of the following happens:

If there's no more tasks in the queue:

-- task2 is terminated, but the worker then hangs and doesn't process any further tasks.

If there are tasks in the queue:

-- task2 is not terminated, the worker continues executing task2 and subsequent tasks as if no revoke call was made

Issue 2:
I have checked the issues list

for similar or identical enhancement to an existing feature.

I have checked the pull requests list

for existing proposed enhancements.

I have checked the commit log

to find out if the if the same enhancement was already implemented in the

master branch.

I have included all related issues and possible duplicate issues in this issue

(If there are none, check this box anyway).

Related Issues and Possible Duplicates

None I could find on the issue tracker.

Brief Summary

The Celery 4.0 lowercase name change brings zero benefit for developer but causes downsides in the form of name and style collisions in existing configuration files/classes.

Design

Architectural Considerations

None

Proposed Behavior

Allow people to keep the old behaviour because the new one isn't beneficial.

Diagrams

N/A

Alternatives

There isn't a way to avoid name collisions in a simple way because Celery decided to namesquat randomly. Separate file maybe. The lack of configuration option owner prefix can't really be worked around trivially.