]
Pete Muir updated WELD-59:
--------------------------
Fix Version/s: TBC
(was: 1.1.0.CR1)
Issues in JBoss EJB 3 mean that we can't test Weld in a cluster. We are aiming to get
these EJB3 issues resolved for AS 6, but that is not certain (I have pleaded ;-). So
slipping this to TBC for clarity.
Clustered WebBeans, no support for sessionscoped (and higher)
replication
-------------------------------------------------------------------------
Key: WELD-59
URL:
https://jira.jboss.org/browse/WELD-59
Project: Weld
Issue Type: Bug
Components: Scopes & Contexts
Affects Versions: 1.0.0.PREVIEW1
Environment: JBoss AS 5.1 + JDK 6
Reporter: John Ament
Fix For: TBC
Attachments: ClusteredWebBeansTestApp.zip, ClusteredWebBeansTestApp.zip
From what I can tell, this is what happens.
Assume you have a 2 node environment w/ apache httpd + mod_jk in front of the jboss
servers, used to limit servers exposed + a loadbalancer (F5 ASM) in front of those. The
apache servers are only configured to talk to one jboss server each (httpd + jboss are on
same box, they only talk to the local client). the f5 serving the initial request is
configured for pure round robin (no cookie persistence) and as a result request 1 could go
to server 1 and then request 2 goes to server 2.
Now assume that the two jboss servers are clustered together, the EJBs are clustered and
have a cache policy (based on the JBoss annotations). They only have local interfaces.
In addition, there are some classes that are only POJOs; but they sit in the ejb module.
Based on what's happening these objects should be replicated as part of the HTTP
session state.
A few problems seem to occur when the request goes to the second server after the first
request goes to the first server.
1. References to the resources required by the EJBs are not injected in the second
server. This includes members decorated @Resource or @PersistenceContext
2. References to EJBs required at the view level are not restored.
In addition, concurrent modification exceptions seem to be more likely when deployed like
this, resulting in having to downgrade EJBs to POJOs in order to remain stateful.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: