Imported Google Group message. Original thread at: Redirecting to Google Groups Import Date: 2016-01-19 21:04:00 +0000.
Sender:Martin Buhr.
Date:Tuesday, 27 January 2015 09:28:45 UTC.
Hi Everyone,
Last night we pushed version 1.4 of Tyk to our releases page, the main new feature for this release is a whole new scriptable middleware and event handler system system which should make integrating Tyk with existing infrastructure and authentication systems much easier. We’ve also made significant changes to how rate limiting and quotas work, making them much more accurate an effective in multi-node HA environments.
We’ve also worked on our documentation, with the Advanced Management API and the Dashboard now having their own full sections, giving much more detail on how a full Tyk installation is structured as well as the benefits of using the Advanced API vs. the Core API, particularly around multi-client systems.
Full details and discussion of the release can be found in the blog post, and as always, the releases for various architectures are available from our Github downloads page.
For those that just want to know what has changed, here’s the changelog:
Data expiry headers will be added to all analytics records, set expire_analytics_after to 0 to have data live indefinitely (currently 100 years), set to anything above zero for data in MongoDB to be removed after x seconds. requirement: Mus create an expiry TTL index on the tyk_analytics collection manually (http://docs.mongodb.org/manual/tutorial/expire-data/). If you do not wish Mongo to manage data expiry at all, simply do not create the index.
Added a JS Virtual Machine so dynamic JS middleware can be run PRE and POST middleware chain
Added a global JS VM
Added an eh_dynamic_handler event handler type that runs JS event handlers
Added Session management API and HttpRequest API to event handler JSVM.
Added JS samples
Fixed a bug where requests that happened at identical times could influence the quota wrongly
Modified default quota behaviour: On create or update, key quotas are reset. unless a new param ?suppress_reset=1 accompanies the REST request. This way a key can be updated and have the quota in Redis reset to Max, OR it can be edited without affecting the quota
Rate limiter now uses new Redis based rate limiting pattern
Organisations can now have quotas
Added a ?reset_quota=1 parameter check to /tyk/orgs/key endpoint so that quotas can be reset for organisation-wide locks
Keys and organisations can be made inactive without deleting
Any and all feedback is always greatly appreciated, so have at it 
Cheers,
Martin & the Tyk team.