Skip to content
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

pool of sockets #58

Open
mmaquevice opened this issue Apr 4, 2015 · 3 comments
Open

pool of sockets #58

mmaquevice opened this issue Apr 4, 2015 · 3 comments

Comments

@mmaquevice
Copy link

Hey,

Congrats for the lib ! :)

Is there any plan of managing a pool of sockets instead of having to create one by connection ?

Thanks !

@ra1u
Copy link
Contributor

ra1u commented Apr 6, 2015

why would you use that? You can use one connection for all clients.

@mmaquevice
Copy link
Author

In production, it is a best practice to manage a pool of sockets (which size is known), instead of creating one for all requests or by request.

Another question : do you plan to handle a cluster of redis nodes with sentinels ?

Thanks

@ra1u
Copy link
Contributor

ra1u commented Apr 9, 2015

Issue with pool is that you need to track ownership of resources somehow. Once you say to pool giime_socet, this same person should give you this socket back in order to release resource.

This kind of ordering is kind a hard to achieve not from implementation perspective, but from user perspective. If user does not release resource or it release before all futures completed you have misuse. Let imagine simple interface and here is example of use:

var connection = RedisClient.getConnetionFromPool();
connection.getClient()
.then((RedisClient client) {
    // Use your client here. Eg.:
    client.set("test", "value")
        .then((_) => client.get("test"))
        .then((value) => print("success: $value"));
})
.then((_) => connection.ReleseBackToPoll());

Do you spot bug and leaking resource?
Problem is that there is missing return in line 5. So .get gets called after connection.ReleseBackToPoll(). This example shows, that it is way to easy to misuse this kind of api.

On the other hand, futures and cooperative approach in Dart enables you to have certain degree of trust that futures will not halt your execution.

Using one connection for everybody is not that bad and messages cant get mixed up. Only exception are commands that affect connection for example calling command select changes database for connection and that would affect all users. Other that this kind of stuff, one just can't misuse and each user doesn't know that shares same connection with other users, just like they don’t know that they are all sharing same thread.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants