Asynchronous Message Queue

[hupili]

With the increasing number of channels, synchronous call to all methods causes larger and larger delay. Before it exceeds human tolerable span, we should consider an asynchronous message queue.

The queue:

• Is built on SNSPocket to avoid platform specific details.
• Support multiple threads subject to configuration.
• Support per-platform / per-account / per-key locking. e.g. simultaneous request to a single platform from a single computer may fail.
• Act as a persistent data structure. e.g. dump to SQLite up receiving new message.
• Can be operated as a channel. This allows hierarchical organisation of SNS.

Requires experienced Python developer and one who is familiar with SNSAPI framework.

Welcome any prototyping and restructuring effort to make the queue easy to implement.

[iptux]

maybe, wrapper synchronous calls into threads is another, but poor, solution for these DELAYs https://github.com/iptux/snsapi/commit/db24686e73ce31fa186c7aacda9d515ad47dabe5

i'm considering whether to make a pull request, it havn't solve the underlying problem

[hupili]

Nice commit!

I think this is the current best solution for upper layer apps. However, it is not suitable to put that commit in the snspocket.

Instead of method by method modification, my suggestion is:

• make a decorator, see "require_authed" in snsbase.py, which make a method callback-able.
• We should define clearly what the input/output structure for callback functions, making it extensible for future demand. e.g. when it is decorated as callback-able, callback function will receive sth. like {'platform':xxx, 'channel': xxx, 'method_param': xxx, 'callback_param': xxx, ... }. This is to help callback functions operate in a stateless manner. Also, users can put some app-specific data in callback_param so as to coordinate between several (probably simultaneous calls).
• Add timeout mechanism. Since Python thread can not be killed, process may help

The use cases are then:

• This make_callback decorator can be used by many other components, even as a building block for the queue.
• If certain entry is configured in pocket.json, SNSPocket can dynamically decorate those methods in __init__.
• We can add SNSPocketCallback which derives SNSPocket and make all methods defaultly callback-able.

This way looks better for me before we have such async-queue facility. What do you think?

[hupili]

One prototype is implemented in sina-automator

It implements a leaky bucket for resource management. The rate_limit decorator also has callback support. For resource management within one channel, the sina-automator's lbucket suffices.

One still missing piece is the ability to coordinate resources between different channels. Note that when there are more and more channels, apps may want to simultaneously request them. Resources should be considered across channels, i.e. "Support per-platform / per-account / per-key locking.".

[hupili]

This feature will gradually enter SNSAPI starting from v0.7 .

@fqj1994 , please place a warning log message to notify users about possible interfaces changes of async related stuffs.