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. For more options, visit https://groups.google.com/d/optout.
