[keycloak-dev] infinispan as a storage mechanism

Bill Burke bburke at redhat.com
Tue Feb 27 09:02:34 EST 2018


This is something I've been doing off and on for awhile.  An hour here
or there.  Its a lot of monotonous work.

Well worth it IMO if our build times drop drastically.  30 min build
is becoming burdensome.  If the console tests get turned on combined
with all the other tests that are added daily, I can see this turning
into 60 min by the end of the year.  Not to mention when I run a
single test from the IDE it takes like 10 seconds to start.  I'm just
sick and tired of it.

For migration, if you base your stored objects on Maps, you only have
to worry about cases where you're modifying objects that are
serialized.  These would need to be versioned as per java
serialization.  New things


On Tue, Feb 27, 2018 at 1:53 AM, Stian Thorgersen <sthorger at redhat.com> wrote:
> I'm really not convinced about this. Infinispan still needs to persist the
> data. It still needs to handle migration whenever we change things. It's
> another layer to get working correctly, etc.. I think we have more important
> work than to work on another data layer.
>
> On 26 February 2018 at 21:47, Bill Burke <bburke at redhat.com> wrote:
>>
>> I'm thinking of this mostly for running our testsuite.  If you're not
>> developing on DB, much nicer if your test startup times is
>> milliseconds rather than 5-10 secs.
>>
>> For production, I'm thinking more of when people need lightweight
>> keycloak instances and are doing a lot of identity federation.  This
>> is really long term thoughts though.
>>
>> On Mon, Feb 26, 2018 at 2:56 PM, Pedro Igor Silva <psilva at redhat.com>
>> wrote:
>> > I think MongoDB will start supporting transactions very soon on v4 ....
>> >
>> > I'm not sure about running both app and database in the same VM though.
>> > For
>> > dev purposes that is fine, but in real world scenarios you probably want
>> > to
>> > avoid sharing resources (mem, cpu) with your DB. In your case, people
>> > will
>> > probably need JBoss DataGrid in production.
>> >
>> > On Mon, Feb 26, 2018 at 4:30 PM, Bill Burke <bburke at redhat.com> wrote:
>> >>
>> >> Other than MongoDB not supporting transactions or even sessions?  And
>> >> requiring a DB to be run in a separate VM?
>> >>
>> >> No not really :)
>> >>
>> >>
>> >>
>> >> On Mon, Feb 26, 2018 at 12:54 PM, Pedro Igor Silva <psilva at redhat.com>
>> >> wrote:
>> >> > Isn't this somewhat related with what we used to have with MongoDB ?
>> >> >
>> >> > On Mon, Feb 26, 2018 at 2:35 PM, Bill Burke <bburke at redhat.com>
>> >> > wrote:
>> >> >>
>> >> >> If we had a built-in, clusterable storage mechanism for Keycloak
>> >> >> using
>> >> >> Infinispan we would:
>> >> >> * Shorten build times drastically.  30 minutes and growing for me
>> >> >> for
>> >> >> JPA builds.  Liquibase + JPA startup takes 5-7 seconds on my box.
>> >> >> * Simpler startup.  No need to start a DB.
>> >> >> * Reduce memory footprint?  I think JPA is responsible for a lot of
>> >> >> classes loaded.
>> >> >>
>> >> >> I've started some work on this in spare time.  I'd say I'd be done
>> >> >> in
>> >> >> like 2 months considering the other work I have in queue.
>> >> >>
>> >> >> Looking at FineGrainAtomicMap as an implementation.  Should make DB
>> >> >> migration simple and replication quicker.
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Bill Burke
>> >> >> Red Hat
>> >> >> _______________________________________________
>> >> >> keycloak-dev mailing list
>> >> >> keycloak-dev at lists.jboss.org
>> >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Bill Burke
>> >> Red Hat
>> >
>> >
>>
>>
>>
>> --
>> Bill Burke
>> Red Hat
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>



-- 
Bill Burke
Red Hat


More information about the keycloak-dev mailing list