November 2013 - jboss-jira - Jboss List Archives

[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

12 years, 6 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

12 years, 6 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

12 years, 6 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

12 years, 6 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

12 years, 6 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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2435) Upgrade Generic JMS RA to 1.0.1.Final

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2435?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2435: ----------------------------------------------- Martin Simka <msimka(a)redhat.com> made a comment on [bug 1026397|https://bugzilla.redhat.com/show_bug.cgi?id=1026397] This issue was verified using the 6.2.0.CR1 preview bits. > Upgrade Generic JMS RA to 1.0.1.Final > ------------------------------------- > > Key: WFLY-2435 > URL: https://issues.jboss.org/browse/WFLY-2435 > Project: WildFly > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: JCA > Affects Versions: 8.0.0.Beta1 > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 8.0.0.CR1 > > -- 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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2435) Upgrade Generic JMS RA to 1.0.1.Final

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2435?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2435: ----------------------------------------------- Martin Simka <msimka(a)redhat.com> changed the Status of [bug 1026397|https://bugzilla.redhat.com/show_bug.cgi?id=1026397] from ON_QA to VERIFIED > Upgrade Generic JMS RA to 1.0.1.Final > ------------------------------------- > > Key: WFLY-2435 > URL: https://issues.jboss.org/browse/WFLY-2435 > Project: WildFly > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: JCA > Affects Versions: 8.0.0.Beta1 > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 8.0.0.CR1 > > -- 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

12 years, 6 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: -------------------------------- Done for UNICAST3 and NAKACK2 which are the recommended protocols for unicast and multicast retransmission respectively. > 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

12 years, 6 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: -------------------------------- This is only done for single messages which are marked as {{OOB | INTERNAL}}. For message *batches*, all OOB messages are delivered before regular messages. Internal-only (non OOB) messages are delivered in the order in which they were batched. The suggestion at this point is to send internal messages as {{INTERNAL | OOB | DONT_BUNDLE}}. When JGRP-1737 is implemented, all messages will be bundled, but messages tagged with {{DONT_BUNDLE}} will get delivered on a seperate thread. > 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

12 years, 6 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 November 2013