[Design of JCA on JBoss] - Re: JcaXAResourceRecovery
by weston.price＠jboss.com
Yes. I am aware of how it works.
For JCA resources this is not straightforward being that the underlying connection (and thus access to the XAResource) cannot always be easily recreated.
In the recovery work for JBM, you simply pass the name of the JMSProviderAdapter to your RecoveryModule implementation which allows you to access the XAConnection->XASession->XAResource.
In many cases in JCA deployments this isn't that straightforward for a variety of reasons:
1) The underlying resource requires an authenticated Subject to be created
2) The underlying resource requires programmatic user information (ConnectionRequestInfo) that is not supplied in the deployment.
3) Unlike JMS, most JCA deployments do not provide XA based connection factories for client use. In other words you cannot simply get a reference to the connection factory in JNDI and get the XAResource.
JMS is one thing, JCA is a different animal altogether.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4009356#4009356
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4009356
17 years, 2 months
[Design of JCA on JBoss] - Re: JcaXAResourceRecovery
by timfox
Also, one thing I noticed when doing the XA recovery work for JBM is that the JMSProviderXAResourceRecovery instance that was done for JBossMQ is broken.
The way JBoss TS recovery manager works is as follows:
It calls:
myXAResourceRecovery.hasMoreResources()
returns true
myXAResourceRecovery.getXAResource()
returns resource
myXAResourceRecovery.hasMoreResources()
returns false
it then calls recover() as appropriate on the XAResoource
and then commit/rollback as appropriate
and then, and it *throws the XAResource away*
then on the next time around (120 seconds later or whatever)
it goes through the whole procedure again.
The way the JBossMQ XAResourceRecovery was written is that it never returns true to hasMoreResources after the first time.
So any in doubt transactions after that time will never be picked up.
Also the concept of an XAResourceWrapper which will transparent reconnect doesn't make much sense to me, if you bear in mind the above. Since JBoss TS will throw away the Wrapper anyway after the pass.
You may as well create a new one on each pass. (This is what we do) It certainly makes the code a lot simpler.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4009331#4009331
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4009331
17 years, 2 months
[Design of JCA on JBoss] - Re: JcaXAResourceRecovery
by timfox
"weston.price(a)jboss.com" wrote : I may have initially underestimated this task. The JcaXAResourceWrapper, by itself, is not sufficient for recovery integration. I have started on
|
|
| | org.jboss.resource.connectionmanager.xa.JcaXAResourceRecovery
| |
|
| for this purpose. It's easy enough to configure something like this for DataSources such as
|
|
| | <property name="com.arjuna.ats.jta.recovery.XAResourceRecoveryJCA=org.jboss.resource.connectionmanager.xa.JcaXAResourceRecovery;DSNAME1, DSNAM2"/>
| |
|
| the issue I am not following is for DataSource and other JCA deployments that rely on a CRI, Subject etc. I would assume that for recovery purposes, a default connection of some sort will have to be provided by the client to allow JBossTS to do it's job. This would seem to suggest that we are now at the very least going to force a separate deployment for recovery if the default deployment cannot be accessed in this manner. The JMS example assumes the creation of a connection without JMS credentials so I am assuming I am in the same boat.
|
| I can't see any other way to do this unless we made them provide a separate configuration file for their resources that we could access that would allow me to recreate the underlying resource.
|
|
When I wrote the ResourceRecovery instance for the JMS bridge, it gets its config from a properties file, which also (optionally) contains the username and password to create the XAConnection to get the XASession and XAResource.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4009329#4009329
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4009329
17 years, 2 months
[Design of JCA on JBoss] - JcaXAResourceRecovery
by weston.price＠jboss.com
I may have initially underestimated this task. The JcaXAResourceWrapper, by itself, is not sufficient for recovery integration. I have started on
| org.jboss.resource.connectionmanager.xa.JcaXAResourceRecovery
|
for this purpose. It's easy enough to configure something like this for DataSources such as
| <property name="com.arjuna.ats.jta.recovery.XAResourceRecoveryJCA=org.jboss.resource.connectionmanager.xa.JcaXAResourceRecovery;DSNAME1, DSNAM2"/>
|
the issue I am not following is for DataSource and other JCA deployments that rely on a CRI, Subject etc. I would assume that for recovery purposes, a default connection of some sort will have to be provided by the client to allow JBossTS to do it's job. This would seem to suggest that we are now at the very least going to force a separate deployment for recovery if the default deployment cannot be accessed in this manner. The JMS example assumes the creation of a connection without JMS credentials so I am assuming I am in the same boat.
I can't see any other way to do this unless we made them provide a separate configuration file for their resources that we could access that would allow me to recreate the underlying resource.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4009298#4009298
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4009298
17 years, 2 months
[Design of JBoss internal QA (Test Suite)] - How to print or log the values in org.jboss.test.iiop.test.P
by mp123
Hello,
I have encountered the error while running the Testsuite with HP-UX OS, jdk1.5, JBoss AS 4.0.5.GA in the testcase
org.jboss.test.iiop.test.ParameterPassingStressTestCase
in the test test_getException
Error:
anonymous wrote :
| Invalid indirection to offset 1704
|
| java.io.IOException: Invalid indirection to offset 1704
| at com.sun.corba.se.impl.io.IIOPInputStream$ActiveRecursionManager.getObject(IIOPInputStream.java:2684)
| at com.sun.corba.se.impl.io.IIOPInputStream.inputClassFields(IIOPInputStream.java:2218)
| at com.sun.corba.se.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1221)
| at com.sun.corba.se.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:400)
| at com.sun.corba.se.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:327)
| at com.sun.corba.se.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:293)
| at org.jacorb.util.ValueHandler.readValue(ValueHandler.java:25)
| ...
|
I have given some System.out statements in the file
anonymous wrote : <JBOSS-SRC>/testsuite/src/main/org/jboss/test/iiop/test/ParameterPassingStressTestCase.java file and run the testcase.
#cd <JBOSS-SRC>/testsuite
| #ant tests-iiop
it doesn't log any details regarding my System.out.println statements on both server.log and also in the test.log files.
How can I make the program to log the values of the variables in the program ParameterPassingStressTestCase.java?
Please help me.
Thanks in Advance,
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4009297#4009297
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4009297
17 years, 2 months