Bug 1029099 - [GSS] (6.3) NPE when replicating CDI bean on EAP 6.1.0 cluster
Summary: [GSS] (6.3) NPE when replicating CDI bean on EAP 6.1.0 cluster
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: CDI/Weld
Version: 6.1.0
Hardware: All
OS: All
Target Milestone: DR0
: EAP 6.3.0
Assignee: Jozef Hartinger
QA Contact: Ron Šmeral
Russell Dickenson
Depends On:
Blocks: 1040671 1051205
TreeView+ depends on / blocked
Reported: 2013-11-11 16:34 UTC by Ingo Weiss
Modified: 2018-12-04 16:16 UTC (History)
13 users (show)

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.
Clone Of:
: 1051205 (view as bug list)
Last Closed: 2014-06-28 15:38:41 UTC
Type: Bug

Attachments (Terms of Use)
File contains reproducer, NPE and standalone-ha.xml (38.42 KB, application/zip)
2013-11-11 16:34 UTC, Ingo Weiss
no flags Details

System ID Priority Status Summary Last Updated
Red Hat One Jira Issue Tracker WFLY-2513 Major Resolved BDA ID contains absolute the path of the deployment location 2017-02-23 08:10:23 UTC

Internal Links: 1040671

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-/ 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.

Note You need to log in before you can comment on or make changes to this bug.