December 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-680) "contains" operator behaves inconsistently when used with Maps

by Michael Biarnes Kiefer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-680?page=com.atlassian.jira.plugin... ] Michael Biarnes Kiefer updated DROOLS-680: ------------------------------------------ Fix Version/s: 7.0.0.CR1 (was: 7.0.0.Beta5) > "contains" operator behaves inconsistently when used with Maps > -------------------------------------------------------------- > > Key: DROOLS-680 > URL: https://issues.jboss.org/browse/DROOLS-680 > Project: Drools > Issue Type: Bug > Affects Versions: 5.6.0.Final, 6.0.1.Final, 6.1.0.Final, 6.2.0.CR4 > Reporter: Davide Sottara > Assignee: Mario Fusco > Fix For: 7.0.0.CR1 > > > In a rule > {code} > Bean( map contains "x" ) // assuming "map" is a property of type Map > {code} > "contains" is arbitrarily interpreted as "containsKey" > The constrain will then fail after being jitted > The documentation explicitly states that "contains" applies to collections -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-817) Extremely poor performance of the topological sorting implementation for type declarations performs

by Michael Biarnes Kiefer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-817?page=com.atlassian.jira.plugin... ] Michael Biarnes Kiefer updated DROOLS-817: ------------------------------------------ Fix Version/s: 7.0.0.CR1 (was: 7.0.0.Beta5) > Extremely poor performance of the topological sorting implementation for type declarations performs > ---------------------------------------------------------------------------------------------------- > > Key: DROOLS-817 > URL: https://issues.jboss.org/browse/DROOLS-817 > Project: Drools > Issue Type: Enhancement > Components: core engine > Affects Versions: 6.0.0.Final, 6.0.1.Final, 6.1.0.Final, 6.2.0.Final, 6.3.0.Beta1 > Reporter: Davide Sottara > Assignee: Davide Sottara > Priority: Minor > Fix For: 7.0.0.CR1 > > > The current implementation suffers from thrashing. > In case of large business object models (e.g. derived from an ontology), > the analysis at package build time may take orders of magnitude more > than necessary -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-744) Rule Generation Feature Request

by Michael Biarnes Kiefer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-744?page=com.atlassian.jira.plugin... ] Michael Biarnes Kiefer updated DROOLS-744: ------------------------------------------ Fix Version/s: 7.0.0.CR1 (was: 7.0.0.Beta5) > Rule Generation Feature Request > ------------------------------- > > Key: DROOLS-744 > URL: https://issues.jboss.org/browse/DROOLS-744 > Project: Drools > Issue Type: Feature Request > Components: core engine, kie server > Affects Versions: 6.2.0.Final > Reporter: Justin Holmes > Assignee: Mario Fusco > Fix For: 7.0.0.CR1 > > > As a developer using Drools, I want a rule generation java api that supports control logic in the rule templates (e.g. for loops, if/else) and integrates with the rule workbench in order to build highly dynamic business rules driven systems. > The initial thought process around implementation is to build two things 1) a simple way to author mvel templates in business central, the existing text editor could be used at first and 2) a simple embedded java api in it's own maven module which can checkout the git project that has the mvel template, apply a set of domain objects to the template, check in the resulting rule files to the local git repo and then push the changes back to business central. This allows us to leverage the power of the existing MVEL and JGit tech stack while pushing the complexity to a java api, where we are stronger than the workbench itself. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7834) A test for loading custom login modules from non-default JBoss modules [SECURITY-930][WFLY-7412]

by Peter Palaga (JIRA)

[ https://issues.jboss.org/browse/WFLY-7834?page=com.atlassian.jira.plugin.... ] Peter Palaga updated WFLY-7834: ------------------------------- Summary: A test for loading custom login modules from non-default JBoss modules [SECURITY-930][WFLY-7412] (was: Test for loading custom login modules from non-default JBoss modules [SECURITY-930][WFLY-7412]) > A test for loading custom login modules from non-default JBoss modules [SECURITY-930][WFLY-7412] > ------------------------------------------------------------------------------------------------ > > Key: WFLY-7834 > URL: https://issues.jboss.org/browse/WFLY-7834 > Project: WildFly > Issue Type: Task > Components: Test Suite > Reporter: Peter Palaga > Assignee: Peter Palaga > > Add an integration test that will prove that SECURITY-930 and WFLY-7412 were properly fixed. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-735) Remove unwanted OptaPlanner references from website sources

by Michael Biarnes Kiefer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-735?page=com.atlassian.jira.plugin... ] Michael Biarnes Kiefer resolved DROOLS-735. ------------------------------------------- Resolution: Done > Remove unwanted OptaPlanner references from website sources > ----------------------------------------------------------- > > Key: DROOLS-735 > URL: https://issues.jboss.org/browse/DROOLS-735 > Project: Drools > Issue Type: Bug > Reporter: Petr Široký > Assignee: Michael Biarnes Kiefer > > There are still some unwanted references to OptaPlanner in the Drools website sources. For example the https://github.com/droolsjbpm/drools-website/blob/master/_config/site.yml contains keywords related to OptaPlanner rather than Drools. > There are probably others. We need to fix those. > Note: not every reference is necessarily unwanted. There may be some links or other info about OptaPlanner that we want to keep there. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7834) Test for loading custom login modules from non-default JBoss modules [SECURITY-930][WFLY-7412]

by Peter Palaga (JIRA)

Peter Palaga created WFLY-7834: ---------------------------------- Summary: Test for loading custom login modules from non-default JBoss modules [SECURITY-930][WFLY-7412] Key: WFLY-7834 URL: https://issues.jboss.org/browse/WFLY-7834 Project: WildFly Issue Type: Task Components: Test Suite Reporter: Peter Palaga Assignee: Peter Palaga Add an integration test that will prove that SECURITY-930 and WFLY-7412 were properly fixed. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2141) JMX notifications for ControlledProcessState changes are not updated when the running mode changes

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2141?page=com.atlassian.jira.plugi... ] ehsavoie Hugonnet updated WFCORE-2141: -------------------------------------- Summary: JMX notifications for ControlledProcessState changes are not updated when the running mode changes (was: JMX notifications for ControlledProcessState changes are not sent in admin-only mode) > JMX notifications for ControlledProcessState changes are not updated when the running mode changes > -------------------------------------------------------------------------------------------------- > > Key: WFCORE-2141 > URL: https://issues.jboss.org/browse/WFCORE-2141 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Alpha16 > Reporter: ehsavoie Hugonnet > Assignee: ehsavoie Hugonnet > > JMX notifications added by https://issues.jboss.org/browse/EAP7-471 are not sent in admin-only mode. When notifications are active and the server gets reloaded into admin-only mode, only the normal->stopping transition is received and nothing more after that. > The cause seems to be in the fact that these notifications depend on the {{jboss.mbean.server}} MSC service, but that doesn't exist in admin-only mode. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2141) JMX notifications for ControlledProcessState changes are not updated when the running mode changes

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2141?page=com.atlassian.jira.plugi... ] ehsavoie Hugonnet updated WFCORE-2141: -------------------------------------- Description: When notifications are active and the server gets reloaded into admin-only mode we still have notifications to 'normal' mode. (was: JMX notifications added by https://issues.jboss.org/browse/EAP7-471 are not sent in admin-only mode. When notifications are active and the server gets reloaded into admin-only mode, only the normal->stopping transition is received and nothing more after that. The cause seems to be in the fact that these notifications depend on the {{jboss.mbean.server}} MSC service, but that doesn't exist in admin-only mode.) > JMX notifications for ControlledProcessState changes are not updated when the running mode changes > -------------------------------------------------------------------------------------------------- > > Key: WFCORE-2141 > URL: https://issues.jboss.org/browse/WFCORE-2141 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Alpha16 > Reporter: ehsavoie Hugonnet > Assignee: ehsavoie Hugonnet > > When notifications are active and the server gets reloaded into admin-only mode we still have notifications to 'normal' mode. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2141) JMX notifications for ControlledProcessState changes are not sent in admin-only mode

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2141?page=com.atlassian.jira.plugi... ] ehsavoie Hugonnet moved JBEAP-7990 to WFCORE-2141: -------------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2141 (was: JBEAP-7990) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Domain Management (was: Domain Management) Affects Version/s: 3.0.0.Alpha16 (was: 7.1.0.DR9) > JMX notifications for ControlledProcessState changes are not sent in admin-only mode > ------------------------------------------------------------------------------------ > > Key: WFCORE-2141 > URL: https://issues.jboss.org/browse/WFCORE-2141 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Alpha16 > Reporter: ehsavoie Hugonnet > Assignee: ehsavoie Hugonnet > > JMX notifications added by https://issues.jboss.org/browse/EAP7-471 are not sent in admin-only mode. When notifications are active and the server gets reloaded into admin-only mode, only the normal->stopping transition is received and nothing more after that. > The cause seems to be in the fact that these notifications depend on the {{jboss.mbean.server}} MSC service, but that doesn't exist in admin-only mode. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2143) TP: use only one thread per member to pass up regular messages

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2143?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2143: -------------------------------- I introduced {{MessageProcessingPolicy}} which giverns how received messages (or batches) are processed. The default policy is {{SubmitToThreadPool}} which is the current default as described at the top. The policy implementing JGRP-2143 is {{MaxOneThreadPerSender}} which implements the suggested solution. The policy can be set using attribute {{message_processing_policy}} or managed operation {{setMessageProcessingPolicy}}, ie. at runtime. > TP: use only one thread per member to pass up regular messages > -------------------------------------------------------------- > > Key: JGRP-2143 > URL: https://issues.jboss.org/browse/JGRP-2143 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > This applies only to _regular_ messages; OOB and internal messages are processed by passing them to the thread pool directly when they they're received. > The processing of a message received from B is as follows: > * A regular message (or message batch) is assigned a thread from the thread pool and passed up to the reliability protocol, e.g. NAKACK2 or UNICAST3. > * There is is added to the table for B. > * The thread sees if another thread is already delivering messages from B to the application. If not, it grabs as many consecutive (ordered) messages from the table as it can and delivers them to the application. Otherwise, it returns and can be assigned other tasks. > The problem here is that more than one thread may be passing up messages from a given sender B; only at the NAKACK2 or UNICAST3 level will a single thread be selected to deliver the messages to the application. > This causes higher thread pool usage than required, with all of its drawbacks, e.g. more context switching, higher contention on adding messages to the table for B, and possibly exhaustion of the thread pool. > An example of where service is denied or delayed: > * We have a cluster of \{A,B,C,D\} > * A receives 10 messages from B, 4 from C and 1 from D > * The thread pool's max size is 20 > * The 10 messages from B are processed; all 10 threads add their messages to the table, but only 1 delivers them to the application and the other 9 return to the pool > * 4 messages from C are added to C's table, 1 thread delivers them and 3 return > * The 1 message from D is added to D's table and the same thread is used to deliver the message up the stack to the application > So while we receive 15 messages, effectively only 3 threads are needed to deliver them to the application: as these are regular messages, they need to be delivered in _sender order_. > The 9 threads which process messages from B are only adding them to B's table and then return immediately. This causes increased context switching, plus more contention on B's table (which is synchronized), and possibly exhaustion of the thread pool. For example, if the pool's max size was only 10, then processing the first 10 messages from B would exhaust the table, and the other messages from C and D would be processed in newly spawned threads. > SOLUTION > * (Only applicable to _regular_ messages) > * When a message (or batch) from sender P is received, we check if another thread is already passing up messages from B. If not, we pass the message up by grabbing a thread from the thread pool. This will add the message to P's table and deliver as many messages (from from the table) as possible to the application. > * If there's currently a thread delivering P's message, we simply add the message (or batch) to a queue for P and return. > * When the delivery thread returns, it checks the queue for P and delivers all queued messages, or returns if the queue is empty. > * (The queue is actually a MessageBatch, and new messages are simply appended to it. On delivery, the batch is cleared) > The effects of this for regular messages are > * Fewer threads: the thread pool only has a max of <cluster-members> threads for regular messages where <cluster-members> is the number of members in the cluster from whom we are concurrently receiving messages. E.g. for a cluster \{A,B,C,D\}, if we're receiving messages at the same time from all members, then the max size is 4. > ** Of course, OOB and internal messages, plus timer tasks will add to this number. > * Less contention on the table for a given member: instead of 10 threads all adding their messages to B's table (contention on the table lock) and then CASing a boolean, only 1 thread ever adds and removes messages to/from the table. This means uncontended (= fast) lock acquisition for regular messages (of course, if we use OOB messages, then we do have contention). > * Appending to a batch is much faster then adding to a table > * The downside is that we're storing messages actually twice: once in the batch for P and once in P's table. But these are arrays of pointers, so not a lot of memory required. > Example: the 10 threads for messages from B above, will create a batch of 9 messages in B's queue and grab 1 thread from the pool to deliver its message. When the thread is done, it will grab the message batch of 9 and also add it to the table and deliver it. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 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 December 2016