Open davidediruscio opened 4 years ago
in addition @ambpro : the task is showing "completed" with 100% which is not true. It should be catched at some point.
I think it has no relation with the heart of this issue but I just realized that the metric provider array above doesn't include the related needed dependencies...
The default time out period for OKHTTP is 10 seconds. In commit d7444f9df3c48c480412d30d9235beb959d4d631 I increased the period of time before a timeout is triggered from 10 seconds to:
30
Seconds for Connection1
Minute for Read1
Minute for Write
Let me know if this change helps with this issue.
Thanks @Danny2097. the timeout delay is one thing. Now, as mentioned in my initial comment, what's done after it has been triggered ? Is there a retry ?
The metrics providers above still incomplete. Within the metric-platform, each metric could have or not a set of dependencies: take a look on the http://scava-dev.ow2.org:8182/analysis/metricproviders.
Right now, the validation of the dependencies is done on admin-ui front end and not on the backend endpoint to create a new task /analysis/task/create
.
By looking on the list you have provided, I figure out that it contains only the metricIDs without metricDependenciesIDs.
The metrics providers above still incomplete.
Yes I am aware, and noticed what you mentioned. I did wrote a system to resolve the dependencies in my provisionning script. This being said I'm not sure it's related to the current issue. I'll do another test.
The easy way to reproduce is to issue the following, from the box hosting the docker stack when the task runs:
$ sudo iptables -I FORWARD 1 -d gitlab.ow2.org -j DROP
And my other comment above is still valid:
in addition @ambpro : the task is showing "completed" with 100% which is not true. It should be catched at some point.
If needed I can open a new issue for the later.
Thanks @Danny2097. the timeout delay is one thing. Now, as mentioned in my initial comment, what's done after it has been triggered ? Is there a retry ?
Hi @mhow2, sorry for the delay I have just returned from annual leave. The answer to your question quoted above is no. None of our readers have retry mechanisms built into them as this feature was not requested during discussions in L'Aquila.
No requested ok, but does it sound logical to you to have a retry ? What doesn't sound good to me is when it fails, it is perfectly silent. The end user should know, at least from the UI (@ambpro) that a task got interrupted and ended prematurely, along with the reason to it.
@ambpro , @aabherve , @Danny2097 : I suggest we implement a warning somewhere in the UI when a task got interrupted unexpectedly and say why and when. So we can distinguish tasks that have finished with success and tasks that have aborted because of a system error.
@mhow2,
in addition @ambpro : the task is showing "completed" with 100% which is not true. It should be catched at some point.
I pushed a commit (3a10b83) containing a patch which should move automatically a failed task to ERROR
status, it also cleans up the worker and log the error on the stack traces view.
Consequently, the global status of a project will be in addition to No Data
- In Progress
- Up To Date
the status Error
.
Does it makes sense now?
@mhow2,
I think it has no relation with the heart of this issue but I just realized that the metric provider array above doesn't include the related needed dependencies...
ICYMI, I implemented recently within the services /analysis/task/create
and /analysis/task/update
(see https://github.com/crossminer/scava/issues/345#issuecomment-528851252) a way to validate dependencies on the server side before creating or updating a task.
Project: https://gitlab.ow2.org/sat4j/sat4j Time Span : 2018 Metrics : narrowed to the list below (eg. our Project Scenario).
As an user, I would expect the system not to stop the task but at least to retry X times the last operation or something like that before throwing in the towel.
Exception: