2 instance cluster in master/slave

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

2 instance cluster in master/slave

Arun Gupta
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"


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
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 2 instance cluster in master/slave

kkhan

On 27 May 2014, at 23:39, Arun Gupta <[hidden email]> 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?
>
>
> 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.

> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 2 instance cluster in master/slave

Arun Gupta
On Tue, May 27, 2014 at 4:13 PM, Kabir Khan <[hidden email]> wrote:

>
> On 27 May 2014, at 23:39, Arun Gupta <[hidden email]> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>



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

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 2 instance cluster in master/slave

Arun Gupta
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 ?

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 ?

Arun

On Tue, May 27, 2014 at 5:02 PM, Arun Gupta <[hidden email]> wrote:

> On Tue, May 27, 2014 at 4:13 PM, Kabir Khan <[hidden email]> wrote:
>>
>> On 27 May 2014, at 23:39, Arun Gupta <[hidden email]> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
>
> --
> http://blog.arungupta.me
> http://twitter.com/arungupta



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

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 2 instance cluster in master/slave

kkhan

On 28 May 2014, at 03:49, Arun Gupta <[hidden email]> 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 <[hidden email]> wrote:
>> On Tue, May 27, 2014 at 4:13 PM, Kabir Khan <[hidden email]> wrote:
>>>
>>> On 27 May 2014, at 23:39, Arun Gupta <[hidden email]> 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
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>>
>>
>> --
>> http://blog.arungupta.me
>> http://twitter.com/arungupta
>
>
>
> --
> http://blog.arungupta.me
> http://twitter.com/arungupta


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 2 instance cluster in master/slave

Darran Lofthouse
In reply to this post by kkhan
I think it is a feature request as we know we never added support for
http-remoting in domain mode ;-)  An issue may already exist.

On 28/05/14 00:13, Kabir Khan wrote:

>
> On 27 May 2014, at 23:39, Arun Gupta <[hidden email]> 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?
>>
>>
>> 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.
>
>> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 2 instance cluster in master/slave

Richard Achmatowicz
In reply to this post by kkhan
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 <[hidden email]> 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 <[hidden email]> wrote:
>>> On Tue, May 27, 2014 at 4:13 PM, Kabir Khan <[hidden email]> wrote:
>>>> On 27 May 2014, at 23:39, Arun Gupta <[hidden email]> 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
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>>
>>> --
>>> http://blog.arungupta.me
>>> http://twitter.com/arungupta
>>
>>
>> --
>> http://blog.arungupta.me
>> http://twitter.com/arungupta

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 2 instance cluster in master/slave

Arun Gupta
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
<[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>>>
>>>> On Tue, May 27, 2014 at 4:13 PM, Kabir Khan <[hidden email]>
>>>> wrote:
>>>>>
>>>>> On 27 May 2014, at 23:39, Arun Gupta <[hidden email]> 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
>>>>>> [hidden email]
>>>>>> 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

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 2 instance cluster in master/slave

Richard Achmatowicz
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
> <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>>>> On Tue, May 27, 2014 at 4:13 PM, Kabir Khan <[hidden email]>
>>>>> wrote:
>>>>>> On 27 May 2014, at 23:39, Arun Gupta <[hidden email]> 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
>>>>>>> [hidden email]
>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>>>
>>>>> --
>>>>> http://blog.arungupta.me
>>>>> http://twitter.com/arungupta
>>>>
>>>>
>>>> --
>>>> http://blog.arungupta.me
>>>> http://twitter.com/arungupta
>>
>
>

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 2 instance cluster in master/slave

Arun Gupta
"iptables --flush" did the trick on Raspbian.

Now I have Domain Controller running on one Raspi, and Host Controller
running on another. However the slave is throwing the following
exception:

[Server:server-three] 19:56:54,746 ERROR [org.hornetq.core.server]
(Thread-1 (HornetQ-client-netty-threads-6928453)) HQ224058: Stopping
ClusterManager. As it failed to authenticate with the cluster:
HQ119099: Unable to authenticate cluster user:
HORNETQ.CLUSTER.ADMIN.USER
[Server:server-three] 19:56:54,982 INFO  [org.hornetq.core.server]
(Thread-6 (HornetQ-server-HornetQServerImpl::serverUUID=2b53cedf-e6a2-11e3-9d57-71d44db5d6ff-27664265))
HQ221029: stopped bridge
sf.my-cluster.5e79c85f-e69d-11e3-a06c-37b4b1e261b8
[Server:server-three] 19:56:55,833 ERROR [org.hornetq.core.server]
(default I/O-1) HQ224018: Failed to create session:
HornetQClusterSecurityException[errorType=CLUSTER_SECURITY_EXCEPTION
message=HQ119099: Unable to authenticate cluster user:
HORNETQ.CLUSTER.ADMIN.USER]
[Server:server-three] at
org.hornetq.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:124)
[Server:server-three] at
org.hornetq.core.server.impl.HornetQServerImpl.createSession(HornetQServerImpl.java:1014)
[Server:server-three] at
org.hornetq.core.protocol.core.impl.HornetQPacketHandler.handleCreateSession(HornetQPacketHandler.java:150)

I gather the following value in domain.xml needs to be changed:

<cluster-password>${jboss.messaging.cluster.password:CHANGE
ME!!}</cluster-password>

But to what ? I've created a password for master and slave only so
far. How is cluster password different from them ?

Arun

On Wed, May 28, 2014 at 6:29 AM, Richard Achmatowicz
<[hidden email]> 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
>> <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>>>> wrote:
>>>>>>
>>>>>> On Tue, May 27, 2014 at 4:13 PM, Kabir Khan <[hidden email]>
>>>>>> wrote:
>>>>>>>
>>>>>>> On 27 May 2014, at 23:39, Arun Gupta <[hidden email]> 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
>>>>>>>> [hidden email]
>>>>>>>> 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

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 2 instance cluster in master/slave

Arun Gupta
In reply to this post by Richard Achmatowicz
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
<[hidden email]> 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
>> <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>>>> wrote:
>>>>>>
>>>>>> On Tue, May 27, 2014 at 4:13 PM, Kabir Khan <[hidden email]>
>>>>>> wrote:
>>>>>>>
>>>>>>> On 27 May 2014, at 23:39, Arun Gupta <[hidden email]> 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
>>>>>>>> [hidden email]
>>>>>>>> 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

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 2 instance cluster in master/slave

jtgreene
Administrator

On May 28, 2014, at 3:31 PM, Arun Gupta <[hidden email]> wrote:

> 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

Just in case this is a misconception, clustering and domain management are independent things. You don’t need one to do the other. For example see standalone-full-ha.xml.

>
> 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 ?

Do you have distributable in your web.xml, and does the profile your server is using have session replication configured (e.g using the ha profile or the ha-full profile)?

> Arun
>
>
> On Wed, May 28, 2014 at 6:29 AM, Richard Achmatowicz
> <[hidden email]> 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
>>> <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>>>>> wrote:
>>>>>>>
>>>>>>> On Tue, May 27, 2014 at 4:13 PM, Kabir Khan <[hidden email]>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> On 27 May 2014, at 23:39, Arun Gupta <[hidden email]> 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
>>>>>>>>> [hidden email]
>>>>>>>>> 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
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 2 instance cluster in master/slave

Arun Gupta
>> - Configure Domain Controller (master) on one Raspi
>> - Configure Host Controller (slave) on another Raspi
>> - Deploy an application to the cluster using jboss-cli
>
> Just in case this is a misconception, clustering and domain management are independent things. You don’t need one to do the other. For example see standalone-full-ha.xml.
>
Yes, understood :)

>>
>> 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 ?
>
> Do you have distributable in your web.xml, and does the profile your server is using have session replication configured (e.g using the ha profile or the ha-full profile)?
>

Yes, to both.

web.xml is at: https://github.com/arun-gupta/wildfly-samples/blob/master/clustering/http/src/main/webapp/WEB-INF/web.xml

This WAR file shows sessions being replicated when two instances are
created on the same host in other-server-group which points to full-ha
profile. In both cases (instances on same host or instances as
master/slave), the app is deployed to other-server-group. Does
anything need to be explicitly configured for session replication when
instances are on separate hosts ?

FWIW I've been using port hopping to show session replication, without
any LB in the front. Does that matter ?

Arun


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

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 2 instance cluster in master/slave

Jason T. Greene


Sent from my iPhone

> On May 28, 2014, at 4:24 PM, Arun Gupta <[hidden email]> wrote:
>
>
> FWIW I've been using port hopping to show session replication, without
> any LB in the front. Does that matter ?

Did you ever get help on this?

I would double check that you can see replication events happening, perhaps it's still a network issue.

Also you might want to verify your session cookie is actually matching both locations. You might have two different sessions.
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 2 instance cluster in master/slave

Arun Gupta
On Thu, May 29, 2014 at 8:22 PM, Jason T. Greene <[hidden email]> wrote:

>
>
> Sent from my iPhone
>
>> On May 28, 2014, at 4:24 PM, Arun Gupta <[hidden email]> wrote:
>>
>>
>> FWIW I've been using port hopping to show session replication, without
>> any LB in the front. Does that matter ?
>
> Did you ever get help on this?

Nope.

I've been able to install Apache2 on Raspi but seems like mod_cluster
is not available for ARM. And so I've been trying to build mod_cluster
on Raspi and now debugging:

[ERROR]   The project org.jboss:User-Guide-en:1.3.1.Final-SNAPSHOT
(/home/pi/mod_cluster/mod_cluster/docs/userguide/pom.xml) has 2 errors
[ERROR]     Unresolveable build extension: Plugin
org.jboss.maven.plugins:maven-jdocbook-plugin:2.1.2 or one of its
dependencies could not be resolved: Failed to collect dependencies at
org.jboss.maven.plugins:maven-jdocbook-plugin:jar:2.1.2 ->
org.jboss:jbossorg-docbook-xslt:jar:1.1.0: Failed to read artifact
descriptor for org.jboss:jbossorg-docbook-xslt:jar:1.1.0: Could not
transfer artifact org.jboss:jbossorg-docbook-xslt:pom:1.1.0 from/to
old jboss.org (http://repository.jboss.org/maven2): Access denied to:
http://repository.jboss.org/maven2/org/jboss/jbossorg-docbook-xslt/1.1.0/jbossorg-docbook-xslt-1.1.0.pom
, ReasonPhrase:Forbidden. -> [Help 2]
[ERROR]     Unknown packaging: jdocbook @
org.jboss:User-Guide-${translation}:1.3.1.Final-SNAPSHOT,
/home/pi/mod_cluster/mod_cluster/docs/userguide/pom.xml, line 11,
column 14
[ERROR]


>
> I would double check that you can see replication events happening, perhaps it's still a network issue.

What log messages am I looking for ?

>
> Also you might want to verify your session cookie is actually matching both locations. You might have two different sessions.

The session ids are indeed different. Just pushed out the latest blog
in this series at:

http://blog.arungupta.me/2014/05/wildfly-managed-domain-raspberrypi-techtip27/

The session id are shown towards the end in screen snapshots, and are
indeed different.

Arun



--
http://blog.arungupta.me
http://twitter.com/arungupta
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 2 instance cluster in master/slave

jtgreene
Administrator

On May 29, 2014, at 10:26 PM, Arun Gupta <[hidden email]> wrote:

> On Thu, May 29, 2014 at 8:22 PM, Jason T. Greene <[hidden email]> wrote:
>>
>>
>> Sent from my iPhone
>>
>>> On May 28, 2014, at 4:24 PM, Arun Gupta <[hidden email]> wrote:
>>>
>>>
>>> FWIW I've been using port hopping to show session replication, without
>>> any LB in the front. Does that matter ?
>>
>> Did you ever get help on this?
>
> Nope.

Ah your problem is the session id cookie domain (see below)

>
> I've been able to install Apache2 on Raspi but seems like mod_cluster
> is not available for ARM. And so I've been trying to build mod_cluster
> on Raspi and now debugging:
>

-snip-

A couple other options that would be fun to play with:

1. Using Undertow’s reverse proxy like this (assuming you named the nodes pi1, pi2, and thus they have a pi1, pi2 jvmroute, which defaults to the host name if you didn’t set it):

 <reverse-proxy name="reverse-proxy" connections-per-thread=“20">
      <host name=“http://p1.example:8080" instance-id=“pi1”/>
      <host name=“http://p2.example:8080" instance-id=“pi2"/>
 </reverse-proxy>

2. You could also use undertow 1.1 standalone which has a mod_cluster impl (coming to WildFly soon)

https://github.com/undertow-io/undertow/blob/master/examples/src/main/java/io/undertow/examples/reverseproxy/ModClusterProxyServer.java

(requires alteration for your topology)


>
>
>>
>> I would double check that you can see replication events happening, perhaps it's still a network issue.
>
> What log messages am I looking for ?

You can just use wireshark (which has a jgroups decoder now i think), and look for traffic when you make changes, but this likely isn’t your problem.

>
>>
>> Also you might want to verify your session cookie is actually matching both locations. You might have two different sessions.
>
> The session ids are indeed different. Just pushed out the latest blog
> in this series at:
>
> http://blog.arungupta.me/2014/05/wildfly-managed-domain-raspberrypi-techtip27/
>
> The session id are shown towards the end in screen snapshots, and are
> indeed different.

So the problem is you need to either have a shared cookie domain, or use an LB, since the cookie domain has to match the URL for the browser to send the same cookie. You can do this in either the global config (standalone.xml under servlet-container), or you can add a setting to your web.xml like this:

<session-config>
   <cookie-domain>.example</cookie-domain>
</session-config>

Then you want to add host entries to hosts:

pi1.example 10.x.x.x
pi2.example 10.x.x.x


After you do that you should be able to stick pi1.example and pi2.example in the browser.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 2 instance cluster in master/slave

Radoslav Husar
In reply to this post by Arun Gupta
On 30/05/14 05:26, Arun Gupta wrote:

> On Thu, May 29, 2014 at 8:22 PM, Jason T. Greene <[hidden email]> wrote:
>>
>>
>> Sent from my iPhone
>>
>>> On May 28, 2014, at 4:24 PM, Arun Gupta <[hidden email]> wrote:
>>>
>>>
>>> FWIW I've been using port hopping to show session replication, without
>>> any LB in the front. Does that matter ?
>>
>> Did you ever get help on this?
>
> Nope.

Sorry, I was on PTO so I missed the continuation of your thread.

>> I would double check that you can see replication events happening, perhaps it's still a network issue.
>
> What log messages am I looking for ?

You are looking for a message that you have a new cluster view that has
2 members, such as:

17:38:48,459 INFO
[org.infinispan.remoting.transport.jgroups.JGroupsTransport]
(ServerService Thread Pool -- 55) ISPN000094: Received new cluster view:
[x220/web|1] (2) [x220/web, node2/web]

>> Also you might want to verify your session cookie is actually matching both locations. You might have two different sessions.
>
> The session ids are indeed different. Just pushed out the latest blog
> in this series at:
>
> http://blog.arungupta.me/2014/05/wildfly-managed-domain-raspberrypi-techtip27/
>
> The session id are shown towards the end in screen snapshots, and are
> indeed different.

This is a common mistake. You need to think about how HTTP cookies work
in the browser. If you create a session you are receiving a cookie, the
browser is going to send that cookie that identifies that session only
for the same *domain* (whole RFC and details here
http://tools.ietf.org/html/rfc6265#page-16 ).

Given your setup, the domains are 10.0.0.27 and 10.0.0.28, respectively.
That means the domain is different and cookies will *not* be sent and
thus a new session will be created.

If you were to use port offsetting it's a whole different story, same as
when you are switching from HTTP/80 to HTTPS/443 you keep your session
(watch out for secure cookies though).

To test, you either need to spoof the cookie (e.g. in the WF testsuite
we are using a HTTP client that overrides the domain matching logic to
be relaxed) or use a loadbalancer like mod_proxy or mod_cluster and then
the domain will be the address of the loadbalancer.

So what you are seeing is correct and expected behavior.

Cheers,
Rado
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 2 instance cluster in master/slave

Arun Gupta
In reply to this post by jtgreene
>
> A couple other options that would be fun to play with:
>
> 1. Using Undertow’s reverse proxy like this (assuming you named the nodes pi1, pi2, and thus they have a pi1, pi2 jvmroute, which defaults to the host name if you didn’t set it):
>
>  <reverse-proxy name="reverse-proxy" connections-per-thread=“20">
>       <host name=“http://p1.example:8080" instance-id=“pi1”/>
>       <host name=“http://p2.example:8080" instance-id=“pi2"/>
>  </reverse-proxy>

Where will I add this fragment ?

>
> 2. You could also use undertow 1.1 standalone which has a mod_cluster impl (coming to WildFly soon)
>
> https://github.com/undertow-io/undertow/blob/master/examples/src/main/java/io/undertow/examples/reverseproxy/ModClusterProxyServer.java
>
> (requires alteration for your topology)
OK, let me try the simpler route first.

I'm having issues building mod_cluster on ARM and following up on that
separately. Seems like I may have to use mod_proxy for now since this
is baked into Apache2 for ARM.

>> The session ids are indeed different. Just pushed out the latest blog
>> in this series at:
>>
>> http://blog.arungupta.me/2014/05/wildfly-managed-domain-raspberrypi-techtip27/
>>
>> The session id are shown towards the end in screen snapshots, and are
>> indeed different.
>
> So the problem is you need to either have a shared cookie domain, or use an LB, since the cookie domain has to match the URL for the browser to send the same cookie. You can do this in either the global config (standalone.xml under servlet-container), or you can add a setting to your web.xml like this:
>
> <session-config>
>    <cookie-domain>.example</cookie-domain>
> </session-config>

Can this element be added to domain.xml as well for the managed domain mode ?

>
> Then you want to add host entries to hosts:
>
> pi1.example 10.x.x.x
> pi2.example 10.x.x.x

These entries would be made in each individual /etc/hosts ?

Arun

>
>
> After you do that you should be able to stick pi1.example and pi2.example in the browser.
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>



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

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 2 instance cluster in master/slave

jtgreene
Administrator

On May 30, 2014, at 12:54 PM, Arun Gupta <[hidden email]> wrote:

>>
>> A couple other options that would be fun to play with:
>>
>> 1. Using Undertow’s reverse proxy like this (assuming you named the nodes pi1, pi2, and thus they have a pi1, pi2 jvmroute, which defaults to the host name if you didn’t set it):
>>
>> <reverse-proxy name="reverse-proxy" connections-per-thread=“20">
>>      <host name=“http://p1.example:8080" instance-id=“pi1”/>
>>      <host name=“http://p2.example:8080" instance-id=“pi2"/>
>> </reverse-proxy>
>
> Where will I add this fragment ?

In your domain.xml define a new profile called proxy, which is derived from the “default" profile.

In your new profile under the undertow subsystem, in the handlers section, below the welcome content file handler, add the above proxy config. You then need to change the location name=“/“ to point to the “reverse-proxy” handler (instead of “welcome-content”)

You basically want 3 server instances, one proxy, web server 1, and web server 2, all preferably on separate systems. The proxy would be assigned the proxy profile, the two other servers would get ha profiles.

You could have your DC collocated on the proxy or on a separate box. You need to be sure that your instance-id matches the jvm route on the web 1 and 2 boxes (defaults to hostname) for sticky sessions to work properly. If you look at the cookie value you will see the jvmroute as a suffix.

>
>>
>> 2. You could also use undertow 1.1 standalone which has a mod_cluster impl (coming to WildFly soon)
>>
>> https://github.com/undertow-io/undertow/blob/master/examples/src/main/java/io/undertow/examples/reverseproxy/ModClusterProxyServer.java
>>
>> (requires alteration for your topology)
> OK, let me try the simpler route first.
>
> I'm having issues building mod_cluster on ARM and following up on that
> separately. Seems like I may have to use mod_proxy for now since this
> is baked into Apache2 for ARM.
>
>>> The session ids are indeed different. Just pushed out the latest blog
>>> in this series at:
>>>
>>> http://blog.arungupta.me/2014/05/wildfly-managed-domain-raspberrypi-techtip27/
>>>
>>> The session id are shown towards the end in screen snapshots, and are
>>> indeed different.
>>
>> So the problem is you need to either have a shared cookie domain, or use an LB, since the cookie domain has to match the URL for the browser to send the same cookie. You can do this in either the global config (standalone.xml under servlet-container), or you can add a setting to your web.xml like this:
>>
>> <session-config>
>>   <cookie-domain>.example</cookie-domain>
>> </session-config>
>
> Can this element be added to domain.xml as well for the managed domain mode ?

Yes next to the “server” block inside the undertow subsystem you can add:

<servlet-container>
   <session-cookie domain=“.example”>
</servlet-container>

Although note that you ONLY have to do this if you are not using an LB.
     
>
>>
>> Then you want to add host entries to hosts:
>>
>> pi1.example 10.x.x.x
>> pi2.example 10.x.x.x
>
> These entries would be made in each individual /etc/hosts ?

You just need this on the machine with the client browser, so that when it sends HTTP requests it does “Host: pi1.example” instead of "Host: 10.xxxxx”.

If you decide to go the LB route, and want to have name references then you could do them everywhere to make it all easy.

>
> Arun
>
>>
>>
>> After you do that you should be able to stick pi1.example and pi2.example in the browser.
>>
>> --
>> Jason T. Greene
>> WildFly Lead / JBoss EAP Platform Architect
>> JBoss, a division of Red Hat
>>
>
>
>
> --
> http://blog.arungupta.me
> http://twitter.com/arungupta

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 2 instance cluster in master/slave

Arun Gupta
I almost have 3 raspis (Apache, Domain Controller, Host Controller)
now working and can see session replication happening. Had to use
mod_proxy because building mod_cluster is involving.

One (hopefully) last bit...

How/where do I set the sticky session ?

Arun

On Fri, May 30, 2014 at 11:27 AM, Jason Greene <[hidden email]> wrote:

>
> On May 30, 2014, at 12:54 PM, Arun Gupta <[hidden email]> wrote:
>
>>>
>>> A couple other options that would be fun to play with:
>>>
>>> 1. Using Undertow’s reverse proxy like this (assuming you named the nodes pi1, pi2, and thus they have a pi1, pi2 jvmroute, which defaults to the host name if you didn’t set it):
>>>
>>> <reverse-proxy name="reverse-proxy" connections-per-thread=“20">
>>>      <host name=“http://p1.example:8080" instance-id=“pi1”/>
>>>      <host name=“http://p2.example:8080" instance-id=“pi2"/>
>>> </reverse-proxy>
>>
>> Where will I add this fragment ?
>
> In your domain.xml define a new profile called proxy, which is derived from the “default" profile.
>
> In your new profile under the undertow subsystem, in the handlers section, below the welcome content file handler, add the above proxy config. You then need to change the location name=“/“ to point to the “reverse-proxy” handler (instead of “welcome-content”)
>
> You basically want 3 server instances, one proxy, web server 1, and web server 2, all preferably on separate systems. The proxy would be assigned the proxy profile, the two other servers would get ha profiles.
>
> You could have your DC collocated on the proxy or on a separate box. You need to be sure that your instance-id matches the jvm route on the web 1 and 2 boxes (defaults to hostname) for sticky sessions to work properly. If you look at the cookie value you will see the jvmroute as a suffix.
>
>>
>>>
>>> 2. You could also use undertow 1.1 standalone which has a mod_cluster impl (coming to WildFly soon)
>>>
>>> https://github.com/undertow-io/undertow/blob/master/examples/src/main/java/io/undertow/examples/reverseproxy/ModClusterProxyServer.java
>>>
>>> (requires alteration for your topology)
>> OK, let me try the simpler route first.
>>
>> I'm having issues building mod_cluster on ARM and following up on that
>> separately. Seems like I may have to use mod_proxy for now since this
>> is baked into Apache2 for ARM.
>>
>>>> The session ids are indeed different. Just pushed out the latest blog
>>>> in this series at:
>>>>
>>>> http://blog.arungupta.me/2014/05/wildfly-managed-domain-raspberrypi-techtip27/
>>>>
>>>> The session id are shown towards the end in screen snapshots, and are
>>>> indeed different.
>>>
>>> So the problem is you need to either have a shared cookie domain, or use an LB, since the cookie domain has to match the URL for the browser to send the same cookie. You can do this in either the global config (standalone.xml under servlet-container), or you can add a setting to your web.xml like this:
>>>
>>> <session-config>
>>>   <cookie-domain>.example</cookie-domain>
>>> </session-config>
>>
>> Can this element be added to domain.xml as well for the managed domain mode ?
>
> Yes next to the “server” block inside the undertow subsystem you can add:
>
> <servlet-container>
>    <session-cookie domain=“.example”>
> </servlet-container>
>
> Although note that you ONLY have to do this if you are not using an LB.
>
>>
>>>
>>> Then you want to add host entries to hosts:
>>>
>>> pi1.example 10.x.x.x
>>> pi2.example 10.x.x.x
>>
>> These entries would be made in each individual /etc/hosts ?
>
> You just need this on the machine with the client browser, so that when it sends HTTP requests it does “Host: pi1.example” instead of "Host: 10.xxxxx”.
>
> If you decide to go the LB route, and want to have name references then you could do them everywhere to make it all easy.
>
>>
>> Arun
>>
>>>
>>>
>>> After you do that you should be able to stick pi1.example and pi2.example in the browser.
>>>
>>> --
>>> Jason T. Greene
>>> WildFly Lead / JBoss EAP Platform Architect
>>> JBoss, a division of Red Hat
>>>
>>
>>
>>
>> --
>> http://blog.arungupta.me
>> http://twitter.com/arungupta
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>



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

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
12