we noticed in our application that if one of the message files has a parse error, then that error is almost impossible to identify given the size of the application (see below for some information).
Symptoms: Somebody adjusted the message file in a way that made the parser fail. The next person pulls the changes, tries to start the application and seemingly nothing happens. Only when looking at thread dumps, one could see that there is some activity in the area of message file parsing.
Why is that? We have about a handful of message files with hundreds of keys. Our application is quite big and the MessagesApi is injected in many places. If the initialization of the DefaultMessagesApi fails (due to a parser failure), this singleton is re-initialized again and again (in play 2.5, this is how guice works. in play 2.6, this is how lazy vals work – although I must say we are on play 2.5, so I’m not sure if play 2.6 actually has the same behavior). Essentially, this means that these message files are parsed hundreds of times, which to the user can appear like a deadlock or some other non-terminating condition.
My understanding is that this is just how things work, given how dependency injection works. At the same time, I was wondering if parsing the message files during instantiation was such a clever idea…?
In the end, this was just a quite annoying and hard to pin down issue and I was wondering whether anybody has some suggestions on how we could fail faster.
Thanks a lot.
- play 2.5, scala, guice
- ~5 message files, each about 4k keys
- hundreds of injections of MessagesApi