September 2009 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-3440) HAPartitionImpl.viewAccepted should handle InterruptedException

by Brian Stansberry (JIRA)

HAPartitionImpl.viewAccepted should handle InterruptedException --------------------------------------------------------------- Key: JBAS-3440 URL: http://jira.jboss.com/jira/browse/JBAS-3440 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Minor Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.6.CR1 The JGroups up thread may throw an InterruptedException when the view change is placed in the handler's queue. This can only happen if the channel is being stopped, so if it happens, the exception should be caught and the view change should be ignored. -- 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

16 years, 5 months

2
6
0 / 0

[JBoss JIRA] Created: (JBAS-6859) See if a value-factory element in a -service.xml can create a dependency

by Brian Stansberry (JIRA)

See if a value-factory element in a -service.xml can create a dependency ------------------------------------------------------------------------ Key: JBAS-6859 URL: https://jira.jboss.org/jira/browse/JBAS-6859 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: JBossAS-6.0.0.Alpha1 I don't see code that will result in a dependency being created when a value-factory element appears in a -service.xml. I'm not sure at all if a dependency can be created, at least not without a ton of hacks. So this JIRA is mostly to look into it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 5 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-6584) Clustered classloader leak test repeatedly times out on Solaris and HPUX

by Richard Achmatowicz (JIRA)

Clustered classloader leak test repeatedly times out on Solaris and HPUX ------------------------------------------------------------------------ Key: JBAS-6584 URL: https://jira.jboss.org/jira/browse/JBAS-6584 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-5.0.1.GA Environment: Solaris, HPUX platforms Reporter: Richard Achmatowicz The test case ClusteredClassloaderLeakUnitTest is repeatedly timing out, even when the junit.timeout for the test is extended from 180 secs (default) to 800 secs. This test seems to pass OK on RHEL with the usual timeout. This test deploys a war/ejb/ear, makes a few invocations, and then undeploys the war/ejb/ear. While doing so, it keeps a record of the classloaders deployed via an MBean ClassloaderTracker which is deployed before the tests start. It uses the record of classloaders registered to check that (ii) all classloaders are present when they should be (after deployment) and (ii) all classloaders are absent when they should be (after undeployment). The sequence of steps performed fror the war version of the test are: - checkCleanKeys - deployComponent - makeWebRequest - checkRegistration - undeployComponent - flushSecurityCache - checkClassloaderRelease The test currently performs two tests involving war deployments (tests for the other deployments have been commented out): testSimpleWar, testNoPassivationWar. The test testSimpleWar generally passes, after a substantial wait at checkClassloaderRelease. The test testNoPassivatioWar regularly hangs when it reaches checkClassloaderRelease. I'm not sure of this is a bug, as the test times out and does not fail an assertion; however, even tripling the time allowed for the test does not help. Something seems to be untoward in the method checkClassloaderRelease, which calls ClassloaderStore.getClassloader with the forceGC parameter set to true, and it is untoward only on these platforms. This test has been placed at the end of the testsuite, as it generally modifies the state of the servers so that they also will not shut down properly. This allows the testsuite to complete the generalion of reports and not waste a test run. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 5 months

3
7
0 / 0

[JBoss JIRA] Created: (JBAS-7176) In TCP stacks, set use_send_queues to true

by Brian Stansberry (JIRA)

In TCP stacks, set use_send_queues to true ------------------------------------------ Key: JBAS-7176 URL: https://jira.jboss.org/jira/browse/JBAS-7176 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: JBossAS-5.2.0.Beta1 Per Bela: - use_send_queues: I found this valuable to prevent threads getting blocked in the TCP socket write phase, and therefore blocking other threads too. If you enable this, also set send_queue_size We'll need to figure out the appropriate send_queue_size. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 5 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-5165) Generic ProxyFactoryHA too dependent on deployment ordering

by Brian Stansberry (JIRA)

Generic ProxyFactoryHA too dependent on deployment ordering ----------------------------------------------------------- Key: JBAS-5165 URL: http://jira.jboss.com/jira/browse/JBAS-5165 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Clustering Affects Versions: JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossAS-5.0.0.CR1 org.jboss.proxy.generic.ProxyFactoryHA will not signal its HATarget to allow invocations to proceed until it receives a JMS notification that its target service has started. But, if the target service starts before ProxyFactoryHA.create() is called, it will never get the notification. -- 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

16 years, 5 months

1
3
0 / 0

[JBoss JIRA] Created: (JBAS-4893) JvmRouteValve (UseJK) for non session replication setup

by Takayoshi Kimura (JIRA)

JvmRouteValve (UseJK) for non session replication setup ------------------------------------------------------- Key: JBAS-4893 URL: http://jira.jboss.com/jira/browse/JBAS-4893 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Takayoshi Kimura Currently JBoss doesn't install JvmRouteValve for non session replication setup. However, it's still useful in the following scenario: * 1 Apache HTTPD frontend and 2 JBoss AS instances without session replication * A request goes JBoss node AAA (JSESSIONID=xxx.AAA) * The node AAA crashed * The request goes node BBB, lost session, recreate another * The node AAA recovered * The request comes back to the node AAA, lost session again Enabling JvmRouteValve can prevent last failure. -- 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

16 years, 5 months

3
10
0 / 0

[JBoss JIRA] Created: (JBAS-3556) Add non-integration based testing to cluster module

by Brian Stansberry (JIRA)

Add non-integration based testing to cluster module --------------------------------------------------- Key: JBAS-3556 URL: http://jira.jboss.com/jira/browse/JBAS-3556 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering, Test Suite Reporter: Brian Stansberry All the unit tests for the AS cluster module are run via the testsuite tests-clustering target, which starts two AS instances. This is painful and time consuming and discourages writing of simple unit tests that exercise a particular class, with no need for a larger integration. Need to set up a src/tests tree in the cluster module, add simple unit tests to it, and integrate that into the overall testsuite run. The security module has this kind of setup; look to that to see how the overall testsuite integration is done. -- 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

16 years, 5 months

2
5
0 / 0

[JBoss JIRA] Created: (JBMETA-215) Allow for configuration of transaction-retry

by Carlo de Wolf (JIRA)

Allow for configuration of transaction-retry -------------------------------------------- Key: JBMETA-215 URL: https://jira.jboss.org/jira/browse/JBMETA-215 Project: JBoss Metadata Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Carlo de Wolf Assignee: Carlo de Wolf Fix For: 1.0.2.Beta2, 2.0.0.CR1 The @TransactionRetry annotation must have an equivalent configuration option in descriptors. @TransactionRetry(numRetries=4, waitTime=1, waitTimeUnit=TimeUnit.SECONDS) <assembly-descriptor> <transaction-retry>  <method> <ejb-name>*</ejb-name> <method-name>...</method-name> </method> ... <num-retries>4</num-retries> <wait-time>1</wait-time> <wait-time-unit>SECONDS</wait-time-unit> </transaction-retry> </assembly-descriptor> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 5 months

4
5
0 / 0

[JBoss JIRA] Created: (JBVFS-113) Comprehensive VFS documentation

by Flavia Rainone (JIRA)

Comprehensive VFS documentation ------------------------------- Key: JBVFS-113 URL: https://jira.jboss.org/jira/browse/JBVFS-113 Project: JBoss VFS Issue Type: Task Security Level: Public (Everyone can see) Reporter: Flavia Rainone Assignee: Flavia Rainone Provide a comprehensive documentation for the VFS project. This includes a user guide and a Javadoc (with the API/SPI). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 5 months

4
10
0 / 0

[JBoss JIRA] Created: (JBREM-1080) Add support for future tasks to RequestContext

by David Lloyd (JIRA)

Add support for future tasks to RequestContext ---------------------------------------------- Key: JBREM-1080 URL: https://jira.jboss.org/jira/browse/JBREM-1080 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Components: r3 api Reporter: David Lloyd Fix For: 3.1.0.Beta1 Right now, the RequestContext keeps track of tasks and threads being used to process a request. If all tasks complete and no reply is sent, it makes sure that the requesting party receives an exception indicating that a reply was never sent. However, if the request listener may wish interact with another framework which uses some asynchronous callback mechanism, from which a reply is to be sent. In this case, all tasks terminate but the reply might still be sent. To solve this problem, RequestContext needs a method which can wrap a Runnable (or similar) with some type of cancellable Runnable or task object, which can then be called by other frameworks as needed later on. The RequestContext wouldn't consider a request "dead" until all tasks completed and all such wrapped Runnables have also been completed or GC'd. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 5 months

2
5
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 September 2009