You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current implementation of the jobs queue (the engine in charge of running and orchestrating workflows executions) is built in top of msavin:sjobs-ui-blaze, which at the same time is built in top of MeteorJS.
The new Jobs queue service should be created from the scratch, not using either msavin:sjobs-ui-blaze or MeteorJS. This will allow to:
Run the queue either as a separate process, or within the same process as Tideflow's
Run the queue in a separate machine or server
Let the jobs and Tideflow itself to use separate database connections
Do not depend in possible obsolete or unmaintained MeteorJs packages.
Possiblity to fork queues processes for blazzing fast performance.
To have a separate dashboard to see metrics on the queue.
To be discussed:
How to keep modularity? as the services will run on the queue, but they also have visual elements that are rendered on the main application.
The current implementation of the jobs queue (the engine in charge of running and orchestrating workflows executions) is built in top of
msavin:sjobs-ui-blaze
, which at the same time is built in top of MeteorJS.The new Jobs queue service should be created from the scratch, not using either msavin:sjobs-ui-blaze or MeteorJS. This will allow to:
To be discussed:
Subtasks
workflow-start
workflow-step
RewriteEliminate jobworkflow-execution-notify-email
workflow-execution-finished
_executionLogsRun
_executionLogsSendEmail
s-cron-runOne
s-rss-runOne
s-rss-schedule
server/service
to the new queueThe text was updated successfully, but these errors were encountered: