Foreign JMS provider - How To?

[amueller]

Hello,

I'm Andreas Mueller from IIT (SwiftMQ). Many people have ask us in the past to provide ASF & XA and integrate it into JBoss. Well, I've been looking into JBoss today how SwiftMQ could be integrated (Chapter 8 wise). I must say that I'm a bit disappointed. I don't find any docs about it. When I look into the sources, I find some kind of adapter to obtain an InitialContext (JBossMQProvider). When I look into the StdServerSession.java I find JBossMQ specific code.

Are there any docs how to integrate a foreign JMS provider to use for ConnectionConsumer/XA?

For the ConnectionConsumer: Messages are received within an anonymous JMS session on SwiftMQ side. When the message is being delivered to a MDB, the message must be associated with the MDB's session context to ensure transactional integrity (the message is moved from the anonymous tx to the MDB's tx). Thus, there must be a callback from the container before calling onMessage at the MDB. How is this handled in JBoss? For example, Weblogic provides an interface a foreign JMS provider has to implement. This interface is used for the callback.

Are there any differences in JBoss 2.4.x vs. 3.0 concerning integration of JMS providers?

Thanks,
Andreas

[amueller]

Here is a link to a recent discussion in JMS-INT regarding ConnectionConsumer/MDB/Transactions:

http://swjscmail1.java.sun.com/cgi-bin/wa?A2=ind0108&L=jms-interest&D=0&P=6465

[pra]

> Hello,
>
> I'm Andreas Mueller from IIT (SwiftMQ). Many people
> have ask us in the past to provide ASF & XA and
> integrate it into JBoss. Well, I've been looking into
> JBoss today how SwiftMQ could be integrated (Chapter
> 8 wise). I must say that I'm a bit disappointed.

Don't be. JBoss is not only gratis it is also completly open and you don't have to understand more that maximum 4-5 classes to get how it works.
> I
> don't find any docs about it.

There is no point of documenting something that none of us has never done. Pleas contribute if you find stuff that needs docu.

>When I look into the
> sources, I find some kind of adapter to obtain an
> InitialContext (JBossMQProvider).

Jup, a simpe abstraction to abstract out two of the four JMS provider specific stuff in the JMS spec (JNDI config and names of connection factories). It is junior programming to create a new one that fits your provider. Look into org/jboss/jms/jndi.

> When I look into
> the StdServerSession.java I find JBossMQ specific
> code.

In 2.4.x there is no JBossMQ specific code that I know of, in 3.0 there is an optimaztion possibility if (dynamically) JBossMQ is discovered.

The is also a JBossMQ specific stuff in JMSContainerInvoker when it comes to dynamically creating destinations for MDB:s. But I am not responsible for that code, and it is easy to live without, just fill in your MDB:s correctly and see to it that your destinations exits.

From our perspective we have had a working ASF implementation in JBossMQ for almost a year and a MDB container based on ASF as long as that, without ANY provider specific code. No one has hierto proved that it does not work. Until someone does we will continue consider it working.
>
> Are there any docs how to integrate a foreign JMS
> provider to use for ConnectionConsumer/XA?
>

If uou have a correct ASF (chapter 8) impl, al you should have to do is implement a JMSProviderAdapter, configure a MBean provider factory to use it and configure your MDB:s to work againts that provider adapter.

But, you have to have a clean ASF implementation that works without any need to have special contracts (al la weblogic) with the container.

In my view the transaction is not the problem, but how to create your sessions.

When the Server session pool is created it will create a number of sessions from the connection. When the connection consumer get server sessions and then the session from the server session, it gets its own session and should know how to handle it. The crux is perhaps that the connection will have to leave out sessions it has no way to know will be used in a server session pool.

As for the transaction logic it should be fairly easy to follow how it is done. When the server session is run, it will fetch the XAResource from the XASession and enlist it with the transaction manager. And thats basically it.

> For the ConnectionConsumer: Messages are received
> within an anonymous JMS session on SwiftMQ side. When
> the message is being delivered to a MDB, the message
> must be associated with the MDB's session context to
> ensure transactional integrity (the message is moved
> from the anonymous tx to the MDB's tx).

Why? I don't understand this. Do you Hiram. An MDB has not transactional context outside of the JMS invocation. Why can the JMS XaSession XAResource not just be enlisted in the transactional context that will be created for the MDB?

However, I am not the TX expert here, Hiram is. Do you understand his problem?


//Peter
> Thus, there
> must be a callback from the container before calling
> onMessage at the MDB. How is this handled in JBoss?
> For example, Weblogic provides an interface a foreign
> JMS provider has to implement. This interface is used
> for the callback.
>
> Are there any differences in JBoss 2.4.x vs. 3.0
> concerning integration of JMS providers?
>
> Thanks,
> Andreas
>

[amueller]

> > For the ConnectionConsumer: Messages are received
> > within an anonymous JMS session on SwiftMQ side.
> When
> > the message is being delivered to a MDB, the
> message
> > must be associated with the MDB's session context
> to
> > ensure transactional integrity (the message is
> moved
> > from the anonymous tx to the MDB's tx).
>
> Why? I don't understand this. Do you Hiram. An MDB
> has not transactional context outside of the JMS
> invocation. Why can the JMS XaSession XAResource not
> just be enlisted in the transactional context that
> will be created for the MDB?

Read this to get an introduction:

http://swjscmail1.java.sun.com/cgi-bin/wa?A2=ind0108&L=jms-interest&D=0&P=6465

Andreas

[pra]

So what. Until you can prove our solution does not work I find it utterly unintersting. So, whats wrong with the current solution JBoss has? As I said, from our perspective we have had this working nicely for almost a year now.

As for the mail you are pointfing to I would say JBoss already have something aking to no 1 (the one weblogic longs to have).

We might offcource be wrong (fallible man) but for now I want prof first.

What is it that does NOT work in JBoss? What is not JMS or EJB 2.0 spec compliant. Tell us and we can discuss that.

//Peter

[amueller]

> So what. Until you can prove our solution does not
> work I find it utterly unintersting. So, whats wrong
> with the current solution JBoss has? As I said, from
> our perspective we have had this working nicely for
> almost a year now.

It's fine if it works with JBossMQ. But I don't speak about JBossMQ. I speak about SwiftMQ [and SonicMQ/MQSeries].

> As for the mail you are pointfing to I would say
> JBoss already have something aking to no 1 (the one
> weblogic longs to have).

#1 means that the JMS provider has an own transaction manager (it starts the transaction) and the flow goes with the call. You need RMI/IIOP for this. I assume that you have nothing out of the 3 mentioned points.

I guess that the whole problematic isn't clear at all for you so you should rethink it. Read the whole thread on JMS-INT. I were also in doubth at some point there.

> We might offcource be wrong (fallible man) but for
> now I want prof first.
>
> What is it that does NOT work in JBoss? What is not
> JMS or EJB 2.0 spec compliant. Tell us and we can
> discuss that.

I simply miss a clear and stable interface for foreign JMS providers which respects the transactional problematic mentioned in the link to the discussion in JMS-INT and I don't want to contribute to JBoss! I don't want to read a single line of your source code either! That's the issue.

What you guys should think about is whether you like to integrate foreign JMS providers ASF/XA-wise or not. It does not work like "do you miss one, make one". If you like to do that, you must define a clear and stable interface, which survives major releases of JBoss. Otherwise it's too costly and nobody will support it.

Call me back if you have such an interface.

Bye,
Andreas

[pra]

> > So what. Until you can prove our solution does not
> > work I find it utterly unintersting. So, whats
> wrong
> > with the current solution JBoss has? As I said,
> from
> > our perspective we have had this working nicely
> for
> > almost a year now.
>
> It's fine if it works with JBossMQ. But I don't speak
> about JBossMQ. I speak about SwiftMQ [and
> SonicMQ/MQSeries].

But you have not presented one single line of evidence of what is not working. You only try to get me working blindly on something that does not interest me the least.
>
> > As for the mail you are pointfing to I would say
> > JBoss already have something aking to no 1 (the
> one
> > weblogic longs to have).
>
> #1 means that the JMS provider has an own transaction
> manager (it starts the transaction) and the flow goes
> with the call. You need RMI/IIOP for this.

Why? There is absolutely not requirements what wire protocoll the JMS provider uses. This is actually Hiram turf, but a JMS session is just one resource of many possible that will get added to the transaction manager. The JMS provider must have a backing implementation to handle this. JBossMQ obviously have, if you need to learn how to do this: read the code!
> I assume
> that you have nothing out of the 3 mentioned points.
>
> I guess that the whole problematic isn't clear at all
> for you so you should rethink it. Read the whole
> thread on JMS-INT. I were also in doubth at some
> point there.
>
> > We might offcource be wrong (fallible man) but for
> > now I want prof first.
> >
> > What is it that does NOT work in JBoss? What is
> not
> > JMS or EJB 2.0 spec compliant. Tell us and we can
> > discuss that.
>
> I simply miss a clear and stable interface for
> foreign JMS providers which respects the
> transactional problematic mentioned in the link to
> the discussion in JMS-INT and I don't want to
> contribute to JBoss! I don't want to read a single
> line of your source code either! That's the issue.
>

Again. Tell us what is not working in JBoss, and dont point with your hand at abstract and generall discussions.

> What you guys should think about is whether you like
> to integrate foreign JMS providers ASF/XA-wise or
> not. It does not work like "do you miss one, make
> one". If you like to do that, you must define a clear
> and stable interface, which survives major releases
> of JBoss. Otherwise it's too costly and nobody will
> support it.

No, this is NOT the way it work. If someone is interested in such an integration he has to do it him self. Personally I am totally uniterested in closed source solutions (the worse there is is gratis but closed, ugh).

Either vendors do it since they want to take part in the biggest J2EE success ever: JBoss. JBoss is now taking over the education turf for J2EE - 1000 and 1000 new programmers will start their J2EE life with JBoss. Be a part of it or don't. It's your choice. Not ours.

If you come up with real problems we will help you. As long as you only spread FUD we will not.

An remmber this: JBossMQ and JBoss MDB does not have an internal knowledge of each other. No hiden interface, no nothing. But it works, it follows the specs. What does that say me: There is not need for other interfaces if you have done your stuff correct.

To make me or Hiram or anyone else to start working on "a stable non spec comliant callback interface" you have to show us why and it what wat it is not possible to integrate JMS and a MDB container by only following the spec. And don't prove it by pointing to longish mail. Prove it by poiting out why what is obviously working should not be working.

//Peter
>
> Call me back if you have such an interface.
>
> Bye,
> Andreas

[hchirino]

> > For the ConnectionConsumer: Messages are received
> > within an anonymous JMS session on SwiftMQ side.
> When
> > the message is being delivered to a MDB, the
> message
> > must be associated with the MDB's session context
> to
> > ensure transactional integrity (the message is
> moved
> > from the anonymous tx to the MDB's tx).
>
> Why? I don't understand this. Do you Hiram. An MDB
> has not transactional context outside of the JMS
> invocation. Why can the JMS XaSession XAResource not
> just be enlisted in the transactional context that
> will be created for the MDB?
>
> However, I am not the TX expert here, Hiram is. Do
> you understand his problem?
>

I don't understand the big deal either. WE DO THE CALLBACK! Find to StdServerSession.java. This is JBoss's ServerSession implementation. Per spec, the ServerSession is started() once the JMS Session is loaded with 1+ messages. Our StdServerSession.start() calls StdServerSession.run(). It is in our run() that we do that Call Back you want. It occurs at:


// Use the TM to control the TX
tm.begin();
trans = tm.getTransaction();

if (xaSession != null)
{
XAResource res = xaSession.getXAResource();
trans.enlistResource(res);
if (log.isDebugEnabled())
{
log.debug("XAResource '" + res + "' enlisted.");
}
}

Right there in the run(), the container enlists the session's tx into the TranscationManager's current transation.

Is there a problem with this??? Can SwiftMQ handle this??

As you can tell there is no JBossMQ specific code there. The JBossMQ specific stuff you see in there is only used if the Provider being used is JBossMQ.

Regards,
Hiram

>
> //Peter
> > Thus, there
> > must be a callback from the container before
> calling
> > onMessage at the MDB. How is this handled in
> JBoss?
> > For example, Weblogic provides an interface a
> foreign
> > JMS provider has to implement. This interface is
> used
> > for the callback.
> >
> > Are there any differences in JBoss 2.4.x vs. 3.0
> > concerning integration of JMS providers?
> >
> > Thanks,
> > Andreas
> >
>

[pra]

Thanks Hiram, this was excatly my view to.

Do you know what I think they are having problem with: their own session management (which goes for SonicMQ to). They have not fixed the problem where ther will be sessions created from the connection in ServerSessionPool before the ConnectionCosumer has been created. Therefore they are not able to colocate their sessions in the consumer with the sessions returned from the ServerSession. Well, just a guess.

//Peter

[amueller]

> I don't understand the big deal either. WE DO THE
> CALLBACK! Find to StdServerSession.java. This is
> JBoss's ServerSession implementation. Per spec, the
> ServerSession is started() once the JMS Session is
> loaded with 1+ messages. Our
> StdServerSession.start() calls
> StdServerSession.run(). It is in our run() that we
> do that Call Back you want. It occurs at:
>
>
> // Use the TM to control the TX
> tm.begin();
> trans = tm.getTransaction();
>
> if (xaSession != null)
> {
> XAResource res =
> Resource res = xaSession.getXAResource();
> trans.enlistResource(res);
> if (log.isDebugEnabled())
> {
> log.debug("XAResource '" + res + "'
> rce '" + res + "' enlisted.");
> }
> }
>
> Right there in the run(), the container enlists the
> session's tx into the TranscationManager's current
> transation.

That works only under these 2 assumptions:

1) You always process exactly 1 message.
2) You assume that the JMS provider assigns a message to a transaction, delivered before the transaction has been started.

To process > 1 message, a transaction must be started for each message, hence, before you call onMessage and not in the run method of your server session. The container must ensure that the message which leads to the transaction becomes part of it. Thus, the container must tell the resource manager to assign the message to the transaction before onMessage is invoked.

There are 2 ways to implement it:

1) The JMS provider's session must implement a callback interface and will be called while onMessage is called. The session's message listener is basically a wrapper from the container, taking care of transaction start and call back and invokes the 'real' message listener. This is the approach BEA does.

2) We pass a new XAResource for every message which does the assignment behind the scenes when res.start() is called during the enlistment.

In any case, you have to start the transaction when the session's message listener's onMessage is called.

Cheers,
Andreas

[amueller]

> Thanks Hiram, this was excatly my view to.
>
> Do you know what I think they are having problem
> with: their own session management (which goes for
> SonicMQ to). They have not fixed the problem where
> ther will be sessions created from the connection in
> ServerSessionPool before the ConnectionCosumer has
> been created. Therefore they are not able to colocate
> their sessions in the consumer with the sessions
> returned from the ServerSession. Well, just a guess.

That's wrong, buddy. It does only show your bad thoughts.

The truth is that we are in the process of implementation of that stuff and I am dicovering candidates for an easy integration. But as you know already, JBoss failed.

[pra]

I will know it when you explain it. As said before, it works between JBossMQ and JBoss MDB container without any explicit contract. But since it's a gray area in the spec, yes, if interpreted differently it might not work. As for the TX stuff, I hope you can sort it out with Hiram.

Shers ;-)

//Peter

[pra]

> To process > 1 message, a transaction must be started
> for each message, hence, before you call onMessage
> and not in the run method of your server session. The
> container must ensure that the message which
> leads to the transaction becomes part of it. Thus,
> the container must tell the resource manager
> to assign the message to the transaction before
> onMessage is invoked.
>

Ok, now we are talking. You actually got me to read the JMS spec again (parts of it ;-)). My idea of the spec is that all that is needed should be there, and if it is not, solutions should be based on what's in the spec, not by inventing provider specific solution. Then could we possibly agree on the following.

- A transacted session may handle several messages in one transaction. p. 58 (4.4.7), i.e a message listener connected to a transacted session can chose to receive several messages before comitting; comitting starts a new transaction.

- For sessions required through a server session pool the spec only says the provider is allowed to stuff (in a provider specific way) more messages into the session. But it does not say anything about the transactional integrety.

There is a loophole here I admit: "The JMS provider retains control of its messages until they are delivered to the MessageListener. This ensures it is under direct control of message acknowledgement" (p. 85).

But this is only a loophole if you assume that a session stuffed with several messages should be able to have one transaction for each message. There is nothing in the spec that point in that direction, what I can see.

Instead we have a spec that says that several messages may be delivered in one transaction and a spec that leaves the appserver with only one last way to actually controll the transaction before the session is run (ASF). This would instead lead me to the following conclusion:

When several messages is stuffed into a session they will run under the same transaction, and either all wil be sucessfully delivered or not at all. And the provider MUST assume that it is enrolled in a transaction manager just before session.run() is called.

This is the way JBoss work, and I would say it is spec compliant in all explicit parts and it interprets all gray areas as implicating only a spec compliant solution. I still think that JBoss does it right here.

I do admit that there might be some unexpected side effect for the user swith this behaviour: But I do think that's the reason you have to set the maximum number of messages that a consumer is allowed to stuff into a session in the constructor of the consumer.

I also have to admit I did not considered this that much. If I remember correctly the max messages is rather large in JBoss by default and it is not ducumented as a switch that will cluster the max messages under a single transaction (wich would be a nice optimization - or what do you say Hiram?). Therefore I would say that the default max messages should be set to 1 and be documented for what it is: a way of receiving multiple messages under one transaction.

I am happy to receive your response on this interpretation since I am somewhat biased since it follows the logic of my first interpretation of the spec and the implementation of the JBoss container.

I am also happy you pointed this gray area out, and I am sorry if my tone has been somwhat hard at times.

//Peter
> There are 2 ways to implement it:
>
> 1) The JMS provider's session must implement a
> callback interface and will be called while onMessage
> is called. The session's message listener is
> basically a wrapper from the container, taking care
> of transaction start and call back and invokes the
> 'real' message listener. This is the approach BEA
> does.
>
> 2) We pass a new XAResource for every message which
> does the assignment behind the scenes when
> res.start() is called during the enlistment.
>
> In any case, you have to start the transaction when
> the session's message listener's onMessage is
> called.
>
> Cheers,
> Andreas

[amueller]

> When several messages is stuffed into a session they
> will run under the same transaction, and either all
> wil be sucessfully delivered or not at all. And the
> provider MUST assume that it is enrolled in a
> transaction manager just before session.run() is
> called.

A half year ago or so I struggled with the same thing and I had asked Joe Fialli, the JMS lead from Sun. He told me that the JMS spec was created before the EJB spec was in mind. Therefore, for MDBs, you have to take the EJB 2.0 spec which states that a MDB, if transacted at all, is covered by a transaction message by message.

Because it's container responsibility, it must ensure that, may be due to proprietary interfaces or due to a specified behavior. The JMS RI, for example, has 2 proprietary callbacks, before/afterMessageDelivery (or the like). They have a JMS SPI where you can plug-in your JMS server, if you like to become a J2EE licensee, for example. Then run the CTS against it.

MDB is, btw, NOT dependent on ASF at all. You can map the whole thing on your side on plain JMS functionality (connections/sessions/consumer). Orion drives MDBs with SwiftMQ that way. I don't know at the moment whether another ack-mode than auto-ack can be used when the session is non-transacted. I haven't seen this part in the JBoss code. But if this is possible, the container is responsible for the acknowledgement (client/lazy ack-mode).

If I had the task to design/implement this interface in JBoss, I would do it as generic as possible. I get a connection factory from JNDI and then I can look if that is an XA-CF or not and can create the binding somewhat dynamically. Then I can integrate whatever is there (MQSeries, Sonic (just create the sessions after the connection consumer, because it's before you start the connection), SwiftMQ, Tib/JMS, ...). The result is: the popularity of JBoss goes up! ;-)

> I am also happy you pointed this gray area out, and I
> am sorry if my tone has been somwhat hard at times.

No problem, it took me only 2 hours with my pysichatrist to get over that... :-)

Andreas

[pra]

> > When several messages is stuffed into a session
> they
> > will run under the same transaction, and either
> all
> > wil be sucessfully delivered or not at all. And
> the
> > provider MUST assume that it is enrolled in a
> > transaction manager just before session.run() is
> > called.
>
> A half year ago or so I struggled with the same thing
> and I had asked Joe Fialli, the JMS lead from Sun. He
> told me that the JMS spec was created before the EJB
> spec was in mind. Therefore, for MDBs, you have to
> take the EJB 2.0 spec which states that a MDB, if
> transacted at all, is covered by a transaction
> message by message.

OK, you've got me. It's true: section 17.6.3.2 says what you say. JBoss is not fully spec compliant if you use it at is maximum. What we have to do is to downspec the maxMessages to 1 when we create the connection consumers. Then we are fully spec compliant again ;-) Thanks.
>
> MDB is, btw, NOT dependent on ASF at all.
Yupp, I know. But I happen to simply love standards and specs and what's there already. ASF was in my view the only spec available to do it. But as you say: then you are only allowed to stuff one message at a time into the session (which is actually what JBossMQ does today, as far as I know).

> You can map
> the whole thing on your side on plain JMS
> functionality (connections/sessions/consumer). Orion
> drives MDBs with SwiftMQ that way. I don't know at
> the moment whether another ack-mode than auto-ack can
> be used when the session is non-transacted. I haven't
> seen this part in the JBoss code. But if this is
> possible, the container is responsible for the
> acknowledgement (client/lazy ack-mode).

We had that first (multiple messages in one ack), but removed it.

>
> If I had the task to design/implement this interface
> in JBoss, I would do it as generic as possible. I get
> a connection factory from JNDI and then I can look if
> that is an XA-CF or not and can create the binding
> somewhat dynamically. Then I can integrate whatever
> is there (MQSeries, Sonic (just create the sessions
> after the connection consumer, because it's before
> you start the connection), SwiftMQ, Tib/JMS, ...).
> The result is: the popularity of JBoss goes up! ;-)
>

But hey, this is they way it works today. I would say this: If we only change the maxMessages to one, any "spec compliant" - I qoutw it here since as we have seen there are gray areas in the spec and only if you fully interpret it in the spirit of the spec will it work - provider should work. And I dare to say - ;-) - if it does not work either the provider or we have not followed the spec, and should adhere to it.

I may agree that it would be nice to be able to stuff more messages into the session for performance reason - and for that scenario I now agree that a callback is needed.

But I do not think I will implement it. In that regard I think I prefer to wait for the connector 2.0 spec that will have sorted this out (I hope). If you need a callback for Swift, please contribute one and we will integrate it if it does not disrupte what is already working.

> > I am also happy you pointed this gray area out, and
> I
> > am sorry if my tone has been somwhat hard at
> times.
>
> No problem, it took me only 2 hours with my
> pysichatrist to get over that... :-)


No hard feelings then - or is he expensive ;-) I have to admit I really liked it when you got the the point, cause you had a point.

//Peter
>
> Andreas