Hi, your tip really worked. Thanks. Please see the code below:
DAL:
indiban_meses = Meses.on(Indiban.meses_id == Meses.id)
indiban_anos = Anos.on(Indiban.anos_id == Anos.id)
indiban_indicadores = Indicadores.on(Indiban.indicadores_id ==
Indicadores.id)
indiban_empresas = Empresas.
there was an issue on more than 1kb that showed pretty much a limit on
python's implementation, that's solved in recent releases of the scheduler
but I wonder if the "tax" on that sem_wait() is trying to flush off or read
the buffered output of the task.
On Friday, November 4, 2016 at 11:50:14
On Friday, November 4, 2016 at 10:44:31 PM UTC+1, Niphlod wrote:
>
> BTW: do your task write a lot on stdout/stderr and/or return huge results ?
>
Probably. I wrote into the log more than usual. :( Mostly DEBUGs - it's
possible to switch off them.
--
Resources:
- http://web2py.com
- http://web2
BTW: do your task write a lot on stdout/stderr and/or return huge results ?
On Friday, November 4, 2016 at 10:43:34 PM UTC+1, Niphlod wrote:
>
> well, on unix python docs report that p.terminate() use sigkill, so I
> wonder why in your env one works and not the other...
>
> On Friday, November 4,
well, on unix python docs report that p.terminate() use sigkill, so I
wonder why in your env one works and not the other...
On Friday, November 4, 2016 at 8:57:34 AM UTC+1, Erwn Ltmann wrote:
>
> BTW: if I use os.kill(p.pid,signal.SIGKILL) instead of p.termiate()
> everithing is fine.
>
> 11-04
BTW: if I use os.kill(p.pid,signal.SIGKILL) instead of p.termiate()
everithing is fine.
11-04 08:40:59.521 [13556] web2py.Scheduler - DEBUG - MD: terminating (os
> kill)
> 11-04 08:40:59.521 [13556] web2py.Scheduler - DEBUG - MD: terminated
> 11-04 08:40:59.522 [13556] web2py.Scheduler - DEBUG
Sorry for using the term 'zombie'. In the context of unix it is misleading.
On Thursday, November 3, 2016 at 9:25:41 PM UTC+1, Niphlod wrote:
>
> From where I stand, if the result is the task being labelled as TIMEOUT
> (with the corresponding "task timeout" debug line), it can only be
> origina
Got that. Thanks for explaining your POV. What I was trying to say is that
without being able to reproduce, I can only guess. And since the scheduler
code in regards of process handling is quite streamlined, there are not a
lot of places where a zombie can be created.
So, let's guess...
Are zom
@Niphlod: I decided one year ago to use web2py for our projects. And now I
have a problem and I have to solve it (shortly) - with or without the
group. You are so focused on the scheduler code itself. I search for any
hint to understand the problem. It doesn't helps me to know that the
mankind
I'm naturally curious to know the culprit in your env, but unfortunately I
can't reproduce in any of my systems (*buntu 14.04 + postgresql/sqlite or
Win2012r2 + postgresql/sqlite/mssql).
Needs to be said that I mostly hate mysql (and would never trust it nor
recommend to the worst of my enemies
Hi Niphlod,
your replies are always a pleasure to me. :)
On Wednesday, November 2, 2016 at 12:00:48 PM UTC+1, Niphlod wrote:
>
> I'd say there are a LOT of strange things going on on your system, since
> you're reporting several different issues that nobody ever faced and all in
> the last week
I'd say there are a LOT of strange things going on on your system, since
you're reporting several different issues that nobody ever faced and all in
the last week.
zombie processes shouldn't be there unless you killed improperly a worker
process.
Python can't really do anything about it, and t
12 matches
Mail list logo
