[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
18 years
[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
18 years
[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
18 years
[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
18 years
[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
18 years