[cas-dev] cas-server-integration-ehcache

[Tillinghast, Andrew P.]

Original Jira issue: https://issues.jasig.org/browse/CAS-816

Wiki Article: https://wiki.jasig.org/display/CASUM/EhcacheTicketRegistry

I simple took the wiki Article from unicon, cleaned it up a little and built the directory structure and pom so that it could be distributed in with the core CAS as any easy HA option.

As a deployer I went with ehcache instead of memcacge/repcache because there was so little documentation for repcache. 

Also needed the option to designate end points as multicast is disabled for most of our network and I couldn't find any way to do that within repcache.

The code is here: https://github.com/atilling/cas/tree/feature-ehcache

I have created a pull request to have this module incorporated with jasig/cas 

Andrew Tillinghast

Sr. Web Developer

atil...@conncoll.edu

270 Mohegan Avenue

New London, CT 06320-4196

Ph:860 439-5265 Fax: 860 439-2871

P Think before you print
CONFIDENTIALITY: This email (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you received this email in error, please notify the sender and delete this email from your system.

-- 
You are currently subscribed to cas...@lists.jasig.org as: jasig-cas-dev+...@googlegroups.com
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev

[Marvin Addison]

I will review the patch this week and provide feedback on the pull request.  Provided the code looks good, I would be in favor of adding this module to core if an only if you'd be willing to take on the role of maintainer.  Are you willing to own this module for the long haul?

M

[Scott Battaglia]

On Mon, Nov 14, 2011 at 9:39 AM, Marvin Addison <marvin....@gmail.com> wrote:

I will review the patch this week and provide feedback on the pull request.  Provided the code looks good, I would be in favor of adding this module to core if an only if you'd be willing to take on the role of maintainer.  Are you willing to own this module for the long haul?

+1 that was going to be my major question.  Just a note that ownership of the module includes migration to the CAS4 Storage APIs when they get rolled into master :-)

 

M

-- 
You are currently subscribed to cas...@lists.jasig.org as: scott.b...@gmail.com

To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev

[Tillinghast, Andrew P.]

Currently Connecticut College is using ehcache as a HA solution and we intend to continue both CAS and ehCache. 

Some questions I have related to this:

What is the term of commitment? If this is a requirement for someone to contribute then I think it needs a better definition.

What happens with a module that no longer has a maintainer? 

How is a module demoted from CAS distribution? I ask this question for both the cases where the module isn't maintained or in the cases where a module should be depreciated in favor of a more stable solution - ie spnego vs jaas.

-Andrew

On Nov 14, 2011, at 9:39 AM, Marvin Addison wrote:

I will review the patch this week and provide feedback on the pull request.  Provided the code looks good, I would be in favor of adding this module to core if an only if you'd be willing to take on the role of maintainer.  Are you willing to own this module for the long haul?

M

-- 
You are currently subscribed to cas...@lists.jasig.org as: atil...@conncoll.edu

To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev

[Marvin Addison]

> What is the term of commitment?

Until the module exits core or until you delegate the commitment to
someone else.

> If this is a requirement for someone to contribute then I think it needs a better definition.

I understood that you are attempting to contribute a new module to
core, is that correct? Assuming it is correct, then it's a special
case of contribution. We simply want to only include modules in core
that are actively maintained; new modules need new maintainers.

> What happens with a module that no longer has a maintainer?

It becomes liable to removal. The Berkeley DB module is undergoing
this process at present for lack of maintainer and interest.

M

--

[William G. Thompson, Jr.]

I can back up Andrew T. on EhCache module maintenance or take primary
if he's not able.

Bill

On Mon, Nov 14, 2011 at 9:09 AM, Marvin Addison
<marvin....@gmail.com> wrote:
>> What is the term of commitment?
>
> Until the module exits core or until you delegate the commitment to
> someone else.
>
>> If this is a requirement for someone to contribute then I think it needs a better definition.
>
> I understood that you are attempting to contribute a new module to
> core, is that correct?  Assuming it is correct, then it's a special
> case of contribution.  We simply want to only include modules in core
> that are actively maintained; new modules need new maintainers.
>
>> What happens with a module that no longer has a maintainer?
>
> It becomes liable to removal.  The Berkeley DB module is undergoing
> this process at present for lack of maintainer and interest.
>
> M
>
> --

> You are currently subscribed to cas...@lists.jasig.org as: wgt...@gmail.com

[Marvin Addison]

> I can back up Andrew T. on EhCache module maintenance or take primary
> if he's not able.

Sounds good. I have no further procedural concerns about this module.
I still owe a code review by the end of the week.

M

--

[Scott Battaglia]

Two active maintainers is acceptable also :-)

We should probably document the maintainers somewhere.  Is the web site About section that lists the developers appropriate?

On Wed, Nov 16, 2011 at 10:19 AM, Marvin Addison <marvin....@gmail.com> wrote:

> I can back up Andrew T. on EhCache module maintenance or take primary
> if he's not able.

Sounds good.  I have no further procedural concerns about this module.
 I still owe a code review by the end of the week.

M

--

You are currently subscribed to cas...@lists.jasig.org as: scott.b...@gmail.com

To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev

[Marvin Addison]

> We should probably document the maintainers somewhere.

+1

> Is the web site
> About section that lists the developers appropriate?

Perhaps on the web and in the pom would be better. I'm thinking
<role>module lead</role> in the root pom and <role>developer</role> in
the module pom. Putting roles and responsibilities close to the code
is a good thing.

M

--

[Scott Battaglia]

Sounds like a plan.  Can you create a JIRA issue?  Otherwise I'll create it tonight.

On Thu, Nov 17, 2011 at 2:15 PM, Marvin Addison <marvin....@gmail.com> wrote:

> We should probably document the maintainers somewhere.

+1

> Is the web site
> About section that lists the developers appropriate?

Perhaps on the web and in the pom would be better.  I'm thinking
<role>module lead</role> in the root pom and <role>developer</role> in
the module pom.  Putting roles and responsibilities close to the code
is a good thing.

M

--
You are currently subscribed to cas...@lists.jasig.org as: scott.b...@gmail.com

To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev

[Marvin Addison]

> Can you create a JIRA issue?

Voila, https://issues.jasig.org/browse/CAS-1069.

M

--

[Alexandre DE PELLEGRIN]

@Andrew,

Just a little question : which extension do you use to replicate tickets between caches? Here, I use JGroups instead of RMI or Terracota.

JGroups has the advantage to take an IP port range to establish connection between nodes and it doesn't need to use multicast. My network admin

really like that.  

BTW, don't hesitate to contact me if you need some information about the way I implemented JGroups. For example, I had to implement a fallback algorithm

because it seems that cache synchronization over JGroups is always asynchronous so you can have to validate a service ticket than is not yet replicated.

I've been using this solution in production for 5 months without any problem. (Previously, I had a memcached+repcached but this architecture was too complex  

for sys admin and I decided remove any external dependecy other than LDAP from our CAS server). 

Best regards,

Alexandre de Pellegrin

ESSEC Business School

2011/11/17 Marvin Addison <marvin....@gmail.com>

> Can you create a JIRA issue?

Voila, https://issues.jasig.org/browse/CAS-1069.

M

--

You are currently subscribed to cas...@lists.jasig.org as: depel...@essec.edu

To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev

[Tillinghast, Andrew P.]

We are using RMI, we had originally used a JGroups implementation because most of our  routers filter multicast.

The one issue we had with JGroups is that when bringing up a server there were times where the availability of the peer server would cause the server to hang for a little while. Off hand I don't remember which state the peer would be in that would cause the hang, I think it was where the peer wasn't on at all or where the peer was on but the CAS service wasn't running. 

Since then we've moved the CAS servers to a separate, isolated VLAN behind our load balancer and we've switched to RMI now we're happier with the performance and the stability. 

-Andrew

-- 
You are currently subscribed to cas...@lists.jasig.org as: atil...@conncoll.edu

To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev