Re: [JBoss-dev] JBossXidFactory and MS SQL Server
If l understand the transaction logger, it is persisting the last globalIdNumber between JBoss sessions. If thats the case l would agree it will do the job. You have a NoLogTxLogger in the package. If someone were to use this TxLogger we could see the MS SQL Server problem. Your code in JBossXidFactory.startService() sets the globalIdNumber to zero if there is no TxLogger. If there is no TxLogger we could also see the MS SQL Server problem. Are the NoLogTxLogger or null TxLogger senarios likely to happen? - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 06, 2003 4:55 AM Subject: Re: [JBoss-dev] JBossXidFactory and MS SQL Server I probably wont be able to look at this in detail for at least several days. Could you please 1. look at the transaction logging in jboss 4 to see if that looks like a better long-term solution: if I understand the problem you are having the logging should also solve it. I __might__ backport this to 3.2 but almost certainly not to 3.0.x 2. indicate which version(s) of jboss your patch is for. 3. file either a bug report or a patch on sourceforge and assign it to me if possible. Otherwise I am very apt to lose track of this. Thanks david jencks On 2003.01.05 14:28:58 -0500 Jamie Burns wrote: David J, back in October we were dialoging about XidFactory and a transaction id problem that could occur if MS SQL Server is not restarted when JBoss is stopped and started. The problem was traced to the XidFactory using the same baseGlobalId and resetting its globalIdNumber to zero each time it is started. Ive made some changes to JBossXidFactory based on our discussion. At the time you asked about looking into a guid that is used in other parts of JBoss as a solution to creating a unique baseGlobalId each time JBoss is started. The org.jboss.util.id package has a GUID class that creates unique ids based on the host address, time stamps and counters. The guid it creates is around 40 characters long and will be unique even for multiple instances of JBoss on the same physical machine. I wasnt sure if you still wanted to keep the hostname in baseGlobalId. Ive kept it in but, its likely it will be truncated alot of the time because of the size of the GUID. The JBossXidFactory sticks to reserving 14 characters for the globalIdNumber. The setter method for baseGlobalId doesnt enforce this. Ive added code to truncate the value passed to the setter if it is too long. Im not sure if this is the best approach though. Truncating the value may remove enough significant characters from the string that it is no longer unique. Maybe it would be better to throw some exception if the baseGlobalId was set to a string that doesnt leave 14 characters for the globalIdNumber. What is your view on this? In the old XidFactory you had a setter method for the globalIdNumber. You dont have this in JBossXidFactory so the next comment isnt very relevant, but l'll make it to be thorough. The globalIdNumber is a long which can be up to 22 digits. My thought with the old XidFactory was that someone could supply a globalIdNumber that was greater than 14 digits. If you put a setter method for globalIdNumber back into JBossXidFactory or if you get more than 10^14 transactions taking place in the lifetime of a JBoss instance (pretty unlikely l guess) you will have the potential for non-unique transaction ids. One last thing - again to be thorough. The GUID uses the system time a few times to create its unique string. The system time on MS Windows is only accurate to the nearest 10-15 milliseconds. Someone would be pretty unlucky to get two GUIDs that are the same, but it is possible on a Windows machine if they are created within 10-15 ms of each other. If it does happen to someone maybe they will find this posting. I cant see a way to get a 100% guarantee of uniqueness. Ive attached JBossXidFactory with the changes lve made. Let me know if you need anything done. Jamie !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 Transitional//EN HTMLHEAD META http-equiv=Content-Type content=text/html; charset=iso-8859-1 META content=MSHTML 6.00.2600.0 name=GENERATOR STYLE/STYLE /HEAD BODY bgColor=#ff DIVFONT face=Arial size=2David J,/FONT/DIV DIVFONT face=Arial size=2/FONTnbsp;/DIV DIVFONT face=Arial size=2back in October we were dialoging about XidFactory and a transaction id problem that could occur if MS SQL Server is not restarted when JBoss is stopped and started. The problem was traced to the XidFactory using the same baseGlobalId and resetting its globalIdNumber to zero each time it is started./FONT/DIV DIVFONT face=Arial size=2/FONTnbsp;/DIV DIVFONT face=Arial size=2Ive made some changes to JBossXidFactory based on our discussion./FONT/DIV DIVFONT face=Arial size=2/FONTnbsp;/DIV DIVFONT face
[JBoss-dev] JBossXidFactory and MS SQL Server
David J, back in October we were dialoging about XidFactory and a transaction id problem that could occur if MS SQL Server is not restarted when JBoss is stopped and started. The problem was traced to the XidFactory using the same baseGlobalId and resetting its globalIdNumber to zero each time it is started. Ive made some changes to JBossXidFactory based on our discussion. At the time you asked about looking into a guid that is used in other parts of JBoss as a solution to creating a unique baseGlobalId each time JBoss is started. The org.jboss.util.id package has a GUID class that creates unique ids based on the host address, time stamps and counters. The guid it creates is around 40 characters long and will be unique even for multiple instances of JBoss on the same physical machine. I wasnt sure if you still wanted to keep the hostname in baseGlobalId. Ive kept it in but, its likely it will be truncated alot of the time because of the size of the GUID. The JBossXidFactory sticks to reserving 14 characters for the globalIdNumber. The setter method for baseGlobalId doesnt enforce this. Ive added code to truncate the value passed to the setter if it is too long. Im not sure if this is the best approach though. Truncating the value may remove enough significant characters from the string that it is no longer unique. Maybe it would be better to throw some exception if the baseGlobalId was set to a string that doesnt leave 14 characters for the globalIdNumber. What is your view on this? In the old XidFactory you had a setter method for the globalIdNumber. You dont have this in JBossXidFactory so the nextcomment isnt very relevant, but l'll make it to be thorough. The globalIdNumber is a long which can be up to 22 digits. My thought with the old XidFactory was that someone could supply a globalIdNumber that was greater than 14 digits. If you put a setter method for globalIdNumber back into JBossXidFactory or if you get more than 10^14 transactions taking place in the lifetime of a JBoss instance (pretty unlikely l guess) you will have the potential for non-unique transaction ids. One last thing - again to be thorough. The GUID uses the system time a few times to create its unique string. The system time on MS Windows is only accurate to the nearest 10-15 milliseconds. Someone would be pretty unlucky to get two GUIDs that are the same, but it is possible on a Windows machine if they are created within 10-15 ms of each other. If it does happen to someone maybe they will find this posting. I cant see a way to get a 100% guarantee of uniqueness. Ive attached JBossXidFactory with the changes lve made. Let me know if you need anythingdone. Jamie JBossXidFactory.java Description: Binary data
Re: [JBoss-dev] XADataSource wrapper for JBoss 4
Hi David. You were right about the XidFactory being the problem. It looks like the MS SQLServer JDBC drivers keep a history of Xid's that have been used with its XAResources. If MS SQL Server is not restarted when JBoss is stopped and started, the XidFactory creates the same Xid's as its previous session, which the SQLServer JDBC drivers reject. When l turned on trace the log showed the exception being thrown in endResource(): 2002-10-10 12:35:39,973 TRACE [org.jboss.tm.TransactionImpl] Created new instance for tx=TransactionImpl:XidImpl [FormatId=257, GlobalId=burns01//17, BranchQual=] 2002-10-10 12:35:39,973 TRACE [org.jboss.tm.TxManager] began tx: TransactionImpl:XidImpl [FormatId=257, GlobalId=burns01//17, BranchQual=] 2002-10-10 12:35:39,983 TRACE [org.jboss.tm.TxManager] suspended tx: TransactionImpl:XidImpl [FormatId=257, GlobalId=burns01//17, BranchQual=] 2002-10-10 12:35:39,983 TRACE [org.jboss.tm.TransactionImpl] enlistResource(): Entered, tx=TransactionImpl:XidImpl [FormatId=257, GlobalId=burns01//17, BranchQual=] status=STATUS_ACTIVE 2002-10-10 12:35:39,983 TRACE [org.jboss.tm.TransactionImpl] startResource(XidImpl [FormatId=257, GlobalId=burns01//17, BranchQual=1]) entered: org.jboss.resource.adapter.jdbc.xa.XAManagedConnection@4af9f7 flags=0 2002-10-10 12:35:39,983 TRACE [org.jboss.tm.TransactionImpl] startResource(XidImpl [FormatId=257, GlobalId=burns01//17, BranchQual=1]) leaving: org.jboss.resource.adapter.jdbc.xa.XAManagedConnection@4af9f7 flags=0 2002-10-10 12:35:39,993 TRACE [org.jboss.tm.TransactionImpl] delistResource(): Entered, tx=TransactionImpl:XidImpl [FormatId=257, GlobalId=burns01//17, BranchQual=] status=STATUS_ACTIVE 2002-10-10 12:35:39,993 TRACE [org.jboss.tm.TransactionImpl] endResource(XidImpl [FormatId=257, GlobalId=burns01//17, BranchQual=1]) entered: org.jboss.resource.adapter.jdbc.xa.XAManagedConnection@4af9f7 flag=67108864 2002-10-10 12:35:40,013 TRACE [org.jboss.tm.TransactionImpl] endResource(XidImpl [FormatId=257, GlobalId=burns01//17, BranchQual=1]) leaving: org.jboss.resource.adapter.jdbc.xa.XAManagedConnection@4af9f7 flag=67108864 2002-10-10 12:35:40,013 WARN [org.jboss.tm.TransactionImpl] XAException: tx=TransactionImpl:XidImpl [FormatId=257, GlobalId=burns01//17, BranchQual=] errorCode=XAER_RMERR javax.transaction.xa.XAException: [Microsoft][SQLServer 2000 Driver for JDBC][SQLServer]xa_end (400) returns -6 at com.microsoft.jdbcx.sqlserver.SQLServerImplXAResource.executeXaRpc(Unknown Source) at com.microsoft.jdbcx.sqlserver.SQLServerImplXAResource.end(Unknown Source) at com.microsoft.jdbcx.base.BaseXAResource.end(Unknown Source) at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.end(XAManagedConnecti on.java:118) at org.jboss.tm.TransactionImpl.endResource(TransactionImpl.java:1353) at org.jboss.tm.TransactionImpl.delistResource(TransactionImpl.java:727) at org.jboss.test.jca.tm.XAResourceTest.testSimpleCommitTx(XAResourceTest.java: 238) I wrote a small program to test the theory and it showed the same behaviour - failed with the same error when l used an Xid more than once. Ive made some changes to XidFactory that have addressed the problem. I added 2 things to the baseGlobalId to make it more unique. Ive added a timestamp and an instance counter. The timestamp is the System.currentTimeMillis() when the XidFactory is created. The XidFactory didnt seem to be a singleton so l added the instance counter to cover 2 instances being created close enough together that they have the same timestamp. This creates a baseGlobalId like myhost//1/1034281915599/ The globalIdNumber is added after the final slash. Ive attached the changed XidFactory. Have a look at it and let me know what you think. Another issue with the XidFactory that l think needs addressing is setBaseGlobalId() and setGlobalIdNumber(). In the constructor you made a point of allowing 14 digits for a serial number - which l assume is the current value of globalIdNumber. These 2 setters dont have any code to enforce that we still have a 14 digit serial number or a global transaction id that is no more than Xid.MAXGTRIDSIZE long. Is this something that these setters should be enforcing? If so, let me know and l will add some guard clauses to these setters. Thanks Jamie - Original Message - From: Jamie Burns [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 02, 2002 11:35 PM Subject: Re: [JBoss-dev] XADataSource wrapper for JBoss 4 Had a look at testing your theory. I think l can do it. I'll get back to you when l have a result. - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, October 01, 2002 11:15 PM Subject: Re: [JBoss-dev] XADataSource wrapper for JBoss 4 I suspect this might be a limitation of the current jboss XidFactory... namely it starts over with global ids every time you restart jboss. If you leave SQLServer running, it may object if it gets the same xid later
Re: [JBoss-dev] XADataSource wrapper for JBoss 4
Had a look at testing your theory. I think l can do it. I'll get back to you when l have a result. - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, October 01, 2002 11:15 PM Subject: Re: [JBoss-dev] XADataSource wrapper for JBoss 4 I suspect this might be a limitation of the current jboss XidFactory... namely it starts over with global ids every time you restart jboss. If you leave SQLServer running, it may object if it gets the same xid later on that it committed earlier. Is there an easy way to see if this is the problem? thanks david jencks On 2002.10.01 17:04:10 -0400 Jamie Burns wrote: FW: [JBoss-dev] XADataSource wrapper for JBoss 4Hi Igor. I applied the patch and initially found the XAResourceTest tests ran successfully a number of times. Ive found that after running the XAResourceTest, if l leave SQL Server running, stop and start JBoss and then run the test again, the testSimpleCommitTx test fails (see the log extract below). Ive started having a look at it - if you dont think its worth the effort let me know. Given the senario the exception occurs under and the presence of static objects, is it possible that either the MS JDBC drivers or the VM could be hanging onto something that is messing up the works? Jamie line 238 : tx.delistResource(xares, XAResource.TMSUCCESS); line 239:tx.commit(); Log Extract: 2002-09-30 20:20:36,987 WARN [org.jboss.tm.TransactionImpl] XAException: tx=TransactionImpl:XidImpl [FormatId=257, GlobalId=burns01//17, BranchQual=] errorCode=XAER_RMERR javax.transaction.xa.XAException: [Microsoft][SQLServer 2000 Driver for JDBC][SQLServer]xa_end (400) returns -6 at com.microsoft.jdbcx.sqlserver.SQLServerImplXAResource.executeXaRpc(Unknown Source) at com.microsoft.jdbcx.sqlserver.SQLServerImplXAResource.end(Unknown Source) at com.microsoft.jdbcx.base.BaseXAResource.end(Unknown Source) at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.end(XAManagedConnecti on.java:118) at org.jboss.tm.TransactionImpl.endResource(TransactionImpl.java:1353) at org.jboss.tm.TransactionImpl.delistResource(TransactionImpl.java:727) at org.jboss.test.jca.tm.XAResourceTest.testSimpleCommitTx(XAResourceTest.java: 238) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat cher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:548) at org.jboss.jmx.adaptor.rmi.RMIAdaptorImpl.invoke(RMIAdaptorImpl.java:265) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:7 01) at java.lang.Thread.run(Thread.java:536) 2002-09-30 20:20:36,997 WARN [org.jboss.tm.TransactionImpl] XAException: tx=TransactionImpl:XidImpl [FormatId=257, GlobalId=burns01//17, BranchQual=] errorCode=XAER_RMERR javax.transaction.xa.XAException: [Microsoft][SQLServer 2000 Driver for JDBC][SQLServer]xa_end (400) returns -6 at com.microsoft.jdbcx.sqlserver.SQLServerImplXAResource.executeXaRpc(Unknown Source) at com.microsoft.jdbcx.sqlserver.SQLServerImplXAResource.end(Unknown Source) at com.microsoft.jdbcx.base.BaseXAResource.end(Unknown Source) at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.end(XAManagedConnecti on.java:118) at org.jboss.tm.TransactionImpl.endResource(TransactionImpl.java:1353) at org.jboss.tm.TransactionImpl.endResources(TransactionImpl.java:1428) at org.jboss.tm.TransactionImpl.checkStatusForPrepare(TransactionImpl.java:1917 ) at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:308) at org.jboss.test.jca.tm.XAResourceTest.testSimpleCommitTx(XAResourceTest.java: 239) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:324
Re: [JBoss-dev] XADataSource wrapper for JBoss 4
)at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)at
java.lang.Thread.run(Thread.java:536)2002-09-30 20:25:37,539 WARN
[org.jboss.tm.TransactionImpl] Transaction TransactionImpl:XidImpl
[FormatId=257, GlobalId=burns01//22, BranchQual=] timed out.
status=STATUS_MARKED_ROLLBACK2002-09-30 20:25:37,549 WARN
[org.jboss.tm.TransactionImpl] Transaction TransactionImpl:XidImpl
[FormatId=257, GlobalId=burns01//23, BranchQual=] timed out.
status=STATUS_ACTIVE
-Original Message- From: Igor
Fedorenko [mailto:[EMAIL PROTECTED]]
Sent: Sunday, September 22, 2002 3:52 AM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] XADataSource wrapper for JBoss
4
Jamie,
Could you try following patch for XAResourceTest.java. It is
supposed to fix empty branch id problem.
Jamie Burns wrote: By way of
reminder, the exception is: javax.transaction.xa.XAException at com.microsoft.jdbcx.base.BaseXAResource.checkXid(Unknown
Source) at
com.microsoft.jdbcx.base.BaseXAResource.start(Unknown Source) at
org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.start(XAManagedConnec
tion.java:107)
at
org.jboss.test.jca.tm.XAResourceTest.testSimpleCommitXid(XAResourceTest.java
:173) The checkXid method is failing with the value it is getting from
XidImpl.getBranchQualifier(). XidImpl is
returning a byte[0]. Ive started comparing it to
the JBoss 3.0 code and it looks pretty the same.
Im guessing that somewhere JBoss 3.0 was setting it to a non-zero length array. I am going to look into it more closely
over the weekend.
- Original Message - From: "Igor Fedorenko" [EMAIL PROTECTED]
To:
[EMAIL PROTECTED]
Sent: Saturday, September 07, 2002 2:18 PM
Subject: Re: [JBoss-dev] XADataSource wrapper for JBoss 4
There are two types of tests in this test
suite. First type ("raw" tests) manages xids
and makes xa calls directly, second type ("tx" tests) create instance of Transaction and use this instance to
manage xa stuff. "Tx" tests are more important
because they exercise actual behaviour of
jboss, while "raw" tests were meant to prove that very basic xa functionality works. In your case all "raw" tests
failed and all "tx" tests succeeded. It is
definitely a bug with raw tests but I do not
know what could be wrong with them.
Jamie Burns wrote: Ok. The
XAResourceUnitTestCase threw 3 errors. See attached report. There are sections for
3 adapters in the class. I have hsqldb-ds.xml (Firebird?) and mssql-xa-ds.xml installed. Apart from
removing one of
them, how do
you tell which one has failed?
Thanks Jamie-- Igor Fedorenko Think smart.
Think automated. Think Dynamics. www.thinkdynamics.com---
This sf.net email is sponsored by: OSDN - Tired of
that same old cell phone? Get a new here
for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390
___
Jboss-development mailing list
[EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
--- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf
___
Jboss-development mailing list [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
-- Igor Fedorenko Think smart. Think automated. Think Dynamics.
www.thinkdynamics.com
This electronic mail system is used for information purposes and is
not intended to form any legal contract or binding agreement.
The content is confidential and may be legally privileged. Access
by anyone other than the addressee(s) is unauthorised and any
disclosure, copying, distribution or any other action taken in
reliance on it is prohibited and maybe unlawful
All incoming and outgoing e-mail communications and attachments
are scanned automatically by software designed to detect and remove
any material containing viruses or other unauthorised content. While
we undertake best endeavours to ensure that this content checking
software is up to date, recipients should take steps to assure themselves
that e-mails received are secure.
Re: [JBoss-dev] XADataSource wrapper for JBoss 4
By way of reminder, the exception is: javax.transaction.xa.XAException at com.microsoft.jdbcx.base.BaseXAResource.checkXid(Unknown Source) at com.microsoft.jdbcx.base.BaseXAResource.start(Unknown Source) at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.start(XAManagedConnec tion.java:107) at org.jboss.test.jca.tm.XAResourceTest.testSimpleCommitXid(XAResourceTest.java :173) The checkXid method is failing with the value it is getting from XidImpl.getBranchQualifier(). XidImpl is returning a byte[0]. Ive started comparing it to the JBoss 3.0 code and it looks pretty the same. Im guessing that somewhere JBoss 3.0 was setting it to a non-zero length array. I am going to look into it more closely over the weekend. - Original Message - From: Igor Fedorenko [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, September 07, 2002 2:18 PM Subject: Re: [JBoss-dev] XADataSource wrapper for JBoss 4 There are two types of tests in this test suite. First type (raw tests) manages xids and makes xa calls directly, second type (tx tests) create instance of Transaction and use this instance to manage xa stuff. Tx tests are more important because they exercise actual behaviour of jboss, while raw tests were meant to prove that very basic xa functionality works. In your case all raw tests failed and all tx tests succeeded. It is definitely a bug with raw tests but I do not know what could be wrong with them. Jamie Burns wrote: Ok. The XAResourceUnitTestCase threw 3 errors. See attached report. There are sections for 3 adapters in the class. I have hsqldb-ds.xml (Firebird?) and mssql-xa-ds.xml installed. Apart from removing one of them, how do you tell which one has failed? Thanks Jamie -- Igor Fedorenko Think smart. Think automated. Think Dynamics. www.thinkdynamics.com --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] XADataSource wrapper for JBoss 4
Ive got the latest code and the timeout problem has gone away. I get a different error but l will look at that once l have a go at running your unit test. Ive added a section to org.jboss.test.jca.test.XAResourceUnitTest for MS SQL Server 2000 and Im running build tests. lm wondering when the tests will end. Is there a way to run just the XAResourceUnitTestCase? Thanks Jamie - Original Message - From: Igor Fedorenko [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, September 03, 2002 5:35 AM Subject: Re: [JBoss-dev] XADataSource wrapper for JBoss 4 There was a problem in the new wrapper -- it was mixing native and wrapped xaresources. Due to this problem isSameRM always returned false which could result in your timeouts. Could you get latest code and see if it solves you problem? Also it would be great if you tried our new XA resource compatibility test (see testsuite/src/main/org.jboss.test.jca.test.XAResourceUnitTestCase). Jamie Burns wrote: I checked out Igor's fix as you suggested and got past the compile problem. I've spent the last couple of days working out why my EAR that worked on JBoss 3 didnt work on JBoss 4. In JBoss 3.0, l removed the hsqldb-service.xml because l was using SQL Server and l wanted to use DefaultDS as my JNDI name. JBoss 4 wasnt happy with this. Ive had to keep hsqldb-ds.xml and change the JNDI name for my SQL Server DS to MSSQLDS. What is hsqldb-ds.xml being used for and if its DS is needed to make JBoss work, why cant its DS be called something like JBossDS? I found that the tags, user-name.../user-name password.../password in mssql-xa-ds.xml dont provide username and password information to the connection. I got a login failure when l used these. I removed these tags and added xa-datasource-property name=Usersa/xa-datasource-property xa-datasource-property name=Passwordsecret/xa-datasource-property At this stage l believe they have fixed the login failure. I tested the wrapper with a transaction that inserts records into two tables with two BMP beans - which works when l use it on JBoss 3.0. The transaction ended up timing out. I checked the SQL Server manager and it indicated that two processes were blocking - lm assuming these were the two inserts. I'll do some simpler tests over the next couple of days to give you a better idea of how the wrapper is behaving. Hope this is helpful Jamie Burns (Sorry about the mail threads. When l post a message or reply to a message the list server stops sending replies back to the email address l used. Ive had to set up a second account so that l can see the replies to my postings. I was trying to find a way of making it think that my posts were coming from the one email address but its obvious thats not working - sorry for the mess.) - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, August 31, 2002 1:27 AM Subject: Re: [JBoss-dev] XADataSource wrapper for JBoss 4 I think Igor fixed this in cvs yesterday, have you updated? For some reason your message is not showing as a response to anything in my mail viewer so I can't tell what the context of your post is. david jencks On 2002.08.30 18:16:53 -0400 Jamie Burns wrote: FW: [JBoss-dev] XADataSource wrapper for JBoss 4Thanks Igor. Ive made the change you suggested. The transformed xml looks more familiar. When mssql-xa-ds.xml was deployed, l got the following error in the log java.lang.IllegalArgumentException: The class 'class org.jboss.resource.adapter.jdbc.xa.XAManagedConnectionFactory' has no setter for config property 'XADataSourceClass' at org.jboss.resource.connectionmanager.RARDeployment.setManagedConnectionFacto ryAttribute(RARDeployment.java:567) at org.jboss.resource.connectionmanager.RARDeployment.setMcfProperties(RARDeplo yment.java:670) at org.jboss.resource.connectionmanager.RARDeployment.startService(RARDeploymen t.java:525) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:196) I had a look at XAManagedConnectionFactory and DataSourceTemplate.xml. The problem just appears to be a difference in case. XAManagedConnectionFactory has setXaDataSourceClass() and DataSourceTemplate creates a property XADataSourceClass. It looks like you are capitalising XA. Should XAManagedConnectionFactory be changed to setXADataSourceClass() or should DataSourceTemplate create a property XaDataSourceClass? I've copied jboss-all\build\output to working location on my disk. I can only find DataSourceTemplate.xsl in jboss-all\connector\output\resources\stylesheet. IF l wanted to change DataSourceTemplate to create a property XaDataSourceClass - quicker fix than rebuilding - where do l change this? How does the change you suggested to mssql-xa-ds.xml get made in the CVS? Thanks In mssql-xa
Re: [JBoss-dev] XADataSource wrapper for JBoss 4
I checked out Igor's fix as you suggested and got past the compile problem. I've spent the last couple of days working out why my EAR that worked on JBoss 3 didnt work on JBoss 4. In JBoss 3.0, l removed the hsqldb-service.xml because l was using SQL Server and l wanted to use DefaultDS as my JNDI name. JBoss 4 wasnt happy with this. Ive had to keep hsqldb-ds.xml and change the JNDI name for my SQL Server DS to MSSQLDS. What is hsqldb-ds.xml being used for and if its DS is needed to make JBoss work, why cant its DS be called something like JBossDS? I found that the tags, user-name.../user-name password.../password in mssql-xa-ds.xml dont provide username and password information to the connection. I got a login failure when l used these. I removed these tags and added xa-datasource-property name=Usersa/xa-datasource-property xa-datasource-property name=Passwordsecret/xa-datasource-property At this stage l believe they have fixed the login failure. I tested the wrapper with a transaction that inserts records into two tables with two BMP beans - which works when l use it on JBoss 3.0. The transaction ended up timing out. I checked the SQL Server manager and it indicated that two processes were blocking - lm assuming these were the two inserts. I'll do some simpler tests over the next couple of days to give you a better idea of how the wrapper is behaving. Hope this is helpful Jamie Burns (Sorry about the mail threads. When l post a message or reply to a message the list server stops sending replies back to the email address l used. Ive had to set up a second account so that l can see the replies to my postings. I was trying to find a way of making it think that my posts were coming from the one email address but its obvious thats not working - sorry for the mess.) - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, August 31, 2002 1:27 AM Subject: Re: [JBoss-dev] XADataSource wrapper for JBoss 4 I think Igor fixed this in cvs yesterday, have you updated? For some reason your message is not showing as a response to anything in my mail viewer so I can't tell what the context of your post is. david jencks On 2002.08.30 18:16:53 -0400 Jamie Burns wrote: FW: [JBoss-dev] XADataSource wrapper for JBoss 4Thanks Igor. Ive made the change you suggested. The transformed xml looks more familiar. When mssql-xa-ds.xml was deployed, l got the following error in the log java.lang.IllegalArgumentException: The class 'class org.jboss.resource.adapter.jdbc.xa.XAManagedConnectionFactory' has no setter for config property 'XADataSourceClass' at org.jboss.resource.connectionmanager.RARDeployment.setManagedConnectionFacto ryAttribute(RARDeployment.java:567) at org.jboss.resource.connectionmanager.RARDeployment.setMcfProperties(RARDeplo yment.java:670) at org.jboss.resource.connectionmanager.RARDeployment.startService(RARDeploymen t.java:525) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:196) I had a look at XAManagedConnectionFactory and DataSourceTemplate.xml. The problem just appears to be a difference in case. XAManagedConnectionFactory has setXaDataSourceClass() and DataSourceTemplate creates a property XADataSourceClass. It looks like you are capitalising XA. Should XAManagedConnectionFactory be changed to setXADataSourceClass() or should DataSourceTemplate create a property XaDataSourceClass? I've copied jboss-all\build\output to working location on my disk. I can only find DataSourceTemplate.xsl in jboss-all\connector\output\resources\stylesheet. IF l wanted to change DataSourceTemplate to create a property XaDataSourceClass - quicker fix than rebuilding - where do l change this? How does the change you suggested to mssql-xa-ds.xml get made in the CVS? Thanks In mssql-xa-ds.xml try to replace xa-tx-datasource with xa-datasource. Internally -ds.xml files are transformed into -service.xml using xslt template defined in connector/src/resource/stylesheets/DataSourceTemplate.xsl. You can look into this file to see if it does what you need. Also check logs/console output for exception messages. Jamie Burns wrote: Thanks Igor. Since you have got further than me, can l compare your setup with mine? I am working in jboss-4.0.0alpha\server\default. I have the 3 MS SQL Server 2000 jars in ..\lib. Ive taken hsqldb-ds.xml out of .\deploy so that l have only one DataSource and so that l can use DefaultDS as the jndi name for my MSSQL DataSource. Ive copied mssql-xa-ds.xml from the examples folder and configured it for my site. I used to use mssql-xa-service.xml in JBoss 3.0. It had a lot more in it than mssql-xa-ds.xml. Do l still need to the stuff that was in mssql-xa-service.xml? I dont have mssql-xa-service.xml installed anywhere
RE: [JBoss-dev] XADataSource wrapper for JBoss 4
Title: FW: [JBoss-dev] XADataSource wrapper for JBoss 4 Thanks Igor. Ive made the change you suggested. The transformed xml looks more familiar. When mssql-xa-ds.xml was deployed, l got the following error in the log java.lang.IllegalArgumentException: The class 'class org.jboss.resource.adapter.jdbc.xa.XAManagedConnectionFactory' has no setter for config property 'XADataSourceClass'at org.jboss.resource.connectionmanager.RARDeployment.setManagedConnectionFactoryAttribute(RARDeployment.java:567)at org.jboss.resource.connectionmanager.RARDeployment.setMcfProperties(RARDeployment.java:670)at org.jboss.resource.connectionmanager.RARDeployment.startService(RARDeployment.java:525)at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:196) I had a look at XAManagedConnectionFactory and DataSourceTemplate.xml. The problem just appears to be a difference in case. XAManagedConnectionFactory has setXaDataSourceClass() and DataSourceTemplate creates a property XADataSourceClass. It looks like you are capitalising "XA". Should XAManagedConnectionFactory be changed to setXADataSourceClass() or should DataSourceTemplate create a property XaDataSourceClass? I've copied jboss-all\build\output to working location on my disk. I can only find DataSourceTemplate.xsl in jboss-all\connector\output\resources\stylesheet. IF l wanted to change DataSourceTemplate to create a property XaDataSourceClass - quicker fix than rebuilding - where do l change this? How does the change you suggested to mssql-xa-ds.xml get madein the CVS? Thanks In mssql-xa-ds.xml try to replace "xa-tx-datasource" with "xa-datasource". Internally -ds.xml files are transformed into -service.xml using xslt template defined in connector/src/resource/stylesheets/DataSourceTemplate.xsl. You can look into this file to see if it does what you need. Also check logs/console output for exception messages. Jamie Burns wrote: Thanks Igor. Since you have got further than me, can l compare your setup with mine? I am working in jboss-4.0.0alpha\server\default. I have the 3 MS SQL Server 2000 jars in ..\lib. Ive taken hsqldb-ds.xml out of .\deploy so that l have only one DataSource and so that l can use DefaultDS as the jndi name for my MSSQL DataSource. Ive copied mssql-xa-ds.xml from the examples folder and configured it for my site. I used to use mssql-xa-service.xml in JBoss 3.0. It had a lot more in it than mssql-xa-ds.xml. Do l still need to the stuff that was in mssql-xa-service.xml? I dont have mssql-xa-service.xml installed anywhere. Ive added a application-policy name = "MSSQLDbRealm" to .\conf\login-config.xml because l had that in the JBoss 3. But l dont think l ever used it in JBoss 3. Is there anything l need to do/undo re setting things up for the new XADataSource wrappers? Thanks again. -- Igor Fedorenko Think smart. Think automated. Think Dynamics. www.thinkdynamics.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list Jboss-development@lists=
Re: [JBoss-dev] XADataSource wrapper for JBoss 4
Thanks Igor. Since you have got further than me, can l compare your setup with mine? I am working in jboss-4.0.0alpha\server\default. I have the 3 MS SQL Server 2000 jars in .\lib. Ive taken hsqldb-ds.xml out of .\deploy so that l have only one DataSource and so that l canuse DefaultDS as the jndi name for my MSSQL DataSource. Ive copied mssql-xa-ds.xml from the examples folder and configured it for my site. I used to use mssql-xa-service.xml in JBoss 3.0. It had a lot more in it than mssql-xa-ds.xml. Do l still need to the stuff that was in mssql-xa-service.xml? I dont have mssql-xa-service.xml installed anywhere. Ive added a application-policy name = "MSSQLDbRealm" to .\conf\login-config.xml because l had that in the JBoss 3. But l dont think l ever used it in JBoss 3. Is there anything l need to do/undo re setting things up for the new XADataSource wrappers? Thanks again.
[JBoss-dev] Failed to connect to server iiop
Ive been attempting to test the new XADataSource
wrapper that David Jenks has written but lm having trouble getting JBoss 4 alpha
working so that l can test wrapper.
It mainly looks like the Jboss MQ stuff is not
setting up properly but since l am not using that bit l have been ignoring the
errors.
The error l am trying to get past occurs when my
app goes to get my EJB that is going to access the DataSource
Object obj =
context.lookup("NamingEjb");
There doesnt appear to be any errors in the logs
indicating the iiop failed.
Im using an EAR that works on JBoss 3.
Does anyone have any hints or solutions for a
failure to connect to server iiop?
Thanks
[JBoss-dev] XADataSource wrapper for JBoss 4
Im having a go at testing the XADataSource wrapper that David Jenks has written for JBoss 4 against MS SQL Server 2000. Ive checked out HEAD and built it ok. However, im getting a variety of errorswhen starting JBoss. When JBoss loaded l was getting an error while it was deploying jmx-html-adapter.sar. Ive removed it and get a cleaner startup. Will removing jmx-html-adapter.sar break JBoss? With jmx-html-adapter.sar out of the picture l only get the following error when JBoss starts. ERROR [org.jboss.deployment.scanner.URLDeploymentScanner] MBeanException: Exception in MBean operation 'checkIncompleteDeployments()' I havent written any MBeans so l cant see that l have done anything to cause this. Any clues about what is causing this? When my client tries to load my EJB l get the following error. 20:47:43,187 WARN [NamingContext] Failed to connect to iiop:1099javax.naming.CommunicationException: Failed to connect to server iiop:1099. Root exception isjavax.naming.ServiceUnavailableException: Failed to connect to server iiop:1099. Root exception isjava.net.UnknownHostException: iiop at java.net.InetAddress.getAllByName0(InetAddress.java:920) ... 20:47:48,735 ERROR [STDERR] javax.naming.CommunicationException: Receive timed out. Root exception is20:47:48,735 ERROR [STDERR] java.net.SocketTimeoutException: Receive timed out Is this likely to be related to the MBeanException above or the removal of jmx-html-adapter? The EAR lm going to use to test Davids XADataSource wrapper is working on JBoss 3.0. Is there anything special l have to do to port an EAR across to JBoss 4 alpha? Thanks
