[lexus]

Fuck.

The nirvana was so close to me... Or should I say I was close to nirvana (c).
It blocks in the same place even with jdk1.4.0... But for the first time it simply didn't block after 2 redeployments.

Shit.

[adrian.brock]

I would report it to Sun.

But they will probably want a simpler example to
reproduce it :-(

Regards,
Adrian

[lexus]

You are right, JBoss's MBeans is not a good example. I would prefer another solution for example upgrade linux kernel. JBoss tests are performed on linux 2.4.9-12, but Red Hat 7.2 comes with 2.4.7-10. You said you haven't this problem. What kernel do you use?

[adrian.brock]

My version of Mandrake (8.1) has 2.4.8 although I think
it has been patched a bit. They describe it as the
"Enterprise Kernel".

Regards,
Adrian

[lexus]

I found the cause... Once i have configured external DNS JNDI provider from Sun:


external/DNS
dns.properties
javax.naming.directory.InitialDirContext


After removing this block from jboss.jcml the problem dissapeared.

dns.properties is:

java.naming.factory.initial=com.sun.jndi.dns.DnsContextFactory
java.naming.provider.url=dns://our.dns.server.address

Why this causes lock in ServerDataCollector.refresh() on Linux only... I need this service. Did you mentioned something about jboss's problems with external resourses? Why on Linux??? Have no idea. The DNS provider itself works fine but blocks ServerDataCollector.refresh(). Strange.

[adrian.brock]

I wonder if this is the real cause of your problem?

http://main.jboss.org/thread.jsp?forum=47&thread=7715

Looks like a concurrency problem when listing jndi
bindings in the ServerDataCollector.

Regards,
Adrian

[lexus]

What does ServerDataCollector do? Does it just collect bindings information or something? In my case it locks exactly in refresh() method which is synchronized with some object that it modifies:

public void refresh()
{
// Mark it to be refreshed
synchronized( mRefresh )
{
mRefresh = new Boolean( true );
}
}

As most of methods in this class are synchronized with this mRefresh (and so does call to doRefresh() in run()) we've got a stuck. But why for 30-40 minutes? Ok I'll try to put log outputs to almost every line in doRefresh() to find out where does it stuck.

[adrian.brock]

It collects information about the server.
One of the things it collects is the jndi info
using JNDIView.listXML()

This might be why your external context is
causing problems.

There might have been a problem with concurrent modifications in previous versions (see the link above).

It could be that this has been fixed, but introduced
this problem. Sorry, I've been too busy to investigate
CVS to look for changes. I'll have a look sometime today.

I figured out why I might not see the problem.
I use 3.0 which doesn't run this service in the
default configuration.

Regards,
Adrian

[adrian.brock]

I can't see anything *obvious* in CVS.

It has been replaced with JSR77 in 3.0

Regards,
Adrian

[lexus]

Ok I found it sticks inside recursive loop of listXML() while trying to list the root of DNS context. From this point the discussion I think goes out of jboss scope :-). Sad, I liked talking to you :)
I'll try to find out why under Windows it doesn't stick.

[lexus]

I'm back.
The reason appeared to be in the way sun dns jndi provider lists root of its context. Except for dns server specified in java.naming.provider.url it tries to connect to c.root-servers.net which is unavailable on my linux machine (it has no internet access) but is available on Windows machine which has internet access. Here's the reason why jboss was stuck under Linux :-)

Ok as listing all DNS names in listXML() is not a good idea maybe I can disable listing the whole JNDI tree? After going through the code I concluded I can't but who knows... What listXML() is needed for?

[adrian.brock]

AFAIK, the management package is informational.
I don't know there is an option to disable it.

The deployer dumps a stack trace when it is not
present, but it does continue normally.

Of course you could always comment out the
printStackTrace.

I would suggest adding this as a feature request,
but this service no longer exists in 3.0, JSR77 is
used instead.
I haven't investigated what that does instead.

Regards,
Adrian