JBossDeveloper

Ok, sorry I am a bugger. I should have checked my own code: the maxMessage for the consumer constructor already defaults to one. So we are fully spec compliant ;-).

I don't want to risk a war again ;-) but the stuff we have discussed hierto points me in the direction that we actually have done it right. If it does not work, either the provider has done it wrong, or there is a bug creaping in the JBoss code.

If any of you JMS provider guys could find that bug, please step forward and we will stand corrected.

May the source be with you.

//Peter

Hm, interesting. That's actually where the first transaction code was ;-).

What you are saying is actually this (my interpretation) that regardless of how many messages you stuff into the session your XAresource will not get activated/be available untill your session calls onMessage. Am i right here?

Why can you not make the XAResource available just after you have stuffed one (1) message into the session and just before you call start() on the server session.

If this worked we could test integration, and then move into an enviroment where it would be possible to stuff more than one message into a session.

Hiram, what do you say about this? To me it actually seems a little bit strange to enroll a message receipt in a transaction just after it has actually been received (onMesseage is called from the session), even if it is still only the container beeing called.

The problem from the JBoss perspective is also that we would have to redo the pool-listener logic, i.e for the listener to have access to the XAResource it must be created with access to the session, meaning we would have to have one listener instance per pooled session, and these instances must work against the same invoker.
(I admit this is actually said in the spec)
Possible to do:

- How much would it distrupt JBossMQ, Hiram?
- Have you Swift got anything we could test against?

//Peter

> > Why can you not make the XAResource available just
> > after you have stuffed one (1) message into the
> > session and just before you call start() on the
> > server session.
>
> I can actually live with your current impl. The XA
> resource will simply assign the last delivered
> message every time. But you have to set the
> maxMessage constantly to 1, otherwise your MDB
> transaction will cover more than 1 message.

Now we are really talking. Thank for an interesting discussion. I make two conclussions:

1. Our current implementation works for maxMessages set to 1, which is the default.
2. Our implementation is flawed if the user changes the MaxMessages in the deploymentdescriptor, which is possible but I have never heard of anyoneone doing it. And is probably not maximally efficient.

I will think about if we should change to an implementation that supports the latter based on input from Hiram.

You where right, and I where right - just on different topics. Great.

>
> > - Have you Swift got anything we could test
> against?
>
> Not yet. ASF/XA will be an extension of SwiftMQ 3.0.0
> to be released in January.

Please get back if you have any more problems. (I will not be able to respond between december 12 and january 7.)

//Peter


>
> Andreas

Hey guys.. I think that we are ok.

The problem that we have is that we are enlisting the XAResource too early. But I assume we can fix this within the container code. In other words, we will not need to change JBossMQ to make the fix.

If sonic stays true to spec, it should also behave like JBossMQ. When we fix the container so that it enlists the TX correctly, then we should be 100% compliant and Both JBossMQ and Sonic will be able to use Consumemers with maxMsg>1.

So it seems like we are not really holding back the sonic guys from supporting JBoss right???

Regards,
Hiram

Should we move the enlistment into the MessageListener class in JMSContainerInvoker and create multiple such beasts?

You mean that JBossMQ would not be affected of such a move?

//Peter

Voiala, I know of a dead simple way to solve it (i think). Make the StdServerSession a MessageListener, set it as listener in the pool and give it the JMSContainerInvoker to invoke.

Then we only move the transaction stuff inside the StdServerSession to the onMessage method.

I will test it in the next couple of days if you don't do it first ;-)

//Peter

peter,

Your a SMART Cookie. ;-)

Regards.
Hiram

Unfortunately it did not work fully. I think we have a problem with the ack in the MessageConsumer and ResourceManager when the rollback is run before the onMessage returns.

Could you look into the mail I sent to dev?

//Peter

what do you mean before the onMessage returns?? Who's doing the rollback??? Do you mean the TX manager is doing an rollback on a different thread than the one where the TX is taking place in??

Regards,
Hiram

No,
I moved the tx stuff in StdSession to onMessage instead. SO we basically have this in my test:

stdSession.start()->run()
xaSession.run()->stdSession.onMessage()
//Set the tx stuff in onMessage()
listener.onMessage().

When I run a test where the bean rolls back (setRollbackOnly), the message receipt is rolled back, bit the recover bit is not run, i.e it will be in the queue, but it will not be resent.

The reason, I think, is this:

1. Current behaviour: when onMessage return in the consumer the message will be marked as acked, even if it was an actuall rollback.

But since we do the TX _after_ the consumer has returned the txResourceManager can (and does in the code) go though the acked messages and un-ack them.

2. If we do the TX before the onMessage has returned, the txResourceManager will mark the message as rooled back, but the consumer will mark it as acked, and therefore it will be in an inconsitant state, i.e it is rolled back (placed back in the queue), it is acked (not resent).

Do you follow me?

(Here is the classes involved, I think:

SpyMessageConsumer.sessionConsumerProcessMessage - which does the ack.

SpyXAResourceManager.ackMessage - place acked messages in acked table.

SpyXAResourceManager.rollback - rolls back receipt and unacks all messages placed in the state.ackedMessages

This works good when ackMessage is run before rollback, but not the other way around, which is needed if we should move the TX code into onMessage.

)

//Peter

yep i see what you are saying now. I'm looking into it right now.

Hiram

Ok I just commited the change.
The message is now added to XAResource manager before it calls onMessages. This should allow you to enlist the XAResource IN the onMessage() method.

Which is what I think you wanted.

Regards,
Hiram

Cool, I will have a go at it this week.

//Peter