[jboss-jira] [JBoss JIRA] (WFLY-6747) messaging subsystem bridge fails on differents Ip orders
Lorenzo Pirazzini (JIRA)
issues at jboss.org
Mon Jun 20 09:20:00 EDT 2016
Lorenzo Pirazzini created WFLY-6747:
---------------------------------------
Summary: messaging subsystem bridge fails on differents Ip orders
Key: WFLY-6747
URL: https://issues.jboss.org/browse/WFLY-6747
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 8.2.0.Final
Environment: Wildfly 8.2.0.Final domain mode. 2 Hosts each one with one server, one contains also the domain controller. Verified on Windows and on Linux (AWS machines).
Reporter: Lorenzo Pirazzini
Assignee: Paul Ferraro
While trying to setup a clustered environment with Wildfly 8.2.0.Final I needed a shared topic between servers (I have two Linux machines on AWS).
Everything works fine (domain creation, datasources/persistence unit, infinispan shared caches and Wildfly Console) except for HornetQ messaging subsystem.
I can't use discovery because I don't have a multicast address, so I defined a *domain.xml* like this:
<subsystem xmlns="urn:jboss:domain:messaging:2.0">
<hornetq-server>
<cluster-password>myPassword</cluster-password>
<backup>false</backup>
<shared-store>false</shared-store>
<journal-file-size>102400</journal-file-size>
<connectors>
<http-connector name="http-connector" socket-binding="http">
<param key="http-upgrade-endpoint" value="http-acceptor"/>
</http-connector>
<http-connector name="http-connector-throughput" socket-binding="http">
<param key="http-upgrade-endpoint" value="http-acceptor-throughput"/>
<param key="batch-delay" value="50"/>
</http-connector>
<http-connector name="cnode1" socket-binding="node1">
<param key="http-upgrade-endpoint" value="http-acceptor"/>
</http-connector>
<http-connector name="cnode2" socket-binding="node2">
<param key="http-upgrade-endpoint" value="http-acceptor"/>
</http-connector>
<in-vm-connector name="in-vm" server-id="0"/>
</connectors>
<acceptors>
<http-acceptor http-listener="default" name="http-acceptor"/>
<http-acceptor http-listener="default" name="http-acceptor-throughput">
<param key="batch-delay" value="50"/>
<param key="direct-deliver" value="false"/>
</http-acceptor>
<in-vm-acceptor name="in-vm" server-id="0"/>
</acceptors>
<cluster-connections>
<cluster-connection name="my-cluster">
<address>jms</address>
<connector-ref>http-connector</connector-ref>
<static-connectors>
<connector-ref>
cnode1
</connector-ref>
<connector-ref>
cnode2
</connector-ref>
</static-connectors>
</cluster-connection>
</cluster-connections>
<security-settings>
<security-setting match="#">
<permission type="send" roles="guest"/>
<permission type="consume" roles="guest"/>
<permission type="createNonDurableQueue" roles="guest"/>
<permission type="deleteNonDurableQueue" roles="guest"/>
</security-setting>
</security-settings>
<address-settings>
<address-setting match="#">
<dead-letter-address>jms.queue.DLQ</dead-letter-address>
<expiry-address>jms.queue.ExpiryQueue</expiry-address>
<max-size-bytes>10485760</max-size-bytes>
<page-size-bytes>2097152</page-size-bytes>
<message-counter-history-day-limit>10</message-counter-history-day-limit>
<redistribution-delay>1000</redistribution-delay>
</address-setting>
</address-settings>
<jms-connection-factories>
<connection-factory name="InVmConnectionFactory">
<connectors>
<connector-ref connector-name="in-vm"/>
</connectors>
<entries>
<entry name="java:/ConnectionFactory"/>
</entries>
</connection-factory>
<connection-factory name="RemoteConnectionFactory">
<connectors>
<connector-ref connector-name="http-connector"/>
</connectors>
<entries>
<entry name="java:jboss/exported/jms/RemoteConnectionFactory"/>
</entries>
<ha>true</ha>
<block-on-acknowledge>true</block-on-acknowledge>
<reconnect-attempts>-1</reconnect-attempts>
</connection-factory>
<pooled-connection-factory name="hornetq-ra">
<transaction mode="xa"/>
<connectors>
<connector-ref connector-name="in-vm"/>
</connectors>
<entries>
<entry name="java:/JmsXA"/>
<entry name="java:jboss/DefaultJMSConnectionFactory"/>
</entries>
</pooled-connection-factory>
</jms-connection-factories>
<jms-destinations>
...
<jms-topic name="MyTopic">
<entry name="java:/jms/topic/MyTopic"/>
</jms-topic>
...
</jms-destinations>
</hornetq-server>
</subsystem>
...
<socket-binding-group name="full-ha-sockets" default-interface="public">
<socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
<socket-binding name="http" port="${jboss.http.port:8080}"/>
<socket-binding name="https" port="${jboss.https.port:8443}"/>
<socket-binding name="jacorb" interface="unsecure" port="3528"/>
<socket-binding name="jacorb-ssl" interface="unsecure" port="3529"/>
<socket-binding name="jgroups-mping" port="0" multicast-address="${jboss.default.multicast.address:230.0.0.4}" multicast-port="45700"/>
<socket-binding name="jgroups-tcp" port="7600"/>
<socket-binding name="jgroups-tcp-fd" port="57600"/>
<socket-binding name="jgroups-udp" port="55200" multicast-address="${jboss.default.multicast.address:230.0.0.4}" multicast-port="45688"/>
<socket-binding name="jgroups-udp-fd" port="54200"/>
<socket-binding name="messaging-group" port="0" multicast-address="${jboss.messaging.group.address:231.7.7.7}" multicast-port="${jboss.messaging.group.port:9876}"/>
<socket-binding name="txn-recovery-environment" port="4712"/>
<socket-binding name="txn-status-manager" port="4713"/>
<outbound-socket-binding name="mail-smtp">
<remote-destination host="localhost" port="25"/>
</outbound-socket-binding>
<outbound-socket-binding name="node1">
<remote-destination host="IP-A" port="8080"/>
</outbound-socket-binding>
<outbound-socket-binding name="node2">
<remote-destination host="IP-B" port="8080"/>
</outbound-socket-binding>
</socket-binding-group>
</socket-binding-groups>
where IP-A is the Ip of the host with domain controller and a server, and IP-B is the address of the host with only a server instance.
If I invert those two IPs HornetQ doesn't create the bridge! The topic isn't shared, every message is processed only by the topic owned by the current server.
Why the order of sucjh addresses determines the correct behaviour of the messaging subsystem? I haven't found anything useful on the documentation, am I missing something??
This is the line which is written only in the order proposed which starts the HornetQ shared topics:
2016-06-20 12:18:17,943 INFO [org.hornetq.core.server] (Thread-29 (HornetQ-server-HornetQServerImpl::serverUUID=ead3e226-2c7c-11e6-81c9-1fb90d688ead-2097612799)) HQ221027: Bridge ClusterConnectionBridge at 4862c348 [name=sf.my-cluster.25728e77-2c02-11e6-8d49-3995f9ecf159, queue=QueueImpl[name=sf.my-cluster.25728e77-2c02-11e6-8d49-3995f9ecf159, postOffice=PostOfficeImpl [server=HornetQServerImpl::serverUUID=ead3e226-2c7c-11e6-81c9-1fb90d688ead]]@4ceda5a4 targetConnector=ServerLocatorImpl (identity=(Cluster-connection-bridge::ClusterConnectionBridge at 4862c348 [name=sf.my-cluster.25728e77-2c02-11e6-8d49-3995f9ecf159, queue=QueueImpl[name=sf.my-cluster.25728e77-2c02-11e6-8d49-3995f9ecf159, postOffice=PostOfficeImpl [server=HornetQServerImpl::serverUUID=ead3e226-2c7c-11e6-81c9-1fb90d688ead]]@4ceda5a4 targetConnector=ServerLocatorImpl [initialConnectors=[TransportConfiguration(name=http-connector, factory=org-hornetq-core-remoting-impl-netty-NettyConnectorFactory) ?port=8080&http-upgrade-endpoint=http-acceptor&host=IP_B&http-upgrade-enabled=true], discoveryGroupConfiguration=null]]::ClusterConnectionImpl at 1383156397[nodeUUID=ead3e226-2c7c-11e6-81c9-1fb90d688ead, connector=TransportConfiguration(name=http-connector, factory=org-hornetq-core-remoting-impl-netty-NettyConnectorFactory) ?port=8080&host=IP-A&http-upgrade-endpoint=http-acceptor&http-upgrade-enabled=true, address=jms, server=HornetQServerImpl::serverUUID=ead3e226-2c7c-11e6-81c9-1fb90d688ead])) [initialConnectors=[TransportConfiguration(name=http-connector, factory=org-hornetq-core-remoting-impl-netty-NettyConnectorFactory) ?port=8080&http-upgrade-endpoint=http-acceptor&host=IP-B&http-upgrade-enabled=true], discoveryGroupConfiguration=null]] is connected
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
More information about the jboss-jira
mailing list