December 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBCACHE-1230) Node.toString() should not print entire contents of a node if it exceeds a certain size

by Manik Surtani (JIRA)

Node.toString() should not print entire contents of a node if it exceeds a certain size --------------------------------------------------------------------------------------- Key: JBCACHE-1230 URL: http://jira.jboss.com/jira/browse/JBCACHE-1230 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.1.0.CR2 Reporter: Manik Surtani Assigned To: Manik Surtani Priority: Minor Fix For: 2.1.0.GA Can be very noisy in the logs -- 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, 6 months

1
5
0 / 0

[JBoss JIRA] Created: (JBCACHE-1241) Buddy replication, add data to a node and delete root will cause a exception to be thrown

by Mircea Markus (JIRA)

Buddy replication, add data to a node and delete root will cause a exception to be thrown ----------------------------------------------------------------------------------------- Key: JBCACHE-1241 URL: http://jira.jboss.com/jira/browse/JBCACHE-1241 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.1.0.BETA1 Reporter: Mircea Markus Assigned To: Manik Surtani Fix For: 2.1.0.GA, 1.4.X BuddyReplicationTestsBase on trunk was added to reproduce the issue -- 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, 6 months

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

3
5
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1069) persistance.xml with <jar-file> looks for jar file in the wrong place

by Magnus Sandberg (JIRA)

persistance.xml with <jar-file> looks for jar file in the wrong place --------------------------------------------------------------------- Key: EJBTHREE-1069 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1069 Project: EJB 3.0 Issue Type: Bug Environment: JBoss AS 4.2.0.GA (Hibernate 3.3.1.GA) Reporter: Magnus Sandberg Fix For: AS 4.2.0 GA When using <jar-file> references in persistance.xml the Ejb3Configuration does not look for the jar relative to the jar with the persistance.xml but relative to from where jboss is started. -- 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, 6 months

3
2
0 / 0

[JBoss JIRA] Created: (JGRP-631) Thread pools shared within the same JVM

by Bela Ban (JIRA)

Thread pools shared within the same JVM --------------------------------------- Key: JGRP-631 URL: http://jira.jboss.com/jira/browse/JGRP-631 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.7 If we have multiple Channels inside the same JVM, we may want to enable sharing of the - default thread pools - OOB thread pools and - timer thread pools This could be enabled by marking a thread pool as 'shared'. Advantage: threads are shared, so we need fewer resources -- 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, 6 months

1
3
0 / 0

[JBoss JIRA] Created: (JBAS-5068) Possible NullPointerException in DistributedReplicantManager#_add()

by Takayoshi Kimura (JIRA)

Possible NullPointerException in DistributedReplicantManager#_add() ------------------------------------------------------------------- Key: JBAS-5068 URL: http://jira.jboss.com/jira/browse/JBAS-5068 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Clustering Affects Versions: JBossAS-4.2.2.GA, JBossAS-4.2.1.GA, JBossAS-4.2.0.GA Reporter: Takayoshi Kimura Assigned To: Brian Stansberry Priority: Minor DistributedReplicantManager#_add() can be called before asynchHandler initialization when multiple nodes starts simultaneously. It results NullPointerException below: 2007-11-09 20:40:17,315 ERROR [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.DefaultPartition] _add failed java.lang.NullPointerException at org.jboss.ha.framework.server.DistributedReplicantManagerImpl._add(DistributedReplicantManagerImpl.java:622) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:330) at org.jboss.ha.framework.server.HAPartitionImpl.handle(HAPartitionImpl.java:1126) at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:654) at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:544) at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:367) at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:777) at org.jgroups.JChannel.up(JChannel.java:1091) Impact: Nothing so far, just appearing the ERROR log above. To reproduce this: It's very hard to reproduce. Insert Thread.sleep() call before asynchHandler initialization in DistributedReplicantManager#start() and boot multiple nodes simultaneously. DistributedReplicantManager#start(): // Create the asynch listener handler thread Thread.sleep(10000); asynchHandler = new AsynchEventHandler(this, "AsynchKeyChangeHandler"); asynchHandler.start(); -- 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, 6 months

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

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