fre 2013-02-01 klockan 11:27 +0100 skrev Alexandre DE PELLEGRIN:
> I agree with you. Or perhaps it's due to the audit module based on
> AspectJ. Before activating this module, I didn't realize that.
>
> Before my migration to ehcache, I also lived two years with memcached.
> I remember that nothing was evicted from the cache
> and the delete seemed to do nothing. So, we used it just as a fifo cache.
No, MemcacheTicketRegistry delete tickets when asked to, see snippet
below, and it works fine. Unless TicketRegisty interface is broken, any
TicketRegistry that returns a ticket on getTicket after a call to
deleteTicket is broken. Any code that *depends* on a ticket registry
returning a ticket after it's been deleted is broken. However, it may
well call getTicket if it feels like for whatever purpose, nothing wrong
in that, but should then handle the null it ought to receive.
public boolean deleteTicket(final String ticketId) {
log.debug("Deleting ticket {}", ticketId);
try {
return this.client.delete(ticketId).get();
} catch (final Exception e) {
log.error("Failed deleting {}", ticketId, e);
}
return false;
}
This is really what concerns me with this. I get the not fully confirmed
feeling that some ticket registries have developed weird behaviours
outside the contract that other parts of the server has started to
depend on and this sets of all sorts of alarm clocks with me.
Like returning tickets that should have been deleted.
Like calling expire on tickets on deletion.
This is sloppy and will explode.
Best regards,
/Fredrik
--
You are currently subscribed to cas-dev@lists.jasig.org as:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-dev
