February 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-3046) FileKeystore is hard to use with non-file-based keystores

by Jan Pazdziora (Jira)

[ https://issues.jboss.org/browse/WFCORE-3046?page=com.atlassian.jira.plugi... ] Jan Pazdziora commented on WFCORE-3046: --------------------------------------- For the benefit of someone who does not follow the JBoss development or does not know how Elytron works, could you point me to some migration guide that we could use for https://github.com/latchset/custodia-jca-provider? Also, in which EAP version will Elytron start to be available? > FileKeystore is hard to use with non-file-based keystores > --------------------------------------------------------- > > Key: WFCORE-3046 > URL: https://issues.jboss.org/browse/WFCORE-3046 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Jan Pazdziora > Assignee: Darran Lofthouse > Priority: Major > > We are implementing JCA KeyStore provider to get certificates and keys via external process over the network: > https://github.com/latchset/custodia-jca-provider > However, code in https://github.com/wildfly/wildfly-core/blob/master/domain-management/src... makes use of such code hard. > It seems that FileKeystore has two modes of operation -- either alias is specified and then the KeyStore is treated as file (isKeyStore = true) which has to exist and it has to be able to list aliases, or the file is not required to exist (isKeyStore = false) but then alias cannot be specified (and if it is specified as alias attribute to <keystore> element, it is ignored). > In case we'd like to be able to use our provider without additional configuration in java.security, we'd like to be able to specify alias to retrieve specified entry, especially since getting the list of aliases might be either slow (for large sets) or not possible. For that however, we need to go the isKeyStore = true route with path specified and file existing. Alas, when we try > <ssl> > <keystore provider="custodia-cli" path="/dev/null" alias="wildfly/server-ssl" keystore-password="thepassword" /> > </ssl> > then due to the extra check in WildFly's code, startup fails with > Caused by: org.jboss.msc.service.StartException in anonymous service: WFLYDM0083: The KeyStore /dev/null does not contain any keys. > at org.jboss.as.domain.management.security.FileKeystore.assertContainsKey(FileKeystore.java:169) > at org.jboss.as.domain.management.security.FileKeystore.load(FileKeystore.java:120) > at org.jboss.as.domain.management.security.FileKeyManagerService.loadKeyStore(FileKeyManagerService.java:189) > Please consider removing the > if (isKeyStore) { > assertContainsKey(loadedKeystore); > } > code from https://github.com/wildfly/wildfly-core/blob/master/domain-management/src... since existence of the keystore file does not guarantee that the keys will be stored in it and that the provider will be able to loop through them. The file might be just /dev/null or some config file of the provider. > Ideally though, it should be possible to specify alias even for keystore which has no path specified. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11707) [EAT] : Adding a testcase that is also used with P_o_e_n ...

by Panagiotis Sotiropoulos (Jira)

Panagiotis Sotiropoulos created WFLY-11707: ---------------------------------------------- Summary: [EAT] : Adding a testcase that is also used with P_o_e_n ... Key: WFLY-11707 URL: https://issues.jboss.org/browse/WFLY-11707 Project: WildFly Issue Type: Task Components: Test Suite Reporter: Panagiotis Sotiropoulos Assignee: Panagiotis Sotiropoulos Adding a testcase that is also used with P_o_e_n ... -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2297) Coordinator with ASYM_ENCRYPT in the stack does not leave gracefully

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2297?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2297: --------------------------- Fix Version/s: 4.0.18 (was: 4.0.17) > Coordinator with ASYM_ENCRYPT in the stack does not leave gracefully > -------------------------------------------------------------------- > > Key: JGRP-2297 > URL: https://issues.jboss.org/browse/JGRP-2297 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.14 > Reporter: Radoslav Husar > Assignee: Bela Ban > Priority: Blocker > Fix For: 4.0.18 > > > The {{ASYM_ENCRYPT_LeaveTest}} is designed to test graceful leaving coordinator(s) with ASYM_ENCRYPT in the stack. However, the test currently passes due to presence of MERGE3 in the stack. While the intention of the test seems to be testing graceful leaving of coordinator(s), the cluster ends up with inconsistent views later resolved by MERGE3. > Here is a run of the test with a modification of the test with a *single* coordinator leaving: > https://gist.github.com/rhusar/89172882fae60a1f29327c33f2d124db > The problem seems to be with coordinating of key exchange. In this run, roughly: > 1. node 1 is leaving > 2. node 2 becomes coordinator and key server > {noformat} > 10:55:18.286 [jgroups-3,ASYM_ENCRYPT_LeaveTest,2] DEBUG org.jgroups.protocols.pbcast.GMS - 2: installing view [2|10] (9) [2, 3, 4, 5, 6, 7, 8, 9, 10] > ... > 10:55:18.299 [jgroups-3,ASYM_ENCRYPT_LeaveTest,2] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 2: I'm the new key server > 10:55:18.300 [jgroups-3,ASYM_ENCRYPT_LeaveTest,2] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 2: created new secret key (version: AB1E6F44DE947D792A7D05D2E957AC85) > ... > 10:55:18.300 [jgroups-3,ASYM_ENCRYPT_LeaveTest,2] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 2: created new secret key (version: AB1E6F44DE947D792A7D05D2E957AC85) > {noformat} > 3. node 9 receives {{FETCH_SECRET_KEY}} however receives stale key? looks like it still contacts the leaving coordinator node 1? > {noformat} > 10:55:18.319 [SSL_KEY_EXCHANGE-runner-12,ASYM_ENCRYPT_LeaveTest,1] DEBUG org.jgroups.protocols.SSL_KEY_EXCHANGE - 1: accepted SSL connection from /127.0.0.1:51812; protocol: TLSv1, cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA > ... > 10:55:18.319 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.SSL_KEY_EXCHANGE - 9: created SSL connection to 2 (/127.0.0.1:2157); protocol: TLSv1, cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA > 10:55:18.321 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.SSL_KEY_EXCHANGE - 9: sending up secret key (version: AF7916A9394F49B085D4F35C4F5A0A3E) > 10:55:18.321 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 9: ignoring secret key received from key exchange protocol (version: AF7916A9394F49B085D4F35C4F5A0A3E), as it has already been installed > {noformat} > 4. new coordinator fails to collect all acks (since it cannot decipher stale key?) > {noformat} > 10:55:20.307 [jgroups-3,ASYM_ENCRYPT_LeaveTest,2] WARN org.jgroups.protocols.pbcast.GMS - 2: failed to collect all ACKs (expected=8) for view [2|10] after 2000ms, missing 1 ACKs from (1) 9 > {noformat} > 5. node 9 eventually obtains the key but since it has stale view and still thinks node 1 is coordinator? and fails to contact it > {noformat} > 10:55:20.307 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 9: asking key exchange protocol to get secret key from 2 > 10:55:20.322 [SSL_KEY_EXCHANGE-runner-26,ASYM_ENCRYPT_LeaveTest,2] DEBUG org.jgroups.protocols.SSL_KEY_EXCHANGE - 2: accepted SSL connection from /127.0.0.1:51829; protocol: TLSv1, cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA > 10:55:20.322 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.SSL_KEY_EXCHANGE - 9: created SSL connection to 2 (/127.0.0.1:2158); protocol: TLSv1, cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA > 10:55:20.322 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.SSL_KEY_EXCHANGE - 9: sending up secret key (version: AB1E6F44DE947D792A7D05D2E957AC85) > 10:55:20.322 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 9: installing secret key received from key exchange protocol (version: AB1E6F44DE947D792A7D05D2E957AC85) > 10:55:23.341 [TQ-Bundler-10,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.TCP - JGRP000034: 9: failure sending message to 1: java.net.ConnectException: Connection refused (Connection refused) > {noformat} > 6. cluster is later healed with MERGE3 > {noformat} > 10:55:27.103 [jgroups-27,ASYM_ENCRYPT_LeaveTest,2] DEBUG org.jgroups.protocols.pbcast.GMS - 2: I will be the merge leader. Starting the merge task. Views: {2=[2|10] (9) [2, 3, 4, 5, 6, 7, 8, 9, 10], 9=[1|9] (10) [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]} > {noformat} > Another run with MERGE3 omitted from the stack is here: > https://gist.github.com/rhusar/b51aeee03485a607041f9669bbc6e707 > Further investigation is ongoing, but this might be related to graceful leaving of coordinator JGRP-2293 exacerbating the problem with key exchange in ASYM_ENCRYPT. > Scaling down is typical cloud workflow, especially with encryption since {{ASYM_ENCRYPT}} is the recommended setup making this problem critical. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2327) UNICAST3: create receiver table when non-first message is received first

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2327?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2327: --------------------------- Fix Version/s: 4.0.18 (was: 4.0.17) > UNICAST3: create receiver table when non-first message is received first > ------------------------------------------------------------------------ > > Key: JGRP-2327 > URL: https://issues.jboss.org/browse/JGRP-2327 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 4.0.18 > > > * A and B > * B sends 2 messages to A: B1 and B2 > * A receives B2 _before_ B1 (both B1 and B2 are OOB) > * The current code has A drop B2 and send a SEND_FIRST_SEQNO message to B > * B resends B1, but _not_ B2 > * Retransmission needs to kick in before A receives B2. This might take up to {{xmit_interval * 2}} ms before B2 is retransmitted and delivered > h4. Scenario (JGRP-2293): > * A installs a new view > * B sends a LEAVE-REQ to A (B is leaving, too) on the view installation and a VIEW-ACK for the view. Both messages are unicasts to A and OOB > * The VIEW-ACK (B2) is received first and dropped, so it will have to be retransmitted > * This delays the view installation, as A waits for {{view_ack_collection_timeout}} ms until it has received all VIEW-ACKs > h4. Workaround > * Set GMS.leave_timeout to a higher value (say 8000ms) > h4. Solution > * When B2 is received, and it is not the first message and we don't have a receiver table for B yet, investigate whether we can create the receiver table anyway > * However, this requires the first seqno from B *to always be 0* > --> Investigate whether the first seqno in UNICAST3 is always 0, then this solution will work -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2303) RELAY2: notification when a site is up/down on all cluster nodes

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2303?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2303: --------------------------- Fix Version/s: 4.0.18 (was: 4.0.17) > RELAY2: notification when a site is up/down on all cluster nodes > ---------------------------------------------------------------- > > Key: JGRP-2303 > URL: https://issues.jboss.org/browse/JGRP-2303 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0.18 > > > Provide a callback that's invoked on *all nodes* when a site is up/down, and possibly an initial view of the sites. Could be something like a 'sites view', e.g. \{"LON", "SFO"\}, \{"LON"\}, \{"LON", "SFO", "NYC\} etc -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3535) Out of Memory Error when creating KieSession

by Mario Fusco (Jira)

[ https://issues.jboss.org/browse/DROOLS-3535?page=com.atlassian.jira.plugi... ] Mario Fusco updated DROOLS-3535: -------------------------------- Sprint: 2019 Week 05-07 > Out of Memory Error when creating KieSession > -------------------------------------------- > > Key: DROOLS-3535 > URL: https://issues.jboss.org/browse/DROOLS-3535 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.11.0.Final > Environment: In MacBook Pro (15-inch, 2017) > JDK 8 > java version "1.8.0_161" > Java(TM) SE Runtime Environment (build 1.8.0_161-b12) > Java HotSpot(TM) 64-Bit Server VM (build 25.161-b12, mixed mode) > OpenJDK 11 > openjdk version "11.0.1" 2018-10-16 > OpenJDK Runtime Environment 18.9 (build 11.0.1+13) > OpenJDK 64-Bit Server VM 18.9 (build 11.0.1+13, mixed mode) > Reporter: Sarvagya Pant > Assignee: Mario Fusco > Priority: Blocker > > We are using Drools compiler to compile DRL and create KieSession. Internally, when we try to compile large number of Spreadsheet (e.g. say 500), each containing about 30 rules, we get Out of memory error as shown in logs below: > java.lang.OutOfMemoryError: unable to create native thread: possibly out of memory or process/resource limits reached > at java.base/java.lang.Thread.start0(Native Method) > at java.base/java.lang.Thread.start(Thread.java:803) > at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileRulesLevel(KnowledgeBuilderImpl.java:1155) > at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileRules(KnowledgeBuilderImpl.java:1135) > at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileKnowledgePackages(KnowledgeBuilderImpl.java:973) > at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.buildRules(KnowledgeBuilderImpl.java:2554) > at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.buildPackages(KnowledgeBuilderImpl.java:2489) > at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildPackages(CompositeKnowledgeBuilderImpl.java:113) > at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build(CompositeKnowledgeBuilderImpl.java:103) > at org.drools.compiler.kie.builder.impl.AbstractKieProject.buildKnowledgePackages(AbstractKieProject.java:251) > at org.drools.compiler.kie.builder.impl.AbstractKieProject.verify(AbstractKieProject.java:74) > at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildKieProject(KieBuilderImpl.java:267) > at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:235) > at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:184) > at org.kie.internal.utils.KieHelper.verify(KieHelper.java:94) > at abc.xyz.KnowledgeBaseCreator.createKnowledgeBaseFromDrl(KnowledgeBaseCreator.java:319) > This issue can be traced to KnowledgeBuilderImpl.java as shown below: > Map<String, RuleBuildContext> ruleCxts = new ConcurrentHashMap<>(); > ForkJoinPool pool = new ForkJoinPool(); // avoid common pool > try { > pool.submit(() -> > rules.stream().parallel() > .filter(ruleDescr -> filterAccepts(ResourceChange.Type.RULE, ruleDescr.getNamespace(), ruleDescr.getName())) > .forEach(ruleDescr -> { > initRuleDescr(packageDescr, pkgRegistry, ruleDescr); > RuleBuildContext context = buildRuleBuilderContext(pkgRegistry, ruleDescr); > ruleCxts.put(ruleDescr.getName(), context); > List<? extends KnowledgeBuilderResult> results = addRule(context); > if (!results.isEmpty()) { > synchronized (this.results) { > this.results.addAll(results); > } > } > }) > ).get(); > } catch (InterruptedException | ExecutionException e) { > throw new RuntimeException("Rules compilation failed or interrupted", e); > } > for (RuleDescr ruleDescr : rules) { > RuleBuildContext context = ruleCxts.get(ruleDescr.getName()); > if (context != null) { > pkgRegistry.getPackage().addRule(context.getRule()); > } > } > Here ForkJoinPool is created without specifying any parallelism limit as well as without shutting it down. Moreover, since its avoiding common pool, anyone who is using it in a loop will face the issue as discussed above. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3614) [DMN Designer] Maximize Event brings palette to expression editor

by Jozef Marko (Jira)

[ https://issues.jboss.org/browse/DROOLS-3614?page=com.atlassian.jira.plugi... ] Jozef Marko commented on DROOLS-3614: ------------------------------------- Sorry for the inconvenience [~tirelli] I attached the proper screenshot now. > [DMN Designer] Maximize Event brings palette to expression editor > ----------------------------------------------------------------- > > Key: DROOLS-3614 > URL: https://issues.jboss.org/browse/DROOLS-3614 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.18.0.Final > Reporter: Jozef Marko > Assignee: Michael Anstis > Priority: Major > Labels: drools-tools > Attachments: Screenshot from 2019-02-07 16-06-01.png > > > If the expression editor is maximized, there appears the palette, that should be shown just for diagram editor. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3614) [DMN Designer] Maximize Event brings palette to expression editor

by Jozef Marko (Jira)

[ https://issues.jboss.org/browse/DROOLS-3614?page=com.atlassian.jira.plugi... ] Jozef Marko updated DROOLS-3614: -------------------------------- Attachment: Screenshot from 2019-02-07 16-06-01.png > [DMN Designer] Maximize Event brings palette to expression editor > ----------------------------------------------------------------- > > Key: DROOLS-3614 > URL: https://issues.jboss.org/browse/DROOLS-3614 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.18.0.Final > Reporter: Jozef Marko > Assignee: Michael Anstis > Priority: Major > Labels: drools-tools > Attachments: Screenshot from 2019-02-07 16-06-01.png > > > If the expression editor is maximized, there appears the palette, that should be shown just for diagram editor. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3614) [DMN Designer] Maximize Event brings palette to expression editor

by Jozef Marko (Jira)

[ https://issues.jboss.org/browse/DROOLS-3614?page=com.atlassian.jira.plugi... ] Jozef Marko updated DROOLS-3614: -------------------------------- Attachment: (was: Screenshot from 2019-02-07 14-25-52.png) > [DMN Designer] Maximize Event brings palette to expression editor > ----------------------------------------------------------------- > > Key: DROOLS-3614 > URL: https://issues.jboss.org/browse/DROOLS-3614 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.18.0.Final > Reporter: Jozef Marko > Assignee: Michael Anstis > Priority: Major > Labels: drools-tools > Attachments: Screenshot from 2019-02-07 16-06-01.png > > > If the expression editor is maximized, there appears the palette, that should be shown just for diagram editor. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2327) UNICAST3: create receiver table when non-first message is received first

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2327?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2327: -------------------------------- Yes. This is not a showstopper, as retransmission for leave requests is unicast and therefore ~500ms (default). > UNICAST3: create receiver table when non-first message is received first > ------------------------------------------------------------------------ > > Key: JGRP-2327 > URL: https://issues.jboss.org/browse/JGRP-2327 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 4.0.17 > > > * A and B > * B sends 2 messages to A: B1 and B2 > * A receives B2 _before_ B1 (both B1 and B2 are OOB) > * The current code has A drop B2 and send a SEND_FIRST_SEQNO message to B > * B resends B1, but _not_ B2 > * Retransmission needs to kick in before A receives B2. This might take up to {{xmit_interval * 2}} ms before B2 is retransmitted and delivered > h4. Scenario (JGRP-2293): > * A installs a new view > * B sends a LEAVE-REQ to A (B is leaving, too) on the view installation and a VIEW-ACK for the view. Both messages are unicasts to A and OOB > * The VIEW-ACK (B2) is received first and dropped, so it will have to be retransmitted > * This delays the view installation, as A waits for {{view_ack_collection_timeout}} ms until it has received all VIEW-ACKs > h4. Workaround > * Set GMS.leave_timeout to a higher value (say 8000ms) > h4. Solution > * When B2 is received, and it is not the first message and we don't have a receiver table for B yet, investigate whether we can create the receiver table anyway > * However, this requires the first seqno from B *to always be 0* > --> Investigate whether the first seqno in UNICAST3 is always 0, then this solution will work -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2019