Giter Club home page Giter Club logo

arena's Introduction

Arena

NPM code style: prettier NPM downloads semantic-release

An intuitive Web GUI for Bee Queue, Bull and BullMQ. Built on Express so you can run Arena standalone, or mounted in another app as middleware.

For a quick introduction to the motivations for creating Arena, read Interactively monitoring Bull, a Redis-backed job queue for Node.

Screenshots

Features

  • Check the health of a queue and its jobs at a glance
  • Paginate and filter jobs by their state
  • View details and stacktraces of jobs with permalinks
  • Restart and retry jobs with one click

Usage

Arena accepts the following options:

const Arena = require('bull-arena');

// Mandatory import of queue library.
const Bee = require('bee-queue');

Arena({
  // All queue libraries used must be explicitly imported and included.
  Bee,

  // Provide a `Bull` option when using bull, similar to the `Bee` option above.

  queues: [
    {
      // Required for each queue definition.
      name: 'name_of_my_queue',

      // User-readable display name for the host. Required.
      hostId: 'Queue Server 1',

      // Queue type (Bull or Bee - default Bull).
      type: 'bee',

      // Queue key prefix. Defaults to "bq" for Bee and "bull" for Bull.
      prefix: 'foo',
    },
  ],

  // Optionally include your own stylesheet
  customCssPath: 'https://example.com/custom-arena-styles.css',

  // Optionally include your own script
  customJsPath: 'https://example.com/custom-arena-js.js',
});

The required name and hostId in each queue object have to be present in each queue object. Additional keys can be present in them, to configure the redis client itself.

The three ways in which you can configure the client are:

1. port/host

// In a queue object.
{
  // Hostname or IP. Required.
  "host": "127.0.0.1",

  // Bound port. Optional, default: 6379.
  "port": 6379,

  // Optional, to issue a redis AUTH command.
  "password": "hello",

  // Optional; default 0. Most of the time, you'll leave this absent.
  "db": 1
}

2. URL

You can also provide a url field instead of host, port, db and password.

{
  "url": "[redis:]//[[user][:password@]][host][:port][/db-number][?db=db-number[&password=bar[&option=value]]]"
}

3. Redis client options

Arena is compatible with both Bee and Bull. If you need to pass some specific configuration options directly to the redis client library your queue uses, you can also do so.

Bee uses node redis client, Bull uses ioredis client. These clients expect different configurations options.

{
  "redis": {}
}

For Bee, the redis key will be directly passed to redis.createClient, as explained here.

For Bull, the redis key will be directly passed to ioredis, as explained here. To use this to connect to a Sentinel cluster, see here.

Custom configuration file

To specify a custom configuration file location, see Running Arena as a node module.

Note that if you happen to use Amazon Web Services' ElastiCache as your Redis host, check out http://mixmax.com/blog/bull-queue-aws-autodiscovery

Running Arena as a node module

See the Docker image section or the docker-arena repository for information about running this standalone.

Note that because Arena is implemented using async/await, Arena only currently supports Node >=7.6.

Using Arena as a node module has potential benefits:

  • Arena can be configured to use any method of server/queue configuration desired
    • for example, fetching available redis queues from an AWS instance on server start
    • or even just plain old reading from environment variables
  • Arena can be mounted in other express apps as middleware

Usage:

In project folder:

$ npm install bull-arena

In router.js:

const Arena = require('bull-arena');

const express = require('express');
const router = express.Router();

const arena = Arena({
  // Include a reference to the bee-queue or bull libraries, depending on the library being used.

  queues: [
    {
      // First queue configuration
    },
    {
      // Second queue configuration
    },
    {
      // And so on...
    },
  ],
});

router.use('/', arena);

Arena takes two arguments. The first, config, is a plain object containing the queue configuration, flow configuration (just for bullmq for now) and other optional parameters. The second, listenOpts, is an object that can contain the following optional parameters:

  • port - specify custom port to listen on (default: 4567)
  • host - specify custom ip to listen on (default: '0.0.0.0')
  • basePath - specify custom path to mount server on (default: '/')
  • disableListen - don't let the server listen (useful when mounting Arena as a sub-app of another Express app) (default: false)
  • useCdn - set false to use the bundled js and css files (default: true)
  • customCssPath - an URL to an external stylesheet (default: null)
Example config (for bull)
import Arena from 'bull-arena';
import Bull from 'bull';

const arenaConfig = Arena({
  Bull,
  queues: [
    {
      type: 'bull',

      // Name of the bull queue, this name must match up exactly with what you've defined in bull.
      name: "Notification_Emailer",

      // Hostname or queue prefix, you can put whatever you want.
      hostId: "MyAwesomeQueues",

      // Redis auth.
      redis: {
        port: /* Your redis port */,
        host: /* Your redis host domain*/,
        password: /* Your redis password */,
      },
    },
  ],

  // Optionally include your own stylesheet
  customCssPath: 'https://example.com/custom-arena-styles.css',

  // Optionally include your own script
  customJsPath: 'https://example.com/custom-arena-js.js',
},
{
  // Make the arena dashboard become available at {my-site.com}/arena.
  basePath: '/arena',

  // Let express handle the listening.
  disableListen: true,
});

// Make arena's resources (js/css deps) available at the base app route
app.use('/', arenaConfig);

(Credit to tim-soft for the example config.)

Example config (for bullmq)
import Arena from 'bull-arena';
import { Queue, FlowProducer } from "bullmq";

const arenaConfig = Arena({
  BullMQ: Queue,
  FlowBullMQ: FlowProducer,
  queues: [
    {
      type: 'bullmq',

      // Name of the bullmq queue, this name must match up exactly with what you've defined in bullmq.
      name: "testQueue",

      // Hostname or queue prefix, you can put whatever you want.
      hostId: "worker",

      // Redis auth.
      redis: {
        port: /* Your redis port */,
        host: /* Your redis host domain*/,
        password: /* Your redis password */,
      },
    },
  ],

  flows: [
    {
      type: 'bullmq',

      // Name of the bullmq flow connection, this name helps to identify different connections.
      name: "testConnection",

      // Hostname, you can put whatever you want.
      hostId: "Flow",

      // Redis auth.
      redis: {
        port: /* Your redis port */,
        host: /* Your redis host domain*/,
        password: /* Your redis password */,
      },
    },
  ],

  // Optionally include your own stylesheet
  customCssPath: 'https://example.com/custom-arena-styles.css',

  // Optionally include your own script
  customJsPath: 'https://example.com/custom-arena-js.js',
},
{
  // Make the arena dashboard become available at {my-site.com}/arena.
  basePath: '/arena',

  // Let express handle the listening.
  disableListen: true,
});

// Make arena's resources (js/css deps) available at the base app route
app.use('/', arenaConfig);

Bee Queue support

Arena is dual-compatible with Bull 3.x and Bee-Queue 1.x. To add a Bee queue to the Arena dashboard, include the type: 'bee' property with an individual queue's configuration object.

BullMQ Queue support

Arena has added preliminary support for BullMQ post 3.4.x version. To add a BullMQ queue to the Arena dashboard, include the type: 'bullmq' property with an individual queue's configuration object.

Docker image

You can docker pull Arena from Docker Hub.

Please see the docker-arena repository for details.

Official UIs

Contributing

See contributing guidelines and an example.

License

The MIT License.

arena's People

Contributors

bogdan avatar bradvogel avatar dependabot[bot] avatar dotob avatar eddiefletchernz avatar elsilentforce avatar evolkmann avatar gcox avatar gtpan77 avatar hoo29 avatar idandagan12 avatar jacobpgn avatar krazyjakee avatar kyleolsondesign avatar mattbrictson avatar maximemaillet avatar olliechick avatar patrickheeney avatar piccirello avatar pklingem avatar pluschnikow avatar randallm avatar roggervalf avatar roychri avatar semantic-release-bot avatar skeggse avatar ttacon avatar valvfr avatar wearhere avatar wescossick avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

arena's Issues

Protected function causing server crash

@chuym We currently protect a number of Bull built-ins when instantiating our Bull interface (https://github.com/mixmaxhq/arena/blob/master/src/server/bull/index.js#L47).

One of these methods, updateDelayTimer, can sometimes cause a server crash:

Error: This function is protected !
    at Queue.protectFunction (/Users/randall/Workspace/arena/src/server/bull/index.js:10:9)
    at RedisClient.<anonymous> (/Users/randall/Workspace/arena/node_modules/bull/lib/queue.js:146:13)
    at emitTwo (events.js:106:13)
    at RedisClient.emit (events.js:194:7)
    at return_pub_sub (/Users/randall/Workspace/arena/node_modules/redis/index.js:781:18)
    at RedisClient.return_reply (/Users/randall/Workspace/arena/node_modules/redis/index.js:828:9)
    at JavascriptRedisParser.returnReply (/Users/randall/Workspace/arena/node_modules/redis/index.js:192:18)
    at JavascriptRedisParser.execute (/Users/randall/Workspace/arena/node_modules/redis-parser/lib/parser.js:574:12)
    at Socket.<anonymous> (/Users/randall/Workspace/arena/node_modules/redis/index.js:274:27)
    at emitOne (events.js:96:13)
    at Socket.emit (events.js:191:7)
    at readableAddChunk (_stream_readable.js:178:18)
    at Socket.Readable.push (_stream_readable.js:136:10)
    at TCP.onread (net.js:561:20)
[nodemon] app crashed - waiting for file changes before starting...

because Bull expects this function to be available in its guardianTimer check (https://github.com/OptimalBits/bull/blob/v1.1.3/lib/queue.js#L229).

Although it is possible through a hack using the non-standard Function.caller property to selectively allow these functions to be called depending on their callers, I think it would be better to remove function protection altogether. I also share the concern that some of these functions should not be called by the module (like updateDelayTimer, for example), but I don't think this will be a problem for us as long as we make sure no unnecessary destructive actions are added in the future.

Thoughts?

Job name not displayed

Hi,

In Arena, when viewing a job, its name is not displayed.
Is that possible to add this info to the Job details page ?

Regards,
Sylvain

`disableListen` is unnecessary

The server only starts listening if Arena is loaded directly i.e. in standalone mode.

When mounting Arena into another server, the client would not be calling run, so run does not need to take an option that disables listening (and I'm not sure why you would call run if you didn't want to listen).

Add filter by status

Hello,
Please add a way to know by message status, which queue has message.
For example, have a location that shows which queues with failed messages. Or what are the queues that have messages in wait.
I have about 200 rows, and it's pretty bad having to open one by one to know the states.
Thanks for listening.

Readme Improvements

I had a real heck of a time understanding how to build a working config for arena. I think it would be a lot more helpful to show a full working config for bee-queue and bull instead of what is in the readme currently.

Here's a working outline for a config for bull setup as an express middleware. I hope this helps other people get up and running!

import Arena from 'bull-arena';

const arenaConfig = Arena({
  queues: [
    {
      // Name of the bull queue, this name must match up exactly with what you've defined in bull
      name: "Notification_Emailer",

      // host name or queue prefix, you can put whatever you want
      hostId: "MyAwesomeQueues",

      // Redis auth
      redis: {
        port: /* Your redis port */,
        host: /* Your redis host domain*/,
        password: /* Your redis password */,
      },
    },
  ],
},
{
  // Make the arena dashboard become available at {my-site.com}/arena
  basePath: '/arena',

  // Let express handle the listening
  disableListen: true
});

// Make arena's resources (js/css deps) available at the base app route
app.use('/', arenaConfig);

All times should be client-localized

For example, if connected to a server on the east coast the timezone returned will be EST regardless of where you are. It would be nice to be able to configure this (or at the very least, explicitly display the timezone range)

Replace dependencies on CDN with local ones

I'm working on a project where we there's no decent internet connection setup.
This basically renders the dashboard useless.
What's your opinion regarding replacing the assets hosted on cdn.jsdelivr.net with local ones.
This will affect the jquery, bootstrap and highlightjs.

<!-- Bootstrap core CSS -->
<link rel="stylesheet" href="https://cdn.jsdelivr.net/bootstrap/3.3.7/css/bootstrap.min.css">
<link rel="stylesheet" href="{{ basePath }}/dashboard.css">
<!-- JSON Viewer -->
<link rel="stylesheet" href="//cdnjs.cloudflare.com/ajax/libs/highlight.js/9.12.0/styles/default.min.css">
<script src="//cdnjs.cloudflare.com/ajax/libs/highlight.js/9.12.0/highlight.min.js"></script>
<script>hljs.initHighlightingOnLoad();</script>

Zero configuration deployment

I'd like to suggest that Arena get it's own configuration and other settings from a settings interface. That way, it's ready to go out of the box and the user can configure redis servers and other settings while it's still running.

We should of course keep backwards compatibility with config files by loading that data into Arena's database. I think the "database" could be stored as a json blob in a redis instance defined by the user.

Alternatively, the more advanced features being requested in the issues could benefit from some kind of robust local database which can be more complexly queried. Perhaps the design decision on where to store the Arena configurations should be come after deciding if we should do something as complex as synchronising a queryable database with redis queues (only while the arena client is being used): #23

Perhaps lokijs is good enough with the ability to download backups of the configurations? That way Arena can remain standalone.

Production mode

Can someone explain me... does it works in production mode? I try to compile with production flag and cannot get it work. Of course I test it remotely.

job : Cannot read property 'name' of undefined

sometime error when click job.

9/20/2017 4:07:05 PMArena is running on port 4567
9/20/2017 4:07:08 PM/opt/arena/node_modules/bull/lib/job.js:434
9/20/2017 4:07:08 PM var job = new Job(queue, json.name || Job.DEFAULT_JOB_NAME, json.data, json.opts);
9/20/2017 4:07:08 PM ^
9/20/2017 4:07:08 PM
9/20/2017 4:07:08 PMTypeError: Cannot read property 'name' of undefined
9/20/2017 4:07:08 PM at Function.Job.fromJSON (/opt/arena/node_modules/bull/lib/job.js:434:32)
9/20/2017 4:07:08 PM at Redis. (/opt/arena/node_modules/bull/lib/queue.js:309:23)
9/20/2017 4:07:08 PM at emitThree (events.js:135:13)
9/20/2017 4:07:08 PM at Redis.emit (events.js:216:7)
9/20/2017 4:07:08 PM at Redis.exports.returnReply (/opt/arena/node_modules/ioredis/lib/redis/parser.js:116:14)
9/20/2017 4:07:08 PM at JavascriptRedisParser.returnReply (/opt/arena/node_modules/ioredis/lib/redis/parser.js:27:13)
9/20/2017 4:07:08 PM at JavascriptRedisParser.execute (/opt/arena/node_modules/redis-parser/lib/parser.js:574:12)
9/20/2017 4:07:08 PM at Socket. (/opt/arena/node_modules/ioredis/lib/redis/event_handler.js:107:22)
9/20/2017 4:07:08 PM at emitOne (events.js:115:13)
9/20/2017 4:07:08 PM at Socket.emit (events.js:210:7)
9/20/2017 4:07:08 PM at addChunk (_stream_readable.js:252:12)
9/20/2017 4:07:08 PM at readableAddChunk (_stream_readable.js:239:11)
9/20/2017 4:07:08 PM at Socket.Readable.push (_stream_readable.js:197:10)
9/20/2017 4:07:08 PM at TCP.onread (net.js:588:20)
9/20/2017 4:07:08 PM[nodemon] app crashed - waiting for file changes before starting...

queueJobsByState.js missing basePath

When opening in a new tab for other pages, URL does not include the basePath. This is because basePath value is not passed into the template.

Require error

NodeJS version: v6.10.2
Bull-arena version: 2.2.2

Just try to require 'bull-arena' module:

const Arena = require('bull-arena');

Got an error:

/home/username/folder/node_modules/bull-arena/src/server/views/dashboard/queueDetails.js:4
async function handler(req, res) {
      ^^^^^^^^
SyntaxError: Unexpected token function
    at createScript (vm.js:56:10)
    at Object.runInThisContext (vm.js:97:10)
    at Module._compile (module.js:542:28)
    at Object.Module._extensions..js (module.js:579:10)
    at Module.load (module.js:487:32)
    at tryModuleLoad (module.js:446:12)
    at Function.Module._load (module.js:438:3)
    at Module.require (module.js:497:17)
    at require (internal/module.js:20:19)
    at Object.<anonymous> (/home/username/folder/node_modules/bull-arena/src/server/views/dashboard/index.js:4:22)

What's wrong with it?

Can you help me with setup

Not sure if I'm reading the instructions properly, need clarification:

Here is what I have so far:

//bull setup
var test= new Queue('test');

//arena setup
const arena = Arena({
"name": "test",
"port": 6381,
"host": "127.0.0.1",
"hostId": "Server Name"
});
app.use('/arena', arena);

Right now no ques are showing up, its empty. What am I doing wrong?

Retry jobs only processing # of processes

Hey guys, when we use bull-arena and try to retry failed jobs, we only process through the total # of running workers of bull.

So for example in our queue we instantiate the number of processes like this:

logHandlerQueue.process(5, path.resolve(__dirname, 'handlers.js'))

And then when we retry jobs, only 5 runs at once, each time. The rest just go directly back into the fail queue and not wait. Is this intended?

Specify a basePath from the config file

I'd like to propose the following enhancement to allow specifying a base path from the config file.

The config file would be changed to:

{
  "__example__listenOpts": {
    "basePath": "/arena"
  },
  "listenOpts": {
  },
  "__example_queues": [
    {
      "name": "my_queue",
      "port": 6381,
      "host": "127.0.0.1",
      "hostId": "AWS Server 2"
    }
  ],
  "queues": []
}

And simple check in app.js file:

  if (defaultConfig.listenOpts && defaultConfig.listenOpts.basePath) {
    app.locals.basePath = defaultConfig.listenOpts.basePath;
  } else {
    app.locals.basePath = '';
  }

I'll volunteer to create a PR for it, assuming you'd like to pull it in.

Thanks

Reactify the client?

So I am biased as I know react and love jsx templating. I'd like to get your opinions on this as I feel we could dumb down the back-end to a simple json api while the front-end could be snappier and implementing live updates would be a sinch.

I understand this is my code but I wanted a quick solution to getting some page-specific javascript going. The dependency code is also hideous and we can do better.

So what are your thoughts on getting React and some proper front-end dependency management going?

Job count not reflected on 3.0.0-rc.4

The dashboard does not seem to reflect the actual statuses. Find image below

screen shot 2017-08-05 at 7 33 39 pm

Here are the keys from the CLI

127.0.0.1:6379> keys *
1) "bull:deactivate user:2"
2) "bull:deactivate user:failed"
3) "bull:deactivate user:1"
4) "bull:deactivate user:id"
127.0.0.1:6379>

Here's my index.json

{
  "__example_queues": [
    {
      "name": "my_queue",
      "port": 6381,
      "host": "127.0.0.1",
      "hostId": "AWS Server 2"
    }
  ],
  "queues": [{
    "name": "aws-queue",
    "port": 6379,
    "host": "X.X.X.X",
    "hostId": "AWS Queue",
    "password": "XXX"
  }]
}

I'm using the docker image, if that is helpful.

add resend of a completed message

Hello,
It may seem strange, but it would be very useful to me.
If they can include this option.
It already exists in failed messages, but does not exist in completed messages.
Thanks for listening

Please fix README

After going through the docs, it would be helpful to specify that the first parameter passed to Arena is a javascript object literal with one key value pair called queues that is meant to be an array of all of your queues.

I was able to infer this by context given that queues is plural and by having to look at the index.json file linked. This however could have been avoided by just showing the usage of the API as such:

const fooQueue = {
    name: 'foo',
    port: 6379,
    host: '127.0.0.1',
    hostId: 'queues',
 };

 const arena = Arena({ queues: [fooQueue] }, listenOptions);

This will make it easier for people to infer less and also for those not familiar with the property value shorthand in object literals as used in the docs {queues}.

adding host adress

in the index.js
we want to add the hostadress "127.0.0.1 "to the app.listen.
Thats not possible now? or am i missing something

Can the index.js file be something like the one below:

const port = listenOpts.port || 4567
// START NEW FEATURE -->
// #############################################
// add this option const
const host= listenOpts.host || '0.0.0.0';
// #############################################
// <-- END NEW FEATURE
if (!listenOpts.disableListen) {
app.listen(port, host, () => console.log(Arena is running on port ${port} at host ${host}));
}

Support for filtering jobs

It would be nice to filter jobs in a particular state given some criteria. The most useful use case in my opinion is searching for failed jobs whose first error matches some search term.

Job progress bar doesn't work with Bull v3

It appears that Bull v3 (precisely, 3.0.0-rc.4) returns a job's JSON object with _progress holding the progress field, instead of just progress. Thus, the progress bar in arena always effectively shows 0 percent.

logging the JSON object returned from the Queue class gives:

{ opts: { attempts: 1, delay: 0, timestamp: 1504061405201 },
  name: '__default__',
  queue: 
   Queue {
     name: 'disc ripping',
     token: '39700d85-c68a-427c-876a-e5aea5fb3d17',
     keyPrefix: 'bull',
     _initializing: 
      Promise {
        _bitField: 33554432,
        _fulfillmentHandler0: undefined,
        _rejectionHandler0: undefined,
        _promise0: undefined,
        _receiver0: undefined },
     handlers: {},
     processing: [],
     retrieving: 0,
     settings: 
      { lockDuration: 30000,
        stalledInterval: 30000,
        maxStalledCount: 1,
        guardInterval: 5000,
        retryProcessDelay: 5000,
        drainDelay: 2000,
        lockRenewTime: 15000 },
     _events: { error: [Function] },
     _eventsCount: 1,
     timers: TimerManager { idle: true, listeners: [], timers: {} },
     moveUnlockedJobsToWait: [Function: bound ],
     processJob: [Function: bound ],
     getJobFromId: [Function: bound ],
     IS_BEE: false },
  data: { something: 'somethingelse' },
  _progress: 100,
  delay: 0,
  timestamp: 1504061405201,
  stacktrace: [],
  returnvalue: 18,
  attemptsMade: 0,
  id: '20',
  finishedOn: 1504061415220,
  processedOn: 1504061405209,
  failedReason: undefined,
  jobState: 'completed',
  queueHost: 'ncodr',
  queueName: 'disc ripping',
  basePath: '' } { name: 'log',
  hash: {},
  data: 
   { exphbs: 
      { cache: false,
        view: 'dashboard/templates/jobDetails',
        layout: '/ncodr/node_modules/bull-arena/src/server/views/layout',
        data: undefined,
        helpers: {},
        partials: [Object],
        filePath: '/ncodr/node_modules/bull-arena/src/server/views/dashboard/templates/jobDetails.hbs' },
     _parent: { exphbs: [Object] },
     root: 
      { settings: [Object],
        Queues: [Object],
        basePath: '',
        queueName: 'disc ripping',
        queueHost: 'ncodr',
        jobState: 'completed',
        job: [Object],
        _locals: {},
        cache: false } } }

Which ends up with a display looking like:
image

instead of a full across progress bar. In my troubleshooting, just changing to this._progress in src/server/views/partials/dashboard/jobDetails.hbs solves it. However, I would guess that Bee uses progress, and so the difference would need to be accounted for in arena somehow.
Maybe it's possible to alias _progress to progress if bull is being used from within jobDetails.js?

However, interestingly, when adding the following line in jobDetails.js (around line 28), I get correct output in the log:
console.log('jobdetails -- progress: ' + job.progress());

When running as a node module, arena cannot be nested within a router

I'm running arena as a node module alongside the rest of my app. For this use case it would be great to be able to nest it within a router so that the dashboard could be accessed at someapp.com/arena/dashboard for instance, like this:

const arenaRouter = arena({ queues: getArenaConfig() }, true)
router.use('/arena', arenaRouter)

This is not currently possible, because all href links within the dashboard (and assets) are referenced directly at the root, i.e. <a href="/dashboard/..."></a>

Authentication

I'd like my Arena instance to be effortlessly protected from prying eyes. Perhaps a configuration option for setting a password? The user would need to enter a password to access the interface.

Interface polish

  • Sort Queues in the overview alphabetically.
  • "Queue Navigation Tree" is basically breadcrumbs, let's take back that real-estate and have a horizontal breadcrumb at the top.
  • Put some system statistics in the overview. Ok nvm this
  • Make statistic numbers human readable (gb, mb etc). #42
  • Localize times #27

Other than that, I love the simplicity of this queue manager.

calling done with error doesnt fail the job on Arena

I've setup a bee-queue with arena and In my local env, and I execute jobs as following

queue.process(async function (job, done) {

console.log(`Processing job ${job.id}`);
job.reportProgress(5);
let res = await my_service.execute(job);
if(res.status) {
  //report job progress
  job.reportProgress(100);
  return done(null, res.msg);
} else {
  done(new Error(res.msg));
  
}

});

In an failure case, I do see on my flow that the done(new Error(res.msg)); is being called and I also debugged the done function and I see it rejects the promise. However, when I look at the job on Arena I see it in success section instead the Failed ones

Please advise...

README clarification regarding authentication

It is not obvious from the README that credentials must be provided per-queue. An example would be helpful, something like

const arena = Arena({
	queues: [
		{
		  "name": "****",
		  "hostId": "*******",
		  "host": "*******",
		  "port": xxxxx,
		  "password": "**********************",
		},
		{
			// etc

Can't see job types

Hello, I tried following instructions but I can't see job types, I can however see everything else.
Would be really thankful if someone could point out what I'm doing wrong.

const queues = [{
    "name": "ticketVerification",
    "port": 6379,
    "host": "127.0.0.1",
    "hostId": "main"
  }]

const arena = Arena({
  queues: queues
});

const verificationQueue = new Queue('ticketVerification', 'redis://127.0.0.1:6379');

app.use('/', arena);

If I type in redis-cli keys *, I can see

127.0.0.1:6379> keys *
1) "bull:ticketVerification:1"
2) "bull:ticketVerification:id"
3) "bull:ticketVerification:failed"

I've attached screenshot.

Thank you very much for trying to help!
problem

Crashes when jobs are being processed

Running Arena 2.1.1 in docker. Arena crashes when opened in browser and application is processing jobs. Application itself runs smoothly (uses bull v3.0.0-rc7). Here's the log:

/opt/arena/node_modules/bull/lib/job.js:434
var job = new Job(queue, json.name || Job.DEFAULT_JOB_NAME, json.data, json.opts);
                                                ^

TypeError: Cannot read property 'name' of undefined
at Function.Job.fromJSON (/opt/arena/node_modules/bull/lib/job.js:434:32)
at Redis. (/opt/arena/node_modules/bull/lib/queue.js:309:23)
at emitThree (events.js:135:13)
at Redis.emit (events.js:216:7)
at Redis.exports.returnReply (/opt/arena/node_modules/ioredis/lib/redis/parser.js:116:14)
at JavascriptRedisParser.returnReply (/opt/arena/node_modules/ioredis/lib/redis/parser.js:27:13)
at JavascriptRedisParser.execute (/opt/arena/node_modules/redis-parser/lib/parser.js:574:12)
at Socket. (/opt/arena/node_modules/ioredis/lib/redis/event_handler.js:107:22)
at emitOne (events.js:115:13)
at Socket.emit (events.js:210:7)
at addChunk (_stream_readable.js:252:12)
at readableAddChunk (_stream_readable.js:239:11)
at Socket.Readable.push (_stream_readable.js:197:10)
at TCP.onread (net.js:588:20)

Human readable queue statistics (i.e. `used_memory`)

It would be great if there was the ability to provide a, more easily, human readable format for used_memory. At the moment you can't simply glance at it and ingest the provided information.

Specifically, it would be great if this was more easily human readable:
used_memory

Ability to add a job

This is super useful for debugging purposes. I can test the process functions on jobs by quickly adding them and varying the data.

  • Add a button in the Queue overview "Add Job"
  • On click open an empty JSON editor for the user to populate.
  • On submit, show a success notification but keep the data in the editor for further debugging.
  • Add a close button to clear and close the JSON editor.

Implement move a task to another queue

Please implement the function of moving a job from one queue to another queue.

I ask this, then, I sent 90 messages to one queue and should have sent them to another. Typing error. So I had no way to move, I had to redo everything, a little work.

Thanks for listening

Live updates

Please forgive my lack of redis knowledge, but do any events in this library allow for redis to trigger an update in the server and therefore client? https://github.com/NodeRedis/node_redis - We're getting into websocket or long-poll territory then and perhaps that's going overboard.

If not, I guess a front-end interval would suffice. Since this would be ajaxy as hell, I suggest we perhaps solve this issue first: #58

I'd like to see a job go from state to state without clicking a thing.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.