I just poked, and I see there is a TxStats.getInstance() method. Is that a valid API for accessing this? On 5/12/11 10:25 AM, Michael Musgrove wrote: > Can you give me an example of what other projects are providing you with > or indicate what you prefer. Then I can look into adding it. > > BTW AS7 will be consuming JBOSSTS_4_14_0_Final so what is the process > for making changes. > >> Can these TxStats be accessed via something other than JMX? If at all >> possible I want the AS management layer (in the AS transactions module) >> to not rely on JMX to pull data from subsystems. >> >> On 5/11/11 9:42 AM, Michael Musgrove wrote: >>> Can you clarify what it is that you need to know. I don't understand where these attributes are coming from nor what their values mean. >>> >>> We do have various beans that we have, in the past, exposed via JMX or via RHQ. For example, consider the first attribute "core-environment" => .... I guess this is referring to our CoreEnvironment bean which does have a property called socketProcessIdPort which we use to facilitate creation of unique ids and it also has a property called nodeIdentifier which we use to ensure that different recovery managers don't end up recovering each others transactions. But there are also other properties in that bean which your snippet does not mention. >>> >>> The enable-statistics property simply enables metrics gathering for transaction counts (heuristics, commits etc). Once enabled the statistics can be retrieved from our TxStats MBean. >>> >>> Mike >>> >>> >>> ----- Original Message ----- >>> >>>>> From: "Heiko Braun"<hbraun(a)redhat.com> >>>>> To:"jboss-as7-dev@lists.jboss.org Development"<jboss-as7-dev(a)lists.jboss.org> >>>>> Sent: Tuesday, May 10, 2011 9:07:24 AM >>>>> Subject: [jboss-as7-dev] TX subsystem management use cases >>>>> >>>>> >>>>> >>>>> Can anyone shed some light on the management op's for the transaction >>>>> subsystem? >>>>> The attribute names indicate more sophisticated features, like >>>>> statistics. >>>>> >>>>> I would need to know how to work with this data in order expose >>>>> reasonable functionality through the web UI. >>>>> >>>>> [domain@localhost:9999 /] >>>>> /profile=default/subsystem=transactions:read-resource(recursive=true) >>>>> { >>>>> "outcome" => "success", >>>>> "result" => { >>>>> "core-environment" => { >>>>> "socket-binding" => "txn-socket-process-id", >>>>> "node-identifier" => undefined >>>>> }, >>>>> "recovery-environment" => { >>>>> "socket-binding" => "txn-recovery-environment", >>>>> "status-socket-binding" => "txn-status-manager" >>>>> }, >>>>> "coordinator-environment" => { >>>>> "enable-statistics" => undefined, >>>>> "default-timeout" => undefined >>>>> }, >>>>> "object-store" => { >>>>> "relative-to" => undefined, >>>>> "path" => undefined >>>>> } >>>>> }, >>>>> "compensating-operation" => undefined >>>>> } >>>>> >>> _______________________________________________ >>> jboss-as7-dev mailing list >>> jboss-as7-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

Can you add the requirements and related issue here, please: https://issues.jboss.org/browse/AS7-769 I guess all we currently speaks about goes beyond AS 7.0.Final?

Ike On May 12, 2011, at 6:36 PM, Michael Musgrove wrote: > Yes that will be OK in the medium term. > > In the longer term (possibly in release 5.x which is at least a year > away) we will need to support multiple transaction managers in the same > VM and will need to deprecate most of our static methods. > > We also have an MBean for exposing the transaction logs - it would be > highly desirable to expose these via the management console > (com.arjuna.ats.arjuna.tools.osb.mbean.ObjStoreBrowser). However, the > implementation requires the presence of an MBeanServer. > >> I just poked, and I see there is a TxStats.getInstance() method. Is that >> a valid API for accessing this? >> >> On 5/12/11 10:25 AM, Michael Musgrove wrote: >>> Can you give me an example of what other projects are providing you with >>> or indicate what you prefer. Then I can look into adding it. >>> >>> BTW AS7 will be consuming JBOSSTS_4_14_0_Final so what is the process >>> for making changes. >>> >>>> Can these TxStats be accessed via something other than JMX? If at all >>>> possible I want the AS management layer (in the AS transactions module) >>>> to not rely on JMX to pull data from subsystems. >>>> >>>> On 5/11/11 9:42 AM, Michael Musgrove wrote: >>>>> Can you clarify what it is that you need to know. I don't understand where these attributes are coming from nor what their values mean. >>>>> >>>>> We do have various beans that we have, in the past, exposed via JMX or via RHQ. For example, consider the first attribute "core-environment" => .... I guess this is referring to our CoreEnvironment bean which does have a property called socketProcessIdPort which we use to facilitate creation of unique ids and it also has a property called nodeIdentifier which we use to ensure that different recovery managers don't end up recovering each others transactions. But there are also other properties in that bean which your snippet does not mention. >>>>> >>>>> The enable-statistics property simply enables metrics gathering for transaction counts (heuristics, commits etc). Once enabled the statistics can be retrieved from our TxStats MBean. >>>>> >>>>> Mike >>>>> >>>>> >>>>> ----- Original Message ----- >>>>> >>>>>>> From: "Heiko Braun"<hbraun(a)redhat.com> >>>>>>> To:"jboss-as7-dev@lists.jboss.org Development"<jboss-as7-dev(a)lists.jboss.org> >>>>>>> Sent: Tuesday, May 10, 2011 9:07:24 AM >>>>>>> Subject: [jboss-as7-dev] TX subsystem management use cases >>>>>>> >>>>>>> >>>>>>> >>>>>>> Can anyone shed some light on the management op's for the transaction >>>>>>> subsystem? >>>>>>> The attribute names indicate more sophisticated features, like >>>>>>> statistics. >>>>>>> >>>>>>> I would need to know how to work with this data in order expose >>>>>>> reasonable functionality through the web UI. >>>>>>> >>>>>>> [domain@localhost:9999 /] >>>>>>> /profile=default/subsystem=transactions:read-resource(recursive=true) >>>>>>> { >>>>>>> "outcome" => "success", >>>>>>> "result" => { >>>>>>> "core-environment" => { >>>>>>> "socket-binding" => "txn-socket-process-id", >>>>>>> "node-identifier" => undefined >>>>>>> }, >>>>>>> "recovery-environment" => { >>>>>>> "socket-binding" => "txn-recovery-environment", >>>>>>> "status-socket-binding" => "txn-status-manager" >>>>>>> }, >>>>>>> "coordinator-environment" => { >>>>>>> "enable-statistics" => undefined, >>>>>>> "default-timeout" => undefined >>>>>>> }, >>>>>>> "object-store" => { >>>>>>> "relative-to" => undefined, >>>>>>> "path" => undefined >>>>>>> } >>>>>>> }, >>>>>>> "compensating-operation" => undefined >>>>>>> } >>>>>>> >>>>> _______________________________________________ >>>>> jboss-as7-dev mailing list >>>>> jboss-as7-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>> _______________________________________________ >>> jboss-as7-dev mailing list >>> jboss-as7-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

Couple questions to see if we can future-proof the management configuration of the AS's transactions subsystem: 1) How will these multiple transactions managers be uniquely identified? A simple string name?

2) How will the various configuration components you have now map to these multiple transaction managers? You've got a CoreEnvironmentBean, CoordinatorEnvironmentBean, ObjectStoreEnvironmentBean, RecoveryEnvironmentBean.

those, or will some be common across transaction managers?

On 05/31/2011 01:28 PM, Brian Stansberry wrote: > Couple questions to see if we can future-proof the management > configuration of the AS's transactions subsystem: > > 1) How will these multiple transactions managers be uniquely identified? > A simple string name? Possibly, but no promises at this stage. > 2) How will the various configuration components you have now map to > these multiple transaction managers? You've got a CoreEnvironmentBean, > CoordinatorEnvironmentBean, ObjectStoreEnvironmentBean, > RecoveryEnvironmentBean. Actually there are 12 more such types in the codebase, but what you don't know won't hurt you. for now. probably. Of the 180+ config options in JBossTS, only a handful are actually exposed to AS users. The AS internally overrides a handful more from the defaults that JBossTS ships. The rest use default values. Will each transaction manager have a set of > those, or will some be common across transaction managers? There are already multiple instances of some bean types used internally, particularly for store config. As for future versions, what makes you think any of those will still exist? :-) You can't take anything as fixed, we're making a new major version here and will cheerfully slaughter any sacred cows that get in our way. Perhaps in the future all the internal components of the transaction system will be native MSC modules and services. My gut feeling is the system will be flexible enough to allow multiple high level component instances to be layered onto either shared or individual lower level component instances, but I may change my mind tomorrow. Or even right after coffee. In short, future-proofing attempts would be a waste of time.

On the other hand, making the new HornetQ journal based objectstore implementation a user configurable option would have a huge performance benefit for some scenarios. Likewise making the JTA/JTS choice selectable - just having an ORB present does not necessarily mean a user needs distributed tx and the associated performance penalty for all tx.