It works perfect - thank you!

2016-10-17 21:08 GMT+02:00 Niphlod <niph...@gmail.com>:

> the bug has already been fixed in trunk.
> You can copy/paste the scheduler.py file from master if you want it
> solved, or either pass next_run_time equal to start_time to make things
> work the way they were.
>
> On Sunday, October 16, 2016 at 8:30:23 AM UTC+2, mweissen wrote:
>>
>> Thank you, but start_time has a value.
>> start_time is a paramter of the surrounding function.
>> I have tested it with
>> task_name = task_name + str(start_time)
>> and therefore I have written start_time != None
>>
>> 2016-10-15 19:59 GMT+02:00 Dave S <snide...@gmail.com>:
>>
>>>
>>>
>>> On Saturday, October 15, 2016 at 6:27:33 AM UTC-7, mweissen wrote:
>>>>
>>>> It seems that the start_time parameter in a scheduler_task record does
>>>> not work correctly.
>>>>
>>>> For example:
>>>>
>>>> I add a record to scheduler_task which should start the function
>>>> "smsEmailAussenden" (means "send the email") at 16:00
>>>>
>>>> I expect the email to be sended at 16:00, but it starts immediately. At
>>>> 14:45 all is done...
>>>>
>>>> I use this code to add a new task. All names without a value are
>>>> parameters of the function containing this statement. start_time != None
>>>>
>>>>        tasknr = db.scheduler_task.insert(
>>>>             status='QUEUED',
>>>>             application_name='secure',
>>>>             task_name=task_name,
>>>>             function_name='smsEmailAussenden',
>>>>             args = dumps([aussendungNr]),
>>>>             vars={},
>>>>             enabled=True,
>>>>             start_time=start_time or datetime.datetime.now(),
>>>>
>>>
>>> So if start_time hasn't been set anywhere in your queuing code, it runs
>>> now.
>>> The start_time value on the right side is a (local) variable, not the
>>> previous value of the parameter.
>>>
>>>
>>>
>>>>             stop_time=stop_time or (datetime.datetime.now()+timed
>>>> elta(days=1)),
>>>>
>>>             repeats=1,
>>>>             retry_failed=1,
>>>>             period=800,
>>>>             timeout=200,
>>>>         )
>>>>
>>>> Some months ago this code worked without problems.
>>>> What has changed inside the scheduler?
>>>>
>>>>
>>> The scheduler has been stable across a couple of releases, I think.  My
>>> once-a-day code has been working very well for several months.
>>>
>>> /dps
>>>
>>>
>>>
>>>
>>>> Id: 913997
>>>> Application Name:
>>>> Task Name:
>>>> Group Name:
>>>> Status: QUEUEDRUNNINGCOMPLETEDFAILEDTIMEOUTSTOPPEDEXPIRED
>>>> Function Name: checkschedulerentlassenSendengetstatus1idmauswertung
>>>> kontrollemailmitteilungmahnungparse_emailparse_pushemail
>>>> rundschreibenSendensendeprotokollSendensendprotsendrssmsEmailAussenden
>>>> test
>>>> Uuid:
>>>> Args:
>>>> ×
>>>> ×
>>>> ×
>>>>
>>>> Vars:
>>>> ×
>>>> ×
>>>> ×
>>>>
>>>> Enabled:
>>>> Start Time:
>>>> Next Run Time:
>>>> Stop Time:
>>>> Repeats: 0=unlimited
>>>> Retry Failed: -1=unlimited
>>>> Period: seconds
>>>> Prevent Drift: Cron-like start_times between runs
>>>> Timeout: seconds
>>>> Sync Output: update output every n sec: 0=never
>>>> Times Run:
>>>> Times Failed:
>>>> Last Run Time:
>>>> Assigned Worker Name:
>>>>
>>>>
>>>> Any ideas?
>>>> Regards, Martin
>>>>
>>>>

-- 
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
--- 
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to web2py+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to