Just to clarify: I know this can possibly happen because of incorrectly packaged jar, but there are no such issues when we aren't using singletons. Nothing like this happens when I just add a new bolt with a new mongodb connection for example.
Also regarding abstracting DB connection logic to a separate bolt: we are using a bolt to write data to Cassandra, but I have no idea how to do that with reads. On Mon, Jul 15, 2019 at 4:16 PM Denis Sevosteenko < [email protected]> wrote: > We got NoClassDefFoundError and ExceptionInitializerError in prepare() > methods. > > On Mon, Jul 15, 2019 at 4:13 PM Petr Janeček <[email protected]> > wrote: > >> Hello, >> you'll need to define "fallen apart". What did not work and why? >> Obviously a singleton is single in one Worker (one JVM). For DB >> connections, this seems to be a good thing - you'll want every JVM to have >> a single (or, rather, a limited pool of) DB connection encapsulated in a >> singleton resource. >> >> If you want a singleton to really be single in the topology, you'll need >> to abstract away the DB connection logic to a separate microservice, or a >> single bolt. >> >> PJ >> >> ---------- Původní e-mail ---------- >> Od: Denis Sevosteenko <[email protected]> >> Komu: [email protected] >> Datum: 15. 7. 2019 15:08:26 >> Předmět: Storm and singletons >> >> Hi all, >> >> This may be an old question, but what is the correct way of using >> Singleton pattern with Storm? >> >> Currently we have a topology with around 200 bolts, of which around 50 >> read and write data from/to Cassandra. Each of these 50 bolts creates a new >> Cassandra session, which to my understanding of Cassandra is not great. We >> have tried solving this issue with several implementations of singletons: >> lazy static, eager static and enum. All of these implementations have >> worked in dev environment running on single server, but have fallen apart >> on QA environment which has two supervisor hosts. I'm new to Storm so I >> have no idea if we are missing something crucial or obvious. >> >> Thanks & Regards, >> Denis Sevosteenko >> >>
