[jboss-dev] Re: Sep/14th cutoff date for component updates in AS5 Beta3

Brian Stansberry brian.stansberry at redhat.com
Fri Sep 7 19:26:46 EDT 2007


Can you clarify a bit why moving to 2.6 will never be possible?

JBC and ClusterPartition currently call:

Channel.connect(String)
Channel.getState(Address, long)
Channel.getState(Address, String, long)

Is the issue that you're changing the API of the 2 getState calls to 
throw an exception instead of returning boolean? Is that absolutely 
necessary? Changes to any other overloaded flavors of connect or 
getState don't matter since we don't call them.

Or is the issue more that the connect+getState stuff will change the way 
connecting and state transfer work so much that 2.6 will never be 
interoperable with 2.5? Kind of the old "AS 4.0.x forever stuck on 
2.2.7" problem.

In an AS 5.1
Bela Ban wrote:
> I leave this up to you guys. I would include 2.6 not 2.5 in AS 5, as we 
> will *NOT* be able to upgrade AS 5 to 2.6 ever. But it's not my call. As 
> a matter of fact, I don't mind *not* having to rush a 2.6 GA out the 
> door...
> 
> So 2.5 then huh ?
> 
> Brian Stansberry wrote:
>> I am fine with 2.5 unless in your opinion 2.6 includes some major bug 
>> fixes that really need to be in AS 5.0.0. My assumption has always 
>> been that AS 5 would be targeted toward JGroups 2.5, with 2.6 
>> integrated if it came out far enough in advance of the AS CR1 that we 
>> could properly test it.  Only reason for interest in 2.6 is just the 
>> normal desire to pick up any bug fixes or perf improvements that come 
>> along.
>>
>> Seems we're locking down the libraries for beta3 instead of CR1. That 
>> doesn't change the above.
>>
>> AIUI, the main reason for pushing for 2.6 was the API for the combined 
>> flush for connect+ multiple state transfers we discussed yesterday. 
>> That doesn't seem like something that can be high impact in AS 5.0.0.  
>> I don't see how the different, completely unrelated services that do 
>> state transfer can coordinate their state transfers, at least not 
>> without a major effort that there's no bandwidth for.  So, that leaves 
>> saving 1 flush cycle when the channel shared by all the services 
>> connects. That would be nice, but IMHO not a huge thing worth 
>> disrupting your road map to get in.
>>
>> Bela Ban wrote:
>>> Let me know as soon as possible which version of JGroups you want in 
>>> AS 5. If you want to stick with 2.5, there is no reason for us to 
>>> scramble releasing 2.6 and pushing 50% of the features into 2.7...
>>> Brian ? Dimitris ?
>>>
>>> Bela Ban
>>> Lead JGroups / Clustering Team
>>> JBoss - a division of Red Hat
>>>
>>
>>
> 


-- 
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry at redhat.com




More information about the jboss-development mailing list