it really doesn't matter. the IPC is done on the database, so having local
workers hitting it or remote ones doesn't turn into more transactions.
On Friday, January 27, 2017 at 6:08:56 PM UTC+1, Jason Solack wrote:
>
> In your scenario do you have 10 workers on multiple machines? So having
> 5
In your scenario do you have 10 workers on multiple machines? So having 5
workers on 1 machine and 5 on another? we can easily do 10 workers, but we
run into issues when we have them split across machines
On Thursday, January 26, 2017 at 2:43:19 PM UTC-5, Niphlod wrote:
>
> I think I posted t
I think I posted the relevant number of queries issued to the backend for a
given number of workers but I do daily use the scheduler on an mssql db and
it can easily handle at least 10 workers (with the default heartbeat).
Locking kicks in maybe once or twice a day, which means 1 or 2 on 28800
On Thursday, January 26, 2017 at 9:45:20 AM UTC-8, Jason Solack wrote:
>
> using mssql, the code itself is in gluon scheduler.py - this happens with
> no interaction from the app
>
>
How do you instantiate the Scheduler?
Is the mssql engine on the same machine as any of the web2py nodes? Are
th
using mssql, the code itself is in gluon scheduler.py - this happens with
no interaction from the app
On Thursday, January 26, 2017 at 12:03:41 PM UTC-5, Dave S wrote:
>
>
>
> On Thursday, January 26, 2017 at 8:44:25 AM UTC-8, Jason Solack wrote:
>>
>> So the issue is we run 6 workers on a machin
On Thursday, January 26, 2017 at 8:44:25 AM UTC-8, Jason Solack wrote:
>
> So the issue is we run 6 workers on a machine and it works. If we do 3
> workers on 2 machines we get deadlocks. That is no exaggeration - 6
> records in our worker table and we're getting dealocks.
>
>
Which DB are yo
So the issue we run 6 workers on a machine and it works. If we do 3
workers on 2 machines we get deadlocks. That is no exaggeration - 6
records in our worker table and we're getting dealocks.
On Wednesday, January 25, 2017 at 3:05:37 AM UTC-5, Niphlod wrote:
>
> you *should* have one different
you *should* have one different db for each environment. Each scheduler
tied to the same db will process incoming tasks, and it doesn't matter what
app effectively pushes them.
This is good if you want to have a single scheduler (which can be composed
by several workers) serving many apps, but *
On Tuesday, January 24, 2017 at 1:59:31 PM UTC-8, Jason Solack wrote:
>
> Hello all,
>
> I'm having some re-occurring issue with the scheduler. We are currently
> running multiple environments (production, beta) and have several nodes in
> each environment. If we have scheduler services runnin
9 matches
Mail list logo
