November 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-369) Domain mode: kill an unresponsive JVM

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-369?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on WFLY-369: ---------------------------------------------- Petr Kremensky <pkremens(a)redhat.com> made a comment on [bug 901232|https://bugzilla.redhat.com/show_bug.cgi?id=901232] Verified on EAP 6.2.0.ER7. > Domain mode: kill an unresponsive JVM > ------------------------------------- > > Key: WFLY-369 > URL: https://issues.jboss.org/browse/WFLY-369 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Dennis Reed > Assignee: Emanuel Muckenhuber > Fix For: 8.0.0.Alpha1 > > > If an AS instance gets into a state where it cannot be controlled normally by the host controller, local OS commands must be used to kill it. > It would be helpful to be able to kill an unresponsive JVM through the management interface. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-369) Domain mode: kill an unresponsive JVM

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-369?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on WFLY-369: ---------------------------------------------- Petr Kremensky <pkremens(a)redhat.com> changed the Status of [bug 901232|https://bugzilla.redhat.com/show_bug.cgi?id=901232] from ON_QA to VERIFIED > Domain mode: kill an unresponsive JVM > ------------------------------------- > > Key: WFLY-369 > URL: https://issues.jboss.org/browse/WFLY-369 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Dennis Reed > Assignee: Emanuel Muckenhuber > Fix For: 8.0.0.Alpha1 > > > If an AS instance gets into a state where it cannot be controlled normally by the host controller, local OS commands must be used to kill it. > It would be helpful to be able to kill an unresponsive JVM through the management interface. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2485) @Transactional not working correctly with @Stereotype wrt. Exception handling

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/WFLY-2485?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated WFLY-2485: -------------------------------- Assignee: Michael Musgrove (was: Tom Jenkinson) > @Transactional not working correctly with @Stereotype wrt. Exception handling > ----------------------------------------------------------------------------- > > Key: WFLY-2485 > URL: https://issues.jboss.org/browse/WFLY-2485 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Transactions > Affects Versions: 8.0.0.Beta1 > Reporter: David Mann > Assignee: Michael Musgrove > Priority: Minor > > Hi, > > suppose I have a @Stereotype with a @Transactional annotation: > > @Named > @ViewScoped > @Transactional > @Stereotype > @Retention (RetentionPolicy.RUNTIME) > @Target (ElementType.TYPE) > public @interface Boundary > { } > > I annotate a CDI Bean with this stereotype > > @Boundary > public class BusinessLogic { > public void doSomething(){ > throw new RuntimeException("foo"); > } > } > > If any exceptions are thrown when calling the business method, the user will get the (incorrect) info that the Class is missing a @Transactional annotation, because the Interceptor doesn't bother to look further into the Stereotype (see below). > > What's worse, the interceptor is swallowing the real exeption in the process. We get the following Stacktrace: > > java.lang.RuntimeException: ARJUNA016107: Expected an @Transactional annotation at class and/or method level > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.getTransactional(TransactionalInterceptorBase.java:61) > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.handleException(TransactionalInterceptorBase.java:96) > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInOurTx(TransactionalInterceptorBase.java:72) > Which is pretty clear from the implementation of TransactionalInterceptorBase: > private Transactional getTransactional(InvocationContext ic) { > > Transactional transactional = ic.getMethod().getAnnotation(Transactional.class); > if (transactional != null) { > return transactional; > } > > Class<?> targetClass = ic.getTarget().getClass(); > transactional = targetClass.getAnnotation(Transactional.class); // needs to look further > if (transactional != null) { > return transactional; > } > > throw new RuntimeException(jtaLogger.i18NLogger.get_expected_transactional_annotation()); // swallows the exception that occured at ic.proceed() > } -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2486) EJBComponentDescription#isSecurityEnabled() is incorrect

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-2486?page=com.atlassian.jira.plugin.... ] Stuart Douglas updated WFLY-2486: --------------------------------- Description: This assumes that if the security domain is null, then the there is no security. This is incorrect, as there could be a default security domain. There could also be a security domain set, but not security annotations/metadata that is applicable to the bean. On the whole I think we should remove this method, as its use is problematic, and move any code that relies on it to org.jboss.as.ejb3.security.EJBSecurityViewConfigurator, so all the security stuff is setup in one place. (was: This assumes that if the security domain is null, then the there is no security. This is incorrect, as there could be a default security domain. There could also be a security domain set, but not security annotations/metadata that is applicable to the bean. On the whole I think we should remove this method, as its use is problematic, and move any code that relies on it to org.jboss.as.ejb3.security.EJBSecurityViewConfigurator, so all the security stuff is setup in one place) > EJBComponentDescription#isSecurityEnabled() is incorrect > -------------------------------------------------------- > > Key: WFLY-2486 > URL: https://issues.jboss.org/browse/WFLY-2486 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB > Reporter: Stuart Douglas > Assignee: David Lloyd > > This assumes that if the security domain is null, then the there is no security. This is incorrect, as there could be a default security domain. There could also be a security domain set, but not security annotations/metadata that is applicable to the bean. On the whole I think we should remove this method, as its use is problematic, and move any code that relies on it to org.jboss.as.ejb3.security.EJBSecurityViewConfigurator, so all the security stuff is setup in one place. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2486) EJBComponentDescription#isSecurityEnabled() is incorrect

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-2486: ------------------------------------ Summary: EJBComponentDescription#isSecurityEnabled() is incorrect Key: WFLY-2486 URL: https://issues.jboss.org/browse/WFLY-2486 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB Reporter: Stuart Douglas Assignee: David Lloyd This assumes that if the security domain is null, then the there is no security. This is incorrect, as there could be a default security domain. There could also be a security domain set, but not security annotations/metadata that is applicable to the bean. On the whole I think we should remove this method, as its use is problematic, and move any code that relies on it to org.jboss.as.ejb3.security.EJBSecurityViewConfigurator, so all the security stuff is setup in one place -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1732) UNICAST/NAKACK: threads from the internal thread pool should not do work stealing

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1732?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1732: -------------------------------- OK, the reason is that UNICAST3 corrects the above scenario quickly (within xmit_interval ms), whereas NAKACK2 has to wait until the next stability message (STABLE), which is seconds by default. Reverting the changr for NAKACK2. > UNICAST/NAKACK: threads from the internal thread pool should not do work stealing > --------------------------------------------------------------------------------- > > Key: JGRP-1732 > URL: https://issues.jboss.org/browse/JGRP-1732 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.5 > > > In NAKACK\{2\} and UNICAST\{2,3\}, threads from all thread pools (regular, OOB and internal) add messages to the table, then grab as many (ordered) messages as possible from the table and pass them up. > This could lead to the case where an internal thread passes up regular or OOB messages, which might block. There's a (small) chance that this exhausts the internal thread pool. > Internal threads should therefore never block, and never steal work from other thread pools. > SOLUTION: > * An internal thread only adds the message to the table and passes it up if in order > * If the internal message is OOB, it is passed up and then the thread returns -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1732) UNICAST/NAKACK: threads from the internal thread pool should not do work stealing

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1732?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-1732 at 11/11/13 8:58 AM: ---------------------------------------------------------- Oops, failures (OOBTest). Perhaps this is 4 (reg) --> 6 (reg) --> 5 (oob) ? When 6 is received, it is added to the table but not delivered as 5 is missing. When 5 is received it is delivered, but 6 is not delivered... The UNICAST3 changes are OK, it is the NAKACK2 change which breaks OOBTest. was (Author: belaban): Oops, failures (OOBTest). Perhaps this is 4 (reg) --> 6 (reg) --> 5 (oob) ? When 6 is received, it is added to the table but not delivered as 5 is missing. When 5 is received it is delivered, but 6 is not delivered... > UNICAST/NAKACK: threads from the internal thread pool should not do work stealing > --------------------------------------------------------------------------------- > > Key: JGRP-1732 > URL: https://issues.jboss.org/browse/JGRP-1732 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.5 > > > In NAKACK\{2\} and UNICAST\{2,3\}, threads from all thread pools (regular, OOB and internal) add messages to the table, then grab as many (ordered) messages as possible from the table and pass them up. > This could lead to the case where an internal thread passes up regular or OOB messages, which might block. There's a (small) chance that this exhausts the internal thread pool. > Internal threads should therefore never block, and never steal work from other thread pools. > SOLUTION: > * An internal thread only adds the message to the table and passes it up if in order > * If the internal message is OOB, it is passed up and then the thread returns -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2425) Use forked version of slf4j to fix concurrency issue with static binding

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2425?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2425: ----------------------------------------------- Jitka Kozana <jkudrnac(a)redhat.com> changed the Status of [bug 1011821|https://bugzilla.redhat.com/show_bug.cgi?id=1011821] from ON_QA to VERIFIED > Use forked version of slf4j to fix concurrency issue with static binding > ------------------------------------------------------------------------ > > Key: WFLY-2425 > URL: https://issues.jboss.org/browse/WFLY-2425 > Project: WildFly > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Minor > Fix For: 8.0.0.CR1 > > > The slf4j-api static binding is not thread safe. A fork of slf4j-api was needed for EAP so we might as well patch WildFly too. The slf4j bugzilla is http://bugzilla.slf4j.org/show_bug.cgi?id=176. The patch used in the fork is attached to the bz. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2425) Use forked version of slf4j to fix concurrency issue with static binding

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2425?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2425: ----------------------------------------------- Jitka Kozana <jkudrnac(a)redhat.com> made a comment on [bug 1011821|https://bugzilla.redhat.com/show_bug.cgi?id=1011821] This issue was verified using the 6.2.0.CR1 preview bits. > Use forked version of slf4j to fix concurrency issue with static binding > ------------------------------------------------------------------------ > > Key: WFLY-2425 > URL: https://issues.jboss.org/browse/WFLY-2425 > Project: WildFly > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Minor > Fix For: 8.0.0.CR1 > > > The slf4j-api static binding is not thread safe. A fork of slf4j-api was needed for EAP so we might as well patch WildFly too. The slf4j bugzilla is http://bugzilla.slf4j.org/show_bug.cgi?id=176. The patch used in the fork is attached to the bz. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1732) UNICAST/NAKACK: threads from the internal thread pool should not do work stealing

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1732?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1732: -------------------------------- Oops, failures (OOBTest). Perhaps this is 4 (reg) --> 6 (reg) --> 5 (oob) ? When 6 is received, it is added to the table but not delivered as 5 is missing. When 5 is received it is delivered, but 6 is not delivered... > UNICAST/NAKACK: threads from the internal thread pool should not do work stealing > --------------------------------------------------------------------------------- > > Key: JGRP-1732 > URL: https://issues.jboss.org/browse/JGRP-1732 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.5 > > > In NAKACK\{2\} and UNICAST\{2,3\}, threads from all thread pools (regular, OOB and internal) add messages to the table, then grab as many (ordered) messages as possible from the table and pass them up. > This could lead to the case where an internal thread passes up regular or OOB messages, which might block. There's a (small) chance that this exhausts the internal thread pool. > Internal threads should therefore never block, and never steal work from other thread pools. > SOLUTION: > * An internal thread only adds the message to the table and passes it up if in order > * If the internal message is OOB, it is passed up and then the thread returns -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 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 November 2013