Neither the default realm context resolver nor the default call context resolver seems suitable for production usage:

Investigating this a bit more, I think the most problematic aspects are:

1 RealmTokenBucketRateLimiter, because this filter kicks in before the authenticating filter, thus executing itself for any request, even unauthenticated. Since it holds a map of token buckets per realm, this map can grow uncontrollably.
2. The tokens endpoint, because this resource is not protected by the authenticating filter and is invoked for every request, even unauthenticated, thus potentially growing the internal maps in LocalPolarisMetaStoreManagerFactory.

On the bright side, I think that the internal maps would not grow uncontrollably in a "real-life" scenario with EclipseLink and a real database, because the realm initialization would fail on an unknown realm:

And that initialization would be triggered by the DefaultCallContextResolver that is invoked in the PolarisApplication.ContextResolverFilter, which is the very first filter to execute. So I believe that un unknown realm would throw an exception here:

That said, it still feels a bit fragile to attempt to create a meta store session for any realm, even unknown, even if from an unauthenticated request, only to see the attempt fail.

(Also, EclipseLink with the default jdbc:h2:file datasource is likely to create meta store sessions for any realm without any form of verification.)

With #594 we have a first step into properly mitigating this issue. It makes it impossible, using the default realm resolver, to inject unknown realms into the application.