-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Need to implement WAIT , tips ? #1474
Comments
We know that Blocking operations are anathema to the current implementation; there are no supported workarounds; you can hack them in via My advice: wait |
Thank you much appreciated. I presume this will be a major release with a long cycle ? |
No, I was going to do this as 2.2, and the proof-of-concept is complete - it just needs integrating and testing, but: this isn't my only project and isn't my day job, so: it is tied on my availability. It is something I really want to get in, because it simplifies the IO path hugely, which should resolve a ton a network pain points. |
Does this mean that there are currently no means of ensuring replication? I am planning to set up master-replicant with sentinels. I suspect I have some data that I need to ensure is the same no matter which node you reach. It seems this is only possible with Is there anything going against an approach using a lua script to perform synchronous operations - i. e. using |
That Lua script will block your entire server, and could even get forcibly
terminated. I don't recommend that.
…On Thu, 19 Aug 2021, 19:19 Mikael Elkiær, ***@***.***> wrote:
Does this mean that there are currently no means of ensuring replication?
I am planning to set up master-replicant with sentinels. I suspect I have
some data that I need to ensure is the same no matter which node you reach.
It seems this is only possible with WAIT.
Is there anything going against an approach using a lua script to perform
synchronous operations - i. e. using WAIT.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1474 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAEHMGXDM6NWWPNRQEKFTLT5VDKJANCNFSM4NLQYN3A>
.
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&utm_campaign=notification-email>
.
|
Ok, if that is more or less ruled out, then what else is there left to do? Is this a problem of client and/or server blocking? I'd assume that server blocking always would be possible despite any limitations in the client - what am I missing here? Edit: I see now that |
@mgravell Sorry for bumping, but I was wondering if you could come with some clarification regarding the last bit of my previous post. Wouldn't it be possible to do |
Honestly, until I get the time to implement pooled connections: I am not, in any scenario, going to advocate anything that introduces a blockage at the server, no matter how transient. I can see many ways it go go badly. Are there scenarios where it might work acceptably under modest load? Possibly, but I'm not going to try and think through what the limits are. |
Fair enough. Thanks for the reply, will keep an eye out for connection pooling. |
Have read the other thread but i need this anyway (not immediately but soon), don't need other blocking operations just WAIT
My options are
Just after some tips / suggestions of the best approach.
The text was updated successfully, but these errors were encountered: