[JBoss JIRA] Created: (JBAS-4485) JMXConnector always binds to the loopback device, regardless of the actual bind address
by Heiko Braun (JIRA)
JMXConnector always binds to the loopback device, regardless of the actual bind address
---------------------------------------------------------------------------------------
Key: JBAS-4485
URL: http://jira.jboss.com/jira/browse/JBAS-4485
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: URL: https://svn.jboss.org/repos/jbossas/trunk
Repository Root: https://svn.jboss.org/repos/jbossas
Repository UUID: 84be2c1e-ba19-0410-b317-a758671a6fc1
Revision: 63502
java version "1.5.0_10"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_10-b03)
Java HotSpot(TM) Client VM (build 1.5.0_10-b03, mixed mode, sharing)
Linux jbws 2.6.20-1.2925.fc6 #1 SMP Sat Mar 10 19:15:16 EST 2007 i686 i686 i386 GNU/Linux
Reporter: Heiko Braun
I am having trouble with a multihome setup.
Event though I am using dedicated bind addresses the JXMConnector fails
to start on the second instance. It looks to like as if the bind address
is just disregarded and instead binds to to the loopback device
(1) Instance A (-b 192.168.0.101) started successfully
(2) Instance B (-b 192.168.0.102) logs:
17:41:37,489 ERROR [AbstractKernelController] Error installing to Start:
name=jboss.remoting:protocol=rmi,service=JMXConnectorServer state=Create
mode=Manual requiredState=Installed
java.io.IOException: Cannot bind to URL
[rmi://192.168.0.102:1090/jmxconnector]:
javax.naming.NameAlreadyBoundException: jmxconnector [Root exception is
java.rmi.AlreadyBoundException: jmxconnector]
at
javax.management.remote.rmi.RMIConnectorServer.newIOException(RMIConnectorServer.java:814)
at
javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:431)
at
org.jboss.mx.remoting.service.JMXConnectorServerService.start(JMXConnectorServerService.java:110)
(3) [hbraun@jbws jboss-5.0.0.Beta3]$ netstat -ln | grep 1090
tcp 0 0 0.0.0.0:1090 0.0.0.0:* LISTEN
The log is quiet misleading. It does actually bind to 0 0.0.0.0:1090.
As far as i can tell, it pulls the jdk 1.5 JMX implementation.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 9 months
[JBoss JIRA] Created: (JBAS-4486) Binding the JMXConnector on a multihomed machine
by Thomas Diesler (JIRA)
Binding the JMXConnector on a multihomed machine
------------------------------------------------
Key: JBAS-4486
URL: http://jira.jboss.com/jira/browse/JBAS-4486
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JMX
Reporter: Thomas Diesler
Assigned To: Dimitris Andreadis
Fix For: JBossAS-5.0.0.Beta3
I am having trouble with a multihome setup.
Event though I am using dedicated bind addresses the JXMConnector fails
to start on the second instance. It looks to like as if the bind address
is just disregarded and instead binds to 0.0.0.0:
(1) Instance A (-b 192.168.0.101) started successfully
(2) Instance B (-b 192.168.0.102) logs:
17:41:37,489 ERROR [AbstractKernelController] Error installing to Start:
name=jboss.remoting:protocol=rmi,service=JMXConnectorServer state=Create
mode=Manual requiredState=Installed
java.io.IOException: Cannot bind to URL
[rmi://192.168.0.102:1090/jmxconnector]:
javax.naming.NameAlreadyBoundException: jmxconnector [Root exception is
java.rmi.AlreadyBoundException: jmxconnector]
at
javax.management.remote.rmi.RMIConnectorServer.newIOException(RMIConnectorServer.java:814)
at
javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:431)
at
org.jboss.mx.remoting.service.JMXConnectorServerService.start(JMXConnectorServerService.java:110)
(3) [tdiesler@jbws jboss-5.0.0.Beta3]$ netstat -ln | grep 1090
tcp 0 0 0.0.0.0:1090 0.0.0.0:* LISTEN
The log is quiet misleading. It does actually bind to 0 0.0.0.0:1090.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 9 months
[JBoss JIRA] Created: (JBAS-3885) JMXConnectorServer not respecting the -b value
by Javid Jamae (JIRA)
JMXConnectorServer not respecting the -b value
----------------------------------------------
Key: JBAS-3885
URL: http://jira.jboss.com/jira/browse/JBAS-3885
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: JBossAS-5.0.0.Beta1
Reporter: Javid Jamae
Priority: Critical
I'm trying to bring up a vertical cluster (Jboss 5.0.0Beta1) using virtual IPs on a Windows XP box. I've created two copies of the all configuration called node1 and node2. I start them in different console windows as follows:
./run.sh -b 192.168.1.140 -c node1
./run.sh -b 192.168.1.141 -c node2
I can bring up the first node, but when I try to bring up the second node, I get the following exception. I've started the nodes in different orders, and it is always the second node that throws this exception.
19:12:28,656 INFO [TomcatDeployment] deploy, ctxPath=/jmx-console, warUrl=.../deploy/jmx-console.war/
19:12:28,828 INFO [StandardContext] Container org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/jmx-console] has already been started
19:12:29,109 ERROR [AbstractKernelController] Error installing to Start: name=jboss.remoting:protocol=rmi,service=JMXConnectorServer state=Create mode=Manual requiredState=Installed
java.io.IOException: Cannot bind to URL [rmi://192.168.1.140:1090/jmxconnector]: javax.naming.NameAlreadyBoundException:
jmxconnector [Root exception is java.rmi.AlreadyBoundException: jmxconnector]
at javax.management.remote.rmi.RMIConnectorServer.newIOException(RMIConnectorServer.java:814)
at javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:431)
at org.jboss.mx.remoting.service.JMXConnectorServerService.start(JMXConnectorServerService.java:110)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:184)
at $Proxy0.start(Unknown Source)
at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42)
at org.jboss.system.microcontainer.ServiceControllerContextAction.install(ServiceControllerContextAction.java:46)
at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:226)
at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:198)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:709)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:429)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:538)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:472)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:320)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:190)
at org.jboss.system.ServiceController.doChange(ServiceController.java:656)
at org.jboss.system.ServiceController.start(ServiceController.java:431)
at org.jboss.system.deployers.ServiceDeployer.start(ServiceDeployer.java:124)
at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:85)
at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:44)
at org.jboss.deployers.plugins.deployers.helpers.AbstractSimpleRealDeployer.deploy(AbstractSimpleRealDeployer.java:53)
at org.jboss.deployers.plugins.deployer.AbstractSimpleDeployer.commitDeploy(AbstractSimpleDeployer.java:52)
at org.jboss.deployers.plugins.deployer.DeployerWrapper.commitDeploy(DeployerWrapper.java:145)
at org.jboss.deployers.plugins.deployment.MainDeployerImpl.commitDeploy(MainDeployerImpl.java:440)
at org.jboss.deployers.plugins.deployment.MainDeployerImpl.commitDeploy(MainDeployerImpl.java:451)
at org.jboss.deployers.plugins.deployment.MainDeployerImpl.process(MainDeployerImpl.java:381)
at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:366)
at org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBootstrap.java:246)
at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89)
at org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:401)
at org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:340)
at org.jboss.Main.boot(Main.java:210)
at org.jboss.Main$1.run(Main.java:508)
at java.lang.Thread.run(Thread.java:595)
Caused by: javax.naming.NameAlreadyBoundException: jmxconnector [Root exception is java.rmi.AlreadyBoundException: jmxconnector]
at com.sun.jndi.rmi.registry.RegistryContext.bind(RegistryContext.java:118)
at com.sun.jndi.toolkit.url.GenericURLContext.bind(GenericURLContext.java:208)
at javax.naming.InitialContext.bind(InitialContext.java:359)
at javax.management.remote.rmi.RMIConnectorServer.bind(RMIConnectorServer.java:635)
at javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:427)
... 42 more
Caused by: java.rmi.AlreadyBoundException: jmxconnector
at sun.rmi.registry.RegistryImpl.bind(RegistryImpl.java:123)
at sun.rmi.registry.RegistryImpl_Skel.dispatch(Unknown Source)
at sun.rmi.server.UnicastServerRef.oldDispatch(UnicastServerRef.java:375)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:240)
at sun.rmi.transport.Transport$1.run(Transport.java:153)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
at java.lang.Thread.run(Thread.java:595)
at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:343)
at sun.rmi.registry.RegistryImpl_Stub.bind(Unknown Source)
at com.sun.jndi.rmi.registry.RegistryContext.bind(RegistryContext.java:116)
... 46 more
19:12:29,187 INFO [TomcatDeployment] deploy, ctxPath=/juddi, warUrl=.../deploy/juddi-service.sar/juddiws.war/
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 9 months
[JBoss JIRA] Created: (JBRULES-1311) NPE when compiling rule consequences
by Edson Tirelli (JIRA)
NPE when compiling rule consequences
------------------------------------
Key: JBRULES-1311
URL: http://jira.jboss.com/jira/browse/JBRULES-1311
Project: JBoss Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Drl Parser/Builder, Rule Assemply/SPI
Affects Versions: 4.0.3, 4.0.2, 4.0.1, 4.0.0.GA
Reporter: Edson Tirelli
Assigned To: Edson Tirelli
Fix For: 4.1.0
I have the following code: (note String[] ruleFiles contains only one string)
public class Engine {
private static RuleBase ruleBase;
public void start(String[] ruleFiles) throws Exception {
PackageBuilderConfiguration cfg = new PackageBuilderConfiguration();
JavaDialectConfiguration javaConf = (JavaDialectConfiguration) cfg.getDialectConfiguration("java");
javaConf.setCompiler(JavaDialectConfiguration.ECLIPSE);
PackageBuilder builder = new PackageBuilder(cfg);
for (String file : ruleFiles) {
builder.addPackageFromDrl(new InputStreamReader(ClassLoader.getSystemResourceAsStream(file)));
}
Package pkg = builder.getPackage();
PackageBuilderErrors errors = builder.getErrors();
if (errors.getErrors().length != 0) {
// do something
}
RuleBaseConfiguration conf = new RuleBaseConfiguration();
conf.setAssertBehaviour(RuleBaseConfiguration.AssertBehaviour.EQUALITY);
ruleBase = RuleBaseFactory.newRuleBase();
ruleBase.addPackage(pkg);
ruleBase.newStatefulSession(false);
}
}
At the builder.addPackageFromDrl(new InputStreamReader(ClassLoader.getSystemResourceAsStream(file))); line I'm getting the following exception:
java.lang.NullPointerException
at org.drools.rule.builder.dialect.java.JavaConsequenceBuilder.build(JavaConsequenceBuilder.java:54)
at org.drools.rule.builder.RuleBuilder.build(RuleBuilder.java:67)
at org.drools.compiler.PackageBuilder.addRule(PackageBuilder.java:446)
at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:304)
at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:167)
at myPackage.rivoli.service.rules.Engine.start(Engine.java:33)
at myPackage.rivoli.rules.LeaderKingAndHeirTest.setUp(LeaderKingAndHeirTest.java:26)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:40)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:90)
I am using Drools 4.0.3
I have the following jars in my class path:
antlr-runtime-3.0.jar
core-3.2.3.v_686_R32x.jar
drools-compiler-4.0.3.jar
drools-core-4.0.3.jar
mvel14-1.2.10.jar
Any ideas would be helpful. Thanks.
rule "leaders in same location"
salience 10
when
$result : RuleResult(rulesPassed not contains "leaders in same location")
$loc : LocationImpl()
$leaderName : String()
$leader1 : LeaderImpl(name == $leaderName, location == $loc)
$leader2 : LeaderImpl(name != $leaderName, this != $leader1, location == $loc)
then
$result.addPassedRule(leaders in same location);
update($result);
end
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 9 months
[JBoss JIRA] Created: (JBXB-115) remove use of System.out from XsdBinder
by Alexey Loubyansky (JIRA)
remove use of System.out from XsdBinder
---------------------------------------
Key: JBXB-115
URL: http://jira.jboss.com/jira/browse/JBXB-115
Project: JBoss XML Binding (JBossXB)
Issue Type: Task
Affects Versions: JBossXB-1.0.0.SP1
Reporter: Alexey Loubyansky
Assigned To: Alexey Loubyansky
Fix For: JBossXB-1.0.0.SP2
$ svn diff
Index: main/java/org/jboss/xb/binding/sunday/unmarshalling/XsdBinder.java
===================================================================
--- main/java/org/jboss/xb/binding/sunday/unmarshalling/XsdBinder.java (revision 2639)
+++ main/java/org/jboss/xb/binding/sunday/unmarshalling/XsdBinder.java (working copy)
@@ -852,7 +852,7 @@
ctx.simpleContentWithIdAsSimpleType &&
particle == null && hasOnlyIdAttrs)
{
- binding.setStartElementCreatesObject(false);System.out.println("no object for " + binding.getQName());
+ binding.setStartElementCreatesObject(false);
}
else
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 9 months
[JBoss JIRA] Created: (EJBTHREE-1094) Update wiki page "Accessing_EJB3s_over_HTTP_HTTPS" for Remoting 2.4.0
by Ron Sigal (JIRA)
Update wiki page "Accessing_EJB3s_over_HTTP_HTTPS" for Remoting 2.4.0
---------------------------------------------------------------------
Key: EJBTHREE-1094
URL: http://jira.jboss.com/jira/browse/EJBTHREE-1094
Project: EJB 3.0
Issue Type: Task
Components: Documentation
Reporter: Ron Sigal
1. As of Remoting 2.2.x, the Object Name of the org.jboss.remoting.transport.servlet.ServerServletInvoker is hard coded as "jboss.remoting:service=invoker,transport=servlet", which means that only a single instance of ServerServletInvoker can be created. That would be a problem if, say, EJB3 and JBossMessaging both wanted to use the servlet transport.
As of Remoting 2.4.0, the Object Name will be generated by org.jboss.remoting.ServerInvoker.getMBeanObjectName(), which adds values for "host", "port", and any other parameters on the InvokerLocator. For example, the Object Name for the ServerServletInvoker in the example is now
jboss.remoting:service=invoker,transport=servlet,host=127.0.0.1,port=8080
2. While the https example works for org.apache.coyote.http11.Http11Protocol (the non-native version), it doesn't seem to work with org.apache.coyote.http11.Http11AprProtocol. It seems that jbossweb wants keystores in openssl PEM format. I must be missing something, though, because I couldn't get it to work with APR.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 9 months
[JBoss JIRA] Created: (JBMESSAGING-1115) java.net.SocketException: Too many open files
by Ovidiu Feodorov (JIRA)
java.net.SocketException: Too many open files
---------------------------------------------
Key: JBMESSAGING-1115
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1115
Project: JBoss Messaging
Issue Type: Bug
Affects Versions: 1.4.0.GA
Reporter: Ovidiu Feodorov
Assigned To: Tim Fox
Priority: Critical
When loading large messages into a queue, the JBM server can not handle the request of open files and starts unloading. This occurred at sending approximately 5000 emails to the queue.
2007-10-03 18:10:20,677 ERROR [org.jboss.remoting.transport.socket.SocketServerInvoker] SocketServerInvoker[10.152.1.72:4457] failed to handle socket
java.net.SocketException: Too many open files
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384)
at java.net.ServerSocket.implAccept(ServerSocket.java:450)
at java.net.ServerSocket.accept(ServerSocket.java:421)
at org.jboss.remoting.transport.socket.SocketServerInvoker.run(SocketServerInvoker.java:520)
at java.lang.Thread.run(Thread.java:595)
2007-10-03 18:10:24,171 WARN [org.jboss.deployment.scanner.URLDeploymentScanner] Scan URL, caught java.io.IOException: Could not list directory '/opt/jboss-eap-4.2/server/production/deploy', reason unknown
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 9 months