December 2006 - jboss-dev-forums - Jboss List Archives

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: XARecovery work merged into TRUNK

by timfox

I have now merged the changes I made after the merge to TRUNk back to 1_0 as well. So now both Branch_1_0 and TRUNK should be up to date with working recovery. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995745#3995745 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995745

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: ManagementView changes

by charles.crouch＠jboss.com

"scott.stark(a)jboss.org" wrote : | Until we drill into the ManagedObject to attachment metadata property/bean propertymapping I'm not sure the current view notion is adequate. The complexity of the ManagedObject as returned from an ear vs a data source is essentially unbounded. | Agreed. This mapping seems to be the biggest point for discussion currently. Lets see if we can determine how to move forward in the JBAS5 meeting tomorrow. I want to try to stick to solving this problem for DataSources first and try to avoid getting swept out into the sea of complexity. To continue the water metaphor, I think we're just learning to paddle, so anywhere other than the shallow end (i.e. simple use cases) is not going to be helpful right now. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995741#3995741 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995741

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: ManagementView changes

by charles.crouch＠jboss.com

"scott.stark(a)jboss.org" wrote : The ManagedPropertyRef I had previously dealt with the notion of a collection of properties using the context notion: | | | /** | | * A namespace context that maps the managed property onto a managed view | | * context (e.g., /, /DataSource, /DataSource/Pool). | | */ | | Part of the property mapping definition should be a classification of the property from the perspective of an admin tool. In reality a property may be in multiple view/perspectives if we start talking about view likes "Server Ports", "Clustering", "Network Interfaces". | I'm not sure I fully understand this. Take for example two properties on a DataSource: the jndiName, and maxConnectionPoolSize. Would both of these properties get mapped to the /DataSource context? Say I had two datasources deployed A and B, and I searched specifying the "/DataSource" context, would I get four property instances back? Two jndiName's and two maxConnectionPoolSize's? How would the jndiName and maxConnectionPoolSize for DataSource A get linked? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995739#3995739 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995739

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: ManagementView changes

by charles.crouch＠jboss.com

"scott.stark(a)jboss.org" wrote : "charles.crouch(a)jboss.com" wrote : | | The management of the deployments in a profile is part of the Profile interface, not a ManagedObject notion. | | Ok, understood. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995738#3995738 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995738

17 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - XARecovery work merged into TRUNK

by timfox

We now have working XA recovery! I have merged Juha's work to trunk, and will very shortly be back merging the changes I have made back to the 1_0 branch. I have had to make some changes to get it to work, in summary, the problems where: 1) TransactionRepository::recoverPreparedTransactions We only want to handleAcks or handleReferences if the prepared tx has been loaded from the database. We don't want to do this if the transaction had been created without restarting and recover had been called for it 2) TransactionRepository::handleReferences Not releasing references 3) TransactionRepository::handleAcks Not creating deliveries with correct delivery observer . (This method was never getting executed since none of the tests were testing transactional acks. Otherwise it would have failed with a ClassCastException) Not releasing memory references 4) JDBCPersistenceManager Now we return a list of MessageChannelPair objects. The main problem with the previous code was that there was an assumption that a message is only in one channel for a tx, which is incorrect. hence a map doesn't work since the mapping gets overwritten when put happens again for the same message. Also no - need for getChannels() method - this can be injected into the transaction repository 5) Missing tests. The previous tests were only testing transacted sends, and not testing transacted acknowledgements or rollbacks Also weren't testing single message in multiple channels I have expanded the tests to include transacted acks in different situations and other cases like rollback. I think we have it pretty much covered now. 6) The following queries: SELECT_MESSAGEID_FOR_REFS SELECT_MESSAGEID_FOR_ACKS were missing from the xxx-persistence-service.xml files in src/etc/server/default/deploy 7) Also some problems with rollback: Also if there are some messages in a queue then in a global tx, they are acked then prepared then the server is restarted then the queue is loaded (it won't load those messages) then the tx is rolled back - this resets the state to C in the database, but does not put the refs back in the queue, so I've added a tx callback that cancels the messages back in under these circumstances 8) Not looking up the correct channel when the channel represents a durable subscription. There were also some intermittent failures in the test suite which were due to switching from using the old JBoss tx Mgr to JBoss TS JTA. The previous tests were relying on resources in a tx being rolled back in a particular order which was an incorrect assumption. This has been remedied. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995737#3995737 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995737

17 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - JBMESSAGING-696 - Reference counting on Lease during failove

by clebert.suconic＠jboss.com

this is a discussion of http://jira.jboss.org/jira/browse/JBMESSAGING-696 Due to a reference counting on Lease, when you create a connection inside a failover the reference counting can get out of sync, and the underlying invoker can get closed earlier than expected. I will be adding a failing testcase for this. For now the issue has the testcase, which will be committed tomorrow or after Christmas. (I'm waiting some merge activity to be done on trunk before committing my test.. I will wait a sign from Tim/Ovidiu for that). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995730#3995730 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995730

17 years, 4 months

1
0
0 / 0

[Design of EJB 3.0] - Re: java:comp.ejb3 versus java:comp

by bill.burke＠jboss.com

Ok, I finished this. EJB 2.1 and EJB 3.0 are now unified. WAR still has to implement push/pop of ENC ID, but EJB invoking on a servlet in the same thread should be impossible right now. so the way it works is EJB(2 or 3) pushes its ID (ObjectName) onto a stack stored in a ThreadLocal before it does an invocation (callback, whatever). It pops this ID from the stack when finished. java:comp ObjectFactory looks to see if there is something pushed onto the stack, if there isn't, then it uses the old classloader way. Ran EJB ENC test, seems to work ok. What I did was search for setContextClassLoader calls in the EJB codebase and added push/pop where appropriate. (destroyService also cleans up the ENC). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995724#3995724 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995724

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: ManagedObjects of ManagedObjects, etc.

by scott.stark＠jboss.org

My view of this was that one had to define the ManagedPropertys that exist on the attachments making up the parsed DeploymentUnit, and these would make up the DeploymentUnit ManagedObject. What is missing in your version of the ManagedProperty that I had in the ManagedPropertyRef was a notion of a context that allowed for classification of the ManagedPropertys into subsets. For example, just the DataSource/URL or DataSource/Pool set of properties. The requirement for a split view you mention is what is problematic, and I'm not sure its needed. That multiple deployment descriptors can affect a given attachment metadata property is something that may need to be audited, but I don't see that these need to be kept as distinct changes. If I have a deployment whose parsed DeploymentUnit metadata attachments produce an ejb property x, the deployment level setting that produced x is only relevant for debugging. As a queriable aspect of the management api its a cumbersome starting requirement. If we want to get such a thing, we would have to have a property change event notion that has sufficient info to tie into the property mapping api to allow this to be determined. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995709#3995709 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995709

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: ManagementView changes

by scott.stark＠jboss.org

"charles.crouch(a)jboss.com" wrote : | | 6) I didn't want to muddy the waters further but clearly we're going to need some concept of setView() representing new deployments, and also removeView() to undeploy/delete existing deployments. I figure we can get to those later, once we've got further on the Read/List api. | The management of the deployments in a profile is part of the Profile interface, not a ManagedObject notion. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995706#3995706 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995706

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: ManagementView changes

by scott.stark＠jboss.org

"charles.crouch(a)jboss.com" wrote : | | 4) We need the concept of a deployment type in order to support retrieving all ManagedObject's/deploymentName's of a particular type e.g. DataSource | | either | public List<ManagedObject> getViews(ProfileKey key, DeploymentType deploy) | | throws NoSuchProfileException, IOException | | | or | | | public List<String> getDeploymentNames(ProfileKey key, DeploymentType deploy) | | throws NoSuchProfileException, IOException | I think we need to flesh out the ManagedObject to deployment metadata mapping issue to define this. The ManagedPropertyRef I had previously dealt with the notion of a collection of properties using the context notion: | public class ManagedPropertyRef | { | /** | * A namespace context that maps the managed property onto a managed view | * context (e.g., /, /DataSource, /DataSource/Pool). | */ | private String context; | Part of the property mapping definition should be a classification of the property from the perspective of an admin tool. In reality a property may be in multiple view/perspectives if we start talking about view likes "Server Ports", "Clustering", "Network Interfaces". View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995705#3995705 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995705

17 years, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums December 2006