infinispan usage

Chad La Joie lajoie at itumi.biz
Wed Sep 7 17:07:46 BST 2011


Perhaps thats the issue.  I've never used the multi-cast mechanism, I
don't think.  I've always used method where you expressing indicate
which cluster nodes there are and have it do the health check via
explicit pings.

On Wed, Sep 7, 2011 at 11:36, Paul Hethmon
<paul.hethmon at clareitysecurity.com> wrote:
> Chad,
>
>
> Thanks for the feedback.
>
> I've been working with the 5.0 release (which just came out last month).
> I'm not sure if it's my LAN set up or the default configuration files they
> provide, but it's been a pain getting multicast working properly. It is
> the first time I've every spelled multicast though. Just things like
> having to tell the JVM to prefer IPv4 and adjusting the ip_ttl property
> just to get my 2 macs to talk.
>
> The coding part of it looks pretty straightforward, the config part has
> about a zillion options.
>
> Once I get it working, I'm planning on putting it out for everyone.
>
> thanks,
>
> Paul
>
>
> On 9/7/11 11:16 AM, "Chad La Joie" <lajoie at itumi.biz> wrote:
>
>>Hey Paul,
>>
>>Well, let me give a caveat upfront.  I haven't done any testing with
>>the latest version (v5) of infinispan.  I did a fair amount of test
>>with v3 (called JBossCache then) and some testing with v4 in order to
>>explore what was new.  I did not have any issues with replication but
>>my tests were not very deep either.
>>
>>Now, to answer your specific question.  It was my intention to ship
>>with two different configs.  One based on synchronous replication and
>>another based on async distribution.  The former being appropriate for
>>systems where max availability and no mid-process loss of users was
>>required.  The later being appropriate for systems  where mid-process
>>user state might be lost in favor of greater scalability (though
>>realistically, I don't know that anyone runs such a large IdP cluster
>>that synch repl would lead to bottlenecks).
>>
>>In addition to that, I am also going to attempt to develop a
>>cookie-based state storage mechanism for our front-channel protocols.
>>That would mean that people willing to forgo artifacts, attribute
>>query, and logout support wouldn't need any clustering mechanism.  I
>>don't know if I'll be able to pull this off though, I have a feeling
>>I'll run in to problems with cookie sizes, but we'll see.
>>
>>
>>On Wed, Sep 7, 2011 at 11:05, Paul Hethmon
>><paul.hethmon at clareitysecurity.com> wrote:
>>> Chad,
>>> I'm in the midst of writing a storage service replacement for IdP 2
>>>using
>>> Infinispan. Writing a replacement is based solely on my continued
>>>trouble
>>> with Terracotta while the choice of Infinispan is based on your
>>>comments on
>>> IdP 3. My question is whether you have given thought to the cluster
>>>mode to
>>> use? In my initial testing, I'm having a problem getting replication
>>>mode
>>> working, it just hangs when a second member joins the cluster.
>>>Distribution
>>> mode seems to work just fine though. There is a bug filed for
>>>replication
>>> mode when running 2 members on the same host for Infinispan, so not
>>>quite
>>> what I'm seeing, but close.
>>> Just wanting your thoughts so I write this thing close to what IdP 3
>>>will
>>> do.
>>> thanks,
>>> Paul
>>> --
>>> Paul Hethmon
>>> Chief Software Architect
>>> Clareity Security, LLC
>>> o) 865.824.1350
>>> c) 865.250.3517
>>> e) paul.hethmon at clareitysecurity.com
>>>
>>> --
>>> To unsubscribe from this list send an email to
>>> dev-unsubscribe at shibboleth.net
>>>
>>
>>
>>
>>--
>>Chad La Joie
>>www.itumi.biz
>>trusted identities, delivered
>>--
>>To unsubscribe from this list send an email to
>>dev-unsubscribe at shibboleth.net
>
> --
> To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net
>



-- 
Chad La Joie
www.itumi.biz
trusted identities, delivered


More information about the dev mailing list