[jboss-cluster-dev] JGroups configurations in JBoss AS 5

Brian Stansberry brian.stansberry at redhat.com
Tue Feb 24 12:27:13 EST 2009


Manik Surtani wrote:
> 
> On 24 Feb 2009, at 17:19, Brian Stansberry wrote:
> 
>> It's the default because it's what been used for years with relatively 
>> few complaints. Also it doesn't involve opening new connections 
>> between nodes, which is one less moving part and possible firewall issue.
>>
>> That said, by default the HAPartition service also uses the same 
>> protocol stack config as the JBC instances. But HAPartition supports 
>> STREAMING_STATE_TRANSFER, so the protocol stack can be converted.
>>
>> All that said though, this is another negative to putting JBC 3.1 in 
>> AS 5.1.
> 
> Another negative in that it is another change.  Not that it is another 
> change that will break stuff.  Correct?
> 

Sorry! Yeah, just that it's another change.

>>
>>
>> Manik Surtani wrote:
>>> Yes, but it relies on an open stream between the 2 instances.  State 
>>> is written without a flush, and then a marker is placed on the stream 
>>> asking the state requester to start a partial flush so that the final 
>>> tx log can be written to the stream as well.
>>> cc'ing Jason since I realise he is not on the jboss-cluster-dev mail 
>>> list.
>>> On 24 Feb 2009, at 16:18, Bela Ban wrote:
>>>> Why does it require STREAMING_STATE_TRANSFER ? Doesn't it just call 
>>>> JChannel.getState() ?
>>>>
>>>> Manik Surtani wrote:
>>>>> I noticed that the JGroups configs in JBoss AS 5.0.0 and 5.0.1 uses 
>>>>> STATE_TRANSFER as opposed to STREAMING_STATE_TRANSFER.  Is there 
>>>>> any reason for this default?
>>>>>
>>>>> The reason I ask is that non-blocking state transfer in JBoss Cache 
>>>>> 3.1.0 requires STREAMING_STATE_TRANSFER to work and I was wondering 
>>>>> whether this may cause other issues elsewhere in the AS.
>>>>>
>>>>> Cheers
>>>>> -- 
>>>>> Manik Surtani
>>>>> Lead, JBoss Cache
>>>>> http://www.jbosscache.org
>>>>> manik at jboss.org <mailto:manik at jboss.org>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>> _______________________________________________
>>>>> jboss-cluster-dev mailing list
>>>>> jboss-cluster-dev at lists.jboss.org 
>>>>> <mailto:jboss-cluster-dev at lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-cluster-dev
>>>>>
>>>>
>>>> -- 
>>>> Bela Ban
>>>> Lead JGroups / Clustering Team
>>>> JBoss - a division of Red Hat
>>>>
>>> --
>>> Manik Surtani
>>> Lead, JBoss Cache
>>> http://www.jbosscache.org
>>> manik at jboss.org <mailto:manik at jboss.org>
>>> ------------------------------------------------------------------------
>>> _______________________________________________
>>> jboss-cluster-dev mailing list
>>> jboss-cluster-dev at lists.jboss.org 
>>> <mailto:jboss-cluster-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/jboss-cluster-dev
>>
>>
>> -- 
>> Brian Stansberry
>> Lead, AS Clustering
>> JBoss, a division of Red Hat
>> brian.stansberry at redhat.com <mailto:brian.stansberry at redhat.com>
> 
> --
> Manik Surtani
> Lead, JBoss Cache
> http://www.jbosscache.org
> manik at jboss.org <mailto:manik at jboss.org>
> 
> 
> 
> 


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



More information about the jboss-cluster-dev mailing list