January 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1980) Improve throughput under contention for FlowControl.Credit

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1980?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-1980 at 1/22/16 3:54 AM: --------------------------------------------------------- Correction: {{needsToSendCreditRequest()}} is only called when there are insufficient credits left, so this is *not* 50%! was (Author: belaban): Correction: {{needsToSendCerditRequest()}} is only called when there are insufficient credits left, so this is *not* 50%! > Improve throughput under contention for FlowControl.Credit > ---------------------------------------------------------- > > Key: JGRP-1980 > URL: https://issues.jboss.org/browse/JGRP-1980 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.6.6 > Reporter: Sanne Grinovero > Assignee: Bela Ban > Fix For: 3.6.8 > > Attachments: bla.java > > > The methods {{org.jgroups.protocols.FlowControl.Credit.decrementIfEnoughCredits(long, long)}} and {{org.jgroups.protocols.FlowControl.Credit.decrementAndGet(long)}} are contending the locks on class synchronization when stress testing JGroups. > Wondering if we can think of polishing the implementation, although it looks like challenging. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1980) Improve throughput under contention for FlowControl.Credit

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1980?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1980: -------------------------------- Correction: {{needsToSendCerditRequest()}} is only called when there are insufficient credits left, so this is *not* 50%! > Improve throughput under contention for FlowControl.Credit > ---------------------------------------------------------- > > Key: JGRP-1980 > URL: https://issues.jboss.org/browse/JGRP-1980 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.6.6 > Reporter: Sanne Grinovero > Assignee: Bela Ban > Fix For: 3.6.8 > > Attachments: bla.java > > > The methods {{org.jgroups.protocols.FlowControl.Credit.decrementIfEnoughCredits(long, long)}} and {{org.jgroups.protocols.FlowControl.Credit.decrementAndGet(long)}} are contending the locks on class synchronization when stress testing JGroups. > Wondering if we can think of polishing the implementation, although it looks like challenging. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBWEB-248) The default error report class valve should be overridable

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBWEB-248?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBWEB-248: ----------------------------------------------- Carlo de Wolf <cdewolf(a)redhat.com> changed the Status of [bug 1166584|https://bugzilla.redhat.com/show_bug.cgi?id=1166584] from NEW to CLOSED > The default error report class valve should be overridable > ---------------------------------------------------------- > > Key: JBWEB-248 > URL: https://issues.jboss.org/browse/JBWEB-248 > Project: JBoss Web > Issue Type: Feature Request > Components: Tomcat > Affects Versions: JBossWeb-7.0.15.GA, JBossWeb-7.0.16.GA > Reporter: Vincent MATHON > Assignee: Remy Maucherat > > The default error report valve class cannot be configured since JBoss 7.x. > The current default implementation (org.apache.catalina.valves.ErrorReportValve) prints the stack trace if any or some server informations. This can be considered as a security issue, so, it would be great to be able to configure a custom error report valve class or at least to be able to filter informations printed by the default one. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1030) Nullpointer in JpaTimerJobInstance.call on startup

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1030?page=com.atlassian.jira.plugi... ] Mario Fusco updated DROOLS-1030: -------------------------------- Issue Type: Bug (was: Feature Request) > Nullpointer in JpaTimerJobInstance.call on startup > --------------------------------------------------- > > Key: DROOLS-1030 > URL: https://issues.jboss.org/browse/DROOLS-1030 > Project: Drools > Issue Type: Bug > Components: core engine > Environment: Mac OS 10.10.5, Eclipse Mars Release, Java 1.8, Drools 6.3.0.Final > Reporter: Artur Kronenberg > Assignee: Mario Fusco > Attachments: test-standalone.zip > > > Hi, > I have noticed Nullpointer exceptions when I try and reload a persisted session on startup. It is a bit hard to recreate (I am actually not managing it now since I deleted all old sessions to attempt recreation) but I figured maybe someone has an idea. Essentially I am getting this NPE twice: > java.lang.NullPointerException: null > at org.drools.persistence.jpa.JpaTimerJobInstance.call(JpaTimerJobInstance.java:50) [drools-persistence-jpa-6.3.0.Final.jar:6.3.0.Final] > at org.drools.persistence.jpa.JpaTimerJobInstance.call(JpaTimerJobInstance.java:30) [drools-persistence-jpa-6.3.0.Final.jar:6.3.0.Final] > at java.util.concurrent.FutureTask.run(FutureTask.java:266) [na:1.8.0_51] > at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [na:1.8.0_51] > at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [na:1.8.0_51] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_51] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_51] > at java.lang.Thread.run(Thread.java:745) [na:1.8.0_51] > When debugging I noticed the following behaviour which points to a race condition: > If I start my server and try to recreate the session, those NPEs happen 2x. > If I start my server and put a breakpoint BEFORE creating the CommandService for execution, I can wait for a few seconds and the service can be found. > It appears that the scheduler's timerJobFactoryManager is not fully there at the time the sessions is being loaded? Or something else is racing with the service creation. > Is there a way for me to make sure everything is fully instantiated before I use drools? Does a workaround exist? Is this even a bug? > Thanks and let me know your thoughts. If I run into this again I will attempt to try and reproduce it. Let me know if more info is needed! > UPDATE: > I noticed that the reason I can't reproduce it at the moment is that the JpaTimerJobInstance is never called with the newly persisted session. It appears that that timer job depends on something else to happen so that it thinks it needs to start the timerJob -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6045) EJB default missing method permission deny is not working

by Nicolas Henneaux (JIRA)

[ https://issues.jboss.org/browse/WFLY-6045?page=com.atlassian.jira.plugin.... ] Nicolas Henneaux commented on WFLY-6045: ---------------------------------------- Indeed, it works now with the jboss-ejb3.xml following value : <assembly-descriptor> <s:security> <ejb-name>*</ejb-name> <s:security-domain>jaspitest</s:security-domain> </s:security> </assembly-descriptor>. Thanks for your explanation and my apologies for my misunderstanding. > EJB default missing method permission deny is not working > --------------------------------------------------------- > > Key: WFLY-6045 > URL: https://issues.jboss.org/browse/WFLY-6045 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 9.0.2.Final, 10.0.0.CR5 > Reporter: Nicolas Henneaux > Attachments: default-missing-method-permissions-deny-access.war, jboss-ejb3.xml > > > The behaviour to deny access if no security annotation is present is not working. I tried to use the property default-missing-method-permissions-deny-access from standalone.xml and the property missing-method-permissions-deny-access from jboss-ejb3.xml and none of them works. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6045) EJB default missing method permission deny is not working

by Nicolas Henneaux (JIRA)

[ https://issues.jboss.org/browse/WFLY-6045?page=com.atlassian.jira.plugin.... ] Nicolas Henneaux closed WFLY-6045. ---------------------------------- > EJB default missing method permission deny is not working > --------------------------------------------------------- > > Key: WFLY-6045 > URL: https://issues.jboss.org/browse/WFLY-6045 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 9.0.2.Final, 10.0.0.CR5 > Reporter: Nicolas Henneaux > Attachments: default-missing-method-permissions-deny-access.war, jboss-ejb3.xml > > > The behaviour to deny access if no security annotation is present is not working. I tried to use the property default-missing-method-permissions-deny-access from standalone.xml and the property missing-method-permissions-deny-access from jboss-ejb3.xml and none of them works. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6045) EJB default missing method permission deny is not working

by Nicolas Henneaux (JIRA)

[ https://issues.jboss.org/browse/WFLY-6045?page=com.atlassian.jira.plugin.... ] Nicolas Henneaux updated WFLY-6045: ----------------------------------- Security Sensitive Issue: (was: This issue is security relevant) > EJB default missing method permission deny is not working > --------------------------------------------------------- > > Key: WFLY-6045 > URL: https://issues.jboss.org/browse/WFLY-6045 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 9.0.2.Final, 10.0.0.CR5 > Reporter: Nicolas Henneaux > Attachments: default-missing-method-permissions-deny-access.war, jboss-ejb3.xml > > > The behaviour to deny access if no security annotation is present is not working. I tried to use the property default-missing-method-permissions-deny-access from standalone.xml and the property missing-method-permissions-deny-access from jboss-ejb3.xml and none of them works. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6045) EJB default missing method permission deny is not working

by Nicolas Henneaux (JIRA)

[ https://issues.jboss.org/browse/WFLY-6045?page=com.atlassian.jira.plugin.... ] Nicolas Henneaux updated WFLY-6045: ----------------------------------- Security: (was: Security Issue) > EJB default missing method permission deny is not working > --------------------------------------------------------- > > Key: WFLY-6045 > URL: https://issues.jboss.org/browse/WFLY-6045 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 9.0.2.Final, 10.0.0.CR5 > Reporter: Nicolas Henneaux > Attachments: default-missing-method-permissions-deny-access.war, jboss-ejb3.xml > > > The behaviour to deny access if no security annotation is present is not working. I tried to use the property default-missing-method-permissions-deny-access from standalone.xml and the property missing-method-permissions-deny-access from jboss-ejb3.xml and none of them works. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-929) CLI is terminated unexpectedly after type "u" on HPUX

by Petr Kremensky (JIRA)

[ https://issues.jboss.org/browse/WFCORE-929?page=com.atlassian.jira.plugin... ] Petr Kremensky commented on WFCORE-929: --------------------------------------- 0.66.4-SNAPSHOT fixes the issue, thanks! > CLI is terminated unexpectedly after type "u" on HPUX > ----------------------------------------------------- > > Key: WFCORE-929 > URL: https://issues.jboss.org/browse/WFCORE-929 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 2.0.0.Beta4 > Reporter: Marek Kopecký > Assignee: Alexey Loubyansky > > *Description of problem:* > CLI is terminated unexpectedly after type "qui" on HPUX > *How reproducible:* > Always on HPUX > *Steps to Reproduce:* > # ./standalone.sh > # ./jboss-cli.sh -c > # qui > #* type "qui" in console to CLI, do not press "enter" > *Actual results:* > CLI is terminated > *Expected results:* > CLI is not terminated -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-929) CLI is terminated unexpectedly after type "u" on HPUX

by Ståle Pedersen (JIRA)

[ https://issues.jboss.org/browse/WFCORE-929?page=com.atlassian.jira.plugin... ] Ståle Pedersen commented on WFCORE-929: --------------------------------------- i've pushed out a 0.66.4-SNAPSHOT version that should fix this. > CLI is terminated unexpectedly after type "u" on HPUX > ----------------------------------------------------- > > Key: WFCORE-929 > URL: https://issues.jboss.org/browse/WFCORE-929 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 2.0.0.Beta4 > Reporter: Marek Kopecký > Assignee: Alexey Loubyansky > > *Description of problem:* > CLI is terminated unexpectedly after type "qui" on HPUX > *How reproducible:* > Always on HPUX > *Steps to Reproduce:* > # ./standalone.sh > # ./jboss-cli.sh -c > # qui > #* type "qui" in console to CLI, do not press "enter" > *Actual results:* > CLI is terminated > *Expected results:* > CLI is not terminated -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 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 2016