MuleQueue Planning

MuleQueue is the original project taken on by Jakcodex/Muledump to handle connecting to ROTMG.

Version 1 Workflow

The shared code is stored in lib/muledump.js (L157, L199) and is directly injected into the mule workflow in lib/mule.js (L204-L508, L641, L760). It works, but there is no real organized way of utilizing it. Mules regulate themselves.

The Mule object is provided to MuleQueue so that it may interact with each Mule.

Initially, a mule is sent to queueStart and checks if any tasks are in the queue. If nothing is in the queue it will run; otherwise it checks for fresh cache data. If this is a cache-only reload the process ends here. If the request proceeds, it is sent to queueWait and tries again after the wait timer expires. The queue order is preserved and eventually all queue items finish their task; however, every item in the queue waits in a dedicated timer. A user with thousands of accounts will have thousands of timers all running, checking. This is not efficient.

Pausing the queue works by overwriting all queue items in state 'queue' to state 'pause' then clearing all wait timers. This is done manually, once on the 'pause reload' button and again in rate limit detection. Resuming resets states to 'queue' and then sends them all back thru queueRun(). Cancelling resets button states in the UI and clears out the queue.

Attempting to reload an account while the queue is running is met by a no-such-feature error. The queue cannot be modified once it is running. During the wait cycles there is no indicator that MuleQueue is even running. There is no way to check on the status of MuleQueue in the UI. No way to determine what is next or how many items are left. The only place this is presently displayed is in the browser console.

Version 2 Introduction

MuleQueue should be treated the same as SetupTools. Pushed to lib/mulequeue.js it will provide a proper interface for managing the queue. It will not rely on mule.js to integrate it so deeply.

The queue should be built at initialization and tracked from a central location rather than having each Mule enforce the queue on itself. Only a few system timers would be necessary instead of one per account. The queue task list would no longer be immutable. Task order could be rearranged, individual accounts/groups cancelled, etc while it is active. MuleQueue could track its state in local storage so it can be resumed on reload if interrupted.

A code control interface will be provided for easy management from mule.js and the UI.

A new UI for managing MuleQueue and seeing status and progress will also be available.