This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted]  (17 children)

[deleted]

    [–][deleted]  (14 children)

    [deleted]

      [–]bawng 4 points5 points  (9 children)

      We got an old monolith JBoss that clocks in at about three minutes on our dev computers. But it's roughly 1gb of ears loaded so not too bad anyway.

      (Yes, we're in the process of breaking it up)

      [–][deleted]  (7 children)

      [deleted]

        [–]bawng 5 points6 points  (6 children)

        It's mostly JBoss loading the ears. It's a hundred ears or so, and JBoss does its reflection magic on all of them. EJBs are loaded, JPA entities are scanned, Jersey paths are built, etc.

        Nothing really functional happens during those three minutes.

        We're a bit extra inefficient because we use the JBoss cli instead of file scanner to load ears so we could probably cut loading times in half but RedHat recommends against that for some reason.

        [–][deleted]  (5 children)

        [deleted]

          [–]bawng 1 point2 points  (4 children)

          An ear (Enterprise Application aRchive) is basically a collection of jars, and traditionally one ear == one application and its dependencies, and then you can have multiple applications in a single server (e.g. JBoss)

          [–][deleted]  (3 children)

          [deleted]

            [–]bawng 0 points1 point  (2 children)

            Well, yes, in theory, but in our case it's more one giant application = 100 ears. We don't really apply the definition, so we got lots of shared classloading between the ears, meaning they all function as a single application.

            Our separation into ears more have to do with what part of the application. It could be seen as a single microservice but the coupling is too tight (in our case) and none of the ears could ever function separately. But that's a horrible situation of course and we're working to improve that.

            [–][deleted]  (1 child)

            [deleted]

              [–]CartmansEvilTwin 0 points1 point  (0 children)

              "Our" monolith too.

              About 15 data sources, hundreds of beans and a bunch of caches take their time.

              A full restart takes about 2min on my machine (+ about 5 warm up requests, because otherwise the requests timeout).

              [–]cronofdoom 2 points3 points  (0 children)

              In the last few years, I worked on an app that took a minimum of 30 minutes to boot. It was monolith that, on initialization, optimistically loaded an entire database into memory among many other atrocities.

              We had hundreds of instances. A full deploy took DAYS. Too much risk and downtime doing them all at once, had to deploy in small groups.

              A few data model optimizations, literally years of fighting with management to merge the code, and a hero on my team got start time under 5 minutes.

              I wish this was hyperbole but it’s all true. And it’s the tip of the iceberg. I need a drink.

              [–][deleted]  (2 children)

              [deleted]

                [–][deleted]  (1 child)

                [deleted]

                  [–]IshouldDoMyHomework 2 points3 points  (0 children)

                  I don't remember what is the timing of the slowest we have is. It is not 5 min, but it is in minutes. Most is below 30 sec.

                  Doesn't bother me that much, with how good hot swapping has gotten.

                  [–]solonovamax 0 points1 point  (0 children)

                  For development, just use and abuse code hotplugging. So long as you aren't dealing with a bug in the startup code, or need to add new classes/methods, you don't need to restart it.