September 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JGRP-322) Provide 3 major default configurations (udp.xml, tcp.xml and tcp-nio.xml)

by Bela Ban (JIRA)

Provide 3 major default configurations (udp.xml, tcp.xml and tcp-nio.xml) ------------------------------------------------------------------------- Key: JGRP-322 URL: http://jira.jboss.com/jira/browse/JGRP-322 Project: JGroups Issue Type: Feature Request Affects Versions: 2.3 SP1 Reporter: Bela Ban Assigned To: Bela Ban Priority: Minor Fix For: 2.2.9 SP4 Those configs should be the same in stacks.xml (for the Multiplexer) as well -- 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

19 years, 10 months

1
2
0 / 0

[JBoss JIRA] Created: (JBESB-144) Add unit tests for new EPR and messaging classes.

by Mark Little (JIRA)

Add unit tests for new EPR and messaging classes. ------------------------------------------------- Key: JBESB-144 URL: http://jira.jboss.com/jira/browse/JBESB-144 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: ESB Core Reporter: Mark Little Assigned To: Mark Little Fix For: 4.0 -- 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

19 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JGRP-323) Set shunning to false in both FD and GMS

by Bela Ban (JIRA)

Set shunning to false in both FD and GMS ---------------------------------------- Key: JGRP-323 URL: http://jira.jboss.com/jira/browse/JGRP-323 Project: JGroups Issue Type: Task Affects Versions: 2.3 SP1 Reporter: Bela Ban Assigned To: Bela Ban Priority: Optional Fix For: 2.4 should be the default, even if no value is set -- 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

19 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-3686) Incomplete Deployment error not thrown when DefaultDS not deployed (/ missing at the end of deployment URL)

by Galder Zamarreno (JIRA)

Incomplete Deployment error not thrown when DefaultDS not deployed (/ missing at the end of deployment URL) ----------------------------------------------------------------------------------------------------------- Key: JBAS-3686 URL: http://jira.jboss.com/jira/browse/JBAS-3686 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Deployment services Affects Versions: JBossAS-4.0.4.GA Reporter: Galder Zamarreno Assigned To: Dimitris Andreadis A URL deployment attribute like this on jboss.deployment:type=DeploymentScanner,flavor=URL (notice missing / at the end): <attribute name="URLs"> deploy </attribute> leads to the datasource not deploying due to waiting on: 2006-09-22 12:04:07,640 DEBUG [org.jboss.system.ServiceController] waiting in start jboss.jca:service=ManagedConnectionFactory,name=DefaultDS on jboss.jca:service=RARDeployment,name='jboss-local-jdbc.rar' JBoss deploys this instead: 2006-09-22 12:04:06,062 DEBUG [org.jboss.resource.deployment.RARDeployment] Created jboss.jca:service=RARDeployment,name='deploy#jboss-local-jdbc.rar' The bug is that DefaultDS is an incomplete deployment and the URLDeploymentScanner should throw something like this: 17:29:03,852 ERROR [URLDeploymentScanner] Incomplete Deployment listing: ...... -- 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

19 years, 10 months

3
4
0 / 0

[JBoss JIRA] Created: (JBWEB-61) Apache Tomcat 6.0 release engineering

by Remy Maucherat (JIRA)

Apache Tomcat 6.0 release engineering ------------------------------------- Key: JBWEB-61 URL: http://jira.jboss.com/jira/browse/JBWEB-61 Project: JBoss Web Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Remy Maucherat Assigned To: Remy Maucherat -- 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

19 years, 10 months

1
6
0 / 0

[JBoss JIRA] Created: (JGRP-325) Priority traffic should use separate network

by Bela Ban (JIRA)

Priority traffic should use separate network -------------------------------------------- Key: JGRP-325 URL: http://jira.jboss.com/jira/browse/JGRP-325 Project: JGroups Issue Type: Feature Request Affects Versions: 2.4 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.x Priority traffic, e.g. heartbeats from FD, or JOIN/LEAVE requests should use a separate NIC, possibly connected to a separate network. This would ensure that priority traffic is *not* discarded because of regular replication traffic which clogs the line -- 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

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-3679) BMP entitybeans cause db-deadlocks

by Onno de Groote (JIRA)

BMP entitybeans cause db-deadlocks ---------------------------------- Key: JBAS-3679 URL: http://jira.jboss.com/jira/browse/JBAS-3679 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Transaction Manager Affects Versions: JBossAS-3.2.7 Final Environment: windows 2003, sun jvm 1.4.2_06, INet Opta JDBC driver 6.04, SQLSERVER 2000 Reporter: Onno de Groote Assigned To: Adrian Brock when using local-tx datasources with no transactionisolation-level specified, it looks like jboss sets it to repeatable-read or higher. The problem with this situation is that in high concurrency situations, two threads using the same entity-bean ( with or without same primary-key ) cause deadlocks in SQLServer. The reason for this is that de select queries in the findby and ejbload code set S-locks on the indexes in the database, thereby blocking any update query of a different thread. In the situation that thread-1 first performs the findby and ejbload, causing S-locks, after which thread-2 does the same, after which thread-1 tries ejbstore, which blocks because of the S-locks of thread-2. Then thread-2 tries the ejbstore, which in turn is blocked by the S-locks of thread-1. SQLServer detectes a deadlock and selects a deadlock victim and one transaction fails. In this case there should not have been a problem so the transaction-failure is incorrect and only caused by the wrong transactionisolation level -- 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

19 years, 10 months

2
1
0 / 0

[JBoss JIRA] Updated: (JBAS-3325) Remove old code

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3325?page=all ] Dimitris Andreadis updated JBAS-3325: ------------------------------------- Fix Version/s: JBossAS-4.0.6.CR1 (was: JBossAS-4.0.5.GA) > Remove old code > --------------- > > Key: JBAS-3325 > URL: http://jira.jboss.com/jira/browse/JBAS-3325 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Other > Affects Versions: JBossAS-4.0.4.GA > Environment: JBoss 4.0.3.SP1 > $ java -version > java version "1.4.2_12" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_12-b03) > Java HotSpot(TM) Client VM (build 1.4.2_12-b03, mixed mode) > $ java -version > java version "1.5.0_07" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-b03) > Java HotSpot(TM) Client VM (build 1.5.0_07-b03, mixed mode, sharing) > Reporter: Robert Schroeder > Assigned To: Dimitris Andreadis > Fix For: JBossAS-4.0.6.CR1 > > > http://wiki.jboss.org/wiki/Wiki.jsp?page=UsingJBossBehindAFirewall mentions the parameter "java.rmi.server.hostname" to set if the external host name differs from the local host (e.g. server machine is behind a firewall) > But org.jboss.web.WebService doesn'r recognize this parameter: > String hostname = server.getBindAddress(); // this always returns something, at least "0.0.0.0"! > // If not user specified hostname given, then try to determine what it should be > if (hostname == null) //this branch is never executed! > { > // First look for the rmi server name > try > { > hostname = System.getProperty("java.rmi.server.hostname"); // this parameter is not recognized as this branch is never executed > } > catch (SecurityException e) > { > // ignore, but don't be silent > ThrowableHandler.addWarning(e); > } > // else use the localhost name > if (hostname == null) > { > try > { > hostname = InetAddress.getLocalHost().getHostName(); > } > catch (IOException e) > { > log.error("Failed to get localhost name; ignoring", e); > } > } > if (hostname != null) > { > setHost(hostname); > } > } > // Host must be set to continue (either by user or detection) > String address = getHost(); > if (address == null) > throw new MissingAttributeException("Host"); > // Set the rmi codebase if it is not already set > String codebase = System.getProperty("java.rmi.server.codebase"); > if (codebase == null) > { > address = ServerConfigUtil.fixRemoteAddress(address); > codebase = "http://" + address + ":" + getPort() + "/"; > System.setProperty("java.rmi.server.codebase", codebase); > } > log.info("Using RMI server codebase: " + codebase); > So the resulting problem is that codebase contains an address which is not reachable from the other side of firewall because "java.rmi.server.hostname" is not recognized (same for "-Djava.rmi.server.useLocalHostname=false" ) > Example: > JBoss started with parameter set "-Djava.rmi.server.hostname=as2.subdomain1.subdomain2.test.com" > but (thanks to rmi logging) the proxy objects on client side have codebase set to "http://as2:<port>" and not to "http://as2.subdomain1.subdomain2.test.com:<port>" as expected. > JBoss 4 runs on a linux machine > hostname --> "as2" > hostname -f --> "as2.subdomain1.subdomain2.test.com" -- 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

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-3399) Transaction timeout fires too late

by tbech (JIRA)

Transaction timeout fires too late ---------------------------------- Key: JBAS-3399 URL: http://jira.jboss.com/jira/browse/JBAS-3399 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Transaction Manager Affects Versions: JBossAS-4.0.3 SP1 Reporter: tbech Assigned To: Adrian Brock Priority: Minor Transaction timeout is fired in the 'commit' probably. It is far too late in order to really limit the transaction. Scenario: - do long job in transaction (CMT); - job is finished; - commit; - timeout exception is thrown; Doesn't matter what timeout is set, server does whole job (few hours even) and at the end throws exception. Shouldn't container: a) throw an error after timeout b) stop the called EJB method ??? -- 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

19 years, 10 months

2
4
0 / 0

[JBoss JIRA] Created: (EJBTHREE-711) During undeployment stop is being called twice

by Carlo de Wolf (JIRA)

During undeployment stop is being called twice ----------------------------------------------- Key: EJBTHREE-711 URL: http://jira.jboss.com/jira/browse/EJBTHREE-711 Project: EJB 3.0 Issue Type: Bug Reporter: Carlo de Wolf Fix For: EJB 3.0 RC9 - FD After destroy is called on the container, stop is called again. -- 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

19 years, 10 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 September 2006