Bug 1115512

I've tested this on a simpler scenario, as I'm having some problems with mod_cluster. It would be interesting to know if my results are consistent with your results. 

- Unzip ER4 into /opt/node1 and then on /opt/node2
- Boot node1 with the following command:
./bin/standalone.sh -c standalone-ha.xml -Djboss.node.name=node1 -b 192.168.122.181

- Wait for node1 to finish booting
- Login on :8080/portal , set root password
- Boot node2 with the following command: 
/bin/sh ./bin/standalone.sh -Djboss.socket.binding.port-offset=100 -c standalone-ha.xml -Djboss.node.name=node2 -b 192.168.122.181

- Open :8180/portal , should be logged in as root
- Deploy the sample WAR to both node1 and node2
- Both the selfv1 and selfv2 should point to node1 (8080)
- On node1, import the logging application (local and remote)
- Stop/start node2
- On node2, the imported applications should be there
- On node1, create two pages: one with the local logging and one with remote logging
- On node1, click several times on the local logging
- On node2, check the count on the local logging (should match node1)
- On node1, click several times on the remote logging, it works fine
- On node2, it doesn't matches the value from node1, and the following appears on the logs:

09:55:48,286 INFO  [stdout] (http-/192.168.122.181:8180-8) No portlet session present, creating a new one.

In my setup, I also added a nginx on the same VM, configured with upstream, to simulate a load balancer (without mod_cluster). The configuration is:

- /etc/nginx/conf.d/cluster.conf

upstream cluster {
        server balancer:8080;
        server balancer:8180;
}

server {
        listen 80;
        location / {
                proxy_set_header X-Forwarded-Host $host;
                proxy_set_header X-Forwarded-Server $host;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_pass http://cluster;
                proxy_set_header Host $http_host;
        }
}

Further information: I've tested with 6.1.1, and the behavior is as follows:

- Accessing node1 directly, the counter increases on each click
- Accessing node2 directly, the counter resets and increases on each click
- Via nginx (round robin), the counter is always at 1, as each request goes to one server, which reports that the session couldn't be found and starts a new one. 

So, in either case, it's not working properly, but it's a different "not working" for each version.

So, the problem was quite simple actually: the wsrp-producer-war didn't have the <distributable/> tag on web.xml . This took a bit long to find out, due to the following facts (noting here for future reference): 

- Portal has a JSESSIONID exposed to the end user
- WSRP has its own JSESSIONID for communicating between consumer and producer
- WSRP has a map between the portal's session ID and WSRP's

The session IDs were being exchanged correctly, ie, when the consumer was able to find the session ID on the map, it sent it to producer. When not, no session was sent. The producer, in turn, does a similar thing. So, when each request goes to each node of the cluster, either the consumer or the producer is unable to find the session on its map (as the requested session is in the other node's map). Marking the producer's WAR as distributable was enough to get it working. 

As a final note, it seems that the requests to the producer is being duplicated: using simple logging example, one click generates two hits:

- Add the logging as a remote portlet to a page
- On first load, nothing is shown
- Click on the button
- It shows "1" as the SeqNumber
- Click on the page name (not refresh)
- It shows now "2". Should have been 1. On the logs, one can see the second hit. 

This behavior was already in place, and seems like this is also affecting only clustered environments. 

I'll be committing a fix for this and it'll be available on the next WSRP release.

Verified in ER05. 

https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EPP/view/EPP/view/6.2/view/UI%20Clustering%20Support/job/epp6_wsrp_cluster_failover_producer/41/

This product has been discontinued or is no longer tracked in Red Hat Bugzilla.