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

Remove client from pool on connection end #537

Closed

Conversation

strk
Copy link
Contributor

@strk strk commented Mar 14, 2014

Might fix #458
Definitely fixes CartoDB/CartoDB-SQL-API#135

@strk
Copy link
Contributor Author

strk commented Mar 14, 2014

I don't understand the failing test (idle-timeout-tests.js).
What's supposed to be ending the test @brianc ?

@strk
Copy link
Contributor Author

strk commented Mar 14, 2014

Ok I do see that an "end" event is also emitted by the client at the end of a query, even with no error. In those cases we don't really want to remove the item from the pool. So what we'd need is a way to distinguish "good" connections from "bad" connections.
Now I'm not even sure if an "end" event received from a client while a query was in progress is a good signal for a "bad" connection :/

Instead, consider receiving a premature stream end while a query
is in progress as an error sign, bubbling up the error to the
client level. Fixes the testsuite while still fixing my cases
and possibly brianc#458.

The correct fix would be to provide a .validate method to the
pooler, and expose a .validate method to the client and to the
connection classes for that purpose...
@strk
Copy link
Contributor Author

strk commented Mar 14, 2014

Still doesn't fix all cases of connection breaking after successful connection.
I've found another one resulting in this error:

Error: This socket is closed.
    at Socket._write (net.js:518:19)
    at Socket.write (net.js:510:15)
    at Connection.query (/usr/src/node/modules/node-postgres/lib/connection.js:177:15)
    at Query.submit (/usr/src/node/modules/node-postgres/lib/query.js:113:16)
    at Client._pulseQueryQueue (/usr/src/node/modules/node-postgres/lib/client.js:280:24)
    at Client.query (/usr/src/node/modules/node-postgres/lib/client.js:323:8)
    at Function.me.eventedQuery (/usr/src/node/apps/CartoDB-SQL-API/CartoDB-SQL-API/app/models/psql.js:185:36)

And subsequently failing to error out on an attempt to use the connection from the pool :'(

@strk
Copy link
Contributor Author

strk commented Mar 14, 2014

This new on fails ./test/unit/client/stream-and-query-error-interaction-tests.js

ARGH (I love testcases :)

@brianc
Copy link
Owner

brianc commented Mar 17, 2014

I do not think emitting an error event here is correct. If the connection is ended that shouldn't result in the client object emitting an error. What about when the connection is ended on purpose such as when one calls client.end()? Calling client.end() and having the client emit an error is not good.

@strk
Copy link
Contributor Author

strk commented Mar 17, 2014

On Sun, Mar 16, 2014 at 07:41:09PM -0700, Brian C wrote:

I do not think emitting an error event here is correct.

Agreed, see a3a1cc9

--strk;

@strk
Copy link
Contributor Author

strk commented Mar 17, 2014

Sorry, you meant it's not good to get 'error' when calling client.end()
even if a query was in progress ? But is it correct to keep the client in the pool on 'end' ?

@strk
Copy link
Contributor Author

strk commented Mar 17, 2014

I actually think removing 'end'-ed connections from the pool is correct, but let's close this pull, too confusing. Will file a cleaner one.

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

Successfully merging this pull request may close these issues.

No response on backend (postgresql) crash Check pg connection
2 participants