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

[ADDED] RetryOnFailedConnect option #581

Merged
merged 1 commit into from
Jul 8, 2020
Merged

Conversation

kozlovic
Copy link
Member

@kozlovic kozlovic commented Jul 7, 2020

Normally, nats.Connect() would fail if there is no server available
when this call is executed. With this new option, if no connection
can be made, this call will return no error and will trigger code
similar to the reconnect code. Therefore, MaxReconnect and ReconnectWait
options are used as if the library had been disconnected and is trying
to reconnect.
Note that subscription and publish calls will also behave as if the
library was in reconnection mode, which means that the calls are
buffered and produce no error until the reconnect buffer size is
full.
Obviously, since the connection is not connected, Flush or Request/Reply
calls would timeout.

If the ReconnectHandler is set, it will be invoked if the library
connects asynchronously.

Unrelated: fixed a test that had a t.skip()...

Resolves #195

Signed-off-by: Ivan Kozlovic ivan@synadia.com

@coveralls
Copy link

coveralls commented Jul 7, 2020

Coverage Status

Coverage increased (+0.6%) to 91.504% when pulling 8a78c4e on retry_on_failed_connect into a16f8c9 on master.

Copy link
Member

@derekcollison derekcollison left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

test/conn_test.go Outdated Show resolved Hide resolved
Normally, nats.Connect() would fail if there is no server available
when this call is executed. With this new option, if no connection
can be made, this call will return no error and will trigger code
similar to the reconnect code. Therefore, MaxReconnect and ReconnectWait
options are used as if the library had been disconnected and is trying
to reconnect.
Note that subscription and publish calls will also behave as if the
library was in reconnection mode, which means that the calls are
buffered and produce no error until the reconnect buffer size is
full.
Obviously, since the connection is not connected, Flush or Request/Reply
calls would timeout.

If the ReconnectHandler is set, it will be invoked if the library
connects asynchronously.

Unrelated: fixed a test that had a t.skip()...

Resolves #195

Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
Copy link
Member

@wallyqs wallyqs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

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.

Should Connect return errors if it cannot connect?
4 participants