July 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-5702) Add JDBC4 support for DataSourceInterceptor

by Jesper Pedersen (JIRA)

Add JDBC4 support for DataSourceInterceptor ------------------------------------------- Key: JBAS-5702 URL: http://jira.jboss.com/jira/browse/JBAS-5702 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: JCA service Affects Versions: JBossAS-5.0.0.CR1 Reporter: Jesper Pedersen Assigned To: Jesper Pedersen Fix For: JBossAS-5.0.0.CR2 Add support for JDBC4 to org.jboss.varia.stats.DataSourceInterceptor in the AS/varia module. -- 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

17 years, 11 months

1
6
0 / 0

[JBoss JIRA] Created: (JBAS-5717) jboss-ds_1_5.dtd has syntax error

by Juergen Zimmermann (JIRA)

jboss-ds_1_5.dtd has syntax error --------------------------------- Key: JBAS-5717 URL: http://jira.jboss.com/jira/browse/JBAS-5717 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-5.0.0.CR1 Reporter: Juergen Zimmermann In examples/dtd/jboss-ds_1_5.dtd a comma is missing at the end of line 44: Inside <!ELEMENT local-tx-datasource ...: line 44: validate-on-match?, idle-timeout-minutes? line 45: no-tx-separate-pools? , new-connection-sql? , check-valid-connection-sql? , -- 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

17 years, 11 months

3
2
0 / 0

[JBoss JIRA] Updated: (JBAS-1436) Improved management

by Vicky Kak (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1436?page=all ] Vicky Kak updated JBAS-1436: ---------------------------- Fix Version/s: (was: JBossAS-4.2.3.GA) > Improved management > ------------------- > > Key: JBAS-1436 > URL: http://jira.jboss.com/jira/browse/JBAS-1436 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JCA service > Reporter: Adrian Brock > Assigned To: Vicky Kak > Priority: Minor > Fix For: JBossAS-5.1.0.CR1 > > > Forum Discussion Thread: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=48682 > **This is a holder issue. Each section should be raised as a new issue as it is > developed with a link from this issue.** > There are a number of areas in JCA that need better management capabilities. > Some of these stats may also reveal the need for new configuration/tuning parameters. > In core JCA: > 1) Better visibility on the ManagedConnectionFactory. > This is currently a DynamicMBean that provides basic config parameters, but we could also > provide a proxy/wrapper to provide statistics of operations on the factory and its > ManagedConnections. > a) createManagedConnections > b) matchManagedConnections > c) events on from the listeners > 2) Better visibility of the Pool(s) > Only top level statistics are provided (you cannot see the subpools). > The statistics are also not synchronized with the pool (for performance reasons > and also the fact that each stat is retrieved on individual MBean getAttribute requests) > Additional statistics could include wait times when requests are waiting on an empty pool, > idle time of unused connections, etc. > 3) Better visibility of the ConnectionManager > Currently this has no visibility for management. > Its main responsibilties are transactions enlistment and security. > e.g. This could show how long is wasted because <track-connection-by-tx/> does not > return the connection the pool until transaction completion. > 4) JDBC resource adapter > PreparedStatementCache stats > Query time stats > etc. > 5) JMS resource adapter > Message send/receive stats > 6) Inbound messaging > Stats for message delivery > 7) Transaction inflow > Stats for transaction inflow and also display a list of current inbound transactions > 8) Work management > Stats for the work management pools and timers -- 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

17 years, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-2131) Better support for BMT SFSB "mistakes"

by Jesper Pedersen (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2131?page=all ] Jesper Pedersen updated JBAS-2131: ---------------------------------- Fix Version/s: (was: JBossAS-4.2.3.GA) > Better support for BMT SFSB "mistakes" > -------------------------------------- > > Key: JBAS-2131 > URL: http://jira.jboss.com/jira/browse/JBAS-2131 > Project: JBoss Application Server > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: EJB2 > Affects Versions: JBossAS-4.0.3RC2 > Reporter: Adrian Brock > Assigned To: Jesper Pedersen > > Further to JBAS-2128 we should also implement some sort of listener on the transaction timeout. > Given the stupid BMT SFSB semantics (this part of the spec is one my favourite anti-patterns :-) > where a client can hog server resources. > sfsb.doBegin(); > doLongRunningProcess(); > sfsb.doCommit(); > And even crash during the doLongRunningProcess(). > We should allow the server to reclaim the resources from a transaction timeout more quickly. > Another option would be to allow a configuration that does a rollback() at transaction timeout. > But this would require some serious testing to make sure all JBoss code is checking transaction status correctly. > It would also confuse any non-j2ee compliant framework that registers transaction synchronizations > and then assumes their "thread local" is still valid from the timeout thread or they aren't threadsafe. > No names mentioned to protect the guilty :-) -- 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

17 years, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-4571) local ant config upsets junit spawns in test build

by Andrew Dinn (JIRA)

local ant config upsets junit spawns in test build -------------------------------------------------- Key: JBAS-4571 URL: http://jira.jboss.com/jira/browse/JBAS-4571 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-4.2.1.GA Reporter: Andrew Dinn The build.sh script should insert --no_config into ANT_OPTIONS before invoking ant. Otherwise when the user has an ant.conf in $HOME/.ant or there is an ant.conf in /etc this can mess up the creation of junit tasks defined in build.xml -- 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

17 years, 11 months

2
1
0 / 0

[JBoss JIRA] Created: (JBAS-4478) ignore local ant options when building

by Dennis Gregorovic (JIRA)

ignore local ant options when building -------------------------------------- Key: JBAS-4478 URL: http://jira.jboss.com/jira/browse/JBAS-4478 Project: JBoss Application Server Issue Type: Patch Security Level: Public (Everyone can see) Components: Build System Affects Versions: JBossAS-4.2.0.GA, JBossAS-5.0.0.Beta2, JBossAS-4.0.4.GA Reporter: Dennis Gregorovic Assigned To: Rajesh Rajasekaran Priority: Minor build/build.sh should use --noconfig when invoking Ant so that the local Ant libraries and configurations do not get picked up. -- 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

17 years, 11 months

3
4
0 / 0

[JBoss JIRA] Created: (JBREM-1007) Change all logging to use XNIO Logger class

by David Lloyd (JIRA)

Change all logging to use XNIO Logger class ------------------------------------------- Key: JBREM-1007 URL: http://jira.jboss.com/jira/browse/JBREM-1007 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: David Lloyd Fix For: 3.0.0-M3 Once conversion is complete, the Logger classes and the corresponding log build modules should be removed from the project. -- 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

17 years, 11 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-993) Change stream handler API to use XNIO handlers

by David Lloyd (JIRA)

Change stream handler API to use XNIO handlers ---------------------------------------------- Key: JBREM-993 URL: http://jira.jboss.com/jira/browse/JBREM-993 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: David Lloyd Fix For: 3.0.0-M3 The stream handler API should be changed to use XNIO IoHandlers instead of the existing StreamHandlers. -- 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

17 years, 11 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-4918) for logging, server.xml references another variable than jboss-log4j.xml does

by Jon Stevens (JIRA)

for logging, server.xml references another variable than jboss-log4j.xml does ----------------------------------------------------------------------------- Key: JBAS-4918 URL: http://jira.jboss.com/jira/browse/JBAS-4918 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Logging Affects Versions: JBossAS-4.2.0.GA Environment: all Reporter: Jon Stevens Assigned To: Scott M Stark jboss-log4j.xml has this as default: <param name="File" value="${jboss.server.log.dir}/server.log"/> jboss-web.deployer has this:  <Valve className="org.apache.catalina.valves.AccessLogValve" prefix="localhost_access_log." suffix=".log" pattern="common" directory="${jboss.server.home.dir}/log" resolveHosts="false" /> Now, because those two variables are different, I can't easily setup logging to say /var/log/jboss because #1. there is two different variables to define: ${jboss.server.home.dir} and ${jboss.server.log.dir} #2. the access logger has /log hard coded to the end of the directory attribute which makes it impossible to set the two variables to the same value. My preference would be that the default is made to a single variable ${jboss.server.log.dir} which can control everything. jon -- 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

17 years, 11 months

2
3
0 / 0

[JBoss JIRA] Created: (JBAS-5716) AspectDeployer is incredibly slow

by Richard Huddleston (JIRA)

AspectDeployer is incredibly slow --------------------------------- Key: JBAS-5716 URL: http://jira.jboss.com/jira/browse/JBAS-5716 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-5.0.0.CR1 Environment: Windows XP ... quad cpu 3 gig, 2+ gigs of memory. Using the default server with some stuff removed. converted defaultDS to mysql Reporter: Richard Huddleston AspectDeployer is incredibly slow and CPU utiliziation is less than 25% on a 4 CPU system. Takes 3+ minutes. 11:21:48,326 INFO [WebService] Using RMI server codebase: http://hf-ws-018:8083/ 11:22:09,405 INFO [AspectDeployer] Deploying xml into org.jboss.aop.AspectManager@1ba1db5 for BaseClassLoader@5b56c4{vfsfile:/U:/Programs/jboss-5.0.0.CR1/server/default/deploy/ejb3-interceptors-aop.xml} 11:25:44,643 WARN [JBossASSecurityMetadataStore] -- 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

17 years, 11 months

1
0
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 July 2008