[JBoss JIRA] Updated: (WELD-59) Clustered WebBeans, no support for sessionscoped (and higher) replication
by Pete Muir (JIRA)
[ https://jira.jboss.org/jira/browse/WELD-59?page=com.atlassian.jira.plugin... ]
Pete Muir updated WELD-59:
--------------------------
Workaround Description: Don't use EJBs :-)
Fix Version/s: 1.0.2.CR1
(was: 1.0.1.CR2)
Workaround: [Workaround Exists]
> Clustered WebBeans, no support for sessionscoped (and higher) replication
> -------------------------------------------------------------------------
>
> Key: WELD-59
> URL: https://jira.jboss.org/jira/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: 1.0.2.CR1
>
> 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.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 10 months
[JBoss JIRA] Updated: (WELDINT-3) Support reporting wrapping exception to TCK
by Pete Muir (JIRA)
[ https://jira.jboss.org/jira/browse/WELDINT-3?page=com.atlassian.jira.plug... ]
Pete Muir updated WELDINT-3:
----------------------------
Fix Version/s: 6.0.0.Beta7
(was: 6.0.0.Beta6)
> Support reporting wrapping exception to TCK
> -------------------------------------------
>
> Key: WELDINT-3
> URL: https://jira.jboss.org/jira/browse/WELDINT-3
> Project: Weld Integration
> Issue Type: Bug
> Reporter: Pete Muir
> Fix For: 6.0.0.Beta7
>
>
> org.jboss.jsr299.tck.tests.deployment.lifecycle.broken.addDefinitionError.AddDefinitionErrorTest.testObserverDefinitionErrorTreatedAsDefinitionError()
> org.jboss.jsr299.tck.tests.deployment.lifecycle.broken.addDeploymentProblem.AddDeploymentProblemTest.testObserverDeploymentProblemTreatedAsDeploymentError()
> org.jboss.jsr299.tck.tests.deployment.lifecycle.broken.beanDiscoveryMethodThrowsException.BeforeBeanDiscoveryThrowsExceptionTest.testThrowsException()
> org.jboss.jsr299.tck.tests.deployment.lifecycle.broken.exceptionInAfterBeanDiscoveryObserver.AfterBeanDiscoveryObserverExecutionFailureTest.testObserverFailureTreatedAsDefinitionError()
> org.jboss.jsr299.tck.tests.deployment.lifecycle.broken.exceptionInAfterBeanValidationObserver.AfterDeploymentValidationObserverExecutionFailureTest.testObserverFailureTreatedAsDeploymentError()
> org.jboss.jsr299.tck.tests.deployment.lifecycle.broken.passivatingScope.AddingPassivatingScopeTest.testAddingScopeType()
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 10 months