November 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-4815) UnifiedInvokerProxyHA - Client instance check and assignment should be atomic

by Galder Zamarreno (JIRA)

UnifiedInvokerProxyHA - Client instance check and assignment should be atomic ----------------------------------------------------------------------------- Key: JBAS-4815 URL: http://jira.jboss.com/jira/browse/JBAS-4815 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Clustering, Remoting Affects Versions: JBossAS-4.2.1.GA, JBossAS-5.0.0.Beta2 Reporter: Galder Zamarreno Assigned To: Galder Zamarreno I have realised that UnifiedInvokerProxy/UnifiedInvokerProxyHA maintain a instance reference to the InvokerLocator/Client instances to a specific invocation is using. That is, when a new target is chosen, the unified proxy updates its Client and corresponding InvokerLocator instances (if they've changed), and uses the Cient instance variable to make the call. As far as I can see there's no synchronisation in the usage/assignment of Client or InvokerLocator. Proxies are meant to be thread safe which means that multiple client app threads could be using the same proxy without any problems. I can see all this going wrong the moment someone uses client proxies this way in a clustered environment with round robin load balance policy. We've got no guarantee that round robin will work correctly in these situations. Several solutions have been discussed in -- 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, 9 months

1
7
0 / 0

[JBoss JIRA] Created: (JBCACHE-890) Custom flags per node, incorporate and consolidate some domain-specific flags

by Elias Ross (JIRA)

Custom flags per node, incorporate and consolidate some domain-specific flags ----------------------------------------------------------------------------- Key: JBCACHE-890 URL: http://jira.jboss.com/jira/browse/JBCACHE-890 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Elias Ross Assigned To: Manik Surtani I believe that with java.util.EnumSet and a list of enumerations, that some of the specific flags we track on a node could be consolidated. Immediately what comes to mind are the CacheLoader flags "childrenLoaded" and "dataLoaded" Further, I believe that some additional functionality could be incorporated. For instance: 1. For certain internal nodes, they could be marked as "internal" or "local" and not replicated. Or possibly hidden from access entirely. 2. Some nodes might be marked as "read-only" or "non-persisted" or "non-evictable" 3. Some nodes might have special sorted ordering. -- 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, 9 months

3
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-1218) System property substitution in config file parsing

by Brian Stansberry (JIRA)

System property substitution in config file parsing --------------------------------------------------- Key: JBCACHE-1218 URL: http://jira.jboss.com/jira/browse/JBCACHE-1218 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Manik Surtani Since JBC parses its own config files it would be nice to support the ${some.system.property:somedefault} syntax. This should be trivial to do; just add callouts to org.jboss.util.StringPropertyReplacer.replaceProperties(String) in XmlHelper.getAttributeValue() and XmlHelper.getElementContent(). This could even be helpful in JBoss AS if XmlParsingConfigurationRegistry is used -- the normal AS parsing wouldn't be used in that case. But, it would be simple enough though for me to write a different ConfigurationRegistry that had its config injected from MC beans rather than parsing the XML itself. Manik, I left this assigned to you to give you a shot at making any inputs. If you think its worthwhile, feel free to assign back to me. -- 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, 9 months

3
6
0 / 0

[JBoss JIRA] Created: (JBAS-3981) Statment caching in update query which return value

by erahamim (JIRA)

Statment caching in update query which return value ---------------------------------------------------- Key: JBAS-3981 URL: http://jira.jboss.com/jira/browse/JBAS-3981 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-4.0.5.GA Environment: jboss 4.0.5 on windows xp / linux with database oracle 10.0.2 Reporter: erahamim Priority: Minor When I set statements cache in oracle-xa-ds.xml: <prepared-statement-cache-size>100</prepared-statement-cache-size> For the following statement: BEGIN UPDATE table SET A=? WHERE ID=? AND TIME=? RETURNING TIME INTO ?; END con = DataSourceManager.getConnection(); statement = con.prepareCall( 'The above query'); statement.setInt(1,1); statement.setTimestamp(2, myTime); statement.registerOutParameter(3, Types.TIMESTAMP); statement.executeUpdate(); final Timestamp ts = statement.getTimestamp(lastIndex); In this scenario, I'm always getting back the time result even if the update didn't match any row in database. When I drop the statement cache I get the result only if there was a row that was updated by this statement. I can't use the return value from executeUpdate() since it always return 1. -- 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, 9 months

3
2
0 / 0

[JBoss JIRA] Created: (JBAS-3511) JMS ASF integration and JMS Session Pools need resource management improvements

by Weston Price (JIRA)

JMS ASF integration and JMS Session Pools need resource management improvements ------------------------------------------------------------------------------- Key: JBAS-3511 URL: http://jira.jboss.com/jira/browse/JBAS-3511 Project: JBoss Application Server Issue Type: Support Patch Security Level: Public (Everyone can see) Components: JCA service Affects Versions: JBossAS-4.0.3 SP1 Reporter: Weston Price Assigned To: Weston Price Priority: Minor A client has requested that the JMS applications server integration facilities for resource management and JMS session pooling be improved primarily in two areas: 1) The ability to not create all JMS sessions on container startup. 2) The ability to recycle/release JMS sessions based on a configurable timeout. Both these features would need to be added to the existing JMSContainerInvoker as well as carried forward to the JBossJCA adapter prior to production release. -- 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, 9 months

3
3
0 / 0

[JBoss JIRA] Created: (JBAS-4200) Last Resource Gambit for non XA MDB

by Weston Price (JIRA)

Last Resource Gambit for non XA MDB ----------------------------------- Key: JBAS-4200 URL: http://jira.jboss.com/jira/browse/JBAS-4200 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: JCA service Reporter: Weston Price Assigned To: Weston Price Currently non XA MDB's do not support the LRG but rely on the local JMS API for redelivery support. It should be considered if we should provide this. -- 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, 9 months

2
1
0 / 0

[JBoss JIRA] Created: (JBAS-3943) JMS/JCA adapter should provide for security domain authentication in addition to JMS client credential

by Weston Price (JIRA)

JMS/JCA adapter should provide for security domain authentication in addition to JMS client credential ------------------------------------------------------------------------------------------------------ Key: JBAS-3943 URL: http://jira.jboss.com/jira/browse/JBAS-3943 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: JCA service Reporter: Weston Price Assigned To: Weston Price Current the JCA/JMS adapter does not allow for security domain based authentication. There is nothing in the JCA spec or in the JMS spec that would prohibit this type of authentication. -- 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, 9 months

2
1
0 / 0

[JBoss JIRA] Created: (JBAS-4001) JMS/JCA inflow adapter needs to be backported from head to 4.2 and 4.0.5 CP releases

by Weston Price (JIRA)

JMS/JCA inflow adapter needs to be backported from head to 4.2 and 4.0.5 CP releases ------------------------------------------------------------------------------------ Key: JBAS-4001 URL: http://jira.jboss.com/jira/browse/JBAS-4001 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JCA service Affects Versions: JBossAS-4.0.5.GA, JBossAS-4.2.0.GA, JBossAS-4.0.5.SP1 Reporter: Weston Price Assigned To: Weston Price The JCA/JMS inflow adapter changes in HEAD need to be backported to 4.x releases. Changes made affect transaction processing that will resolve transaction problems for redelivery for BMT and CMT Not support MDB's. -- 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, 9 months

2
1
0 / 0

[JBoss JIRA] Created: (JBAS-4010) XATerminator interrface of TxManager is not including error codes in XAExceptions thrown

by Adrian Brock (JIRA)

XATerminator interrface of TxManager is not including error codes in XAExceptions thrown ---------------------------------------------------------------------------------------- Key: JBAS-4010 URL: http://jira.jboss.com/jira/browse/JBAS-4010 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: JCA service Affects Versions: JBossAS-4.0.5.GA Reporter: Adrian Brock Assigned To: Weston Price Attachments: XAException.diff According to the javadoc for XATerminator, it should include an error code in the XAException thrown: e.g. see http://java.sun.com/j2ee/1.4/docs/api/javax/resource/spi/XATerminator.htm... This is similar to the fix for the JBossXALocalException done in JBAS-2807 However, our XATerminator impl in TxManager is not including the error code in the thrown XAException. I'm attaching a diff that shows how to fix this for prepare(), i.e. add XA_RBROLLBACK but this also needs doing for the other methods commit/forget/rollback and tests creating to prevent regression. -- 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, 9 months

2
4
0 / 0

[JBoss JIRA] Created: (JBAS-4381) Change the JMS resource adapter to better re-use resources internally

by Adrian Brock (JIRA)

Change the JMS resource adapter to better re-use resources internally --------------------------------------------------------------------- Key: JBAS-4381 URL: http://jira.jboss.com/jira/browse/JBAS-4381 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: JCA service Reporter: Adrian Brock Currently in the JMS resource adapter it always creates a connection for each session. This is mainly because it implements the pooling at the session level, but some of the pooling parameters are specified on the connection, i.e. user/password/client id. Ideally, the pooled sessions should be able to share the same connection if they have the same parameters at the connection 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

16 years, 9 months

3
3
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2007