July 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBNAME-53) InitialContext#lookup does not timeout on cached context

by Stian Thorgersen (JIRA)

InitialContext#lookup does not timeout on cached context -------------------------------------------------------- Key: JBNAME-53 URL: https://issues.jboss.org/browse/JBNAME-53 Project: JBoss Naming Issue Type: Bug Reporter: Stian Thorgersen I've got an issue where InitialContext#lookup will hang forever doing a lookup if there is a problem with the network. I appreciate this is the default settings of the TCP sockets to wait forever, so I've tried to configure the timeout using 'jnp.timeout' and 'jnp.sotimeout'. If the network is disconnected prior to the first attempt to do a lookup it times out as expected (I assume this is 'jnp.timeout' which configures the timeout to create the connection). However, if the network is disconnected after one ore more successful lookups have been performed it waits forever. I assume this is there 'jnp.sotimeout' should have kicked in, but doesn't seem to. {code} Hashtable<String, String> env = new Hashtable<String, String>(); env.put("java.naming.factory.initial", "org.jnp.interfaces.NamingContextFactory"); env.put("java.naming.provider.url", "jnp://10.9.1.11:1099"); env.put("java.naming.factory.url.pkgs", "org.jboss.naming"); env.put("jnp.socketFactor", "org.jnp.interfaces.TimedSocketFactory"); env.put("jnp.timeout", "1000"); env.put("jnp.sotimeout", "1000"); InitialContext ctx = new InitialContext(env); ctx.lookup("something"); // disconnect network here ctx.lookup("something"); {code} In the above example if I disconnect the network before the first lookup it times out as expected, but if I disconnect the network between the first lookup and the second lookup it waits forever. I've tried to wrap it in a thread, that is then interrupted after a timeout, but that doesn't work. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-9365) InitialContext#lookup does not timeout on cached context

by Stian Thorgersen (JIRA)

InitialContext#lookup does not timeout on cached context -------------------------------------------------------- Key: JBAS-9365 URL: https://issues.jboss.org/browse/JBAS-9365 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Stian Thorgersen I've got an issue where InitialContext#lookup will hang forever doing a lookup if there is a problem with the network. I appreciate this is the default settings of the TCP sockets to wait forever, so I've tried to configure the timeout using 'jnp.timeout' and 'jnp.sotimeout'. If the network is disconnected prior to the first attempt to do a lookup it times out as expected (I assume this is 'jnp.timeout' which configures the timeout to create the connection). However, if the network is disconnected after one ore more successful lookups have been performed it waits forever. I assume this is there 'jnp.sotimeout' should have kicked in, but doesn't seem to. {code} Hashtable<String, String> env = new Hashtable<String, String>(); env.put("java.naming.factory.initial", "org.jnp.interfaces.NamingContextFactory"); env.put("java.naming.provider.url", "jnp://10.9.1.11:1099"); env.put("java.naming.factory.url.pkgs", "org.jboss.naming"); env.put("jnp.socketFactor", "org.jnp.interfaces.TimedSocketFactory"); env.put("jnp.timeout", "1000"); env.put("jnp.sotimeout", "1000"); InitialContext ctx = new InitialContext(env); ctx.lookup("something"); // disconnect network here ctx.lookup("something"); {code} In the above example if I disconnect the network before the first lookup it times out as expected, but if I disconnect the network between the first lookup and the second lookup it waits forever. I've tried to wrap it in a thread, that is then interrupted after a timeout, but that doesn't work. Looking at the source code from JBoss Naming it seems that 'jnp.timeout' and 'jnp.sotimeout' is only used to retrieve the NamingServer_Stub, once that is retrieved and cached I can't see that they are being used any longer. I believe this would result in the problem I'm seeing as NamingServer_Stub#lookup would not have a socket timeout associated with the RMI call. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-5515) Failed to load users/passwords/role files

by Heiko Braun (JIRA)

Failed to load users/passwords/role files ----------------------------------------- Key: JBAS-5515 URL: http://jira.jboss.com/jira/browse/JBAS-5515 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Heiko Braun Fix For: JBossAS-5.0.0.CR1 21:25:41,277 ERROR [UsersRolesLoginModule] Failed to load users/passwords/role files java.io.IOException: No properties file: users.properties or defaults: defaultUsers.properties found at org.jboss.security.auth.spi.Util.loadProperties(Util.java:366) at org.jboss.security.auth.spi.UsersRolesLoginModule.loadUsers(UsersRolesLoginModule.java:186) at org.jboss.security.auth.spi.UsersRolesLoginModule.createUsers(UsersRolesLoginModule.java:200) at org.jboss.security.auth.spi.UsersRolesLoginModule.initialize(UsersRolesLoginModule.java:127) When executing one-test: [junit] Running org.jboss.test.ws.jaxws.samples.context.WebServiceContextEJBTestCase [junit] Tests run: 3, Failures: 0, Errors: 3, Time elapsed: 2.421 sec [junit] Test org.jboss.test.ws.jaxws.samples.context.WebServiceContextEJBTestCase FAILED -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

3
5
0 / 0

[JBoss JIRA] Created: (JBAS-8695) Deployment repository garbage collection

by Brian Stansberry (JIRA)

Deployment repository garbage collection ---------------------------------------- Key: JBAS-8695 URL: https://jira.jboss.org/browse/JBAS-8695 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Domain Management Reporter: Brian Stansberry Fix For: 7.0.0.CR1 The deployment repository is only loosely coupled to the domain model; i.e. users can add content to the repo and then have a problem or decide to not execute a deployment plan with the result that the deployment is not used in the model. Or they can remove the deployment from the model via an update, which doesn't remove it from the repo (in case the update needs to be rolled back.) Effect of this is unreferenced deployment content can accumulate in the repo, so we need a gc utility that can be used to clean it out. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

4
6
0 / 0

[JBoss JIRA] Created: (JBRULES-3007) Planner: tabu size is not respected when there are multiple tabus per property tabu

by Geoffrey De Smet (JIRA)

Planner: tabu size is not respected when there are multiple tabus per property tabu ----------------------------------------------------------------------------------- Key: JBRULES-3007 URL: https://issues.jboss.org/browse/JBRULES-3007 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-planner Reporter: Geoffrey De Smet Assignee: Geoffrey De Smet This code is the problem in AbstractTabuAcceptor: while (tabuSequenceList.size() >= maximumTabuListSize) { Consider these moves: move 1 (tabu A, tabu B, tabu C) move 2 (tabu D, tabu E, tabu F, tabu G) move 3 (tabu A, tabu B) and a tabu move size of 4, then move 3 isn't seen as tabu with move 1, while it should be! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-681) Multi-threaded local search solving

by Geoffrey De Smet (JIRA)

Multi-threaded local search solving ----------------------------------- Key: JBRULES-681 URL: http://jira.jboss.com/jira/browse/JBRULES-681 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Solver Reporter: Geoffrey De Smet Assigned To: Geoffrey De Smet Priority: Optional Use Future's to spread all possible moves in each step over a number of threads. This number of threads is equal to the number of cpu's by default, as no IO is done during solving. Problems: - each thread will needs it own WorkingMemory and during a step, each working memory will need to be updated - a bunch of classes will need to be thread safe, or at least visibility save, such as bestsolutionrecaller. - Barriers will be needed to collect the result of each step - decks might be a great way to spread out the load -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
6
0 / 0

[JBoss JIRA] Created: (EJBTHREE-880) Hard-coded localhost in ejb3 test suite

by Aleksandar Kostadinov (JIRA)

Hard-coded localhost in ejb3 test suite --------------------------------------- Key: EJBTHREE-880 URL: http://jira.jboss.com/jira/browse/EJBTHREE-880 Project: EJB 3.0 Issue Type: Bug Reporter: Aleksandar Kostadinov When the ejb3 testsuite is run with "-Dnode0=IP1 -Dnode1=IP2" and IP1!=localhost there are some tests failing with "Retries exceeded, couldn't reconnect to 127.0.0.1:####". I see this for 4_0 and 4_2 jboss branches, but guess it's the same with head. One of the testcases is IiopRemoteUnitTestCase. I've checked ejb3/src/test/org/jboss/ejb3/test/iiop/unit/IiopRemoteUnitTestCase.java and there is 'props.put("java.naming.provider.url", "corbaloc::localhost:3528/NameService");'. Instead of localhost there should be used the node0 property. I guess the others have the same problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

6
16
0 / 0

[JBoss JIRA] Created: (JBAS-9259) Provide an option to change the code source used by deployments

by David Lloyd (JIRA)

Provide an option to change the code source used by deployments --------------------------------------------------------------- Key: JBAS-9259 URL: https://issues.jboss.org/browse/JBAS-9259 Project: JBoss Application Server Issue Type: Enhancement Security Level: Public (Everyone can see) Components: Modules / Class-loading, VFS Reporter: David Lloyd Priority: Minor Fix For: 7.0.0.CR1 For most use cases, using the VFS URL for the code source is best. However in certain cases the code source is expected to correspond to a physical filesystem location, possibly even a valid JAR URL. So there should be an option in jboss-deployment-structure.xml to allow the code source to be changed to be the URL of the physical location of the VFS mount point instead of the VFS root URL. This option would default to "off", meaning use the VFS URL. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

9
16
0 / 0

[JBoss JIRA] Created: (AS7-780) sub-deployments shouldn't be assumed to be VFS children of the parent deployment

by Tobias Crawley (JIRA)

sub-deployments shouldn't be assumed to be VFS children of the parent deployment -------------------------------------------------------------------------------- Key: AS7-780 URL: https://issues.jboss.org/browse/AS7-780 Project: Application Server 7 Issue Type: Bug Reporter: Tobias Crawley Assignee: Jason Greene With TorqueBox, we allow deploying apps that are outside of the deployed artifact. We support a deployment descriptor inside a jar/ear/war that points to an external app directory tree. SubDeploymentProcessor assumes that the root of the sub-deployment is a VFS child of the parent, which won't be the case for TorqueBox: {preformat} final String relativePath = childRoot.getRoot().getPathNameRelativeTo(parentRoot.getRoot()); {preformat} It should be simple enough to only expand the path if it is not absolute: {preformat} final String relativePath = null; if (childRoot.getRoot().isRoot()) { relativePath = childRoot.getRoot().getPathName(); } else { relativePath = childRoot.getRoot().getPathNameRelativeTo(parentRoot.getRoot()); } {preformat} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

6
5
0 / 0

[JBoss JIRA] Created: (AS7-984) Add a switch to run the testsuites with IPv6

by Thomas Diesler (JIRA)

Add a switch to run the testsuites with IPv6 -------------------------------------------- Key: AS7-984 URL: https://issues.jboss.org/browse/AS7-984 Project: Application Server 7 Issue Type: Task Reporter: Thomas Diesler Assignee: Thomas Diesler -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

9
11
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2011