December 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-5059) Update Service Binding configuration for JBossMessaging

by Clebert Suconic (JIRA)

Update Service Binding configuration for JBossMessaging ------------------------------------------------------- Key: JBAS-5059 URL: http://jira.jboss.com/jira/browse/JBAS-5059 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Reporter: Clebert Suconic Assigned To: Clebert Suconic Fix For: JBossAS-5.0.0.Beta3, JBossAS-4.2.3.GA Even thought JBM is not the default JMS provider on community 4.3, we still need to update one JBM configuration on the ServiceBinding, as that can be used by customers on clustering. The current configuration available there is invalid. -- 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

18 years, 5 months

2
6
0 / 0

[JBoss JIRA] Created: (JBAS-4378) Update the management CRUD usecases

by Scott M Stark (JIRA)

Update the management CRUD usecases ----------------------------------- Key: JBAS-4378 URL: http://jira.jboss.com/jira/browse/JBAS-4378 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Deployment services, Management services Reporter: Scott M Stark Assigned To: Charles Crouch Fix For: JBossAS-5.0.0.Beta3 A container task for the defining the management CRUD usecases for Beta3 -- 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

18 years, 5 months

3
6
0 / 0

[JBoss JIRA] Created: (JBAS-5098) Performance Issues

by Scott M Stark (JIRA)

Performance Issues ------------------ Key: JBAS-5098 URL: http://jira.jboss.com/jira/browse/JBAS-5098 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: JBossAS-5.0.0.Beta3 Reporter: Scott M Stark Assigned To: Scott M Stark Priority: Blocker Fix For: JBossAS-5.0.0.CR1 There appear to be a number of areas (vfs, aop, jbossxb, ...) that are affecting both startup time as well as performance of apps like the seam examples. This is a blocker task to address these for the CR1 release. -- 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

18 years, 5 months

3
2
0 / 0

[JBoss JIRA] Created: (JBAS-4762) Make distributable webapps depend on the clustering cache

by Brian Stansberry (JIRA)

Make distributable webapps depend on the clustering cache --------------------------------------------------------- Key: JBAS-4762 URL: http://jira.jboss.com/jira/browse/JBAS-4762 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering, Web (Tomcat) service Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossAS-5.0.0.Beta3 In 4.x, in the all config the JBossWeb service itself depends on the jboss.cache:service=TomcatClusteringCache mbean. In AS 5 this is not viable, as the relevant bean is the TomcatDeployer, which can't/shouldn't depend on a deploy folder service like the cache. In any case, it's really the <distributable/> webapps that depend on the cache, not the deployer. The TomcatDeployer should be adding a dependency on the cache to deployments where WebMetaData.getDistributable() is true (probably in superclass AbstractWarDeployer.deployWebModule()). A problem with this dependency-based approach is it breaks the current "feature" whereby apps marked <distributable/> can be deployed in the default config. When this is done, the 4.x deployment code detects the absence of the cache and falls back on using the standard non-distributable session manager. That won't work if we introduce a deployment dependency. -- 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

18 years, 5 months

2
3
0 / 0

[JBoss JIRA] Created: (JBREM-798) Implement quick Client.removeListener() for polled callbacks, part 2

by Ron Sigal (JIRA)

Implement quick Client.removeListener() for polled callbacks, part 2 -------------------------------------------------------------------- Key: JBREM-798 URL: http://jira.jboss.com/jira/browse/JBREM-798 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.4.0.Beta1 (Pinto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.Beta1 (Pinto) This issue is a continuation of JBREM-757. There are two additions: 1. The unit tests org.jboss.test.remoting.transport.http.timeout.HttpQuickDisconnectTestCase and org.jboss.test.remoting.transport.socket.timeout.SocketQuickDisconnectTestCase did not properly test the the quick version of org.jboss.remoting.Client.removeListener() in the case of polled callbacks. 2. The facility should be tested for the RMI transport when per invocation timeouts are implemented for that transport. (See JBREM-701.) -- 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

18 years, 5 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-874) CLONE -HTTP Client invoker doesn't throw exceptions when using the sslservlet protocol [JBREM-871]

by Ron Sigal (JIRA)

CLONE -HTTP Client invoker doesn't throw exceptions when using the sslservlet protocol [JBREM-871] -------------------------------------------------------------------------------------------------- Key: JBREM-874 URL: http://jira.jboss.com/jira/browse/JBREM-874 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transport Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.2.GA_CP01 Reporter: Jay Howell Assigned To: Ron Sigal Fix For: 2.2.2.SP4 In the HTTP Client Invoker, the only server side exceptions that get thrown are for the servlet protocol only... and also have to be servlet exceptions... The code from the client that throws the exception is inside of this if block.... i// now check for error response and throw exception unless configured to not do so if(responseCode >= 400 || ("servlet".equals(getLocator().getProtocol()) && result instanceof InvocationResponse && ((InvocationResponse) result).getResult() instanceof ServletThrowable)) { -- 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

18 years, 5 months

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-800) Adjust timout values to avoid cruisecontrol failures

by Ron Sigal (JIRA)

Adjust timout values to avoid cruisecontrol failures ---------------------------------------------------- Key: JBREM-800 URL: http://jira.jboss.com/jira/browse/JBREM-800 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.4.0.Beta1 (Pinto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.Beta1 (Pinto) It seems that some tests fail on cruisecontrol because a busy machine causes timout deadlines to be missed. For example, http://cruisecontrol.jboss.com/cc/artifacts/jboss-remoting-testsuite-1.4/... This issue will be an umbrella issue to cover adjusting timeout values. If a test continues to fail despite updated timeout values, it will need a JIRA issue of its own. -- 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

18 years, 5 months

1
4
0 / 0

[JBoss JIRA] Created: (JBREM-760) Change port for shutdown tests.

by Ron Sigal (JIRA)

Change port for shutdown tests. ------------------------------- Key: JBREM-760 URL: http://jira.jboss.com/jira/browse/JBREM-760 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.4.0.Beta1 (Pinto) Reporter: Ron Sigal Assigned To: Ron Sigal Priority: Minor Fix For: 2.4.0.Beta1 (Pinto) The descendants of org.jboss.test.remoting.shutdown.ShutdownTestParent are failing because the port used by the server is in use. The port number should be changed. -- 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

18 years, 5 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-786) stale sockets can be gotten from pool even with current rety logic

by james ahlborn (JIRA)

stale sockets can be gotten from pool even with current rety logic ------------------------------------------------------------------ Key: JBREM-786 URL: http://jira.jboss.com/jira/browse/JBREM-786 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transport Affects Versions: 1.4.6.GA Reporter: james ahlborn The retry logic in SocketClientInvoker.transport attempts to ensure that the invoker does not get a stale socket on the last attempt by flushing the pool. however, this only discards any currently unused scokets. a second invoker could return a stale socket after the flush, causing the first invoker to fail again on the last retry (with an EOFException). while this seems like an edge case, we can hit it reliably under load with many connections to the same destination. i've patched this class so that the last call to getConnection will never return a pooled connection. we never got the EOFException after applying this fix. -- 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

18 years, 5 months

2
8
0 / 0

[JBoss JIRA] Created: (JBREM-701) add timeout config per client invocation for transports not descended from socket transport

by Ron Sigal (JIRA)

add timeout config per client invocation for transports not descended from socket transport ------------------------------------------------------------------------------------------- Key: JBREM-701 URL: http://jira.jboss.com/jira/browse/JBREM-701 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 3.0.0.Alpha1 (Otter) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 3.0.0.Alpha1 (Otter) For JBREM-598 per invocation timeouts were implemented for socket, sslsocket, bisocket, and sslbisocket. It's not clear how to implement per invocation timeouts for http and rmi, but it would be good to do, if possible. -- 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

18 years, 5 months

1
6
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 2007