v3.0.0

WebSockets and a better configuration system

This is a major release. Sections of older actionHero projects will be incompatible with this release.

This release adds web socket support to the project, and abstracts the chat room system to be available generically to all types of persistently-connected clients. This release also updates the configuration system to allow developers to use any/all/none of the connection methods. This should make it easier to add more and more communication protocols to the project.

Notes

General

• default file route changed from '/file' to '/public'; /file is the "action" called file which is provided as an example
• new configuration system. Check config.js for updated structure
• all transports can be enabler or disabled based on config.js
• api.id now reflects protocols in use
• you can now specify which IPs actionHero will listen on for each protocol. Use "0.0.0.0" for "all""

Actions

• randomNumber action update to show how to inspect different HTTP verbs to create different responses

Chat

• new initializer to make chat available to all persistent-socket clients
• new api.chatRoom namespace for chat functions (IE: api.socketServer.socketRoomBroadcast => api.chatRoom.socketRoomBroadcast)

Web Sockets

• socket.io a dependency of the project
• socket.io client JS symlikned to /public
• websocket example created
• status counts for webSockets
• websockets can be bound to http or https

Tests

• Spec Helper & Tests updated to reflect new configuration system

Examples

• updated to reflect new configuration system

v2.0.3

Summary: Bug Fixes, Examples, and REPL

• actionHero now has a REPL! You can use the command line to use all the api-namespaced functions and define your own. Great for debugging or checking on the status of the cluster.
• Checkout the /examples folder for how to use the actionHeroClient package, browser javascript, and curl to interface with actionHero. More languages coming soon.

Notes

• cache actions now take milliseconds like everything else.
• you can now have non-expiring cache entires (just pass a null value for expireTimeMS)
• there are no no default periodically-run tasks. Look in /examples for the tasks that used to be there and copy them into your own project's /tasks folder. This was done to reduce the 'magic' in the framework. the runTask task still remains, as it was not run periodically.

Note:
** actionHeroClient released! Connect node to node! **

v2.0.2

Summary: Bug Fixes & Examples

Details
Check the notes for the bug fixes. There are now also more examples in the project, showing off how you can connect from various environments. This also coincides with the release of the actionHeroClient NPM package. More coming soon.

Notes

• Updates to how socket client requests are tracked to enforce proper message IDs. If you directly used api.processAction before, the interface has changed.
• running the test suite will now use a separate redis db. You can also set this in config.json for your app.
• better logic to ensure that tasks are enqueued properly
• cluster members will remove stale tasks they were working on when the app is started (in case of a crash)

v2.0.1

** Redis-powered Cluster & major refactor **

Details

This version realizes the dream of a true cluster for actionHero. There is no longer a need for a master process, and every node in the cluster can work alone or in a group. This release also enables using the node.js cluster module to make the most of your server(s).

This version is likely to be incompatible with prior versions. Running an actionCluster now requires redis (running a single node does not require redis and is still a pure node.js implementation).

Using a redis backend, actionHero nodes can now share memory objects and have a common queue for tasks. Philosophically, we have changed from a mesh network to a queue-based network. This means that no longer will every node talk to every other node, but rather all nodes will talk to redis. Now, I know that you are thinking "isn't that bad because it creates a single point of failure?" Normally, the answer is yes, but redis already has mesh networking support! The suggested method of deployment is to setup a redis instance on each server, and they will handle the mesh networking for you.

api.cache now works in a shared way if you are part of an actionCluster. All cache actions refer to redis and in this way, all peers can have access to shared objects. To avoid conflicts, you will have access to 'lastReadAt' as part of api.cache.load responses. actionHero will also no longer store its own cache to disc periodically as redis does this already.

The task system also has undergone some major refactoring. All tasks are now stored in a shared queue within redis. All peers will periodically check the queue for unfilled tasks, and drain the queue one at a time. In this manner, you can add more task capacity by spinning up more actionHero nodes which may or may not also handle web/socket traffic. This also means that tasks will not get lost if a node crashes as they will remain in the redis queue until drained. Each peer also has a 'personal' task queue for "all" actions.

For periodic tasks ("any" and "all"), the peer which most recently completed the task while hold the semaphore for that task (in a actionHero:tasksClaimed shared list) until the proper amount of time has elapsed, then they will re-enqueue the task. This does not mean that a specific node will always preform tasks of the same type.

There are new requirements to config.json to configure redis. Here is an example:

"redis" : {
"enable": true,
"host": "127.0.0.1",
"port": 6379,
"password": null,
"options": null
},

All methods under the api.actionCluster namespace have been removed for simplicity. Just use the normal cache methods, and if you are in a cluster, you will operate in a shared memory space.

Notes

• all peers now share the same api.cache data
• api.tasks.enqueue is now api.tasks.enqueue(api, taskName, runAtTime, params) Set runAtTime to 0 to run the task as soon as possible
• using redis cache save; no longer saving cache periodically
• all nodes are created equal; there is no need for a master
• the entire actionCluster namesapace has been removed
• there are new requirements to config.json to setup redis
• every node will try to handle requests and process one job pending in the task queue at a time
• shared tasks will be preferred over per-node tasks
• the 'status' action has some new output types to reflect 'global' stats in comparison to 'local' stats (IE: count of web requests that this node has served vs total)

v1.0.3: Merge pull request #4 from tmaindron/tmaindron-work

** Optional Headers **

Details

• You can now define custom host-headers in config.json which will be sent with every http/https response
• bug fixes introduced with task sharing (v 1.0.1)

v1.0.2

** Task Sharing **

Details

• The master process will now delegate tasks in his queue to other peers in the cluster.
• Minor bug fixes

v1.0.1

** SSL / HTTPS web server **

Details

• You can now spin up a secure https server along with you http server in action hero. It will work exactly the same as the http server, and you can have both on at the same time with no overhead.
  • There are new configuration settings in config.json for this below

Settings for https server:

"secureWebServer" : {
"port": 4443,
"enable": true,
"keyFile": "./certs/server-key.pem",
"certFile": "./certs/server-cert.pem"
},

v1.0.0

Summary: OMG 1.0!

Details:

• initializers
  • you can add your own initializers to a folder called initializers in your project's root. They will be loaded at boot and accessible like this:
    • actionHero.myNewInitFunction(api, function(){ next(); });
• This is a cleanup and bug-fix release
• After some refactoring, actionHero is now at v 1.0
• The last message sent by a socket client can now be read by inspecting connection.lastLine
• Better error handling if the socket / web port are in use
• Cleanup of the example HTML pages
• HTTP requests will now return serverInformation.currentTime
• The original server (the one with no configData.actionCluster.startingPeer will be the only server to run 'any' tasks)
  • Other servers will NOT assume the role of running "any" tasks, but they will keep them in memory until the master server comes back upon a crash.
• Using the node-mime module
• Adding 10 min cache-control to flat files

v0.2.6

Summary: Cluster Task Managment

Details:

• rewrite of the task system to be more like actions
• tasks now live in ./tasks/ in your application root
• tasks can now have their own specific timers
• tasks are now scoped to be "any" or "all", to run once per actionCluster (any) or on all nodes (all)
• Default tasks within the api are now better explained:
  • calculateStats
    • Polls all other members in the actionCluster to build up statistics
    • Runs every 10 seconds
  • cleanLogFiles
    • removes all files in ./log/ if they are larger than api.configData.maxLogFileSize
    • runs every 60 seconds
  • cleanOldCacheObjects
    • removes expired objects in api.cache.data
    • runs every 10 seconds
  • pingSocketClients
    • sends a keep-alive message to all TCP socket clients
    • runs every 60 seconds
  • runAction
    • a wrapper to run an action as a task
    • will not run automatically
  • saveCacheToDisk
    • will save the contents of api.cache.data to disc
    • runs every 60 seconds

v0.2.5

Summary: Goodbye Databases & Models, hello other versions of Node!

Details:

• You can now use actionHero on node.js version 5 upwards (including the new v0.7)
• In order to keep actionHero as compartmentalized as possible, we have removed databases and models.
  • There are tons of great ORMs and drivers for node. When deploying actionHero in production, I expect that you will make use of them. However, requiring database integration with actionHero is no longer a core part of the framework. The previous DB connection support was too specific to my test implementations to be useful for everyone.
  • This makes previous implementations of actionHero incompatible with versions > 0.2.4.
    • I'm sorry, but that's the price of progress!
• The location where the cache is saved and loaded from is configurable in config.json via api.configData.cache.cacheFolder and api.configData.cache.cacheFile