June 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-11214) Periodic recovery does not recover XAResource after jvm crash when agroal subsystem is used

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-11214?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-11214: ------------------------------------ Fix Version/s: 18.0.0.Beta1 (was: 17.0.0.Final) > Periodic recovery does not recover XAResource after jvm crash when agroal subsystem is used > ------------------------------------------------------------------------------------------- > > Key: WFLY-11214 > URL: https://issues.jboss.org/browse/WFLY-11214 > Project: WildFly > Issue Type: Bug > Components: Agroal, Transactions > Reporter: Ivan Straka > Assignee: Luis Barreiro > Priority: Critical > Fix For: 18.0.0.Beta1 > > Attachments: JPACrashRecoveryTestCase_commitHaltSecond_jta_server.log, JPACrashRecoveryTestCase_commitHaltSecond_jts_server.log > > > Scenario: > Halts server at commit phase ... > # enlist TestXA resource > # enlist XA resource > # prepare TestXA resource > # prepare XA resource > # commit Test XA resource > # JVM crash > # recovery started > # commit XA resource > Periodic recovery does not recover xa resource. It looks like agroal subsystem does not register xa resource to xa recovery module. > Test outcome: > {code:java} > Running org.jboss.as.test.jbossts.crashrec.test.JPACrashRecoveryTestCase > Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 109.002 sec <<< FAILURE! - in org.jboss.as.test.jbossts.crashrec.test.JPACrashRecoveryTestCase > commitHaltSecond(org.jboss.as.test.jbossts.crashrec.test.JPACrashRecoveryTestCase) Time elapsed: 102.976 sec <<< FAILURE! > java.lang.AssertionError: Incorrect data in database after crash recovery. expected:<2> but was:<1> > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:834) > at org.junit.Assert.assertEquals(Assert.java:645) > at org.jboss.as.test.jbossts.crashrec.test.JPABaseCrashRecoveryTestCase.checkAfterTestExecution(JPABaseCrashRecoveryTestCase.java:150) > at org.jboss.as.test.jbossts.crashrec.test.TestBaseCrashRecovery.commitHaltTest(TestBaseCrashRecovery.java:485) > at org.jboss.as.test.jbossts.crashrec.test.TestBaseCrashRecovery.commitHaltSecond(TestBaseCrashRecovery.java:418) > at org.jboss.as.test.jbossts.crashrec.test.JPACrashRecoveryTestCase.commitHaltSecond(JPACrashRecoveryTestCase.java:76) > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-12051) Elytron: Ability to load the attributes of an identity from multiple sources

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-12051?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-12051: ------------------------------------ Fix Version/s: 18.0.0.Beta1 (was: 17.0.0.Final) > Elytron: Ability to load the attributes of an identity from multiple sources > ---------------------------------------------------------------------------- > > Key: WFLY-12051 > URL: https://issues.jboss.org/browse/WFLY-12051 > Project: WildFly > Issue Type: Feature Request > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 18.0.0.Beta1 > > > In previous versions a {{security-domain}} was used to merge or add roles from multiple repositories. For example the roles for the users were obtained from two different ldaps and a database. All the roles were merged and the final authenticated principal belonged to all of them. The old picketbox subsystem used stacking of login modules (and password) to implement this feature. This use-case is not rare among the customers. > This issue is avoiding migrations from the old security subsystem to elytron. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-12045) Some clustering test cases do not close JNDI InitialContext between tests

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-12045?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-12045: ------------------------------------ Fix Version/s: 18.0.0.Beta1 (was: 17.0.0.Final) > Some clustering test cases do not close JNDI InitialContext between tests > ------------------------------------------------------------------------- > > Key: WFLY-12045 > URL: https://issues.jboss.org/browse/WFLY-12045 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Affects Versions: 17.0.0.Alpha1 > Reporter: Richard Achmatowicz > Assignee: Richard Achmatowicz > Priority: Major > Fix For: 18.0.0.Beta1 > > > The test case RemoteStatelessFailoverTestCase makes use of the helper class EJBRemoteDirectory to lookup JNDI names for beans in test cases. The EJB client then uses the resulting proxies to make invocations on the beans. > This helper class is defined statically and initialized before any of the test cases run. Consequenty, the InitialContext created by the helper class is used across multiple test cases. The effect of this is that all of the proxies used in the test case are created from the same InitialContext. Consequently, they share a RemoteEJBDiscoveryProvider instance which is a class used to maintain information about server and module deployments which the EJB client references during invocation to find a suitable target for the invocation. > This means that any server startup or shutdown activities are passed from one test case to another. This is not wanted as crash failures or shutdowns in one test will contaminate the next test, and this is exactly what is happening in a particular failure of this test. > If your test class only involves one test, then static usage will work, but probably not recommended. > UPDATE: This problem is present in a few other test cases, so I have updated them. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-11958) Eliminate deprecated DeploymentPhaseContext.addDependency() method usages

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-11958?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-11958: ------------------------------------ Fix Version/s: 18.0.0.Beta1 (was: 17.0.0.Final) > Eliminate deprecated DeploymentPhaseContext.addDependency() method usages > ------------------------------------------------------------------------- > > Key: WFLY-11958 > URL: https://issues.jboss.org/browse/WFLY-11958 > Project: WildFly > Issue Type: Enhancement > Components: EE, Transactions > Reporter: Richard Opalka > Assignee: Richard Opalka > Priority: Major > Fix For: 18.0.0.Beta1 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-11538) Opentracing - SmallRye - IllegalStateException

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-11538?page=com.atlassian.jira.plugin... ] Brian Stansberry reassigned WFLY-11538: --------------------------------------- Assignee: Jeff Mesnil > Opentracing - SmallRye - IllegalStateException > ---------------------------------------------- > > Key: WFLY-11538 > URL: https://issues.jboss.org/browse/WFLY-11538 > Project: WildFly > Issue Type: Bug > Components: MP OpenTracing > Affects Versions: 15.0.0.Final > Reporter: Alessandro Moscatelli > Assignee: Jeff Mesnil > Priority: Major > Fix For: 17.0.0.Final > > > Caused by: org.jboss.weld.exceptions.IllegalStateException: WELD-000713: Unable to inject ServletContext. None is associated with ModuleClassLoader for Module > The problem is the interaction between these two: > https://github.com/wildfly/wildfly/blob/master/microprofile/opentracing-s... > https://github.com/smallrye/smallrye-opentracing/blob/1.1.1/implementatio... > Those are delivered with Wildfly 15 out of the box in: > smallrye-opentracing-1.1.1.jar > wildfly-microprofile-opentracing-smallrye-15.0.0.Final.jar > I have an EAR with a EJB jar, WAR and a common JAR library. > To reproduce the issue I created a Stateless EJB in the EJB jar and then I injected a Traced ApplicationScoped bean from the JAR library in the Stateless EJB. > SmallRyeTracingCDIInterceptor triggers and it requires an Injected Tracer. > TracerProducer triggers and it has no active ServletContext and this leads to the error above. > My suggestion: > I don't think the ServletContext is a really good place to store the Tracer. > I think that the Tracer created by Wildfly should be registered into the GlobalTracer. > This should be done by: > https://github.com/wildfly/wildfly/blob/master/microprofile/opentracing-s... > If you don't want Wildfly to register automatically its Tracer in the GlobalTracer, this behavior could be disabled in the subsystem. > Also please be aware that SmallRyeTracingCDIInterceptor is dismissed in the last versions of the library and SmallRye states (https://github.com/smallrye/smallrye-opentracing) it has been replaced with: > https://github.com/opentracing-contrib/java-interceptors/blob/master/src/... > Also be aware that what I am suggesting is similar to the same behavior adopted in opentracing java-cdi (not yet integrated in Wildfly): > https://github.com/opentracing-contrib/java-cdi/blob/master/opentracing-c... > https://github.com/opentracing-contrib/java-cdi/blob/master/opentracing-c... > Also notice that opentracing java-ejb (not yet integrated in Wildfly) also requires a registration in GlobalTracing: > https://github.com/opentracing-contrib/java-ejb/blob/master/opentracing-e... > Thank you for your support. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-4513) remoting subsystem endpoint does not use specified worker

by Ivo Studensky (Jira)

[ https://issues.jboss.org/browse/WFCORE-4513?page=com.atlassian.jira.plugi... ] Ivo Studensky moved JBEAP-17033 to WFCORE-4513: ----------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-4513 (was: JBEAP-17033) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Server (was: Server) Affects Version/s: (was: 7.2.1.GA) Fix Version/s: (was: 7.2.3.GA) > remoting subsystem endpoint does not use specified worker > --------------------------------------------------------- > > Key: WFCORE-4513 > URL: https://issues.jboss.org/browse/WFCORE-4513 > Project: WildFly Core > Issue Type: Bug > Components: Server > Reporter: Ivo Studensky > Assignee: Ivo Studensky > Priority: Critical > Labels: regression > > remoting subsystem endpoint does not use specified worker > If you reconfigure the server, changing the default io worker name from 'default' to 'thread-pool' and then update all references that used 'default' and start the server, the remoting endpoint is looking for 'default' when it is configured to look for 'thread-pool' > {code} > ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "remoting")]) - failure description: { > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.io.worker.default"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.remoting.endpoint is missing [org.wildfly.io.worker.default]"] > {code} > {code} > embed-server > /subsystem=io/worker=mypool:add() > /subsystem=remoting:write-attribute(name=worker, value=mypool) > /subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=worker,value=mypool) > /subsystem=undertow/servlet-container=default/setting=websockets:write-attribute(name=worker,value=mypool) > /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=worker,value=mypool) > /subsystem=io/worker=default:remove() > stop-embed-server > {code} > produces: > {code} > <subsystem xmlns="urn:jboss:domain:io:3.0"> > <worker name="mypool"/> > <buffer-pool name="default"/> > </subsystem> > <subsystem xmlns="urn:jboss:domain:remoting:4.0"> > <endpoint worker="mypool"/> > <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/> > </subsystem> > ... > <http-listener name="default" socket-binding="http" worker="mypool" redirect-socket="https" enable-http2="true"/> > <https-listener name="https" socket-binding="https" worker="mypool" security-realm="ApplicationRealm" enable-http2="true"/> > ... > <servlet-container name="default"> > <jsp-config/> > <websockets worker="mypool"/> > </servlet-container> > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-4513) remoting subsystem endpoint does not use specified worker

by Ivo Studensky (Jira)

[ https://issues.jboss.org/browse/WFCORE-4513?page=com.atlassian.jira.plugi... ] Ivo Studensky updated WFCORE-4513: ---------------------------------- Component/s: Remoting (was: Server) > remoting subsystem endpoint does not use specified worker > --------------------------------------------------------- > > Key: WFCORE-4513 > URL: https://issues.jboss.org/browse/WFCORE-4513 > Project: WildFly Core > Issue Type: Bug > Components: Remoting > Reporter: Ivo Studensky > Assignee: Ivo Studensky > Priority: Critical > Labels: regression > > remoting subsystem endpoint does not use specified worker > If you reconfigure the server, changing the default io worker name from 'default' to 'thread-pool' and then update all references that used 'default' and start the server, the remoting endpoint is looking for 'default' when it is configured to look for 'thread-pool' > {code} > ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "remoting")]) - failure description: { > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.io.worker.default"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.remoting.endpoint is missing [org.wildfly.io.worker.default]"] > {code} > {code} > embed-server > /subsystem=io/worker=mypool:add() > /subsystem=remoting:write-attribute(name=worker, value=mypool) > /subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=worker,value=mypool) > /subsystem=undertow/servlet-container=default/setting=websockets:write-attribute(name=worker,value=mypool) > /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=worker,value=mypool) > /subsystem=io/worker=default:remove() > stop-embed-server > {code} > produces: > {code} > <subsystem xmlns="urn:jboss:domain:io:3.0"> > <worker name="mypool"/> > <buffer-pool name="default"/> > </subsystem> > <subsystem xmlns="urn:jboss:domain:remoting:4.0"> > <endpoint worker="mypool"/> > <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/> > </subsystem> > ... > <http-listener name="default" socket-binding="http" worker="mypool" redirect-socket="https" enable-http2="true"/> > <https-listener name="https" socket-binding="https" worker="mypool" security-realm="ApplicationRealm" enable-http2="true"/> > ... > <servlet-container name="default"> > <jsp-config/> > <websockets worker="mypool"/> > </servlet-container> > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-4151) Add proxy to Maven repositories read from settings.xml if an active proxy is set up

by Tibor Zimanyi (Jira)

[ https://issues.jboss.org/browse/DROOLS-4151?page=com.atlassian.jira.plugi... ] Tibor Zimanyi updated DROOLS-4151: ---------------------------------- Description: When repositories are read from settings.xml file and an active proxy is defined, the created repositories don't contain a proxy settings [1]. [1] https://github.com/kiegroup/kie-soup/blob/master/kie-soup-maven-utils/kie... was: When repositories are read from settings.xml file and an active proxy is defined, these repositories don't contain a proxy settings [1]. [1] https://github.com/kiegroup/kie-soup/blob/master/kie-soup-maven-utils/kie... > Add proxy to Maven repositories read from settings.xml if an active proxy is set up > ----------------------------------------------------------------------------------- > > Key: DROOLS-4151 > URL: https://issues.jboss.org/browse/DROOLS-4151 > Project: Drools > Issue Type: Bug > Components: integration > Affects Versions: 7.23.0.Final > Reporter: Tibor Zimanyi > Assignee: Tibor Zimanyi > Priority: Critical > > When repositories are read from settings.xml file and an active proxy is defined, the created repositories don't contain a proxy settings [1]. > [1] https://github.com/kiegroup/kie-soup/blob/master/kie-soup-maven-utils/kie... -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-9631) "Failed to reinstate timer" warning is shown when creating large number of EJB timers

by Michal Jurc (Jira)

[ https://issues.jboss.org/browse/WFLY-9631?page=com.atlassian.jira.plugin.... ] Michal Jurc reassigned WFLY-9631: --------------------------------- Assignee: Cheng Fang (was: Michal Jurc) > "Failed to reinstate timer" warning is shown when creating large number of EJB timers > ------------------------------------------------------------------------------------- > > Key: WFLY-9631 > URL: https://issues.jboss.org/browse/WFLY-9631 > Project: WildFly > Issue Type: Bug > Components: EJB > Environment: EAP 7.0.8.GA > Oracle 12 c > [Configuration of datasources|https://github.com/MarianMacik/timers-testing/blob/c7dde64d27...] - XA Datasource for jBPM - our application - and a separate XA Datasource for EJB Timers in a different schema. > Reporter: Marian Macik > Assignee: Cheng Fang > Priority: Major > Attachments: WFLY-9631-reproducer.zip > > > Hi, [~manovotn], > as we discussed before, I am creating a JIRA for an issue I experienced when testing EJB Timers with jBPM. > What I did was that I started a large number of processes with jBPM, let's say 10 000 and more. Each process contains a timer which jBPM will create an EJB Timer for. Each timer was configured to fire at exactly the same time, e.g. 12:00 PM. During the test I got this warning displayed about 5 times for each 10 000 timers created: > {code:java} > WARN [org.jboss.as.ejb3] (Timer-1) WFLYEJB0161: Failed to reinstate timer 'kie-server.kie-server.EJBTimerScheduler' (id=09afab21-6b0f-41b0-9338-403b4a12e507) from its persistent state: java.lang.IllegalStateException: WFLYCTL0075: Duplicate resource 09afab21-6b0f-41b0-9338-403b4a12e507 > at org.jboss.as.controller.registry.AbstractModelResource$DefaultResourceProvider.register(AbstractModelResource.java:290) > at org.jboss.as.controller.registry.AbstractModelResource.registerChild(AbstractModelResource.java:169) > at org.jboss.as.ejb3.subsystem.deployment.TimerServiceResource.timerCreated(TimerServiceResource.java:193) > at org.jboss.as.ejb3.timerservice.TimerServiceImpl.registerTimerResource(TimerServiceImpl.java:1094) > at org.jboss.as.ejb3.timerservice.TimerServiceImpl.startTimer(TimerServiceImpl.java:767) > at org.jboss.as.ejb3.timerservice.TimerServiceImpl$TimerRefreshListener.timerAdded(TimerServiceImpl.java:1235) > at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence$RefreshTask.run(DatabaseTimerPersistence.java:820) > at java.util.TimerThread.mainLoop(Timer.java:555) > at java.util.TimerThread.run(Timer.java:505) > {code} > The result of these warnings was that when I had only one EAP instance to fire these timers, it wouldn't fire exactly the timers with ids that were in those warnings, e.g. if it was id=09afab21-6b0f-41b0-9338-403b4a12e507 then this timer wouldn't fire. I had waited for minutes to be sure there is another tick of a refresh interval (configured to 1 min) but nothing happened. But when I started the second EAP instance, they were immediately picked up by that instance and fired. It seems that if there is this warning on a particular instance, the instance won't pick up the timer whatsoever. They will be picked up only by some other instances if there are any. With 2 EAP instances there were warnings too, but all timers fired since I guess affected timers were picked up each time by the other instance. > Another interesting observation is that when I configured a refresh interval to be shorter, e.g. 5 seconds, these warnings were showing up almost every 5 seconds. When I set it to 30 minutes, I didn't get warnings at all, since all timers fired earlier than a refresh occurred. > So I think it has something to do with refresh interval. > Can you please have a look at it? For further configuration details, check the Environment field. > Thank you very much! > Marian Macik -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-4152) Add proxy to Maven repositories read from settings.xml if an active proxy is set up

by Tibor Zimanyi (Jira)

Tibor Zimanyi created DROOLS-4152: ------------------------------------- Summary: Add proxy to Maven repositories read from settings.xml if an active proxy is set up Key: DROOLS-4152 URL: https://issues.jboss.org/browse/DROOLS-4152 Project: Drools Issue Type: Bug Components: integration Affects Versions: 7.23.0.Final Reporter: Tibor Zimanyi Assignee: Tibor Zimanyi When repositories are read from settings.xml file and an active proxy is defined, these repositories don't contain a proxy settings [1]. [1] https://github.com/kiegroup/kie-soup/blob/master/kie-soup-maven-utils/kie... -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2019