[JBoss JIRA] (ELY-1525) When SSO is enabled, multipart form and form enconding stop working.
by Farah Juma (Jira)
[ https://issues.jboss.org/browse/ELY-1525?page=com.atlassian.jira.plugin.s... ]
Farah Juma updated ELY-1525:
----------------------------
Fix Version/s: 1.8.0.CR1
(was: 1.7.0.Final)
> When SSO is enabled, multipart form and form enconding stop working.
> --------------------------------------------------------------------
>
> Key: ELY-1525
> URL: https://issues.jboss.org/browse/ELY-1525
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.6.Final, 1.2.1.Final
> Reporter: Estevão Freitas
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 1.8.0.CR1
>
>
> I developed a JSF application with "h:inputFile" component and it requires a form with " enctype="multipart/form-data" ".
> I use this tutorial for SSO: https://docs.jboss.org/author/display/WFLY/Web+Single+Sign-On .
> When I execute the last step: " /subsystem=undertow/application-security-domain=other/setting=single-sign-on:add(key-store=example-keystore, key-alias=localhost, domain=localhost, credential-reference=clear-text=secret}) ", all commandButtons stop working.
> If I remove the "h:inputFile" component and " enctype="multipart/form-data" " from form all buttons works again, but all words with accents are corrupted.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (ELY-1475) Empty username for FormAuthenticationMechanism causes IllegalArgumentException
by Farah Juma (Jira)
[ https://issues.jboss.org/browse/ELY-1475?page=com.atlassian.jira.plugin.s... ]
Farah Juma updated ELY-1475:
----------------------------
Fix Version/s: 1.8.0.CR1
(was: 1.7.0.Final)
> Empty username for FormAuthenticationMechanism causes IllegalArgumentException
> ------------------------------------------------------------------------------
>
> Key: ELY-1475
> URL: https://issues.jboss.org/browse/ELY-1475
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.2.0.Beta11
> Reporter: Ondrej Lukas
> Assignee: Ilia Vassilev
> Priority: Major
> Fix For: 1.8.0.CR1
>
>
> In case when empty username is passed to FormAuthenticationMechanism.attemptAuthentication then IllegalArgumentException is thrown from constructor of NameCallback. This happens in cases when form is sent with empty value for j_username.
> See exception:
> {code}
> ERROR [io.undertow.request] (default task-18) UT005023: Exception handling request to /depForm/j_security_check: java.lang.IllegalArgumentException
> at javax.security.auth.callback.NameCallback.<init>(NameCallback.java:90)
> at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:60)
> at org.wildfly.security.http.impl.FormAuthenticationMechanism.attemptAuthentication(FormAuthenticationMechanism.java:172)
> at org.wildfly.security.http.impl.FormAuthenticationMechanism.evaluateRequest(FormAuthenticationMechanism.java:106)
> at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:114)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:115)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:94)
> at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:78)
> at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:100)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
> 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)
> {code}
> It seems that [1] should also check {{username.length() == 0}}.
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/32ff7c17965b3eca...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (ELY-1703) Intermittent failure of PrincipalMappingSuiteChild#testDnToDnVerify
by Farah Juma (Jira)
[ https://issues.jboss.org/browse/ELY-1703?page=com.atlassian.jira.plugin.s... ]
Farah Juma updated ELY-1703:
----------------------------
Fix Version/s: 1.8.0.CR1
(was: 1.7.0.Final)
> Intermittent failure of PrincipalMappingSuiteChild#testDnToDnVerify
> -------------------------------------------------------------------
>
> Key: ELY-1703
> URL: https://issues.jboss.org/browse/ELY-1703
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Testsuite
> Affects Versions: 1.7.0.CR3
> Reporter: Martin Choma
> Priority: Optional
> Fix For: 1.8.0.CR1
>
>
> Test PrincipalMappingSuiteChild#testDnToDnVerify failed (1:1000) on read timeout, which is 60 s. So probably prolonging timeout is not an option. Maybe solution is implement some kind of retry?
> Error Message
> ELY01108: Ldap-backed realm identity search failed
> Stacktrace
> {noformat}
> org.wildfly.security.auth.server.RealmUnavailableException: ELY01108: Ldap-backed realm identity search failed
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapSearch.search(LdapSecurityRealm.java:1141)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:688)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:669)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.exists(LdapSecurityRealm.java:624)
> at org.wildfly.security.ldap.PrincipalMappingSuiteChild.testDnToDnVerify(PrincipalMappingSuiteChild.java:132)
> at org.wildfly.security.ldap.DirContextFactoryRule$1.evaluate(DirContextFactoryRule.java:218)
> Caused by: javax.naming.NamingException: LDAP response read timed out, timeout used:60000ms.; remaining name 'uid=nobody,dc=elytron,dc=wildfly,dc=org'
> at java.naming/com.sun.jndi.ldap.Connection.readReply(Connection.java:443)
> at java.naming/com.sun.jndi.ldap.LdapClient.processReply(LdapClient.java:888)
> at java.naming/com.sun.jndi.ldap.LdapClient.compare(LdapClient.java:1168)
> at java.naming/com.sun.jndi.ldap.LdapCtx.compare(LdapCtx.java:2117)
> at java.naming/com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1840)
> at java.naming/com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1770)
> at java.naming/com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1787)
> at java.naming/com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:418)
> at java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:396)
> at java.naming/javax.naming.directory.InitialDirContext.search(InitialDirContext.java:297)
> at org.wildfly.security.auth.realm.ldap.DelegatingLdapContext.search(DelegatingLdapContext.java:336)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapSearch.searchWithPagination(LdapSecurityRealm.java:1161)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapSearch.search(LdapSecurityRealm.java:1038)
> ... 5 more
> {noformat}
> {noformat}
> 21:11:54,245 DEBUG (main) [org.wildfly.security] <LdapSecurityRealm.java:695> Identity for principal [uid=nobody,dc=elytron,dc=wildfly,dc=org] not found.
> 21:11:54,245 DEBUG (main) [org.wildfly.security] <LdapSecurityRealm.java:628> Principal [uid=nobody,dc=elytron,dc=wildfly,dc=org] does not exists.
> 21:11:54,248 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:463> Context [javax.naming.ldap.InitialLdapContext@2dba05b1] was closed. Connection closed or just returned to the pool.
> 21:11:54,249 DEBUG (main) [org.wildfly.security] <LdapSecurityRealm.java:189> Obtaining lock for identity [uid=PlainUser,dc=elytron,dc=wildfly,dc=org]...
> 21:11:54,249 DEBUG (main) [org.wildfly.security] <LdapSecurityRealm.java:197> Obtained lock for identity [uid=PlainUser,dc=elytron,dc=wildfly,dc=org].
> 21:11:54,249 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:427> Creating [class javax.naming.directory.InitialDirContext] with environment:
> 21:11:54,249 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.security.credentials] with value [******]
> 21:11:54,249 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.ldap.factory.socket] with value [org.wildfly.security.auth.realm.ldap.ThreadLocalSSLSocketFactory]
> 21:11:54,249 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.security.authentication] with value [simple]
> 21:11:54,249 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.provider.url] with value [ldap://localhost:11390/]
> 21:11:54,249 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [com.sun.jndi.ldap.read.timeout] with value [60000]
> 21:11:54,250 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [com.sun.jndi.ldap.connect.timeout] with value [5000]
> 21:11:54,250 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.security.principal] with value [uid=server,dc=elytron,dc=wildfly,dc=org]
> 21:11:54,250 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.referral] with value [ignore]
> 21:11:54,250 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.factory.initial] with value [com.sun.jndi.ldap.LdapCtxFactory]
> 21:11:54,300 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:444> [javax.naming.ldap.InitialLdapContext@31b0f02] successfully created. Connection established to LDAP server.
> 21:11:54,300 DEBUG (main) [org.wildfly.security] <LdapSecurityRealm.java:673> Trying to create identity for principal [uid=PlainUser,dc=elytron,dc=wildfly,dc=org].
> 21:11:54,300 DEBUG (main) [org.wildfly.security] <LdapSecurityRealm.java:1027> Executing search [(uid={0})] in context [uid=PlainUser,dc=elytron,dc=wildfly,dc=org] with arguments [PlainUser]. Returning attributes are [null]. Binary attributes are [null].
> 21:11:54,302 DEBUG (main) [org.wildfly.security] <LdapSecurityRealm.java:1096> Found entry [uid=PlainUser,dc=elytron,dc=wildfly,dc=org].
> 21:11:54,302 DEBUG (main) [org.wildfly.security] <LdapSecurityRealm.java:692> Identity for principal [uid=PlainUser,dc=elytron,dc=wildfly,dc=org] found at [uid=PlainUser,dc=elytron,dc=wildfly,dc=org].
> 21:11:54,303 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:463> Context [javax.naming.ldap.InitialLdapContext@31b0f02] was closed. Connection closed or just returned to the pool.
> 21:11:54,303 DEBUG (main) [org.wildfly.security] <LdapSecurityRealm.java:189> Obtaining lock for identity [uid=nobody,dc=elytron,dc=wildfly,dc=org]...
> 21:11:54,303 DEBUG (main) [org.wildfly.security] <LdapSecurityRealm.java:197> Obtained lock for identity [uid=nobody,dc=elytron,dc=wildfly,dc=org].
> 21:11:54,303 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:427> Creating [class javax.naming.directory.InitialDirContext] with environment:
> 21:11:54,304 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.security.credentials] with value [******]
> 21:11:54,304 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.ldap.factory.socket] with value [org.wildfly.security.auth.realm.ldap.ThreadLocalSSLSocketFactory]
> 21:11:54,304 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.security.authentication] with value [simple]
> 21:11:54,304 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.provider.url] with value [ldap://localhost:11390/]
> 21:11:54,304 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [com.sun.jndi.ldap.read.timeout] with value [60000]
> 21:11:54,304 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [com.sun.jndi.ldap.connect.timeout] with value [5000]
> 21:11:54,304 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.security.principal] with value [uid=server,dc=elytron,dc=wildfly,dc=org]
> 21:11:54,304 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.referral] with value [ignore]
> 21:11:54,304 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.factory.initial] with value [com.sun.jndi.ldap.LdapCtxFactory]
> 21:11:54,354 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:444> [javax.naming.ldap.InitialLdapContext@19ae2ee5] successfully created. Connection established to LDAP server.
> 21:11:54,354 DEBUG (main) [org.wildfly.security] <LdapSecurityRealm.java:673> Trying to create identity for principal [uid=nobody,dc=elytron,dc=wildfly,dc=org].
> 21:11:54,354 DEBUG (main) [org.wildfly.security] <LdapSecurityRealm.java:1027> Executing search [(uid={0})] in context [uid=nobody,dc=elytron,dc=wildfly,dc=org] with arguments [nobody]. Returning attributes are [null]. Binary attributes are [null].
> 21:12:54,358 WARN (pool-3-thread-2) [org.apache.directory.server.ldap.LdapSession] <LdapSession.java:254> AbandonableRequest with messageId 2 not found in outstandingRequests.
> 21:12:54,364 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:463> Context [javax.naming.ldap.InitialLdapContext@19ae2ee5] was closed. Connection closed or just returned to the pool.
> 21:12:54,368 INFO (pool-3-thread-2) [org.apache.directory.server.ldap.handlers.LdapRequestHandler] <LdapRequestHandler.java:131> ignoring the message MessageType : UNBIND_REQUEST
> Message ID : 4
> UnBind Requestorg.apache.directory.api.ldap.model.message.UnbindRequestImpl@949b7f8 ManageDsaITImpl Control
> Type OID : '2.16.840.1.113730.3.4.2'
> Criticality : 'false'
> '
> received from null session
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (WFCORE-3796) Incorrect Elytron permission class-name or module should throw exception
by Ilia Vassilev (Jira)
[ https://issues.jboss.org/browse/WFCORE-3796?page=com.atlassian.jira.plugi... ]
Ilia Vassilev commented on WFCORE-3796:
---------------------------------------
Requirement [1] was introduced with https://issues.jboss.org/browse/WFWIP-9 which has been implemented in https://issues.jboss.org/browse/WFCORE-3596 (commit [2]). In result of that change when non-existent class-name is added an exception will be thrown at runtime. I've verified that when the following is added to Elytron configuration, exception [3] occurs.
{code}
<constant-permission-mapper name="cpm">
<permission class-name="org.wildfly.security.auth.permission.LoginPermission"/>
<permission class-name="WrongName"/>
</constant-permission-mapper>
{code}
Same exception occurs for permission-sets
{code}
<permission-sets>
<permission-set name="login-permission">
<permission class-name="org.wildfly.security.auth.permission.LoginPermission"/>
</permission-set>
<permission-set name="default-permissions">
<permission class-name="org.wildfly.extension.batch.jberet.deployment.BatchPermission" module="org.wildfly.extension.batch.jberet" target-name="*"/>
<permission class-name="org.wildfly.transaction.client.RemoteTransactionPermission" module="org.wildfly.transaction.client"/>
<permission class-name="org.jboss.ejb.client.RemoteEJBPermission" module="org.jboss.ejb-client"/>
<permission class-name="WrongName"/>
</permission-set>
</permission-sets>
{code}
[1]
"When non-existent class-name or module (e.g. when there is a typo) is added to any Elytron permission mapper (constant-permission-mapper or simple-permission-mapper) then exception should be thrown. Otherwise it can result to situation when due to a typo some permission is granted to any identity instead of denying it - when permission in used on 'deny' side."
[2] https://github.com/wildfly/wildfly-core/commit/1266d9aec57abb409a7c5dce3f...
[3]
{code}
17:19:39,939 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service org.wildfly.security.permission-set.default-permissions: org.jboss.msc.service.StartException in service org.wildfly.security.permission-set.default-permissions: WFLYELY00038: Could not load permission class 'WrongName'
at org.wildfly.extension.elytron.PermissionMapperDefinitions.createPermission(PermissionMapperDefinitions.java:432)
at org.wildfly.extension.elytron.PermissionMapperDefinitions.createPermissions(PermissionMapperDefinitions.java:410)
at org.wildfly.extension.elytron.PermissionSetDefinition$1.lambda$getValueSupplier$0(PermissionSetDefinition.java:75)
at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1738)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1700)
at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1558)
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:1364)
at java.lang.Thread.run(Thread.java:748)
17:19:39,975 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "elytron"),
("permission-set" => "default-permissions")
]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.security.permission-set.default-permissions" => "WFLYELY00038: Could not load permission class 'WrongName'"}}
{code}
> Incorrect Elytron permission class-name or module should throw exception
> ------------------------------------------------------------------------
>
> Key: WFCORE-3796
> URL: https://issues.jboss.org/browse/WFCORE-3796
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 5.0.0.Alpha4
> Reporter: Ondrej Lukas
> Assignee: Ilia Vassilev
> Priority: Major
>
> When non-existent class-name or module (e.g. when there is a typo) is added to any Elytron permission mapper (constant-permission-mapper or simple-permission-mapper) then exception should be thrown. Otherwise it can result to situation when due to a typo some permission is granted to any identity instead of denying it - when permission in used on 'deny' side.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (DROOLS-3192) [DMN Designer] Undefined Expression Grid: Re-design 'decision logic' selector
by Liz Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-3192?page=com.atlassian.jira.plugi... ]
Liz Clayton commented on DROOLS-3192:
-------------------------------------
Thanks [~karreiro] :)
> [DMN Designer] Undefined Expression Grid: Re-design 'decision logic' selector
> -----------------------------------------------------------------------------
>
> Key: DROOLS-3192
> URL: https://issues.jboss.org/browse/DROOLS-3192
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Priority: Major
> Labels: drools-tools
> Attachments: logic_pop-over.png
>
>
> * The {{UndefinedExpression}} grid "decision logic" selector (menu to select logic type: Literal expression, Context, etc.) currently uses a double-left mouse click to launch the menu. Given the menu is closer in spirit (and intention) to a popover menu - to provide a more consistent and predictable user experience it would be preferable to launch this menu on a single, left mouse click (will be covered by DROOLS-2910).
> * Re-design the {{UndefinedExpression}} grid "decision logic" selector.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (WFLY-11292) Legacy EJB Client: High fail rate
by tommaso borgato (Jira)
[ https://issues.jboss.org/browse/WFLY-11292?page=com.atlassian.jira.plugin... ]
tommaso borgato commented on WFLY-11292:
----------------------------------------
[~rachmato] I attached the logs for the run with 10 clients ({{logs-10clients.zip}}): there is just one error, do you want a run with some more clients?
> Legacy EJB Client: High fail rate
> ---------------------------------
>
> Key: WFLY-11292
> URL: https://issues.jboss.org/browse/WFLY-11292
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 15.0.0.Alpha1
> Reporter: tommaso borgato
> Assignee: Flavia Rainone
> Priority: Blocker
> Attachments: jboss-ejb-client.properties, logs-10clients.zip, logs.zip
>
>
> This bug is being filed as Blocker because we are observing and elevated fail rate: roughly a thousand each run for (about 0.3%).
> h2. WildFly Built from master branch on 6 Nov 2018
> With this WildFly version (client org.jboss:jboss-ejb-client-legacy:3.0.2.Final-redhat-1) in a scenario with 4 clustered nodes where nodes are failed via jboss shut-down / restart: after node 1 of 4 is shut-down, a a series of errors start on the client side the yield to 1097 errors on a total of 340218 samples;
> find [here|https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/...] the complete logs;
> the start of client errors is here:
> {noformat}
> 2018/11/07 05:28:51:255 EST [INFO ][TestController] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Failing node 0 (perf18)
> 2018/11/07 05:28:51:270 EST [INFO ][StatsRunner] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Total: Sessions: 2000, active: 2000, samples: 5118, throughput: 511.7 samples/s, bandwidth: 0.0 MB/s, response min: 1 ms, mean: 1 ms, max: 54 ms, sampling errors: 0, unhealthy samples: 0, valid samples: 5118 (100%)
> 2018/11/07 05:28:51:270 EST [INFO ][StatsRunner] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - unknown-node: Sessions: 2000, active: 2000, samples: 5118, throughput: 511.7 samples/s, bandwidth: 0.0 MB/s, response min: 1 ms, mean: 1 ms, max: 54 ms, sampling errors: 0, unhealthy samples: 0, valid samples: 5118 (100%)
> 05:28:53,257 INFO [org.jboss.ejb.client.remoting] (Remoting "config-based-ejb-client-endpoint" task-2) EJBCLIENT000016: Channel Channel ID c540daf7 (outbound) of Remoting connection 4ed5523c to perf18/10.16.90.54:8080 of endpoint "config-based-ejb-client-endpoint" <664ac6d5> can no longer process messages
> 05:28:53,277 ERROR [org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver] (Remoting "config-based-ejb-client-endpoint" task-2) Failed to open channel for context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext@3cd51445, receiver=Remoting connection EJB receiver [connection=org.jboss.ejb.client.remoting.ConnectionPool$PooledConnection(a)302066a5,channel=jboss.ejb,nodename=perf18]}
> org.jboss.remoting3.NotOpenException: Cannot open new channel because close was initiated
> at org.jboss.remoting3.remote.RemoteConnectionHandler.handleOutboundChannelOpen(RemoteConnectionHandler.java:198)
> at org.jboss.remoting3.remote.RemoteConnectionHandler.open(RemoteConnectionHandler.java:335)
> at org.jboss.remoting3.ConnectionImpl.openChannel(ConnectionImpl.java:109)
> at org.jboss.ejb.client.remoting.ConnectionPool$PooledConnection.openChannel(ConnectionPool.java:292)
> at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.associate(RemotingConnectionEJBReceiver.java:180)
> at org.jboss.ejb.client.EJBClientContext.registerEJBReceiver(EJBClientContext.java:399)
> at org.jboss.ejb.client.EJBClientContext.registerEJBReceiver(EJBClientContext.java:349)
> at org.jboss.ejb.client.remoting.EJBClientContextConnectionReconnectHandler.reconnect(EJBClientContextConnectionReconnectHandler.java:67)
> at org.jboss.ejb.client.EJBClientContext$ReconnectAttempt.run(EJBClientContext.java:1474)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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}
> h2. WildFly Built from master branch on 7 Nov 2018
> Same situation.
> find [here|https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/...] the complete logs;
> the start of client errors is here:
> {noformat}
> 2018/11/07 09:23:22:916 EST [INFO ][TestController] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Failing node 0 (perf18)
> 2018/11/07 09:23:22:930 EST [INFO ][StatsRunner] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Total: Sessions: 2000, active: 2000, samples: 5125, throughput: 512.4 samples/s, bandwidth: 0.0 MB/s, response min: 1 ms, mean: 2 ms, max: 32 ms, sampling errors: 0, unhealthy samples: 0, valid samples: 5125 (100%)
> 2018/11/07 09:23:22:930 EST [INFO ][StatsRunner] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - unknown-node: Sessions: 2000, active: 2000, samples: 5125, throughput: 512.4 samples/s, bandwidth: 0.0 MB/s, response min: 1 ms, mean: 2 ms, max: 32 ms, sampling errors: 0, unhealthy samples: 0, valid samples: 5125 (100%)
> 09:23:24,924 INFO [org.jboss.ejb.client.remoting] (Remoting "config-based-ejb-client-endpoint" task-4) EJBCLIENT000016: Channel Channel ID d940c707 (outbound) of Remoting connection 73cfdf01 to perf18/10.16.90.54:8080 of endpoint "config-based-ejb-client-endpoint" <7501616b> can no longer process messages
> 09:23:24,949 ERROR [org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver] (Remoting "config-based-ejb-client-endpoint" task-6) Failed to open channel for context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext@56248025, receiver=Remoting connection EJB receiver [connection=org.jboss.ejb.client.remoting.ConnectionPool$PooledConnection(a)5269f48d,channel=jboss.ejb,nodename=perf18]}
> org.jboss.remoting3.NotOpenException: Cannot open new channel because close was initiated
> at org.jboss.remoting3.remote.RemoteConnectionHandler.handleOutboundChannelOpen(RemoteConnectionHandler.java:198)
> at org.jboss.remoting3.remote.RemoteConnectionHandler.open(RemoteConnectionHandler.java:335)
> at org.jboss.remoting3.ConnectionImpl.openChannel(ConnectionImpl.java:109)
> at org.jboss.ejb.client.remoting.ConnectionPool$PooledConnection.openChannel(ConnectionPool.java:292)
> at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.associate(RemotingConnectionEJBReceiver.java:180)
> at org.jboss.ejb.client.EJBClientContext.registerEJBReceiver(EJBClientContext.java:399)
> at org.jboss.ejb.client.EJBClientContext.registerEJBReceiver(EJBClientContext.java:349)
> at org.jboss.ejb.client.remoting.EJBClientContextConnectionReconnectHandler.reconnect(EJBClientContextConnectionReconnectHandler.java:67)
> at org.jboss.ejb.client.EJBClientContext$ReconnectAttempt.run(EJBClientContext.java:1474)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (WFLY-11292) Legacy EJB Client: High fail rate
by tommaso borgato (Jira)
[ https://issues.jboss.org/browse/WFLY-11292?page=com.atlassian.jira.plugin... ]
tommaso borgato updated WFLY-11292:
-----------------------------------
Attachment: logs-10clients.zip
> Legacy EJB Client: High fail rate
> ---------------------------------
>
> Key: WFLY-11292
> URL: https://issues.jboss.org/browse/WFLY-11292
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 15.0.0.Alpha1
> Reporter: tommaso borgato
> Assignee: Flavia Rainone
> Priority: Blocker
> Attachments: jboss-ejb-client.properties, logs-10clients.zip, logs.zip
>
>
> This bug is being filed as Blocker because we are observing and elevated fail rate: roughly a thousand each run for (about 0.3%).
> h2. WildFly Built from master branch on 6 Nov 2018
> With this WildFly version (client org.jboss:jboss-ejb-client-legacy:3.0.2.Final-redhat-1) in a scenario with 4 clustered nodes where nodes are failed via jboss shut-down / restart: after node 1 of 4 is shut-down, a a series of errors start on the client side the yield to 1097 errors on a total of 340218 samples;
> find [here|https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/...] the complete logs;
> the start of client errors is here:
> {noformat}
> 2018/11/07 05:28:51:255 EST [INFO ][TestController] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Failing node 0 (perf18)
> 2018/11/07 05:28:51:270 EST [INFO ][StatsRunner] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Total: Sessions: 2000, active: 2000, samples: 5118, throughput: 511.7 samples/s, bandwidth: 0.0 MB/s, response min: 1 ms, mean: 1 ms, max: 54 ms, sampling errors: 0, unhealthy samples: 0, valid samples: 5118 (100%)
> 2018/11/07 05:28:51:270 EST [INFO ][StatsRunner] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - unknown-node: Sessions: 2000, active: 2000, samples: 5118, throughput: 511.7 samples/s, bandwidth: 0.0 MB/s, response min: 1 ms, mean: 1 ms, max: 54 ms, sampling errors: 0, unhealthy samples: 0, valid samples: 5118 (100%)
> 05:28:53,257 INFO [org.jboss.ejb.client.remoting] (Remoting "config-based-ejb-client-endpoint" task-2) EJBCLIENT000016: Channel Channel ID c540daf7 (outbound) of Remoting connection 4ed5523c to perf18/10.16.90.54:8080 of endpoint "config-based-ejb-client-endpoint" <664ac6d5> can no longer process messages
> 05:28:53,277 ERROR [org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver] (Remoting "config-based-ejb-client-endpoint" task-2) Failed to open channel for context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext@3cd51445, receiver=Remoting connection EJB receiver [connection=org.jboss.ejb.client.remoting.ConnectionPool$PooledConnection(a)302066a5,channel=jboss.ejb,nodename=perf18]}
> org.jboss.remoting3.NotOpenException: Cannot open new channel because close was initiated
> at org.jboss.remoting3.remote.RemoteConnectionHandler.handleOutboundChannelOpen(RemoteConnectionHandler.java:198)
> at org.jboss.remoting3.remote.RemoteConnectionHandler.open(RemoteConnectionHandler.java:335)
> at org.jboss.remoting3.ConnectionImpl.openChannel(ConnectionImpl.java:109)
> at org.jboss.ejb.client.remoting.ConnectionPool$PooledConnection.openChannel(ConnectionPool.java:292)
> at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.associate(RemotingConnectionEJBReceiver.java:180)
> at org.jboss.ejb.client.EJBClientContext.registerEJBReceiver(EJBClientContext.java:399)
> at org.jboss.ejb.client.EJBClientContext.registerEJBReceiver(EJBClientContext.java:349)
> at org.jboss.ejb.client.remoting.EJBClientContextConnectionReconnectHandler.reconnect(EJBClientContextConnectionReconnectHandler.java:67)
> at org.jboss.ejb.client.EJBClientContext$ReconnectAttempt.run(EJBClientContext.java:1474)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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}
> h2. WildFly Built from master branch on 7 Nov 2018
> Same situation.
> find [here|https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/...] the complete logs;
> the start of client errors is here:
> {noformat}
> 2018/11/07 09:23:22:916 EST [INFO ][TestController] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Failing node 0 (perf18)
> 2018/11/07 09:23:22:930 EST [INFO ][StatsRunner] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Total: Sessions: 2000, active: 2000, samples: 5125, throughput: 512.4 samples/s, bandwidth: 0.0 MB/s, response min: 1 ms, mean: 2 ms, max: 32 ms, sampling errors: 0, unhealthy samples: 0, valid samples: 5125 (100%)
> 2018/11/07 09:23:22:930 EST [INFO ][StatsRunner] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - unknown-node: Sessions: 2000, active: 2000, samples: 5125, throughput: 512.4 samples/s, bandwidth: 0.0 MB/s, response min: 1 ms, mean: 2 ms, max: 32 ms, sampling errors: 0, unhealthy samples: 0, valid samples: 5125 (100%)
> 09:23:24,924 INFO [org.jboss.ejb.client.remoting] (Remoting "config-based-ejb-client-endpoint" task-4) EJBCLIENT000016: Channel Channel ID d940c707 (outbound) of Remoting connection 73cfdf01 to perf18/10.16.90.54:8080 of endpoint "config-based-ejb-client-endpoint" <7501616b> can no longer process messages
> 09:23:24,949 ERROR [org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver] (Remoting "config-based-ejb-client-endpoint" task-6) Failed to open channel for context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext@56248025, receiver=Remoting connection EJB receiver [connection=org.jboss.ejb.client.remoting.ConnectionPool$PooledConnection(a)5269f48d,channel=jboss.ejb,nodename=perf18]}
> org.jboss.remoting3.NotOpenException: Cannot open new channel because close was initiated
> at org.jboss.remoting3.remote.RemoteConnectionHandler.handleOutboundChannelOpen(RemoteConnectionHandler.java:198)
> at org.jboss.remoting3.remote.RemoteConnectionHandler.open(RemoteConnectionHandler.java:335)
> at org.jboss.remoting3.ConnectionImpl.openChannel(ConnectionImpl.java:109)
> at org.jboss.ejb.client.remoting.ConnectionPool$PooledConnection.openChannel(ConnectionPool.java:292)
> at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.associate(RemotingConnectionEJBReceiver.java:180)
> at org.jboss.ejb.client.EJBClientContext.registerEJBReceiver(EJBClientContext.java:399)
> at org.jboss.ejb.client.EJBClientContext.registerEJBReceiver(EJBClientContext.java:349)
> at org.jboss.ejb.client.remoting.EJBClientContextConnectionReconnectHandler.reconnect(EJBClientContextConnectionReconnectHandler.java:67)
> at org.jboss.ejb.client.EJBClientContext$ReconnectAttempt.run(EJBClientContext.java:1474)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (WFLY-11292) Legacy EJB Client: High fail rate
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/WFLY-11292?page=com.atlassian.jira.plugin... ]
Radoslav Husar commented on WFLY-11292:
---------------------------------------
> Need to find out why these channels are being closed.
[~rachmato] The channel is being closed because the server is shutting down. These are logs from the failover tests using graceful shutdown. For instance, the message from your comment above happens when the node 2 (wildfly-service-2) is being shut down.
> Legacy EJB Client: High fail rate
> ---------------------------------
>
> Key: WFLY-11292
> URL: https://issues.jboss.org/browse/WFLY-11292
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 15.0.0.Alpha1
> Reporter: tommaso borgato
> Assignee: Flavia Rainone
> Priority: Blocker
> Attachments: jboss-ejb-client.properties, logs.zip
>
>
> This bug is being filed as Blocker because we are observing and elevated fail rate: roughly a thousand each run for (about 0.3%).
> h2. WildFly Built from master branch on 6 Nov 2018
> With this WildFly version (client org.jboss:jboss-ejb-client-legacy:3.0.2.Final-redhat-1) in a scenario with 4 clustered nodes where nodes are failed via jboss shut-down / restart: after node 1 of 4 is shut-down, a a series of errors start on the client side the yield to 1097 errors on a total of 340218 samples;
> find [here|https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/...] the complete logs;
> the start of client errors is here:
> {noformat}
> 2018/11/07 05:28:51:255 EST [INFO ][TestController] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Failing node 0 (perf18)
> 2018/11/07 05:28:51:270 EST [INFO ][StatsRunner] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Total: Sessions: 2000, active: 2000, samples: 5118, throughput: 511.7 samples/s, bandwidth: 0.0 MB/s, response min: 1 ms, mean: 1 ms, max: 54 ms, sampling errors: 0, unhealthy samples: 0, valid samples: 5118 (100%)
> 2018/11/07 05:28:51:270 EST [INFO ][StatsRunner] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - unknown-node: Sessions: 2000, active: 2000, samples: 5118, throughput: 511.7 samples/s, bandwidth: 0.0 MB/s, response min: 1 ms, mean: 1 ms, max: 54 ms, sampling errors: 0, unhealthy samples: 0, valid samples: 5118 (100%)
> 05:28:53,257 INFO [org.jboss.ejb.client.remoting] (Remoting "config-based-ejb-client-endpoint" task-2) EJBCLIENT000016: Channel Channel ID c540daf7 (outbound) of Remoting connection 4ed5523c to perf18/10.16.90.54:8080 of endpoint "config-based-ejb-client-endpoint" <664ac6d5> can no longer process messages
> 05:28:53,277 ERROR [org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver] (Remoting "config-based-ejb-client-endpoint" task-2) Failed to open channel for context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext@3cd51445, receiver=Remoting connection EJB receiver [connection=org.jboss.ejb.client.remoting.ConnectionPool$PooledConnection(a)302066a5,channel=jboss.ejb,nodename=perf18]}
> org.jboss.remoting3.NotOpenException: Cannot open new channel because close was initiated
> at org.jboss.remoting3.remote.RemoteConnectionHandler.handleOutboundChannelOpen(RemoteConnectionHandler.java:198)
> at org.jboss.remoting3.remote.RemoteConnectionHandler.open(RemoteConnectionHandler.java:335)
> at org.jboss.remoting3.ConnectionImpl.openChannel(ConnectionImpl.java:109)
> at org.jboss.ejb.client.remoting.ConnectionPool$PooledConnection.openChannel(ConnectionPool.java:292)
> at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.associate(RemotingConnectionEJBReceiver.java:180)
> at org.jboss.ejb.client.EJBClientContext.registerEJBReceiver(EJBClientContext.java:399)
> at org.jboss.ejb.client.EJBClientContext.registerEJBReceiver(EJBClientContext.java:349)
> at org.jboss.ejb.client.remoting.EJBClientContextConnectionReconnectHandler.reconnect(EJBClientContextConnectionReconnectHandler.java:67)
> at org.jboss.ejb.client.EJBClientContext$ReconnectAttempt.run(EJBClientContext.java:1474)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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}
> h2. WildFly Built from master branch on 7 Nov 2018
> Same situation.
> find [here|https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/...] the complete logs;
> the start of client errors is here:
> {noformat}
> 2018/11/07 09:23:22:916 EST [INFO ][TestController] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Failing node 0 (perf18)
> 2018/11/07 09:23:22:930 EST [INFO ][StatsRunner] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Total: Sessions: 2000, active: 2000, samples: 5125, throughput: 512.4 samples/s, bandwidth: 0.0 MB/s, response min: 1 ms, mean: 2 ms, max: 32 ms, sampling errors: 0, unhealthy samples: 0, valid samples: 5125 (100%)
> 2018/11/07 09:23:22:930 EST [INFO ][StatsRunner] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - unknown-node: Sessions: 2000, active: 2000, samples: 5125, throughput: 512.4 samples/s, bandwidth: 0.0 MB/s, response min: 1 ms, mean: 2 ms, max: 32 ms, sampling errors: 0, unhealthy samples: 0, valid samples: 5125 (100%)
> 09:23:24,924 INFO [org.jboss.ejb.client.remoting] (Remoting "config-based-ejb-client-endpoint" task-4) EJBCLIENT000016: Channel Channel ID d940c707 (outbound) of Remoting connection 73cfdf01 to perf18/10.16.90.54:8080 of endpoint "config-based-ejb-client-endpoint" <7501616b> can no longer process messages
> 09:23:24,949 ERROR [org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver] (Remoting "config-based-ejb-client-endpoint" task-6) Failed to open channel for context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext@56248025, receiver=Remoting connection EJB receiver [connection=org.jboss.ejb.client.remoting.ConnectionPool$PooledConnection(a)5269f48d,channel=jboss.ejb,nodename=perf18]}
> org.jboss.remoting3.NotOpenException: Cannot open new channel because close was initiated
> at org.jboss.remoting3.remote.RemoteConnectionHandler.handleOutboundChannelOpen(RemoteConnectionHandler.java:198)
> at org.jboss.remoting3.remote.RemoteConnectionHandler.open(RemoteConnectionHandler.java:335)
> at org.jboss.remoting3.ConnectionImpl.openChannel(ConnectionImpl.java:109)
> at org.jboss.ejb.client.remoting.ConnectionPool$PooledConnection.openChannel(ConnectionPool.java:292)
> at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.associate(RemotingConnectionEJBReceiver.java:180)
> at org.jboss.ejb.client.EJBClientContext.registerEJBReceiver(EJBClientContext.java:399)
> at org.jboss.ejb.client.EJBClientContext.registerEJBReceiver(EJBClientContext.java:349)
> at org.jboss.ejb.client.remoting.EJBClientContextConnectionReconnectHandler.reconnect(EJBClientContextConnectionReconnectHandler.java:67)
> at org.jboss.ejb.client.EJBClientContext$ReconnectAttempt.run(EJBClientContext.java:1474)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months