JSF conversation-based app in cluster does not work on failover

[glassfishrobot]

[Tracking issue]

Refer to issue 13881 for background

Because of a recent change in Mojarra, JSF does not update the session. This causes problem during a fail-over scenario (refer to issue 13881). This showed up during JavaOne when the JSF based demo ran into issues.

There is a new property that needs to be set to make the JSF update the session. This is needed in a HA environment. Rajiv would be able to provide the details on the new property.

During deployment, when availability is enabled and the new Mojarra property is not set, we should set this property in the in-memory representation of DOL/runtime library so that HA application continues to work. If user set the property explicitly, we should honor that. In other words, lets try to make JSF based application work in a HA environment transparently similar to GlassFish v2.x.

I am filing the bug in deployment since we need to do this during application loading.

Environment

Operating System: All Platform: All

Affected Versions

[3.1]

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/glassfish/issues/14028
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @sivakumart
• Original Issue Closed By:@glassfishrobot

[glassfishrobot]

@glassfishrobot Commented @honghzzhang said: Ok. Rajiv: please let me know the following information by Thursday for this to make the MS6: a. is this going to be a property (-property foo=bar) or deployment option (- foo bar) b. if it's a deploy option, does it need to be persisted in the domain.xml (property will be automatically persisted in the domain.xml) c. what's the name of the property/option and the possible values, what value we should set it if user does not set it.

[glassfishrobot]

@glassfishrobot Commented anilam said: Please let me know if there is any UI changes needed to support this in GUI.

[glassfishrobot]

@glassfishrobot Commented mode said: It's a context param that goes in the web.xml. The param is

com.sun.faces.enableAgressiveSessionDirtying and must be set to true. The descriptor should look like -

com.sun.faces.enableAgressiveSessionDirtying true

[glassfishrobot]

@glassfishrobot Commented mode said:

• • • Issue 14140 has been marked as a duplicate of this issue. ***

[glassfishrobot]

@glassfishrobot Commented @honghzzhang said: I see. As this is in form of context-param in web.xml and not a deploy option/property, there is nothin we need to do in the deployment framework, assign to Shingwai to follow up to see if there is any work in the web container.

[glassfishrobot]

@glassfishrobot Commented @shingwaichan said: If the parameter is needed for the jsf implementation, then it may be a good idea to have set this in jsf implementation or jsf integration code. Can we set this parameter to be true by default in jsf impl?

[glassfishrobot]

@glassfishrobot Commented rogerk said: target

[glassfishrobot]

@glassfishrobot Commented rogerk said: JSF implementation (Mojarra) has that web configuration parameter - the default is false. I presume I can test following: https://glassfish.dev.java.net/issues/show_bug.cgi?id=13881 with this configuration param set to "true".

[glassfishrobot]

@glassfishrobot Commented rogerk said: status - will test with changed default.

[glassfishrobot]

@glassfishrobot Commented rogerk said: status

[glassfishrobot]

@glassfishrobot Commented rogerk said: The default value is false in Mojarra JSF implementation. Changing this to true would most likely carry with it performance implications. It seems to me that this should be set by individual applications tat are run in HA clustered environment.

[glassfishrobot]

@glassfishrobot Commented mode said: At least when --availabilityenabled=true is set in the deployment of the app - the context param should be set by default. I don't know if the JSF app has access to the deployment context. ServerConfigLookup from web-glue can provide this info. If you inject SErverConfigLookup then call the method getWebContainerAvailabilityEnabledFromConfig and if that returns true then the param should be set.

[glassfishrobot]

@glassfishrobot Commented rogerk said: Well Mojarra does not have access to DeploymentContext. Who are you suggesting injects ServerConfigLookup?

[glassfishrobot]

@glassfishrobot Commented rogerk said: reassign

[glassfishrobot]

@glassfishrobot Commented @edburns said: Rajiv, Shing-wai, and Ed Burns had a meeting yesterday at which we decided there were two parts to this issue.

1. A potential bug where writes to the session initiating in JSF are not getting immediately pushed through to HttpSession.setAttribute()

2. A feature where including the --availabilityenabled=true command line option upon deploying the app automatically causes the com.sun.faces.enableAgressiveSessionDirtying context-param to be set to true, unless the web.xml has this parameter explicitly set to false.

I will investigate the potential bug first and then turn my attention to implementing the requested feature.

[glassfishrobot]

@glassfishrobot Commented @edburns said: RM> Well the application's web.xml must have the tag in RM> addition to the sun-web.xml configuraiton.

[glassfishrobot]

@glassfishrobot Commented @edburns said: triage

[glassfishrobot]

@glassfishrobot Commented @edburns said: This issue lets the JSF glue access the deployment context.

[glassfishrobot]

@glassfishrobot Commented @edburns said: To test the session replication portion of this bug, do the following.

Create a two node cluster on a single host. This will yield two server endpoints with different port numbers, something like

http://localhost:5080/app/ http://localhost:7080/app/

Visit the 5080 app in the browser, and cause the session to be created and populated.

In the same browser, change 5080 to 7080 and revisit the app, you should see the same session content as before. If not, there's a problem.

[glassfishrobot]

@glassfishrobot Commented @edburns said: For the second part of the issue, invoke this method on serverConfigLookup: calculateWebAvailabilityEnabledFromConfig(WebModule ctx)

This will return true if the app was deployed in the following setup.

1. deployed to a V 3.1 cluster

2. has in the web.xml

3. Was deployed with --availabilityenabled --target

[glassfishrobot]

@glassfishrobot Commented sheetalv said: assign

[glassfishrobot]

@glassfishrobot Commented @edburns said: In progress. Just trying to figure out if there is really a bug. Not convinced yet.

[glassfishrobot]

@glassfishrobot Commented @edburns said: I deleted a comment stating that there was a problem with request-char-encoding-no-session test. The problem was in the test. This particular test needed session stickiness. The test has been changed. Carry on.

[glassfishrobot]

@glassfishrobot Commented sheetalv said: code review request. The cactus tests do not completely execute the enableHA() method since the ServletContext instance cannot be cast to org.apache.catalina.core.ApplicationContextFacade.

[glassfishrobot]

@glassfishrobot Commented sheetalv said: final changes

[glassfishrobot]

@glassfishrobot Commented @edburns said: r=edburns. You are cleared for commit.

We need to work together to add at Test Last Design testcase, though. Sheetal, can you please file a TASK so we can close this issue?

Thank you for taking it over from me.

[glassfishrobot]

@glassfishrobot Commented sheetalv said: Thanks Ed. I have checked in the changes into the JSF workspace. Will check in the changes to GF workspace only after the JSF integration is complete.

[glassfishrobot]

@glassfishrobot Commented @edburns said: First snapshot of patch that asserts the correctness of clustering.

[glassfishrobot]

@glassfishrobot Commented @edburns said: Second iteration. Test is fully automated.

[glassfishrobot]

@glassfishrobot Commented @edburns said: Sending common/ant/glassfishV3.1/container.xml Sending jsf-ri/systest/src/com/sun/faces/htmlunit/AbstractTestCase.java Sending jsf-ri/systest-per-webapp/build-tests.xml Sending jsf-ri/systest-per-webapp/build.xml Adding jsf-ri/systest-per-webapp/cluster-no-agressive-session-dirtying Adding jsf-ri/systest-per-webapp/cluster-no-agressive-session-dirtying/src Adding jsf-ri/systest-per-webapp/cluster-no-agressive-session-dirtying/src/java Adding jsf-ri/systest-per-webapp/cluster-no-agressive-session-dirtying/src/java/com Adding jsf-ri/systest-per-webapp/cluster-no-agressive-session-dirtying/src/java/com/sun Adding jsf-ri/systest-per-webapp/cluster-no-agressive-session-dirtying/src/java/com/sun/faces Adding jsf-ri/systest-per-webapp/cluster-no-agressive-session-dirtying/src/java/com/sun/faces/systest Adding jsf-ri/systest-per-webapp/cluster-no-agressive-session-dirtying/src/java/com/sun/faces/systest/ClusterNoAgressiveSessionDirtyingTestCase.java Adding jsf-ri/systest-per-webapp/cluster-no-agressive-session-dirtying/web Adding jsf-ri/systest-per-webapp/cluster-no-agressive-session-dirtying/web/WEB-INF Adding jsf-ri/systest-per-webapp/cluster-no-agressive-session-dirtying/web/WEB-INF/web.xml Adding jsf-ri/systest-per-webapp/cluster-no-agressive-session-dirtying/web/error.jsp Adding jsf-ri/systest-per-webapp/cluster-no-agressive-session-dirtying/web/session.xhtml Adding jsf-ri/systest-per-webapp/cluster-no-agressive-session-dirtying/web/test.jsp Transmitting file data ......... Committed revision 8774.