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(a)jboss.org ------------------------------------------------------------------------ _______________________________________________ jboss-cluster-dev mailing list jboss-cluster-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-cluster-dev

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(a)jboss.org <mailto:manik@jboss.org> >> >> >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> jboss-cluster-dev mailing list >> jboss-cluster-dev(a)lists.jboss.org >> <mailto:jboss-cluster-dev@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(a)jboss.org <mailto:manik@jboss.org> ------------------------------------------------------------------------ _______________________________________________ jboss-cluster-dev mailing list jboss-cluster-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-cluster-dev

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?

> > > 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(a)jboss.org <mailto:manik@jboss.org> >>>> >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> jboss-cluster-dev mailing list >>>> jboss-cluster-dev(a)lists.jboss.org >>>> <mailto:jboss-cluster-dev@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(a)jboss.org <mailto:manik@jboss.org> >> ------------------------------------------------------------------------ >> _______________________________________________ >> jboss-cluster-dev mailing list >> jboss-cluster-dev(a)lists.jboss.org >> <mailto:jboss-cluster-dev@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(a)redhat.com <mailto:brian.stansberry@redhat.com> -- Manik Surtani Lead, JBoss Cache http://www.jbosscache.org manik(a)jboss.org <mailto:manik@jboss.org>