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

Persistence whilst awaiting initial connection #333

Merged
merged 2 commits into from Aug 29, 2019
Merged

Persistence whilst awaiting initial connection #333

merged 2 commits into from Aug 29, 2019

Conversation

MattBrittan
Copy link
Contributor

@MattBrittan MattBrittan commented Jul 11, 2019

Adds the options ConnectRetry and ConnectRetryInterval along with the code to implement them and enable messages to be stored whilst the connection is in progress. The aim is to enable Publish() to be called before a connection is established (the message will get added to the store and sent eventually).

This is useful in situations where the comms are unreliable and the system may need to shutdown for periods to reduce power use. With this change there is no need to write separate code to store messages that are generated before the connection comes up.

The majority of changes should only apply if the new flag is set to true; about the only change that will affect all users is moving the store open and set status to connect outside of the go routine (needed because a user could call connect() and then publish() immediately with this new option enabled).
There are also a few more locks to align connect/reconnect - I was going to separate out the connect code so that the same code could be used for connect & reconnect but figured that you would prefer a smaller change.

closes #332

Add ability to automatically retry initial Connect
Support publish while initial connect is in progress

Signed-off-by: Matt Brittan <matt@brittan.nz>
@alsm
Copy link
Contributor

alsm commented Jul 17, 2019

Thanks for the work on this, I'll take a closer look over the next day or two before deciding. I had avoided allowing Publish before connect in case you never successfully connect, but in that case is it any worse to store messages that will never be delivered, probably not.

@MattBrittan
Copy link
Contributor Author

MattBrittan commented Jul 17, 2019

I had avoided allowing Publish before connect in case you never successfully connect

That was one of my concerns too - I deal with the possibility with something like the below (as a go routine) in my application code. This allows the end user to ascertain if there is an issue when performing initial setup.

for {
	done := token.WaitTimeout(1 * time.Minute)
	if done {
		if token.Error() != nil {
			***Log Error Message.... Happens if Disconnect is called before connection completes 
		} else {
			***Log Info Message indicating successful connection
		}
		return // token all done - nothing more will happen
	}
	*** Log info saying connect still in progress
}

@alsm alsm merged commit c49ea09 into eclipse:master Aug 29, 2019
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.

Persistence whilst awaiting initial connection
2 participants