January 2021 - jboss-jira - Jboss List Archives

[Red Hat JIRA] (SWSQE-1184) OC API - Service list - Add health

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-1184?page=com.atlassian.jira.plugi... ] Hayk Hovsepyan updated SWSQE-1184: ---------------------------------- Sprint: Kiali Sprint #51 > OC API - Service list - Add health > ---------------------------------- > > Key: SWSQE-1184 > URL: https://issues.redhat.com/browse/SWSQE-1184 > Project: Kiali QE > Issue Type: QE Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Major > Labels: automation > > openshift_api.service_list > service_details > TODO: heath needs to be added -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (JGRP-2525) Replace XML parse for configuration with simple parser

by Bela Ban (Jira)

Bela Ban created JGRP-2525: ------------------------------ Summary: Replace XML parse for configuration with simple parser Key: JGRP-2525 URL: https://issues.redhat.com/browse/JGRP-2525 Project: JGroups Issue Type: Enhancement Reporter: Bela Ban Assignee: Bela Ban Fix For: 5.1.3, 4.2.12 Similarly to JGRP-2524, this replaces the javax.xml classes used for parsing of configuration with a simple parser. This reduces the number of classes pulled in and should result in a smaller memory footprint. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (JGRP-2524) Replace XML parser with simple parser for magic-map and protocol-ids

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2524?page=com.atlassian.jira.plugin... ] Bela Ban commented on JGRP-2524: -------------------------------- Parsing of jg-protocol-id.xml and jg-magic-map.xml works. > Replace XML parser with simple parser for magic-map and protocol-ids > -------------------------------------------------------------------- > > Key: JGRP-2524 > URL: https://issues.redhat.com/browse/JGRP-2524 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 4.2.11, 5.1.3 > > > Even when configuring a stack programmatically, the reading of magic-map-ids.xml and protocol-ids.xml requires {{javax.xml}}, which pulls in a lot of classes, which remain in memory for the duration of the program. > Todo: replace this with a simple XML parser. > Perhaps use the same method to parse XML configuration, too -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (WFCORE-4360) Support encrypted expression resolution using a CredentialStore

by Ash Westbrook (Jira)

[ https://issues.redhat.com/browse/WFCORE-4360?page=com.atlassian.jira.plug... ] Ash Westbrook updated WFCORE-4360: ---------------------------------- Labels: NAPS app-services-naps (was: ) > Support encrypted expression resolution using a CredentialStore > --------------------------------------------------------------- > > Key: WFCORE-4360 > URL: https://issues.redhat.com/browse/WFCORE-4360 > Project: WildFly Core > Issue Type: Feature Request > Components: Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Labels: NAPS, app-services-naps > -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ELY-2067) Elytron tool should use FIPS compatible ciphers when FIPS mode is enabled

by Ash Westbrook (Jira)

[ https://issues.redhat.com/browse/ELY-2067?page=com.atlassian.jira.plugin.... ] Ash Westbrook updated ELY-2067: ------------------------------- Labels: NAPS app-services-naps (was: NAPS) > Elytron tool should use FIPS compatible ciphers when FIPS mode is enabled > ------------------------------------------------------------------------- > > Key: ELY-2067 > URL: https://issues.redhat.com/browse/ELY-2067 > Project: WildFly Elytron > Issue Type: Bug > Components: API / SPI, Credential Store > Reporter: Diana Vilkolakova > Assignee: Diana Vilkolakova > Priority: Major > Labels: NAPS, app-services-naps > > Elytron tool fails to mask password when FIPS mode is enabled on RHEL 8. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (JGRP-2522) FD_ALL2 throws NPE

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2522?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2522: --------------------------- Fix Version/s: 4.2.12 (was: 4.2.11) > FD_ALL2 throws NPE > ------------------ > > Key: JGRP-2522 > URL: https://issues.redhat.com/browse/JGRP-2522 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 5.2, 4.2.12 > > > This is in 4.x: > {noformat} > Exception in thread "jgroups-28,TEST4,192.168.123.100:Reciever-18" java.lang.NullPointerException > at org.jgroups.protocols.FD_ALL2.lambda$new$0(FD_ALL2.java:83) > at org.jgroups.util.MessageBatch.replaceIf(MessageBatch.java:220) > at org.jgroups.protocols.FD_ALL2.up(FD_ALL2.java:186) > at org.jgroups.stack.Protocol.up(Protocol.java:372) > at org.jgroups.stack.Protocol.up(Protocol.java:372) > at org.jgroups.stack.Protocol.up(Protocol.java:372) > at org.jgroups.protocols.TP.passBatchUp(TP.java:1274) > at org.jgroups.util.SubmitToThreadPool$BatchHandler.passBatchUp(SubmitToThreadPool.java:140) > at org.jgroups.util.SubmitToThreadPool$BatchHandler.run(SubmitToThreadPool.java:136) > 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 (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (JGRP-2520) CENTRAL_LOCK2: locks not released on kill

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2520?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2520: --------------------------- Fix Version/s: 4.2.12 (was: 4.2.11) > CENTRAL_LOCK2: locks not released on kill > ----------------------------------------- > > Key: JGRP-2520 > URL: https://issues.redhat.com/browse/JGRP-2520 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 5.2, 4.2.12 > > > 2 emails from D. White: > When a node thread is killed the JChannel/LockService still remains active because the node JVM is not killed. A new worker thread is created to replace the thread that was killed. In this case, the cluster view has not changed and therefore the locks remain. > When the node JVM process is killed, that action triggers a cluster view change which is received by the Coordinator. In this case, the server lock state is rebuilt and the locks are released. > I think the following will help: > Setup: 3 node cluster, each node with two worker threads. Each set of worker threads has access to the parent node JChannel. > dwhite-jgroups-node1 (Coordinator) > dwhite-jgroups-node2 > dwhite-jgroups-node3 > dwhite-jgroups-node2 thread1 acquires lock on resource ENV:ISA_IEA:1 > dwhite-jgroups-node2 thread1 acquires lock on resource ENV:GS_GE:1 > dwhite-jgroups-node2 thread2 requests lock on resource ENV:ISA_IEA:1 > dwhite-jgroups-node1 thread1 requests lock on resource ENV:ISA_IEA:1 > dwhite-jgroups-node1 thread2 requests lock on resource ENV:ISA_IEA:1 > dwhite-jgroups-node3 thread1 requests lock on resource ENV:ISA_IEA:1 > dwhite-jgroups-node3 thread2 requests lock on resource ENV:ISA_IEA:1 > Scenario #1: > dwhite-jgroups-node2 thread1 runs too long, does not respond to soft shutdown, and the node JVM process killed by watch dog service. > [SPEChannelAdapter] viewAccepted received by Coordinator dwhite-jgroups-node1. > Both locks are released. > Scenario #2: > dwhite-jgroups-node2 thread1 runs too long, and the soft shutdown kills thread1 leaving the server locks in place and the node2 JVM process running. > Watch dog detects locks held too long for ENV:ISA_IEA:1 and ENV:GS_GE:1, and issues RELEASE_LOCK messages from the Coordinator with the proper Owner. > ENV:GS_GE:1 is released. > ENV:ISA_IEA:1 remains locked, seemingly due to the presence of a GRANT_LOCK request from dwhite-jgroups-node2 thread2. > Scenario #3 (slight variation on #2): > dwhite-jgroups-node2 thread1 runs too long, and the soft shutdown kills thread1 leaving the server locks in place and the node2 JVM process running. > Watch dog detects lock held too long on ENV:ISA_IEA:1 and ENV:GS_GE:1 and issues RELEASE_LOCK from the Coordinator with proper Owner. > Watch dog also removes GRANT_LOCK request for ENV:ISA_IEA:1 from dwhite-jgroups-node2 thread2. > Now both locks are released. > The presence of GRANT_LOCK requests from node1 and node3 does not prevent the release of the lock for ENV:ISA_IEA:1 held by node2. > Email 2: > Yes, we acquire a lock within a try/catch block and release with finally. > In production, each JVM has two worker threads. If any of the threads runs too a long, a monitor task force kills the JVM process. If there are acquired locks they do not get released from the unlock call in the finally block. Usually a JVM is killed because a bad customer map runs too long and the other thread with acquired locks becomes "collateral damage". Not every business scenario uses locks. Therefore, the "orphan lock" scenario doesn't happen every time a JVM process is killed. Also, both threads are not always active. > We use the CENTRAL_LOCK2 protocol. For some reason the locks acquired from the killed process may remain in the server locks table. On occasion, the existing Coordinator doesn't detect the "orphan" locks and revoke them. > Does a view change where the Coordinator has not changed cause that Coordinator to rebuild the lock state? In a view change where the Coordinator does change, that seems to fix the problem because the new Coordinator rebuilds the lock state table. > In the case where a new Coordinator is assigned, do the state transfer protocols need to be in the configuration (e.g. BARRIER, pbcast.STATE_TRANSFER) in order for the new Coordinator to correctly re-establish the lock state? I don't think so because CENTRAL_LOCK2 does not use state-transfer; the Coordinator rebuilds the lock state. > To alleviate this problem, we have a lock monitor thread which runs on the Coordinator node and keeps track of how long each lock has been held. Since no flow can run more than an hour any lock held for more is definitely an orphan. The lock monitor task issues RELEASE_LOCK requests using the owner address of the orphan lock. The RELEASE_LOCK message works in all cases except where there are pending GRANT_LOCK requests in the queue from the same owner address of the held lock. If the GRANT_LOCK requests are from other addresses, the RELEASE_LOCK request works. > In order to simulate the problem, a test application ignores the unlock operation in the finally block purposefully creating the "orphan" in the server locks table. Other instances of the test application are running with normal lock/unlock operations. The lock monitor thread on the Coordinator subsequently detects the "lock held too long" orphan condition and issues the RELEASE_LOCK request on behalf of the orphan lock owner. Whenever a lock is successfully acquired, the lock monitor task internally keeps track of the acquired timestamp, owner, and lock ID. > I'd love to get rid of the complex lock monitor and ensure lock revoke operations are initiated by the Coordinator via the CENTRAL_LOCK2 protocol. > Another enhancement that would completely solve this problem: Allow a timeout to be specified for holding a lock. The JGroups protocol would then revoke the lock if the timeout threshold were reached. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (WFCORE-5243) NullPointerException when invalid <permission> classes specified

by Ricardo Martin Camarero (Jira)

[ https://issues.redhat.com/browse/WFCORE-5243?page=com.atlassian.jira.plug... ] Ricardo Martin Camarero updated WFCORE-5243: -------------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/4453 > NullPointerException when invalid <permission> classes specified > ---------------------------------------------------------------- > > Key: WFCORE-5243 > URL: https://issues.redhat.com/browse/WFCORE-5243 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 14.0.0.Final > Reporter: Ricardo Martin Camarero > Assignee: Ricardo Martin Camarero > Priority: Major > > If the security manager contains an invalid class or other data in the minimum-set it throws a NullPointerException instead of a useful error message. > > {noformat} > ERROR [management-operation] WFLYCTL0013 : Operation ("add") failed - address ([("subsystem" => "security-manager")]): java.lang.NullPointerException > at java.security.Permissions.getPermissionCollection(Permissions.java:240) > at java.security.Permissions.implies(Permissions.java:179) at org.jboss.modules.security.FactoryPermissionCollection.implies(FactoryPermissionCollection.java:75) at org.wildfly.extension.security.manager.SecurityManagerSubsystemAdd.performBoottime(SecurityManagerSubsystemAdd.java:101) > ...{noformat} > > > The same thing happens with other missing data. > * Works: > {noformat} > <permission class="java.io.FilePermission" name="/foo" actions="read"/>{noformat} > * Fail with NullPointerException: > {noformat} > <permission class="invalid.class.name" name="/foo" actions="read"/>{noformat} > {noformat} > <permission class="java.io.FilePermission" name="/foo"/>{noformat} > {noformat} > <permission class="java.io.FilePermission" actions="read"/>{noformat} > > The NullPointerException does not occur if maximum-set is absent, or contains *java.security.AllPermission* -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (JGRP-2524) Replace XML parser with simple parser for magic-map and protocol-ids

by Bela Ban (Jira)

Bela Ban created JGRP-2524: ------------------------------ Summary: Replace XML parser with simple parser for magic-map and protocol-ids Key: JGRP-2524 URL: https://issues.redhat.com/browse/JGRP-2524 Project: JGroups Issue Type: Enhancement Reporter: Bela Ban Assignee: Bela Ban Fix For: 4.2.11, 5.1.3 Even when configuring a stack programmatically, the reading of magic-map-ids.xml and protocol-ids.xml requires {{javax.xml}}, which pulls in a lot of classes, which remain in memory for the duration of the program. Todo: replace this with a simple XML parser. Perhaps use the same method to parse XML configuration, too -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-12018) WebSocket13Channel not Serializable

by Benjamin La O (Jira)

[ https://issues.redhat.com/browse/WFLY-12018?page=com.atlassian.jira.plugi... ] Benjamin La O commented on WFLY-12018: -------------------------------------- Same issue. > WebSocket13Channel not Serializable > ----------------------------------- > > Key: WFLY-12018 > URL: https://issues.redhat.com/browse/WFLY-12018 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 16.0.0.Final > Environment: wildfly16 full-ha domain mode > Reporter: georges goebel > Assignee: Paul Ferraro > Priority: Major > Labels: downstream_dependency > Fix For: 20.0.0.Beta1, 20.0.0.Final > > > I have running an webapplication in a clustered wildfly16 environment (*full-ha domain* mode) with the *distributable*-web.xml tag. > I want to add websocket support to it, but as soon as I use it in a JSF-page, I'm getting a *NotSerializableException* for the "* io.undertow.websockets.core.protocol.version13.WebSocket13Channel*". -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 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 January 2021