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

Not handling growing concurrency past init_count very well #25

Closed
MaxPower15 opened this issue Feb 3, 2016 · 8 comments
Closed

Not handling growing concurrency past init_count very well #25

MaxPower15 opened this issue Feb 3, 2016 · 8 comments

Comments

@MaxPower15
Copy link

Hi there, I'm using Riak in a system that potentially requires high concurrency and have run into an exception that's hard to handle. It looks like this:

21:03:45.777 [error] Process #PID<0.192.0> raised an exception
** (FunctionClauseError) no function clause matching in Riak.find/4
    (riak) lib/riak.ex:301: Riak.find(:error_no_members, :error_no_members, "abc", "def")
    (riak) lib/riak.ex:301: Riak.find/3
    (riak) lib/riak.ex:282: Riak.find/2

I set up a test repo with instructions to demonstrate: https://github.com/MaxPower15/riak_pooler_issue

I poked around myself with pooler, hoping to maybe get a PR fix, but I don't think I'm familiar enough with the underlying code to really do it correctly. I hope this demo helps though!

@edgurgel
Copy link
Collaborator

edgurgel commented Feb 3, 2016

@MaxPower15 I would simply increase your pool https://github.com/drewkerrigan/riak-elixir-client#connection-pooling

Maybe each function should give a better error but it's fair to explode if no connection from the pool is ready to deal with the request.

@MaxPower15
Copy link
Author

@edgurgel Yes, that's my current solution; I talk about it here: https://github.com/MaxPower15/riak_pooler_issue#explanation. I just think it should be handled better out of the box. :)

@MaxPower15
Copy link
Author

I should mention, this occurs when requesting a connection when well below the max_count. It just needs to be above the previous minimum value, which is init_count in the demo.

@edgurgel
Copy link
Collaborator

edgurgel commented Feb 3, 2016

Oh gotcha! I should have read the whole thing! Thanks for the report!

@edgurgel
Copy link
Collaborator

edgurgel commented Feb 3, 2016

This issue seems to be the same you noticed: epgsql/pooler#54

@MaxPower15
Copy link
Author

Aha, so perhaps a pooler issue. I wonder if it's introduced in a new version. Will try with an older one to see if it can still be reproduced.

@MaxPower15
Copy link
Author

Well, so much for that idea. I couldn't compile pooler pre-1.5.0. I guess the question is if that's intended behavior or not with pooler.

@randysecrist
Copy link
Collaborator

Definitely think this is a pooler issue. I've done some house keeping with pooler recently and fixed some of the compilation issues and warnings including pushing some things up to hex.

Will close this, but will also mention this pooler PR. Might be worth considering pulling this in but I need to think about it more.

epgsql/pooler#72

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

3 participants