is this error storage related ?

[Jonathan Johnson]

Tracked this down to one of the update methods in the hazelcast storage service storing the wrong expiration (relative, which is used by hazelcast, rather than absolute, used by shib). I’ve pushed the change to the repo. Anyone noticing problems like this should update when they can. I’m surprised this hasn’t surfaced before.

It might be worth noting in the javadocs somewhere that the expiration is used for something other than just pure expiration. The original implementation that I wrote didn’t store this since the underlying storage mechanism took care of it for me.

Thanks.

-Jj

On February 2, 2016 at 11:47:17, Kevin Foote (kpfoote at uoregon.edu) wrote:


> On Feb 1, 2016, at 3:47 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:  
>  
>> I have pulled the Hazelcast backed storage for now and returned to server-side.  
>  
> You mean client-side?  

Sorry, I reverted back to in memory (shibboleth.StorageService) for the server side session layer - needed for CAS protocol.  

> Who wrote the plugin? Maybe there's a bug in it, possibly how it's storing the record expirations.  

Yea.. Unicon. I’m getting them data as well.  


--------  
thanks  
kevin.foote
--  
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160204/3e791bd2/attachment-0001.html>