gemmellr commented on PR #5079: URL: https://github.com/apache/activemq-artemis/pull/5079#issuecomment-2230548047
> > I find it awkward to reconcile the encoding having changed, with there being no consideration needed at all in terms of upgrade behaviour. > > The _main_ thing that changed here is the calculation of the encoding size, a calculation which isn't performed during the decoding process. > > The only actual encoding change was to fix a bug where encoding & decoding were using mismatched methods. Encoding was using `writeString` and decoding was using `readNullableString`. Technically speaking, this could have been fixed by changing the decoding to using `readString`, but that would have had implications for compatibility. Instead I changed the encoding to use `writeNullableString` which means that the data in the buffer is correct now and there should be no compatibility issues. > > > By 'continue to work as it always had', do you for example mean 'continue to behave incorrectly, until only data generated by new brokers exists'? > > If you have an old broker sending broken data to a new broker the new broker will choke on it. I don't see a reasonable way to avoid that. To clarify, are you saying that this fact needs to be documented? > > > ...if the calculated size has changed...couldnt that have similar effect during the access of old persisted data with the wrong encoded size by a newer broker? > > The encoding size is calculated and written to disk (or wire) along with the record. The new calculation won't come into play when reading this old data. The new broker will read the data from disk just like the old broker did since there's been no changes to decoding. Ok, so you have confirmed everything I thought would be the case. So yes, I think it is reasonable that is at least noted somewhere, even if just the JIRA. Someone who has hit this, upgrades their broker and has now a 'bug fixed' version, is likely to expect that completely resolves their issue. If it actually wont change anything until only data generated by new brokers is in play, it feels like that should be stated so the user can figure that out and learn what to do about it. E.g is it a case of deleting their store to remove the old persisted thing? Removing a specific config and recreating it? Other? I really dont know, hence the suggestion we should perhaps have a few word covering the scenario for anyone else that wouldnt immediately know. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org For additional commands, e-mail: gitbox-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
