JBossDeveloper

I commited the changes that you sent me. It's working now in the CVS head!

Regards,
Hiram

The changes are only int the 3.x HEAD branch.

As for the error, a stack trace (w/ line numbers) would be nice so I can trace the error down to the lookup() call that's causing the error.

Regards,
Hiram

> Hi Hiram,
>
> fortunately you are wrong -- the changes are in 2.4.4
> as well! I've downloaded the sources today.
>

Wow, those backporter work faster than I thought! Great!

> I have successfully integrated SwiftMQ 3.0.0 XA/ASF
> into 2.4.4. It works just fine without any changes on
> our side.
>

Good to hear.

> Here are some minor issues I have detected during
> integration:
>
> 1. You don't use the topic/queue name specified in
> the xml. You always prefix that with "topic/" resp.
> "queue/". That's JBossMQ specific. You should use the
> names from the xml. Lucky to me, one can define a
> JNDI alias in SwiftMQ so the lookup succeeds.
>

Yep, this seem like a bug we should fix. Post this request to the jboss-dev mailing list since the fix would break some compatibility with previous mdb deployment descriptors. I'm for the fix.

> 2. The DLQ handling doesn't use the InitialContext of
> the JMS provider but simply InitialContext(), hence
> the JNP naming provider. I had to remove the DLQ
> stuff out of standardjboss.xml to get that work (this
> was the error from my prev. post, btw).
>

Once again this seem like a design bug. I'll look into fixing this later in the week. It should be getting the InitialContext via the JMSProviderAdapter.getInitialContext() method.

> 3. DurableConnectionConsumer doesn't work. A durable
> subscription is identified through
> clientid+durablename. You don't set the clientId so
> SwiftMQ generates a random one. Therefore, you never
> will reconnect to the durable but create a new one
> every time. Just set the clientId as the first method
> call just after creating the connection.
>

I've never tested this myself so I can't really help you here. If you identify how to fix this and submit a patch (this also goes for any of the above problems too) for it, I'll look into merging it into the CVS.

> The XA stuff works great!
>

Glad it works,
Hiram!

> That's it!
>
> Thanks,
> Andreas

Hi back again from Thailand, severely jetlagged...

> > Hi Hiram,
> >
> > fortunately you are wrong -- the changes are in
> 2.4.4
> > as well! I've downloaded the sources today.
> >
>
> Wow, those backporter work faster than I thought!
> Great!
>
> > I have successfully integrated SwiftMQ 3.0.0
> XA/ASF
> > into 2.4.4. It works just fine without any changes
> on
> > our side.
> >
>
> Good to hear.
>
> > Here are some minor issues I have detected during
> > integration:
> >
> > 1. You don't use the topic/queue name specified in
> > the xml. You always prefix that with "topic/"
> resp.
> > "queue/". That's JBossMQ specific. You should use
> the
> > names from the xml. Lucky to me, one can define a
> > JNDI alias in SwiftMQ so the lookup succeeds.
> >
>
> Yep, this seem like a bug we should fix. Post this
> request to the jboss-dev mailing list since the fix
> would break some compatibility with previous mdb
> deployment descriptors. I'm for the fix.
>

Me to. It was this autocreation stuff - that we opposed - that broke it. It is still a fact that the auto creation stuff will be unportable.

> > 2. The DLQ handling doesn't use the InitialContext
> of
> > the JMS provider but simply InitialContext(),
> hence
> > the JNP naming provider. I had to remove the DLQ
> > stuff out of standardjboss.xml to get that work
> (this
> > was the error from my prev. post, btw).
> >
>
> Once again this seem like a design bug. I'll look
> into fixing this later in the week. It should be
> getting the InitialContext via the
> JMSProviderAdapter.getInitialContext() method.

Yea, maybe. At the time I did it I thought the whole MDB layer was heading in a fairly unportable direction and no one seemed to use it with any other server. I was also not shure at the time if I really could make a portable message copy function. This should be fairly easy to change - but at least I did ad the possibility to remove the DLQ handler before tha XA changes was comitted ;-)
>
> > 3. DurableConnectionConsumer doesn't work. A
> durable
> > subscription is identified through
> > clientid+durablename. You don't set the clientId
> so
> > SwiftMQ generates a random one. Therefore, you
> never
> > will reconnect to the durable but create a new one
> > every time. Just set the clientId as the first
> method
> > call just after creating the connection.
> >
>
> I've never tested this myself so I can't really help
> you here. If you identify how to fix this and submit
> a patch (this also goes for any of the above problems
> too) for it, I'll look into merging it into the CVS.
>

Well, I have to admit I am not shure that JBossMQ handles the durable stuff correct. From the discussion we had a year ago I derived the functionality thats there now: define a user with a client id, log in as that user and use the client id as the subscription name.

Reading the JMS API and tutorial again it looks more like it should work like this:

1. Either define a client specific factory through an admin interface (this connect a connection with a specific clientID) or let the user set the clientId.

2. Let users dynalically create and delete durable subscriptions by naming them with a subscription name.

Hiram, is the user-clientId binding actually an implementation of (1)? I do not think that the requirement to actually have to authenticate to get a particular clientId - if that is the case - is fully spec compliant.

Will there be dynamic creation of durable subscriptions though the subscription name today, i.e can we use other name for the subsriptionName than the clientId?

Andreas, do you have an administartiv interface to create a specific factory that is connected to a specific clientId - as is the JMS tutorial?

> > The XA stuff works great!

;-)

//Peter
> >
>
> Glad it works,
> Hiram!
>
> > That's it!
> >
> > Thanks,
> > Andreas
>

> Thanks again for the changes you made. I have some
> frustrating weeks behind me trying to integrate
> MDB/XA in 7-8 app servers. It was terrible! NO other
> (except Pramati which I'm checking right now) is able
> to integrate a foreign JMS provider to drive MDBs
> with XA. Neither WLS, nor HPAS, nor Orion. They all
> do it plain JMS or in some faked-XA manner
> (simulating XA). So JBoss is the only app server
> around to plug-in an XA-capable JMS provider!

Pretty god result from a bad start ;-)

I or Hiram will make the changes ( I will keep out of CVS wri8te a couple of days until my jetlag has disolved - just now I do not even feel rational).

//Peter
>
> Cheers,
> Andreas

>
> Well, I have to admit I am not shure that JBossMQ
> handles the durable stuff correct. From the
> discussion we had a year ago I derived the
> functionality thats there now: define a user with a
> client id, log in as that user and use the client id
> as the subscription name.
>

Uhmmm.. we must have had a miss-connect. UserId/password connection assigns the client id to the connection. You can then use any subscription name that is configured for that with the clientId.

> Reading the JMS API and tutorial again it looks more
> like it should work like this:
>
> 1. Either define a client specific factory through an
> admin interface (this connect a connection with a
> specific clientID) or let the user set the clientId.
>
> 2. Let users dynalically create and delete durable
> subscriptions by naming them with a subscription
> name.
>
> Hiram, is the user-clientId binding actually an
> implementation of (1)? I do not think that the
> requirement to actually have to authenticate to get a
> particular clientId - if that is the case - is fully
> spec compliant.
>

Yes it is to spec. The spec says that once logged in via a userid/password the provider can assign the clientId to the connection. So the user should not try to assign the clientID as it is allready assigned. Thats how we do it in JBossMQ.

> Will there be dynamic creation of durable
> subscriptions though the subscription name today, i.e
> can we use other name for the subsriptionName than
> the clientId?
>

Yes the subscription id can be diffent.
Since I applied Andreas's chanages, I also changed the way subscriptions are started. The jboss.xml now has a <mdb-subscription-id> tag that should hold the subscription id (it now has nothing to do with the client id).

Regards,
Hiram

Great Hiram!

//Peter

Does it also work with SwiftMQ 2.1.3? Could you post the working configuration files somewhere.

This was great to see, two teams start off with a large distance between them and then converge!

Thanks for everyone's help