[JBoss JIRA] (WFLY-11604) Non-anonymous principal is not propagated from EJB context to CDI bean
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFLY-11604?page=com.atlassian.jira.plugin... ]
Darran Lofthouse commented on WFLY-11604:
-----------------------------------------
Is this looking at Elytron or PicketBox?
> Non-anonymous principal is not propagated from EJB context to CDI bean
> ----------------------------------------------------------------------
>
> Key: WFLY-11604
> URL: https://issues.jboss.org/browse/WFLY-11604
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Security
> Affects Versions: 14.0.1.Final, 15.0.1.Final
> Reporter: Nikoleta Žiaková
> Assignee: Matej Novotny
> Priority: Critical
>
> This is a follow-up on WFLY-11587 which only dealt with being able to inject the principal.
> However, during testing I have tried a scenario when the caller principal was not anonymous (run-as-principal setting in jboss-ejb3.xml). See the test case in this [commit|https://github.com/nziakova/wildfly/commit/9ae586ad0159e6399f65103...].
> The principal is not propagated from the EJB context. The result is that injected principal in the CDI bean is always anonymous, although {{ctx.getCallerPrincipal()}} in the EJB returns correct principal.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
- 1
- 0
[JBoss JIRA] (WFLY-11604) Non-anonymous principal is not propagated from EJB context to CDI bean
by Martin Choma (Jira)
[ https://issues.jboss.org/browse/WFLY-11604?page=com.atlassian.jira.plugin... ]
Martin Choma updated WFLY-11604:
--------------------------------
Priority: Critical (was: Major)
> Non-anonymous principal is not propagated from EJB context to CDI bean
> ----------------------------------------------------------------------
>
> Key: WFLY-11604
> URL: https://issues.jboss.org/browse/WFLY-11604
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Security
> Affects Versions: 14.0.1.Final, 15.0.1.Final
> Reporter: Nikoleta Žiaková
> Assignee: Matej Novotny
> Priority: Critical
>
> This is a follow-up on WFLY-11587 which only dealt with being able to inject the principal.
> However, during testing I have tried a scenario when the caller principal was not anonymous (run-as-principal setting in jboss-ejb3.xml). See the test case in this [commit|https://github.com/nziakova/wildfly/commit/9ae586ad0159e6399f65103...].
> The principal is not propagated from the EJB context. The result is that injected principal in the CDI bean is always anonymous, although {{ctx.getCallerPrincipal()}} in the EJB returns correct principal.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
- 1
- 0
[JBoss JIRA] (WFLY-11604) Non-anonymous principal is not propagated from EJB context to CDI bean
by Martin Choma (Jira)
[ https://issues.jboss.org/browse/WFLY-11604?page=com.atlassian.jira.plugin... ]
Martin Choma commented on WFLY-11604:
-------------------------------------
[~dlofthouse] could you have a look? Although we are not sure it is a bug, it seems very suspicious. We cant spot the problem in the test. Setting to Critical to triage properly.
> Non-anonymous principal is not propagated from EJB context to CDI bean
> ----------------------------------------------------------------------
>
> Key: WFLY-11604
> URL: https://issues.jboss.org/browse/WFLY-11604
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Security
> Affects Versions: 14.0.1.Final, 15.0.1.Final
> Reporter: Nikoleta Žiaková
> Assignee: Matej Novotny
> Priority: Major
>
> This is a follow-up on WFLY-11587 which only dealt with being able to inject the principal.
> However, during testing I have tried a scenario when the caller principal was not anonymous (run-as-principal setting in jboss-ejb3.xml). See the test case in this [commit|https://github.com/nziakova/wildfly/commit/9ae586ad0159e6399f65103...].
> The principal is not propagated from the EJB context. The result is that injected principal in the CDI bean is always anonymous, although {{ctx.getCallerPrincipal()}} in the EJB returns correct principal.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
- 1
- 0
[JBoss JIRA] (WFLY-11604) Non-anonymous principal is not propagated from EJB context to CDI bean
by Nikoleta Žiaková (Jira)
[ https://issues.jboss.org/browse/WFLY-11604?page=com.atlassian.jira.plugin... ]
Nikoleta Žiaková updated WFLY-11604:
------------------------------------
Steps to Reproduce:
Run the test: mvn test -Dtest=InjectPrincipalTestCase
Repo: git@github.com:nziakova/wildfly.git
Branch: wfly11587-followup
was:Run the test: mvn test -Dtest=InjectPrincipalTestCase
> Non-anonymous principal is not propagated from EJB context to CDI bean
> ----------------------------------------------------------------------
>
> Key: WFLY-11604
> URL: https://issues.jboss.org/browse/WFLY-11604
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Security
> Affects Versions: 14.0.1.Final, 15.0.1.Final
> Reporter: Nikoleta Žiaková
> Assignee: Matej Novotny
> Priority: Major
>
> This is a follow-up on WFLY-11587 which only dealt with being able to inject the principal.
> However, during testing I have tried a scenario when the caller principal was not anonymous (run-as-principal setting in jboss-ejb3.xml). See the test case in this [commit|https://github.com/nziakova/wildfly/commit/9ae586ad0159e6399f65103...].
> The principal is not propagated from the EJB context. The result is that injected principal in the CDI bean is always anonymous, although {{ctx.getCallerPrincipal()}} in the EJB returns correct principal.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
- 1
- 0
[JBoss JIRA] (JGRP-2324) TransferQueueBundler: view change must not purge messages to non-members
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2324?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2324:
---------------------------
Description:
Currently, {{BaseBundler.viewChange()}} purges queued messages to non-members. This poses the following problem:
* Members A, B. The view is \{A,B\}
* A is coord and sends a LEAVE request to B
* B adds a LEAVE response (to A) to the TransferQueueBundler's queue and installs new view \{B\}
* If the LEAVE response to A is still in the TQB's queue and the new view is installed _before_ the message gets sent, the {{BaseBundler.viewChange()}} method _removes_ all queued messages to non-members, therefore the LEAVE response to A is removed
* As a result, A will never receive the LEAVE response and therefore run into {{GMS.leave_timeout}}!
This is aggravated by the fact that a LEAVE response is unreliable (flag={{NO_RELIABILITY}}), and therefore not retransmitted by UNICAST3.
h4. Solution: remove the {{viewChange()}} method.
h4. Reason:
* Unicast messages _can_ be sent to non-members. This is in line with the design of UNICAST3, which allows for non-members as destinations of messages.
* The {{msgs}} hashmap in {{BaseBundler}} will be emptied by the runner anyway, so we don't need to do housekeeping on that hashmap
was:
Currently, {{BaseBundler.viewChange()}} purges queued messages to non-members. This poses the following problem:
* Members A, B. The view is \{A,B\}
* A is coord and sends a LEAVE request to B
* B adds a LEAVE response (to A) to the TransferQueueBundler's queue and installs new view \{B\}
* If the LEAVE response to A is still in the TQB's queue and the new view is installed _before_ the message gets sent, the {{BaseBundler.viewChange()}} method _removes_ all queued messages to non-members, therefore the LEAVE response to A is removed
* As a result, A will never receive the LEAVE response and therefore run into {{GMS.leave_timeout}}!
This is aggravated by the fact that a LEAVE response is unreliable (flag={{NO_RELIABILITY}}), and therefore not retransmitted by UNICAST3.
Solution: remove the {{viewChange()}} method.
Reason:
* Unicast messages _can_ be sent to non-members. This is in line with the design of UNICAST3, which allows for non-members as destinations of messages.
* The {{msgs}} hashmap in {{BaseBundler}} will be emptied by the runner anyway, so we don't need to do housekeeping on that hashmap
> TransferQueueBundler: view change must not purge messages to non-members
> ------------------------------------------------------------------------
>
> Key: JGRP-2324
> URL: https://issues.jboss.org/browse/JGRP-2324
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.0.16
>
>
> Currently, {{BaseBundler.viewChange()}} purges queued messages to non-members. This poses the following problem:
> * Members A, B. The view is \{A,B\}
> * A is coord and sends a LEAVE request to B
> * B adds a LEAVE response (to A) to the TransferQueueBundler's queue and installs new view \{B\}
> * If the LEAVE response to A is still in the TQB's queue and the new view is installed _before_ the message gets sent, the {{BaseBundler.viewChange()}} method _removes_ all queued messages to non-members, therefore the LEAVE response to A is removed
> * As a result, A will never receive the LEAVE response and therefore run into {{GMS.leave_timeout}}!
> This is aggravated by the fact that a LEAVE response is unreliable (flag={{NO_RELIABILITY}}), and therefore not retransmitted by UNICAST3.
> h4. Solution: remove the {{viewChange()}} method.
> h4. Reason:
> * Unicast messages _can_ be sent to non-members. This is in line with the design of UNICAST3, which allows for non-members as destinations of messages.
> * The {{msgs}} hashmap in {{BaseBundler}} will be emptied by the runner anyway, so we don't need to do housekeeping on that hashmap
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
- 1
- 0
[JBoss JIRA] (JGRP-2324) TransferQueueBundler: view change must not purge messages to non-members
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2324?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2324:
---------------------------
Description:
Currently, {{BaseBundler.viewChange()}} purges queued messages to non-members. This poses the following problem:
* Members A, B. The view is \{A,B\}
* A is coord and sends a LEAVE request to B
* B adds a LEAVE response (to A) to the TransferQueueBundler's queue and installs new view \{B\}
* If the LEAVE response to A is still in the TQB's queue and the new view is installed _before_ the message gets sent, the {{BaseBundler.viewChange()}} method _removes_ all queued messages to non-members, therefore the LEAVE response to A is removed
* As a result, A will never receive the LEAVE response and therefore run into {{GMS.leave_timeout}}!
This is aggravated by the fact that a LEAVE response is unreliable (flag={{NO_RELIABILITY}}), and therefore not retransmitted by UNICAST3.
h4. Solution
* Remove the {{viewChange()}} method.
h4. Reason
* Unicast messages _can_ be sent to non-members. This is in line with the design of UNICAST3, which allows for non-members as destinations of messages.
* The {{msgs}} hashmap in {{BaseBundler}} will be emptied by the runner anyway, so we don't need to do housekeeping on that hashmap
was:
Currently, {{BaseBundler.viewChange()}} purges queued messages to non-members. This poses the following problem:
* Members A, B. The view is \{A,B\}
* A is coord and sends a LEAVE request to B
* B adds a LEAVE response (to A) to the TransferQueueBundler's queue and installs new view \{B\}
* If the LEAVE response to A is still in the TQB's queue and the new view is installed _before_ the message gets sent, the {{BaseBundler.viewChange()}} method _removes_ all queued messages to non-members, therefore the LEAVE response to A is removed
* As a result, A will never receive the LEAVE response and therefore run into {{GMS.leave_timeout}}!
This is aggravated by the fact that a LEAVE response is unreliable (flag={{NO_RELIABILITY}}), and therefore not retransmitted by UNICAST3.
h4. Solution: remove the {{viewChange()}} method.
h4. Reason:
* Unicast messages _can_ be sent to non-members. This is in line with the design of UNICAST3, which allows for non-members as destinations of messages.
* The {{msgs}} hashmap in {{BaseBundler}} will be emptied by the runner anyway, so we don't need to do housekeeping on that hashmap
> TransferQueueBundler: view change must not purge messages to non-members
> ------------------------------------------------------------------------
>
> Key: JGRP-2324
> URL: https://issues.jboss.org/browse/JGRP-2324
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.0.16
>
>
> Currently, {{BaseBundler.viewChange()}} purges queued messages to non-members. This poses the following problem:
> * Members A, B. The view is \{A,B\}
> * A is coord and sends a LEAVE request to B
> * B adds a LEAVE response (to A) to the TransferQueueBundler's queue and installs new view \{B\}
> * If the LEAVE response to A is still in the TQB's queue and the new view is installed _before_ the message gets sent, the {{BaseBundler.viewChange()}} method _removes_ all queued messages to non-members, therefore the LEAVE response to A is removed
> * As a result, A will never receive the LEAVE response and therefore run into {{GMS.leave_timeout}}!
> This is aggravated by the fact that a LEAVE response is unreliable (flag={{NO_RELIABILITY}}), and therefore not retransmitted by UNICAST3.
> h4. Solution
> * Remove the {{viewChange()}} method.
> h4. Reason
> * Unicast messages _can_ be sent to non-members. This is in line with the design of UNICAST3, which allows for non-members as destinations of messages.
> * The {{msgs}} hashmap in {{BaseBundler}} will be emptied by the runner anyway, so we don't need to do housekeeping on that hashmap
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
- 1
- 0
[JBoss JIRA] (WFLY-11489) SFSB not sticky on a single cluster node when clustering of the bean is disabled
by Richard Achmatowicz (Jira)
[ https://issues.jboss.org/browse/WFLY-11489?page=com.atlassian.jira.plugin... ]
Richard Achmatowicz edited comment on WFLY-11489 at 1/22/19 4:53 AM:
---------------------------------------------------------------------
I now have a fix for this issue, in the sense that it fixes the reproducer problem and also passes the testsuite, but i'm going to have to try to write some more test cases before pushing it out. The changes affect both the EJB client and Wildfly codebases.
The main changes are as follows:
1. Correct affinity assignment on server during session creation
2. Adjust affinity assignment on server during invocation
3. Adjust affinity processing in NamingInterceptor
4. Add in more debug/trace logging so we can see what is going on with affinity processing
1. This required using the values Cache.getStrongAffinity() and Cache.getWeakAffinity() to assign affinity values to new sessions. In the case where strong affinity evaluates to NodeAffinity (as with beans which have passivationEnabled=false), don't send back any affinity. This will cause the client to convert (NONE, NONE) to (targetAffinity, NONE) which works.
2. Generally, the only time the server should adjust affinity on invocations is when the weak affinity needs to be adjusted for an invocation which has failed over. Use the Cache.getWeakAffinity() for that. Also, in order to make the testsuite pass, I had to leave in a bit of code which forces SLSB to have strong affinity to "the cluster"; in other words, when a SLSB is sent to a clustered node, its strong affinity is always forced to "the cluster". I'll have to double check how this worked in the past; in general, it seems wrong (a SLSB with affinity (NONE,NONE) should not be converted to (Cluster, NONE) just because it was non-deterministically sent to a clustered node).
3. If the user has defined a PROVDER_URL in the JNDI naming context, in the case of a bean with default affinity (NONE, NONE), the NamingInterceptor will choose one URI in the PROVIDER_URL as the target; it can do this because (NONE, NONE) does not place any restrictions on the choice of target. This also has the consequence of bypassing the DiscoveryEJBClientInterceptor. However, the NamingInterceptor was calling DiscoveryEJBClientInterceptor.setupAffinities() before the invocation went out, which means that the server adjustments were not being correctly updated during reply processing. I Changed this to update the affinities on the way back, and it works as expected now.
Generally, such target selection does not check that the module is even deployed on that target before sending the invocation as discovery is bypassed; but that is for another day.
4. I have added in logging at every location where affinities are updates. This makes it a lot easier to follow what is going on.
I'll tidy up the current PR and post a ink to it.
was (Author: rachmato):
I now have a fix for this issue, in the sense that it fixes the reproducer problem and also passes the testsuite, but i'm going to have to try to write some more test cases before pushing it out. The changes affect both the EJB client and Wildfly codebases.
The main changes are as follows:
1. Correct affinity assignment on server during session creation
2. Adjust affinity assignment on server during invocation
3. Adjust affinity processing in NamingInterceptor
4. Add in more debug/trace logging so we can see what is going on with affinity processing
1. This required using the values Cache.getStrongAffinity() and Cache.getWeakAffinity() to assign affinity values to new sessions. In the case where strong affinity evaluates to NodeAffinity (as with beans which have passivationEnabled=false), don't send back any affinity. This will cause the client to convert (NONE, NONE) to (targetAffinity, NONE) which works.
2. Generally, the only time the server should adjust affinity on invocations is when the weak affinity needs to be adjusted for an invocation which has failed over. Use the Cache.getWeakAffinity() for that. Also, in order to make the testsuite pass, I had to leave in a bit of code which forces SLSB to have strong affinity to "the cluster"; in other words, when a SLSB is sent to a clustered node, its strong affinity is always forced to "the cluster". I'll have to double check how this worked in the past; in general, it seems wrong (a SLSB with affinity (NONE,NONE) should not be converted to (Cluster, NONE) just because it was non-deterministically sent to a clustered node).
3. If the user has defined a PROVDER_URL in the JNDI naming context, in the case of a bean with default affinity (NONE, NONE), the NamingInterceptor will choose one URI in the PROVIDER_URL as the target; it can do this because (NONE, NONE) does not place any restrictions on the choice of target. However, the NamingInterceptor was calling DiscoveryEJBClientInterceptor.setupAffinities() before the invocation went out, which means that the server adjustments were not being correctly updated during reply processing. I Changed this to update the affinities on the way back, and it works as expected now.
4. I have added in logging at every location where affinities are updates. This makes it a lot easier to follow what is going on.
I'll tidy up the current PR and post a ink to it.
> SFSB not sticky on a single cluster node when clustering of the bean is disabled
> --------------------------------------------------------------------------------
>
> Key: WFLY-11489
> URL: https://issues.jboss.org/browse/WFLY-11489
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Remoting
> Affects Versions: 15.0.0.Final
> Environment: A clustered environment with 2 nodes. Both nodes started with an unmodified {{standalone-ha.xml}} configuration (see _Steps to Reproduce_)
> This issue happens on 15.0.0.Final and was tested as well as on current head (sha: 372697282dccefd0b9df48e6aa4dcb69e1c4b40f).
> Reporter: Jörg Bäsner
> Assignee: Richard Achmatowicz
> Priority: Major
> Attachments: reproducer.zip
>
>
> In case a stateful session bean is annotated with:
> {{@Stateful(passivationCapable=false)}}
> then the serialization is *disabled* and thus the bean is only available on a single cluster node.
> When a client now calls two different methods on this stateful bean it intermittently ends up on different cluster nodes, resulting in the following Exception:
> {code}
> ERROR [org.jboss.as.ejb3.invocation] (default task-2) WFLYEJB0034: EJB Invocation failed on component TestSessionEJB for method public abstract void test.ITestSession.method2(java.lang.String,java.lang.String) throws javax.ejb.EJBException,java.rmi.RemoteException: javax.ejb.NoSuchEJBException: WFLYEJB0168: Could not find EJB with id UUIDSessionID [4b0f4a27-40ba-411b-8852-0108a5ec64f4]
> at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:55)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:81)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:618)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> at org.wildfly.security.auth.server.SecurityIdentity.runAsFunctionEx(SecurityIdentity.java:406)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeWithIdentity(AssociationImpl.java:565)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:546)
> at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:197)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1349)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
- 1
- 0
[JBoss JIRA] (WFLY-11489) SFSB not sticky on a single cluster node when clustering of the bean is disabled
by Richard Achmatowicz (Jira)
[ https://issues.jboss.org/browse/WFLY-11489?page=com.atlassian.jira.plugin... ]
Richard Achmatowicz edited comment on WFLY-11489 at 1/22/19 4:49 AM:
---------------------------------------------------------------------
I now have a fix for this issue, in the sense that it fixes the reproducer problem and also passes the testsuite, but i'm going to have to try to write some more test cases before pushing it out. The changes affect both the EJB client and Wildfly codebases.
The main changes are as follows:
1. Correct affinity assignment on server during session creation
2. Adjust affinity assignment on server during invocation
3. Adjust affinity processing in NamingInterceptor
4. Add in more debug/trace logging so we can see what is going on with affinity processing
1. This required using the values Cache.getStrongAffinity() and Cache.getWeakAffinity() to assign affinity values to new sessions. In the case where strong affinity evaluates to NodeAffinity (as with beans which have passivationEnabled=false), don't send back any affinity. This will cause the client to convert (NONE, NONE) to (targetAffinity, NONE) which works.
2. Generally, the only time the server should adjust affinity on invocations is when the weak affinity needs to be adjusted for an invocation which has failed over. Use the Cache.getWeakAffinity() for that. Also, in order to make the testsuite pass, I had to leave in a bit of code which forces SLSB to have strong affinity to "the cluster"; in other words, when a SLSB is sent to a clustered node, its strong affinity is always forced to "the cluster". I'll have to double check how this worked in the past; in general, it seems wrong (a SLSB with affinity (NONE,NONE) should not be converted to (Cluster, NONE) just because it was non-deterministically sent to a clustered node).
3. If the user has defined a PROVDER_URL in the JNDI naming context, in the case of a bean with default affinity (NONE, NONE), the NamingInterceptor will choose one URI in the PROVIDER_URL as the target; it can do this because (NONE, NONE) does not place any restrictions on the choice of target. However, the NamingInterceptor was calling DiscoveryEJBClientInterceptor.setupAffinities() before the invocation went out, which means that the server adjustments were not being correctly updated during reply processing. I Changed this to update the affinities on the way back, and it works as expected now.
4. I have added in logging at every location where affinities are updates. This makes it a lot easier to follow what is going on.
I'll tidy up the current PR and post a ink to it.
was (Author: rachmato):
I now have a fix for this issue, in the sense that it fixes the reproducer problem and also passes the testsuite, but i'm going to have to try to write some more test cases before pushing it out. The changes affect both the EJB client and Wildfly codebases.
The main changes are as follows:
1. Correct affinity assignment on server during session creation
2. Adjust affinity assignment on server during invocation
3. Adjust affinity processing in NamingInterceptor
4. Add in more debug/trace logging so we can see what is going on with affinity processing
1. This required using the values Cache.getStrongAffinity() and Cache.getWeakAffinity() to assign affinity values to new sessions. In the case where strong affinity evaluates to NodeAffinity (as with beans which have passivationEnabled=false), don't send back any affinity. This will cause the client to convert (NONE, NONE) to (targetAffinity, NONE) which works.
2. Generally, the only time the server should adjust affinity on invocations is when the weak affinity needs to be adjusted for an invocation which has failed over. Use the Cache.getWeakAffinity() for that. Also, in order to make the testsuite pass, I had to leave in a bit of code which forces SLSB to have strong affinity to "the cluster"; in other words, when a s SLSB is send to a clustered node, its strong affinity is always forced to "the cluster". I'll have to double check how this worked in the past; in general, it seems wrong (a SLSB with affinity (NONE,NONE) should not be converted to (Cluster, NONE) just because it was non-deterministically sent to a clustered node).
3. If the user has defined a PROVDER_URL in the JNDI naming context, in the case of a bean with default affinity (NONE, NONE), the NamingInterceptor will choose one URI in the PROVIDER_URL as the target; it can do this because (NONE, NONE) does not place any restrictions on the choice of target. However, the NamingInterceptor was calling DiscoveryEJBClientInterceptor.setupAffinities() before the invocation went out, which means that the server adjustments were not being correctly updated during reply processing. I Changed this to update the affinities on the way back, and it works as expected now.
4. I have added in logging at every location where affinities are updates. This makes it a lot easier to follow what is going on.
I'll tidy up the current PR and post a ink to it.
> SFSB not sticky on a single cluster node when clustering of the bean is disabled
> --------------------------------------------------------------------------------
>
> Key: WFLY-11489
> URL: https://issues.jboss.org/browse/WFLY-11489
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Remoting
> Affects Versions: 15.0.0.Final
> Environment: A clustered environment with 2 nodes. Both nodes started with an unmodified {{standalone-ha.xml}} configuration (see _Steps to Reproduce_)
> This issue happens on 15.0.0.Final and was tested as well as on current head (sha: 372697282dccefd0b9df48e6aa4dcb69e1c4b40f).
> Reporter: Jörg Bäsner
> Assignee: Richard Achmatowicz
> Priority: Major
> Attachments: reproducer.zip
>
>
> In case a stateful session bean is annotated with:
> {{@Stateful(passivationCapable=false)}}
> then the serialization is *disabled* and thus the bean is only available on a single cluster node.
> When a client now calls two different methods on this stateful bean it intermittently ends up on different cluster nodes, resulting in the following Exception:
> {code}
> ERROR [org.jboss.as.ejb3.invocation] (default task-2) WFLYEJB0034: EJB Invocation failed on component TestSessionEJB for method public abstract void test.ITestSession.method2(java.lang.String,java.lang.String) throws javax.ejb.EJBException,java.rmi.RemoteException: javax.ejb.NoSuchEJBException: WFLYEJB0168: Could not find EJB with id UUIDSessionID [4b0f4a27-40ba-411b-8852-0108a5ec64f4]
> at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:55)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:81)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:618)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> at org.wildfly.security.auth.server.SecurityIdentity.runAsFunctionEx(SecurityIdentity.java:406)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeWithIdentity(AssociationImpl.java:565)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:546)
> at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:197)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1349)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
- 1
- 0
[JBoss JIRA] (WFLY-10191) Artemis can fail when resolving DNS under a security manager
by ehsavoie Hugonnet (Jira)
[ https://issues.jboss.org/browse/WFLY-10191?page=com.atlassian.jira.plugin... ]
ehsavoie Hugonnet resolved WFLY-10191.
--------------------------------------
Fix Version/s: 16.0.0.Beta1
Resolution: Done
> Artemis can fail when resolving DNS under a security manager
> ------------------------------------------------------------
>
> Key: WFLY-10191
> URL: https://issues.jboss.org/browse/WFLY-10191
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 12.0.0.Final, 14.0.0.Final
> Reporter: David Lloyd
> Assignee: ehsavoie Hugonnet
> Priority: Major
> Labels: security-manager
> Fix For: 16.0.0.Beta1
>
>
> The stack trace looks like this:
> {noformat}
> AMQ212007: connector.create or connectorFactory.createConnector should never throw an exception, implementation is badly behaved, but we will deal with it anyway.: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "localhost" "resolve")" in code source "(vfs:/content/JMSResourceDefinitionsTestCase.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.JMSResourceDefinitionsTestCase.jar" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:295)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:192)
> at java.lang.SecurityManager.checkConnect(SecurityManager.java:1048)
> at org.wildfly.security.manager.WildFlySecurityManager.checkConnect(WildFlySecurityManager.java:390)
> at java.net.InetAddress.getAllByName0(InetAddress.java:1268)
> at java.net.InetAddress.getAllByName(InetAddress.java:1192)
> at java.net.InetAddress.getAllByName(InetAddress.java:1126)
> at java.net.InetAddress.getByName(InetAddress.java:1076)
> at java.net.InetSocketAddress.<init>(InetSocketAddress.java:220)
> at org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector.createConnection(NettyConnector.java:600)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.openTransportConnection(ClientSessionFactoryImpl.java:1036)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createTransportConnection(ClientSessionFactoryImpl.java:1076)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.establishNewConnection(ClientSessionFactoryImpl.java:1254)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.getConnection(ClientSessionFactoryImpl.java:891)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.getConnectionWithRetry(ClientSessionFactoryImpl.java:795)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.connect(ClientSessionFactoryImpl.java:238)
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:772)
> at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:755)
> at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createXAConnection(ActiveMQConnectionFactory.java:338)
> at org.apache.activemq.artemis.ra.ActiveMQRAManagedConnection.setup(ActiveMQRAManagedConnection.java:769)
> at org.apache.activemq.artemis.ra.ActiveMQRAManagedConnection.<init>(ActiveMQRAManagedConnection.java:161)
> at org.apache.activemq.artemis.ra.ActiveMQRAManagedConnectionFactory.createManagedConnection(ActiveMQRAManagedConnectionFactory.java:151)
> at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.createConnectionEventListener(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:1326)
> at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.getConnection(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:499)
> at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getTransactionNewConnection(AbstractPool.java:714)
> at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:613)
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:624)
> at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:430)
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:789)
> at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.allocateConnection(ActiveMQRASessionFactoryImpl.java:873)
> at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:531)
> at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:746)
> at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:751)
> at org.apache.activemq.artemis.ra.ActiveMQRAConnectionFactoryImpl.validateUser(ActiveMQRAConnectionFactoryImpl.java:475)
> at org.apache.activemq.artemis.ra.ActiveMQRAConnectionFactoryImpl.createContext(ActiveMQRAConnectionFactoryImpl.java:432)
> at org.jboss.as.test.integration.messaging.jms.definitions.MessagingBean.checkInjectedResources(MessagingBean.java:182)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:90)
> at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:101)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:40)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:273)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:330)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:238)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:72)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:619)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:81)
> at org.jboss.as.test.integration.messaging.jms.definitions.MessagingBean$$$view259.checkInjectedResources(Unknown Source)
> at org.jboss.as.test.integration.messaging.jms.definitions.JMSResourceDefinitionsTestCase.testInjectedDefinitions(JMSResourceDefinitionsTestCase.java:152)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:379)
> at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:85)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:143)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:85)
> at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> at sun.reflect.GeneratedMethodAccessor264.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:92)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> at sun.reflect.GeneratedMethodAccessor263.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:92)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> at sun.reflect.GeneratedMethodAccessor262.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:92)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:143)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136)
> at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:372)
> at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:246)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:431)
> at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:55)
> at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:260)
> at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:324)
> at org.jboss.arquillian.container.test.impl.execution.BeforeLifecycleEventExecuter.on(BeforeLifecycleEventExecuter.java:35)
> at sun.reflect.GeneratedMethodAccessor265.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:85)
> at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> at sun.reflect.GeneratedMethodAccessor264.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:92)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> at sun.reflect.GeneratedMethodAccessor263.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:92)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> at sun.reflect.GeneratedMethodAccessor262.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:92)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:143)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159)
> at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:317)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:205)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:431)
> at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:55)
> at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:219)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:167)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:66)
> at org.jboss.arquillian.protocol.jmx.JMXTestRunner.doRunTestMethod(JMXTestRunner.java:180)
> at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.doRunTestMethod(ArquillianService.java:200)
> at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:162)
> at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:141)
> at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:176)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
> at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1475)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:724)
> at org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168)
> at org.jboss.as.jmx.AuthorizingMBeanServer.invoke(AuthorizingMBeanServer.java:258)
> at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950)
> at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:71)
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:66)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:287)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225)
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:66)
> at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> The solution may be to explicitly resolve the InetAddress(s) in a privileged block before passing them in to Netty.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
- 1
- 0
[JBoss JIRA] (WFLY-11489) SFSB not sticky on a single cluster node when clustering of the bean is disabled
by Richard Achmatowicz (Jira)
[ https://issues.jboss.org/browse/WFLY-11489?page=com.atlassian.jira.plugin... ]
Richard Achmatowicz edited comment on WFLY-11489 at 1/22/19 4:48 AM:
---------------------------------------------------------------------
I now have a fix for this issue, in the sense that it fixes the reproducer problem and also passes the testsuite, but i'm going to have to try to write some more test cases before pushing it out. The changes affect both the EJB client and Wildfly codebases.
The main changes are as follows:
1. Correct affinity assignment on server during session creation
2. Adjust affinity assignment on server during invocation
3. Adjust affinity processing in NamingInterceptor
4. Add in more debug/trace logging so we can see what is going on with affinity processing
1. This required using the values Cache.getStrongAffinity() and Cache.getWeakAffinity() to assign affinity values to new sessions. In the case where strong affinity evaluates to NodeAffinity (as with beans which have passivationEnabled=false), don't send back any affinity. This will cause the client to convert (NONE, NONE) to (targetAffinity, NONE) which works.
2. Generally, the only time the server should adjust affinity on invocations is when the weak affinity needs to be adjusted for an invocation which has failed over. Use the Cache.getWeakAffinity() for that. Also, in order to make the testsuite pass, I had to leave in a bit of code which forces SLSB to have strong affinity to "the cluster"; in other words, when a s SLSB is send to a clustered node, its strong affinity is always forced to "the cluster". I'll have to double check how this worked in the past; in general, it seems wrong (a SLSB with affinity (NONE,NONE) should not be converted to (Cluster, NONE) just because it was non-deterministically sent to a clustered node).
3. If the user has defined a PROVDER_URL in the JNDI naming context, in the case of a bean with default affinity (NONE, NONE), the NamingInterceptor will choose one URI in the PROVIDER_URL as the target; it can do this because (NONE, NONE) does not place any restrictions on the choice of target. However, the NamingInterceptor was calling DiscoveryEJBClientInterceptor.setupAffinities() before the invocation went out, which means that the server adjustments were not being correctly updated during reply processing. I Changed this to update the affinities on the way back, and it works as expected now.
4. I have added in logging at every location where affinities are updates. This makes it a lot easier to follow what is going on.
I'll tidy up the current PR and post a ink to it.
was (Author: rachmato):
I now have a fix for this issue, in the sense that it fixes the reproducer problem and also passes the testsuite, but i'm going to have to try to write some more test cases before pushing it out.
The changes affect both the EJB client and Wildfly codebases.
The main changes are as follows:
1. Correct affinity assignment on server during session creation
2. Adjust affinity assignment on server during invocation
3. Adjust affinity processing in NamingInterceptor
4. Add in more debug/trace logging so we can see what is going on with affinity processing
1. This required using the values Cache.getStrongAffinity() and Cache.getWeakAffinity() to assign affinity values to new sessions. In the case where strong affinity evaluates to NodeAffinity (as with beans which have passivationEnabled=false), don't send back any affinity. This will cause the client to convert (NONE, NONE) to (targetNode, NONE) which works.
2. Generally, the only time the server should adjust affinity on onvocations is when the weak affinity needs to be adjusted for an invocation which has failed over. Use the Cache.getWeakAffinity() for that. Also, in order to make the testsuite pass, I had to leave in a bit of code which forces SLSB to have strong affinity to "the cluster"; in other words, when a s SLSB is send to a clustered node, its strong affinity is always forced to "the cluster". I'll have to double check how this worked in the past; in general, it seems wrong (a SLSB with affinity (NONE,NONE) should not be converted to (Cluster, NONE) just because it was non-deterministically sent to a clustered node).
3. If the user has defined a PROVDER_URL in the JNDI naming context, in the case of a bean with default affinity (NONE, NONE), the NamingInterceptor will choose one URI in the PROVIDER_URL as the target; it can do this because (NONE, NONE) does not place any restrictions on the choice of target. However, the NamingInterceptor was calling DiscoveryEJBClientInterceptor.setupAffinities() before the invocation went out, which means that the server adjustments were not being correctly updated during reply processing. I Changed this to update the affinities on the way back, and it works as expected now.
4. I have added in logging at every location where affinities are updates. This makes it a lot easier to follow what is going on.
I'll tidy up the current PR and post a ink to it.
> SFSB not sticky on a single cluster node when clustering of the bean is disabled
> --------------------------------------------------------------------------------
>
> Key: WFLY-11489
> URL: https://issues.jboss.org/browse/WFLY-11489
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Remoting
> Affects Versions: 15.0.0.Final
> Environment: A clustered environment with 2 nodes. Both nodes started with an unmodified {{standalone-ha.xml}} configuration (see _Steps to Reproduce_)
> This issue happens on 15.0.0.Final and was tested as well as on current head (sha: 372697282dccefd0b9df48e6aa4dcb69e1c4b40f).
> Reporter: Jörg Bäsner
> Assignee: Richard Achmatowicz
> Priority: Major
> Attachments: reproducer.zip
>
>
> In case a stateful session bean is annotated with:
> {{@Stateful(passivationCapable=false)}}
> then the serialization is *disabled* and thus the bean is only available on a single cluster node.
> When a client now calls two different methods on this stateful bean it intermittently ends up on different cluster nodes, resulting in the following Exception:
> {code}
> ERROR [org.jboss.as.ejb3.invocation] (default task-2) WFLYEJB0034: EJB Invocation failed on component TestSessionEJB for method public abstract void test.ITestSession.method2(java.lang.String,java.lang.String) throws javax.ejb.EJBException,java.rmi.RemoteException: javax.ejb.NoSuchEJBException: WFLYEJB0168: Could not find EJB with id UUIDSessionID [4b0f4a27-40ba-411b-8852-0108a5ec64f4]
> at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:55)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:81)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:618)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> at org.wildfly.security.auth.server.SecurityIdentity.runAsFunctionEx(SecurityIdentity.java:406)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeWithIdentity(AssociationImpl.java:565)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:546)
> at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:197)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1349)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
- 1
- 0