October 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBCACHE-1165) Endless loop in PessimisticLockInterceptor

by Jacek Halat (JIRA)

Endless loop in PessimisticLockInterceptor ------------------------------------------ Key: JBCACHE-1165 URL: http://jira.jboss.com/jira/browse/JBCACHE-1165 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 1.4.1.SP4 Environment: Windows XP, Sun jdk150_06 Solaris 10 Reporter: Jacek Halat Assigned To: Manik Surtani When 2 Threads are simulatanous putting/removing values from this same node TreeCache hang's up and goes into endless loop. Main loop looks like: for (int x = 0; x < 1000; x++) { tm.begin(); System.out.println("R" + Thread.currentThread().getName()); //inside transaction cache.remove("/a"); System.out.println("AR" + Thread.currentThread().getName()); tm.commit(); //outside transaction System.out.println("P" + Thread.currentThread().getName()); cache.put("/a/b/c/d", "text"+x,"b"); System.out.println("AP" + Thread.currentThread().getName()); } -- 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

5
19
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, 6 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, 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: (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-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

[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: (JBPORTAL-1466) customizable error page in the portlet that threw the exception

by William DeCoste (JIRA)

customizable error page in the portlet that threw the exception --------------------------------------------------------------- Key: JBPORTAL-1466 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1466 Project: JBoss Portal Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Portal Core Affects Versions: 2.6.CR2 Reporter: William DeCoste Assigned To: Julien Viet Feature request from Intuit Feature: For error handing, the portlet should be able to render a customizable error page in the portlet that threw the exception. This feature would be something similar to the error-page tag in web.xml. Currently JBoss Portal provides a way to either hide the portlet that has errors or show it with the stack trace or show it with only the error message. But there is no way where the developers could customize the contents that appear in the window for the portlet that throws an exception. We had opened case #00015844 about not being able to use web.xml error-page tag with JBoss portal applications. The provided solution about catching the specific exception in the render method does not work as it is not customizable & too tied up with the portlet class code. And as you might be aware about the WAP function - someone using the WAP application components will not be able to customize it according to their requirements. We know that the portlet standard doesn't specify what to do, and we're just trying to have it behave as much like a regular web application in lieu of something being in the standard. -- 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

4
13
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, 6 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 October 2007