search

lemonzone2010 / javamelody

Automatically exported from code.google.com/p/javamelody
0 stars 0 forks source link

Wildfly #360

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Use newest Wildfly (JBoss AS 8...what a dumb name change), Beta1 or 2
2. Put Javamelody in Webapp with a configured Datasource, e.g. existend 
-Djavamelody.datasources=java:jboss/datasources/ExampleDS
3. Start ;)

What is the expected output? What do you see instead?

Should run ;)
Webapp doesn't deploy with activated datasource monitoring.
Also management port stops to work, kill <pid> doesn't work...some threads hang?

What version of the product are you using? On what application server, JDK,
operating system?

Cent OS, Wildfly (JBoss AS 8) Beta2

Please provide any additional information below.

Sry...didn't investigate much deeper into this, it also hangs if I use 
autodetect datasources with java:/jdbc/... etc.

Original issue reported on code.google.com by andrePan...@gmail.com on 25 Nov 2013 at 10:21

GoogleCodeExporter commented 9 years ago 
Reproduced.

The problem is certainly that it should not try that if JBoss. And the cause is 
that the server is not identified as JBoss. In fact, the name given by the 
server says nothing about JBoss, it says "Undertow - 1.0.0.Beta17".
What is Undertow anyway?
And why not JBoss or WildFly?

Original comment by evernat@free.fr on 1 Dec 2013 at 12:40

GoogleCodeExporter commented 9 years ago 
For reference, the stack-trace on WildFly is in 
org.jboss.msc.service.StabilityMonitor.awaitStability:
"MSC service thread 1-5" prio=6 tid=0x0338a800 nid=0x13f8 in Object.wait() 
[0x037bf000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <0x295a46d8> (a java.lang.Object)
    at java.lang.Object.wait(Object.java:503)
    at org.jboss.msc.service.StabilityMonitor.awaitStability(StabilityMonitor.java:274)
    - locked <0x295a46d8> (a java.lang.Object)
    at org.jboss.msc.service.StabilityMonitor.awaitStability(StabilityMonitor.java:189)
    at org.jboss.as.naming.WritableServiceBasedNamingStore.unbind(WritableServiceBasedNamingStore.java:128)
    at org.jboss.as.naming.WritableServiceBasedNamingStore.rebind(WritableServiceBasedNamingStore.java:100)
    at org.jboss.as.naming.NamingContext.rebind(NamingContext.java:274)
    at org.jboss.as.naming.InitialContext.rebind(InitialContext.java:158)
    at org.jboss.as.naming.NamingContext.rebind(NamingContext.java:282)
    at javax.naming.InitialContext.rebind(Unknown Source)
    at net.bull.javamelody.JdbcWrapperHelper.rebindDataSource(JdbcWrapperHelper.java:109)
    at net.bull.javamelody.JdbcWrapper.rebindDataSources(JdbcWrapper.java:445)
    at net.bull.javamelody.SessionListener.contextInitialized(SessionListener.java:230)
    at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:173)
    at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:166)
    at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:86)
    at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:71)
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944)
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)

   Locked ownable synchronizers:
    - <0x2822a2e0> (a java.util.concurrent.ThreadPoolExecutor$Worker)

Original comment by evernat@free.fr on 1 Dec 2013 at 11:05

GoogleCodeExporter commented 9 years ago 
Hi,

thank you for looking into this.

JBoss AS had an embedded Tomcat as Servlet Container up to version 7.1.
In the recent version of JBoss AS (Wildfly) they replaced it with Undertow as 
new Servlet container.

There is also sometimes a Null Pointer issue with Undertow. First we should 
have resolved this datasource problem, then I will again activate melody to 
catch the Null Pointer.

In all I think Wildfly will soon be a major hub for Java Melody...if you want 
to go forward with JBoss you have to do this with Wildfly and Undertow, as 
silly as some decissions around this product might appear to some of us 
currently.

Cheers,
André

Original comment by andrePan...@gmail.com on 1 Dec 2013 at 12:44

GoogleCodeExporter commented 9 years ago 
The fix may be simple for WildFly Beta1/2: in net.bull.javamelody.JdbcWrapper, 
replace the following line
   jboss = serverInfo.contains("JBoss")
by
   jboss = serverInfo.contains("JBoss") || jboss = serverInfo.contains("Undertow")

But in my opinion, this should not be. Because, WildFly should not say that the 
server name is "Undertow", it should say something like "WildFly (ex JBossAS)". 
For example, JBossAS does not say that the server name is "Apache Tomcat".

Original comment by evernat@free.fr on 1 Dec 2013 at 3:13

GoogleCodeExporter commented 9 years ago 
Indeed the context.serverinfo is Undertow and not Wildfly...seems not OK.

For me, remember:
If I change this I get 2 potential follow up problems.
I try to find the problems, maybe it's in Wildfly and not in jmelody:

17:05:02,345 WARN  [net.bull.javamelody] (javamelody xrepository) exception 
while collecting data: java.lang.NullPointerException
    at io.undertow.servlet.spec.ServletContextImpl.getContextPath(ServletContextImpl.java:161) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
    at net.bull.javamelody.Parameters.getContextPath(Parameters.java:363) [javamelody-core-1.49.0-SNAPSHOT.jar:1.49.0-SNAPSHOT]
    at net.bull.javamelody.JavaInformations.<init>(JavaInformations.java:169) [javamelody-core-1.49.0-SNAPSHOT.jar:1.49.0-SNAPSHOT]
    at net.bull.javamelody.Collector.collectLocalContextWithoutErrors(Collector.java:293) [javamelody-core-1.49.0-SNAPSHOT.jar:1.49.0-SNAPSHOT]
    at net.bull.javamelody.FilterContext$CollectTimerTask.run(FilterContext.java:57) [javamelody-core-1.49.0-SNAPSHOT.jar:1.49.0-SNAPSHOT]
    at java.util.TimerThread.mainLoop(Timer.java:555) [rt.jar:1.7.0_45]
    at java.util.TimerThread.run(Timer.java:505) [rt.jar:1.7.0_45]

Other exception is, that Parameters.getInitParameter is not available 
sometimes. If I get him will post him...try to find  it.

Original comment by andrePan...@gmail.com on 11 Dec 2013 at 4:15

GoogleCodeExporter commented 9 years ago 
Remember me:

18:56:34,009 INFO  [org.jboss.as.jpa] (ServerService Thread Pool -- 63) 
JBAS011409: Starting Persistence Unit (phase 2 of 2) Service 
'xrepository.war#omarDS'
18:56:34,057 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 
63) MSC000001: Failed to start service 
jboss.persistenceunit."xrepository.war#omarDS": 
org.jboss.msc.service.StartException in service 
jboss.persistenceunit."xrepository.war#omarDS": java.lang.NullPointerException
    at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:172) [wildfly-jpa-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
    at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117) [wildfly-jpa-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
    at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_45]
    at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463)
    at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:182) [wildfly-jpa-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
    at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
    at org.jboss.threads.JBossThread.run(JBossThread.java:122)
Caused by: java.lang.NullPointerException
    at io.undertow.servlet.spec.ServletContextImpl.getInitParameter(ServletContextImpl.java:347) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
    at net.bull.javamelody.Parameters.getParameter(Parameters.java:426) [javamelody-core-1.49.0-SNAPSHOT.jar:1.49.0-SNAPSHOT]
    at net.bull.javamelody.JdbcWrapper.isMonitoringDisabled(JdbcWrapper.java:814) [javamelody-core-1.49.0-SNAPSHOT.jar:1.49.0-SNAPSHOT]
    at net.bull.javamelody.JdbcWrapper.createConnectionProxy(JdbcWrapper.java:786) [javamelody-core-1.49.0-SNAPSHOT.jar:1.49.0-SNAPSHOT]
    at net.bull.javamelody.JdbcWrapper.rewrapConnection(JdbcWrapper.java:712) [javamelody-core-1.49.0-SNAPSHOT.jar:1.49.0-SNAPSHOT]
    at net.bull.javamelody.JdbcWrapper.createConnectionProxyOrRewrapIfJBossOrGlassfish(JdbcWrapper.java:771) [javamelody-core-1.49.0-SNAPSHOT.jar:1.49.0-SNAPSHOT]
    at net.bull.javamelody.JdbcWrapper$ConnectionManagerInvocationHandler.invoke(JdbcWrapper.java:239) [javamelody-core-1.49.0-SNAPSHOT.jar:1.49.0-SNAPSHOT]
    at net.bull.javamelody.JdbcWrapper$DelegatingInvocationHandler.invoke(JdbcWrapper.java:282) [javamelody-core-1.49.0-SNAPSHOT.jar:1.49.0-SNAPSHOT]
    at com.sun.proxy.$Proxy170.allocateConnection(Unknown Source)
    at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:142)
    at org.hibernate.engine.jdbc.connections.internal.DatasourceConnectionProviderImpl.getConnection(DatasourceConnectionProviderImpl.java:138) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
    at org.hibernate.engine.jdbc.internal.JdbcServicesImpl$ConnectionProviderJdbcConnectionAccess.obtainConnection(JdbcServicesImpl.java:263) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
    at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:124) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
    at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:89) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
    at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:160) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
    at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:132) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
    at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1865) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
    at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1823) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
    at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854) [hibernate-entitymanager-4.3.0.Beta4.jar:4.3.0.Beta4]
    at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847) [hibernate-entitymanager-4.3.0.Beta4.jar:4.3.0.Beta4]
    at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
    at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846) [hibernate-entitymanager-4.3.0.Beta4.jar:4.3.0.Beta4]
    at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44) [jipijapa-hibernate4-3-1.0.0.Beta3.jar:]
    at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:154) [wildfly-jpa-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
    ... 8 more

Original comment by andrePan...@gmail.com on 11 Dec 2013 at 5:57

GoogleCodeExporter commented 9 years ago 
to me, both NullPointerException seem like blocker issues in WildFly beta, and 
are probably related to each other

Original comment by evernat@free.fr on 12 Dec 2013 at 12:32

GoogleCodeExporter commented 9 years ago 
So it is a WildFly issue and only a WildFly issue.
I suggest to create a blocker issue in the WildFly bugtracker. You can link 
this issue if needed: https://code.google.com/p/javamelody/issues/detail?id=360

And resolving this issue as invalid, since this is not a javamelody issue.

Original comment by evernat@free.fr on 18 Dec 2013 at 2:24

GoogleCodeExporter commented 9 years ago 
Hi,

I'm not so shure if all of this is really invalid.

Some of them are resolved in the most recent version, but one issue remains and 
is connected to the Collector Timer Task:

11:15:54,989 WARN  [net.bull.javamelody] (javamelody xrepository) exception 
while collecting data: java.lang.NullPointerException
    at io.undertow.servlet.spec.ServletContextImpl.getContextPath(ServletContextImpl.java:161) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
    at net.bull.javamelody.Parameters.getContextPath(Parameters.java:368) [javamelody-core-1.49.0-SNAPSHOT.jar:1.49.0-SNAPSHOT]
    at net.bull.javamelody.JavaInformations.<init>(JavaInformations.java:169) [javamelody-core-1.49.0-SNAPSHOT.jar:1.49.0-SNAPSHOT]
    at net.bull.javamelody.Collector.collectLocalContextWithoutErrors(Collector.java:293) [javamelody-core-1.49.0-SNAPSHOT.jar:1.49.0-SNAPSHOT]
    at net.bull.javamelody.FilterContext$CollectTimerTask.run(FilterContext.java:57) [javamelody-core-1.49.0-SNAPSHOT.jar:1.49.0-SNAPSHOT]
    at java.util.TimerThread.mainLoop(Timer.java:555) [rt.jar:1.7.0_45]
    at java.util.TimerThread.run(Timer.java:505) [rt.jar:1.7.0_45]

This timer task never stops. If i redeploy, I have multiple of them running in 
the background.

What happens now in the new JBoss is, that the ServletContextImpl has an 
internal parameter containing the DeploymentInfo and this is set to null if the 
context is destroyed. So I assume, the not stopped times where already a 
problem but where not noticed before because the did run happily in the 
background in parallel.

He remembers this timer task in the Filter Context, but this changes which each 
redeploy, new class loaders and all that.

So this timer is never stopped and never garbage collected.
Shouldn't this be added to some global destroy listener like
ServletContextListener.contextDestroyed() ?

Shure, I might not have spotted the timer stop by flying through the code.

Original comment by andrePan...@gmail.com on 3 Jan 2014 at 10:23

GoogleCodeExporter commented 9 years ago 
OK found it...MonitoringFilter.destroy() stops the timer via timer.cancel.

But Wildfly never triggers Filter.destroy().

ServletContextListener.contextDestroyed() is called reliable by Wildfly but not 
Filter.destroy().

I don't know what the specification says about this, if this has to happen at 
time of undeployment or sometimes later if garbage collected.

I will ask them and you could think about if it's more reliable to tear down 
all such stuff in SessionListener.contextDestroyed() ? ;)

BTW: Thanks for your great work.

Original comment by andrePan...@gmail.com on 3 Jan 2014 at 11:06

GoogleCodeExporter commented 9 years ago 
According to https://issues.jboss.org/browse/WFLY-2707, this issue should be 
fixed. I'm using Wildfly 8.1.0.Final and am facing the issue described above:

Caused by: java.lang.NullPointerException
    at io.undertow.servlet.spec.ServletContextImpl.getInitParameter(ServletContextImpl.java:338) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
    at net.bull.javamelody.Parameters.getParameterByName(Parameters.java:431) [javamelody-core-1.53.0.jar:1.53.0]
    at net.bull.javamelody.Parameters.getParameter(Parameters.java:420) [javamelody-core-1.53.0.jar:1.53.0]
    at net.bull.javamelody.JdbcWrapper.isMonitoringDisabled(JdbcWrapper.java:821) [javamelody-core-1.53.0.jar:1.53.0]
...

Did anyone solve this problem? Is there a workaround?

Thank you

Original comment by schragma...@gmail.com on 13 Nov 2014 at 3:13

GoogleCodeExporter commented 9 years ago 
This is a NPE in WildFly, ask them, do not ask us.

Original comment by evernat@free.fr on 28 Nov 2014 at 9:29