Python Agent 2.0.0.1

Released on: 
Wednesday, September 4, 2013 - 03:33
End of Life

The end-of-life date for this agent version is July 29, 2019. To update to the latest agent version, see Update the agent. For more information, see End-of-life policy.

Notes

This release of the Python agent is a major new version and primarily focuses on the addition of support for Python 3.

The agent can be installed using easy_install/pip/distribute via the Python Package Index or can be downloaded directory from our download site.

For a list of known issues with the Python agent see our online help article on the status of the Python agent.

New Features:

  • Python 3.3 or later is now supported. This includes support for popular web frameworks that have been ported to Python 3, such as CherryPy, Django, Flask, Pyramid and Tornado.

  • Added new instrumentation to track as external service calls, requests made by the 'thrift' client module.

  • Added new instrumentation to track memcache calls made by the 'bmemcached' client module.

Features Removed:

  • Python 2.5 is no longer supported. The minimum required Python version is now 2.6. If using Python 2.5, you should ensure that any requirement for the 'newrelic' module listed in a 'setup.py' or pip requirements file says 'newrelic<2.0.0.0'.

Bug fixes/Improvements:

  • Fixed broken instrumentation for 'httplib' module, which would cause an exception where the 'httplib' connect() method was being invoked via the Connection class type rather than an instance of the Connection class.

  • Fixed issue where if the host system clock was wound backwards, then the response time of active requests could be set as being zero, resulting in a ZeroDivisionError when calculating thread utilization.

  • Fixed issue where the use of SSL via a HTTP proxy by the agent to connect to the New Relic data collector to report data would fail.

  • Fixed broken instrumentation for sqlite database client module which resulted in the executescript() API call failing.

  • Add workaround for uWSGI issue where when using gevent mode of uWSGI, it would attempt to wait on all greenlets on process shutdown, instead of only on non daemon threads, specifically the request threads. The issue was causing processes to hang for 60 seconds on shutdown before the uWSGI master process killed the process. We are in discussion with uWSGI authors about a permanent fix to uWSGI.