[keycloak-dev] infinispan as a storage mechanism

Mon Mar 5 11:45:16 EST 2018

On 5 Mar 2018 3:21 pm, "Bill Burke" <bburke at redhat.com> wrote:

I don't see how any incremental improvements would be noticable when
the bulk of the time running a single test in the IDE is spent in
JPA/Liquibase initialization.  This has really annoyed me for years.

If we're only talking the time it takes to run a single test then
improvements can be made to liquibase. We can create a new starting point.
Then there's also Hibernate that could/should be improved. We talked to
Andy about that a while ago and they where looking into it.

For total execution time there's probably loads we can do, but all takes
time and effort.

Also, I always had this worry that our RDBMS requirement might be a
turn off or complete overkill for some users, especially if they are
storing everything in LDAP or doing identity brokering.  This is
different than Mongo in that this would be self-contained.  In the
long run, removing RDBMS as a hard requirement for us would be pretty
huge.  Removes a big installation headache for customers.  Allows
Keycloak to be clusterable out of the box with parameters that we
control.

Anyways, I've been implementing this off and on for almost a year and
have never been able to finish it so we're arguing over vaporware.

If we can find out from Infinispan team perhaps if it can do what we want
and would work well then perhaps it is something worth spending time on
calendar completing. Perhaps we can drop jpa altogether and use Infinispan
with different stores instead. Maybe we could do a course dump realm config
as a single blob, but do more broken up stuff for users, roles, clients,
etc.. Would probably at least be worth looking into.

On Mon, Mar 5, 2018 at 8:58 AM, Stian Thorgersen <sthorger at redhat.com>
wrote:
> To be honest the idea of replacing our JPA layer with Infinispan
completely
> is interesting if it works/performs. Having/maintaining two in the long
run
> is very unattractive
>
> On 5 Mar 2018 11:29 am, "Stian Thorgersen" <sthorger at redhat.com> wrote:
>>
>> With regards to test execution time we're talking extra maintenance
effort
>> to save a few seconds. The base testsuite takes 20 min to run and it only
>> starts/initializes jpa/liquibase once. In memory h2 is actually a very
fast
>> persistence option once running so we're only talking about startup time.
>>
>> We'll also easily end up with issues where it worked on a local build
with
>> the mock persistence layer and it fails on jpa in ci. Or the other way
>> around. Personally I really have no interest in debugging/fixing a mock
>> persistence layer or adding/extending it for that matter. We have enough
>> pita here with the undertow in ide vs full dist in Maven/vi already not
sure
>> why we would like to make life even more complicated for ourselves.
>>
>> I'm also sure there's loads of improvements we could do to the testsuite
>> to make it run faster both for developers and CI. I would much rather
like
>> to see improvements/effort spent there than in a mock persistence layer
for
>> testing only.
>>
>> On 5 Mar 2018 10:56 am, "Boleslaw Dawidowicz" <bdawidow at redhat.com>
wrote:
>>>
>>> It testsuite local time is a main concern I know some companies are
>>> mocking DB or part of data layer to keep it down to minutes. Having
“good
>>> enough” but fast for local and proper setup in CI invoked per PR. Or
proper
>>> timely one invoked locally only rarely before wrapping up the work.
>>>
>>>
>>> W dniu śr., 28.02.2018 o 15:20 Bill Burke <bburke at redhat.com>
napisał(a):
>>>>
>>>> I often have tests that pass within the IDE, or if run singly through
>>>> maven, but fail on a maven build.  So, I'm often running a full build.
>>>>
>>>> In my measurements, skipping Liquibase only shaves off 1-2 seconds
>>>> (which is still a lot).  JPA initialization takes 5 seconds.
>>>> Testsuite slowness is 90% because of Liquibase/JPA.  At least on my
>>>> laptop.  Eventually I'll be able to give you numbers when I finish the
>>>> Infinispan backend, but I'm weeks away from that as I'm only doing it
>>>> off and on.
>>>>
>>>> On Wed, Feb 28, 2018 at 4:23 AM, Marek Posolda <mposolda at redhat.com>
>>>> wrote:
>>>> > I am also personally not concerned about running full testsuite
>>>> > through "mvn
>>>> > clean install", however I agree will be good to improve startup when
>>>> > you run
>>>> > single test from IDE.
>>>> >
>>>> > We already use in-memory H2 by default on embedded undertow. But
maybe
>>>> > it
>>>> > helps if we skip liquibase at all and let Hibernate to create the
>>>> > schema
>>>> > when running testsuite with in-mem H2? The problem with Liquibase is,
>>>> > that
>>>> > there are more and more changelogs and more and more changes and we
>>>> > can't
>>>> > get rid old changelogs. So there are many things like the table is
>>>> > created
>>>> > by jpa-changelog-1.0.0, but then immediately dropped by
>>>> > jpa-changelog-1.5.0
>>>> > etc. This is not so big issue for production environments when schema
>>>> > is
>>>> > created just once, but sucks during development IMO.
>>>> >
>>>> > Question is, how much time is spent on schema initialization and how
>>>> > much on
>>>> > other initialization things (EG. importing master realm and "test"
>>>> > realm
>>>> > etc)... Maybe to try some startup profiling will help...
>>>> >
>>>> > Marek
>>>> >
>>>> >
>>>> >
>>>> > On 27/02/18 21:08, Stian Thorgersen wrote:
>>>> >>
>>>> >> It's not going to help with startup time, but perhaps one simple way
>>>> >> to
>>>> >> make the testsuite run faster would be configuring the h2 dB as
>>>> >> in-mem/non-persisted.
>>>> >>
>>>> >> On 27 Feb 2018 7:11 pm, "Stian Thorgersen" <sthorger at redhat.com>
>>>> >> wrote:
>>>> >>
>>>> >>>
>>>> >>> On 27 February 2018 at 15:02, Bill Burke <bburke at redhat.com> wrote:
>>>> >>>
>>>> >>>> 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.
>>>> >>>>
>>>> >>> I can only see how it saves time on starting the Keycloak server,
>>>> >>> not for
>>>> >>> individual tests. That means you're only saving a few seconds each
>>>> >>> time
>>>> >>> the
>>>> >>> server is started, which is not many times for a full run. You'll
>>>> >>> probably
>>>> >>> end up shaving 1 min of the whole 30 min at best.
>>>> >>>
>>>> >>> Andy also mentioned that the Hibernate guys are working on
>>>> >>> performance.
>>>> >>> There is something weird about the Hibernate startup time in
>>>> >>> general. So
>>>> >>> if
>>>> >>> there's improvements there that 1 min you could shave would become
>>>> >>> even
>>>> >>> less.
>>>> >>>
>>>> >>> We're also working towards having the full testsuite ran on PRs,
>>>> >>> which
>>>> >>> means as a dev you would be better of picking and running only the
>>>> >>> tests
>>>> >>> you believe may be affected and let the CI run the complete set of
>>>> >>> jobs.
>>>> >>>
>>>> >>> I'd never bother running the admin console tests locally unless
I've
>>>> >>> done
>>>> >>> some changes to the admin console. I also found that running the
>>>> >>> tests
>>>> >>> from
>>>> >>> the IDE run significantly quicker than through Maven. The
difference
>>>> >>> there
>>>> >>> is down to something else than JPA as that's used in both cases.
>>>> >>> Personally
>>>> >>> I very rarely build the full distro or run the tests from Maven at
>>>> >>> all. I
>>>> >>> just let Travis do that, while I run tests through the IDE.
>>>> >>>
>>>> >>>
>>>> >>>> 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
>>>> >>>>
>>>> >>> I really don't want us to maintain two different persistence
layers.
>>>> >>> It's
>>>> >>> a lot of duplicated effort. Becomes even worse when you start
>>>> >>> thinking
>>>> >>> about things like migration, cross-dc, rolling upgrades, etc..
>>>> >>>
>>>> >>> If you are suggesting to completely drop our JPA store altogether
>>>> >>> and use
>>>> >>> Infinispan with a cache store instead that could be an interesting
>>>> >>> option,
>>>> >>> but I have loads and loads of concerns around that.
>>>> >>>
>>>> >>>
>>>> >>>>
>>>> >>>> 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
>>>> >>>>
>>>> >>>
>>>> >> _______________________________________________
>>>> >> keycloak-dev mailing list
>>>> >> keycloak-dev at lists.jboss.org
>>>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>> >
>>>> >
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> 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