Jboss Cache resource

[Scott Battaglia]

We saw horrible response times even at relatively low load.  I don't have
the numbers with me here.  We were running it on two Sun V240s.  Our current
set up with two Sun T5120 and repcache performs significantly faster
(ignoring the fact that the machines are in general a lot faster than the
V240).

-Scott

-Scott Battaglia
PGP Public Key Id: 0x383733AA
LinkedIn: http://www.linkedin.com/in/scottbattaglia


On Fri, Oct 3, 2008 at 8:00 AM, Andrew Ralph Feller, afelle1 <
afelle1 at lsu.edu> wrote:

>  Now that is something interesting!  What performance expectations did it
> not meet?  Throughput (# logins / second)?  Network Utilization?
>
> Thanks,
> Andy
>
>
> On 10/2/08 3:16 PM, "Scott Battaglia" <scott.battaglia at gmail.com> wrote:
>
> 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 <
> afelle1 at lsu.edu> 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" <scott.battaglia at gmail.com <
> http://scott.battaglia@gmail.com> > 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 <
> afelle1 at lsu.edu <http://afelle1@lsu.edu> > wrote:
>
> Anyone?
>
>
>
>
> On 10/1/08 2:17 PM, "Andrew Feller" <afelle1 at lsu.edu <
> http://afelle1@lsu.edu>  <http://afelle1@lsu.edu> > 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
> cas at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas/attachments/20081004/c3ebc119/attachment.html