Bug 1029099

Summary: [GSS] (6.3) NPE when replicating CDI bean on EAP 6.1.0 cluster
Product: [JBoss] JBoss Enterprise Application Platform 6 Reporter: Ingo Weiss <iweiss>
Component: CDI/WeldAssignee: Jozef Hartinger <jharting>
Status: CLOSED CURRENTRELEASE QA Contact: Ron Šmeral <rsmeral>
Severity: high Docs Contact: Russell Dickenson <rdickens>
Priority: unspecified    
Version: 6.1.0CC: amelicha, batkisso, bmaxwell, iweiss, jsenshar, kkhan, maschmid, myarboro, pmuir, rhusar, smatasar, smumford, twells
Target Milestone: DR0   
Target Release: EAP 6.3.0   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
The session ID created in clustered instances of earlier JBoss EAP versions contained a full source in a deployed bean's metadata (used to create a session ID). This was causing beans deployed across different nodes in the cluster to be recreated if a session ID was reused when accessing a different node. A NullPointerException could also been seen in the later node's log. New code has been introduced that obtains a relative path, rather than an absolute path. This means that beans are no longer recreated and the NPE no longer presents.
Story Points: ---
Clone Of:
: 1051205 (view as bug list) Environment:
Last Closed: 2014-06-28 15:38:41 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1040671, 1051205    
Attachments:
Description Flags
File contains reproducer, NPE and standalone-ha.xml none

Description Ingo Weiss 2013-11-11 16:34:50 UTC
Created attachment 822497 [details]
File contains reproducer, NPE and standalone-ha.xml

Description of problem:
On a JSF page which contains: session creation date, bean1 Timestamp property and bean2 Timestamp property.

When accessing node1, a session is created and the JSF is loaded showing the timestamp for the 3 properties.

When trying to access node2 using the same session ID, via index.xhtml;jsessionid=...sessionid... node2 JSF will show the same session ID and timestamp as node1, but the bean1 and bean2 Timestamps are new, meaning both beans were recreated.

We can see on node2 logs that it threw JBAS010322 and a NPE.

This was tested using multicast and unicast.

Version-Release number of selected component (if applicable):

Weld 1.1.13.Final-redhat-1

How reproducible:

Please see attached file.

Steps to Reproduce:
1. Configure an EAP cluster
2. Build and deploy the code on the attached file
3. Access one of the nodes, http://node1-ip:8080/demo-war/index.xhtml
4. Copy the session ID
5. On the second node try http://node2-ip:8080/demo-war/index.xhtml;jsessionid=<sessionid-from-node1>

Actual results:

bean1 and bean2 timestamps are different between nodes

Expected results:

bean1 and bean2 timestamps should be the same

Comment 1 Jozef Hartinger 2013-11-13 14:54:15 UTC
The NPE is thrown after a serialized proxy is unable to attach back to the Bean<?> instance on deserialization. It seems that no Bean<?> with the matching id is found on the other node.

Bean ID creation is deterministic and both nodes should contain the same set of beans and IDs.

The only scenario in which this could possibly happen is when the an application on one node is different to the other one. This could include a small difference such as a filename.

Unfortunately Weld currently does not provide any debug information on such failure.

Comment 2 Ingo Weiss 2013-11-14 10:20:59 UTC
I got this reply from the customer:

> we had a closer look at the id:
> 18:37:48,303 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host]] (http-/127.0.0.1:8180-1) JBWEB000233: Exception sending request initialized lifecycle event to listener instance of class org.jboss.weld.servlet.WeldListener: java.lang.IllegalStateException: Error restoring serialized contextual with id org.jboss.weld.bean-demo-ear.ear.demo-war.war/home/pete/jboss-eap-6.1-orig-1/standalone/deployments/demo-ear.ear/demo-war.war/WEB-INF/classes-ManagedBean-class demo.war.DemoSessionBean
> 
> It seems likt the id contains the complete path, in our example:
> demo-war.war/home/pete/boss-eap-6.1-orig-1/standalone/deployments/
> so we deployed it on two hosts, and switched from:
> /home/pete/jboss-eap-6.1-orig-1
> /home/pete/ticket-rh/jboss-eap-6.1-orig-2
> to 
> /home/pete/jboss-eap-6.1-orig 
> on both hosts. And it worked!

It seems the contextual ID is taking the full path into consideration.

Comment 3 Jozef Hartinger 2013-11-14 11:41:42 UTC
resourceRoot.getRoot().getPathName() apparently returns an absolute path /home/pete/jboss-eap-6.1-orig-1/standalone/deployments/demo-ear.ear/demo-war.war instead of the relative one such as /content/demo-ear.ear/demo-war.war

Comment 4 Jozef Hartinger 2013-11-14 11:45:11 UTC
This happens for exploded deployments

Comment 6 Jozef Hartinger 2013-11-29 13:28:59 UTC
The upstream fix should deal with this as well.

Comment 14 Shay Matasaro 2013-12-11 21:54:02 UTC
eap 6.2.0 patch ready at https://bugzilla.redhat.com/show_bug.cgi?id=1040671

Comment 17 Scott Mumford 2014-01-17 04:13:47 UTC
Added draft release note text in the Docs Text field above.

Comment 18 Ron Šmeral 2014-02-16 20:44:26 UTC
Verified on 6.3.0.DR0.