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

Arun Gupta arun.gupta at gmail.com
Wed May 28 09:11:49 EDT 2014 

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