[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