Forgot to send to the list :)<br><br><br>---------- Forwarded message ----------<br>From: Dan Berindei <<a href="mailto:dan.berindei@gmail.com">dan.berindei@gmail.com</a>><br>Date: Tue, May 15, 2012 at 7:41 PM<br>Subject: Re: Backward compatibility and rolling upgrades<br>
To: Manik Surtani <<a href="mailto:manik@jboss.org">manik@jboss.org</a>><br><br><br>On Tue, May 15, 2012 at 4:31 PM, Manik Surtani <<a href="mailto:manik@jboss.org">manik@jboss.org</a>> wrote:<br>><br>> On 15 May 2012, at 10:53, Sanne Grinovero wrote:<br>
><br>>> Since I've been long advocating this (thanks Tristan to point it out<br>>> first) I appreciate the strong push from the project lead.<br>>> Still as you say in the first half of the mail this wasn't supposed to<br>
>> work in previous releases, so why are your 3 points in the end of the<br>>> mail asking specific details to migrate from 4.2 ?<br>><br>> Because we (Red Hat services) would need to provide a ramp-up to getting people already using 4.2 onto JDG (based on 5.1) without any downtime. Granted, Red Hat services will charge for this, we still need to be able to help them out with building such a tool.<br>
><br>>> It's too late to bridge for existing versions, you can't even patch<br>>> them as people running them are already running them.. unless you<br>>> intend to make intermediate releases, such as a "4.2/5.1" specific<br>
>> release.<br>><br>> I was thinking perhaps a 5.1.Compat release which can parse and participate in a 4.2-style state transfer, etc. It would be a case of then upgrading half the cluster to 5.1.Compat, then the other half to full 5.1, and then the first half again to full 5.1.<br>
><br><br>Manik, I doubt that stock JGroups 3.0.x is binary compatible with<br>JGroups 2.12.x, but we could perhaps copy the protocols from 2.12 to<br>create a 3.0.compat version. When the entire cluster is running<br>5.1.compat, we could close the compat-mode channels all at once and<br>
start new JGroups 3.0 channels. We'd need some kind of "disable state<br>transfer" switch, but it sounds doable.<br><br>OTOH, 4.2 state transfer requires partial state transfer support from<br>JGroups (at least in replicated mode). I'm not sure if Bela can hack<br>
partial state transfer back into 3.0 to support state transfer from<br>4.2 -> 5.1 in replicated mode. For distributed caches I think it may<br>be easier, the 4.2 rehashing code should still work with JGroups 3.0.<br><br>
Even if we do get state transfer working, the nodes then have to<br>interact: 5.1 nodes have to respond to 4.2 commands, and 4.2 nodes<br>have to respond to 5.1 commands. I'm pretty sure we have some<br>incompatibilities, with all the optimization rounds that we had going<br>
on...<br><br>>> Did you see the issues we opened back in Lisbon on JIRA? they are<br>>> supposed to make it possible to perform a rolling upgrade, but need to<br>>> be included in the project *before* as I had already pointed out, to<br>
>> make it possible to migrate to future versions.<br>>><br>>> All issues are still open, apparently not considered important enough<br>>> :-( see <a href="https://issues.jboss.org/browse/ISPN-1410">https://issues.jboss.org/browse/ISPN-1410</a> and all it's<br>
>> dependencies.<br>><br>> I saw this, but I think there are a few bits missing. From your umbrella JIRA:<br>><br>> ISPN-1409: why is this necessary? CacheLoaders use VersionAwareMarshallers which create versioned streams as it is. So from a serialisation perspective, we should be protected.<br>
><br><br>Looking at the code of VersionAwareMarshaller, it reads the version id<br>in startObjectInput but it doesn't do anything with it...<br>Also, how do you register an Externalizer to handle a particular version?<br>
<br>> ISPN-1406: Not sure I understand the purpose of this. If we're writing through to a cache store then this happens anyway.<br>><br><br>Assuming VersionAwareMarshaller does pick the right Externalizer based<br>
on the version id...<br><br>>> As I see it, even JDG customers won't be able to migrate to newer<br>>> versions since this wasn't tested and for sure there will be more<br>>> changes needed: I certainly won't presume our theoretical draft will<br>
>> work flawlessly in practice.<br>><br>> Yes, this definitely needs work, and more than that, as you say, some real-world migration tests.<br>><br>>> Also the thread we opened on Flags is relevant (active even today)<br>
><br>> +1.<br>><br>> But I'm still very curious about the 3 points I raised in my original email. :)<br>><br>