Hi guys,
 
About Synchronization Task I would like to know how Syncope works and what's 
the expected behavior.
 
In particulare what's happen if I submit a Sync Task Request while this an 
already started synch task under execution? 
Submitted request it's queued or discarded ? 
 
And about tracing/logging of Task Executions. 
Is there a cache (writes or reads) that can delay logging Task Executions on 
console?
 
Many thanks,
Denis.
 
-----Messaggio originale-----
Da: Daniel DeFreez [mailto:[email protected]]
Inviato: lunedì 23 luglio 2012 16.42
A: [email protected]
Oggetto: Re: Trouble running synchronization tasks



Hi Daniel,
sorry for late response.

Even though you've found how to get things working, your experience seems to 
confirm my feelings about everything that can be executed in Syncope (tasks and 
reports) and the admin input from console.

In particular, I'd like to modify the console behavior so that a new execution 
cannot be requested until a task or a report is already under execution: of 
course we'd need some handle to prevent or recover from race or other error 
conditions...

WDYT?

-- 

Francesco Chicchiriccò



ASF Member, Apache Cocoon PMC and Apache Syncope PPMC Member

http://people.apache.org/~ilgrosso/




Thank you for your reply. It is appreciated.


>From the perspective of someone who is trying to learn how to use Syncope, one 
>of the most helpful improvements would be feedback in the console as to why a 
>task did not run. This is distinct from the success/failure result of a task 
>after execution. After a task execution is requested, there does not appear to 
>be any feedback as to whether or not the task will actually run, or why it did 
>not run. When executing a task, the only feedback is 'Operation executed 
>successfully,' even if the task may fail to run. The last execution date 
>should update under all conditions with the result. If the result is something 
>like 'Cannot execute more than one instance of this task,' or whatever the 
>actual error is, that would be great. 


Daniel

Reply via email to