JBoss and SonicMQ

[fracalde]

Hello,
I am trying to integrate SonicMQ into JBoss as JMS
provider. I almost managed to do that but I still get
a JMS exception as soon as I deploy more than one MDB :
______________________________________________________
[Container factory] Serious error in init: javax.jms.JMSException: [129] progress.message.client.EUserAlreadyConnected: 8884927054856847360
[Container factory] java.lang.Exception: javax.jms.JMSException: [129] progress.message.client.EUserAlreadyConnected: 8884927054856847360
[Container factory] at org.jboss.ejb.MessageDrivenContainer.init(MessageDrivenContainer.java:173)
[Container factory] at org.jboss.ejb.Application.init(Application.java:202)
[Container factory] at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:372)
[Container factory] at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:304)
[Container factory] at java.lang.reflect.Method.invoke(Native Method)
[Container factory] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628)
[Container factory] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
[Container factory] at org.jboss.deployment.J2eeDeployer.startModules(J2eeDeployer.java:486)
[Container factory] at org.jboss.deployment.J2eeDeployer.startApplication(J2eeDeployer.java:464)
[Container factory] at org.jboss.deployment.J2eeDeployer.deploy(J2eeDeployer.java:208)
[Container factory] at java.lang.reflect.Method.invoke(Native Method)
[Container factory] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628)
[Container factory] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
[Container factory] at org.jboss.ejb.AutoDeployer.deploy(AutoDeployer.java:379)
[Container factory] at org.jboss.ejb.AutoDeployer.run(AutoDeployer.java:217)
[Container factory] at java.lang.Thread.run(Unknown Source)
[J2EE Deployer Default] Starting connectioncontroller.jar failed!
_____________________________________________________


Do you have an idea about that ??

Regards,
Francesco.

[pra]

Do they really have a functional ASF (chapter 8, jms spec) implementation. I thought not.

//Peter

[marc.fleury]

They don't have the ASF last I heard,

use JBossMQ it is really fast in 1.0 and really stable

[fracalde]

Hi Peter,
yes they actually claim they implement message consumers
and server session pools in their latest SonicMQ3.5 version. They also support transactions via the XA specification.

Cheers,
Francesco.

[fracalde]

Hi Marc,

yes, they implement ASF as far as they say in their latest SonicMQ3.5 release, the one I am just trying
to plug into JBoss 2.4.

Cheers,
Francesco.

[pra]

Marc, marc, have we done something wrong with marketing. From latest SonicMQ release:

"SonicMQ 3.5 is the only Java Message Service (JMS?) message server that includes a XAResource API to provide guaranteed end-to-end transactional integrity. The XAResource API works in conjunction with a transaction manager to implement the standard protocol for two-phase commit. With these industrial strength capabilities, SonicMQ 3.5 ensures that any two dependent transactions are atomic, consistent, isolated and durable until completion. By adding support for the JTA (Java Transaction Protocol API) and the XAResource API, SonicMQ becomes the only JMS product to offer standard robust transactional capabilities to JMS as defined by J2EE."

And we have had XA support since december/january!!

//Peter

[pra]

Hi,
if anyone is really interested to check if SonicMQ is possible to integrate, one of the things that has to be done is check if their implementation really work and follows the spec. I problem is that the spec is not crystal clear, and for a App server vendo to implement ServerSessionPool one has to interpret the spec.

I think we have done the right interpretation, but SonicMQ may have done anotherone (when I talked to David at sonic 6 month ago he said it was not possible to implement the ASF ;-))

If anyone is interested my old mail that started the ASF supoort in JBoss (we was the first, not sonic, BASTA) is available here:

http://www.backsource.org/source/java/jms-ejb/JMS-ASF-mail.txt

//Peter

[marc.fleury]

THAT REALLY PISSES ME OFF

Dumb marketeer claiming "we were the first!" NO WE WERE THE FIRSTS AND BY *****6****** FUCKING MONTHS!!!!!!!

You know what I am about to finish the development of the RH and then I will reinvent myself in CEO/Marketeer I have had enough of the bullshit. Like "young" from Lutris/Enhydra and the folks there telling SUN "JBOSS sucks, Enhydra is better" IF THEY ONLY KNEW HOW BAD THEIR FUCKING CODE IS!!!!!! BUNCH OF FUCKING MORONS!!!!
WE HAVE BEEN ASKING SONIC FOR ASF INTEGRATION FOR 6 MONTH AND THEY ALWAYS SAID "NOPE" AND NOW THEY CLAIM "WE HAVE IT !!!! FIRST!"... RIDICULOUS! MAKE SURE TO BLAST THEM ON THE MQ PAGE, PLEASE!

I will build a company out of this, I will make this work, and I won't tolerate that kind of bullshit any longer.

Peter, you have RW and the first thing you can do is update the JMS page, noone does and you are good about thenews thing if I remember correctly.

My sincerest apologies for not pushing more on the marketing and commercial side, it will change soon.

[pra]

I do not blame any one, not you, not even my self ;-). I actually do think that weblogic was there before us if I remember correct, but they do not have a standalone JMS provider.

But it is really iritating. I remember sitting there sipping on my bear and talking to Dave Shapell (yes thats him, technical leader/evangelist at sonic and co author of the JMS book) about MDB, ASF and XA, and he told me about their integreation work with some comercial EJB vendors where they had built a custom/proprietary integration layer becaus ASF would not work. And I know he asked me for my bussines card when I told him we already had done it ;-) Bugger!.

But Marc, I really do not know what to put up on the JMS page. I was a journalist, you know, not a marketer ;-)

Go for it Marc and thanks for al your great work (ejboss 0.3 was probably the first version I downloaded, it feels as if a lot of water has flown under the bridges since then ;-))

//Peter

[boca007]

I have had the same problem, a simple work-around is to set up SonicMQ for security and have unique users for each bean. Use <mdb-user> and <mdb-passwd> tags in jboss.xml deployment descriptor.

But this only works with non-XA connections. If you use XAConnections the ConnectionConsumer will refuse to start due to: "The session and connection consumer must be created from the same connection". This beats me.

Since I'm a few months late, perhaps someone has solved this?

Bo Carlsson

[amueller]

> Hi,
> if anyone is really interested to check if SonicMQ is
> possible to integrate, one of the things that has to
> be done is check if their implementation really work
> and follows the spec. I problem is that the spec is
> not crystal clear, and for a App server vendo to
> implement ServerSessionPool one has to interpret the
> spec.

It works and it follows the spec, believe me. However, the interface between container and JMS provider is unspecified. There is a transaction flow problem which has to be addressed (see my other post).

In that post I asked about a way of integrating a foreign JMS server (SwiftMQ in this case). I haven't received a reply and it seems there is no other way than to dive deep into the jboss sources.

That's simply too much effort for *one* app server. There are several others which have a clean interface to plug in a JMS provider (see MDBTransaction in WLS, for example). They are all different but they are clean. Hence, JBoss will not be our choice until JCA 2.0. We will probably try the HP-AS in Q1 for XA/ASF or may be WLS.

Andreas

[pra]

Hey, soo you will start pissing me of. Stop spredding your FUD around here. Present you prof first of what is not working and why it is our fault.

From the Sonic errors reported here I would say they have made it wrong. A lot of talk: but we wants code, errors, specification references.

And remember: it is not our work to integrate comercial JMS providers. It is not our work to do anyting at all. We do what we love: create open source code at our spare time. If you need more that that, contribute it your self. The source is there to understand, learn from, admire, scrutinize and critisize. But don't whine.

//Peter

[amueller]

> Hey, soo you will start pissing me of. Stop spredding
> your FUD around here. Present you prof first of what
> is not working and why it is our fault.
>
> From the Sonic errors reported here I would say they
> have made it wrong. A lot of talk: but we wants code,
> errors, specification references.

The Sonic errors show me that you have a) created multiple connections with the same client id and b) that the sessions and the connection consumer have different connections. a) is wrong at your side and I guess it is caused from connection pooling. b) is the result of the unspecified contract between container and JMS provider but I would say that sessions/cc must use the same connection. At least it should be configurable. But since the only JMS provider you can handle is your own, it's not possible.

> And remember: it is not our work to integrate
> comercial JMS providers.

I have understand that. Then you and your users must live with JBossMQ.

> It is not our work to do
> anyting at all. We do what we love: create open
> source code at our spare time. If you need more that
> that, contribute it your self. The source is there to
> understand, learn from, admire, scrutinize and
> critisize. But don't whine.

Sorry, sniff. I had the false impression to have a chance to talk to someone which understands the transaction flow problematic and can point out how it is handled in JBoss. Instead I got flamed from an aggressive melanomaniac guy, dreaming to hack the 'biggest J2EE success ever' in spare time on a 'need it, hack it' base. That's funny!

EOD.

[pra]

> > Hey, soo you will start pissing me of. Stop
> spredding
> > your FUD around here. Present you prof first of
> what
> > is not working and why it is our fault.
> >
> > From the Sonic errors reported here I would say
> they
> > have made it wrong. A lot of talk: but we wants
> code,
> > errors, specification references.
>
> The Sonic errors show me that you have a) created
> multiple connections with the same client id and b)
> that the sessions and the connection consumer have
> different connections. a) is wrong at your side and I
> guess it is caused from connection pooling. b) is the
> result of the unspecified contract between container
> and JMS provider but I would say that sessions/cc
> must use the same connection. At least it should be
> configurable. But since the only JMS provider you can
> handle is your own, it's not possible.

This is so funny, but at least now you try to get up with something concrete. Theses stuff says you a lot, but you do not look into the code. No, we are not using different connections. I would think the problem is that Sonic does not correctly handle the fact that the sessions returned from the ServerSession was created against the connection before the ConnectionConsumer was created from it, and that these sessions is pooled. But this is, according to my interpretation, the only way to do it spec compliant.

See my old mail on how I once interpreted the ServerSession stuff: http://www.backsource.org/source/java/jms-ejb/JMS-ASF-mail.txt
>
> > And remember: it is not our work to integrate
> > comercial JMS providers.
>
> I have understand that. Then you and your users must
> live with JBossMQ.

Yes, if not a user or a vendors steps forward and does it. I was once a JBoss user that needed MDB. Instead og whining I did it myself, for better or for worse.

>
> > It is not our work to do
> > anyting at all. We do what we love: create open
> > source code at our spare time. If you need more
> that
> > that, contribute it your self. The source is there
> to
> > understand, learn from, admire, scrutinize and
> > critisize. But don't whine.
>
> Sorry, sniff. I had the false impression to have a
> chance to talk to someone which understands the
> transaction flow problematic and can point out how it
> is handled in JBoss.

It is 10 to 20 line in the source code, dude...

>Instead I got flamed from an
> aggressive melanomaniac guy, dreaming to hack the
> 'biggest J2EE success ever' in spare time on a 'need
> it, hack it' base. That's funny!

Ain't it ;-)

I have only written, what 5 mails, asking to to step formward and present your problem in a concrete way. But you only keep telling us that we have made it wrong and that it does not work. No more. Verry hard to help then (and it's not even me that wrote the transaction code).

Hope you have success with your product ;-)

//Peter

No one has hierto come forward and told us how they did their integration, but as far as we have heard MQSeries and spirit-soft JMS product have been sucessfully integrated with JBoss MDB.
>
> EOD.

[boca007]

Here is something concrete, although I'll spare you the source of the ProviderAdapter which I believe is not relevant.

A few pieces from the startup sections of my server.log.

First, a connection and session pool for GenericJMSBean is created:

:
[JMSContainerInvoker] context: javax.naming.InitialContext@6963d0
[JMSContainerInvoker] jndiSuffix: FhntStor
[JMSContainerInvoker] Got destination type Queue for GenericJMSBean
[ConnectionFactoryHelper] using connection factory: progress.message.jclient.xa.XAQueueConnectionFactory@4eb043
[ConnectionFactoryHelper] using username/password: poe/poe
[ConnectionFactoryHelper] created XAQueueConnection: progress.message.jclient.xa.XAQueueConnection@7864fe
[JMSContainerInvoker] looking up session pool factory: java:/StdJMSPool
[StdServerSessionPool] initializing with connection: progress.message.jclient.xa.XAQueueConnection@7864fe
[StdServerSessionPool] setting session listener: org.jboss.ejb.plugins.jms.JMSContainerInvoker$MessageListenerImpl@497904
[StdServerSession] initializing (pool, session, xaSession): org.jboss.jms.asf.StdServerSessionPool@4e28b, progress.message.jclient.QueueSession@354362, progress.message.jclient.xa.XAQueueSession@5b0e2c
[StdServerSessionPool] added server session to the pool: org.jboss.jms.asf.StdServerSession@7f9053
:

This is repeated for 15 sessions.

Next, a new connection and pool for NotisBean:

:
[JMSContainerInvoker] context: javax.naming.InitialContext@6963d0
[JMSContainerInvoker] jndiSuffix: FhntNotis
[JMSContainerInvoker] Got destination type Queue for NotisBean
[ConnectionFactoryHelper] using connection factory: progress.message.jclient.xa.XAQueueConnectionFactory@472243
[ConnectionFactoryHelper] using username/password: jms/jms
[ConnectionFactoryHelper] created XAQueueConnection: progress.message.jclient.xa.XAQueueConnection@1a8416
[JMSContainerInvoker] looking up session pool factory: java:/StdJMSPool
[StdServerSessionPool] initializing with connection: progress.message.jclient.xa.XAQueueConnection@1a8416
[StdServerSessionPool] setting session listener: org.jboss.ejb.plugins.jms.JMSContainerInvoker$MessageListenerImpl@35e6e3
[StdServerSession] initializing (pool, session, xaSession): org.jboss.jms.asf.StdServerSessionPool@49630a, progress.message.jclient.QueueSession@5572a, progress.message.jclient.xa.XAQueueSession@1daa0e
[StdServerSessionPool] added server session to the pool: org.jboss.jms.asf.StdServerSession@79860
:

At last, the two containers are started and an error appears.

:
[JMSContainerInvoker] Starting JMSContainerInvoker for bean GenericJMSBean
[Container factory] Bound Item to ejb/Item
[JMSContainerInvoker] Starting JMSContainerInvoker for bean NotisBean
[StdServerSessionPool] getting a server session
[StdServerSessionPool] using server session: org.jboss.jms.asf.StdServerSession@7f9053
[Default] javax.jms.JMSException: The session and the connection consumer must be created from the same connection
[Default] at progress.message.jclient.aspi.pq.handleMessage(:252)
[Default]
[Default] at progress.message.zclient.MessageHandler.doNextWorkItem(:186)
[Default]
[Default] at progress.message.zclient.go.threadMain(:116)
[Default]
[Default] at progress.message.zclient.DebugThread.run(:56)
:

This error occurs only when using XAConnections. Non XA works fine, except the UOW warning message for every Session that is created.

Bo Carlsson