Skip to content
Snippets Groups Projects

Improvements regarding server-side Queue management (fixes #187 and #172)

Merged Marcus Oskarsson requested to merge gh-46ae92de/196/mxcube/issue187 into master

Created by: mguijarr

See detailed info in commit messages.

One remark : I am not so convinced any more that we should hold the queue state entirely in the server, I started to experiment with redux-persist in order to have persistence on the client side (I created a branch for that, this is a work in progress). While doing this I ended up thinking we should almost only store on the client... So the opposite compared to what we are doing now ! I will come back on this later.

Merge request reports

Merged by avatar (Jan 10, 2025 12:32pm UTC)

Merge details

  • Changes merged into with 0de7218d.
  • Deleted the source branch.

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • Created by: meguiraun

    Thanks for the work, a much clearer code. A few comments:

    • It is far more easier to understand working with a queue dict rather than with the mxcube.queue (in routes.Queue: when adding samples, executing entry, etc.). How do we know, e.g, if a sample has been already added if we only know the sample location string? In other methods it should be pretty easy to move to working only with the mxcube.queue, for a later PR?
    • mxlogin_required decorator: you are absolutely right, it is there as an old test, is it not in use
    • why did you remove the dispatch(getInitialStatus) in actions/login.js?

    I still think that the server is the place for storing the queue... Storing in the client would not mean to have some potential issues when synchronizing? The client does not need to have the whole mxcube.queue but the corresponding dict, but the server needs the whole hwobj which would be managed/saved/whatever by the client. We can discuss it of course!

  • Created by: mguijarr

    Hi Mikel,

    getInitialStatus is called from the getLoginInfo action now. I didn't remove it ?

    At the beginning I thought exactly the same as you regarding the queue, I thought the state should be kept in the server, just as we said during our last workshop.

    But I started to have another idea, it's not ready yet so I prefer to talk about it when I would have time to think about all cases and how it could work, and the more important for us : if it gives better results in less time for us than storing the queue on the server. More news later... ;)

    I was also thinking that maybe we could generate new Queue objects every time we need it instead of mutating one Queue from the beginning (in this case, we could parse our own JSON structure from the client for example and make a new Queue on the fly each time). Well, I am not sure of this neither - I am looking for ways of simplifying our code...

Please register or sign in to reply
Loading