Feature Request: make it work well when several instances are run concurrently

[expipiplus1]

for i in $(seq 1 10); do matrix-commander --message $i & ; done

Running the above yields:

• One successful message to the channel
• Two peewee.OperationalError: database is locked errors
• Six corrupt messages in the channel Unable to decrypt: The secure channel with the sender was corrupted
• One ERROR: matrix-commander: Message send failed. Sorry. with no traceback

It would be excellent if multiple instances of this program could run concurrently, or at the very least wait politely for a while for any siblings to finish.

[8go]

Thank you @expipiplus1 for bringing this to my attention.

Yes, you are right. Concurrency is currently not supported and will cause errors and problems.

Making the matrix-commander concurrent would be quite some work.

Just as a workaround, for performance reason it is much better anyway to first prepare all messages and send all N messages with a single matrix-commander command.

Like:

# some preprocessing, preparing all N messages
# calling matrix-commander similar to this:
matrix-commander --message $M1 --message $M2 ... --message $Mn
# this requires less resources and is way faster than calling matrix-commander N times

[expipiplus1]

Sure, but sometimes that's not possible. For example when MC is being invoked concurrently from several scripts. Is it not possible to do something simple like maintain a lock file on any contended resources?

…

On Thu, 20 May 2021, 11:02 pm 8go, ***@***.***> wrote: Thank you @expipiplus1 <https://github.com/expipiplus1> for bringing this to my attention. Yes, you are right. Concurrency is currently not supported and will cause errors and problems. Making the matrix-commander concurrent would be quite some work. Just as a workaround, for performance reason it is much better anyway to first prepare all messages and send all N messages with a single matrix-commander command. Like: # some preprocessing, preparing all N messages # calling matrix-commander similar to this: matrix-commander --message $M1 --message $M2 ... --message $Mn # this requires less resources and is way faster than calling matrix-commander N times — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#31 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGRJXHDMHTOME3MMG3QTGDTOUP7TANCNFSM44EL2WFA> .

[8go]

Sure, a "lockfile" or a PID-file is possible, maybe in combination with a flag/argument --wait which can be used as:

• if --wait is not set and another MC process is running, the newly invoked MC process simply aborts with a message "another MC already running"
• if --wait is set and another MC process is running, the newly invoked MC process will wait (sleep) and periodically (e.g. every 1 or 2 seconds) check if the lockfile (PID file) is still there and by doing so wait until other MC instances have finished, in which case it will itself create the lockfile (PID file) and start running.

From the 2 variants lock-file vs PID-file the PID-file logic is already implemented.

• See the PID file in e.g. /home/$USER/.run
• See also code: https://github.com/8go/matrix-commander/blob/master/matrix-commander.py#L786-L794
• Also note that multiple MC instance running in parralel are possible if they use different stores, etc.

So, overall what you want is possible. The missing part, logic, is the "check, sleep, recheck" logic.

It is not high on my priority list. Any nice soul out there that wants to contribute this feature as a PR?

[8go]

Reopened issue as Feature Request in hope to find a contributor for this feature.

[expipiplus1]

Thanks for reopening. I wonder if there's some existing program which wraps other programs doing this lock file management. Probably wouldn't take too long to do in bash. Next time I bump into it I might take a look.

[8go]

Thanks for reopening. I wonder if there's some existing program which wraps other programs doing this lock file management. Probably wouldn't take too long to do in bash. Next time I bump into it I might take a look.

Yes, it could also be implemented OUTSIDE of matrix-commander as you point out correctly. You are right, a bash script wrapper could look for the presence of a PID file in the PID directory (e.g. /home/$USER/.run) and "pause" until no more PID files are in the directory.

Only a 99.9% solution because this would still allow 2 MC instances to start concurrently, both check at the same time, both find the dir empty of PID files, both start, .... and then possibly collide. A race condition.

[expipiplus1]

well, that particular bug is easy to work around, after writing the pid file, only start if you read your own pid from that file. But overall you're right, concurrent programming is tricky :)

…

On Tue, May 25, 2021 at 10:31 PM 8go ***@***.***> wrote: Thanks for reopening. I wonder if there's some existing program which wraps other programs doing this lock file management. Probably wouldn't take too long to do in bash. Next time I bump into it I might take a look. Yes, it could also be implemented OUTSIDE of matrix-commander as you point out correctly. You are right, a bash script wrapper could look for the presence of a PID file in the PID directory (e.g. /home/$USER/.run) and "pause" until no more PID files are in the directory. Only a 99.9% solution because this would still allow 2 MC instances to start concurrently, both check at the same time, both find the dir empty of PID files, both start, .... and then possibly collide. A race condition. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#31 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGRJXEMN7SLNG5QS73EONTTPOYDDANCNFSM44EL2WFA> .

[nirgal]

@expipiplus1 As a workaround, you could wrap your calls with flock.
I mean rather than run "matrix-commander args" run instead "flock -c mylockfile matrix-commander args"...
This will delay the execution until the lock is available

[expipiplus1]

yeah, that's a pretty good idea. thanks

…

On Tue, Aug 31, 2021 at 3:54 PM nirgal ***@***.***> wrote: @expipiplus1 <https://github.com/expipiplus1> As a workaround, you could wrap your calls with flock. I mean rather than run "matrix-commander args" run instead "flock -c mylockfile matrix-commander args"... This will delay the execution until the lock is available — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#31 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGRJXHC44IMGYRKGZ3XJMTT7TUJRANCNFSM44EL2WFA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[xurizaemon]

Another tactic would be to run parallel instances of matrix-commander in containers, eg via docker matrixcommander/matrix-commander. Containers could be given whatever shared state is required via a shared mount, and at the same time isolated from interfering with each others running.

[8go]

Thank you all @nirgal @expipiplus1 @xurizaemon for adding your excellent ideas. Please keep sharing. So, others can learn and take some clues, or even implement some of your suggestions.

For other people: Keep it going and please keep adding more suggestions if you have any! They are welcome! Thanks.