After some research I've come closer to the cause of the problem. I'll
explain again.
Let's take cts.jar from jboss-test. The issue really depends on neither type
and number of beans in the application nor their database connectivity. In
my experiments i've used cts.jar with all the beans disabled exept 1
stateless session bean.
Tech info:
JBoss 2.4.4
JDK: Sun's jdk1.3.1_02 (also tried blackdown 1.3.1 with the same effect)
OS: RedHat Linux 7.2 kernel 2.4.7-10
(1) Trying to deploy cts.jar, then undeploy it. Everything is ok so far.
(2) After trying to deploy it again some part of jboss locks for 30-40
minutes so it can undeploy and even shutdown gracefully no more.
The number of iterations (1) until effect is reached may increase to 2 but
with cts.jar it was always 1.
I've put log messages to relevent places of jboss source code (and even
com.sun.management.jmx.MBeanServerImpl) to determine the exact place of the
lock.
The lock appered to be in the following place:
1) J2eeDeployer.startModules() calls ContainerFactory.deploy() through
MServerBean.invoke().
2) ContainerFactory.deploy() finishes normally but the corresponding
MServerBean.invoke() doesn't exit.
3) After adding logging to com.sun.management.jmx.MBeanServerImpl i found
that immediately after ContainerFactory.deploy() the
orj.jboss.management.ServerDataCollector.refresh() is called which is
public void refresh()
{
// Mark it to be refreshed
log.info("LEXUS::::: ServerDataCollector.refresh(): before
synchronized( mRefresh )");
synchronized( mRefresh )
{
mRefresh = new Boolean( true );
}
log.info("LEXUS::::: ServerDataCollector.refresh(): after
synchronized( mRefresh )");
}
log.info() are added by myself. THIS IS THE PLACE where the thread locks and
waits 30-40 minutes for mRefresh to be released.
Can now anybody explain why this may happen?
Best wishes,
Alexei Yudichev mailto:[EMAIL PROTECTED]
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
