one time task scheduler patch

1 view
Skip to first unread message

Daniel Fetchinson

unread,
Feb 3, 2008, 2:00:55 AM2/3/08
to turbogea...@googlegroups.com
Hello tg people, here is a small patch (against the 1.0 branch trunk)
that allows one to schedule one-time tasks via the
turbogears.scheduler.add_onetime_task function. It's basically the
same as interval_task but doesn't reschedule. I found this to be
useful for starting long running processes when the client is not
required to wait for the result.

BTW, is this list the right place for submitting patches?

Cheers,
Daniel

onetime.patch

Daniel Fetchinson

unread,
Feb 3, 2008, 2:04:33 AM2/3/08
to turbogea...@googlegroups.com
> BTW, is this list the right place for submitting patches?

Just noticed on http://docs.turbogears.org/Contributing that patches
should go to trac as new tickets after discussion so I guess I'm
asking for comments now.

Cheers,
Daniel

Christopher Arndt

unread,
Feb 3, 2008, 7:20:07 AM2/3/08
to turbogea...@googlegroups.com
Daniel Fetchinson schrieb:

Hi Daniel,

nice patch! I'll have a closer look at it later today. I think this is a
useful addition, so I suggest you go ahead and create an enhancement ticket.

Please note that new features should go to the 1.1 branch now. Can you
make a new patch for the 1.1 branch? Also, please format your source
code according to PEP 8:

http://www.python.org/dev/peps/pep-0008/

Chris

Daniel Fetchinson

unread,
Feb 3, 2008, 1:55:28 PM2/3/08
to turbogea...@googlegroups.com
> nice patch! I'll have a closer look at it later today. I think this is a
> useful addition, so I suggest you go ahead and create an enhancement ticket.

It's http://trac.turbogears.org/ticket/1709

> Please note that new features should go to the 1.1 branch now. Can you
> make a new patch for the 1.1 branch?

Yep, it's now for the 1.1 branch.

> Also, please format your source code according to PEP 8:
>
> http://www.python.org/dev/peps/pep-0008/

As far as I can tell the formatting is correct. I changed the Onetime
name to Single so now the classes are SingleTask, ThreadedSingleTask,
ForkedSingleTask and the function add_single_task.

Cheers,
Daniel

Kevin Horn

unread,
Feb 3, 2008, 2:06:33 PM2/3/08
to turbogea...@googlegroups.com
Created ticket in trac (#1710)

http://trac.turbogears.org/ticket/1710

Kevin Horn

Kevin Horn

unread,
Feb 3, 2008, 2:57:36 PM2/3/08
to turbogea...@googlegroups.com
Sorry for the duplicate ticket, Daniel.  Just trying to make sure your patch didn't get lost in the shiffle.

Kevin Horn

Daniel Fetchinson

unread,
Feb 3, 2008, 3:04:17 PM2/3/08
to turbogea...@googlegroups.com
> Sorry for the duplicate ticket, Daniel. Just trying to make sure your patch
> didn't get lost in the shiffle.

No problem :)
Just noticed the duplicate, the thing is that on the version I sent to
the mailing list from which you created ticket/1710 the names were
such as OnetimeTask, add_onetime_task, etc and on ticket/1709 I
renamed them to SingleTask, add_single_task, etc because Chris
mentioned PEP-8 which I took to mean that Onetime should be OneTime
which didn't look very good to me.

In addition ticket/1709 is for trunk 1.1 while ticket/1710 is for
trunk 1.0 (although as far as I can tell scheduler.py is the same),
again something Chris asked for so I guess 1709 is the relevant ticket
not 1710 (although as things are marked now, 1709 is closed and 1710
is open). Kinda confusing :)

Cheers,
Daniel

Christopher Arndt

unread,
Feb 3, 2008, 3:47:16 PM2/3/08
to turbogea...@googlegroups.com
Daniel Fetchinson schrieb:

>> Sorry for the duplicate ticket, Daniel. Just trying to make sure your patch
>> didn't get lost in the shiffle.
>
> No problem :)
> Just noticed the duplicate, the thing is that on the version I sent to
> the mailing list from which you created ticket/1710 the names were
> such as OnetimeTask, add_onetime_task, etc and on ticket/1709 I
> renamed them to SingleTask, add_single_task, etc because Chris
> mentioned PEP-8 which I took to mean that Onetime should be OneTime
> which didn't look very good to me.

No, I meant the improper white space after opening parantheses and such
things.

Anyway, I'm just in the process of cleaning up the whole scheduler
mdoule and making it PEP-8 compliant. I'll then integrate your new patch
with the new names (which I like better). It'll be ready in a couple of
minutes.

> In addition ticket/1709 is for trunk 1.1 while ticket/1710 is for
> trunk 1.0 (although as far as I can tell scheduler.py is the same),
> again something Chris asked for so I guess 1709 is the relevant ticket
> not 1710 (although as things are marked now, 1709 is closed and 1710
> is open). Kinda confusing :)

I don't think we should have two different tickets for the same issue
for the different branches. New features should go in bramch 1.1 and if
we want to backport them to 1.0, we can open a ticket for this task once
the feature is complete in 1.1.

Chris

Christopher Arndt

unread,
Feb 3, 2008, 4:27:08 PM2/3/08
to turbogea...@googlegroups.com
Christopher Arndt schrieb:

> Anyway, I'm just in the process of cleaning up the whole scheduler
> mdoule and making it PEP-8 compliant. I'll then integrate your new patch
> with the new names (which I like better). It'll be ready in a couple of
> minutes.

The new patch is now added. Can somebody else please review the
functions as well?

BTW, there seem to be no unit tests for the scheduler module. Should we
open a ticket for this?

Chris

Kevin Horn

unread,
Feb 3, 2008, 4:37:17 PM2/3/08
to turbogea...@googlegroups.com
Yes there should be a ticket for this.  Now there is :)
http://trac.turbogears.org/ticket/1712

Felix Schwarz

unread,
Feb 4, 2008, 4:07:48 PM2/4/08
to turbogea...@googlegroups.com

I like to high-jack this thread for some general question about the
scheduler in TG2.

As far as I understand, TG2 will be based on Pylons which seems to use a
FastCGI configuration (at least as recommend production environment)
instead of a custom server like CherryPy. If this is true, it has some
serious implications for "server plugins" like the scheduler or TurboMail.

Previously we could rely on the server which was always available. FastCGI
processes will be killed after a certain amount of request (or a configured
time) so it must not be assumed that at least one process is always
running. (Am I completely wrong?)

Do you have some ideas how to deal with this problem?

fs

Mark Ramm

unread,
Feb 4, 2008, 4:19:36 PM2/4/08
to turbogea...@googlegroups.com
I don't expect the standard deployment of TG2 to be much different
than TG1. We'll have a process (some wsgi server) that is
long-running, and AFIK that's the general way that pylons is deployed
right now too.

FastCGI may be supported, but it's far from the default in pylons
anymore... Seems like lots of people are using ModWSGI these days.

--Mark

--
Mark Ramm-Christensen
email: mark at compoundthinking dot com
blog: www.compoundthinking.com/blog

Reply all
Reply to author
Forward
0 new messages