February 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-2445) MessageBatch: removal on iteration is inefficient

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2445?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2445: --------------------------- Description: We oftentimes have iteration through a MessageBatch and removal, e.g. {code:java} for(Message msg: batch) { if(condition) batch.remove(msg); } } {code} This is inefficient for large batches, as {{MessageBatch.remove()}} iterates through the batch until it finds the message to be nulled. It is more efficient to use {{BatchIterator.remove()}}. Also include a {{BatchIterator.replace()}} method. Pedro's code: [1] https://github.com/pruivo/JGroups/tree/t_msg_batch_iterator was: We oftentimes have iteration through a MessageBatch and removal, e.g. {code:java} for(Message msg: batch) { if(condition) batch.remove(msg); } } {code} This is inefficient for large batches, as {{MessageBatch.remove()}} iterates through the batch until it finds the message to be nulled. It is more efficient to use {{BatchIterator.remove()}}. Pedro's code: [1] https://github.com/pruivo/JGroups/tree/t_msg_batch_iterator > MessageBatch: removal on iteration is inefficient > ------------------------------------------------- > > Key: JGRP-2445 > URL: https://issues.redhat.com/browse/JGRP-2445 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 5.0, 4.2.0 > > > We oftentimes have iteration through a MessageBatch and removal, e.g. > {code:java} > for(Message msg: batch) { > if(condition) > batch.remove(msg); > } > } > {code} > This is inefficient for large batches, as {{MessageBatch.remove()}} iterates through the batch until it finds the message to be nulled. > It is more efficient to use {{BatchIterator.remove()}}. > Also include a {{BatchIterator.replace()}} method. > Pedro's code: [1] https://github.com/pruivo/JGroups/tree/t_msg_batch_iterator -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2446) MessageBatch: iterate with filter

by Bela Ban (Jira)

Bela Ban created JGRP-2446: ------------------------------ Summary: MessageBatch: iterate with filter Key: JGRP-2446 URL: https://issues.redhat.com/browse/JGRP-2446 Project: JGroups Issue Type: Enhancement Reporter: Bela Ban Assignee: Bela Ban Fix For: 5.0 Create a {{MessageBatch.BatchIterator}} with a predicate that defines which messages are selected by the iterator. Non-selected messages are skipped. See the code in Pedro's branch [1]. [1] https://github.com/pruivo/JGroups/tree/t_msg_batch_iterator -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2445) MessageBatch: removal on iteration is inefficient

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2445?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2445: --------------------------- Description: We oftentimes have iteration through a MessageBatch and removal, e.g. {code:java} for(Message msg: batch) { if(condition) batch.remove(msg); } } {code} This is inefficient for large batches, as {{MessageBatch.remove()}} iterates through the batch until it finds the message to be nulled. It is more efficient to use {{BatchIterator.remove()}}. Pedro's code: [1] https://github.com/pruivo/JGroups/tree/t_msg_batch_iterator was: We oftentimes have iteration through a MessageBatch and removal, e.g. {code:java} for(Message msg: batch) { if(condition) batch.remove(msg); } } {code} This is inefficient for large batches, as {{MessageBatch.remove()}} iterates through the batch until it finds the message to be nulled. It is more efficient to use {{BatchIterator.remove()}}. > MessageBatch: removal on iteration is inefficient > ------------------------------------------------- > > Key: JGRP-2445 > URL: https://issues.redhat.com/browse/JGRP-2445 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 5.0, 4.2.0 > > > We oftentimes have iteration through a MessageBatch and removal, e.g. > {code:java} > for(Message msg: batch) { > if(condition) > batch.remove(msg); > } > } > {code} > This is inefficient for large batches, as {{MessageBatch.remove()}} iterates through the batch until it finds the message to be nulled. > It is more efficient to use {{BatchIterator.remove()}}. > Pedro's code: [1] https://github.com/pruivo/JGroups/tree/t_msg_batch_iterator -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4833) Cannot configure Elytron legacy security domain integration in admin-only mode

by Yeray Borges (Jira)

Yeray Borges created WFCORE-4833: ------------------------------------ Summary: Cannot configure Elytron legacy security domain integration in admin-only mode Key: WFCORE-4833 URL: https://issues.redhat.com/browse/WFCORE-4833 Project: WildFly Core Issue Type: Bug Affects Versions: 10.0.0.Beta2 Reporter: Yeray Borges Assignee: Yeray Borges The following sequence can be configured using the embedded server, however it doesn't work when we start the server in admin only: {noformat} /subsystem=security/security-domain=HiThere:add(cache-type=default) /subsystem=security/security-domain=HiThere/authentication=classic:add(login-modules=[{code="UsersRoles", flag=required, module-options={"usersProperties"=>"${jboss.server.config.dir}/users.properties","rolesProperties"=>"${jboss.server.config.dir}/roles.properties"}}]) /subsystem=security/elytron-realm=HiThere:add(legacy-jaas-config=HiThere) /subsystem=elytron/security-domain=HiThere:add(realms=[{realm=HiThere}],default-realm=HiThere,permission-mapper=default-permission-mapper) /subsystem=elytron/http-authentication-factory=HiThere-http:add(http-server-mechanism-factory=global,security-domain=HiThere,mechanism-configurations=[{mechanism-name=BASIC},{mechanism-name=FORM}]) {noformat} Executing it in admin-only mode, the following exception is thrown on the last command: {noformat} [standalone@localhost:9990 /] /subsystem=elytron/http-authentication-factory=HiThere-http:add(http-server-mechanism-factory=global,security-domain=HiThere,mechanism-configurations=[{mechanism-name=BASIC},{mechanism-name=FORM}]) { "outcome" => "failed", "failure-description" => undefined, "rolled-back" => true } {noformat} {noformat} 11:43:43,034 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 19.0.0.Beta2-SNAPSHOT (WildFly Core 11.0.0.Beta8-SNAPSHOT) started in 129ms - Started 81 of 90 services (32 services are lazy, passive or on-demand) 11:43:47,923 INFO [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0183: Service status report WFLYCTL0184: New missing/unsatisfied dependencies: service org.wildfly.security.security-realm.HiThere (missing) dependents: [service org.wildfly.security.security-domain.HiThere.initial] WFLYCTL0448: 1 additional services are down due to their dependencies being missing or failed {noformat} The execution using the embedded server works fine. This issue basically is a follow up on WFCORE-4407, where we fixed this issue on the embedded server, however, it looks like we were pretty conservative with the changes. Now we need this on a standard admin-only server mode to allow cloud images to apply the server configuration using CLI operations. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2445) MessageBatch: removal on iteration is inefficient

by Bela Ban (Jira)

Bela Ban created JGRP-2445: ------------------------------ Summary: MessageBatch: removal on iteration is inefficient Key: JGRP-2445 URL: https://issues.redhat.com/browse/JGRP-2445 Project: JGroups Issue Type: Enhancement Reporter: Bela Ban Assignee: Bela Ban Fix For: 5.0, 4.2.0 We oftentimes have iteration through a MessageBatch and removal, e.g. {code:java} for(Message msg: batch) { if(condition) batch.remove(msg); } } {code} This is inefficient for large batches, as {{MessageBatch.remove()}} iterates through the batch until it finds the message to be nulled. It is more efficient to use {{BatchIterator.remove()}}. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5000) Support getContext in Drools' executable model

by Luca Molteni (Jira)

[ https://issues.redhat.com/browse/DROOLS-5000?page=com.atlassian.jira.plug... ] Luca Molteni reassigned DROOLS-5000: ------------------------------------ Assignee: Mario Fusco (was: Luca Molteni) > Support getContext in Drools' executable model > ---------------------------------------------- > > Key: DROOLS-5000 > URL: https://issues.redhat.com/browse/DROOLS-5000 > Project: Drools > Issue Type: Bug > Components: executable model > Reporter: Luca Molteni > Assignee: Mario Fusco > Priority: Major > > jBPM uses this utility method in Knowledge Helper > package org.drools.bpmn2 > import org.kie.api.runtime.process.ProcessContext > rule "Auto-activate Hello1" ruleflow-group "Hello" > when > then > System.out.println(drools); > System.out.println(drools.getContext(ProcessContext.class)); System.out.println(drools.getContext(ProcessContext.class).getProcessInstance()); > drools.getContext(ProcessContext.class).getProcessInstance().signalEvent("Hello1", null); > end -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5000) Support getContext in Drools' executable model

by Luca Molteni (Jira)

[ https://issues.redhat.com/browse/DROOLS-5000?page=com.atlassian.jira.plug... ] Luca Molteni updated DROOLS-5000: --------------------------------- Sprint: 2020 Week 04-06 (from Jan 20) > Support getContext in Drools' executable model > ---------------------------------------------- > > Key: DROOLS-5000 > URL: https://issues.redhat.com/browse/DROOLS-5000 > Project: Drools > Issue Type: Bug > Components: executable model > Reporter: Luca Molteni > Assignee: Luca Molteni > Priority: Major > > jBPM uses this utility method in Knowledge Helper > package org.drools.bpmn2 > import org.kie.api.runtime.process.ProcessContext > rule "Auto-activate Hello1" ruleflow-group "Hello" > when > then > System.out.println(drools); > System.out.println(drools.getContext(ProcessContext.class)); System.out.println(drools.getContext(ProcessContext.class).getProcessInstance()); > drools.getContext(ProcessContext.class).getProcessInstance().signalEvent("Hello1", null); > end -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4868) HA-CEP test with Executable Model

by Luca Molteni (Jira)

[ https://issues.redhat.com/browse/DROOLS-4868?page=com.atlassian.jira.plug... ] Luca Molteni updated DROOLS-4868: --------------------------------- Sprint: 2019 Week 50-52 (from Dec 9), 2020 Week 01-03 (from Dec 30) (was: 2019 Week 50-52 (from Dec 9), 2020 Week 01-03 (from Dec 30), 2020 Week 04-06 (from Jan 20)) > HA-CEP test with Executable Model > --------------------------------- > > Key: DROOLS-4868 > URL: https://issues.redhat.com/browse/DROOLS-4868 > Project: Drools > Issue Type: Bug > Reporter: Luca Molteni > Assignee: Luca Molteni > Priority: Major > > org.kie.hacep.PodAsLeaderSnapshotTest.processMessagesAsLeaderAndCreateSnapshotTest -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4984) Enable the executable model in Optaplanner

by Luca Molteni (Jira)

[ https://issues.redhat.com/browse/DROOLS-4984?page=com.atlassian.jira.plug... ] Luca Molteni updated DROOLS-4984: --------------------------------- Sprint: (was: 2020 Week 04-06 (from Jan 20)) > Enable the executable model in Optaplanner > ------------------------------------------ > > Key: DROOLS-4984 > URL: https://issues.redhat.com/browse/DROOLS-4984 > Project: Drools > Issue Type: Bug > Components: executable model > Reporter: Luca Molteni > Assignee: Luca Molteni > Priority: Major > > Currently it's disabled -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5003) Avoid generating the executable model sources if drools-model-compiler is not in the pom.xml file

by Luca Molteni (Jira)

[ https://issues.redhat.com/browse/DROOLS-5003?page=com.atlassian.jira.plug... ] Luca Molteni updated DROOLS-5003: --------------------------------- Sprint: 2020 Week 04-06 (from Jan 20) > Avoid generating the executable model sources if drools-model-compiler is not in the pom.xml file > ------------------------------------------------------------------------------------------------- > > Key: DROOLS-5003 > URL: https://issues.redhat.com/browse/DROOLS-5003 > Project: Drools > Issue Type: Enhancement > Components: executable model > Reporter: Luca Molteni > Assignee: Luca Molteni > Priority: Major > > Currently, if you try to generate the executable model using the kie-maven-plugin with > YES or YES_WITHDRL > but you forget to add the drools-model-compiler the plugin will generate the sources but the compile phase will fail. > It should be better to avoid generating the source, revert to the NO behaviour and show a warning of what happened. > This will help the migration as customer who will upgrade to 7.7 will have the exec model as a default but they won't have the jar in the pom.xml -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 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 2020