December 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1759) BecomeServerTest.testSendingOfMsgsOnUnconnectedChannel deadlocks

by Richard Achmatowicz (JIRA)

[ https://issues.jboss.org/browse/JGRP-1759?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz commented on JGRP-1759: ------------------------------------------- The debugging output above clearly shows the correct rule being loaded, processed and called. I can't say for sure where/why the program is being deadlocked; I guess the next step is to run it locally on that machine (the tests are run via Jenkins) and create a thread dump. But, as you know, whenever you use a rendezvous with no timeout, the possibility for deadlock is there. I was going to suggest to Andrew to create a version of rendezvous which if all threads do not arrive after a specified timeout, performs the thread dump itself as well as listing the threads which did/did not make it to the rendezvous point. That information would have been helpful here. > BecomeServerTest.testSendingOfMsgsOnUnconnectedChannel deadlocks > ---------------------------------------------------------------- > > Key: JGRP-1759 > URL: https://issues.jboss.org/browse/JGRP-1759 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.5 > Environment: Windows 2008, x86_64 > Reporter: Richard Achmatowicz > Assignee: Bela Ban > Priority: Minor > Fix For: 3.5 > > > Running the Byteman tests in the QA lab, this test deadlocks in a repeatable fashion and causes the testsuite to hang. > The test makes use of the Byteman rendezvous built-in function to suspend (and reorder) thread execution. It appears that with threads re-ordered, certain parts of JGroups block in such a way that no progress is made and the test deadlocks. > . -- 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-1749) Remove override for jgroups.bind_addr, jgroups.udp.mcast_addr, jgroups.udp.mcast_port

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1749?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1749. ---------------------------- Resolution: Done > Remove override for jgroups.bind_addr, jgroups.udp.mcast_addr, jgroups.udp.mcast_port > ------------------------------------------------------------------------------------- > > Key: JGRP-1749 > URL: https://issues.jboss.org/browse/JGRP-1749 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 3.4.2, 3.5 > > > If we have > {code:xml} > <UDP mcast_addr="${myapp.mcast_addr:235.5.5.5}".../> > {code} > , then the default mcast_addr is {{235.5.5.5}}. > If we set {{-Dmyapp.mcast_addr=238.5.5.5}} but also set {{-Djgroups.udp.mcast_addr=239.5.5.5}}, then *the latter system property always overrides the former*, so we'll use {{239.5.5.5}} as mcast_addr. > This is bad, e.g. when we have multiple channels in the same JVM, where one channel uses {{myapp1.mcast_addr}} and the other {{myapp2.mcast_addr}}. If {{-Djgroups.udp.mcast_addr}} is set (e.g. by JBoss EAP), then we'll always use it rather than the different mcast addresses ! > This means that - if we use the same {{mcast_port}} value - the 2 clusters will see each other's traffic as they use the same {{mcast_addr}}. > Investigate whether we still need to use those overrides. Contact Brian Stansberry, IIRC he's the one who suggested this. > SOLUTION: > * If a property is set in the XML, either directly or via property substitution (e.g. {{myapp.mcast_addr}}, then use that value > * If the value is not set and a system property (e.g. {{jgroups.udp.mcast_addr}}) has been set, set the value from that system property -- 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-2682) Conversation identifier does not get incremented

by Adriano Scheffer (JIRA)

[ https://issues.jboss.org/browse/WFLY-2682?page=com.atlassian.jira.plugin.... ] Adriano Scheffer updated WFLY-2682: ----------------------------------- Description: The conversation id is not getting incremented when I open another browser tab. Conversely, this problems was not happening in Beta1. (was: The conversation id is not getting incremented when I open another browser tab. Conversally, this problems was not happening in Beta1.) > Conversation identifier does not get incremented > ------------------------------------------------ > > Key: WFLY-2682 > URL: https://issues.jboss.org/browse/WFLY-2682 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CDI / Weld, JSF > Affects Versions: 8.0.0.CR1 > Environment: Windows 7 > Reporter: Adriano Scheffer > Assignee: Stuart Douglas > > The conversation id is not getting incremented when I open another browser tab. Conversely, this problems was not happening in Beta1. -- 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-1749) Remove override for jgroups.bind_addr, jgroups.udp.mcast_addr, jgroups.udp.mcast_port

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1749?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1749: --------------------------- Description: If we have {code:xml} <UDP mcast_addr="${myapp.mcast_addr:235.5.5.5}".../> {code} , then the default mcast_addr is {{235.5.5.5}}. If we set {{-Dmyapp.mcast_addr=238.5.5.5}} but also set {{-Djgroups.udp.mcast_addr=239.5.5.5}}, then *the latter system property always overrides the former*, so we'll use {{239.5.5.5}} as mcast_addr. This is bad, e.g. when we have multiple channels in the same JVM, where one channel uses {{myapp1.mcast_addr}} and the other {{myapp2.mcast_addr}}. If {{-Djgroups.udp.mcast_addr}} is set (e.g. by JBoss EAP), then we'll always use it rather than the different mcast addresses ! This means that - if we use the same {{mcast_port}} value - the 2 clusters will see each other's traffic as they use the same {{mcast_addr}}. Investigate whether we still need to use those overrides. Contact Brian Stansberry, IIRC he's the one who suggested this. SOLUTION: * If a property is set in the XML, either directly or via property substitution (e.g. {{myapp.mcast_addr}}, then use that value * If the value is not set and a system property (e.g. {{jgroups.udp.mcast_addr}}) has been set, set the value from that system property was: If we have {code:xml} <UDP bind_addr="${myapp.bind_addr:127.0.0.1}".../> {code} , then the default bind_addr is {{127.0.0.1}}. If we set {{-Dmyapp.bind_addr=1.2.3.4}} but also set {{-Djgroups.bind_addr=5.6.7.8}}, then *the latter system property always overrides the former*. This is bad, e.g. when we have multiple channels in the same JVM, where one channel uses {{myapp1.bind_addr}} and the other {{myapp2.bind_addr}}. If {{-Djgroups.bind_addr}} is set (e.g. by JBoss EAP), then we'll always use it rather than the different bind addresses ! Investigate whether we still need to use those overrides. Contact Brian Stansberry, IIRC he's the one who suggested this. SOLUTION: * If a property is set in the XML, either directly or via property substitution (e.g. {{myapp.bind_addr}}, then use that value * If the value is not set and a system property (e.g. {{jgroups.bind_addr}}) has been set, set the value from that system property > Remove override for jgroups.bind_addr, jgroups.udp.mcast_addr, jgroups.udp.mcast_port > ------------------------------------------------------------------------------------- > > Key: JGRP-1749 > URL: https://issues.jboss.org/browse/JGRP-1749 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 3.4.2, 3.5 > > > If we have > {code:xml} > <UDP mcast_addr="${myapp.mcast_addr:235.5.5.5}".../> > {code} > , then the default mcast_addr is {{235.5.5.5}}. > If we set {{-Dmyapp.mcast_addr=238.5.5.5}} but also set {{-Djgroups.udp.mcast_addr=239.5.5.5}}, then *the latter system property always overrides the former*, so we'll use {{239.5.5.5}} as mcast_addr. > This is bad, e.g. when we have multiple channels in the same JVM, where one channel uses {{myapp1.mcast_addr}} and the other {{myapp2.mcast_addr}}. If {{-Djgroups.udp.mcast_addr}} is set (e.g. by JBoss EAP), then we'll always use it rather than the different mcast addresses ! > This means that - if we use the same {{mcast_port}} value - the 2 clusters will see each other's traffic as they use the same {{mcast_addr}}. > Investigate whether we still need to use those overrides. Contact Brian Stansberry, IIRC he's the one who suggested this. > SOLUTION: > * If a property is set in the XML, either directly or via property substitution (e.g. {{myapp.mcast_addr}}, then use that value > * If the value is not set and a system property (e.g. {{jgroups.udp.mcast_addr}}) has been set, set the value from that system property -- 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-2107) JASPI custom provider fails with no explicit error message

by Stefan Guilhen (JIRA)

[ https://issues.jboss.org/browse/WFLY-2107?page=com.atlassian.jira.plugin.... ] Stefan Guilhen resolved WFLY-2107. ---------------------------------- Fix Version/s: 8.0.0.CR1 Resolution: Done This has been fixed a while ago in PicketBox as part of SECURITY-759 > JASPI custom provider fails with no explicit error message > ---------------------------------------------------------- > > Key: WFLY-2107 > URL: https://issues.jboss.org/browse/WFLY-2107 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Security > Reporter: Derek Horton > Assignee: Darran Lofthouse > Fix For: 8.0.0.CR1 > > > The JASPI module loading code does not provide a useful error message. The error appears to be generated in org.jboss.security.auth.message.config.JBossServerAuthConfig, but its lost before it makes it into the log file. > A user can run into this issue when the auth-module class name (the 'code' attribute) is wrong or when a custom auth-module is used and the class loading dependencies are not setup correctly. > Steps to Reproduce: > 1. Misspell the auth-module class name -- 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] (SECURITY-767) SecurityConfiguration#appPolicies is not thread safe

by Stefan Guilhen (JIRA)

[ https://issues.jboss.org/browse/SECURITY-767?page=com.atlassian.jira.plug... ] Stefan Guilhen resolved SECURITY-767. ------------------------------------- Fix Version/s: PicketBox_4_0_20.Final Resolution: Done The fix is included in the patch submitted in SECURITY-777 > SecurityConfiguration#appPolicies is not thread safe > ---------------------------------------------------- > > Key: SECURITY-767 > URL: https://issues.jboss.org/browse/SECURITY-767 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: PicketBox_4_0_20.Beta2 > Reporter: Stuart Douglas > Assignee: Stefan Guilhen > Fix For: PicketBox_4_0_20.Final > > > This map is a normal hash map with no sync. When multiple security domains are being added this could cause problems, as Wildfly starts the security domain services concurrently. -- 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-2682) Conversation identifier does not get incremented

by Adriano Scheffer (JIRA)

Adriano Scheffer created WFLY-2682: -------------------------------------- Summary: Conversation identifier does not get incremented Key: WFLY-2682 URL: https://issues.jboss.org/browse/WFLY-2682 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: CDI / Weld, JSF Affects Versions: 8.0.0.CR1 Environment: Windows 7 Reporter: Adriano Scheffer Assignee: Stuart Douglas The conversation id is not getting incremented when I open another browser tab. Conversally, this problems was not happening in Beta1. -- 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] (DROOLS-385) KModules get added twice

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-385?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated DROOLS-385: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1046095 > KModules get added twice > ------------------------ > > Key: DROOLS-385 > URL: https://issues.jboss.org/browse/DROOLS-385 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Mark Proctor > Assignee: Mario Fusco > > The class loader is returning duplicate entries, as it incorrectly implements: > @Override > protected Enumeration<URL> findResources(String name) throws IOException { > return getParent().getResources(name); > } > Deleting this method resolves the problem -- 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-1749) Remove override for jgroups.bind_addr, jgroups.udp.mcast_addr, jgroups.udp.mcast_port

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1749?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1749: --------------------------- Description: If we have {code:xml} <UDP bind_addr="${myapp.bind_addr:127.0.0.1}".../> {code} , then the default bind_addr is {{127.0.0.1}}. If we set {{-Dmyapp.bind_addr=1.2.3.4}} but also set {{-Djgroups.bind_addr=5.6.7.8}}, then *the latter system property always overrides the former*. This is bad, e.g. when we have multiple channels in the same JVM, where one channel uses {{myapp1.bind_addr}} and the other {{myapp2.bind_addr}}. If {{-Djgroups.bind_addr}} is set (e.g. by JBoss EAP), then we'll always use it rather than the different bind addresses ! Investigate whether we still need to use those overrides. Contact Brian Stansberry, IIRC he's the one who suggested this. SOLUTION: * If a property is set in the XML, either directly or via property substitution (e.g. {{myapp.bind_addr}}, then use that value * If the value is not set and a system property (e.g. {{jgroups.bind_addr}}) has been set, set the value from that system property was: If we have {code:xml} <UDP bind_addr="${myapp.bind_addr:127.0.0.1}".../> {code} , then the default bind_addr is {{127.0.0.1}}. If we set {{-Dmyapp.bind_addr=1.2.3.4}} but also set {{-Djgroups.bind_addr=5.6.7.8}}, then *the latter system property always overrides the former*. This is bad, e.g. when we have multiple channels in the same JVM, where one channel uses {{myapp1.bind_addr}} and the other {{myapp2.bind_addr}}. If {{-Djgroups.bind_addr}} is set (e.g. by JBoss EAP), then we'll always use it rather than the different bind addresses ! Investigate whether we still need to use those overrides. Contact Brian Stansberry, IIRC he's the one who suggested this. SOLUTION: remove the _global_ system properties such as {{jgroups.bind_addr}}. > Remove override for jgroups.bind_addr, jgroups.udp.mcast_addr, jgroups.udp.mcast_port > ------------------------------------------------------------------------------------- > > Key: JGRP-1749 > URL: https://issues.jboss.org/browse/JGRP-1749 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 3.4.2, 3.5 > > > If we have > {code:xml} > <UDP bind_addr="${myapp.bind_addr:127.0.0.1}".../> > {code} > , then the default bind_addr is {{127.0.0.1}}. > If we set {{-Dmyapp.bind_addr=1.2.3.4}} but also set {{-Djgroups.bind_addr=5.6.7.8}}, then *the latter system property always overrides the former*. > This is bad, e.g. when we have multiple channels in the same JVM, where one channel uses {{myapp1.bind_addr}} and the other {{myapp2.bind_addr}}. If {{-Djgroups.bind_addr}} is set (e.g. by JBoss EAP), then we'll always use it rather than the different bind addresses ! > Investigate whether we still need to use those overrides. Contact Brian Stansberry, IIRC he's the one who suggested this. > SOLUTION: > * If a property is set in the XML, either directly or via property substitution (e.g. {{myapp.bind_addr}}, then use that value > * If the value is not set and a system property (e.g. {{jgroups.bind_addr}}) has been set, set the value from that system property -- 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] (DROOLS-385) KModules get added twice

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-385?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-385: ------------------------------------------------ Mario Fusco <mfusco(a)redhat.com> changed the Status of [bug 1046095|https://bugzilla.redhat.com/show_bug.cgi?id=1046095] from NEW to ASSIGNED > KModules get added twice > ------------------------ > > Key: DROOLS-385 > URL: https://issues.jboss.org/browse/DROOLS-385 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Mark Proctor > Assignee: Mario Fusco > > The class loader is returning duplicate entries, as it incorrectly implements: > @Override > protected Enumeration<URL> findResources(String name) throws IOException { > return getParent().getResources(name); > } > Deleting this method resolves the problem -- 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 December 2013