Conversation
|
@leiyangyou is the above something that you think addresses the need you expressed in #59? |
|
@bernardd what do you think of this approach? |
|
Looks mostly fine to me. My main comment would be that the calls |
| end, sets:to_list(NewClients)), | ||
| {noreply, undefined}. | ||
|
|
||
| handle_info(timeout, _State) -> |
There was a problem hiding this comment.
Could this stuff not be done in init/1? The only catch I can see is the call to cqerl_hash:get_client/1, but cqerl_hash should already be started by the time this module starts up. But it's very likely I'm missing something :)
There was a problem hiding this comment.
It was mainly to not block the supervisor trying to spawn the cluster gen_server process, while possibly multiple groups of clients are being started.
It is probably not necessary, I've just grown accustomed to not do anything too expensive in init/1 😃
There was a problem hiding this comment.
Eh, it's fair enough. Thinking on it more, it's probably harmless at worst and a good idea at best :)
|
About the exposed API, would you see it exposed as |
|
Actually yeah - I said |
|
Would it be possible to get the cluster stuff merged in on its own, separate from the other items? I ask because we're just at a point now where it would be really handy to have it :) |
|
@bernardd I added a new branch called |
|
Brilliant, thanks. If I have some time I'll try to add some. |
|
Now has docs and tests, merging! |
This is a work-in-progress PR for version 1.0
Suggested changes:
hashmode the default (addresses Doesn't seem to scale... #49), and still supportpoolermode when set explicitlyCluster support
The information about the members of a cluster is kept in a protected ets table, readable from the user's process, so no bottleneck is introduced in this mechanism, just one more hop to a ETS table.
Simple clusters