I probably pasted someone's example. We've never used it successfully here. And by successful I mean that it met our performance expectations. ;-)
-Scott -Scott Battaglia PGP Public Key Id: 0x383733AA LinkedIn: http://www.linkedin.com/in/scottbattaglia On Thu, Oct 2, 2008 at 3:46 PM, Andrew Ralph Feller, afelle1 < [EMAIL PROTECTED]> wrote: > Scott, > > Yeah, I thought yall would have done so lest that feature might not have > made it into the project. =) Though since SVN blame/praise shows you > checked it in at revision 39423, I was hoping you had some knowledge about > the configuration choices made. Was this file provided by someone else > originally and simply included? > > Thank you, > Andrew > > On 10/2/08 2:07 PM, "Scott Battaglia" <[EMAIL PROTECTED]> wrote: > > Sorry, we deploy using repcache (memcached) at Rutgers. > > -Scott > > -Scott Battaglia > PGP Public Key Id: 0x383733AA > LinkedIn: http://www.linkedin.com/in/scottbattaglia > > > On Thu, Oct 2, 2008 at 2:15 PM, Andrew Ralph Feller, afelle1 < > [EMAIL PROTECTED]> wrote: > > Anyone? > > > > On 10/1/08 2:17 PM, "Andrew Feller" <[EMAIL PROTECTED] < > http://[EMAIL PROTECTED]> > wrote: > > Since we originally deployed CAS, a sample configuration file for Jboss > Cache has been distributed with the CAS server ( > https://www.ja-sig.org/svn/cas3/tags/cas-3-2-1-final/cas-server-integration-jboss/src/test/resources/jbossTestCache.xml). > Upon comparing it with our current configuration, I have noticed there > have been several discrepancies, which I hoped could be explained. > > JGroups discrepancies > > 1. <FD> has been commented out in favor of <FD_SOCK> > 2. <pbcast.NAKACK> and <UNICAST> are both used > 3. <FRAG> has been included > > > JBoss Cache Discrepancies > > 1. UseReplQueue, ReplQueueInterval, ReplQueueMaxElements are declared > but are only used by asynchronous replication > 2. TransactionManager is specified yet the online documentation for > cluster has it being removed ( > http://www.ja-sig.org/wiki/display/CASUM/Clustering+CAS ) > > > My primary focus is on the JGroup changes as I don't know if FD_SOCK uses > the same notion of shunning as FD. The source behind FD_SOCK shows removal > of suspect members and broadcasting the removal to the cluster, so it should > be okay. I am also curious why the <FRAG> entity was introduced; were > people having replication packets that were too large or being blocked due > to size? > > Thanks, > Andrew > > > -- > Andrew R. Feller, Analyst > Information Technology Services > 200 Fred Frey Building > Louisiana State University > Baton Rouge, LA 70803 > (225) 578-3737 (Office) > (225) 578-6400 (Fax) > > _______________________________________________ > Yale CAS mailing list > [email protected] > http://tp.its.yale.edu/mailman/listinfo/cas > >
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
