I am trying to set up JBoss 4.2.2 and JConsole for remote monitoring. As per many of the how-to's I have found on the web to do this you need to enable jmxremote by setting the following options in run.conf. (I realize the other two opts disable authentication)
我正在尝试设置JBoss 4.2.2和JConsole进行远程监控。根据我在网上找到的许多操作方法,你需要通过在run.conf中设置以下选项来启用jmxremote。 (我意识到其他两个选项禁用身份验证)
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.port=11099"
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.authenticate=false"
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.ssl=false"
Which results in the following exception:
这导致以下异常:
13:06:56,418 INFO [TomcatDeployer] performDeployInternal :: deploy, ctxPath=/services, warUrl=.../tmp/deploy/tmp34585xxxxxxxxx.ear-contents/mDate-Services-exp.war/
13:06:57,706 WARN [AbstractServerConfig] getWebServicePort :: Unable to calculate 'WebServicePort', using default '8080'
13:06:57,711 WARN [AbstractServerConfig] getWebServicePort :: Unable to calculate 'WebServicePort', using default '8080'
13:06:58,070 WARN [AbstractServerConfig] getWebServicePort :: Unable to calculate 'WebServicePort', using default '8080'
13:06:58,071 WARN [AbstractServerConfig] getWebServicePort :: Unable to calculate 'WebServicePort', using default '8080'
13:06:58,138 ERROR [MainDeployer] start :: Could not start deployment: file:/opt/jboss-4.2.2.GA/server/default/tmp/deploy/tmp34585xxxxxxxxx.ear-contents/xxxxx-Services.war
java.lang.NullPointerException
at org.jboss.wsf.stack.jbws.WSDLFilePublisher.getPublishLocation(WSDLFilePublisher.java:303)
at org.jboss.wsf.stack.jbws.WSDLFilePublisher.publishWsdlFiles(WSDLFilePublisher.java:103)
at org.jboss.wsf.stack.jbws.PublishContractDeploymentAspect.create(PublishContractDeploymentAspect.java:52)
at org.jboss.wsf.framework.deployment.DeploymentAspectManagerImpl.deploy(DeploymentAspectManagerImpl.java:115)
at org.jboss.wsf.container.jboss42.ArchiveDeployerHook.deploy(ArchiveDeployerHook.java:97)
...
My application uses JWS which according to this bug:
我的应用程序使用JWS,根据此bug:
https://jira.jboss.org/jira/browse/JBWS-1943
Suggests this workaround:
建议此解决方法:
JAVA_OPTS="$JAVA_OPTS -Djavax.management.builder.initial=org.jboss.system.server.jmx.MBeanServerBuilderImpl"
JAVA_OPTS="$JAVA_OPTS -Djboss.platform.mbeanserver"
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote"
I've tried that however that then throws the following exception while trying to deploy a sar file in my ear which only contains on class which implements Schedulable for a couple of scheduled jobs my application requires:
我已经尝试过,但是当我尝试在我的耳朵中部署一个sar文件时会抛出以下异常,该文件只包含在我的应用程序需要的几个预定作业上实现Schedulable的类:
Caused by: java.lang.NullPointerException
at EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap.hash(ConcurrentReaderHashMap.java:298)
at EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap.get(ConcurrentReaderHashMap.java:410)
at org.jboss.mx.server.registry.BasicMBeanRegistry.getMBeanMap(BasicMBeanRegistry.java:959)
at org.jboss.mx.server.registry.BasicMBeanRegistry.contains(BasicMBeanRegistry.java:577)
Any suggestions on where to go from here?
关于从哪里去的任何建议?
EDIT:
I have also tried the following variation:
我也尝试了以下变化:
JAVA_OPTS="$JAVA_OPTS -DmbipropertyFile=../server/default/conf/mbi.properties -DpropertyFile=../server/default/conf/mdate.properties -Dwicket.configuration=DEVELOPMENT"
JAVA_OPTS="$JAVA_OPTS -Djavax.management.builder.initial=org.jboss.system.server.jmx.MBeanServerBuilderImpl"
JAVA_OPTS="$JAVA_OPTS -Djboss.platform.mbeanserver"
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote"
I'm using JDK 1.6.0_01-b06
我正在使用JDK 1.6.0_01-b06
5 个解决方案
#1
2
I have honestly never tried this remoting approach. But, if both your client machine and the server happen to both be linux boxes or similar *nixes with SSH, then you can ssh -XCA to the server and start JConsole on the server and have the GUI display on your client machine with X port forwarding. A JConsole running locally to the server JVM you want to monitor should not have any trouble connecting.
我老实说从未尝试过这种远程方法。但是,如果您的客户端计算机和服务器都是Linux机箱或类似的* nixes与SSH,那么您可以ssh -XCA到服务器并在服务器上启动JConsole并在客户端计算机上使用X端口显示GUI转发。在本地运行到要监视的服务器JVM的JConsole应该没有任何连接问题。
I personally think that's a nifty trick but I realize that it dosn't really solve the problem of getting JConsole to connect remotely through JWS.
我个人认为这是一个很好的技巧但我意识到它并没有真正解决让JConsole通过JWS远程连接的问题。
#2
0
First thing I would do is to delete both /tmp and /work directories under JBoss /default and redeploy the WAR. If that doesn't, I would upgrade the JDK to use a more recent version of 1.6. 1.6.0_01 is pretty old.
我要做的第一件事是删除JBoss / default下的/ tmp和/ work目录并重新部署WAR。如果没有,我会升级JDK以使用1.6的更新版本。 1.6.0_01很老了。
#3
0
I'm not sure if there's a specific reason you're trying to use WS to access the mbean server, but with JConsole you can directly access a remote JVM. To do this use "service:jmx:rmi:///jndi/rmi://<remote-machine>:<port>/jmxrmi" (where <remote-machine> is whatever machine your trying to connect to and <port> is 11099) as the remote process.
我不确定您是否尝试使用WS访问mbean服务器,但使用JConsole可以直接访问远程JVM。为此,请使用“service:jmx:rmi:/// jndi / rmi://
I have used this to connect to any 1.6 JVM that exposes an mbean server (JBoss, ActiveMQ, etc).
我用它来连接任何暴露mbean服务器(JBoss,ActiveMQ等)的1.6 JVM。
#4
0
I don't know if this is related, but JBoss has a tendency to redirect to itself. If you connect to a host, say jboss.localdomain:3873, wanting to connect to a ejb, JBoss might lookup its own hostname and redirect to the address it gets from there. If you have a public hostname, it might find that instead (say jboss.publicdomain.com), and tell the client to reconnect to jboss.publicdomain.com:1099. Depending on your DNS, this might or might not be a reachable address from your client.
我不知道这是否相关,但JBoss有重新定向的倾向。如果您连接到主机,比如jboss.localdomain:3873,想要连接到ejb,JBoss可能会查找自己的主机名并重定向到它从那里获得的地址。如果你有一个公共主机名,它可能会找到(比如jboss.publicdomain.com),并告诉客户端重新连接到jboss.publicdomain.com:1099。根据您的DNS,这可能是也可能不是您客户端的可访问地址。
There are various varations of this problem, and as a bonus, sometimes the initial "connection check" works, so the client app deploys, but fails later on connect.
这个问题存在各种各样的变化,作为奖励,有时最初的“连接检查”有效,因此客户端应用程序部署,但稍后在连接时失败。
#5
0
Had a similar issue, but with JBoss Seam: take a look at JBSEAM-4029. As one of the workarounds it suggests to override the class running into the NPE - in Seam's case the JBossClusterMonitor.
有一个类似的问题,但与JBoss Seam:看看JBSEAM-4029。作为解决方法之一,它建议覆盖运行到NPE中的类 - 在Seam的情况下是JBossClusterMonitor。
I bet the JWS code is running into exact same issue, i.e. ending up calling MBeanServerFactory.findMBeanServer(null) at some point in time. The stack trace should reveal which exact class does this.
我敢打赌,JWS代码遇到了完全相同的问题,即最终在某个时间点调用MBeanServerFactory.findMBeanServer(null)。堆栈跟踪应该显示哪个类完成此操作。
#1
2
I have honestly never tried this remoting approach. But, if both your client machine and the server happen to both be linux boxes or similar *nixes with SSH, then you can ssh -XCA to the server and start JConsole on the server and have the GUI display on your client machine with X port forwarding. A JConsole running locally to the server JVM you want to monitor should not have any trouble connecting.
我老实说从未尝试过这种远程方法。但是,如果您的客户端计算机和服务器都是Linux机箱或类似的* nixes与SSH,那么您可以ssh -XCA到服务器并在服务器上启动JConsole并在客户端计算机上使用X端口显示GUI转发。在本地运行到要监视的服务器JVM的JConsole应该没有任何连接问题。
I personally think that's a nifty trick but I realize that it dosn't really solve the problem of getting JConsole to connect remotely through JWS.
我个人认为这是一个很好的技巧但我意识到它并没有真正解决让JConsole通过JWS远程连接的问题。
#2
0
First thing I would do is to delete both /tmp and /work directories under JBoss /default and redeploy the WAR. If that doesn't, I would upgrade the JDK to use a more recent version of 1.6. 1.6.0_01 is pretty old.
我要做的第一件事是删除JBoss / default下的/ tmp和/ work目录并重新部署WAR。如果没有,我会升级JDK以使用1.6的更新版本。 1.6.0_01很老了。
#3
0
I'm not sure if there's a specific reason you're trying to use WS to access the mbean server, but with JConsole you can directly access a remote JVM. To do this use "service:jmx:rmi:///jndi/rmi://<remote-machine>:<port>/jmxrmi" (where <remote-machine> is whatever machine your trying to connect to and <port> is 11099) as the remote process.
我不确定您是否尝试使用WS访问mbean服务器,但使用JConsole可以直接访问远程JVM。为此,请使用“service:jmx:rmi:/// jndi / rmi://
I have used this to connect to any 1.6 JVM that exposes an mbean server (JBoss, ActiveMQ, etc).
我用它来连接任何暴露mbean服务器(JBoss,ActiveMQ等)的1.6 JVM。
#4
0
I don't know if this is related, but JBoss has a tendency to redirect to itself. If you connect to a host, say jboss.localdomain:3873, wanting to connect to a ejb, JBoss might lookup its own hostname and redirect to the address it gets from there. If you have a public hostname, it might find that instead (say jboss.publicdomain.com), and tell the client to reconnect to jboss.publicdomain.com:1099. Depending on your DNS, this might or might not be a reachable address from your client.
我不知道这是否相关,但JBoss有重新定向的倾向。如果您连接到主机,比如jboss.localdomain:3873,想要连接到ejb,JBoss可能会查找自己的主机名并重定向到它从那里获得的地址。如果你有一个公共主机名,它可能会找到(比如jboss.publicdomain.com),并告诉客户端重新连接到jboss.publicdomain.com:1099。根据您的DNS,这可能是也可能不是您客户端的可访问地址。
There are various varations of this problem, and as a bonus, sometimes the initial "connection check" works, so the client app deploys, but fails later on connect.
这个问题存在各种各样的变化,作为奖励,有时最初的“连接检查”有效,因此客户端应用程序部署,但稍后在连接时失败。
#5
0
Had a similar issue, but with JBoss Seam: take a look at JBSEAM-4029. As one of the workarounds it suggests to override the class running into the NPE - in Seam's case the JBossClusterMonitor.
有一个类似的问题,但与JBoss Seam:看看JBSEAM-4029。作为解决方法之一,它建议覆盖运行到NPE中的类 - 在Seam的情况下是JBossClusterMonitor。
I bet the JWS code is running into exact same issue, i.e. ending up calling MBeanServerFactory.findMBeanServer(null) at some point in time. The stack trace should reveal which exact class does this.
我敢打赌,JWS代码遇到了完全相同的问题,即最终在某个时间点调用MBeanServerFactory.findMBeanServer(null)。堆栈跟踪应该显示哪个类完成此操作。