uwsgi error

[mkloveyy]

Describe the bug: ...

[pid: 32738|app: 0|req: 9507/17121] 10.15.203.202 () {38 vars in 644 bytes} [Wed Apr  3 16:02:05 2019] GET /api/v2/redisservice/isdocker?ip=10.14.132.95&port=6379 => generated 179 bytes in 536 msecs (HTTP/1.1 200) 2 headers in 88 bytes (1 switches on core 11)
ERROR 2019-04-03 16:02:06,163 __init__ 32738 139774123824896 Exception during timing of request
Traceback (most recent call last):
  File "/var/www/cdportal/shared/venv/lib/python2.7/site-packages/elasticapm/contrib/django/middleware/__init__.py", line 170, in process_response
    if self.client.config.django_transaction_name_from_route and hasattr(request.resolver_match, "route"):
AttributeError: 'Config' object has no attribute 'django_transaction_name_from_route'

Environment (please complete the following information)

• OS: [e.g. Linux]
• Python version: 2.7.5
• Framework and version [e.g. Django 2.1]: Django 1.9
• APM Server version: 4.1.0
• Agent version:
  Linux version 3.10.0-327.36.3.el7.x86_64 (builder@kbuilder.dev.centos.org) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-4) (GCC) ) Update copyright in LICENSE #1 SMP Mon Oct 24 16:09:20 UTC 2016

Additional context

Here is my uwsgi.ini

[uwsgi]
uid = cdportal
gid = cdportal
pidfile = /var/run/uwsgi/uwsgi.pid
# stats = /var/run/uwsgi/stats.sock
cap = setgid, setuid
chdir = /var/www/cdportal/current/backend
module = cdportal.wsgi:application
master = True
vacuum = True
max-requests = 1000
daemonize = /var/log/uwsgi/cdportal.log
socket = 127.0.0.1:49152
workers = 8
threads = 30
listen = 1024
enable-threads = True

[beniwohli]

This is a very weird error, since that attribute is defined on the Config class:

apm-agent-python/elasticapm/conf/__init__.py

Line 288 in 5a287a4

django_transaction_name_from_route = _BoolConfigValue("DJANGO_TRANSACTION_NAME_FROM_ROUTE", default=False)

. Do you do anything fancy with client configuration?

BTW, we don't support Django 1.9, as it reached end of life 2 years ago. I also recommend using a more recent version of Python 2.7, as 2.7.5 is not something we test. I can't say if these old versions contribute to the problem, though.

[mkloveyy]

@beniwohli Do you mean that version 4.2.1 doesn't support Django 1.9? So which one is the last version to support Django 1.9?

[beniwohli]

We never officially supported Django 1.9, as it went EOL before Elastic APM was released. I realised just now that in the Django specific docs, we list 1.8/1.9/1.10 as supported, which I mistakenly copied from the Opbeat docs (the name of the product before we became members of the Elastic family). The information on our Supported Technologies page is correct. I will fix the Django docs ASAP.

We do however still run the test suite with Django 1.8/1.9/1.10 on a nightly basis, so things should still work, we just don't offer commercial support when using these versions, and we can't guarantee that future versions of the agent won't break compatibility without notice.

[mkloveyy]

Understood. Thanks for you helps! We will use version 4.1.0 as it seems to be more stable now.
BTW, now we use below way to solve the problem in #442 temporarily:

# we kill all workers forcely and then restart the uwsgi
ps -ef | grep uwsgi | grep -v grep | awk '{print $2}' | xargs kill -9

[beniwohli]

Closing this for now, as I've not been able to reproduce this.