Behavior of non-daemon threads in CDI 2.0?

[ljnelson]

Maybe I'm missing something obvious.  :-)

It's my understanding that a JVM will exit when (a) Runtime.exit() is called in some way (let's forget about this case) or (b) there are no non-daemon threads left running.

I'm seeing something that looks odd to me in a CDI 2.0 SE situation.

I'm using the container startup recipe found here: SeContainerInitializer (CDI APIs 2.0-PFD API) (so the try-with-resources loop).

Within the try-with-resources loop, on the main thread, I am creating a new Grizzly HttpServer.  Then I'm calling start() on it, which starts the server on a daemon thread.  Obviously if I do nothing else, the non-blocking start() call returns, the container auto-closes, and the VM exits.  This all makes sense to me since the only other thread created is the one created by the HttpServer.start() call, and that is a daemon (you can verify this by looking at the Grizzly HttpServer source code).

I tried (just for experimenting) to create a new non-daemon thread and have it call HttpServer.start(), followed immediately by Thread.currentThread().join().  My thought was: OK, this new thread, being a non-daemon, would prevent the VM from exiting, since it would join() on itself and thus never die.

If that's all I did, then I would expect the main loop to carry on, and so I'd expect the container to close.  But I would expect that my non-daemon thread would still be alive, and so consequently I'd expect that the VM would just block.

But instead, I see the container close and the VM exit .  I placed a println after my join() call to see if somehow the join() call was being exited prematurely.  It's not.  I catch Exception and log it--but I'm not seeing any InterruptedExceptions.  Basically, what I'm seeing is that my non-daemon thread correctly enters the join() call, where it proceeds to wait "forever", just as I'd expect...and then the VM exits anyway (and I don't really know how my thread is dying without being interrupted).  I can't come up with an explanation for how this could be happening, unless Weld is somehow aggressively killing child threads in some fashion when it closes the container.

Does Weld aggressively kill threads (surely not)?  What piece of the puzzle am I missing here?

[ljnelson]

(Related: java - Why does this non-daemon Thread not prevent the JVM from exiting? - Stack Overflow )

[mkouba]

Hi Laird,

AFAIK Weld does not kill any threads. Do you have a reproducer so that we can check the code? By the way, the fact that the Weld container is closed seems to be correct, right?

[ljnelson]

I'm working on the reproducer.

Yes, it is correct (I think) that the Weld container is closed.  It's actually a mistake on my part—I obviously want to have Grizzly running while the container is up—but when I made this mistake I then noticed that the very next thing that happened was the VM exited, which surprised me (hence this discussion).

The part that is particularly puzzling to me is that with my code at the moment I see no evidence that the thread ever "exits" its join() call.  I need to check for ThreadDeath etc. so I can understand just exactly how the join() is being exited.  Or perhaps I don't understand enough about wait() (which is how join() is implemented): perhaps a waiting Thread doesn't count as one that is alive for the purposes of the VM exiting?  Anyway, reproducer code coming later today.  Thanks for your input.

[ljnelson]

I have added a reproducer at java - Why does this non-daemon Thread not prevent the JVM from exiting? - Stack Overflow .  Again, I'm sure I'm missing something very obvious.  Thanks for your help.

[ljnelson]

This does not seem to have anything inherently to do with CDI 2.0; my apologies.  That said, you may continue to find the issue interesting as I have now boiled down the problem to something that I cannot reconcile with the behavior prescribed by the Java Language Specification.