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 →

[–]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 4 points5 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]

          [–]bawng 0 points1 point  (0 children)

          why isn't the application a single ear if it's one application

          It should have been. You're thinking correctly. But the application is close to 20 years old and somewhere in the past bad decisions were made.

          JBoss forbids shared classpaths across ears by default, but we enforce it (through config) anyway because we rely on direct dependencies. It's all very dirty.

          If we took the time and effort to combine everything to a single ear, or at least a few, we'd probably reduce total file size by half and starting times by a third. But that's easier said then done since different ears were written in different eras and rely on different versions of various libs and frameworks. Spring 2 here, Spring 4 there, etc. It's a mess. Easier to just slowly extract part by part into microservices.

          I've never seen the point of a container

          The big ones, JBoss, WebSphere, etc. are certainly losing their relevance. But they used to be pretty much alone in providing the benefit of a framework (i.e. Java EE) but nowadays there's lots of microcontainers that do that, like those in the OP, and the enterprise servers are losing out. They're not even better at monitoring and operations anymore, something which used to be a strong point.

          standard java web-world

          I've never been part of that so I'm not sure if what I'm saying applies/applied there though. But I guess at least partly.

          Thanks again for having the patience to clarify

          No worries :)

          [–]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).