Not sure. I made the problem go away (see below); once I can recreate it
I'll take a thread dump to try to find out more about the thread.
A ref to it is held by java.lang.ThreadGroup[name=jboss,maxpri=10] if
that group name tells you where it came from.
Anyway, when I broke this test out from the 'all' tests, I forgot to
include /deploy-hasingleton in the new config. With that added back, it
now doesn't fail! No idea why that should matter; the test that fails
involves a simple remote call to a non-clustered ejb; no JMS involvement
either.
I'll keep playing with it this evening once I get some stuff the product
team needs done.
Scott M Stark wrote:
We really need to fix these nondescript thread names: Thread-31
Could it be the dynamic class loading web server thread pool?
Brian Stansberry wrote:
> Thanks. I found where EjbModule creates that. Still haven't found where
> it's leaking as the TCCL though. :(
>
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com