March 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SECURITY-810) Lifetime configuration option for Kerberos LoginModule

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/SECURITY-810?page=com.atlassian.jira.plug... ] Darran Lofthouse updated SECURITY-810: -------------------------------------- Component/s: Negotiation > Lifetime configuration option for Kerberos LoginModule > ------------------------------------------------------ > > Key: SECURITY-810 > URL: https://issues.jboss.org/browse/SECURITY-810 > Project: PicketBox > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Negotiation > Reporter: Jesper Pedersen > Assignee: Darran Lofthouse > > Add a configuration option to the Kerberos LoginModule that allows to control the lifetime -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-810) Lifetime configuration option for Kerberos LoginModule

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/SECURITY-810?page=com.atlassian.jira.plug... ] Darran Lofthouse updated SECURITY-810: -------------------------------------- Fix Version/s: Negotiation_2_3_0_CR1 > Lifetime configuration option for Kerberos LoginModule > ------------------------------------------------------ > > Key: SECURITY-810 > URL: https://issues.jboss.org/browse/SECURITY-810 > Project: PicketBox > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Negotiation > Reporter: Jesper Pedersen > Assignee: Darran Lofthouse > Fix For: Negotiation_2_3_0_CR1 > > > Add a configuration option to the Kerberos LoginModule that allows to control the lifetime -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3077) Convert command line IPv6 URL literals to address literals

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3077?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3077: ----------------------------------------------- Rostislav Svoboda <rsvoboda(a)redhat.com> changed the Status of [bug 1064771|https://bugzilla.redhat.com/show_bug.cgi?id=1064771] from ASSIGNED to VERIFIED > Convert command line IPv6 URL literals to address literals > ---------------------------------------------------------- > > Key: WFLY-3077 > URL: https://issues.jboss.org/browse/WFLY-3077 > Project: WildFly > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Affects Versions: 8.0.0.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Minor > Fix For: 8.0.1.Final > > > When people provide URL-style values like [::1] for command line args like -b, convert them to address values (i.e. strip the enclosing brackets.) -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-810) Lifetime configuration option for Kerberos LoginModule

by Jesper Pedersen (JIRA)

Jesper Pedersen created SECURITY-810: ---------------------------------------- Summary: Lifetime configuration option for Kerberos LoginModule Key: SECURITY-810 URL: https://issues.jboss.org/browse/SECURITY-810 Project: PicketBox Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Jesper Pedersen Assignee: Darran Lofthouse Add a configuration option to the Kerberos LoginModule that allows to control the lifetime -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2214) Allow additional environment properties to be set for outbound LDAP connections used by security realms.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2214?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2214: ----------------------------------------------- Darran Lofthouse <darran.lofthouse(a)redhat.com> changed the Status of [bug 1015303|https://bugzilla.redhat.com/show_bug.cgi?id=1015303] from ASSIGNED to POST > Allow additional environment properties to be set for outbound LDAP connections used by security realms. > -------------------------------------------------------------------------------------------------------- > > Key: WFLY-2214 > URL: https://issues.jboss.org/browse/WFLY-2214 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.0.0.Alpha4 > Reporter: Derek Horton > Assignee: Darran Lofthouse > Fix For: 8.0.0.CR1 > > > LDAP security realm needs to have configurable timeouts. > The default LDAP connection timeout appears to be 2 minutes. If the ldap server is down, it could take 2 minutes for the connection to timeout. This can cause unneeded delay if you have configured multiple ldap servers for failover / redundancy. > The following hack appears to work: > +++ domain-management/src/main/java/org/jboss/as/domain/management/connections/ldap/LdapConnectionManagerService.java > @@ -132,6 +132,7 @@ public class LdapConnectionManagerService implements Service<LdapConnectionManag > result.put(Context.INITIAL_CONTEXT_FACTORY,initialContextFactory); > String url = config.require(URL).asString(); > result.put(Context.PROVIDER_URL,url); > + result.put("com.sun.jndi.ldap.connect.timeout", "500"); > return result; > } -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-315) Avoid running out of threads when connecting to the DC from a slave to pull down missing data

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-315?page=com.atlassian.jira.plugin.s... ] David Lloyd commented on WFLY-315: ---------------------------------- Ideally, dependency-oriented tasks would be asynchronous/callback-based. I have a simple DependencyTask class in jboss-threads that might be interesting for certain trivial cases (probably not for this case though). The idea is to avoid submitting tasks that you know will block, instead favoring tasks that will proceed and that will resolve future tasks' blocks before they are executed. > Avoid running out of threads when connecting to the DC from a slave to pull down missing data > --------------------------------------------------------------------------------------------- > > Key: WFLY-315 > URL: https://issues.jboss.org/browse/WFLY-315 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Kabir Khan > Assignee: Emanuel Muckenhuber > Priority: Blocker > Fix For: 9.0.0.CR1 > > > For WFLY-259 when a slave connects to the DC to pull down missing data, it does this by either getting a lock for the DC, or by joining the permit of the existing DC lock if the request to update a slave's server-config was executed as part of a composite obtaining a lock on the DC. > The way it works at present there is a thread per slave which is blocked until the transaction completes. The DC threads are a finite resource, so a large number of slaves trying to pull down dats will cause deadlock -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-315) Avoid running out of threads when connecting to the DC from a slave to pull down missing data

by Emanuel Muckenhuber (JIRA)

[ https://issues.jboss.org/browse/WFLY-315?page=com.atlassian.jira.plugin.s... ] Emanuel Muckenhuber commented on WFLY-315: ------------------------------------------ But yeah all blocking/cancellable task have to be executed outside of the IO (remoting) threads. This should be the case already, if you spot something like that it's definitely a bug and has to be fixed. > Avoid running out of threads when connecting to the DC from a slave to pull down missing data > --------------------------------------------------------------------------------------------- > > Key: WFLY-315 > URL: https://issues.jboss.org/browse/WFLY-315 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Kabir Khan > Assignee: Emanuel Muckenhuber > Priority: Blocker > Fix For: 9.0.0.CR1 > > > For WFLY-259 when a slave connects to the DC to pull down missing data, it does this by either getting a lock for the DC, or by joining the permit of the existing DC lock if the request to update a slave's server-config was executed as part of a composite obtaining a lock on the DC. > The way it works at present there is a thread per slave which is blocked until the transaction completes. The DC threads are a finite resource, so a large number of slaves trying to pull down dats will cause deadlock -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-315) Avoid running out of threads when connecting to the DC from a slave to pull down missing data

by Emanuel Muckenhuber (JIRA)

[ https://issues.jboss.org/browse/WFLY-315?page=com.atlassian.jira.plugin.s... ] Emanuel Muckenhuber edited comment on WFLY-315 at 3/21/14 9:40 AM: ------------------------------------------------------------------- But yeah all blocking/cancellable tasks have to be executed outside of the IO (remoting) threads. This should be the case already, if you spot something like that it's definitely a bug and has to be fixed. was (Author: emuckenhuber): But yeah all blocking/cancellable task have to be executed outside of the IO (remoting) threads. This should be the case already, if you spot something like that it's definitely a bug and has to be fixed. > Avoid running out of threads when connecting to the DC from a slave to pull down missing data > --------------------------------------------------------------------------------------------- > > Key: WFLY-315 > URL: https://issues.jboss.org/browse/WFLY-315 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Kabir Khan > Assignee: Emanuel Muckenhuber > Priority: Blocker > Fix For: 9.0.0.CR1 > > > For WFLY-259 when a slave connects to the DC to pull down missing data, it does this by either getting a lock for the DC, or by joining the permit of the existing DC lock if the request to update a slave's server-config was executed as part of a composite obtaining a lock on the DC. > The way it works at present there is a thread per slave which is blocked until the transaction completes. The DC threads are a finite resource, so a large number of slaves trying to pull down dats will cause deadlock -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-315) Avoid running out of threads when connecting to the DC from a slave to pull down missing data

by Emanuel Muckenhuber (JIRA)

[ https://issues.jboss.org/browse/WFLY-315?page=com.atlassian.jira.plugin.s... ] Emanuel Muckenhuber commented on WFLY-315: ------------------------------------------ Yeah, i mean most of this relies on unbounded thread pools, so that operations don't deadlock. We should really get rid of those at one point though. We do throttle (1) mainly because when i was running a lot of concurrent requests with an not limited thread pool the server pretty much ran out of memory pretty quickly (thanks to ModelNode.clone()). (2) are executed by single thread, because it's kinda pointless have multiple registration just use threads, when they cannot be executed concurrently. (3) we have a limited pool on the DC, however proxied request cannot be limited, because they are all blocking (awaiting the tx.complete from the DC). Also inbound request for fetching data and files are unlimited to avoid deadlocks. This all is a huge mess needs to be cleaned up at one point, however would require some fundamental changes. > Avoid running out of threads when connecting to the DC from a slave to pull down missing data > --------------------------------------------------------------------------------------------- > > Key: WFLY-315 > URL: https://issues.jboss.org/browse/WFLY-315 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Kabir Khan > Assignee: Emanuel Muckenhuber > Priority: Blocker > Fix For: 9.0.0.CR1 > > > For WFLY-259 when a slave connects to the DC to pull down missing data, it does this by either getting a lock for the DC, or by joining the permit of the existing DC lock if the request to update a slave's server-config was executed as part of a composite obtaining a lock on the DC. > The way it works at present there is a thread per slave which is blocked until the transaction completes. The DC threads are a finite resource, so a large number of slaves trying to pull down dats will cause deadlock -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2644) Java heap space exceeded looping connect/disconnect cycle

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2644?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2644: ----------------------------------------------- Radim Hatlapatka <rhatlapa(a)redhat.com> changed the Status of [bug 1037574|https://bugzilla.redhat.com/show_bug.cgi?id=1037574] from ASSIGNED to VERIFIED > Java heap space exceeded looping connect/disconnect cycle > --------------------------------------------------------- > > Key: WFLY-2644 > URL: https://issues.jboss.org/browse/WFLY-2644 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CLI > Affects Versions: 8.0.0.Beta1 > Reporter: Alexey Loubyansky > Assignee: Alexey Loubyansky > Fix For: 8.0.0.Final > > > CLIModelControllerClient implementation is not cleaning up something related to connection handling which leads to OOME repeating a cycle of ensureConnected(...) and close(). On my laptop it happens after around 1400 iterations. -- 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, 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 March 2014