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

Client doesn't recover from DNS refreshes #75

Closed
leonmaia opened this issue Mar 7, 2018 · 0 comments · Fixed by #76
Closed

Client doesn't recover from DNS refreshes #75

leonmaia opened this issue Mar 7, 2018 · 0 comments · Fixed by #76

Comments

@leonmaia
Copy link
Collaborator

leonmaia commented Mar 7, 2018

Right now finagle-postgres caches the DNS resolution forever when retrieving custom types from Postgres. That causes to the client to be forever dead even if the naming resolution succedes afterward, causing to Finagle stop complaining about Name resolution failed but still causing failures when trying to query anything.

[info] 18:38:46.899 DEBUG [finagle/netty4-4] connection-1 - Sent frontend message of type: com.twitter.finagle.postgres.messages.Sync$
[info] 18:38:46.899 DEBUG [finagle/netty4-4] state machine-1 - Received event com.twitter.finagle.postgres.messages.Sync$ in state com.twitter.finagle.postgres.connection.Connected$
[info] 18:38:46.899 DEBUG [finagle/netty4-4] state machine-1 - Transitioning to state com.twitter.finagle.postgres.connection.Syncing$ and emiting result
[info] 18:38:46.900 DEBUG [finagle/netty3-2] connection-1 - Received backend message of type: com.twitter.finagle.postgres.messages.ReadyForQuery
[info] 18:38:46.900 DEBUG [finagle/netty3-2] state machine-1 - Received event com.twitter.finagle.postgres.messages.ReadyForQuery in state com.twitter.finagle.postgres.connection.Syncing$
[info] 18:38:46.900 DEBUG [finagle/netty3-2] state machine-1 - Transitioning to state com.twitter.finagle.postgres.connection.Connected$ and emiting result
[info] 18:38:46.900 DEBUG [finagle/netty3-2] connection-1 - Emitting result com.twitter.finagle.postgres.messages.ReadyForQueryResponse$
[info] 18:38:46.901 WARN  [finagle/netty3-2] c.t.o.s.m.NoBrokersAvailableExceptionMapper - Name resolution failed with No hosts are available for db, Dtab.base=[], Dtab.local=[]. Aborting.

For now as a workaround we can create the client adding withDefaultTypes() and that will make it work. But only if all the types needed by the application are described in: https://github.com/finagle/finagle-postgres/blob/master/src/main/scala/com/twitter/finagle/postgres/PostgresClient.scala#L84

leonmaia added a commit to leonmaia/finagle-postgres that referenced this issue Mar 12, 2018
leonmaia added a commit to leonmaia/finagle-postgres that referenced this issue Mar 12, 2018
leonmaia added a commit to leonmaia/finagle-postgres that referenced this issue Mar 12, 2018
leonmaia added a commit to leonmaia/finagle-postgres that referenced this issue Mar 12, 2018
leonmaia added a commit to leonmaia/finagle-postgres that referenced this issue Nov 13, 2018
leonmaia added a commit to leonmaia/finagle-postgres that referenced this issue Nov 13, 2018
leonmaia added a commit to leonmaia/finagle-postgres that referenced this issue Nov 13, 2018
leonmaia added a commit to leonmaia/finagle-postgres that referenced this issue Nov 13, 2018
leonmaia added a commit to leonmaia/finagle-postgres that referenced this issue Nov 13, 2018
leonmaia added a commit to leonmaia/finagle-postgres that referenced this issue Nov 13, 2018
leonmaia added a commit to leonmaia/finagle-postgres that referenced this issue Nov 13, 2018
This closes finagle#75:
 - The strategy was to find a way to cache only successful evaluations of the `typeMap`.
 - I chose to use the `Refresh` since it provides memoization for futures and doesn't cache failed ones.
 - `Refresh` provides us with an API to cache values that don't change often so we don't have to call the database every time and we also don't cache failed futures.
 - I also had to make sure that for when using the `prepareAndQuery` and the `prepareAndExecute` that the `typeMap` had been previously evaluated, that's why I added a `flatMap` on those two methods.
leonmaia added a commit that referenced this issue Nov 13, 2018
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 a pull request may close this issue.

1 participant