[JBoss JIRA] Created: (AS7-1296) JBREM00200: Remote connection failed
by Gary Quinn (JIRA)
JBREM00200: Remote connection failed
------------------------------------
Key: AS7-1296
URL: https://issues.jboss.org/browse/AS7-1296
Project: Application Server 7
Issue Type: Bug
Affects Versions: 7.0.0.Final
Reporter: Gary Quinn
Downloaded JBoss and followed the "Installing and starting JBoss AS on Linux, Unix or Mac OS X". started the standalone server (jboss-as-7.0.0.Final/bin/standalone.sh)
Server starts but keep logging the following error: 13:57:52,026 ERROR [org.jboss.remoting.remote] (XNIO NIO Read 1) JBREM00200: Remote connection failed: java.io.IOException: Received an invalid message length of 1195725856
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] (AS7-4580) Hornetq 2.2.14 Discovery Binding Failing
by James Scollard (JIRA)
James Scollard created AS7-4580:
-----------------------------------
Summary: Hornetq 2.2.14 Discovery Binding Failing
Key: AS7-4580
URL: https://issues.jboss.org/browse/AS7-4580
Project: Application Server 7
Issue Type: Clarification
Components: Clustering
Affects Versions: 7.1.0.Final
Environment: RHEL 6, jdk 1.6.0_32, hornetq 2.2.14
Reporter: James Scollard
Assignee: Paul Ferraro
Priority: Minor
We have downloaded the new (published yesterday) hornetq 2.2.14 from https://repository.jboss.org/nexus/content/repositories/releases/org/horn... and added our config from 2.2.5 which ran without issues. Only submitting this since this was released yesterday. We are trying to upgrade from 2.2.5 due to the bug that affects our topic/subscriber configuration preventing clustering. Also the Maven 2.2.14 client does not seem to be available anywhere in the jboss maven repo.
JBoss's maven repository: https://repository.jboss.org/nexus/content/repositories/releases/org/horn...
Only 2.2.13 and 2.2.15 are available.
Hornetq 2.2.14 Cluster Settings:
<broadcast-groups>
<broadcast-group name="Corp-UAT">
<group-address>225.3.2.3</group-address>
<group-port>7777</group-port>
<broadcast-period>5000</broadcast-period>
<connector-ref>netty</connector-ref>
</broadcast-group>
</broadcast-groups>
<discovery-groups>
<discovery-group name="Discovery">
<group-address>225.3.2.3</group-address>
<group-port>7777</group-port>
<refresh-timeout>10000</refresh-timeout>
</discovery-group>
</discovery-groups>
<cluster-connections>
<cluster-connection name="UAT-Cluster">
<address>jms</address>
<connector-ref>netty</connector-ref>
<discovery-group-ref discovery-group-name="Discovery"/>
</cluster-connection>
</cluster-connections>
Error on Startup:
* [main] 20-Apr 13:7:23,775 WARNING [DiscoveryGroupImpl] Could not bind to 225.3.2.3 (IPv4 address); make sure your discovery group-address is of the same type as the IP stack (IPv4 or IPv6).
Ignoring discovery group-address, but this may lead to cross talking.
java.net.BindException: Cannot assign requested address
at java.net.PlainDatagramSocketImpl.bind0(Native Method)
at java.net.PlainDatagramSocketImpl.bind(PlainDatagramSocketImpl.java:91)
at java.net.DatagramSocket.bind(DatagramSocket.java:372)
at java.net.MulticastSocket.<init>(MulticastSocket.java:147)
at org.hornetq.core.cluster.impl.DiscoveryGroupImpl.start(DiscoveryGroupImpl.java:129)
at org.hornetq.core.client.impl.ServerLocatorImpl.initialise(ServerLocatorImpl.java:370)
at org.hornetq.core.client.impl.ServerLocatorImpl.start(ServerLocatorImpl.java:544)
at org.hornetq.core.server.cluster.impl.ClusterConnectionImpl.activate(ClusterConnectionImpl.java:707)
at org.hornetq.core.server.cluster.impl.ClusterConnectionImpl.start(ClusterConnectionImpl.java:385)
at org.hornetq.core.server.cluster.impl.ClusterManagerImpl.start(ClusterManagerImpl.java:205)
at org.hornetq.core.server.impl.HornetQServerImpl.initialisePart2(HornetQServerImpl.java:1493)
at org.hornetq.core.server.impl.HornetQServerImpl.access$1200(HornetQServerImpl.java:138)
at org.hornetq.core.server.impl.HornetQServerImpl$SharedStoreLiveActivation.run(HornetQServerImpl.java:1919)
at org.hornetq.core.server.impl.HornetQServerImpl.start(HornetQServerImpl.java:366)
at org.hornetq.jms.server.impl.JMSServerManagerImpl.start(JMSServerManagerImpl.java:269)
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:597)
at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
at org.jboss.kernel.plugins.dependency.LifecycleAction.installActionInternal(LifecycleAction.java:221)
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42)
at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:774)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBean(AbstractKernelDeployer.java:319)
at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBeans(AbstractKernelDeployer.java:297)
at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deploy(AbstractKernelDeployer.java:130)
at org.jboss.kernel.plugins.deployment.xml.BeanXMLDeployer.deploy(BeanXMLDeployer.java:96)
at org.hornetq.integration.bootstrap.HornetQBootstrapServer.deploy(HornetQBootstrapServer.java:236)
at org.hornetq.integration.bootstrap.HornetQBootstrapServer.deploy(HornetQBootstrapServer.java:206)
at org.hornetq.integration.bootstrap.HornetQBootstrapServer.bootstrap(HornetQBootstrapServer.java:155)
at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:83)
at org.hornetq.integration.bootstrap.HornetQBootstrapServer.run(HornetQBootstrapServer.java:116)
at org.hornetq.integration.bootstrap.HornetQBootstrapServer.main(HornetQBootstrapServer.java:73)
* [main] 20-Apr 13:7:23,820 INFO [NettyAcceptor] Started Netty Acceptor version 3.2.5.Final-a96d88c 10.60.2.38:7777 for CORE protocol
* [main] 20-Apr 13:7:23,821 INFO [HornetQServerImpl] Server is now live
* [main] 20-Apr 13:7:23,821 INFO [HornetQServerImpl] HornetQ Server version 2.2.14.Final (HQ_2_2_14_FINAL, 122) [4aab31e6-8b0b-11e1-b160-4db571fc46b1]) started
Then once the second server is started with the same settings:
* [Thread-4 (HornetQ-server-HornetQServerImpl::serverUUID=4aab31e6-8b0b-11e1-b160-4db571fc46b1-1332226643)] 20-Apr 13:14:10,689 INFO [BridgeImpl] Bridge ClusterConnectionBridge@4e842e74 [name=sf.UAT-Cluster.3ba6a1f7-8b0c-11e1-a397-b19663cedaac, queue=QueueImpl[name=sf.UAT-Cluster.3ba6a1f7-8b0c-11e1-a397-b19663cedaac, postOffice=PostOfficeImpl [server=HornetQServerImpl::serverUUID=4aab31e6-8b0b-11e1-b160-4db571fc46b1]]@4805e9f1 targetConnector=ServerLocatorImpl (identity=(Cluster-connection-bridge::ClusterConnectionBridge@4e842e74 [name=sf.UAT-Cluster.3ba6a1f7-8b0c-11e1-a397-b19663cedaac, queue=QueueImpl[name=sf.UAT-Cluster.3ba6a1f7-8b0c-11e1-a397-b19663cedaac, postOffice=PostOfficeImpl [server=HornetQServerImpl::serverUUID=4aab31e6-8b0b-11e1-b160-4db571fc46b1]]@4805e9f1 targetConnector=ServerLocatorImpl [initialConnectors=[org-hornetq-core-remoting-impl-netty-NettyConnectorFactory?port=7777&host=10-60-2-39], discoveryGroupConfiguration=null]]::ClusterConnectionImpl@1224217602[nodeUUID=4aab31e6-8b0b-11e1-b160-4db571fc46b1, connector=org-hornetq-core-remoting-impl-netty-NettyConnectorFactory?port=7777&host=10-60-2-38, address=jms, server=HornetQServerImpl::serverUUID=4aab31e6-8b0b-11e1-b160-4db571fc46b1])) [initialConnectors=[org-hornetq-core-remoting-impl-netty-NettyConnectorFactory?port=7777&host=10-60-2-39], discoveryGroupConfiguration=null]] is connected
Is there a setting that I may have excluded when adding my configuration to the newer container? I just copied over the configs that came with the archive but when I look at the configs that were included in the new version they are the same as the defaults from 2.2.5.
Apologies. We are new to adopting this product so it is very likely that we have missed something.
Thanks in advance
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] (AS7-4811) /deployment=*/:read-resource(recursive=true) returns attributes in value-type field
by Stan Silvert (JIRA)
Stan Silvert created AS7-4811:
---------------------------------
Summary: /deployment=*/:read-resource(recursive=true) returns attributes in value-type field
Key: AS7-4811
URL: https://issues.jboss.org/browse/AS7-4811
Project: Application Server 7
Issue Type: Bug
Components: ConfigAdmin
Affects Versions: 7.1.2.Final (EAP)
Reporter: Stan Silvert
Assignee: Brian Stansberry
Scroll down to the content attribute. Its type is LIST. In value-type, I expect to get a ModelType so I know what type of list it is. Instead I see a list of sub-attributes. Shouldn't the value-type always be of type ModelType?
{noformat}
/deployment=*/:read-resource-description(recursive=true)
{
"outcome" => "success",
"result" => [{
"address" => [("deployment" => "*")],
"outcome" => "success",
"result" => {
"description" => "A deployment represents anything that can be deployed (e.g. an application such as EJB-JAR, WAR, EAR, any kind of standard archive such as RAR or JBoss-specific deployment) into a server.",
"head-comment-allowed" => true,
"tail-comment-allowed" => false,
"attributes" => {
"name" => {
"type" => STRING,
"description" => "Unique identifier of the deployment. Must be unique across all deployments.",
"required" => true,
"min-length" => 1,
"nillable" => false,
"access-type" => "read-only",
"storage" => "configuration"
},
"runtime-name" => {
"type" => STRING,
"description" => "Name by which the deployment should be known within a server's runtime. This would be equivalent to the file name of a deployment file, and would form the basis for such things as default Java Enterprise Edition application and module names. This would typically be the same as 'name', but in some cases users may wish to have two deployments with the same 'runtime-name' (e.g. two versions of \"foo.war\") both available in the deployment content repository, in which case the deployments would need to have distinct 'name' values but would have the same 'runtime-name'.",
"required" => true,
"min-length" => 1,
"nillable" => false,
"access-type" => "read-only",
"storage" => "configuration"
},
"content" => {
"type" => LIST,
"description" => "List of pieces of content that comprise the deployment.",
"required" => true,
"min-length" => 1,
"value-type" => {
"input-stream-index" => {
"type" => INT,
"description" => "The index into the operation's attached input streams of the input stream that contains deployment content that should be uploaded to the domain's or standalone server's deployment content repository.",
"required" => false,
"min" => 0,
"nillable" => true
},
"hash" => {
"type" => BYTES,
"description" => "The hash of managed deployment content that has been uploaded to the domain's or standalone server's deployment content repository.",
"required" => false,
"min-length" => 20,
"max-length" => 20,
"nillable" => true
},
"bytes" => {
"type" => BYTES,
"description" => "Byte array containing the deployment content that should uploaded to the domain's or standalone server's deployment content repository..",
"required" => false,
"min-length" => 1,
"nillable" => true
},
"url" => {
"type" => STRING,
"description" => "The URL at which the deployment content is available for upload to the domain's or standalone server's deployment content repository.. Note that the URL must be accessible from the target of the operation (i.e. the Domain Controller or standalone server).",
"required" => false,
"min-length" => 1,
"nillable" => true
},
"path" => {
"type" => STRING,
"description" => "Path (relative or absolute) to unmanaged content that is part of the deployment.",
"required" => false,
"min-length" => 1,
"nillable" => false
},
"relative-to" => {
"type" => STRING,
"description" => "Name of a system path to which the value of the 'path' is relative. If not set, the 'path' is considered to be absolute.",
"required" => false,
"min-length" => 1,
"nillable" => true
},
"archive" => {
"type" => BOOLEAN,
"description" => "Flag indicating whether unmanaged content is a zip archive (true) or exploded (false).",
"required" => false
}
},
"access-type" => "read-only",
"storage" => "configuration"
},
...
{noformat}
Compare to read-resource for /extension=\*/subsystem=\*/xml-namespaces attribute. In this case, value-type is indeed a ModelType (STRING). That's what I expect so I know how to interpret the list.
{noformat}
/extension=*/:read-resource-description(recursive=true)
{
"outcome" => "success",
"result" => [{
"address" => [("extension" => "*")],
"outcome" => "success",
"result" => {
"description" => "A module that extends the standard capabilities of a domain or a standalone server.",
"attributes" => {"module" => {
"type" => STRING,
"description" => "The name of the module.",
"expressions-allowed" => false,
"nillable" => false,
"min-length" => 1L,
"max-length" => 2147483647L,
"access-type" => "read-only",
"storage" => "configuration"
}},
"operations" => undefined,
"children" => {"subsystem" => {
"description" => "A subsystem provided by the extension. What is provided here is information about the xml schema and management interface provided by the subsystem, not the configuration of the subsystem itself.",
"model-description" => {"*" => {
"description" => "A subsystem provided by the extension. What is provided here is information about the xml schema and management interface provided by the subsystem, not the configuration of the subsystem itself.",
"attributes" => {
"management-major-version" => {
"type" => INT,
"description" => "Major version of the subsystem's management interface. May be undefined if the subsystem does not currently provide a versioned management interface.",
"expressions-allowed" => false,
"nillable" => true,
"access-type" => "read-only",
"storage" => "runtime"
},
"xml-namespaces" => {
"type" => LIST,
"description" => "A list of URIs for the XML namespaces supported by the subsystem's XML parser. May be empty if the extension did not clearly associate an XML namespace with a particular subsystem.",
"expressions-allowed" => false,
"nillable" => false,
"value-type" => STRING,
"access-type" => "read-only",
"storage" => "runtime"
},
"management-minor-version" => {
"type" => INT,
"description" => "Minor version of the subsystem's management interface. May be undefined if the subsystem does not currently provide a versioned management interface.",
"expressions-allowed" => false,
"nillable" => true,
"access-type" => "read-only",
"storage" => "runtime"
}
},
"operations" => undefined,
"children" => {}
}}
}}
}
}]
}
{noformat}
Because of this, if I try to walk through a read-resource-description on /deployment=*, I will get an IllegalArgumentException because the value-type is not actually a ModelType.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months