-
Notifications
You must be signed in to change notification settings - Fork 93
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
V0.20 (session persistence) Release Discussion #207
Comments
I'm now running @master in production with:
All connections run QOS1 and the remote clients utilise autopaho To date the only real issue I've encountered was due to a corrupted queue (addressed in #194 and #199 ). This will have been caused by the power being pulled (was a component in a larger system being built in a customers factory, so regular power outages are to be expected); upcoming change to add Apart from the one issue, I'd say that things are running better than the v3 client (got out-of-order packets fairly frequently with that following loss of connection, have not had the same issue with the V5 client). My app does perform checks for missing and out of order messages, and I've not seen any alerts, so fairly happy that the session management piece is working OK. The only downtime I've suffered was due to the corrupted queue issue (as this was a test site I was able to leave it as-is until the fix was available so have confirmation that the fix works). |
Thanks for all the work you've put in to get to this point, it's really appreciated! Since the next release is going to break existing user code already, here are some additional breaking changes I think should be considered before the next release.
I can take a stab at one or both of these and submit a PR if that'd be useful. |
My thoughts on to-do's for the next release:
I'm ambivalent on the logging change (this is primarily for library development and is not something most users will need to touch). Anyway looks like a release is not far off; would like to see this happen in Jan. |
@vishnureddy17 would love to see a PR for this. |
@MattBrittan Sounds good. I'd be happy to do the pinger PR, and I can get that out next weekend (Jan 6-7). Another change I think is important is to allow users to get back the ack on an async publish. One way to achieve this is to change This is quite important for my use-case. I can work on a PR for that and make an effort to get that out in January. The |
My thought on this was to add callbacks to
Yep - I would like to see a solution for this but struggle with the logic around reconnections (I'm thinking more of the logic that would be required in users code than the logic in the client). It would be good to see use-cases from someone who needs this functionality. |
I think that's expected and necessary. As a user, I'd want to know when the publish was handled in the session (regardless of how many reconnections happened in the interim). In the solution you suggest, that would mean that the callback can potentially be called long after a particular client is dead. I see how that could be confusing to the user, and that behavior would need to be documented. |
Hello all, appreciate your work! Would love to see PingHandler fix in the next release - we recently found out that this is causing issues in our deployment, resulting in more than 5 minutes lags when connection problem is unnoticed. |
Update on the to-do list: Done:
In progress:
Backlog / Undecided:
My thought is that once we get the pinger sorted I'll run this on a few production workloads for a week or so before cutting a release. After that release it would be good to pull a "Before V1" list because I think we are fairly close. |
It wouldn't break users who are using Despite this, I think it's ok to defer this change to a future release as long as it's before V1. I don't anticipate that changes to |
You are right (however realistically I don't see anyone else implementing this interface for some time :-) ). With the introduction of the new Pinger I think we have everything needed for the release. I'll push the current @master out to a few non-critical systems and leave it running for a week as a final test (happy to see further changes but will probably Update 20th Jan: Further changes (pinger and clean shutdown process ref issue #227) will delay this slightly; I am running the current master (ef0065f) on a few machines in production without issue. Really appreciate any other feedback from testing (every use-case differs so I will not catch all bugs!). |
v0.20 released so I'll close this issue. Thanks very much to everyone who contributed! |
Creating this issue to provide a place to discuss the next release (including session persistence). This release will contain major changes (a few of which are likely to break existing users code - permitted as we are still pre 1.0).
Due to the extent of the changes (particularly session persistence) we are keen to receive feedback from anyone using @master (the more people we know are using this successfully, the more confidence we will have that it's ready for release).
Issue creation prompted by an email to the paho-dev mailing list (an issue here seems the best place to discuss this).
The text was updated successfully, but these errors were encountered: