8:20 a.m.
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@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@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@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)