February 2021 - jboss-jira - Jboss List Archives

[Red Hat JIRA] (SWSQE-1267) UI Automations - Overview Health Filters

by Praneeth Bajjuri (Jira)

[ https://issues.redhat.com/browse/SWSQE-1267?page=com.atlassian.jira.plugi... ] Praneeth Bajjuri closed SWSQE-1267. ----------------------------------- Resolution: Done > UI Automations - Overview Health Filters > ---------------------------------------- > > Key: SWSQE-1267 > URL: https://issues.redhat.com/browse/SWSQE-1267 > Project: Kiali QE > Issue Type: QE Task > Reporter: Praneeth Bajjuri > Assignee: Praneeth Bajjuri > Priority: Major > > Adding Health new test cases for test_overview_page.py > Adding OverviewHealth values for enums.py > https://github.com/Kiali-QE/kiali-qe-python/pull/381 -- This message was sent by Atlassian Jira (v8.13.1#813001)

4 years, 11 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14391) Quickstart for Reactive Messaging with Kafka

by Kabir Khan (Jira)

[ https://issues.redhat.com/browse/WFLY-14391?page=com.atlassian.jira.plugi... ] Kabir Khan moved EAP7-1636 to WFLY-14391: ----------------------------------------- Component/s: Quickstarts (was: MicroProfile) (was: Quickstarts) EAP PT Analysis Document (AD): (was: TODO) EAP PT Community Docs (CD): (was: TODO) EAP PT Docs Analysis (DA): (was: TODO) EAP PT Feature Implementation (FI): (was: TODO) EAP PT Pre-Checked (PC): (was: TODO) EAP PT Product Docs (PD): (was: New) EAP PT Test Dev (TD): (was: TODO) EAP PT Test Plan (TP): (was: TODO) Key: WFLY-14391 (was: EAP7-1636) Target Release: (was: EAP-XP-3.0.0.GA) Workflow: GIT Pull Request workflow (was: EAP Agile Workflow 2.0) Issue Type: Feature Request (was: Requirement) Project: WildFly (was: JBoss EAP Planning for version 7 and above) > Quickstart for Reactive Messaging with Kafka > -------------------------------------------- > > Key: WFLY-14391 > URL: https://issues.redhat.com/browse/WFLY-14391 > Project: WildFly > Issue Type: Feature Request > Components: Quickstarts > Reporter: Kabir Khan > Assignee: Kabir Khan > Priority: Major > Labels: EAP-CD23 > -- This message was sent by Atlassian Jira (v8.13.1#813001)

4 years, 11 months

1
0
0 / 0

[Red Hat JIRA] (WFCORE-4970) Changing the JVM settings at host level does not put the servers in restart-required

by Yeray Borges Santana (Jira)

[ https://issues.redhat.com/browse/WFCORE-4970?page=com.atlassian.jira.plug... ] Yeray Borges Santana commented on WFCORE-4970: ---------------------------------------------- Hello [~parsharma], in response to your question about this issue, at first glance, it looks like the cause is all the [JvmAttributes|https://github.com/wildfly/wildfly-core/blob/master/ho... are not flagged as [RESTART_JVM|https://github.com/wildfly/wildfly-core/blob/master/controlle...]. It has to be verified where those attributes are being used and see if there is any CI test failing, though, but it could be a possible fix. It is suspicious that nobody has changed them before. [~jmesnil] / [~brian.stansberry] Do you know beforehand if there is any reason why the JvmAttributes are not flagged as Restart JVM? > Changing the JVM settings at host level does not put the servers in restart-required > ------------------------------------------------------------------------------------ > > Key: WFCORE-4970 > URL: https://issues.redhat.com/browse/WFCORE-4970 > Project: WildFly Core > Issue Type: Bug > Components: Management > Affects Versions: 12.0.0.Beta2 > Reporter: Yeray Borges Santana > Assignee: Parul Sharma > Priority: Major > > Operations like the following one should put the servers in restart required to indicate the user changes will be applied after restarting the servers: > {noformat} > [domain@localhost:9990 /] /host=master/jvm=default:write-attribute(name=heap-size, value=256m) > { > "outcome" => "success", > "result" => undefined, > "server-groups" => undefined > } > {noformat} -- This message was sent by Atlassian Jira (v8.13.1#813001)

4 years, 11 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14234) EJB bean method direct memory buffer leaking

by Bartosz Baranowski (Jira)

[ https://issues.redhat.com/browse/WFLY-14234?page=com.atlassian.jira.plugi... ] Bartosz Baranowski commented on WFLY-14234: ------------------------------------------- [~zharymv] Hey. It would be very helpful to include full setup and steps to reproduce. I know you did describe it, but stitching something based on description can sometimes prove to be a challenge, let alone hope for it to be valid. > EJB bean method direct memory buffer leaking > -------------------------------------------- > > Key: WFLY-14234 > URL: https://issues.redhat.com/browse/WFLY-14234 > Project: WildFly > Issue Type: Bug > Components: EJB, IO > Affects Versions: 19.0.0.Final > Reporter: Mike Zhary > Assignee: Flavia Rainone > Priority: Major > Attachments: 2020-11-10-112753_563x276_scrot.png, src_main_java_org_jboss_remoting3_remote_RemoteConnectionProvider.java > > > Wildfly.19.0.1.Final standalone > We're using haproxy to balance ejb calls between wildfly servers. > That's very useful model, but there are problems with it. > All connections are declared as remote-outbound-connection and it works. > {code} > <remote-outbound-connection name="{{ c.name }}" outbound-socket-binding-ref="{{ c.socket_binding }}" protocol="http-remoting" security-realm="{{ c.security_realm }}" username="{{ c.user }}"> > <properties> > <property name="SASL_POLICY_NOANONYMOUS" value="false"/> > <property name="SSL_ENABLED" value="false"/> > </properties> > </remote-outbound-connection> > {code} > But there is the problem when some from servers is offline. haproxy send response by http and sends RST by tcp, but WF can't make sense of this response. > Problem can be reprouced when servers listening port, but there is no repsonse for ejb call(in our case it means haproxy doesn't have suitable backend online) > But everything is clear, when port closed or server don't response for a calls. > Haproxy doesn't have feature to don't listen port if backed is offline. > At OS problems shows as huge count(equal to thread count) of connections in state CLOSE_WAIT. That means server had send packet TCP_FIN and client accepted it, but there were no respond on it. In other words WF and it's subsystems didn't agree with closing connection and it becomes to CLOSE_WAIT. At OS side closing connection in sometime and took it as dead(it's normal case) > At WF memory it appears as growing count of objects org.xnio.ByteBufferSlicePool$PooledByteBuffer, that have attribute buffer that holds about 2mb each. > Take a look: > !2020-11-10-112753_563x276_scrot.png|thumbnail! > Problem allocated in XNIO library. There were found a mistake and looks very similar to our problem. XNIO-254 > The same time we'd found XNIO-380 and we tried it with last version of this library(snapshot 3.9), no results were there. > We tried get undrestanding ow DMB clean, but did nothing due to too complicated code design. > As per investigations DMB used for an SSL connection, but we don't it. > So we were to patch jboss-remoting class RemoteConnectionProvider. > after that we'd solved issue with leaking of DMB. > Our patched library: [^src_main_java_org_jboss_remoting3_remote_RemoteConnectionProvider.java] > Please take look how this bug can be fixed. -- This message was sent by Atlassian Jira (v8.13.1#813001)

4 years, 11 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14390) WildFly does not start when async-registration attribute in XTS subsystem is set to an expression

by Ivan Straka (Jira)

Ivan Straka created WFLY-14390: ---------------------------------- Summary: WildFly does not start when async-registration attribute in XTS subsystem is set to an expression Key: WFLY-14390 URL: https://issues.redhat.com/browse/WFLY-14390 Project: WildFly Issue Type: Bug Components: XTS Affects Versions: 22.0.0.Final Reporter: Ivan Straka Assignee: Ondrej Chaloupka XTS subsystem supports expression for async-registration as described in the description: {code:java} /subsystem=xts:read-resource-description ... "attributes" => { "async-registration" => { "type" => BOOLEAN, "description" => "Initialize endpoints for asynchronous registration needed for WS-AT .NET integration.", "expressions-allowed" => true, "required" => false, "nillable" => true, "default" => false, "access-type" => "read-write", "storage" => "configuration", "restart-required" => "all-services" }, {code} However if I set the attribute to an expression, the server fails to reload: {code:java} 12:17:26,482 ERROR [org.jboss.as.controller] (Controller Boot Thread) OPVDX001: Validation error in standalone-xts.xml ------------------------------- | | 670: <xts-environment url="http://${jboss.bind.address:127.0.0.1}:8080/ws-c11/ActivationService"/> | 671: <default-context-propagation enabled="true"/> | 672: <async-registration enabled="${env.var:false}"/> | ^^^^ '${env.var:false}' isn't a valid value for the 'enabled' attribute | | 673: </subsystem> | 674: </profile> | 675: <interfaces> | | The primary underlying error message was: | > ParseError at [row,col]:[672,13] | > Message: WFLYCTL0106: Invalid value '${env.var:false}' for attribute | > 'enabled' | |------------------------------------------------------------------------------- 12:17:26,483 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:143) at org.jboss.as.server.ServerService.boot(ServerService.java:395) at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:416) at java.lang.Thread.run(Thread.java:748) 12:17:26,484 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details. {code} The subsystem is deprecated hence priority is major. {code:java} "result" => { "description" => "The configuration of the XST subsystem.", "deprecated" => { "since" => "3.0.0", "reason" => "Deprecated since the XTS feature set is rarely used and is considered legacy within development approaches nowadays." }, {code} -- This message was sent by Atlassian Jira (v8.13.1#813001)

4 years, 11 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14353) Upgrade to IronJacamar 1.4.27.Final

by Tomas Hofman (Jira)

[ https://issues.redhat.com/browse/WFLY-14353?page=com.atlassian.jira.plugi... ] Tomas Hofman updated WFLY-14353: -------------------------------- Summary: Upgrade to IronJacamar 1.4.27.Final (was: Upgrade to IronJacamar 1.4.26.Final) > Upgrade to IronJacamar 1.4.27.Final > ----------------------------------- > > Key: WFLY-14353 > URL: https://issues.redhat.com/browse/WFLY-14353 > Project: WildFly > Issue Type: Component Upgrade > Components: JCA > Reporter: Tomas Hofman > Assignee: Tomasz Adamski > Priority: Major > Labels: EE9 > Fix For: 22.0.0.Alpha1 > > -- This message was sent by Atlassian Jira (v8.13.1#813001)

4 years, 11 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14353) Upgrade to IronJacamar 1.4.26.Final

by Tomas Hofman (Jira)

[ https://issues.redhat.com/browse/WFLY-14353?page=com.atlassian.jira.plugi... ] Tomas Hofman updated WFLY-14353: -------------------------------- Git Pull Request: (was: https://github.com/wildfly/wildfly/pull/13700) > Upgrade to IronJacamar 1.4.26.Final > ----------------------------------- > > Key: WFLY-14353 > URL: https://issues.redhat.com/browse/WFLY-14353 > Project: WildFly > Issue Type: Component Upgrade > Components: JCA > Reporter: Tomas Hofman > Assignee: Tomasz Adamski > Priority: Major > Labels: EE9 > Fix For: 22.0.0.Alpha1 > > -- This message was sent by Atlassian Jira (v8.13.1#813001)

4 years, 11 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14380) Cant configure Let's Encrypt simple steps

by Bartosz Baranowski (Jira)

[ https://issues.redhat.com/browse/WFLY-14380?page=com.atlassian.jira.plugi... ] Bartosz Baranowski commented on WFLY-14380: ------------------------------------------- [~erick.de.oliveira.leal] - which windows? > Cant configure Let's Encrypt simple steps > ----------------------------------------- > > Key: WFLY-14380 > URL: https://issues.redhat.com/browse/WFLY-14380 > Project: WildFly > Issue Type: Bug > Affects Versions: 22.0.0.Final > Reporter: erick leal > Assignee: Brian Stansberry > Priority: Major > Attachments: Capturar.PNG > > > I'm tyring to configure Let's Encrypt in my server, and I followed instructions that said to simple type security enable-ssl-http-server --interactive --lets-encrypt > But I believe because I'm in Windows I ran into the issue described in the picture below > !Capturar.PNG! -- This message was sent by Atlassian Jira (v8.13.1#813001)

4 years, 11 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14389) Resource adapters subsystem does not accept expression for security-application attribute

by Ivan Straka (Jira)

[ https://issues.redhat.com/browse/WFLY-14389?page=com.atlassian.jira.plugi... ] Ivan Straka updated WFLY-14389: ------------------------------- Attachment: standalone-genericjms.xml > Resource adapters subsystem does not accept expression for security-application attribute > ----------------------------------------------------------------------------------------- > > Key: WFLY-14389 > URL: https://issues.redhat.com/browse/WFLY-14389 > Project: WildFly > Issue Type: Bug > Components: Server > Affects Versions: 22.0.0.Final > Reporter: Ivan Straka > Assignee: Brian Stansberry > Priority: Major > Attachments: standalone-genericjms.xml > > > Resource adapters subsystem supports expression for security-application attribute: > {code:java} > /subsystem=resource-adapters/resource-adapter=generic-jms-ra.rar/connection-definitions=\$\{genericjms.cf.pool-name\}:read-resource-description > ... > "security-application" => { > "type" => BOOLEAN, > "description" => "Indicates that application-supplied parameters, such as from getConnection(user, pw), are used to distinguish connections in the pool.", > "expressions-allowed" => true, > "required" => false, > "nillable" => true, > "default" => false, > "alternatives" => [ > "security-domain", > "security-domain-and-application", > "authentication-context", > "authentication-context-and-application" > ], > "access-constraints" => {"sensitive" => { > "security-domain-ref" => {"type" => "core"}, > "resource-adapter-security" => {"type" => "resource-adapters"} > }}, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "all-services" > }, > {code} > however it fails to marshall it: > {code:java} > /subsystem=resource-adapters/resource-adapter=generic-jms-ra.rar/connection-definitions=\$\{genericjms.cf.pool-name\}:write-attribute(name=security-application, value=${test:true}) > {code} > {code:java} > 22:39:11,111 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0008: Failed to persist configuration change: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0084: Failed to marshal configuration > at org.jboss.as.controller.persistence.AbstractFilePersistenceResource.<init>(AbstractFilePersistenceResource.java:53) > at org.jboss.as.controller.persistence.ConfigurationFilePersistenceResource.<init>(ConfigurationFilePersistenceResource.java:46) > at org.jboss.as.controller.persistence.BackupXmlConfigurationPersister.store(BackupXmlConfigurationPersister.java:120) > at org.jboss.as.controller.ModelControllerImpl.writeModel(ModelControllerImpl.java:728) > at org.jboss.as.controller.OperationContextImpl.createPersistenceResource(OperationContextImpl.java:535) > at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:821) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:770) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:468) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1415) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:431) > at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:248) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:304) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:270) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:248) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:240) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:138) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:162) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:158) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:328) > at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:285) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:158) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) > at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) > at java.lang.Thread.run(Thread.java:748) > at org.jboss.threads.JBossThread.run(JBossThread.java:513) > Caused by: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0089: Failed to write configuration > at org.jboss.as.controller.persistence.AbstractConfigurationPersister.marshallAsXml(AbstractConfigurationPersister.java:112) > at org.jboss.as.controller.persistence.AbstractFilePersistenceResource.<init>(AbstractFilePersistenceResource.java:46) > ... 30 more > Caused by: java.lang.IllegalArgumentException > at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:69) > at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:324) > at org.jboss.as.connector.subsystems.resourceadapters.ResourceAdapterSubsystemParser.writeConDef(ResourceAdapterSubsystemParser.java:378) > at org.jboss.as.connector.subsystems.resourceadapters.ResourceAdapterSubsystemParser.writeRaElement(ResourceAdapterSubsystemParser.java:232) > at org.jboss.as.connector.subsystems.resourceadapters.ResourceAdapterSubsystemParser.writeContent(ResourceAdapterSubsystemParser.java:148) > at org.jboss.as.connector.subsystems.resourceadapters.ResourceAdapterSubsystemParser.writeContent(ResourceAdapterSubsystemParser.java:130) > at org.jboss.as.server.parsing.CommonXml.writeSubsystems(CommonXml.java:281) > at org.jboss.as.server.parsing.StandaloneXml_16.writeServerProfile(StandaloneXml_16.java:830) > at org.jboss.as.server.parsing.StandaloneXml_16.writeContent(StandaloneXml_16.java:760) > at org.jboss.as.server.parsing.StandaloneXml.writeContent(StandaloneXml.java:151) > at org.jboss.as.server.parsing.StandaloneXml.writeContent(StandaloneXml.java:52) > at org.jboss.staxmapper.XMLMapperImpl.doDeparse(XMLMapperImpl.java:96) > at org.jboss.staxmapper.XMLMapperImpl.deparseDocument(XMLMapperImpl.java:91) > at org.jboss.as.controller.persistence.AbstractConfigurationPersister.marshallAsXml(AbstractConfigurationPersister.java:106) > ... 31 more > {code} > The error is caused by [1] where the parser does not resolve expression but read raw string (${yada yada}) as bool. > [1] https://github.com/wildfly/wildfly/blob/22.0.0.Final/connector/src/main/j... -- This message was sent by Atlassian Jira (v8.13.1#813001)

4 years, 11 months

1
0
0 / 0

[Red Hat JIRA] (DROOLS-5996) DMN Temporal alignment with redactions

by Matteo Mortari (Jira)

[ https://issues.redhat.com/browse/DROOLS-5996?page=com.atlassian.jira.plug... ] Matteo Mortari updated DROOLS-5996: ----------------------------------- Description: This is a task to address several redactions occurred at the RTF, to align the implementation with the actual details of the specification voted. # Named parameters, as pointed out [here|https://github.com/dmn-tck/tck/pull/369#issuecomment-755246944] # Formula alignments for "overlaps" and "overlaps before", as pointed out [here|https://issues.omg.org/browse/DMN14-125] > DMN Temporal alignment with redactions > -------------------------------------- > > Key: DROOLS-5996 > URL: https://issues.redhat.com/browse/DROOLS-5996 > Project: Drools > Issue Type: Task > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Priority: Major > > This is a task to address several redactions occurred at the RTF, to align the implementation with the actual details of the specification voted. > # Named parameters, as pointed out [here|https://github.com/dmn-tck/tck/pull/369#issuecomment-755246944] > # Formula alignments for "overlaps" and "overlaps before", as pointed out [here|https://issues.omg.org/browse/DMN14-125] -- This message was sent by Atlassian Jira (v8.13.1#813001)

4 years, 11 months

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 February 2021