Bug 900923 (JBPAPP6-1073)

Attaching simple app from Seam 3 examples.

Attachment: Added: faces-shortly.war

Attaching jstack output (you can see output for MSC service thread 1-4)

Attachment: Added: jstack-output

Since this is a CLI issue, assigning to Alexey for triage.

How come when a thread on the server-side is stuck it is a tool's issue? With that approach any bug in the AS is a CLI bug...
Is there a tool that can successfully undeploy it?

Issue discussed in community looks related regarding the issue with undeploying the application.   CLI is not related.
https://community.jboss.org/message/762306

@cheng can you assess the root cause of this issue

I was able to reproduce it on EAP 6.0.1 ER2 build, and AS 7.1.3.Final, but not on AS7 master or AS7 7.1.3.Final-SNAPSHOT build.

So it appears some commits might have fixed it after 7.1.3.Final was tagged.  The last commit in 7.1.3 was:
{noformat}
commit f1f5122c0b675454f91e9c458cc1aa9545f2c32c
Author: Brian Stansberry <brian.stansberry>
Date:   Fri Sep 21 14:14:05 2012 -0500

    Prepare for 7.1.3.Final

commit 59fa8f3e565abb52b958c22380261c03b5b041e7
Author: Scott Marlow <smarlow>
Date:   Thu Sep 13 15:42:20 2012 -0400

    AS7-5549 Add support for @PersistenceContexts
{noformat}

The direct cause is a wait() call in org/jboss/as/naming/ServiceReferenceObjectFactory while getting object instance from the lookup result:
{code:java}
-        synchronized (listener) {
-            // if we are interrupted just let the exception propagate for now
-            while (!listener.finished) {
-                try {
-                    listener.wait();
-                } catch (InterruptedException e) {
-                    throw MESSAGES.threadInterrupt(serviceName);
-                }
-            }
-        }
{code}

The notifyAll() call in org.jboss.as.naming.ServiceReferenceObjectFactory.ServiceReferenceListener#handleStateChange, which supposedly will end the wait, is not executed in this case.  The controller.state is DOWN during undeployment.

However, by looking at the code path, I don't see why this wait() call is needed.  The listener add operation is synchronous.  After removing the wait() call, I was able to get the undeploy work.

Why does the undeploy work in as7 master build and as7 7.1 post-7.1.3.final build?  The reason is in those more recent builds, the BeanManager resource is bound to jndi as a link ref which points to java:comp/env/BeanManager, and its actual type is ...weld.manager.BeanManagerImpl.  So the lookup operation will not include resolving javax.naming.Reference nor org.jboss.as.naming.ServiceReferenceObjectFactory

2 options from what I can see:
1, for EAP 6.0.1 to pick up whatever has been committed after 7.1.3.final to better support BeanManager resource;

2, for EAP 6.0.1 to keep the current BeanManager resource support in 7.1.3.final, and also fix the wait/notifyAll issue.

Forum Reference: Added: https://community.jboss.org/thread/205959?tstart=0

Link: Added: This issue is related to AS7-5489

The upstream fix for AS7-5489 has been merged to EAP.
http://git.app.eng.bos.redhat.com/?p=jbossas/jboss-as.git;a=commitdiff;h=69223d1333052f4ff57f9b470d5729f8e3bd7b19

According to Stuart, the upstream jira is still open because there is still some related lower priority work to be done.

Release Notes Docs Status: Added: Not Required
Forum Reference: Removed: https://community.jboss.org/thread/205959?tstart=0 Added: https://community.jboss.org/thread/205959?tstart=0

Verified on EAP 6.0.1 ER3

Release Notes Docs Status: Removed: Not Required 
Docs QE Status: Removed: NEW