Regarding the use of eager singletons, the theory would be that there's
less resource contention at boot-up time, so there's less likely to be this
scenario, but thats not *provably *so. There's nothing to stop somebody
from binding a particularly big (dependency-wise) class as an eager
singleton and giving rise to the scenario I've outlined.
Regarding the use of a service manager, what you would imply then is that
you would register some initialization component with an injected service
at construction time, to circumvent this problem? That would mean your
constructors read like
class SomeComponent implements SomethingInitializerWants{
@Inject
public SomeComponent(Dep1 one, Dep2 two /*...*/
InitializerService initializer){
this.one = one;
this.two = two;
initializer.register(this);
}
@Override
public void doMoreInitialization(){
one.configure(this, 1.234);
this.madeModel = two.factorySomething(stuff());
}
//...
}
Is that correct?
JavaFX itself has this concept built in, I was silly enough to ignore it
without investigating exactly why its structured to have both a constructor
*and* an initializer.
Thanks for your help guys,
-Geoff
On Saturday, November 28, 2015 at 5:47:21 PM UTC-8, Christian Gruber wrote:
>
> 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]
> <javascript:>> 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]
>> <javascript:>> 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] <javascript:>.
>>> To post to this group, send email to [email protected]
>>> <javascript:>.
>>> 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] <javascript:>.
>> To post to this group, send email to [email protected]
>> <javascript:>.
>> 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/b6575c52-4929-4cba-bcf3-3d56ac9eab32%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
