-
Notifications
You must be signed in to change notification settings - Fork 97
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
Automatic discovery of nodes #79
Comments
@tlvenn distribution has actually been removed in the 2.x branch because it was causing issues with the introduction of new features. Can Phoenix Presence be using without depending on the entire Phoenix framework? |
Yes, only need Phoenix.PubSub project: https://github.com/phoenixframework/phoenix_pubsub and it is rock solid. |
@tlvenn even so, distribution has been removed from core Cachex. The intent is to fork out a new project which provides distribution but with some features removed (e.g. the LRU caching introduced in v2.x cannot be supported on distributed tables). I will leave this open for now, but with the disclaimer that it very likely won't live inside this repo (unless I solve the consistency issues with LRU across nodes). |
Ha oky, I wasnt aware of that.. |
Could the distribution be added just using hooks with some kind of plugin system so that we could add cachex.distributed package to provide the feature without forking the whole project ? |
@tlvenn it only happened recently, see discussion inside #49. And per your suggestion, that is something I've tried to figure out. My intent for a while was to have interchangeable backends for a cache, so it could be ETS, could be Mnesia, could be Redis, etc. This would work, but the big catch is that there are some features which simply do not work in a distributed state. It could be that this repo lives on as a distributed cache implementation and I fork out the non-distributed version into a new repo (which actually makes a fair bit of sense now I think about it). How familiar are you with Presence? Do you know if it's possible to have a "master" node? This is the only thing I need to keep distribution - if there's a master node it's trivial to implement things that are currently local-only (i.e. LRW caches) because all the cleanup processes would happen on the master and just replicate out - as it stands there's no way to determine this and so it becomes near impossible to implement correctly. |
@tlvenn FWIW I'm looking into Presence - doesn't seem like a good fit just because the sync interval is so high (default is recommended to be 1500ms). It also appears that it doesn't actually do discovery - you have to instruct it as to which nodes to work with. |
@tlvenn I'm going to close this because of the distribution being stripped out. I'm planning on building up a new project aimed at being a distributed implementation in future so I'll drop a link here when that's up. Cachex being distributed really doesn't make much sense due to the consistency issues as well as trying to be fast. My intent is to build something which is distributed at its core to improve the resiliency there. If you have any other suggestions please feel free to let me know, but for now it looks like distribution is dying in the v1.x branch. |
No problem @zackehh, thanks for the discussion. |
Hi,
First of all, thanks for this amazing project !
I was wondering if we could not discover nodes automatically using Phoenix Presence which also solves Service Discovery across nodes.
The text was updated successfully, but these errors were encountered: