NB: my mail was stucked somewhere for a few days. It is obsolete since Misagh
implemented a Redis-pubsub-synchronised-memory-cache for the tickets :-)
On 14/11/2022 14:54, Pascal Rigaux wrote:
Hi,
Commit "support a second-level inmemory cache for redis" implements a memory cache
[ ticketId
Hi,
Commit "support a second-level inmemory cache for redis" implements a memory cache
[ ticketId => Ticket ]
=> nice speed-up since getting a new ST requires a lot of calls to "getTicket"
to get the TGT (~8 calls on CAS 5.3, ~15 calls on CAS 6.5)
(hence the 0ms vs 2ms with one java node)
very nice!
Could I ask you to also verify master (or v7 RC2) with a clustered
setup, whenever you find the chance? I was able to make the cache work
across the cluster, and I think you should see the average time be
closer to 0.
On Fri, Nov 18, 2022 at 9:33 PM leleuj wrote:
>
> Hi,
>
> Some
Hi,
Some follow up on this master.
I have made new performance tests between v6.6.2 and v6.6.3-SNAPSHOT to
evaluate the backport from v7.
For 5000 logins and service ticket validations:
6.6.2 :
Average time: 221 ms
6.6.3-SNAPSHOT:
Average time: 4 ms
Performance are now very good for the
Hi,
I just started the development of pac4j v6.
CAS v7 will use pac4j v6.
So the ETA is *February 2023*, just before CAS v7.
It is based on *JDK 17*.
The deprecated *pac4j-saml*, *pac4j-cas* and *pac4j-springboot *modules are
removed.
The *pac4j-saml-opensamlv5* module is renamed as
