May 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1845) Null pointer exception in Samsung Q1 using 3G connection

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1845?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1845: --------------------------- Fix Version/s: 3.3.6 3.4.5 3.5 Priority: Minor (was: Major) > Null pointer exception in Samsung Q1 using 3G connection > -------------------------------------------------------- > > Key: JGRP-1845 > URL: https://issues.jboss.org/browse/JGRP-1845 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.1, 3.2, 3.2.1, 3.2.2, 3.2.3, 3.2.4, 3.2.5, 3.2.6, 3.2.7, 3.2.8, 3.2.9, 3.2.10, 3.2.12, 3.2.13, 3.3, 3.3.1, 3.3.2, 3.3.3, 3.3.4, 3.3.5, 3.4, 3.4.1, 3.4.2, 3.4.3, 3.4.4 > Environment: Samsung Q1 with Windows XP Tablet Edition and 3G connection. Java 6 or Java 7. > Reporter: Denis Lamela > Assignee: Bela Ban > Priority: Minor > Fix For: 3.3.6, 3.4.5, 3.5 > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > Null pointer exception in method "bindToInterfaces" of class "org.jgroups.stack.DiagnosticsHandler". The exception is thrown while executing "i.getInterfaceAddresses().isEmpty()". "i.getInterfaceAddresses()" returns null. > This bug can be fixed checking if "i.getInterfaceAddresses()" returns null. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-1845) Null pointer exception in Samsung Q1 using 3G connection

by Denis Lamela (JIRA)

Denis Lamela created JGRP-1845: ---------------------------------- Summary: Null pointer exception in Samsung Q1 using 3G connection Key: JGRP-1845 URL: https://issues.jboss.org/browse/JGRP-1845 Project: JGroups Issue Type: Bug Affects Versions: 3.4.4, 3.4.3, 3.4.2, 3.4.1, 3.4, 3.3.5, 3.3.4, 3.3.3, 3.3.2, 3.3.1, 3.3, 3.2.13, 3.2.12, 3.2.10, 3.2.9, 3.2.8, 3.2.7, 3.2.6, 3.2.5, 3.2.4, 3.2.3, 3.2.2, 3.2.1, 3.2, 3.1 Environment: Samsung Q1 with Windows XP Tablet Edition and 3G connection. Java 6 or Java 7. Reporter: Denis Lamela Assignee: Bela Ban Null pointer exception in method "bindToInterfaces" of class "org.jgroups.stack.DiagnosticsHandler". The exception is thrown while executing "i.getInterfaceAddresses().isEmpty()". "i.getInterfaceAddresses()" returns null. This bug can be fixed checking if "i.getInterfaceAddresses()" returns null. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3406) JARs Made Invalid By Patch Installation Should Be Renamed to Indicate Their Status

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3406?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-3406: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1085696 > JARs Made Invalid By Patch Installation Should Be Renamed to Indicate Their Status > ---------------------------------------------------------------------------------- > > Key: WFLY-3406 > URL: https://issues.jboss.org/browse/WFLY-3406 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Patching > Affects Versions: 8.1.0.CR2 > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3406) JARs Made Invalid By Patch Installation Should Be Renamed to Indicate Their Status

by Emmanuel Hugonnet (JIRA)

Emmanuel Hugonnet created WFLY-3406: --------------------------------------- Summary: JARs Made Invalid By Patch Installation Should Be Renamed to Indicate Their Status Key: WFLY-3406 URL: https://issues.jboss.org/browse/WFLY-3406 Project: WildFly Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Patching Affects Versions: 8.1.0.CR2 Reporter: Emmanuel Hugonnet Assignee: Emmanuel Hugonnet -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3392) Make the test suite more robust for DomainDeployWithRuntimeNameTestCase

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3392?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3392: ----------------------------------------------- Carlo de Wolf <cdewolf(a)redhat.com> changed the Status of [bug 1099876|https://bugzilla.redhat.com/show_bug.cgi?id=1099876] from POST to MODIFIED > Make the test suite more robust for DomainDeployWithRuntimeNameTestCase > ----------------------------------------------------------------------- > > Key: WFLY-3392 > URL: https://issues.jboss.org/browse/WFLY-3392 > Project: WildFly > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Test Suite > Affects Versions: 8.1.0.CR2 > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Priority: Trivial > Fix For: 9.0.0.Alpha1 > > > The test DomainDeployWithRuntimeNameTestCase depends on the server groups list which is backed by a Set. > Converting it to a list ands osrting it makes the test more reliable -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3404) Major performance degradation from JBoss 7.1 to Wildfly 8.0.0-Final.

by Timothy Heider (JIRA)

[ https://issues.jboss.org/browse/WFLY-3404?page=com.atlassian.jira.plugin.... ] Timothy Heider resolved WFLY-3404. ---------------------------------- Resolution: Done Not a bug obviously but a big difference between JBoss and Wildfly in 8.0.0. > Major performance degradation from JBoss 7.1 to Wildfly 8.0.0-Final. > -------------------------------------------------------------------- > > Key: WFLY-3404 > URL: https://issues.jboss.org/browse/WFLY-3404 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 8.0.0.Final > Reporter: Timothy Heider > Assignee: Jason Greene > > I have deployed my application to Wildfly 8.0.0 Final and it is almost unusable now. We have rolled back to JBoss 7.1 (same application WARs) and it works fine. > Specifically what seems to be slow is our SOAP web services are taking up to 8 to 10 seconds to respond. We have user concurrency of probably 10-30 users at once hitting these services every 10 seconds or so. > On JBoss 7.1 these services all respond sub-second. The database is totally unburdened and the server is 90% idle all the time. > We have one service endpoint that is a Comet queue wait call. Probably 10 users are waiting on that. Did something change between JBoss 7 and Wildfly 8 that might cause that to not work now? (e.g. too small a thread pool that blocks until the 10 second comet call breaks on a timeout?) > We will try 8.1.0CR2 but I wanted to report we're investigating this and see if you can help us. Thanks! -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3404) Major performance degradation from JBoss 7.1 to Wildfly 8.0.0-Final.

by Timothy Heider (JIRA)

[ https://issues.jboss.org/browse/WFLY-3404?page=com.atlassian.jira.plugin.... ] Timothy Heider commented on WFLY-3404: -------------------------------------- I found worker thread pool settings in Profile > Core > IO. They were very low by default. I guess the small thread pool would go into a blocking state until the Comet call broke (on a timeout). We've decided to stop using Comet and instead use 2 second polling until we can implement something like WebSockets. > Major performance degradation from JBoss 7.1 to Wildfly 8.0.0-Final. > -------------------------------------------------------------------- > > Key: WFLY-3404 > URL: https://issues.jboss.org/browse/WFLY-3404 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 8.0.0.Final > Reporter: Timothy Heider > Assignee: Jason Greene > > I have deployed my application to Wildfly 8.0.0 Final and it is almost unusable now. We have rolled back to JBoss 7.1 (same application WARs) and it works fine. > Specifically what seems to be slow is our SOAP web services are taking up to 8 to 10 seconds to respond. We have user concurrency of probably 10-30 users at once hitting these services every 10 seconds or so. > On JBoss 7.1 these services all respond sub-second. The database is totally unburdened and the server is 90% idle all the time. > We have one service endpoint that is a Comet queue wait call. Probably 10 users are waiting on that. Did something change between JBoss 7 and Wildfly 8 that might cause that to not work now? (e.g. too small a thread pool that blocks until the 10 second comet call breaks on a timeout?) > We will try 8.1.0CR2 but I wanted to report we're investigating this and see if you can help us. Thanks! -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBWEB-299) Add support for OpenSSL syntax when defining ciphers

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBWEB-299?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBWEB-299: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1078204|https://bugzilla.redhat.com/show_bug.cgi?id=1078204] from POST to MODIFIED > Add support for OpenSSL syntax when defining ciphers > ---------------------------------------------------- > > Key: JBWEB-299 > URL: https://issues.jboss.org/browse/JBWEB-299 > Project: JBoss Web > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Core > Affects Versions: JBossWeb-7.2.1.GA > Reporter: Emmanuel Hugonnet > Assignee: Remy Maucherat > Attachments: bz-1078204.patch > > > SSL connector fails to start if cipher-suite="ALL" even though in the xsd schema it is defined as default value -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3072) Support Referrals for security realms using LDAP for authentication or group loading.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3072?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3072: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1066488|https://bugzilla.redhat.com/show_bug.cgi?id=1066488] from MODIFIED to ON_QA > Support Referrals for security realms using LDAP for authentication or group loading. > ------------------------------------------------------------------------------------- > > Key: WFLY-3072 > URL: https://issues.jboss.org/browse/WFLY-3072 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 8.1.0.CR2, 8.1.0.Final > > > I see the following scenarios to cover for this: - > - Authentication - A search is performed e.g against 'uid' and a referral is encountered, the URL needs to be extracted from the referral and a new connection created using the referral URL to load any additional attributes for the user, the referral URL is then used to establish the connection as the user to verify that their password is correct. > Group loading then has a couple of issues, firstly where the user was a referral. > The search for group membership information is a fresh start but now we potentially have 2 simple named and 2 distinguished names that could be referenced from the group object. We may want a config option to specify which one to actually use and even possibly use both. > Next could a group also be a referral, i.e. it contains the reference to the user as an attribute so was matched in the search but is also a referral to the true named group in another location. In this situation I suggest any iterative search takes into account the context containing the actual group definition and continues the search from there. > And then where the principal contains an attribute that references, this one should be a simple following of a referral and once followed continue the attribute loading using the new connection. > The connection manager logic is going to need reworking, ideally for a referral we should check if we have a connection definition that matches based on the URL returned otherwise we will need to try and establish a connection based on the settings of the last connection used, this probably also introduces a notion of some form of connection stack of the connections used for the current request - referrals could have us bouncing back and forth so connections should be cached and re-used where possible during authentication and group loading. > * Connection Settings * > We are going to need to support two different modes in relation to the 'java.naming.referral' property, follow and throw. > - *follow* - In this mode when the InitialDirContext encounters a referral during a search it will automatically follow it, this means automatically connecting to the server in the URL. This is fine if the remaining connection settings are valid for the alternative server e.g. same bindDN and credential. We however need to take the following into account for subsequent operations such as password validation or further queries. > - *throw* - When a referral is encountered and exception will be thrown instead, this mode should make it easier to have some more advanced referral handling logic that allows us control of which connection we subsequently use, e.g. we could not use a completely different host name to the one in the referral or use a different bind DN / credential pair. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-2789) Remote client transaction timeout values are overwrote by hardcoded values

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2789?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2789: ----------------------------------------------- Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1093128|https://bugzilla.redhat.com/show_bug.cgi?id=1093128] from ASSIGNED to POST > Remote client transaction timeout values are overwrote by hardcoded values > -------------------------------------------------------------------------- > > Key: WFLY-2789 > URL: https://issues.jboss.org/browse/WFLY-2789 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB > Reporter: Johnathon Lee > Assignee: David Lloyd > Fix For: 8.1.0.Final, 9.0.0.Alpha1 > > > The EJB3 interceptor is not using client values for timeouts, this is a problem for users trying to use EJB for transaction propagation. > Refer to the code in https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo...: > private void createOrResumeXidTransaction(final XidTransactionID xidTransactionID) throws Exception { > final TransactionManager transactionManager = this.ejbRemoteTransactionsRepository.getTransactionManager(); > final Transaction alreadyCreatedTx = this.ejbRemoteTransactionsRepository.getImportedTransaction(xidTransactionID); > if (alreadyCreatedTx != null) { > // resume the already created tx > transactionManager.resume(alreadyCreatedTx); > } else { > // begin a new tx and add it to the tx repository > // TODO: Fix the tx timeout (which currently is passed as 300 seconds) > final Transaction newSubOrdinateTx = this.ejbRemoteTransactionsRepository.importTransaction(xidTransactionID, 300); > // associate this tx with the thread > transactionManager.resume(newSubOrdinateTx); > } > } -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

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 May 2014