July 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JGRP-457) Optimization: make threads return immediately if NAKACK has another active thread for the same sender

by Bela Ban (JIRA)

Optimization: make threads return immediately if NAKACK has another active thread for the same sender ----------------------------------------------------------------------------------------------------- Key: JGRP-457 URL: http://jira.jboss.com/jira/browse/JGRP-457 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assigned To: Bela Ban Priority: Minor Fix For: 2.5 In NAKACK, when a thread places a message for sender S into the NakReceiverWindow NRW, it subsequently acquires a lock on NRW (lock by sender) and removes as many messages as possible and passes them up. If many threads do this at the same time, all threads but one are blocked, and - when finally unblocked - usually return. This causes context switches and possibly cache flushing, so a better way would be to have the threads check whether another thread is already removing messages using a CAS operation *before* acquiring the lock. The effect should be that no threads will wait on the lock unnecessarily, and thus fewer context switches, and more threads available to the pool. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 week, 2 days

2
3
0 / 0

[JBoss JIRA] (ELY-776) Eliminate reference to "slot" from module configurations

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-776?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse reassigned ELY-776: ------------------------------------ Assignee: Darran Lofthouse > Eliminate reference to "slot" from module configurations > -------------------------------------------------------- > > Key: ELY-776 > URL: https://issues.jboss.org/browse/ELY-776 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Client > Reporter: David Lloyd > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta15 > > > The final version of our client XSD should accept a name for modules but no slot. Instead, either the new name-only APIs should be used or a ModuleIdentifier created via that class's "fromString" method. Module slots are deprecated. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

1 month

2
1
0 / 0

[JBoss JIRA] (JBRULES-3445) DSL expander expands lines in /* */comment block

by Mario Fusco (JIRA)

Mario Fusco created JBRULES-3445: ------------------------------------ Summary: DSL expander expands lines in /* */comment block Key: JBRULES-3445 URL: https://issues.jboss.org/browse/JBRULES-3445 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Mario Fusco Assignee: Mario Fusco When you comment some code in dslr file, the expander still tries to expand it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

6 months

3
10
0 / 0

[JBoss JIRA] (WFLY-9138) Warning message mistake

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-9138?page=com.atlassian.jira.plugin.... ] Stuart Douglas resolved WFLY-9138. ---------------------------------- Resolution: Duplicate Issue https://issues.jboss.org/browse/WFLY-7228 > Warning message mistake > ----------------------- > > Key: WFLY-9138 > URL: https://issues.jboss.org/browse/WFLY-9138 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Affects Versions: 10.1.0.Final > Reporter: Baturman Şen > Assignee: Stuart Douglas > Priority: Trivial > > I am not native english speaker but, following warning message should be fixed. > {panel:title=Original Message} > 09:52:31,242 WARN [org.jboss.weld.deployer] (MSC service thread 1-5) WFLYWELD0013: Deployment deployment "xxxx" contains CDI annotations but no bean archive was not found. (No beans.xml nor class with bean defining annotations) > {panel} > {panel:title=Fixed Message} > 09:52:31,242 WARN [org.jboss.weld.deployer] (MSC service thread 1-5) WFLYWELD0013: Deployment "xxxx" contains CDI annotations but no bean archive was found. (No beans.xml nor class with bean defining annotations) > {panel} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-153) [QE] - INV-008 View Relationships between EAP servers and VMs that run a Linux OS and navigate across the relationships

by Vojtech Prusa (JIRA)

Vojtech Prusa created HAWKULARQE-153: ---------------------------------------- Summary: [QE] - INV-008 View Relationships between EAP servers and VMs that run a Linux OS and navigate across the relationships Key: HAWKULARQE-153 URL: https://issues.jboss.org/browse/HAWKULARQE-153 Project: Hawkular QE Issue Type: Task Environment: Need instances CFME, RHEVM, HS and EAP monitored by this HS when EAP is running on VM under RHEVM. Reporter: Vojtech Prusa Assignee: Michael Foley Manually tested. Automate https://trello.com/c/oBeMkciI/254-inv-008-view-relationships-between-eap-... Use JON QE RHEVMs test user. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3073) Handle TERM gracefully

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3073?page=com.atlassian.jira.plugi... ] Brian Stansberry edited comment on WFCORE-3073 at 7/31/17 5:59 PM: ------------------------------------------------------------------- Requirement analysis doc for this feature: https://developer.jboss.org/docs/DOC-56032 Possible implementation is at https://github.com/wildfly/wildfly-core/compare/master...bstansberry:WFCO.... Manual use and an integration test shows the suspend logic gets invoked as expected. was (Author: brian.stansberry): Requirement analysis doc for this feature: https://developer.jboss.org/docs/DOC-56032 Possible implementation is at https://github.com/wildfly/wildfly-core/compare/master...bstansberry:WFCO..., although that needs an integration test. Manual use shows the suspend logic gets invoked as expected. > Handle TERM gracefully > ---------------------- > > Key: WFCORE-3073 > URL: https://issues.jboss.org/browse/WFCORE-3073 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Ben Parees > Assignee: Brian Stansberry > Fix For: 4.0.0.Alpha1 > > > The wildfly server currently terminates immediately in response to a TERM signal. To achieve a clean shutdown requires invoking the CLI tooling. This is particularly problematic in container environments like kubernetes where the container process (wildfly in this case) is going to get a TERM signal when the container needs to be moved. > While it's possible to wrapper the process and handle the TERM and then invoke the CLI, it would be preferable for the server process itself to cleanly handle a TERM signal by waiting for in-flight requests to complete (w/ some grace period of course). > Having this as configurable behavior would be good if there are backwards compatibility concerns about introducing this behavior change. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3103) Embedded server doesn't close open file handles

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3103?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-3103: ---------------------------------------- Assignee: Ken Wills (was: Brian Stansberry) [~luck3y] I'm going to pass this one over to you. https://github.com/wildfly/wildfly-core/compare/master...bstansberry:WFCO... has my experiment on that, but the testsuite does not pass. To get meaningful behavior with it you have to run with David's jboss-modules branch with the MODULES-301 commit in it. For sure https://github.com/wildfly/wildfly-core/compare/master...bstansberry:WFCO... or something like it has to happen, otherwise we close the boot module loader which is wrongness. But when I make that change things blow up. > Embedded server doesn't close open file handles > ----------------------------------------------- > > Key: WFCORE-3103 > URL: https://issues.jboss.org/browse/WFCORE-3103 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Modules > Reporter: Jan Blizňák > Assignee: Ken Wills > > When embedded server is started programatically (eg. via CLI wrapper) with specified jboss home, JARs from that path are opened via classloader. But these open handles are never released even after embedded server is stopped. > This causes problem in situation eg. when you want to delete that jboss home. This is exactly one of the scenarios used in EAP installer, you are not allowed to delete open files on Windows - see JBEAP-1404. > I created a simple project that reproduce the issue with arbitrary EAP/WF distribution https://github.com/jbliznak/embedded-server-filelocking > Run it with: > mvn clean test "-Dwildfly.home=C:\dev\jboss-eap-7.1" "-Denforcer.skip" -Dtest=ModulesFileLockingTestCase > Manual steps to reproduce in Java code: > * start a CLI wrapper > * start embed-server from given server path > * stop embed-server > * terminate CLI wrapper > * try to delete given server path -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1685) Improve performance of rules using "or" in LHS

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1685?page=com.atlassian.jira.plugi... ] Mario Fusco commented on DROOLS-1685: ------------------------------------- The rulesets you pasted are not totally equivalent. In the first one you have {code} entity.entityTypeId in ( 291262 ) {code} while in second {code} entity.entityTypeId == 291262 {code} I think this could make a huge difference performance wise because only the second constraint can be indexed. If your problem persists after having fixed this difference please send a complete reproducer so I could further investigate this problem. > Improve performance of rules using "or" in LHS > ---------------------------------------------- > > Key: DROOLS-1685 > URL: https://issues.jboss.org/browse/DROOLS-1685 > Project: Drools > Issue Type: Enhancement > Components: core engine, kie server > Affects Versions: 6.5.0.Final > Reporter: Russell Morrisey > Assignee: Mario Fusco > > The following two rulesets produce the same output, but their performance differs dramatically. > My understanding is that the two rulesets should be equivalent to one another. It seems like the 'or' operation must be handled inefficiently by the engine. Is there anything that can be improved the engine's performance in this case? > Ruleset #1 takes ~3 seconds to execute on my local machine (for a dataset with 3 entities, 1 service ordered each). Ruleset #2 runs in ~200 ms. > *Ruleset 1* > {code:java} > rule "Rule183" > dialect "mvel" > when > $entity : Entity( ) > ( $service : ServiceOrdered( serviceId == "FORM" , entity == $entity , entity.entityTypeId in ( 291262, 291275, 291277 ) ) or $service : ServiceOrdered( serviceId == "DISSO" , entity == $entity , entity.entityTypeId in ( 291262 ) , stateId == 290864 ) ) > $r1 : QuestionDefinition( id == 590 ) > then > Question fact0 = new Question(); > fact0.setQuestionDefinition( $r1 ); > fact0.setEntity( $entity ); > insert( fact0 ); > end > {code} > *Ruleset 2* > {code:java} > rule "Rule183" > dialect "mvel" > when > $entity : Entity( ) > $service : ServiceOrdered( serviceId == "FORM" , entity == $entity , entity.entityTypeId in ( 291262, 291275, 291277 ) ) > $r1 : QuestionDefinition( id == 590 ) > then > Question fact0 = new Question(); > fact0.setQuestionDefinition( $r1 ); > fact0.setEntity( $entity ); > insert( fact0 ); > end > {code} > {code} > rule "Rule183-2" > dialect "mvel" > when > $entity : Entity( ) > $service : ServiceOrdered( serviceId == "DISSO" , entity == $entity , entity.entityTypeId == 291262 , stateId == 290864 ) > $r1 : QuestionDefinition( id == 590 ) > then > Question fact0 = new Question(); > fact0.setQuestionDefinition( $r1 ); > fact0.setEntity( $entity ); > insert( fact0 ); > end > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1684) Java Types introduced after an incremental compilation aren't correctly processed

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1684?page=com.atlassian.jira.plugi... ] Mario Fusco commented on DROOLS-1684: ------------------------------------- Cherry-picked to branch 7.2.x with https://github.com/kiegroup/drools/commit/95231ec83 > Java Types introduced after an incremental compilation aren't correctly processed > --------------------------------------------------------------------------------- > > Key: DROOLS-1684 > URL: https://issues.jboss.org/browse/DROOLS-1684 > Project: Drools > Issue Type: Bug > Components: core engine > Reporter: Mario Fusco > Assignee: Mario Fusco > Fix For: 7.2.0.Final > > > Java Types introduced after an incremental compilation are not property reactive by default as expected and in more in general they declaration is not correctly processed. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1684) Java Types introduced after an incremental compilation aren't correctly processed

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1684?page=com.atlassian.jira.plugi... ] Mario Fusco updated DROOLS-1684: -------------------------------- Fix Version/s: 7.2.0.Final > Java Types introduced after an incremental compilation aren't correctly processed > --------------------------------------------------------------------------------- > > Key: DROOLS-1684 > URL: https://issues.jboss.org/browse/DROOLS-1684 > Project: Drools > Issue Type: Bug > Components: core engine > Reporter: Mario Fusco > Assignee: Mario Fusco > Fix For: 7.2.0.Final > > > Java Types introduced after an incremental compilation are not property reactive by default as expected and in more in general they declaration is not correctly processed. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2017