[wildfly-dev] 2 instance cluster in master/slave

Arun Gupta arun.gupta at gmail.com
Wed May 28 16:31:35 EDT 2014 

Richard,

Now I can:

- Configure Domain Controller (master) on one Raspi
- Configure Host Controller (slave) on another Raspi
- Deploy an application to the cluster using jboss-cli

However the session replication does not seem to work, i.e. session
attributes added to HTTP session on master are not replicated to
slave, and vice versa. How do I get that piece working ?

Arun


On Wed, May 28, 2014 at 6:29 AM, Richard Achmatowicz
<rachmato at redhat.com> wrote:
> Hi Arun
>
> It's a Linux command and applies to a Linux OS only. You need to do it via
> root in order to use it.
> Disabling firewalls and configuring multicast communication is unfortunately
> OS dependent.
> I'm not a Mac user, but from a quick Google, it looks as through it is
> disabled/enabled from System Preferences.
> If Raspbian is based on Debian, then the iptables command may be similarly
> available from root.
>
> If none of this works, then there is the option of further debugging with
> some JGroups tools, or simply configuring JGroups to use a TCP-based stack.
>
> By the way, when you have started two nodes which you are expecting to
> connect, you should see group membership messages appearing in the console
> logs, near the end of the startup. You should see both hosts (IP addresses)
> listed in the group membership - that will confirm that JGroups
> communication is working correctly. If you only see one IP address on each
> machine, the messages are not getting through.
>
>
> Richard
>
>
> On 28/05/14 09:11 AM, Arun Gupta wrote:
>>
>> Richard,
>>
>> Is this a command or this entry needs to be commented in a file somewhere
>> ?
>>
>> Does it matter if the master is on Mac and slave is on Raspbian ?
>>
>> Arun
>>
>> On Wed, May 28, 2014 at 6:00 AM, Richard Achmatowicz
>> <rachmato at redhat.com> wrote:
>>>
>>> Arun
>>>
>>> The usual suspect in such a problem (updates to sessions not getting
>>> replicated between nodes) is JGroups not being able to send replication
>>> messages from one host to another. For example, if you are using the
>>> default
>>> udp stack of JGroups, you need to ensure that multicast communication is
>>> set
>>> up correctly on the machines you are using. On Linux boxes, the default
>>> firewall settings usually block multicast the JGroups messages from
>>> arriving
>>> successfully. If you are working on Linux, you can disable the firewall
>>> with:
>>>
>>> # iptables -F
>>>
>>> This will remove all firewall rules until the next reboot and allow the
>>> JGroups multicast messages to get through. Give that a shot. Configuring
>>> the
>>> JGroups transport is about the only additional configuration that is
>>> required for clustering to work.
>>>
>>> Richard
>>>
>>>
>>> On 28/05/14 04:39 AM, Kabir Khan wrote:
>>>>
>>>> On 28 May 2014, at 03:49, Arun Gupta <arun.gupta at gmail.com> wrote:
>>>>
>>>>> I think master/slave is now configured on two nodes, Domain Controller
>>>>> shows the following message:
>>>>>
>>>>> [Host Controller] 16:34:18,888 INFO  [org.jboss.as.domain] (Host
>>>>> Controller Service Threads - 32) JBAS010918: Registered remote slave
>>>>> host "slave", WildFly 8.1.0.CR2 "Kenny"
>>>>>
>>>>> Deployed/enabled a simple app and assigned to other-server-group and
>>>>> saw the log message:
>>>>>
>>>>> [Host Controller] 18:57:19,508 INFO  [org.jboss.as.repository] (XNIO-1
>>>>> task-9) JBAS014900: Content added at location
>>>>>
>>>>>
>>>>> /Users/arungupta/tools/wildfly-8.1.0.CR2/domain/data/content/c4/f73f651f03c68d3a7b29686519e6142bccdfa4/content
>>>>>
>>>>> The app is now accessible on master and slave on :8330.
>>>>>
>>>>> By default, if an app is deployed to other-server-group on Domain
>>>>> Controller, does it get deployed to all servers in that server-group ?
>>>>
>>>> Yes, and if you bring up more hosts with servers in that server group,
>>>> or
>>>> more servers in that group on an existing host, the app gets deployed to
>>>> those as well.
>>>>>
>>>>> If the two nodes are on the same host then session replication work.
>>>>> This is the first time I've configured nodes on two different hosts
>>>>> and can't get session replication to work. That is, session attributes
>>>>> added to the application on one node (master) are not visible on the
>>>>> other node (slave). What configuration am I missing ?
>>>>
>>>> I’m not so familiar with clustering so I am not sure. Richard?
>>>>>
>>>>> Arun
>>>>>
>>>>> On Tue, May 27, 2014 at 5:02 PM, Arun Gupta <arun.gupta at gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> On Tue, May 27, 2014 at 4:13 PM, Kabir Khan <kabir.khan at jboss.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> On 27 May 2014, at 23:39, Arun Gupta <arun.gupta at gmail.com> wrote:
>>>>>>>
>>>>>>>> Trying to following the instructions at:
>>>>>>>>
>>>>>>>> https://docs.jboss.org/author/display/WFLY8/WildFly+8+Cluster+Howto
>>>>>>>>
>>>>>>>> This shows how to setup a 2-instance cluster in master/slave where
>>>>>>>> master is on my laptop and slave is on a Raspi. Couple of questions
>>>>>>>> ...
>>>>>>>>
>>>>>>>> 1). Why the following entry is still referring to 9999 ? Shouldn't
>>>>>>>> it
>>>>>>>> be 9990 ?
>>>>>>>>
>>>>>>>> <domain-controller>
>>>>>>>>    <remote host="10.211.55.7" port="9999"/>
>>>>>>>> </domain-controller>
>>>>>>>>
>>>>>>>> FTR it only works with 9999, not with 9990.
>>>>>>>>
>>>>>>>> Domain Controller shows the message:
>>>>>>>>
>>>>>>>> [Host Controller] 15:36:22,811 INFO  [org.jboss.as.domain] (Host
>>>>>>>> Controller Service Threads - 28) JBAS010918: Registered remote slave
>>>>>>>> host "slave", WildFly 8.1.0.CR2 “Kenny”
>>>>>>>
>>>>>>> It looks like we hardcode the old “remote://“ protocol in
>>>>>>> RemoteDomainConnectionService rather than the new http-remoting
>>>>>>> protocol, so
>>>>>>> it is a bug. I am not sure if that is something we should attempt to
>>>>>>> negotiate explicitly, or to make the <remote> element take a
>>>>>>> ‘protocol’
>>>>>>> attribute?
>>>>>>>>
>>>>>>>>
>>>>>> Filed https://issues.jboss.org/browse/WFLY-3410 for tracking.
>>>>>>
>>>>>>>> 2). Master is throwing the following exception:
>>>>>>>>
>>>>>>>> 22:15:25,094 INFO  [org.jboss.as.process.Server:server-one.status]
>>>>>>>> (ProcessController-threads - 3) JBAS012017: Starting process
>>>>>>>> 'Server:server-one'
>>>>>>>> [Server:server-one] Error occurred during initialization of VM
>>>>>>>> [Server:server-one] Server VM is only supported on ARMv7+ VFP
>>>>>>>
>>>>>>> This ^^ seems to be the real error. Try removing “-server” in the
>>>>>>> jvm-options.
>>>>>>
>>>>>> I removed -server from domain.sh, didn't realize its hardcoded in
>>>>>> host.xml. It worked after commenting in host.xml. Is that a bug as
>>>>>> well ?
>>>>>>
>>>>>> Arun
>>>>>>
>>>>>>>> 22:15:25,557 INFO  [org.jboss.as.process.Server:server-one.status]
>>>>>>>> (reaper for Server:server-one) JBAS012010: Process
>>>>>>>> 'Server:server-one'
>>>>>>>> finished with an exit status of 1
>>>>>>>> [Host Controller] 22:15:26,408 INFO  [org.jboss.as.host.controller]
>>>>>>>> (ProcessControllerConnection-thread - 2) JBAS010926: Unregistering
>>>>>>>> server server-one
>>>>>>>> [Host Controller] 22:15:26,495 INFO  [org.jboss.as.host.controller]
>>>>>>>> (Controller Boot Thread) JBAS010922: Starting server server-two
>>>>>>>> 22:15:26,417 ERROR [org.jboss.as.process.Server:server-one.status]
>>>>>>>> (ProcessController-threads - 3) JBAS012006: Failed to send data
>>>>>>>> bytes
>>>>>>>> to process 'Server:server-one' input stream: java.io.IOException:
>>>>>>>> Stream closed
>>>>>>>> at
>>>>>>>>
>>>>>>>> java.lang.ProcessBuilder$NullOutputStream.write(ProcessBuilder.java:434)
>>>>>>>> [rt.jar:1.7.0_40]
>>>>>>>> at java.io.OutputStream.write(OutputStream.java:116)
>>>>>>>> [rt.jar:1.7.0_40]
>>>>>>>> at
>>>>>>>>
>>>>>>>> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
>>>>>>>> [rt.jar:1.7.0_40]
>>>>>>>> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
>>>>>>>> [rt.jar:1.7.0_40]
>>>>>>>> at java.io.FilterOutputStream.flush(FilterOutputStream.java:140)
>>>>>>>> [rt.jar:1.7.0_40]
>>>>>>>> at
>>>>>>>>
>>>>>>>> org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:125)
>>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
>>>>>>>> at
>>>>>>>>
>>>>>>>> org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:137)
>>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
>>>>>>>> at
>>>>>>>>
>>>>>>>> org.jboss.as.process.stdin.Base64OutputStream.flush(Base64OutputStream.java:44)
>>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
>>>>>>>> at
>>>>>>>>
>>>>>>>> org.jboss.as.process.stdin.BaseNCodecOutputStream.close(BaseNCodecOutputStream.java:154)
>>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
>>>>>>>> at
>>>>>>>>
>>>>>>>> org.jboss.as.process.stdin.Base64OutputStream.close(Base64OutputStream.java:44)
>>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
>>>>>>>> at
>>>>>>>>
>>>>>>>> org.jboss.as.process.ManagedProcess.sendStdin(ManagedProcess.java:164)
>>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
>>>>>>>> at
>>>>>>>>
>>>>>>>> org.jboss.as.process.ProcessController.sendStdin(ProcessController.java:207)
>>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
>>>>>>>> at
>>>>>>>>
>>>>>>>> org.jboss.as.process.ProcessControllerServerHandler$InitMessageHandler$ConnectedMessageHandler.handleMessage(ProcessControllerServerHandler.java:140)
>>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
>>>>>>>> at
>>>>>>>>
>>>>>>>> org.jboss.as.process.protocol.ConnectionImpl.safeHandleMessage(ConnectionImpl.java:269)
>>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
>>>>>>>> at
>>>>>>>>
>>>>>>>> org.jboss.as.process.protocol.ConnectionImpl$1$1.run(ConnectionImpl.java:223)
>>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
>>>>>>>> at
>>>>>>>>
>>>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>>>>>>>> [rt.jar:1.7.0_40]
>>>>>>>> at
>>>>>>>>
>>>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>>>>>>>> [rt.jar:1.7.0_40]
>>>>>>>> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
>>>>>>>> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
>>>>>>>> [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
>>>>>>>> 22:15:26,573 ERROR [org.jboss.as.protocol.connection]
>>>>>>>> (ProcessController-threads - 3) JBAS016610: Failed to read a
>>>>>>>> message:
>>>>>>>> java.io.IOException: Stream closed
>>>>>>>> at
>>>>>>>>
>>>>>>>> java.lang.ProcessBuilder$NullOutputStream.write(ProcessBuilder.java:434)
>>>>>>>> [rt.jar:1.7.0_40]
>>>>>>>> at java.io.OutputStream.write(OutputStream.java:116)
>>>>>>>> [rt.jar:1.7.0_40]
>>>>>>>> at
>>>>>>>>
>>>>>>>> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
>>>>>>>> [rt.jar:1.7.0_40]
>>>>>>>> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
>>>>>>>> [rt.jar:1.7.0_40]
>>>>>>>> at java.io.FilterOutputStream.flush(FilterOutputStream.java:140)
>>>>>>>> [rt.jar:1.7.0_40]
>>>>>>>> at
>>>>>>>>
>>>>>>>> org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:125)
>>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
>>>>>>>> at
>>>>>>>>
>>>>>>>> org.jboss.as.process.stdin.BaseNCodecOutputStream.flush(BaseNCodecOutputStream.java:137)
>>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
>>>>>>>> at
>>>>>>>>
>>>>>>>> org.jboss.as.process.stdin.Base64OutputStream.flush(Base64OutputStream.java:44)
>>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
>>>>>>>> at
>>>>>>>>
>>>>>>>> org.jboss.as.process.stdin.BaseNCodecOutputStream.close(BaseNCodecOutputStream.java:154)
>>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
>>>>>>>> at
>>>>>>>>
>>>>>>>> org.jboss.as.process.stdin.Base64OutputStream.close(Base64OutputStream.java:44)
>>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
>>>>>>>> at
>>>>>>>>
>>>>>>>> org.jboss.as.process.ManagedProcess.sendStdin(ManagedProcess.java:164)
>>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
>>>>>>>> at
>>>>>>>>
>>>>>>>> org.jboss.as.process.ProcessController.sendStdin(ProcessController.java:207)
>>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
>>>>>>>> at
>>>>>>>>
>>>>>>>> org.jboss.as.process.ProcessControllerServerHandler$InitMessageHandler$ConnectedMessageHandler.handleMessage(ProcessControllerServerHandler.java:140)
>>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
>>>>>>>> at
>>>>>>>>
>>>>>>>> org.jboss.as.process.protocol.ConnectionImpl.safeHandleMessage(ConnectionImpl.java:269)
>>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
>>>>>>>> at
>>>>>>>>
>>>>>>>> org.jboss.as.process.protocol.ConnectionImpl$1$1.run(ConnectionImpl.java:223)
>>>>>>>> [wildfly-process-controller-8.1.0.CR2.jar:8.1.0.CR2]
>>>>>>>> at
>>>>>>>>
>>>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>>>>>>>> [rt.jar:1.7.0_40]
>>>>>>>> at
>>>>>>>>
>>>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>>>>>>>> [rt.jar:1.7.0_40]
>>>>>>>> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
>>>>>>>> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
>>>>>>>> [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
>>>>>>>>
>>>>>>>> Same error for server-two as well.
>>>>>>>>
>>>>>>>> Trying to explicitly start server-three on slave gives the same
>>>>>>>> error.
>>>>>>>>
>>>>>>>> This is all using 8.1 CR2.
>>>>>>>>
>>>>>>>> Any idea what might be wrong ?
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Aru
>>>>>>>>
>>>>>>>> --
>>>>>>>> http://blog.arungupta.me
>>>>>>>> http://twitter.com/arungupta
>>>>>>>> _______________________________________________
>>>>>>>> wildfly-dev mailing list
>>>>>>>> wildfly-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> http://blog.arungupta.me
>>>>>> http://twitter.com/arungupta
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> http://blog.arungupta.me
>>>>> http://twitter.com/arungupta
>>>
>>>
>>
>>
>



-- 
http://blog.arungupta.me
http://twitter.com/arungupta

More information about the wildfly-dev mailing list