October 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Commented: (JBMESSAGING-406) Persistence refactoring

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-406?page=comments#action_12... ] Tim Fox commented on JBMESSAGING-406: ------------------------------------- We need to support automatic failover for the case where no shared file systems is present. In which case we need to replicate state to a buddy. This should be configurable on a per queue level. We can supply different levels of reliability: 1) Once and only once - with this mode we would need two streams one for replication messages and one for replication acks We would also need to store last sequence received in the storage to avoid having to use XA 2) At most once - replication sent async. Chance of message loss. 3) No replication > Persistence refactoring > ----------------------- > > Key: JBMESSAGING-406 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-406 > Project: JBoss Messaging > Issue Type: Task > Reporter: Tim Fox > Assigned To: Tim Fox > Priority: Critical > Fix For: 2.0.0 Alpha > > > Need to refactor persistence so each node has its own storage. > We should provide at least three local persistence manager configs: > 1) JDBC local pm that works out of the box with HSQL - not recommended for production. > 2) BDB based pm that customers need to download - recommended for best performance. > Should optimise for the SAN use case. > Need to consider whether we need to support replication for failover too. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1118) Sucker connection created back to itself doesn't need to be created

by Jay Howell (JIRA)

Sucker connection created back to itself doesn't need to be created ------------------------------------------------------------------- Key: JBMESSAGING-1118 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1118 Project: JBoss Messaging Issue Type: Bug Components: Messaging Core Affects Versions: 1.4.0.GA Reporter: Jay Howell Assigned To: Tim Fox Priority: Minor The following code in ClusteredConnecitonManager creates a connection back to itself and is never used in a non-clustered environment. So if you have a non-clustered environment, and you are running only one server, if you look at the connections in the peer mbean, you can see the connection client for the sucker. while (iter.hasNext()) { Map.Entry entry = (Map.Entry)iter.next(); Integer nid = (Integer)entry.getKey(); ClientConnectionFactoryDelegate delegate = (ClientConnectionFactoryDelegate)entry.getValue(); if (connections.get(nid) == null) { try { ConnectionInfo info = new ConnectionInfo(new JBossConnectionFactory(delegate), suckerUser, suckerPassword); log.trace(this + " created connection info " + info); connections.put(nid, info); info.start(); } catch (Exception e) { log.error("Failed to start connection info ", e); } } -- 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, 9 months

2
2
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1120) Data channel from MultiplexerChannelFactory prevents state transfers from other users of the shared channel

by Brian Stansberry (JIRA)

Data channel from MultiplexerChannelFactory prevents state transfers from other users of the shared channel ----------------------------------------------------------------------------------------------------------- Key: JBMESSAGING-1120 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1120 Project: JBoss Messaging Issue Type: Bug Components: Messaging Core Distributed Support Affects Versions: 1.4.0.GA Reporter: Brian Stansberry Assigned To: Tim Fox JBM's usage of the JGroups JChannelFactory is causing the startup of the AS to hang. Problem is JBM's MultiplexerChannelFactory creates the data channel as follows: public Channel createDataChannel() throws Exception { return (Channel) server.invoke(this.channelFactory, MUX_OPERATION, new Object[]{dataStack, uniqueID + "-DATA", Boolean.TRUE, uniqueID}, MUX_SIGNATURE); } The Boolean.TRUE argument tells the JGroups multiplexer that a getState() call will be invoked for this service. JBM never calls getState(), so it *must not* pass Boolean.TRUE. Valid usages are: public Channel createDataChannel() throws Exception { String[] simpleMuxSignature = new String[] {"java.lang.String", "java.lang.String"}; return (Channel) server.invoke(this.channelFactory, MUX_OPERATION, new Object[]{dataStack, uniqueID + "-DATA"}, simpleMuxSignature); } or public Channel createDataChannel() throws Exception { return (Channel) server.invoke(this.channelFactory, MUX_OPERATION, new Object[]{dataStack, uniqueID + "-DATA", Boolean.FALSE, null}, MUX_SIGNATURE); } The former invokes a convenience method that delegates to the latter. Passing true for the "register_for_state_transfer" param tells JGroups that you will call getState(). If several services create MuxChannels based on the same underlying JChannel, JGroups will try to group together their state transfer calls. If several callers have created mux channels, it will block any initial getState() call until all of the callers call getState(), executing the state transfer when all the getState calls have been invoked. (Each service gets only its own state; the above just describes how JGroups attempts to coordinate things internally.) When JBM creates a mux channel with register_for_state_transfer=true and then never calls getState(), any other service that later creates a mux channel on the same underlying channel will not be able to properly execute a state transfer when it calls getState(). I'll open a JGroups JIRA to get proper javadoc for this interface. It's obviously pretty complex. -- 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, 9 months

2
2
0 / 0

[JBoss JIRA] Closed: (JBAS-1419) test when resource hot-deployed

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1419?page=all ] Adrian Brock closed JBAS-1419. ------------------------------ Resolution: Out of Date > test when resource hot-deployed > ------------------------------- > > Key: JBAS-1419 > URL: http://jira.jboss.com/jira/browse/JBAS-1419 > Project: JBoss Application Server > Issue Type: Sub-task > Components: Transaction Manager > Reporter: Bill Burke > -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBAS-1420) last resource gambit recovery logger

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1420?page=all ] Adrian Brock closed JBAS-1420. ------------------------------ Resolution: Out of Date > last resource gambit recovery logger > ------------------------------------ > > Key: JBAS-1420 > URL: http://jira.jboss.com/jira/browse/JBAS-1420 > Project: JBoss Application Server > Issue Type: Sub-task > Components: Transaction Manager > Reporter: Bill Burke > -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBAS-1409) JCA should have recovery config

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1409?page=all ] Adrian Brock closed JBAS-1409. ------------------------------ Resolution: Out of Date > JCA should have recovery config > ------------------------------- > > Key: JBAS-1409 > URL: http://jira.jboss.com/jira/browse/JBAS-1409 > Project: JBoss Application Server > Issue Type: Sub-task > Components: JCA service > Reporter: Bill Burke > > See here: > http://www.jboss.org/wiki/Wiki.jsp?page=TransactionRecovery > JCA adapter should register a Recoverable with the RecoveryManager. There should be additional switches on witch Subject or SecurityDomain should be used for recovery. Regular XA connections may not have permission to do recovery and the app developer may not want to allow app connections to do recovery. > Additionally, different XAResources may need different recovery switches that are passed to XAResource.recover() For instance Informix needs only TMSTARTRSCAN while Oracle may need both TMENDRSCAN. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBAS-1410) check resources available

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1410?page=all ] Adrian Brock closed JBAS-1410. ------------------------------ Resolution: Out of Date > check resources available > ------------------------- > > Key: JBAS-1410 > URL: http://jira.jboss.com/jira/browse/JBAS-1410 > Project: JBoss Application Server > Issue Type: Sub-task > Components: Transaction Manager > Reporter: Bill Burke > > Write in the TX Log header all REcoverable IDs that are needed to recover that particular file. If not all resources are available log error message and don't remove file. Save it for later. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-4827) TECH REVIEW: Getting Started Guide - Chapter 3. About the Example Applications

by Michael Smith (JIRA)

TECH REVIEW: Getting Started Guide - Chapter 3. About the Example Applications ------------------------------------------------------------------------------ Key: JBAS-4827 URL: http://jira.jboss.com/jira/browse/JBAS-4827 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Affects Versions: JBossAS-4.2.2.GA Reporter: Michael Smith Attached is an Open Office 2.0 Document contain a chapter of the Getting Started Guide 1. Open document in Open Office 2. Edit -> Changes -> Record 3. Edit the document 4. Save changes and reattach to this Jira It is important for track changes to be enabled so the re-write can be easily performed. http://labs.jboss.com/jbossas/docs/Getting_Started_Guide/beta422/html/ -- 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, 9 months

2
7
0 / 0

[JBoss JIRA] Closed: (JBAS-1407) recover flags should be a JCA option

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1407?page=all ] Adrian Brock closed JBAS-1407. ------------------------------ Resolution: Out of Date > recover flags should be a JCA option > ------------------------------------ > > Key: JBAS-1407 > URL: http://jira.jboss.com/jira/browse/JBAS-1407 > Project: JBoss Application Server > Issue Type: Sub-task > Components: JCA service > Reporter: Bill Burke > > The XAResource managed by JCA should be wrapped and calls to XAResource.recover should ignore passed in flags and use a configurable set of flags to pass into the XAResource. This is important because some XAResources are finicky about what flags are passed to them in recover(). -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBAS-1408) JCA layer should register Recoverables

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1408?page=all ] Adrian Brock closed JBAS-1408. ------------------------------ Resolution: Out of Date > JCA layer should register Recoverables > -------------------------------------- > > Key: JBAS-1408 > URL: http://jira.jboss.com/jira/browse/JBAS-1408 > Project: JBoss Application Server > Issue Type: Sub-task > Components: JCA service > Reporter: Bill Burke > > JCA layer should provide a generic mechanism to register Recoverables with the RecoveryManager. See http://www.jboss.org/wiki/Wiki.jsp?page=TransactionRecovery > for more details. > The way this will work is that the wrapper class for ManagedConnectionFactory will look at the metadata for creating the recoverable Subject and the metadata for the XAResource.recover() flags so that it can create a JCARecoverable class isntance to register with the recovery manager. -- 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, 9 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 October 2007