October 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBREM-557) need to include all the transports within the tests.versioning ant target

by Tom Elrod (JIRA)

need to include all the transports within the tests.versioning ant target ------------------------------------------------------------------------- Key: JBREM-557 URL: http://jira.jboss.com/jira/browse/JBREM-557 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Components: general Affects Versions: 2.0.0.Beta2 (Boon) Reporter: Tom Elrod Assigned To: Tom Elrod Fix For: 2.2.0.Beta1 (Bluto) Due to a problem with the test setup, some of the versioning tests (for rmi and socket) do not pass when running the versioning tests. Know these actually work when run manually, so need to investigate why automated tests are failing. -- 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, 11 months

2
4
0 / 0

[JBoss JIRA] Created: (JBAS-3532) Inject DRM and DS into ClusterPartition

by Brian Stansberry (JIRA)

Inject DRM and DS into ClusterPartition --------------------------------------- Key: JBAS-3532 URL: http://jira.jboss.com/jira/browse/JBAS-3532 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossAS-5.0.0.Beta DRM and DS are now independent services. Inject them into ClusterPartiton so they can be exposed via HAPartition. ClusterPartition in create or start must confirm that the injected DRM and DS are using the same JChannelFactory and stack that it is. -- 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, 11 months

5
8
0 / 0

[JBoss JIRA] Created: (JBAOP-290) Make src/build.xml work

by Kabir Khan (JIRA)

Make src/build.xml work ----------------------- Key: JBAOP-290 URL: http://jira.jboss.com/jira/browse/JBAOP-290 Project: JBoss AOP Issue Type: Task Security Level: Public (Everyone can see) Reporter: Kabir Khan Assigned To: Kabir Khan Fix For: 2.0.0.alpha2 Should be part of the dist and it should be possible to build the full aop/aspects releases and run some of the tests -- 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, 11 months

3
13
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

16 years, 11 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

16 years, 11 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

16 years, 11 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

16 years, 11 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

16 years, 11 months

3
6
0 / 0

[JBoss JIRA] Created: (JBCACHE-754) RPC return values to use a marshaller as well

by Manik Surtani (JIRA)

RPC return values to use a marshaller as well --------------------------------------------- Key: JBCACHE-754 URL: http://jira.jboss.com/jira/browse/JBCACHE-754 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 1.4.0, 2.0.0 Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.1.0 Currently, all RPC calls go through the VersionAwareMarshaller which is responsible for efficiently marshalling JBC internal objects as well as user objects using JBoss Serialization. Return values and exceptions, on the other hand, are marshalled/unmarshalled using JGroups' Util.{to|from}ByteBuffer() which uses standard object serialization. The problems here are twofold: 1) Relatively inefficient (in speed as well as byte array size) marshalling/unmarshalling for return values 2) Potential class loader problems Most RPC calls in JBoss Cache do not have return values so this is not a problem that comes up often, but certain features (clustered cache loader, data gravitation in buddy replication) rely on return values. The solution to this problem is to be able to register a marshaller with the JGroups RPCDispatcher for return values (and exceptions) as well as for the RPC calls themselves. -- 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, 12 months

2
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-718) PojoCache TxLockInterceptor needs to release the lock node as well

by Ben Wang (JIRA)

PojoCache TxLockInterceptor needs to release the lock node as well ------------------------------------------------------------------ Key: JBCACHE-718 URL: http://jira.jboss.com/jira/browse/JBCACHE-718 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Components: PojoCache Reporter: Ben Wang Assigned To: Ben Wang Priority: Minor Fix For: 2.0.0 Currently, in TxLockInterceptor, I achieve the node lock by applying explicitly a cache.put(). It has two drawbacks: 1) It explicit going to insert a value to that node 2) Needs to do a remove when it is done. Not much can be done re: 1 now, but we should do 2, alhtough it will degrade the performance further. -- 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, 12 months

3
5
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2006