Message content requests are processed synchronously, resulting in a frozen screen when the user clicks on a message row.

[mercihabam]

It would be much better not to have to wait until the request has finished for the app to respond to further actions, such as navigating to another folder or viewing a different message instead of the currently requested one.

I'll explore later how this can be made asynchronous. In the meantime, ideas from everyone are welcome.

[marclaporte]

@kroky please advise

[kroky]

We have a deeper problem here as ajax requests are asynchronous by default. I think the actual problem is session locking on the PHP side where your other navigation requests get queued and not responded until the original one is ready but it is not, since it is probably waiting for slow IO from an IMAP server. The best we can do on frontend/UI part is some kind of a spinner/waiting message. Dealing with this on the server-side involves some more complex considerations as when we can close the session early (no further writes), can we have async sessions and things like that. We have discusses similar issues with Tiki codebase, so probably worth doing it on a single place. @marclaporte do you know such a place? I am pretty sure session locking as its own issue or set of issues here and in Tiki.

[marclaporte]

do you know such a place?

@kroky Do you mean where we should discuss or which parts of the code?

[kroky]

I think we had a session locking discussion for Tiki somewhere with you but I cannot find the thread - was wondering if you remember it?

[marclaporte]

https://dev.tiki.org/item8365-Race-condition-Sessions-stored-in-the-database-and-Cypht

Internal tasks:

• https://avan.tech/item89272-Revamp-our-db-session-storage-to-work-in-exclusive-locking-mode-like-native-file-session-storage-works
• https://avan.tech/item88244-With-session_storage-db-in-24x-Cypht-reply-to-empty-instead-of-sender

[kroky]

Thanks! I've checked the discussions we had and they involve both Tiki and Tiki-Cypht integration. Part of the updates/fixes for locking and truly asynchronous requests were in Tiki-Cypht integration but now we need to think about standalone Cypht. Recent changes in master made the db-stored sessions work in exclusive lock mode like the file storage sessions in PHP. This is a step forward towards unification. Since Cypht is a heavy user of ajax requests, I think next steps would involve:

• analyze and list potentially slow ajax endpoints (anything involving IO with 3rd party server)
• analyze session usage for each Cypht module and potentially reduce the usage of session only to where it is absolutely necessary
• refactor to close the session early when further modules don't write data in the session (this is already happening in a couple of places but needs more coverage)
• consider switching to read-write-close session handling for asynchronous requests - we need to make sure session is freshly read every time it is used and then written and closed when something needs to be stored. This way, parallel requests can access and share the same data. Special care must be taken in not using an old/stale data in a session cache.
• session locking must still be implemented during write operations, so concurrent write issues are solved
• consider data integrity checks stored as hashes, so subsequent reads of async requests know if their data is fresh or not and if they should reload it (should speed up the session management operations)

[marclaporte]

@jasonmunro wrote in the community chatroom:

"Yep, that is a tricky one :) Kroky is correct I believe, the "problem" is session locking. The best I could come up with to help mitigate that was to allow requests to close the session early so any non-writing action can be performed after the session is closed:

cypht/modules/core/handler_modules.php

Line 120 in 13e3a96

class Hm_Handler_close_session_early extends Hm_Handler_Module {

"

Source: https://matrix.to/#/!SeNiIGzqZwRjAclUCr:gitter.im/$7B90VpPjtYJJPygxtN51hDIEeaeSmqmkENfje65FiSo?via=matrix.org&via=gitter.im&via=osba.nl