[JBoss JIRA] (WFCORE-4668) Transaction recovery of remote ejb calls should not be using static Default AuthenticationContext
by Ondrej Chaloupka (Jira)
[ https://issues.redhat.com/browse/WFCORE-4668?page=com.atlassian.jira.plug... ]
Ondrej Chaloupka commented on WFCORE-4668:
------------------------------------------
hi [~mshikalw], I assume this is still issue. The trouble is that if authentication for remote EJB calls is used and transaction propagation happens then the recovery does not work properly until there is explicitly created a user with password for recovery processing. The user has to be created on the remote jboss node and the caller then defines the descriptor via `-Dwildfly.config.url`.
Unfortunately there is no easy standalone reproducer. The reason why this issue was created is the need for OpenShift configuration to define hardcoded user/password for any WFLY server which calls another server. This can be checked on OpenShift and WildFly s2i image.
For standalone reproducer - as I would check it - it could be to take a WFLY calling the other WFLY and disable silent authentication - forcing the remote call to use the authentication even the both WFLY servers are running on the local machine.
I think that the starting point could be the quickstart: https://github.com/wildfly/quickstart/blob/master/ejb-remote/
There is need to disable silent authentication (https://github.com/wildfly/quickstart/blob/20.0.0.Final/ejb-remote/client...).
If this all works then it's needed to create have an unfinished transaction on the second server (the server side) and check recovery to be started. There could be seen the failure until the specific setup of global default credentials are made.
Another chance could be to use the EAP QE crashrec test (https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/tests-transactions) where wildfly-config.xml would not be defined.
> Transaction recovery of remote ejb calls should not be using static Default AuthenticationContext
> -------------------------------------------------------------------------------------------------
>
> Key: WFCORE-4668
> URL: https://issues.redhat.com/browse/WFCORE-4668
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 10.0.0.Beta9
> Reporter: Ondrej Chaloupka
> Priority: Critical
>
> The issue WFCORE-4599 removed the `AuthenticationContext` would be static. This started to cause troubles for transaction recovery processing when remote ejb calls are invoked.
> The configuration that was used earlier for server to server ejb calls[1] (used with `-Dwildfly.config.url`) stopped working.
> It was possible to configure the default authentication context in the `standalone.xml` for the whole elytron subsystem (in way like [2]). But this change started to cause threads being stuck on execution of remote ejb calls in WFTC (somewhere here [3]).
> Because of that the WFCORE-4659 reverted back the functionality of static global authentication context. This was rather a bit workaround as the functionality should be rather working as Stuart pointed out
> {quote}
> - Add an explicit config to specify the authentication context used by transaction recovery
> - If this is not set fall back to the default authentication context that is used by deployments
> - If none of the above are set then the auth context should be empty
> {quote}
> [1]
> {code}
> <configuration>
> <authentication-client xmlns="urn:elytron:1.0">
> <authentication-rules>
> <rule use-configuration="jta">
> <match-abstract-type name="jta" authority="jboss"/>
> </rule>
> </authentication-rules>
> <authentication-configurations>
> <configuration name="jta">
> <sasl-mechanism-selector selector="DIGEST-MD5"/>
> <providers>
> <use-service-loader />
> </providers>
> <set-user-name name="ejb"/>
> <credentials>
> <clear-password password="ejb"/>
> </credentials>
> <set-mechanism-realm name="ApplicationRealm" />
> </configuration>
> </authentication-configurations>
> </authentication-client>
> </configuration>
> {code}
> [2]
> {code}
> <subsystem xmlns="urn:wildfly:elytron:8.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto" default-authentication-context="jta">
> <authentication-client>
> <authentication-configuration name="jta" authentication-name="ejb" realm="ApplicationRealm" sasl-mechanism-selector="DIGEST-MD5">
> <credential-reference clear-text="ejb"/>
> </authentication-configuration>
> <authentication-context name="jta">
> <match-rule match-abstract-type-authority="jboss" authentication-configuration="jta"/>
> </authentication-context>
> </authentication-client>
> {code}
> [3] https://github.com/wildfly/wildfly-transaction-client/blob/master/src/mai...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (JGRP-2492) TimeScheduler3.add() gets more expensive as the queue size grows
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2492?page=com.atlassian.jira.plugin... ]
Bela Ban edited comment on JGRP-2492 at 7/21/20 10:43 AM:
----------------------------------------------------------
The ultimate solution would be to reactive the hashwheel based timer, plus get rid of tasks which compute their execution delay every time ({{RecurringTask}}) they're executed: the random execution time could be computed *once* (at startup), and then be used as a fixed interval (or delay) for subsequent executions.
But this is not critical, as there are not many tasks in a timer at any given time, and a task executes every coupld of hundred millis...
was (Author: belaban):
The ultimate solution would be to reactive the hashwheel based timer, plus get rid of tasks which compute their execution delay every time (\{{RecurringTask}}) they're executed: the random execution time could be computed *once* (at startup), and then be used as a fixed interval (or delay) for subsequent executions.
> TimeScheduler3.add() gets more expensive as the queue size grows
> ----------------------------------------------------------------
>
> Key: JGRP-2492
> URL: https://issues.redhat.com/browse/JGRP-2492
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.2.4
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 5.0.0.Final
>
>
> {{TimeScheduler3.add()}} calls {{removeCancelledTasks()}}, which ends up calling {{DelayQueue.toArray()}} (because {{DelayQueue}} doesn't support directly iterating over its contents).
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (JGRP-2492) TimeScheduler3.add() gets more expensive as the queue size grows
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2492?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-2492:
--------------------------------
The ultimate solution would be to reactive the hashwheel based timer, plus get rid of tasks which compute their execution delay every time (\{{RecurringTask}}) they're executed: the random execution time could be computed *once* (at startup), and then be used as a fixed interval (or delay) for subsequent executions.
> TimeScheduler3.add() gets more expensive as the queue size grows
> ----------------------------------------------------------------
>
> Key: JGRP-2492
> URL: https://issues.redhat.com/browse/JGRP-2492
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.2.4
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 5.0.0.Final
>
>
> {{TimeScheduler3.add()}} calls {{removeCancelledTasks()}}, which ends up calling {{DelayQueue.toArray()}} (because {{DelayQueue}} doesn't support directly iterating over its contents).
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (JGRP-2492) TimeScheduler3.add() gets more expensive as the queue size grows
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2492?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-2492:
--------------------------------
The immediate solution is to remove {{removeCancelledTasks()}}; this is not as bad as it sounds, because:
* Tasks are continually removed from the head of the queue. If a task was cancelled, it will simply not get executed (but still removed)
* There are typically 7-9 tasks in the queue, so this is not a big issue
* On {{stop()}}, all tasks are cancelled and removed. Using {{toArray()}} here for iteration is not critical, as this is called before the program terminated anyway.
> TimeScheduler3.add() gets more expensive as the queue size grows
> ----------------------------------------------------------------
>
> Key: JGRP-2492
> URL: https://issues.redhat.com/browse/JGRP-2492
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.2.4
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 5.0.0.Final
>
>
> {{TimeScheduler3.add()}} calls {{removeCancelledTasks()}}, which ends up calling {{DelayQueue.toArray()}} (because {{DelayQueue}} doesn't support directly iterating over its contents).
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (WFCORE-3485) Misleading failure-description for capabilities in domain
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFCORE-3485?page=com.atlassian.jira.plug... ]
Brian Stansberry commented on WFCORE-3485:
------------------------------------------
[~mshikalw] I don't think this is an appropriate priority for right now. It is a minor issue that will require too much discussion with people who have critical tasks.
> Misleading failure-description for capabilities in domain
> ---------------------------------------------------------
>
> Key: WFCORE-3485
> URL: https://issues.redhat.com/browse/WFCORE-3485
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Affects Versions: 3.0.10.Final
> Reporter: Ondrej Lukas
> Priority: Minor
>
> In case when configuration in domain.xml tries to reference any capability from host.xml (or vice versa), but should not be able to reference it then it correctly fails, but there is failure-description which is misleading.
> Start domain with default domain.xml and host.xml and run following CLI command and see:
> {code}
> /profile=full/subsystem=elytron/http-authentication-factory=some-factory:add(http-server-mechanism-factory=global,security-domain=ManagementDomain)
> {
> "outcome" => "failed",
> "failure-description" => {"domain-failure-description" => "WFLYCTL0369: Required capabilities are not available:
> org.wildfly.security.security-domain.ManagementDomain in context 'profile=full'; Possible registration points for this capability:
> /host=master/subsystem=elytron/security-domain=*
> /profile=*/subsystem=elytron/security-domain=*"},
> "rolled-back" => true
> }
> {code}
> It should show only correct registration point {{/profile=\*/subsystem=elytron/security-domain=\*}}. It is misleading because ManagementDomain capability exists in {{/host=master/subsystem=elytron/security-domain=*}}.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (WFLY-13150) Create a Galleon layer for distributable web
by Paul Ferraro (Jira)
[ https://issues.redhat.com/browse/WFLY-13150?page=com.atlassian.jira.plugi... ]
Paul Ferraro commented on WFLY-13150:
-------------------------------------
The term "distributable", meaning "able to be distributed," was taken from the servlet spec (e.g. <distributable/> in web.xml).
IMO, "web-clustering-local" is confusing as the terms clustering and local are effectively antonyms.
> Create a Galleon layer for distributable web
> --------------------------------------------
>
> Key: WFLY-13150
> URL: https://issues.redhat.com/browse/WFLY-13150
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering, Web (Undertow)
> Reporter: Brian Stansberry
> Assignee: Paul Ferraro
> Priority: Major
> Fix For: 21.0.0.Beta1
>
>
> We have a web-clustering layer that provides the distributable-web subsystem and the related infinispan web session caching resources, configured for multi-server distributed sessions.
> We need a variant of this with infinispan configured for local caching.
> The WFLY-13099 standalone-microprofile.xml config should have this kind of setup; otherwise session sharing does not work . (A failure in org.jboss.as.test.clustering.cluster.web.shared.SharedSessionTestCase if the server uses a config without it shows this.) For WFLY-13099 I can work around this by adding the needed config stuff without a layer, but as everything else needed for those configs are from layers, it's better to use a layer in WF 20.
> Besides it's a good layer to have anyway. :)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (WFLY-12649) Deal with mixed-domain failures in the OpenJ9 jobs
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-12649?page=com.atlassian.jira.plugi... ]
Cheng Fang reopened WFLY-12649:
-------------------------------
12 tests in {{MixedDomainDeployment700TestCase}} still failed on Linux JDK 8 and JDK11 intermittently in totally unrelated PR. For instance,
https://github.com/wildfly/wildfly/pull/13399
https://github.com/wildfly/wildfly/pull/11711
{code}
#6186 at 17 Jul 08:32
Tests failed: 12 (12 new), passed: 6719, ignored: 107
13:11:40
org.jboss.as.test.integration.domain.mixed.eap700.MixedDomainDeployment700TestCase.testJsfWorks
13:11:40
java.lang.AssertionError: {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"other-server-group" => {"host" => {"slave" => {"server-one" => {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => {
"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.naming.context.java.module.test.test.DefaultJMSConnectionFactory is missing [jboss.naming.context.java.jboss.DefaultJMSConnectionFactory]"],
"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
"Services that were unable to start:" => [
"jboss.deployment.unit.\"test.war\".CdiValidatorFactoryService",
"jboss.deployment.unit.\"test.war\".WeldStartService",
"jboss.deployment.unit.\"test.war\".component.\"com.sun.faces.config.ConfigureListener\".START",
"jboss.deployment.unit.\"test.war\".component.\"com.sun.faces.config.ConfigureListener\".WeldInstantiator",
"jboss.deployment.unit.\"test.war\".component.\"javax.faces.webapp.FacetTag\".START",
"jboss.deployment.unit.\"test.war\".component.\"javax.faces.webapp.FacetTag\".WeldInstantiator",
"jboss.deployment.unit.\"test.war\".component.\"javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV\".START",
"jboss.deployment.unit.\"test.war\".component.\"javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV\".WeldInstantiator",
"jboss.deployment.unit.\"test.war\".component.\"javax.servlet.jsp.jstl.tlv.ScriptFreeTLV\".START",
"jboss.deployment.unit.\"test.war\".component.\"javax.servlet.jsp.jstl.tlv.ScriptFreeTLV\".WeldInstantiator",
"jboss.deployment.unit.\"test.war\".component.\"org.jboss.weld.servlet.WeldInitialListener\".START",
"jboss.deployment.unit.\"test.war\".component.\"org.jboss.weld.servlet.WeldInitialListener\".WeldInstantiator",
"jboss.deployment.unit.\"test.war\".component.\"org.jboss.weld.servlet.WeldTerminalListener\".START",
"jboss.deployment.unit.\"test.war\".component.\"org.jboss.weld.servlet.WeldTerminalListener\".WeldInstantiator",
"jboss.deployment.unit.\"test.war\".deploymentCompleteService",
"jboss.deployment.unit.\"test.war\".jndiDependencyService",
"jboss.undertow.deployment.default-server.default-host./test",
"jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService"
],
"Services that may be the cause:" => [
"jboss.clustering.singleton.server.default",
"jboss.naming.context.java.jboss.DefaultJMSConnectionFactory"
]
}
}}}}}}}}}
13:11:40
java.lang.AssertionError:
{"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"other-server-group" => {"host" => {"slave" => {"server-one" => {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => {
"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.naming.context.java.module.test.test.DefaultJMSConnectionFactory is missing [jboss.naming.context.java.jboss.DefaultJMSConnectionFactory]"],
{code}
> Deal with mixed-domain failures in the OpenJ9 jobs
> --------------------------------------------------
>
> Key: WFLY-12649
> URL: https://issues.redhat.com/browse/WFLY-12649
> Project: WildFly
> Issue Type: Task
> Components: Management, Test Suite
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Minor
> Labels: OpenJ9
> Fix For: 19.0.0.Beta1, 19.0.0.Final
>
>
> The nightly CI jobs against OpenJ9 have 12 failures in the mixed-domain testsuite due to problems starting the embedded messaging broker on an EAP 7.0.0 Host.
> https://ci.wildfly.org/viewLog.html?buildId=170906&tab=buildResultsDiv&bu...
> I think this relates to https://issues.apache.org/jira/browse/ARTEMIS-444 and JBEAP-1887. The latter is resolved with a Fix Version of 7.0.2.CR1 but our mixed domain tests are not able to test against CPs.
> So task here is to work around this somehow.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months