Agreed. Generally making your objects cheap to construct and separating initialization from construction using something like guava's ServiceManager for startup/shutdown logic.
On Sat, Nov 28, 2015, 14:44 Nate Bauernfeind <[email protected]> wrote: > I believe I've avoided this by 1) using eager singletons and 2) separating > object creation from service starting. (I.e. Constructors only construct, > and then a start/stop method is required for all services that "do stuff".) > > On Sat, Nov 28, 2015, 5:38 PM Geoff Groos <[email protected]> > wrote: > >> Hey guys, >> >> We're developing a GUI'd application with guice. >> >> I recently discovered a horrifying and rather tragic behavior within our >> software, *once in a while* it will enter deadlock when running under a >> couple specific situations. >> >> I've got this deadlock down to a contention between two resources: >> >> - The JavaFX thread --specifically, we've written a method called >> runImmedlatelyOnFX. the source code can be found here >> <https://gist.github.com/Groostav/2944cb86e87848399924>, but its >> effectively draining the fx job queue. >> - A singleton's constructor. >> >> The scenario is: >> >> 1. Worker-Thread requests and instance of singleton-class B from >> guice. >> 2. Guice acquires some kind of mutex to indicate that its >> constructing a singleton, and calls the Class-B constructor on >> Worker-Thread. >> 3. the JavaFX application thread requests an instance of >> singleton-class B from guice. *It's blocked by guice pending the >> result from Worker-Thread's Class-B-Construtor call*. >> 4. The constructor for singleton-class B calls runImmediatelyOnFX. *It's >> blocked until the JavaFX thread executes its enqueued job* >> >> *and we have deadlock.* >> >> >> So I don't think it will be too helpful to get into a deep discussion >> about our usage of JavaFX, but I'm wondering if anybody else has run into >> this problem, and if there's some miracle solution I'm not aware of. >> >> >> The two things I can employ to mitigate/solve this problem: >> >> - There is one overt use case for this runImmediately business, and >> it has to do with loading fxml documents (typically done in constructors). >> If I make our UI code a little bit more flexible about when it actually >> gets an instanced view tree (read: in a callback rather than in the ctor), >> we can reduce the number of ctor's that block on runImmediately() >> quite significantly. >> - I can use use Quantem's enterNestedEventLoop() >> >> <http://grepcode.com/file/repo1.maven.org/maven2/net.java.openjfx.backport/openjfx-78-backport/1.8.0-ea-b96.1/com/sun/javafx/tk/Toolkit.java#Toolkit.enterNestedEventLoop%28java.lang.Object%29> >> to give the appearance of running immediately on the javaFX thread without >> actually blocking the javaFX thread. This will likely defeat the purpose >> of >> the method for some use cases, so the old "enqueue the job and wait" >> strategy will have to remain available for them, but it will likely be >> sufficient for most of the callers. >> >> >> Is there something I'm missing? Is there some architectural master stroke >> somebody can fill me in on to deal with this problem quickly and easily? >> >> >> One of the things I'm looking to do now is start failing integration >> tests when they notice the potential for this deadlock. My plan for this is >> to have SyncingUtilitles.runImmediatelyOnFXThread and guice singletons act >> like resource acquisitions, with each checking to see if the thread they're >> running on has already acquired the other. If they have, they would log >> some kind of warning that they may be entering deadlock. logging a warning >> will fail our cucumber performance tests and our ranorex UI automation >> tests, which should prevent us from pushing new code with these issues. >> >> >> I haven't started writing that provision listener, is it technically >> possible? >> >> >> Thanks for any help! >> >> >> -Geoff >> >> -- >> You received this message because you are subscribed to the Google Groups >> "google-guice" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/google-guice. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/google-guice/2b89be39-c127-45e0-871d-4e46b42812ae%40googlegroups.com >> <https://groups.google.com/d/msgid/google-guice/2b89be39-c127-45e0-871d-4e46b42812ae%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- > You received this message because you are subscribed to the Google Groups > "google-guice" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/google-guice. > To view this discussion on the web visit > https://groups.google.com/d/msgid/google-guice/CAHNex9_yOGiT05y52944yQQOrJEWEGZPeoNC350MHaZ27fLOyQ%40mail.gmail.com > <https://groups.google.com/d/msgid/google-guice/CAHNex9_yOGiT05y52944yQQOrJEWEGZPeoNC350MHaZ27fLOyQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "google-guice" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/google-guice. To view this discussion on the web visit https://groups.google.com/d/msgid/google-guice/CAHsNDCSO74iaRi9DqutzirFE4JnDkWipMSwgdJ-zquJh4QtoEQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
