#2930 closed enhancement (done)

Prevent UI-Freeze in case of Endpoint-Failure

Reported by: fholzing Owned by: mkommend
Priority: high Milestone: HeuristicLab 3.3.16
Component: Clients.OKB Version: trunk
Keywords: Timeout Cc:

Description

Currently, the class CreateFromExperimentMenuItem Enables/Disables the MenuItem "Upload Runs from Experiment". To do so, it has some logic attached to the OnActiveViewChanged-Event and checks certain aspects of the content of the currently active view, such as if it is null or locked or the user has the required privileges.

A certain flaw emerges during a server outage, which may result in a UI-freeze until a timeout occurs.

Change History (14)

comment:1 Changed 12 months ago by fholzing

r16024: Made the permissions-check async and restructured the logic for short-circuit evaluation.

comment:2 Changed 12 months ago by fholzing

  • Status changed from new to assigned

comment:3 Changed 12 months ago by fholzing

r16025: Removed workaround.

comment:4 Changed 12 months ago by fholzing

  • Owner changed from fholzing to abeham
  • Status changed from assigned to reviewing

comment:5 follow-ups: Changed 12 months ago by abeham

  • Owner changed from abeham to fholzing
  • Status changed from reviewing to assigned

I checked some other menu items and I think none of the other service-related menu items perform a check for privilege. Not even the other menu items in the OKB namespace. I think it's a nice way to check the permission and disable options the user doesn't have. But if it causes problems, then we can also get rid of it.

I see two options:

  1. Just remove the privilege check altogether (consistent with everything else)
  2. Implement a privilege check for all service-related menu items in a way that you have done

Do you know what happens when the service is badly accessible and I switch between some views several times. Will there be multiple calls to the service being queued or executed concurrently?

comment:6 in reply to: ↑ 5 Changed 12 months ago by swagner

Replying to abeham:

I checked some other menu items and I think none of the other service-related menu items perform a check for privilege. Not even the other menu items in the OKB namespace. I think it's a nice way to check the permission and disable options the user doesn't have. But if it causes problems, then we can also get rid of it.

I see two options:

  1. Just remove the privilege check altogether (consistent with everything else)
  2. Implement a privilege check for all service-related menu items in a way that you have done

Do you know what happens when the service is badly accessible and I switch between some views several times. Will there be multiple calls to the service being queued or executed concurrently?

I would prefer not to check user permissions every time, when the active view is changed. Therefore, my recommendation is option 1. I want to rethink identity and rights management in general, when we think about necessary improvements for Hive.

comment:7 in reply to: ↑ 5 Changed 12 months ago by fholzing

Replying to abeham:

I checked some other menu items and I think none of the other service-related menu items perform a check for privilege. Not even the other menu items in the OKB namespace. I think it's a nice way to check the permission and disable options the user doesn't have. But if it causes problems, then we can also get rid of it.

I see two options:

  1. Just remove the privilege check altogether (consistent with everything else)
  2. Implement a privilege check for all service-related menu items in a way that you have done

Do you know what happens when the service is badly accessible and I switch between some views several times. Will there be multiple calls to the service being queued or executed concurrently?

Just checked the behaviour: they will be executed concurrently, at least down to the ClientBase-Level. For each individual call a new ClientBase will be instantiated, therefore each ClientBase should have an unique ChannelFactory. A channel itself will handle requests in a sequential way. If they would share a common ChannelFactory, the TimeOut of one minute should terminate all requests. Also, the result is cached, so no new concurrent calls should happen after the first call returns.

comment:8 Changed 12 months ago by fholzing

r16032: Removed permission check

comment:9 Changed 12 months ago by fholzing

  • Owner changed from fholzing to abeham
  • Status changed from assigned to reviewing

comment:10 Changed 12 months ago by abeham

  • Owner changed from abeham to fholzing
  • Status changed from reviewing to readytorelease

In r16032 we have two GUI updates instead of one. Not that it matters, but I prefer it this way.

r16033: reduced to what it was before, but without privilege check

comment:11 Changed 12 months ago by mkommend

  • Owner changed from fholzing to mkommend
  • Status changed from readytorelease to reviewing

comment:12 Changed 12 months ago by mkommend

  • Status changed from reviewing to readytorelease

comment:13 Changed 12 months ago by mkommend

r16049: Merged r16024, r16025, r16032, r16033 into stable.

comment:14 Changed 12 months ago by mkommend

  • Resolution set to done
  • Status changed from readytorelease to closed
Note: See TracTickets for help on using tickets.