February 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-3921) Merge JBCLUSTER-150 fixes with 4.0.5.GA tag

by Vivek Lakshmanan (JIRA)

Merge JBCLUSTER-150 fixes with 4.0.5.GA tag ------------------------------------------- Key: JBAS-3921 URL: http://jira.jboss.com/jira/browse/JBAS-3921 Project: JBoss Application Server Issue Type: Support Patch Security Level: Public (Everyone can see) Affects Versions: JBossAS-4.0.5.GA Reporter: Vivek Lakshmanan Assigned To: Brian Stansberry Fixes from https://svn.jboss.org/repos/jbossas/tags/JBoss_4_0_5_GA_EJBTHREE-798 need merging into a branch off the 4.0.5GA tag so they can be picked up by the patch process. No tag needs to be made on this branch as long as the branch's head satisfactorily fixes the JBCLUSTER-150 issues. -- 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, 3 months

4
10
0 / 0

[JBoss JIRA] Created: (JBAS-3934) Backport JBAS-3460 to Branch_4_2

by Brian Stansberry (JIRA)

Backport JBAS-3460 to Branch_4_2 -------------------------------- Key: JBAS-3934 URL: http://jira.jboss.com/jira/browse/JBAS-3934 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Clustering, Web (Tomcat) service Reporter: Brian Stansberry Assigned To: Brian Stansberry The additions to jboss-web.xml should be backported. My inclination is not to remove the default snapshot mode/interval config from the Tomcat SAR config though, as 4.2 is not a major 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, 3 months

2
2
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, 3 months

1
6
0 / 0

[JBoss JIRA] Created: (EJBTHREE-853) Partial StringProperty replacement in ejb 3 container

by Roland R?z (JIRA)

Partial StringProperty replacement in ejb 3 container ----------------------------------------------------- Key: EJBTHREE-853 URL: http://jira.jboss.com/jira/browse/EJBTHREE-853 Project: EJB 3.0 Issue Type: Feature Request Affects Versions: EJB 3.0 RC9 - FD Reporter: Roland R?z I tried to change the messageSelector in an EJB 3.0 MDB in the ejb.jar.xml containing partial System Property references (aaa${xyz}bbb). Sadly this didn't work as with ejb 2.1. I think fully supporting system property replacement as with ejb 2.x in EJB 3.0 would be a nice feature. The method org.jboss.ejb3.metamodel.EjbJarDDObjectFactory.getValue(String name, String value) could be changed to { value = org.jboss.util.StringPropertyReplacer.replaceProperties(value); } I would suggest, to implement the string property replacement even better in the class org.jboss.metamodel.descriptor.DDObjectFactory.getValue() and remove the getValue method from JBossDDObjectFactory and EjbJarDDObjectFactory. The idea of using an MBean abstraction to replace system properties is fine but the nice syntax of the StringPropertyReplacer should be still supported (${v1,v2:default}). Returning always the replaced property is one possibility (currently it is not done this way) but probably a new method "getReplaced" would be less surprising. -- 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, 3 months

2
1
0 / 0

[JBoss JIRA] Created: (JGRP-375) Paralellize discovery phase

by Bela Ban (JIRA)

Paralellize discovery phase --------------------------- Key: JGRP-375 URL: http://jira.jboss.com/jira/browse/JGRP-375 Project: JGroups Issue Type: Feature Request Affects Versions: 2.4 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.6 With TCPPING, if we have 10 servers defined in the list, we sequentially send a GET_MBRS_REQ to each. However, if that server is not reachable, we will timeout out on the socket connect call. Also, DNS lookup might take some time, so we might time out if we cannot contact all servers. Example: servers 1 - 10. 1-9 are down or not reachable, plus we have a slow DNS, 10 is running. So before we get to 10, the discovery will timeout and we will become a singleton node. SOLUTION: use threads from the common (global) thread pool in JGroups to parallelize the sending of requests to all 10 servers. -- 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, 3 months

3
5
0 / 0

[JBoss JIRA] Created: (JBAS-3794) Remove all calls to InetAddress.getHostName() (causes reverse DNS lookup)

by Michael Newcomb (JIRA)

Remove all calls to InetAddress.getHostName() (causes reverse DNS lookup) ------------------------------------------------------------------------- Key: JBAS-3794 URL: http://jira.jboss.com/jira/browse/JBAS-3794 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Clustering Affects Versions: JBossAS-4.0.4.GA Environment: Java 5 JBoss 4.0.4 Reporter: Michael Newcomb Assigned To: Brian Stansberry Priority: Minor Any call to InetAddress.getHostName() will cause a reverse DNS lookup. If DNS is not configured properly, can cause slow startup/join times between JBoss clusters. The most notable is in ClusterNode.java: public ClusterNode(IpAddress jgAddress) { if (jgAddress.getAdditionalData() == null) { this.id = jgAddress.getIpAddress().getHostAddress() + ":" + jgAddress.getPort(); } else { this.id = new String(jgAddress.getAdditionalData()); } this.originalJGAddress = jgAddress; StringBuffer sb = new StringBuffer(); java.net.InetAddress jgIPAddr = jgAddress.getIpAddress(); if (jgIPAddr == null) sb.append("<null>"); else { if (jgIPAddr.isMulticastAddress()) sb.append(jgIPAddr.getHostAddress()); else ----->>>> sb.append(getShortName(jgIPAddr.getHostName())); } sb.append(":" + jgAddress.getPort()); this.jgId = sb.toString(); } The following: if (jgIPAddr.isMulticastAddress()) sb.append(jgIPAddr.getHostAddress()); else sb.append(getShortName(jgIPAddr.getHostName())); should be replaced with: sb.append(jgIPAddr.getHostAddress()); -- 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, 3 months

2
3
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-135) Extract the common use clustering code from the JBoss AS codebase

by Brian Stansberry (JIRA)

Extract the common use clustering code from the JBoss AS codebase ----------------------------------------------------------------- Key: JBCLUSTER-135 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-135 Project: JBoss Clustering Issue Type: Task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Critical Fix For: Q3Y6 Remoting, Messaging, JBoss Cache and JBoss AS all have clustering aspects to their functionality. There is potential for code reuse between these projects that can't be realized if the clustering code resides in the cluster module of the AS codebase. 1) Extract general purpose clustering code from the AS cluster module into a separate project and produce binaries that other projects can use without creating a dependence on the AS project. 2) Provide APIs that both support standalone functionality of non-AS projects and facilitate ease of integration into the AS. This task is meant to be an umbrella task, with specific detailed subtasks. This task is primarily focused on meeting the short requirements of JBMESSAGING-516, but we also need to give due consideration to potential use in other projects. -- 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, 3 months

2
4
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-142) Determine binaries

by Brian Stansberry (JIRA)

Determine binaries ------------------ Key: JBCLUSTER-142 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-142 Project: JBoss Clustering Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: Q3Y6 Need to determine what binaries should be built. Projects like Remoting want a lightweight binary, so we may need to create more than one. -- 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, 3 months

2
3
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-143) Create initial release schedule

by Brian Stansberry (JIRA)

Create initial release schedule ------------------------------- Key: JBCLUSTER-143 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-143 Project: JBoss Clustering Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: Q3Y6 Analyze when things need to be done so they can be integrated into dependent projects. -- 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, 3 months

2
3
0 / 0

[JBoss JIRA] Created: (JBAS-3410) VDF Deployer migration tasks

by Scott M Stark (JIRA)

VDF Deployer migration tasks ---------------------------- Key: JBAS-3410 URL: http://jira.jboss.com/jira/browse/JBAS-3410 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Deployment services Reporter: Scott M Stark Assigned To: Dimitris Andreadis Priority: Blocker Fix For: JBossAS-5.0.0.Beta The deployers need to be migrated to the new VDF framework: http://wiki.jboss.org/wiki/Wiki.jsp?page=JBoss5DeploymentFramework The subtasks map to the deployers needing to be migrated. -- 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, 3 months

3
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 February 2007