[keycloak-dev] infinispan as a storage mechanism

Mon Mar 5 15:04:57 EST 2018

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

On Mon, Mar 5, 2018 at 11:45 AM, Stian Thorgersen <sthorger at redhat.com>
wrote:
>
>
> 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.
>
1.5-2 secs for liquibase.  5 secs for JPA layer.

Which is just plain odd. Liquibase actually does a lot of work looping
through the migration files to build the schema. What Hibernate does for 5
seconds is just weird. If I remember a long time ago when I was first
annoyed by Hibernate startup time it was 5 seconds for a single entity war.

>
> 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
>
>

--
Bill Burke
Red Hat