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

[Radoslav Husar]

On 30/05/14 05:26, Arun Gupta wrote:
> On Thu, May 29, 2014 at 8:22 PM, Jason T. Greene <jgreene at redhat.com> wrote:
>>
>>
>> Sent from my iPhone
>>
>>> On May 28, 2014, at 4:24 PM, Arun Gupta <arun.gupta at gmail.com> 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