Re: [JBoss-dev] JBoss JMS RA + SwiftMQ + Possible Problems
I just double checked my app and I am closing senders, sessions and connections where appropriate... and yet I am still getting XAExceptions like this: WARN TxCapsule [SocketListener-1] (MailingManager) XAException: tx=XidImpl [FormatId=257, GlobalId=eng-ecr3a//21, BranchQual=] errorCode=XAER_RMERR javax.transaction.xa.XAException at com.swiftmq.jms.XAResourceImpl.start(XAResourceImpl.java:121) at org.jboss.tm.TxCapsule.startResource(TxCapsule.java:1090) at org.jboss.tm.TxCapsule.enlistResource(TxCapsule.java:623) at org.jboss.tm.TransactionImpl.enlistResource(TransactionImpl.java:111) at org.jboss.pool.connector.BaseConnectionManager$XAListener.enlist(BaseConnectionManager.java:592) at org.jboss.pool.connector.BaseConnectionManager$XAListener.register(BaseConnectionManager.java:601) at org.jboss.pool.connector.XAConnectionManager.allocateConnection(XAConnectionManager.java:95) at org.jboss.jms.ra.JmsSessionFactoryImpl.createQueueSession(JmsSessionFactoryImpl.java:125) at com.boldfish.does.mailing.service.internal.MailingManagerEJB.enqueueStartJob(MailingManagerEJB.java:130) at com.boldfish.does.mailing.service.internal.MailingManagerEJB.enqueueCreateJob(MailingManagerEJB.java:230) at com.boldfish.does.mailing.service.internal.MailingManagerEJB.createMailing(MailingManagerEJB.java:253) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:572) at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:67) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:97) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:154) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:63) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:129) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:168) at org.jboss.ejb.StatelessSessionContainer.invoke(StatelessSessionContainer.java:282) at org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke(JRMPContainerInvoker.java:445) at org.jboss.ejb.plugins.jrmp.interfaces.GenericProxy.invokeContainer(GenericProxy.java:339) at org.jboss.ejb.plugins.jrmp.interfaces.StatelessSessionProxy.invoke(StatelessSessionProxy.java:123) at $Proxy9.createMailing(Unknown Source) at com.boldfish.does.listener.xmlrpc.MailingHandler.createMailing(MailingHandler.java:977) at com.boldfish.does.listener.xmlrpc.MailingHandler.uploadEndOfPostedList(MailingHandler.java:763) at java.lang.reflect.Method.invoke(Native Method) at com.boldfish.xmlrpc.handler.DynamicHandler.execute(DynamicHandler.java:126) at com.boldfish.xmlrpc.handler.DynamicHandler.execute(DynamicHandler.java:81) at com.boldfish.xmlrpc.handler.NestedHandler.execute(NestedHandler.java:79) at com.boldfish.xmlrpc.handler.XmlRpcHandlerAdapter.execute(XmlRpcHandlerAdapter.java:56) at org.apache.xmlrpc.XmlRpcServer$Worker.execute(XmlRpcServer.java) at org.apache.xmlrpc.XmlRpcServer.execute(XmlRpcServer.java) at org.apache.xmlrpc.XmlRpcServer.execute(XmlRpcServer.java) at com.boldfish.xmlrpc.handler.servlet.XRServlet.doPost(XRServlet.java:205) at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at com.boldfish.xmlrpc.handler.servlet.XRServlet.service(XRServlet.java:127) at com.mortbay.Jetty.Servlet.ServletHolder.handle(ServletHolder.java:488) at com.mortbay.Jetty.Servlet.ServletHandler.handle(ServletHandler.java:537) at com.mortbay.Jetty.Servlet.ServletHandler.handle(ServletHandler.java:366) at com.mortbay.HTTP.HandlerContext.handle(HandlerContext.java:956) at com.mortbay.HTTP.HandlerContext.handle(HandlerContext.java:913) at com.mortbay.HTTP.HttpServer.service(HttpServer.java:718) at com.mortbay.HTTP.HttpConnection.service(HttpConnection.java:547) at com.mortbay.HTTP.HttpConnection.handle(HttpConnection.java:365) at com.mortbay.HTTP.SocketListener.handleConnection(SocketListener.java:107) at com.mortbay.Util.ThreadedServer.handle(ThreadedServer.java:294) at com.mortbay.Util.ThreadPool$PoolThreadRunnable.run(ThreadPool.java:613) at java.lang.Thread.run(Thread.java:484) Note this is in a pre 3.0 container... I will try running the same app in the 3.0 RC, but that is going to be a pain, since I have to reconfig everything (and unsar jetty and others so that I can config everything as I could in 2.4.x & pre-3.0. I posted a question on the SwiftMQ forums, but if someone here could tell
Re: [JBoss-dev] JBoss JMS RA + SwiftMQ + Possible Problems
On Wed, 24 Apr 2002, Anatoly Akkerman wrote: > It is a big and complex beast. I remember digging through it when I > found some bugs, shrug ... It implements all the CORBA JTA stuff for > distributed TXs. I just wrote a hack to propagate the transaction context > together with JBoss MethodInvocation, instead of CORBA ORB -- the way > Tyrex would do it. Do you reckon how difficult it would be to use Tyrex together with JBoss/IIOP and do transaction propagation the CORBA way? Best, Francisco ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss JMS RA + SwiftMQ + Possible Problems
Hi again, I dont know if I have al possible error conditions in my head, and my excperiences are based on the 2.4.3 code. Also remember that the current JMS RA does not have any support for reconnect or exception listener. What we basically want is failover, i.e the JMS provider in this case (or a db I guess in other cases) has gone down and come up again. 1. The case where the EIS is down when the client is doing a call should be transparent. The client gets an exception and the mc uses the listener to invalidate that mc in the pool. Things gets more complicated when the EIS has come back. One verry important restriction here is that the spec says that an instance of an mc must allways return the same XAResource! 2. The client gets an handle, probably from the pool. a) If the RA does not have an asynchronous exception mechanism (as JMS have), we are in big trubble. The server side JCA stuff will macth an existring mc, will atach a listener and get the XAResource, and if this is correctly done that XAResource will actually not be valid any more, something like this will be reported: [SMSTransport] XAException: tx=XidImpl [FormatId=257, GlobalId=linutv1//10, BranchQual=] errorCode=XAER_NOTA [SMSTransport] javax.transaction.xa.XAException Since we have, per spec to return the same XAResource for a mc we are not allowed to do magic here, i.e check if the resource has bee invalidated due to connection outake and make a new connection and return a new and valid XAResource. What could we do here: verry hard to say: In the API it says the getXAResource may throw a javax.resource.spi.ResourceAdapterInternalException to indicate that the mc is not valid any more. This could perhaps be used to invalidate the mc, and let the JCA stuff simple create a new one. b) If it has asynchronous support the listener API could be used to propagate the invalidation. I do not know if it is reallt spec compliant not to set the listener every time the mc is taken from the pool, but the way you have done it seems to do it easy to have asynchronous error reporting/invalidation. I guess it is also important for an XAResource that is invalid in the way described before is never enlisted in the tm. What I am trying to say is simply this: XA capable mc:s for wich the connection has gone down, but the EIS has come up agains, needs to invalidated in a transparent way for the client using it. //Peter On 24 Apr, David Jencks wrote: > On 2002.04.24 15:48:16 -0400 [EMAIL PROTECTED] wrote: >> On 24 Apr, David Jencks wrote: >> > So the problem you had was that ManagedConnection.getXAResource was >> called >> > before ManagedConnection.addConnectionEventListener? It is always >> > dangerous to claim things about code, but I am sure that >> > ManagedConnection.addConnectionEventListener is always called before >> > ManagedConnection.getXAResource in the new implementation. >> > >> > When connectionErrorOccurred is called, the ManagedConnection is >> destroyed >> > and removed from the pool. IMO with a compliant adapter, this will >> result >> > in all the connection handles associated with that ManagedConnection >> > becoming unattached to any ManagedConnection. In the new >> implementation, >> > if you cache connection handles accross method invocations, in the next >> > invocation these handles will be associated with a presumably valid >> > ManagedConnection obtained from the pool or newly created. Again IMO >> the >> > adapter should throw enough of an exception to roll back the current tx >> if >> > the physical connection dies. >> >> This sounds OK. If you try to get an mc, and these things happens (i.e >> whan you add the listener add will emediately be called at >> connectionErrorOccurred, what happends then, do you try to get a new mc >> from the pool (which probaly are dead all of them), or do you create a >> new mc. > > I haven't thought about these asynchronous possibilities before. The > adapter is supposed to call the connectionErrorOccurred on the listeners > and then through an exception to the client. Is there any way to do that, > even when you know there is a client? I'd imagine that when there isn't, > no problem. > >> >> The basic problem here is that when using an ExceptionListener with JMS >> the connectio error can happen any time. If the mc is in use, it will be >> noticed and all is fine, but if the mc is in the pool, the only way it >> can raise the error is to wait for a listener to become added when it is >> above to be moved from the pool into an active state. > > Again, I haven't thought through this asynchronous case, but it might work > fine as is. In the new system, a ManagedConnection gets one > ConnectionEventListener throughout its entire lifespan, and keeps it while > it is pooled. I haven't checked my destroy/kill logic, but it should be > possible to deal with these events properly even when the managed > connection is in the pool. > > Is there any chance you have tests
Re: [JBoss-dev] JBoss JMS RA + SwiftMQ + Possible Problems
On 2002.04.24 19:57:23 -0400 Jason Dillon wrote: > > > > > >It doesn't pretend to do logging, which is what you need for failure > >recovery and reliable 2pc. Do you have any evidence that anything else > is > >ever causing problems in it? Much to my surprise, all the bugs I've > >thought were definitely in the tx manager turned out to be in my code;-) > > >(OK, there were a couple of minor tweaks I made). > > > > Bugs... in my own code? Ha, you are funny. > > =P > > >Tyrex is way way way more than a tx manager-- it includes all sorts of > >things such as connection pooling. I don't think relying on it is a > >terribly good idea for the long term. I would rather see us add logging > to > >our tm. Perhaps we can get Ole to give us a little advice on this one. > If > >we use the jdk 1.4 nio maybe it even won't be ridiculously slow;-) > > > > I was only implying that we don't have to build every component... if > there is something out there which is better... lets use it. I don't > know about the Tyrex case, which is why I asked for opinions. > > Grow by aquisition where possible, it will allow us to get there > faster as long as integration and maintence overheads are kept in > check that is. IMNSHO the tm is so central we should control the code base of our standard tm. david > > --jason > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss JMS RA + SwiftMQ + Possible Problems
> > >It doesn't pretend to do logging, which is what you need for failure >recovery and reliable 2pc. Do you have any evidence that anything else is >ever causing problems in it? Much to my surprise, all the bugs I've >thought were definitely in the tx manager turned out to be in my code;-) >(OK, there were a couple of minor tweaks I made). > Bugs... in my own code? Ha, you are funny. =P >Tyrex is way way way more than a tx manager-- it includes all sorts of >things such as connection pooling. I don't think relying on it is a >terribly good idea for the long term. I would rather see us add logging to >our tm. Perhaps we can get Ole to give us a little advice on this one. If >we use the jdk 1.4 nio maybe it even won't be ridiculously slow;-) > I was only implying that we don't have to build every component... if there is something out there which is better... lets use it. I don't know about the Tyrex case, which is why I asked for opinions. Grow by aquisition where possible, it will allow us to get there faster as long as integration and maintence overheads are kept in check that is. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss JMS RA + SwiftMQ + Possible Problems
On 2002.04.24 17:46:04 -0400 Jason Dillon wrote: > > Tyrex works in 3.0 (at least it did about 2 months ago when I patched > it > > up). I would not recommend Tyrex for work in distributed transactions, > > because it would be very slow. It should work fine as a local TM as > well > > but, probably, it is slower than JBossTX. To get it to work you would > have > > How much slower compaired to how much more robust? Can we fix some of > its > slowness? > > I don't have lots of evidence to back this up yet... but I think our fast > tx > manager is not very robust and reliable... but that is just a feeling I > have > right now. It doesn't pretend to do logging, which is what you need for failure recovery and reliable 2pc. Do you have any evidence that anything else is ever causing problems in it? Much to my surprise, all the bugs I've thought were definitely in the tx manager turned out to be in my code;-) (OK, there were a couple of minor tweaks I made). Tyrex is way way way more than a tx manager-- it includes all sorts of things such as connection pooling. I don't think relying on it is a terribly good idea for the long term. I would rather see us add logging to our tm. Perhaps we can get Ole to give us a little advice on this one. If we use the jdk 1.4 nio maybe it even won't be ridiculously slow;-) david jencks > > I would rather have slower and more stable than super quick... but right > now I > would not trust using Tyrex, because hardly anyone uses it with JBoss. > > It's open source (are the licenses compatible... don't know, have not > cjecked > what the exact license is), if it is more feature rich why don't we > integrate > it at the source level then work on fixing its speed issues? > > > to tweak some build files, though, since I never had a chance to make > it a > > SAR, the tyrex-plugin.jar does not get built, though the classes are > > compiled > > Please don't turn it into a .sar... leave it as a .jar + .xml (see my > previous > rants about this). > > --jason > > > - > This mail sent through IMP: http://horde.org/imp/ > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss JMS RA + SwiftMQ + Possible Problems
On Wed, 24 Apr 2002, Jason Dillon wrote: > > Tyrex works in 3.0 (at least it did about 2 months ago when I patched it > > up). I would not recommend Tyrex for work in distributed transactions, > > because it would be very slow. It should work fine as a local TM as well > > but, probably, it is slower than JBossTX. To get it to work you would have > > How much slower compaired to how much more robust? Can we fix some of its > slowness? I have no idea how much slower it is. Are there any speed tests in the testsuite? > > I don't have lots of evidence to back this up yet... but I think our fast tx > manager is not very robust and reliable... but that is just a feeling I have > right now. > > I would rather have slower and more stable than super quick... but right now I > would not trust using Tyrex, because hardly anyone uses it with JBoss. Hey, it is just a matter of trying it out. Someone has to start, the rest will follow :) Not that I'm advocating Tyrex here. > > It's open source (are the licenses compatible... don't know, have not cjecked > what the exact license is), if it is more feature rich why don't we integrate > it at the source level then work on fixing its speed issues? > It is a big and complex beast. I remember digging through it when I found some bugs, shrug ... It implements all the CORBA JTA stuff for distributed TXs. I just wrote a hack to propagate the transaction context together with JBoss MethodInvocation, instead of CORBA ORB -- the way Tyrex would do it. Anatoly. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss JMS RA + SwiftMQ + Possible Problems
> Tyrex works in 3.0 (at least it did about 2 months ago when I patched it > up). I would not recommend Tyrex for work in distributed transactions, > because it would be very slow. It should work fine as a local TM as well > but, probably, it is slower than JBossTX. To get it to work you would have How much slower compaired to how much more robust? Can we fix some of its slowness? I don't have lots of evidence to back this up yet... but I think our fast tx manager is not very robust and reliable... but that is just a feeling I have right now. I would rather have slower and more stable than super quick... but right now I would not trust using Tyrex, because hardly anyone uses it with JBoss. It's open source (are the licenses compatible... don't know, have not cjecked what the exact license is), if it is more feature rich why don't we integrate it at the source level then work on fixing its speed issues? > to tweak some build files, though, since I never had a chance to make it a > SAR, the tyrex-plugin.jar does not get built, though the classes are > compiled Please don't turn it into a .sar... leave it as a .jar + .xml (see my previous rants about this). --jason - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss JMS RA + SwiftMQ + Possible Problems
I have not yet tested my systems with 3.0 yet... as the config change is a bit too much for me to manage on top of the billion other things I have todo. Though I may beforced to write a testsuite which reproduces my problem and then test it under 3.0... though I would like to avoid that, even though the added testsuite would be good for us... I just don't have time right now. I just need it to work =| --jason Quoting David Jencks <[EMAIL PROTECTED]>: > On 2002.04.24 10:14:20 -0400 Peter Antman wrote: > > > > I thing JBoss is the only appserver where JMS XA sending is not tied to > > the server nor to a specific JMS provider, but perhaps at a price: close > > your sessions!! Otherwise it works nice, I think and what should be > > fixed are some problems with the app server side of the JCA > > implementation. > > What are they? Can you be more specific? Any tests? Are the problems still > present with the all-new jca implementation in jboss 3? > > Thanks > david jencks > > > > //Peter > > > > > >>I could not come up with a good solution on this problem, except > > >>documenting how to use it. If someone can find a solution, pleas > > commit > > >>it. > > >> > > >>//Peter > > >> > > > >> > Anyone have some time to check this out and look over what needs to > > be > > >>done? > > >> > > > >> > Thanks, > > >> > > > >> > --jason > > >> > > > >> > > > >> > ___ > > >> > Jboss-development mailing list > > >> > [EMAIL PROTECTED] > > >> > https://lists.sourceforge.net/lists/listinfo/jboss-development > > >> > > >>-- > > >> > > >>Peter Antman Chief Systems Architect, Business Development > > >>Technology in Media, Box 34105 100 26 Stockholm > > >>WWW: http://www.tim.seWWW: http://www.backsource.org > > >>Email: [EMAIL PROTECTED] > > >>Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942 > > >> > > >> > > >> > > >>___ > > >>Jboss-development mailing list > > >>[EMAIL PROTECTED] > > >>https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > > > > > > > _ > > > Join the worlds largest e-mail service with MSN Hotmail. > > > http://www.hotmail.com > > > > > > > > > ___ > > > Jboss-development mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > -- > > > > Peter AntmanChief Systems Architect, Business Development > > Technology in Media, Box 34105 100 26 Stockholm > > WWW: http://www.tim.se WWW: http://www.backsource.org > > Email: [EMAIL PROTECTED] > > Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942 > > > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss JMS RA + SwiftMQ + Possible Problems
Would it be reasonable for the Connection which is handed out to manage a set of Sessions which it has created, then when the user closes the connection it will close each session created? I thought I read somewhere in the JMS spec that if you closed a session it could close all readers and senders, or that it was not nessicary then, also that if you close as connection it does the same to a session. So people might simply be closing the connections per the spec? Man, I wish you had time to lok over this stuff... XA just makes me insane. --jason Quoting Peter Antman <[EMAIL PROTECTED]>: > On 24 Apr, Hiram Chirino wrote: > >>From: Peter Antman <[EMAIL PROTECTED]> > >>To: [EMAIL PROTECTED] > >>CC: [EMAIL PROTECTED] > >>Subject: Re: [JBoss-dev] JBoss JMS RA + SwiftMQ + Possible Problems > >>Date: Wed, 24 Apr 2002 10:35:29 +0200 (CEST) > >> > >>On 23 Apr, Jason Dillon wrote: > >> > Hey, I have just started integrating SwiftMQ for use in my production > >> > environment at work and by doing so I have notice d that we might have > >> > some issues with the JMS RA. > >> > > >> > Clayton Wheeler responsed to a message I wrote in the SwiftMQ forums > >> > with a document he wrote about getting it to work: > >> > > >> > http://culture.iridio.com/~csw/jboss-swiftmq/ > >> > > >> > I was hoping that the JMS folks (probably Peter since he wrote it, or > >> > really anyone else familar with this stuff) could take a look at the > >> > document and see if we can nail down some of the issues (like > >> > connection.close() not closing sessions and finally drop the queue/ > and > >> > topic/ prefixes from being requirements of the system). > >> > >>Hi, I am currently under sever time contraints, so unfortunately I do > >>not have the time to do the testing that is rquired to check new stuff > >>in. Just yesterday I integrated SonicMQ into 2.4.3 and I have also seen > >>a couple of things that needs to be done to ease integration. > >> > >>- JMS ContainerInvoker and DLQHandler need to be easier to subclass. > >>- We must probably factor out the ConnectionConsumer stuff. > >>- We must also see to it that StdServerSession and Pool are easy to > >>sublcass, and at least factor out creation of StdServerSession > >> > > > > I have a feeling that the DLQHandler can be implemented as an interceptor. > > > So before the message gets delivered to the bean, the interceptor checks to > > > see if it has been redelivered to many times. This should help decouple > the > > the DLQ from the ContainerInvoker. > > I thought I tought about that and found it a noop, but looking at it > agains makes me wonder :-) It is probably a really great idea. > > > > >>- The DLQHandler must be configurable with a connectionfactory (JBossMQ > >> only handles Messages from foraign provider if they are Serializable, > >> wich is not part of the Message API. > >> > >>- topic and queue stuff from ContainerInvoker should be removed. This > >> was added by the one who implemented automatic creation of > >> destinations (which I oposed to). One way of doing this would be > >> moving creation of destination out into the PrividerAdapter to make it > >> possible to let also foraign providers create destinations on the fly > >> (if the can handle this). > >> > > > > Yes!!! I agree 102%!! > > > >>As for the JMS RA. This is basically a hack. Not in the meaning bad code > >>(I hope ;-)) but in that the spec for JCA is not designed for JMS. The > >>stuff you take from the pool, is the stuff that is transacted. This > >>works nice for db but not for JMS, since in JMS it is the session that > >>is transacted and that should be pooled in the JCA adapter, but it is > >>not a common idiom to directly get a session in JMS (which you can with > >>the JCA adapter). The connection is just a cover up class, which > >>basically do no JCA intercation. It's the session that do it. > >> > > > > So are you saying that every JMS provider should provider thier own RA > > implementation since that way they can cope with the architecture by using > > > provider specific calls in the RA?? > > No, that JCA RA is not meant to use to integrate JMS. Other appserver > vendors has verry special code to do this, and it will often mean that > integrating a new JMS provider means adding special code for th
Re: [JBoss-dev] JBoss JMS RA + SwiftMQ + Possible Problems
On 2002.04.24 15:48:16 -0400 [EMAIL PROTECTED] wrote: > On 24 Apr, David Jencks wrote: > > So the problem you had was that ManagedConnection.getXAResource was > called > > before ManagedConnection.addConnectionEventListener? It is always > > dangerous to claim things about code, but I am sure that > > ManagedConnection.addConnectionEventListener is always called before > > ManagedConnection.getXAResource in the new implementation. > > > > When connectionErrorOccurred is called, the ManagedConnection is > destroyed > > and removed from the pool. IMO with a compliant adapter, this will > result > > in all the connection handles associated with that ManagedConnection > > becoming unattached to any ManagedConnection. In the new > implementation, > > if you cache connection handles accross method invocations, in the next > > invocation these handles will be associated with a presumably valid > > ManagedConnection obtained from the pool or newly created. Again IMO > the > > adapter should throw enough of an exception to roll back the current tx > if > > the physical connection dies. > > This sounds OK. If you try to get an mc, and these things happens (i.e > whan you add the listener add will emediately be called at > connectionErrorOccurred, what happends then, do you try to get a new mc > from the pool (which probaly are dead all of them), or do you create a > new mc. I haven't thought about these asynchronous possibilities before. The adapter is supposed to call the connectionErrorOccurred on the listeners and then through an exception to the client. Is there any way to do that, even when you know there is a client? I'd imagine that when there isn't, no problem. > > The basic problem here is that when using an ExceptionListener with JMS > the connectio error can happen any time. If the mc is in use, it will be > noticed and all is fine, but if the mc is in the pool, the only way it > can raise the error is to wait for a listener to become added when it is > above to be moved from the pool into an active state. Again, I haven't thought through this asynchronous case, but it might work fine as is. In the new system, a ManagedConnection gets one ConnectionEventListener throughout its entire lifespan, and keeps it while it is pooled. I haven't checked my destroy/kill logic, but it should be possible to deal with these events properly even when the managed connection is in the pool. Is there any chance you have tests for this behavior? Or any more bad cases to be aware of? This is getting interesting! Thanks david jencks > > //Peter > > > > Are there some other issues I should look at? Have I missed something? > > > > thanks > > david jencks > > > > On 2002.04.24 11:07:07 -0400 Peter Antman wrote: > >> On 24 Apr, David Jencks wrote: > >> > On 2002.04.24 10:14:20 -0400 Peter Antman wrote: > >> > > > >> >> I thing JBoss is the only appserver where JMS XA sending is not > tied > >> to > >> >> the server nor to a specific JMS provider, but perhaps at a price: > >> close > >> >> your sessions!! Otherwise it works nice, I think and what should be > >> >> fixed are some problems with the app server side of the JCA > >> >> implementation. > >> > > >> > What are they? Can you be more specific? Any tests? Are the > problems > >> still > >> > present with the all-new jca implementation in jboss 3? > >> > >> As I wrote in an earlier mail: > >> > >> The real problem with the RA is that it is not failsafe. In itself > that > >> is pretty easilly fixed by adding an ExceptionListener, but it does > not > >> work with the (old?) jbosspool code: > >> > >> First it takes the XAResource before it adds a listener, but does not > >> handle when it gets an invalid XAResource due to a connection failour > >> (and by that time it is to late to transmit the error via the > listener). > >> > >> Then one can allways wonder about this: if we have a number of pooled > >> JMS session, all will become invallid when the connection has gone > down > >> (the XAResource is connected to a ManagedConnection and must allways > be > >> the same for each mc, but this is not possible if the > connection/session > >> is reestablished, i.e all outsating mc with a broken connection must > be > >> marked as invalid). But there is not way to know if the pool is just > >> trying pooled mc:s or are actually returning new one, which makes it > >> impossible to really know from the (XA)ConnectionManager how many > times > >> it should retry. > >> > >> At least this is the case in the 2.4 line (I think). > >> > >> And I also had to write: I unfortunately do not have the time to test > >> this out in the near future (next couple of weeks), especially not > with > >> the 3.0 line. > >> > >> Sorry. > >> //Peter > >> > > >> > Thanks > >> > david jencks > >> >> > >> >> //Peter > >> >> > > >> >> >>I could not come up with a good solution on this problem, except > >> >> >>documenting how to use it. If someone can find a solution, ple
Re: [JBoss-dev] JBoss JMS RA + SwiftMQ + Possible Problems
On Tue, 23 Apr 2002, Jason Dillon wrote: > Looking over the last bit of this doc about Xids and JBossTX... > > "JBossTX starts the global ID numbering from 1 each time it runs, so the global IDs >are not very unique. Needless to say, this could stand some improvement." > > Why don't we use a org.jboss.util.id.UID or org.jboss.util.GUID here for better >uniquness? > > Also, it refers to Tyrex, which has been integrated for a while. Does anyone know >what the status of Tyrex is? Is it still being maintained? Is is a better TX manager? > If so, why don't we make it the default? Tyrex works in 3.0 (at least it did about 2 months ago when I patched it up). I would not recommend Tyrex for work in distributed transactions, because it would be very slow. It should work fine as a local TM as well but, probably, it is slower than JBossTX. To get it to work you would have to tweak some build files, though, since I never had a chance to make it a SAR, the tyrex-plugin.jar does not get built, though the classes are compiled Anatoly. > > --jason > * * * > > View thread online: http://jboss.org/forums/thread.jsp?forum=66&thread=13848 > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss JMS RA + SwiftMQ + Possible Problems
So the problem you had was that ManagedConnection.getXAResource was called before ManagedConnection.addConnectionEventListener? It is always dangerous to claim things about code, but I am sure that ManagedConnection.addConnectionEventListener is always called before ManagedConnection.getXAResource in the new implementation. When connectionErrorOccurred is called, the ManagedConnection is destroyed and removed from the pool. IMO with a compliant adapter, this will result in all the connection handles associated with that ManagedConnection becoming unattached to any ManagedConnection. In the new implementation, if you cache connection handles accross method invocations, in the next invocation these handles will be associated with a presumably valid ManagedConnection obtained from the pool or newly created. Again IMO the adapter should throw enough of an exception to roll back the current tx if the physical connection dies. Are there some other issues I should look at? Have I missed something? thanks david jencks On 2002.04.24 11:07:07 -0400 Peter Antman wrote: > On 24 Apr, David Jencks wrote: > > On 2002.04.24 10:14:20 -0400 Peter Antman wrote: > > > > >> I thing JBoss is the only appserver where JMS XA sending is not tied > to > >> the server nor to a specific JMS provider, but perhaps at a price: > close > >> your sessions!! Otherwise it works nice, I think and what should be > >> fixed are some problems with the app server side of the JCA > >> implementation. > > > > What are they? Can you be more specific? Any tests? Are the problems > still > > present with the all-new jca implementation in jboss 3? > > As I wrote in an earlier mail: > > The real problem with the RA is that it is not failsafe. In itself that > is pretty easilly fixed by adding an ExceptionListener, but it does not > work with the (old?) jbosspool code: > > First it takes the XAResource before it adds a listener, but does not > handle when it gets an invalid XAResource due to a connection failour > (and by that time it is to late to transmit the error via the listener). > > Then one can allways wonder about this: if we have a number of pooled > JMS session, all will become invallid when the connection has gone down > (the XAResource is connected to a ManagedConnection and must allways be > the same for each mc, but this is not possible if the connection/session > is reestablished, i.e all outsating mc with a broken connection must be > marked as invalid). But there is not way to know if the pool is just > trying pooled mc:s or are actually returning new one, which makes it > impossible to really know from the (XA)ConnectionManager how many times > it should retry. > > At least this is the case in the 2.4 line (I think). > > And I also had to write: I unfortunately do not have the time to test > this out in the near future (next couple of weeks), especially not with > the 3.0 line. > > Sorry. > //Peter > > > > Thanks > > david jencks > >> > >> //Peter > >> > > >> >>I could not come up with a good solution on this problem, except > >> >>documenting how to use it. If someone can find a solution, pleas > >> commit > >> >>it. > >> >> > >> >>//Peter > >> >> > > >> >> > Anyone have some time to check this out and look over what needs > to > >> be > >> >>done? > >> >> > > >> >> > Thanks, > >> >> > > >> >> > --jason > >> >> > > >> >> > > >> >> > ___ > >> >> > Jboss-development mailing list > >> >> > [EMAIL PROTECTED] > >> >> > https://lists.sourceforge.net/lists/listinfo/jboss-development > >> >> > >> >>-- > >> >> > >> >>Peter Antman Chief Systems Architect, Business Development > >> >>Technology in Media, Box 34105 100 26 Stockholm > >> >>WWW: http://www.tim.se WWW: http://www.backsource.org > >> >>Email: [EMAIL PROTECTED] > >> >>Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942 > >> >> > >> >> > >> >> > >> >>___ > >> >>Jboss-development mailing list > >> >>[EMAIL PROTECTED] > >> >>https://lists.sourceforge.net/lists/listinfo/jboss-development > >> > > >> > > >> > > >> > > >> > _ > >> > Join the worlds largest e-mail service with MSN Hotmail. > >> > http://www.hotmail.com > >> > > >> > > >> > ___ > >> > Jboss-development mailing list > >> > [EMAIL PROTECTED] > >> > https://lists.sourceforge.net/lists/listinfo/jboss-development > >> > >> -- > >> > >> Peter Antman Chief Systems Architect, Business Development > >> Technology in Media, Box 34105 100 26 Stockholm > >> WWW: http://www.tim.se WWW: http://www.backsource.org > >> Email: [EMAIL PROTECTED] > >> Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942 > >>
Re: [JBoss-dev] JBoss JMS RA + SwiftMQ + Possible Problems
On 24 Apr, David Jencks wrote: > On 2002.04.24 10:14:20 -0400 Peter Antman wrote: > > >> I thing JBoss is the only appserver where JMS XA sending is not tied to >> the server nor to a specific JMS provider, but perhaps at a price: close >> your sessions!! Otherwise it works nice, I think and what should be >> fixed are some problems with the app server side of the JCA >> implementation. > > What are they? Can you be more specific? Any tests? Are the problems still > present with the all-new jca implementation in jboss 3? As I wrote in an earlier mail: The real problem with the RA is that it is not failsafe. In itself that is pretty easilly fixed by adding an ExceptionListener, but it does not work with the (old?) jbosspool code: First it takes the XAResource before it adds a listener, but does not handle when it gets an invalid XAResource due to a connection failour (and by that time it is to late to transmit the error via the listener). Then one can allways wonder about this: if we have a number of pooled JMS session, all will become invallid when the connection has gone down (the XAResource is connected to a ManagedConnection and must allways be the same for each mc, but this is not possible if the connection/session is reestablished, i.e all outsating mc with a broken connection must be marked as invalid). But there is not way to know if the pool is just trying pooled mc:s or are actually returning new one, which makes it impossible to really know from the (XA)ConnectionManager how many times it should retry. At least this is the case in the 2.4 line (I think). And I also had to write: I unfortunately do not have the time to test this out in the near future (next couple of weeks), especially not with the 3.0 line. Sorry. //Peter > > Thanks > david jencks >> >> //Peter >> > >> >>I could not come up with a good solution on this problem, except >> >>documenting how to use it. If someone can find a solution, pleas >> commit >> >>it. >> >> >> >>//Peter >> >> > >> >> > Anyone have some time to check this out and look over what needs to >> be >> >>done? >> >> > >> >> > Thanks, >> >> > >> >> > --jason >> >> > >> >> > >> >> > ___ >> >> > Jboss-development mailing list >> >> > [EMAIL PROTECTED] >> >> > https://lists.sourceforge.net/lists/listinfo/jboss-development >> >> >> >>-- >> >> >> >>Peter Antman Chief Systems Architect, Business Development >> >>Technology in Media, Box 34105 100 26 Stockholm >> >>WWW: http://www.tim.se WWW: http://www.backsource.org >> >>Email: [EMAIL PROTECTED] >> >>Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942 >> >> >> >> >> >> >> >>___ >> >>Jboss-development mailing list >> >>[EMAIL PROTECTED] >> >>https://lists.sourceforge.net/lists/listinfo/jboss-development >> > >> > >> > >> > >> > _ >> > Join the worlds largest e-mail service with MSN Hotmail. >> > http://www.hotmail.com >> > >> > >> > ___ >> > Jboss-development mailing list >> > [EMAIL PROTECTED] >> > https://lists.sourceforge.net/lists/listinfo/jboss-development >> >> -- >> >> Peter Antman Chief Systems Architect, Business Development >> Technology in Media, Box 34105 100 26 Stockholm >> WWW: http://www.tim.se WWW: http://www.backsource.org >> Email: [EMAIL PROTECTED] >> Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942 >> >> >> >> ___ >> Jboss-development mailing list >> [EMAIL PROTECTED] >> https://lists.sourceforge.net/lists/listinfo/jboss-development >> >> -- Peter AntmanChief Systems Architect, Business Development Technology in Media, Box 34105 100 26 Stockholm WWW: http://www.tim.se WWW: http://www.backsource.org Email: [EMAIL PROTECTED] Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss JMS RA + SwiftMQ + Possible Problems
On 2002.04.24 10:14:20 -0400 Peter Antman wrote: > > I thing JBoss is the only appserver where JMS XA sending is not tied to > the server nor to a specific JMS provider, but perhaps at a price: close > your sessions!! Otherwise it works nice, I think and what should be > fixed are some problems with the app server side of the JCA > implementation. What are they? Can you be more specific? Any tests? Are the problems still present with the all-new jca implementation in jboss 3? Thanks david jencks > > //Peter > > > >>I could not come up with a good solution on this problem, except > >>documenting how to use it. If someone can find a solution, pleas > commit > >>it. > >> > >>//Peter > >> > > >> > Anyone have some time to check this out and look over what needs to > be > >>done? > >> > > >> > Thanks, > >> > > >> > --jason > >> > > >> > > >> > ___ > >> > Jboss-development mailing list > >> > [EMAIL PROTECTED] > >> > https://lists.sourceforge.net/lists/listinfo/jboss-development > >> > >>-- > >> > >>Peter AntmanChief Systems Architect, Business Development > >>Technology in Media, Box 34105 100 26 Stockholm > >>WWW: http://www.tim.se WWW: http://www.backsource.org > >>Email: [EMAIL PROTECTED] > >>Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942 > >> > >> > >> > >>___ > >>Jboss-development mailing list > >>[EMAIL PROTECTED] > >>https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > > _ > > Join the worlds largest e-mail service with MSN Hotmail. > > http://www.hotmail.com > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > -- > > Peter Antman Chief Systems Architect, Business Development > Technology in Media, Box 34105 100 26 Stockholm > WWW: http://www.tim.seWWW: http://www.backsource.org > Email: [EMAIL PROTECTED] > Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942 > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss JMS RA + SwiftMQ + Possible Problems
On 24 Apr, Hiram Chirino wrote: >>From: Peter Antman <[EMAIL PROTECTED]> >>To: [EMAIL PROTECTED] >>CC: [EMAIL PROTECTED] >>Subject: Re: [JBoss-dev] JBoss JMS RA + SwiftMQ + Possible Problems >>Date: Wed, 24 Apr 2002 10:35:29 +0200 (CEST) >> >>On 23 Apr, Jason Dillon wrote: >> > Hey, I have just started integrating SwiftMQ for use in my production >> > environment at work and by doing so I have notice d that we might have >> > some issues with the JMS RA. >> > >> > Clayton Wheeler responsed to a message I wrote in the SwiftMQ forums >> > with a document he wrote about getting it to work: >> > >> > http://culture.iridio.com/~csw/jboss-swiftmq/ >> > >> > I was hoping that the JMS folks (probably Peter since he wrote it, or >> > really anyone else familar with this stuff) could take a look at the >> > document and see if we can nail down some of the issues (like >> > connection.close() not closing sessions and finally drop the queue/ and >> > topic/ prefixes from being requirements of the system). >> >>Hi, I am currently under sever time contraints, so unfortunately I do >>not have the time to do the testing that is rquired to check new stuff >>in. Just yesterday I integrated SonicMQ into 2.4.3 and I have also seen >>a couple of things that needs to be done to ease integration. >> >>- JMS ContainerInvoker and DLQHandler need to be easier to subclass. >>- We must probably factor out the ConnectionConsumer stuff. >>- We must also see to it that StdServerSession and Pool are easy to >>sublcass, and at least factor out creation of StdServerSession >> > > I have a feeling that the DLQHandler can be implemented as an interceptor. > So before the message gets delivered to the bean, the interceptor checks to > see if it has been redelivered to many times. This should help decouple the > the DLQ from the ContainerInvoker. I thought I tought about that and found it a noop, but looking at it agains makes me wonder :-) It is probably a really great idea. > >>- The DLQHandler must be configurable with a connectionfactory (JBossMQ >> only handles Messages from foraign provider if they are Serializable, >> wich is not part of the Message API. >> >>- topic and queue stuff from ContainerInvoker should be removed. This >> was added by the one who implemented automatic creation of >> destinations (which I oposed to). One way of doing this would be >> moving creation of destination out into the PrividerAdapter to make it >> possible to let also foraign providers create destinations on the fly >> (if the can handle this). >> > > Yes!!! I agree 102%!! > >>As for the JMS RA. This is basically a hack. Not in the meaning bad code >>(I hope ;-)) but in that the spec for JCA is not designed for JMS. The >>stuff you take from the pool, is the stuff that is transacted. This >>works nice for db but not for JMS, since in JMS it is the session that >>is transacted and that should be pooled in the JCA adapter, but it is >>not a common idiom to directly get a session in JMS (which you can with >>the JCA adapter). The connection is just a cover up class, which >>basically do no JCA intercation. It's the session that do it. >> > > So are you saying that every JMS provider should provider thier own RA > implementation since that way they can cope with the architecture by using > provider specific calls in the RA?? No, that JCA RA is not meant to use to integrate JMS. Other appserver vendors has verry special code to do this, and it will often mean that integrating a new JMS provider means adding special code for that provider. I thing JBoss is the only appserver where JMS XA sending is not tied to the server nor to a specific JMS provider, but perhaps at a price: close your sessions!! Otherwise it works nice, I think and what should be fixed are some problems with the app server side of the JCA implementation. //Peter > >>I could not come up with a good solution on this problem, except >>documenting how to use it. If someone can find a solution, pleas commit >>it. >> >>//Peter >> > >> > Anyone have some time to check this out and look over what needs to be >>done? >> > >> > Thanks, >> > >> > --jason >> > >> > >> > ___ >> > Jboss-development mailing list >> > [EMAIL PROTECTED] >> > https://lists.sourceforge.net/lists/listinfo/jboss-development >>
Re: [JBoss-dev] JBoss JMS RA + SwiftMQ + Possible Problems
On 24 Apr, Andreas Mueller wrote: >> As for the JMS RA. This is basically a hack. Not in >> the meaning bad code >> (I hope ;-)) but in that the spec for JCA is not >> designed for JMS. The >> stuff you take from the pool, is the stuff that is >> transacted. This >> works nice for db but not for JMS, since in JMS it is >> the session that >> is transacted and that should be pooled in the JCA >> adapter, but it is >> not a common idiom to directly get a session in JMS >> (which you can with >> the JCA adapter). The connection is just a cover up >> class, which >> basically do no JCA intercation. It's the session >> that do it. >> >> I could not come up with a good solution on this >> problem, except >> documenting how to use it. If someone can find a >> solution, pleas commit >> it. > > Well, a really hot fix could be that someone from JBoss takes a look at Jonas. We >have integrated SwiftMQ there and it worked out of the box, including producing >messages within a MDB inside the same XA transaction, using multiple XA resources >(Oracle and SwiftMQ). They haven't a JCA RA but a very good wrapper around the JMS >stuff that handles the JTA enlistment etc. > > Since it is open source as well, you could use it at least as a template. > > -- Andreas > I would say it currently works pretty nice for JBoss to, and Swift have been integrated for 4 month, and we have has XA support longer that any other JMS vendor. //Peter > * * * > > View thread online: http://jboss.org/forums/thread.jsp?forum=66&thread=13848 > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development -- Peter AntmanChief Systems Architect, Business Development Technology in Media, Box 34105 100 26 Stockholm WWW: http://www.tim.se WWW: http://www.backsource.org Email: [EMAIL PROTECTED] Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss JMS RA + SwiftMQ + Possible Problems
>From: Peter Antman <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >CC: [EMAIL PROTECTED] >Subject: Re: [JBoss-dev] JBoss JMS RA + SwiftMQ + Possible Problems >Date: Wed, 24 Apr 2002 10:35:29 +0200 (CEST) > >On 23 Apr, Jason Dillon wrote: > > Hey, I have just started integrating SwiftMQ for use in my production > > environment at work and by doing so I have notice d that we might have > > some issues with the JMS RA. > > > > Clayton Wheeler responsed to a message I wrote in the SwiftMQ forums > > with a document he wrote about getting it to work: > > > > http://culture.iridio.com/~csw/jboss-swiftmq/ > > > > I was hoping that the JMS folks (probably Peter since he wrote it, or > > really anyone else familar with this stuff) could take a look at the > > document and see if we can nail down some of the issues (like > > connection.close() not closing sessions and finally drop the queue/ and > > topic/ prefixes from being requirements of the system). > >Hi, I am currently under sever time contraints, so unfortunately I do >not have the time to do the testing that is rquired to check new stuff >in. Just yesterday I integrated SonicMQ into 2.4.3 and I have also seen >a couple of things that needs to be done to ease integration. > >- JMS ContainerInvoker and DLQHandler need to be easier to subclass. >- We must probably factor out the ConnectionConsumer stuff. >- We must also see to it that StdServerSession and Pool are easy to >sublcass, and at least factor out creation of StdServerSession > I have a feeling that the DLQHandler can be implemented as an interceptor. So before the message gets delivered to the bean, the interceptor checks to see if it has been redelivered to many times. This should help decouple the the DLQ from the ContainerInvoker. >- The DLQHandler must be configurable with a connectionfactory (JBossMQ > only handles Messages from foraign provider if they are Serializable, > wich is not part of the Message API. > >- topic and queue stuff from ContainerInvoker should be removed. This > was added by the one who implemented automatic creation of > destinations (which I oposed to). One way of doing this would be > moving creation of destination out into the PrividerAdapter to make it > possible to let also foraign providers create destinations on the fly > (if the can handle this). > Yes!!! I agree 102%!! >As for the JMS RA. This is basically a hack. Not in the meaning bad code >(I hope ;-)) but in that the spec for JCA is not designed for JMS. The >stuff you take from the pool, is the stuff that is transacted. This >works nice for db but not for JMS, since in JMS it is the session that >is transacted and that should be pooled in the JCA adapter, but it is >not a common idiom to directly get a session in JMS (which you can with >the JCA adapter). The connection is just a cover up class, which >basically do no JCA intercation. It's the session that do it. > So are you saying that every JMS provider should provider thier own RA implementation since that way they can cope with the architecture by using provider specific calls in the RA?? >I could not come up with a good solution on this problem, except >documenting how to use it. If someone can find a solution, pleas commit >it. > >//Peter > > > > Anyone have some time to check this out and look over what needs to be >done? > > > > Thanks, > > > > --jason > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > >-- > >Peter Antman Chief Systems Architect, Business Development >Technology in Media, Box 34105 100 26 Stockholm >WWW: http://www.tim.se WWW: http://www.backsource.org >Email: [EMAIL PROTECTED] >Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942 > > > >___ >Jboss-development mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/jboss-development _ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss JMS RA + SwiftMQ + Possible Problems
On 23 Apr, Jason Dillon wrote: > Hey, I have just started integrating SwiftMQ for use in my production > environment at work and by doing so I have notice d that we might have > some issues with the JMS RA. The real problem with the RA is that it is not failsafe. In itself that is pretty easilly fixed by adding an ExceptionListener, but it does not work with the (old?) jbosspool code: First it takes the XAResource before it adds a listener, but does not handle when it gets an invalid XAResource due to a connection failour (and by that time it is to late to transmit the error via the listener). Then one can allways wonder about this: if we have a number of pooled JMS session, all will become invallid when the connection has gone down (the XAResource is connected to a ManagedConnection and must allways be the same for each mc, but this is not possible if the connection/session is reestablished, i.e all outsating mc with a broken connection must be marked as invalid). But there is not way to know if the pool is just trying pooled mc:s or are actually returning new one, which makes it impossible to really know from the (XA)ConnectionManager how many times it should retry. At least this is the case in the 2.4 line (I think). //Peter > > Clayton Wheeler responsed to a message I wrote in the SwiftMQ forums > with a document he wrote about getting it to work: > > http://culture.iridio.com/~csw/jboss-swiftmq/ > > I was hoping that the JMS folks (probably Peter since he wrote it, or > really anyone else familar with this stuff) could take a look at the > document and see if we can nail down some of the issues (like > connection.close() not closing sessions and finally drop the queue/ and > topic/ prefixes from being requirements of the system). > > Anyone have some time to check this out and look over what needs to be done? > > Thanks, > > --jason > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development -- Peter AntmanChief Systems Architect, Business Development Technology in Media, Box 34105 100 26 Stockholm WWW: http://www.tim.se WWW: http://www.backsource.org Email: [EMAIL PROTECTED] Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss JMS RA + SwiftMQ + Possible Problems
> As for the JMS RA. This is basically a hack. Not in > the meaning bad code > (I hope ;-)) but in that the spec for JCA is not > designed for JMS. The > stuff you take from the pool, is the stuff that is > transacted. This > works nice for db but not for JMS, since in JMS it is > the session that > is transacted and that should be pooled in the JCA > adapter, but it is > not a common idiom to directly get a session in JMS > (which you can with > the JCA adapter). The connection is just a cover up > class, which > basically do no JCA intercation. It's the session > that do it. > > I could not come up with a good solution on this > problem, except > documenting how to use it. If someone can find a > solution, pleas commit > it. Well, a really hot fix could be that someone from JBoss takes a look at Jonas. We have integrated SwiftMQ there and it worked out of the box, including producing messages within a MDB inside the same XA transaction, using multiple XA resources (Oracle and SwiftMQ). They haven't a JCA RA but a very good wrapper around the JMS stuff that handles the JTA enlistment etc. Since it is open source as well, you could use it at least as a template. -- Andreas * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66&thread=13848 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss JMS RA + SwiftMQ + Possible Problems
On 23 Apr, Jason Dillon wrote: > Hey, I have just started integrating SwiftMQ for use in my production > environment at work and by doing so I have notice d that we might have > some issues with the JMS RA. > > Clayton Wheeler responsed to a message I wrote in the SwiftMQ forums > with a document he wrote about getting it to work: > > http://culture.iridio.com/~csw/jboss-swiftmq/ > > I was hoping that the JMS folks (probably Peter since he wrote it, or > really anyone else familar with this stuff) could take a look at the > document and see if we can nail down some of the issues (like > connection.close() not closing sessions and finally drop the queue/ and > topic/ prefixes from being requirements of the system). Hi, I am currently under sever time contraints, so unfortunately I do not have the time to do the testing that is rquired to check new stuff in. Just yesterday I integrated SonicMQ into 2.4.3 and I have also seen a couple of things that needs to be done to ease integration. - JMS ContainerInvoker and DLQHandler need to be easier to subclass. - We must probably factor out the ConnectionConsumer stuff. - We must also see to it that StdServerSession and Pool are easy to sublcass, and at least factor out creation of StdServerSession - The DLQHandler must be configurable with a connectionfactory (JBossMQ only handles Messages from foraign provider if they are Serializable, wich is not part of the Message API. - topic and queue stuff from ContainerInvoker should be removed. This was added by the one who implemented automatic creation of destinations (which I oposed to). One way of doing this would be moving creation of destination out into the PrividerAdapter to make it possible to let also foraign providers create destinations on the fly (if the can handle this). As for the JMS RA. This is basically a hack. Not in the meaning bad code (I hope ;-)) but in that the spec for JCA is not designed for JMS. The stuff you take from the pool, is the stuff that is transacted. This works nice for db but not for JMS, since in JMS it is the session that is transacted and that should be pooled in the JCA adapter, but it is not a common idiom to directly get a session in JMS (which you can with the JCA adapter). The connection is just a cover up class, which basically do no JCA intercation. It's the session that do it. I could not come up with a good solution on this problem, except documenting how to use it. If someone can find a solution, pleas commit it. //Peter > > Anyone have some time to check this out and look over what needs to be done? > > Thanks, > > --jason > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development -- Peter AntmanChief Systems Architect, Business Development Technology in Media, Box 34105 100 26 Stockholm WWW: http://www.tim.se WWW: http://www.backsource.org Email: [EMAIL PROTECTED] Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss JMS RA + SwiftMQ + Possible Problems
Looking over the last bit of this doc about Xids and JBossTX... "JBossTX starts the global ID numbering from 1 each time it runs, so the global IDs are not very unique. Needless to say, this could stand some improvement." Why don't we use a org.jboss.util.id.UID or org.jboss.util.GUID here for better uniquness? Also, it refers to Tyrex, which has been integrated for a while. Does anyone know what the status of Tyrex is? Is it still being maintained? Is is a better TX manager? If so, why don't we make it the default? --jason * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66&thread=13848 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JBoss JMS RA + SwiftMQ + Possible Problems
Hey, I have just started integrating SwiftMQ for use in my production environment at work and by doing so I have notice d that we might have some issues with the JMS RA. Clayton Wheeler responsed to a message I wrote in the SwiftMQ forums with a document he wrote about getting it to work: http://culture.iridio.com/~csw/jboss-swiftmq/ I was hoping that the JMS folks (probably Peter since he wrote it, or really anyone else familar with this stuff) could take a look at the document and see if we can nail down some of the issues (like connection.close() not closing sessions and finally drop the queue/ and topic/ prefixes from being requirements of the system). Anyone have some time to check this out and look over what needs to be done? Thanks, --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
