JHipster VS Caffeine

An easy way to get a pre-configured Keycloak instance is to use JHipster's jhipster-sample-app-oauth2 application. It gets updated with every JHipster release. You can clone it with the following command:

provider "auth0" { domain = "https://" debug = false } # Create a new Auth0 application for the JHipster app resource "auth0_client" "java_ms_client" { name = "JavaMicroservices" description = "Java Microservices Client Created Through Terraform" app_type = "regular_web" callbacks = ["http://localhost:8080/login/oauth2/code/oidc"] allowed_logout_urls = ["http://localhost:8080"] oidc_conformant = true jwt_configuration { alg = "RS256" } } # Configuring client_secret_post as an authentication method. resource "auth0_client_credentials" "java_ms_client_creds" { client_id = auth0_client.java_ms_client.id authentication_method = "client_secret_post" } # Create roles for the JHipster app resource "auth0_role" "admin" { name = "ROLE_ADMIN" description = "Administrator" } resource "auth0_role" "user" { name = "ROLE_USER" description = "User" } # Create an action to customize the authentication flow to add the roles and the username to the access token claims expected by JHipster applications. resource "auth0_action" "jhipster_action" { name = "jhipster_roles_claim" runtime = "node18" deploy = true code = <<-EOT /** * Handler that will be called during the execution of a PostLogin flow. * * @param {Event} event - Details about the user and the context in which they are logging in. * @param {PostLoginAPI} api - Interface whose methods can be used to change the behavior of the login. */ exports.onExecutePostLogin = async (event, api) => { const namespace = 'https://www.jhipster.tech'; if (event.authorization) { api.idToken.setCustomClaim(namespace + '/roles', event.authorization.roles); api.accessToken.setCustomClaim(namespace + '/roles', event.authorization.roles); } }; EOT supported_triggers { id = "post-login" version = "v3" } } # Attach the action to the login flow resource "auth0_trigger_actions" "login_flow" { trigger = "post-login" actions { id = auth0_action.jhipster_action.id display_name = auth0_action.jhipster_action.name } } # Create a test user. You can create more users here if needed resource "auth0_user" "test_user" { connection_name = "Username-Password-Authentication" name = "Jane Doe" email = "[email protected]" email_verified = true password = "passpass$12$12" # Don't set passwords like this in production! Use env variables instead. lifecycle { ignore_changes = [roles] } } resource "auth0_user_roles" "test_user_roles" { user_id = auth0_user.test_user.id roles = [auth0_role.admin.id, auth0_role.user.id] } output "auth0_webapp_client_id" { description = "Auth0 JavaMicroservices Client ID" value = auth0_client.java_ms_client.client_id } output "auth0_webapp_client_secret" { description = "Auth0 JavaMicroservices Client Secret" value = auth0_client_credentials.java_ms_client_creds.client_secret sensitive = true }

If you want a Spring backend with an Angular Frontend check out https://www.jhipster.tech. This is very nice for CRUD stuff.

Use https://www.jhipster.tech/

To test GitHub Actions, we need a new project which in this case I generated using JHipster with the configuration seen here:

exports.onExecutePostLogin = async (event, api) => { const namespace = 'https://www.jhipster.tech'; if (event.authorization) { api.idToken.setCustomClaim('preferred_username', event.user.email); api.idToken.setCustomClaim(`${namespace}/roles`, event.authorization.roles); api.accessToken.setCustomClaim(`${namespace}/roles`, event.authorization.roles); } }

What you maybe asking for is something like vaadin or jhipster which marries the front with the backend. (I don't like them tbh but it worth mentioning)

You can try this stack https://www.jhipster.tech with generator for mobile app https://github.com/jhipster/generator-jhipster-ionic.

/u/someplaceguy,

Those LIRS traces, along with many others, available at this page [1]. I did a cursory review using their traces using Caffeine's and the author's simulators to avoid bias or a mistaken implementation. In their target workloads Caffeine was on par or better [2]. I have not seen anything novel in this or their previous works and find their claims to be easily disproven, so I have not implement this policy in Caffeine simulator yet.

[1]: https://github.com/ben-manes/caffeine/wiki/Simulator

[2]: https://github.com/1a1a11a/libCacheSim/discussions/20

That, and also when caffeine came out it replaced one of the major uses (caching) of guava.

https://github.com/ben-manes/caffeine

I decided to start with an overview of what open-source options are currently available. When it comes to the implementation of the on-heap cache mechanism, the options are numerous – there is well known: guava, ehcache, caffeine and many other solutions. However, when I began researching cache mechanisms offering the possibility of storing data outside GC control, I found out that there are very few solutions left. Out of the popular ones, only Terracotta is supported. It seems that this is a very niche solution and we do not have many options to choose from. In terms of less-known projects, I came across Chronicle-Map, MapDB and OHC. I chose the last one because it was created as part of the Cassandra project, which I had some experience with and was curious about how this component worked:

Visit the official Caffeine git project and documentation here for more information if you are interested in the subject.

not to distract from your valid points but, when used properly, Caffeine + Reactor can work together really nicely [1].

[1] https://github.com/ben-manes/caffeine/tree/master/examples/c...

Yes, I think that is my main concern in that often research papers do not disclose the weaknesses of their approaches and the opposing tradeoffs. There is no silver bullet.

The stress workload that I use is to chain corda-large [1], 5x loop [2], corda-large at a cache size of 512 entries and 6M requests. This shifts from a strongly LRU-biased pattern to an MRU one, and then back again. My solution to this was to use hill climbing by sampling the hit rate to adaptively size of the admission window (aka your FIFO) to reconfigure the cache region sizes. You already have similar code in your CACHEUS implementation which built on that idea to apply it to a multi-agent policy.

Caffeine adjusts the frequency comparison for admission slightly to allow ~1% of losing warm candidates to enter the main region. This is to protect against hash flooding attack (HashDoS) [3]. That isn't intended to improve or correct the policy's decision making so should be unrelated to your observations, but an important change for real-world usage.

I believe LIRS2 [4] adaptively sizes their LIR region, but I do not recall the details as a complex algorithm. It did very well across different workloads when I tried it out and the authors were able to make a few performance fixes based on my feedback. Unfortunately I find LIRS algorithms to be too difficult to maintain for an industry setting because while excellent, the implementation logic is not intuitive which makes it frustrating to debug.

[1] https://github.com/ben-manes/caffeine/blob/master/simulator/...

A lot of Guava's most popular libraries graduated to the JDK. Also Caffeine is the evolution of our c.g.common.cache library. So you need Guava less than you used to. Hooray!

Unfortunately, I don't gather statistics on the demonstration server. I believe that the in-memory caffeine cache (https://github.com/ben-manes/caffeine) saved me.

Caffeine is a Java cache that uses a 4-bit count-min sketch to estimate the popularity of an entry over a sample period. This is used by an admission filter (TinyLFU) to determine whether the new arrival is more valuable than the LRU victim. This is combined with hill climbing to optimize how much space is allocated for frequency vs recency. That results in an adaptive eviction policy that is space and time efficient, and achieves very high hit rates.