We are migrating an application from JBoss AS 4.2 to JBoss eap 6.4. While deploying the application getting the below exception.
javax.naming.CommunicationException: Could not obtain connection to any of these urls: localhost:10099 and discovery failed with error: javax.naming.CommunicationException: Receive timed out [Root exception is java.net.SocketTimeoutException: Receive timed out] [Root exception is javax.naming.CommunicationException: Failed to connect to server localhost:10099 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server localhost:10099 [Root exception is java.net.ConnectException: Connection refused: connect]]]
at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1562)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:634)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:627)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
The connection to localhost:10099 is failed. When I have checked in the jboss-service.xml file of AS 4.2 the configuration for this port is present.
<mbean code="org.jboss.naming.NamingService"
name="jboss:service=Naming"
xmbean-dd="resource:xmdesc/NamingService-xmbean.xml">
<!-- The call by value mode. true if all lookups are unmarshalled using
the caller's TCL, false if in VM lookups return the value by reference.
-->
<attribute name="CallByValue">false</attribute>
<!-- The listening port for the bootstrap JNP service. Set this to -1
to run the NamingService without the JNP invoker listening port.
-->
<attribute name="Port">10099</attribute>
Can anyone please tell me where can we do the similar configuration in EAP 6. Tried adding in socket-binding-group in standalone.xml but did not work.
Check the boot.log to see what the value of jboss.bind.address is.
There should be a line similar to:
DEBUG [ServerInfo] jboss.bind.address: 127.0.0.1
Telnet to the server on the JNDI port to confirm there is a service listening:1.telnet HOSTNAME/IP JNDI_PORT 2. JNDI by default would be on port 1099
Check the firewall rules at the host machine and make sure ports 10099 are opened in order for twiddle to work.
Related
I am using vert.x java client for connecting solace server. While using SSL certificates for connectivity, receiving below SSL handshake error.I am using settrustall(true) in my code. Could someone help with cause for the error and resolution.
Below is the error:
SEVERE: Unhandled exception
java.lang.IllegalStateException: Bridge was not successfully started
at io.vertx.amqpbridge.impl.AmqpBridgeImpl.createConsumer(AmqpBridgeImpl.java:174)
at com.gtaa.nch.amqp.MyErrorResponse.lambda$2(MyErrorResponse.java:241)
at io.vertx.amqpbridge.impl.AmqpBridgeImpl.lambda$startImpl$5(AmqpBridgeImpl.java:157)
at io.vertx.proton.impl.ProtonClientImpl$ConnectCompletionHandler.handle(ProtonClientImpl.java:122)
at io.vertx.proton.impl.ProtonClientImpl.lambda$connectNetClient$1(ProtonClientImpl.java:97)
at io.vertx.core.net.impl.NetClientImpl.lambda$connect$2(NetClientImpl.java:113)
at io.vertx.core.net.impl.NetClientImpl.doFailed(NetClientImpl.java:268)
at io.vertx.core.net.impl.NetClientImpl.lambda$failed$12(NetClientImpl.java:264)
at io.vertx.core.impl.ContextImpl.lambda$wrapTask$2(ContextImpl.java:337)
at io.vertx.core.impl.ContextImpl.executeFromIO(ContextImpl.java:195)
at io.vertx.core.net.impl.NetClientImpl.failed(NetClientImpl.java:264)
at io.vertx.core.net.impl.NetClientImpl.lambda$null$4(NetClientImpl.java:208)
at io.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.java:507)
at io.netty.util.concurrent.DefaultPromise.notifyListeners0(DefaultPromise.java:500)
at io.netty.util.concurrent.DefaultPromise.notifyListenersNow(DefaultPromise.java:479)
at io.netty.util.concurrent.DefaultPromise.notifyListeners(DefaultPromise.java:420)
at io.netty.util.concurrent.DefaultPromise.tryFailure(DefaultPromise.java:122)
at io.netty.handler.ssl.SslHandler.notifyHandshakeFailure(SslHandler.java:1535)
at io.netty.handler.ssl.SslHandler.setHandshakeFailure(SslHandler.java:1521)
at io.netty.handler.ssl.SslHandler.setHandshakeFailure(SslHandler.java:1493)
at io.netty.handler.ssl.SslHandler.handleUnwrapThrowable(SslHandler.java:1186)
at io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1165)
at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1194)
at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:489)
at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:428)
at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:265)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1359)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:935)
at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:141)
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:645)
at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:580)
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:497)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:459)
at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:886)
at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.lang.Thread.run(Unknown Source)
This is in all likelihood an SSL configuration problem.
Check your bridge configuration targets the AMQP SSL port on the Solace broker, not the plain text port (defaults are 5671 rather than 5672)
Check the broker SSL configuration is valid (is the AMQP SSL service showing Operational UP?
Use sdkperf_jmsamqp to check that your SSL connection, certificates etc are valid.
Im trying to invoke an EJB from a remote server using JNDI lookup, Im using EJB3 with Spring-MVC in WildFly 10 and the configuration guided in this documentation has been done in my client and remote server
https://docs.jboss.org/author/display/WFLY10/EJB+invocations+from+a+remote+client+using+JNDI
But still I'm not able to get the connection of remote server.
1) Created a user under ApplicationRealm and gave the permissions for master slave setup for remote EJB Invocation.
2) This is my jboss-ejb-client.properties file, Here I have given the wildfly User_Name and Password of Host server.
endpoint.name=client-endpoint
remote.connections=one, two
remote.connection.one.host=172.16.25.26
remote.connection.one.port=8080
remote.connection.one.username=ABCD
remote.connection.one.password=ABCD#123
remote.connection.two.host=localhost
remote.connection.two.port=8080
remote.connection.two.username=guest
remote.connection.two.username=guest
# org.jboss.as.logging.per-deployment=true
My exception is
javax.naming.AuthenticationException: Failed to connect to any server. Servers tried:
[http-remoting://172.16.25.26:8080 (Authentication failed: all available authentication mechanisms failed:
JBOSS-LOCAL-USER: javax.security.sasl.SaslException: Failed to read server challenge [Caused by
java.io.FileNotFoundException: D:\wildfly-10.0.0.Final\standalone\tmp\auth\local3540175271681581878.challenge
(The system cannot find the file specified)]
DIGEST-MD5: javax.security.sasl.SaslException: DIGEST-MD5: Cannot perform callback to acquire realm,
authentication ID or password [Caused by javax.security.auth.callback.UnsupportedCallbackException])]
[Root exception is javax.security.sasl.SaslException: Authentication failed: all available authentication
mechanisms failed:
Please tell me what am I missing here thats causing this exception and what is the significance of secret-key generated while creating the user in wildfly and where to configure that key
I am trying to run a simple JPA test (persist, read, JSON serialize) with Arquillian and Wildfly (8.1.0.Final and 8.2.0.Final tested) container, but until now I was not able to deploy test.war to the embedded server. The test runs with Jboss 7.1.1.Final container.
I have used arquillian-tutorial package given on Arquillian Getting Started Guide and Arquillian Example Project (google: github arquillian tutorial)
I have used Arquillian - Wildfly configuration given here
You can find a downloadable project package on google drive. You can see Maven and Arquillian configurations in that package. I have tried with or without Management realm credentials. On profile wildfy81-embedded-credentials (which is the default in the package), the build first unpacks wildfly package and then overwrites mgmt-users.properties and mgmt-groups.properties where admin user credentials and role is defined.
The exception is
INFO [org.jboss.ws.common.management] JBWS022052: Starting JBoss Web Services - Stack CXF Server 4.2.4.Final
INFO [org.jboss.as] JBAS015961: Http management interface listening on http://127.0.0.1:9990/management
INFO [org.jboss.as] JBAS015951: Admin console listening on http://127.0.0.1:9990
INFO [org.jboss.as] JBAS015874: WildFly 8.1.0.Final "Kenny" started in 3401ms - Started 184 of 233 services (81 services are lazy, passive or on-demand)
INFO [org.xnio] XNIO version 3.2.0.Beta4
INFO [org.xnio.nio] XNIO NIO Implementation Version 3.2.0.Beta4
INFO [org.jboss.remoting] JBoss Remoting version 4.0.3.Final
ERROR [org.jboss.remoting.remote.connection] JBREM000200: Remote connection failed: java.io.IOException: JBREM000202: Abrupt close on Remoting connection 0a93e136 to /127.0.0.1:9990
ERROR [org.jboss.remoting.remote.connection] JBREM000200: Remote connection failed: java.io.IOException: An existing connection was forcibly closed by the remote host
ERROR [org.jboss.remoting.remote.connection] JBREM000200: Remote connection failed: java.io.IOException: JBREM000202: Abrupt close on Remoting connection 084cf5d6 to /127.0.0.1:9990
ERROR [org.jboss.remoting.remote.connection] JBREM000200: Remote connection failed: java.io.IOException: An existing connection was forcibly closed by the remote host
WARN [org.jboss.as.arquillian.container.ArchiveDeployer] Cannot undeploy: test.war: org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper$ServerDeploymentException: java.lang.RuntimeException: java.net.ConnectException: JBAS012174: Could not connect to http-remoting://127.0.0.1:9990. The connection failed
at org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.undeploy(ServerDeploymentHelper.java:109) [wildfly-controller-client-8.1.0.Final.jar:8.1.0.Final]
at org.jboss.as.arquillian.container.ArchiveDeployer.undeploy(ArchiveDeployer.java:55) [wildfly-arquillian-common-8.1.0.Final.jar:8.1.0.Final]
at org.jboss.as.arquillian.container.CommonDeployableContainer.undeploy(CommonDeployableContainer.java:152) [wildfly-arquillian-common-8.1.0.Final.jar:8.1.0.Final]
Caused by: java.lang.RuntimeException: java.net.ConnectException: JBAS012174: Could not connect to http-remoting://127.0.0.1:9990. The connection failed
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeAsync(AbstractModelControllerClient.java:103) [wildfly-controller-client-8.1.0.Final.jar:8.1.0.Final]
at org.jboss.as.controller.client.helpers.standalone.impl.ModelControllerClientServerDeploymentManager.executeOperation(ModelControllerClientServerDeploymentManager.java:50) [wildfly-controller-client-8.1.0.Final.jar:8.1.0.Final]
at org.jboss.as.controller.client.helpers.standalone.impl.AbstractServerDeploymentManager.execute(AbstractServerDeploymentManager.java:79) [wildfly-controller-client-8.1.0.Final.jar:8.1.0.Final]
at org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.undeploy(ServerDeploymentHelper.java:106) [wildfly-controller-client-8.1.0.Final.jar:8.1.0.Final]
... 82 more
Caused by: java.net.ConnectException: JBAS012174: Could not connect to http-remoting://127.0.0.1:9990. The connection failed
at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:117) [wildfly-protocol-8.1.0.Final.jar:8.1.0.Final]
at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:256) [wildfly-protocol-8.1.0.Final.jar:8.1.0.Final]
Could you please help me to find the issue here?
Thanks in advance.
Edit 1
From arquillian.xml
<container qualifier="wildfly-embedded-credentials">
<configuration>
<property name="jbossHome">target/wildfly-8.1.0.Final</property>
<property name="modulePath">target/wildfly-8.1.0.Final/modules</property>
<property name="managementAddress">127.0.0.1</property>
<property name="managementPort">9990</property>
<property name="username">admin</property>
<property name="password">admin</property>
<property name="outputToConsole">true</property>
</configuration>
</container>
Deployment code:
#Deployment
public static WebArchive createDeployment() {
return ShrinkWrap.create(WebArchive.class, "test.war")
.addPackage(MyBean.class.getPackage())
.addAsLibraries(new File("target/test-libs/commons-collections.jar"),
new File("target/test-libs/flexjson.jar"))
.addAsResource("test-persistence.xml", "META-INF/persistence.xml")
.addAsWebInfResource("jboss-ds.xml")
.addAsWebInfResource(EmptyAsset.INSTANCE, "beans.xml");
}
I wonder if this is because of URL
INFO Http management interface listening on http://127.0.0.1:9990/management
Edit 2
In the attached project (google drive link above), you will see there is another profile wildfy81-embedded in pom.xml with different arquillian configuration where I do not supply management address or username and password, only jbossHome and modulePath folders are defined. I get same exception (same port as well, 9990).
<container qualifier="wildfly-embedded">
<configuration>
<property name="jbossHome">target/wildfly-8.1.0.Final</property>
<property name="modulePath">target/wildfly-8.1.0.Final/modules</property>
<property name="outputToConsole">true</property>
</configuration>
</container>
On my last test, I have noticed one more exception cause (maybe because of java version or eclipse version that I am using at home). This was the exception at the bottom of other exception lines Could not connect to http-remoting://127.0.0.1:9990. The connection failed
Caused by: java.io.IOException: Invalid response
at org.xnio.http.HttpUpgradeParser.parseVersion(HttpUpgradeParser.java:150) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
at org.xnio.http.HttpUpgradeParser.parse(HttpUpgradeParser.java:53) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:299) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:279) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.0.Beta4.jar:3.2.0.Beta4]
at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4]
at org.xnio.nio.WorkerThread.run(WorkerThread.java:531) [xnio-nio-3.2.0.Beta4.jar:3.2.0.Beta4]
at ...asynchronous invocation...(Unknown Source)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272) [jboss-remoting-4.0.3.Final.jar:4.0.3.Final]
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:253) [jboss-remoting-4.0.3.Final.jar:4.0.3.Final]
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:351) [jboss-remoting-4.0.3.Final.jar:4.0.3.Final]
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:339) [jboss-remoting-4.0.3.Final.jar:4.0.3.Final]
at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:78) [wildfly-protocol-8.1.0.Final.jar:8.1.0.Final]
at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:109) [wildfly-protocol-8.1.0.Final.jar:8.1.0.Final]
... 95 more
I have encountered this exception (invalid response part) a few times because of Nvidia drivers on windows platform. NVIDIA Network Service is using the same port WildFly/JBoss AS is using. If you are using windows with nvidia, then please go to local services and stop this service, then check if the tests work :).
A few comments:
I have tried jboss/wildfly embedded a million times and never gotten it to work. It seems to merge the classpath with your maven or IDE environment with Wildfly. As a result I always have to revert to -managed deployment. Your example project works for me in this sense when I change it to managed.
I would recommend upgrading Arquillian to the latest version: 1.1.9.Final. A lot of bug fixes happen between releases
Your DeploymentFactory is referring to jar files in the /target/ directory but those don't exist under a normal maven run. (maybe your IDE is putting them there?). A better way to get the jar files you need is to use the shrinkwrap maven resolver.
<dependency>
<groupId>org.jboss.shrinkwrap.resolver</groupId>
<artifactId>shrinkwrap-resolver-depchain</artifactId>
<version>2.1.0</version>
<scope>test</scope>
<type>pom</type>
</dependency>
ConfigurableMavenResolverSystem mvnResolver = Maven.configureResolver();
PomEquippedResolveStage pers = mvnResolver.loadPomFromFile("pom.xml");
return ShrinkWrap.create(WebArchive.class, "test.war")
.addPackage(MyBean.class.getPackage())
.addAsLibraries(pers.resolve("commons-collections:commons-collections").withTransitivity().asFile())
.addAsLibraries(pers.resolve("net.sf.flexjson:flexjson").withTransitivity().asFile())
.addAsResource("test-persistence.xml", "META-INF/persistence.xml")
.addAsWebInfResource("jboss-ds.xml")
.addAsWebInfResource(EmptyAsset.INSTANCE, "beans.xml");
Changing management port in Wildfly worked for me:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-failsafe-plugin</artifactId>
<version>2.18.1</version>
<configuration>
<forkCount>1</forkCount>
<systemPropertyVariables>
<java.util.logging.manager>org.jboss.logmanager.LogManager</java.util.logging.manager>
<jboss.home>${project.basedir}/container/wildfly-8.1.0.Final</jboss.home>
<module.path>${project.basedir}/container/wildfly-8.1.0.Final/modules</module.path>
<jboss.http.port>8181</jboss.http.port>
<jboss.management.http.port>9090</jboss.management.http.port>
</systemPropertyVariables>
<redirectTestOutputToFile>false</redirectTestOutputToFile>
</configuration>
<executions>
<execution>
<goals>
<goal>integration-test</goal>
<goal>verify</goal>
</goals>
</execution>
</executions>
</plugin>
Remember to configure management port for Arquillian in arquillian.xml:
<container qualifier="wildfly-embedded" default="true">
<configuration>
<property name="managementPort">9090</property>
</configuration>
</container>
I'm having trouble making a remote JMX call to JBoss 6 on a Centos 5.6 server. I've previously been able to do this when running the same app on a Debian server.
./twiddle.sh --server=service:jmx:rmi:///jndi/rmi://SERVER:1090/jmxconnector invoke foo:service=bar baz
Caused by: java.net.NoRouteToHostException: No route to host
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:529)
at java.net.Socket.connect(Socket.java:478)
at java.net.Socket.<init>(Socket.java:375)
at java.net.Socket.<init>(Socket.java:189)
at sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:22)
at sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:128)
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:595)
The same call succeeds if I run it locally on SERVER. I've opened port 1090 with iptables, and I can connect via telnet to SERVER:1090. hostname -i returns the correct IP address.
I've also tried starting JBoss with -Djava.rmi.server.hostname=localhost. If I do this, then I get a different exception:
Caused by: java.rmi.NoSuchObjectException: no such object in table
at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:255)
at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:233)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:142)
at javax.management.remote.rmi.RMIServerImpl_Stub.newClient(Unknown Source)
at javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java:2327)
at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:279)
at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:248)
at org.jboss.console.twiddle.Twiddle.createMBeanServerConnection(Twiddle.java:322)
at org.jboss.console.twiddle.Twiddle.connect(Twiddle.java:331)
at org.jboss.console.twiddle.Twiddle.access$400(Twiddle.java:60)
at org.jboss.console.twiddle.Twiddle$1.getServer(Twiddle.java:217)
It turns out that in addition to port 1090, JMX/RMI also uses a dynamically allocated port, which gets blocked by the firewall. So, if it's appropriate, disable the firewall altogether, or else this seems to be an alternative (which I've not tried yet):
http://olegz.wordpress.com/2009/03/23/jmx-connectivity-through-the-firewall/
What I did was this:
Update the file activemq.xml and specify rmiServerPort.
<managementContext createConnector="true" connectorPort="SOME_PORT" rmiServerPort="SOME_OTHER" jmxDomainName="org.apache.activemq"/>
Allow both ports by updating your iptables entry, restart activemq and it should work.
We have a couple of jboss instances running on different machines. We needed a script to invoke a JMX console operation using twiddle utility available with JBoss.
For localhost the command is working fine but when we try to access the remote via:
twiddle.sh -s <servername>:<http port> -uadmin -p<password> serverinfo -c
but for remote servers we are facing following exception:
05:25:34,205 ERROR [Twiddle] Exec failed
org.jboss.util.NestedRuntimeException: - nested throwable: (javax.naming.CommunicationException [Root exception is java.rmi.NoSuchObjectException: no such object in table])
at org.jboss.console.twiddle.Twiddle$1.getServer(Twiddle.java:144)
at org.jboss.console.twiddle.command.MBeanServerCommand.getMBeanServer(MBeanServerCommand.java:59)
at org.jboss.console.twiddle.command.MBeanServerCommand.queryMBeans(MBeanServerCommand.java:66)
at org.jboss.console.twiddle.command.InvokeCommand.execute(InvokeCommand.java:274)
at org.jboss.console.twiddle.Twiddle.main(Twiddle.java:306)
Caused by: javax.naming.CommunicationException [Root exception is java.rmi.NoSuchObjectException: no such object in table]
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:780)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:627)
at javax.naming.InitialContext.lookup(InitialContext.java:351)
at org.jboss.console.twiddle.Twiddle.createMBeanServerConnection(Twiddle.java:251)
at org.jboss.console.twiddle.Twiddle.connect(Twiddle.java:269)
at org.jboss.console.twiddle.Twiddle.access$300(Twiddle.java:63)
at org.jboss.console.twiddle.Twiddle$1.getServer(Twiddle.java:140)
... 4 more
Caused by: java.rmi.NoSuchObjectException: no such object in table
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:126)
at org.jnp.server.NamingServer_Stub.lookup(Unknown Source)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:675)
... 10 more
Any help?
We weren't able to find a solution for this and finally managed to do so using SSH only.