[JBoss JIRA] (ELY-1230) Attribute security-domain from Elytron authentication-configuration does not propagate credentials
by Pedro Igor (JIRA)
[ https://issues.jboss.org/browse/ELY-1230?page=com.atlassian.jira.plugin.s... ]
Pedro Igor commented on ELY-1230:
---------------------------------
Another fix on the way in order to fix remoting in WFCORE in order to properly configure identity propagation to outbound connections.
> Attribute security-domain from Elytron authentication-configuration does not propagate credentials
> --------------------------------------------------------------------------------------------------
>
> Key: ELY-1230
> URL: https://issues.jboss.org/browse/ELY-1230
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta47
> Reporter: Ondrej Lukas
> Assignee: Pedro Igor
> Priority: Critical
>
> When client-server schema as 'Client -> Server A -> Server B' is used and intermediate server (server A) uses {{authentication-configuration.security-domain}} and DIGEST-MD5 mechanism is used then application (i.e. EJB) from intermediate server cannot authenticate to server B. It seems that DIGEST-MD5 mechanism cannot be chosen by SASL mechanism selector when no user and credentials are explicitly allowed.
> As we understand attribute {{authentication-configuration.security-domain}} correctly (since there is not any sufficient documentation or example project), then intermediate server should be able to obtain credentials from given security domain and use them for authentication.
> See reproducer for more details.
> Exception from intermediate server:
> {code}
> ERROR [org.jboss.as.ejb3.invocation] (default task-6) WFLYEJB0034: EJB Invocation failed on component Intermediate for method public abstract java.lang.String example.ejb.WhoAmIBeanRemote.whoAmI(): javax.ejb.EJBException: java.lang.IllegalStateException: EJBCLIENT000024: Not able to find EJB matching "StatelessEJBLocator for "/server-side/WhoAmIBean", view is interface example.ejb.WhoAmIBeanRemote, affinity is None"
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:188)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:332)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:240)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:327)
> at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:89)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.security.AuthorizationInterceptor.processInvocation(AuthorizationInterceptor.java:138)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:256)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:609)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 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:380)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeWithIdentity(AssociationImpl.java:460)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:455)
> at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:165)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.IllegalStateException: EJBCLIENT000024: Not able to find EJB matching "StatelessEJBLocator for "/server-side/WhoAmIBean", view is interface example.ejb.WhoAmIBeanRemote, affinity is None"
> at org.jboss.ejb.client.EJBClientContext.discoverAffinityNone(EJBClientContext.java:719)
> at org.jboss.ejb.client.EJBClientContext.performLocatedAction(EJBClientContext.java:701)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:162)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:112)
> at com.sun.proxy.$Proxy48.whoAmI(Unknown Source)
> at example.ejb.Intermediate.whoAmI(Intermediate.java:21)
> 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:497)
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:327)
> 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:240)
> at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:40)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 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:240)
> at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> ... 44 more
> Suppressed: javax.security.sasl.SaslException: Authentication failed: none of the mechanisms presented by the server (JBOSS-LOCAL-USER, DIGEST-MD5) are supported
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:438)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:246)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:567)
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:545)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:513)
> at org.jboss.remoting3.ConnectionInfo$None.getConnection(ConnectionInfo.java:84)
> at org.jboss.remoting3.ConnectionInfo.getConnection(ConnectionInfo.java:57)
> at org.jboss.remoting3.EndpointImpl.doGetConnection(EndpointImpl.java:464)
> at org.jboss.remoting3.EndpointImpl.getConnectedIdentity(EndpointImpl.java:410)
> at org.jboss.remoting3.Endpoint.getConnectedIdentity(Endpoint.java:126)
> at org.jboss.remoting3.Endpoint.getConnectedIdentity(Endpoint.java:139)
> at org.jboss.remoting3.Endpoint.getConnection(Endpoint.java:216)
> at org.jboss.ejb.protocol.remote.RemotingEJBDiscoveryProvider.lambda$discover$0(RemotingEJBDiscoveryProvider.java:103)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.ejb.protocol.remote.RemotingEJBDiscoveryProvider.discover(RemotingEJBDiscoveryProvider.java:103)
> at org.wildfly.discovery.impl.AggregateDiscoveryProvider.discover(AggregateDiscoveryProvider.java:58)
> at org.wildfly.discovery.Discovery.discover(Discovery.java:94)
> at org.jboss.ejb.client.EJBClientContext.discover(EJBClientContext.java:442)
> at org.jboss.ejb.client.EJBClientContext.discoverAffinityNone(EJBClientContext.java:714)
> ... 74 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (ELY-1230) Attribute security-domain from Elytron authentication-configuration does not propagate credentials
by Pedro Igor (JIRA)
[ https://issues.jboss.org/browse/ELY-1230?page=com.atlassian.jira.plugin.s... ]
Pedro Igor reassigned ELY-1230:
-------------------------------
Assignee: Pedro Igor (was: Darran Lofthouse)
> Attribute security-domain from Elytron authentication-configuration does not propagate credentials
> --------------------------------------------------------------------------------------------------
>
> Key: ELY-1230
> URL: https://issues.jboss.org/browse/ELY-1230
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta47
> Reporter: Ondrej Lukas
> Assignee: Pedro Igor
> Priority: Critical
>
> When client-server schema as 'Client -> Server A -> Server B' is used and intermediate server (server A) uses {{authentication-configuration.security-domain}} and DIGEST-MD5 mechanism is used then application (i.e. EJB) from intermediate server cannot authenticate to server B. It seems that DIGEST-MD5 mechanism cannot be chosen by SASL mechanism selector when no user and credentials are explicitly allowed.
> As we understand attribute {{authentication-configuration.security-domain}} correctly (since there is not any sufficient documentation or example project), then intermediate server should be able to obtain credentials from given security domain and use them for authentication.
> See reproducer for more details.
> Exception from intermediate server:
> {code}
> ERROR [org.jboss.as.ejb3.invocation] (default task-6) WFLYEJB0034: EJB Invocation failed on component Intermediate for method public abstract java.lang.String example.ejb.WhoAmIBeanRemote.whoAmI(): javax.ejb.EJBException: java.lang.IllegalStateException: EJBCLIENT000024: Not able to find EJB matching "StatelessEJBLocator for "/server-side/WhoAmIBean", view is interface example.ejb.WhoAmIBeanRemote, affinity is None"
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:188)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:332)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:240)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:327)
> at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:89)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.security.AuthorizationInterceptor.processInvocation(AuthorizationInterceptor.java:138)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:256)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:609)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 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:380)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeWithIdentity(AssociationImpl.java:460)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:455)
> at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:165)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.IllegalStateException: EJBCLIENT000024: Not able to find EJB matching "StatelessEJBLocator for "/server-side/WhoAmIBean", view is interface example.ejb.WhoAmIBeanRemote, affinity is None"
> at org.jboss.ejb.client.EJBClientContext.discoverAffinityNone(EJBClientContext.java:719)
> at org.jboss.ejb.client.EJBClientContext.performLocatedAction(EJBClientContext.java:701)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:162)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:112)
> at com.sun.proxy.$Proxy48.whoAmI(Unknown Source)
> at example.ejb.Intermediate.whoAmI(Intermediate.java:21)
> 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:497)
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:327)
> 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:240)
> at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:40)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 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:240)
> at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> ... 44 more
> Suppressed: javax.security.sasl.SaslException: Authentication failed: none of the mechanisms presented by the server (JBOSS-LOCAL-USER, DIGEST-MD5) are supported
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:438)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:246)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:567)
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:545)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:513)
> at org.jboss.remoting3.ConnectionInfo$None.getConnection(ConnectionInfo.java:84)
> at org.jboss.remoting3.ConnectionInfo.getConnection(ConnectionInfo.java:57)
> at org.jboss.remoting3.EndpointImpl.doGetConnection(EndpointImpl.java:464)
> at org.jboss.remoting3.EndpointImpl.getConnectedIdentity(EndpointImpl.java:410)
> at org.jboss.remoting3.Endpoint.getConnectedIdentity(Endpoint.java:126)
> at org.jboss.remoting3.Endpoint.getConnectedIdentity(Endpoint.java:139)
> at org.jboss.remoting3.Endpoint.getConnection(Endpoint.java:216)
> at org.jboss.ejb.protocol.remote.RemotingEJBDiscoveryProvider.lambda$discover$0(RemotingEJBDiscoveryProvider.java:103)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.ejb.protocol.remote.RemotingEJBDiscoveryProvider.discover(RemotingEJBDiscoveryProvider.java:103)
> at org.wildfly.discovery.impl.AggregateDiscoveryProvider.discover(AggregateDiscoveryProvider.java:58)
> at org.wildfly.discovery.Discovery.discover(Discovery.java:94)
> at org.jboss.ejb.client.EJBClientContext.discover(EJBClientContext.java:442)
> at org.jboss.ejb.client.EJBClientContext.discoverAffinityNone(EJBClientContext.java:714)
> ... 74 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9006) Fix http-connector setup in EjbElytronDomainSetup to ensure the correct sasl-authentication-factory gets used
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFLY-9006?page=com.atlassian.jira.plugin.... ]
Farah Juma moved JBEAP-11814 to WFLY-9006:
------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-9006 (was: JBEAP-11814)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Test Suite
(was: Test Suite)
> Fix http-connector setup in EjbElytronDomainSetup to ensure the correct sasl-authentication-factory gets used
> -------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9006
> URL: https://issues.jboss.org/browse/WFLY-9006
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Farah Juma
> Assignee: Farah Juma
>
> Currently, it's possible for GetCallerPrincipalTestCase to fail due to the wrong sasl-authentication-factory being used by the http-connector (i.e., "application-sasl-factory" gets used instead of the sasl-authentication-factory that's created in EjbElytronDomainSetup).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9004) Artemis leaks JGroups channels on reload
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-9004?page=com.atlassian.jira.plugin.... ]
Radoslav Husar moved JBEAP-11812 to WFLY-9004:
----------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-9004 (was: JBEAP-11812)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Clustering
(was: Clustering)
Affects Version/s: 11.0.0.Alpha1
(was: 7.1.0.ER1)
> Artemis leaks JGroups channels on reload
> ----------------------------------------
>
> Key: WFLY-9004
> URL: https://issues.jboss.org/browse/WFLY-9004
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 11.0.0.Alpha1
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Blocker
>
> _Customer Impact:_ If server is reloaded multiple times then there is growing number of threads. This can crash server on OutOfMemoryError. Also threads continuously increases memory footprint.
> If server is reloaded multiple times then there seems to be infinite grow in numbers of following 2 threads:
> {code}
> "thread-2,shared=<CLUSTER>" #158395 daemon prio=5 os_prio=0 tid=0x00007fb5e351c000 nid=0x2672 waiting on condition [0x00007fb5cabaf000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000fc9e6d48> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52)
> at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory$$Lambda$868/1712469388.run(Unknown Source)
> at java.lang.Thread.run(Thread.java:744)
> {code}
> {code}
> "Timer runner-1,shared=<CLUSTER>" #158327 daemon prio=5 os_prio=0 tid=0x00007fb6bdd50800 nid=0x262b runnable [0x00007fb5d5d5e000]
> java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000fc9e76f0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> at java.util.concurrent.DelayQueue.take(DelayQueue.java:223)
> at java.util.concurrent.DelayQueue.take(DelayQueue.java:70)
> at org.jgroups.util.TimeScheduler3.run(TimeScheduler3.java:166)
> at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52)
> at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory$$Lambda$868/1712469388.run(Unknown Source)
> at java.lang.Thread.run(Thread.java:744)
> {code}
> There seems to be thread pool executor which is creating new and new thread after each reload waiting for a task to be executed. However number of those threads is not going down and most likely there is not set maximum limit.
> Attaching 2 thread dumps where diff between threads can be made. I've used script https://github.com/dudaerich/scripts/blob/master/src/thread-dump-analyzer... to get number of threads from each thread pool and then made a diff.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (DROOLS-1629) PersisteHelper and ObjectMarshallingStrategyStore are mixing ObjectMarshallingStrategies
by Manuel Castro (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1629?page=com.atlassian.jira.plugi... ]
Manuel Castro commented on DROOLS-1629:
---------------------------------------
Hi Mario, I will do it, but this week I'm on holidays so will be requesting it next week.
Regards.
El 27/6/2017 9:33, "Mario Fusco (JIRA)" <issues(a)jboss.org> escribió:
[1]Mario Fusco commented on [2]DROOLS-1629
[3]Re: PersisteHelper and ObjectMarshallingStrategyStore are mixing ObjectMarshallingStrategies
[4]Manuel Castro Are you still going to send your pull request against master?
[5] [6]Add Comment
This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d)
----------------------------------------------------------------------------------------
[1] https://issues.jboss.org/secure/ViewProfile.jspa?name=mfusco
[2] https://issues.jboss.org/browse/DROOLS-1629
[3] https://issues.jboss.org/browse/DROOLS-1629
[4] https://issues.jboss.org/secure/ViewProfile.jspa?name=ngs_mtech
[5] https://issues.jboss.org/browse/DROOLS-1629#add-comment
[6] https://issues.jboss.org/browse/DROOLS-1629#add-comment
> PersisteHelper and ObjectMarshallingStrategyStore are mixing ObjectMarshallingStrategies
> ----------------------------------------------------------------------------------------
>
> Key: DROOLS-1629
> URL: https://issues.jboss.org/browse/DROOLS-1629
> Project: Drools
> Issue Type: Bug
> Components: core engine, kie server
> Affects Versions: 6.4.0.Final, 6.5.0.Final
> Reporter: Manuel Castro
> Assignee: Mario Fusco
> Original Estimate: 3 days
> Remaining Estimate: 3 days
>
> We are defining our custom JPAPlaceHolderResolverStrategy, parametrizing the constructuctor with the persistence unit name it handles.
> When we need two of them to handle different kind of Entities probably from different DataSources, the marshalling process works properly as calling to accept method before marshalling returns true for the correct ObjectMarshallingStrategy.
> The problem occurs while unmarshalling the entities. As the class name is being used to find the correct ObjectMarshallingStrategy from the store, the class name matches two Object Marshalling Strategies, so the first one found is returned, making the environment work in a random space.
> This problem could be solved adding to ObjectMarshallingStrategy interface a getName() method in order to be able to avoid the usage of the getClass().getName() approach is being used now.
> Then PersisteHelper must use this method to store the ProtobufferHeader and then ObjectMarshallingStrategyStore must use the method to retrieve the appropiate implementation.
> In order to enable backward compatibility a NamedObjectMarshallingStrategyInterface could be added to be invoked only for updated implementors.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months