On 10 Sep, Hiram Chirino wrote:
>
> Hi I thought of an Idea that should fix Jason's problem while not chaning
> the current MDB invoker too much. What we have to do is get rid of that
> ugly timeout. So when MDB TX is NotSupported, lets not elist the TX with
> the TM since he sill timeout the transaction. Lets just manually
> commit/rollback the TX via the sessions's XAResource.
>
> What do you think???
Yupp, that might be it. Would have to lookinto what info the
ServerSession and ServerSession pool has about the transaction
atributes. What could perhaps be used (which we did before) was to use
the ACK mode in ServerSessionPool. This will be CLIENT_ACKNOWLEDGE_MODE
when and only when we have a TX Required.
//Peter
>
> Regards,
> Hiram
>
>>From: Peter Antman <[EMAIL PROTECTED]>
>>Reply-To: [EMAIL PROTECTED]
>>To: [EMAIL PROTECTED]
>>Subject: Re: [JBoss-dev] message redelivery & MDB TX timeout with
>>NotSupport ed
>>Date: Mon, 10 Sep 2001 13:17:23 +0200 (CEST)
>>
>>On 10 Sep, Jason Dillon wrote:
>> >> >> Hiram is the one who did the transaction parts of the MDB, but I
>>would
>> >> >> geuss this is what is going on: An MDB is ALWAYS transacted (the
>>receipt
>> >> >> that is), the flags only determins under what TX context the bean is
>> >> >> invoked. This mean there will allways be a transaction going on
>>under
>> >> >> the hood.
>> >> >
>> >> > Is that by design... that NotSupported still runs with a TX?
>> >>
>> >> Yes, but remember. The receipt is under a transaction, but not the
>>bean.
>> >
>> > Ah, so it waits for onMessage() to complete.
>> >
>> > Is the TX only for removing from the queue/topic? Will this same TX be
>>used
>> > by component invocations done by the MDB in NotSupported? Sorry, I am
>>still
>> > getting the hang of how EJB & JMS transactions really work.
>>
>>First: StdServerSession.run() is the place to look in. Thats where the
>>meat of the invokation is done.
>>
>>
>>Here is part of the flow:
>>
>>1. Connection consumer get ServerSession
>>2. Invokes run()
>>3. Transaction is started and enlisted if there was a XA cf.
>>4. ServerSession invokes run on JMS session.
>>5. JMS session calles JMSContanerInvoker.
>>6. Container invoker calls interceptor chain
>>7. TX interceptor handles TX, if Required (CMT) the bean is invoked with
>> the TX started in 3, if NotSuported the transaction is suspended
>> during the call to the MDB and resumed afterwards.
>>
>>8. Bean is finally called.
>>...Trickled back though the chain
>>9. the run() method finnished by committing the transaction.
>>
>> >
>> > Perhaps in this situation the receipt tx should be committed just prior
>>to
>> > calling onMessage()?
>>
>>I really do not know if that is even possible, but even if it is it is
>>risky. You might say the the spec says that message receipt is out of
>>controll of the MDB with NotSuported or BMT and therefore an ack
>>alaready at message receipt at a hight level would be ok.
>>
>>On the other hand, I would say, that what the contract guarantes is that
>>any container failour should be treated with and not result in an acked
>>message receipt. If the we ack early in the chain, we certainly expose
>>our self of container failours that will not leed to a non acked
>>receipt.
>>
>> >
>> > What are your thoughts about adding support for the MDB system to use an
>> > optional dynamic policy to indicate if it should accept messages? you
>>know
>> > instead of simply blindly taking messages from the queue/topic. Perhaps
>> > the dead letter support can be augmented to take a policy interceptor
>>chain?
>> >
>>
>>That might be an idea, but in generall, all this have to lie within the
>>JMS provider. Say the MDB container might decide not allow a new
>>message, and did not ack it, if this message really would find its way
>>into another MDB somewhere is really up to the JMS provider to decide.
>>As far as last we discussed this, this behavour is not implemented in
>>JBossMQ.
>>
>>
>> > I would like to use MDB simplicity to process messages, but also make
>>use of
>> > JMS as a load balancer. Right now I could simply have onMessage() throw
>> > exceptions to indicate non-interest, but that is just plain crazy.
>>
>>No you could not, since JBossMQ has alreadt delivered the message to the
>>local consumer and will try and try again to deliver it to that one (as
>>far as I know). As far as I can see it your load balancing will never be
>>better than the balancing algorithm the JMS provider uses to publish
>>queue messaged to the queue subscribers.
>>
>>Basically: its up to the JMS provider.
>>
>>However: if you are willing to roll your own JMSContainerInvoker you
>>could probably use another aproach. Write an invoker that only handles
>>one message a time and does a receive. Something like this.
>>
>>for(;;) {
>> Message m = messageConsumer.receive();
>> onMessage(m);
>>}
>>
>>
>>You could overide typically init and start to implement your special
>>code
>>
>>
>>Well, maybe that idea stinks, or maybe we could build some extended
>>functionality into the vanilla JMSContainerInvoker. I really do not
>>know, but I think it would get you your wanted behaviour.
>>
>>//Peter
>>
>>
>>
>> >
>> > --jason
>> >
>> >
>> > _______________________________________________
>> > Jboss-development mailing list
>> > [EMAIL PROTECTED]
>> > https://lists.sourceforge.net/lists/listinfo/jboss-development
>>
>>--
>>Jobba hos oss: http://www.tim.se/weblab
>>------------------------------------------------------------
>>Peter Antman Technology in Media, Box 34105 100 26 Stockholm
>>Systems Architect WWW: http://www.tim.se
>>Email: [EMAIL PROTECTED] WWW: http://www.backsource.org
>>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
>
>
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
--
Jobba hos oss: http://www.tim.se/weblab
------------------------------------------------------------
Peter Antman Technology in Media, Box 34105 100 26 Stockholm
Systems Architect WWW: http://www.tim.se
Email: [EMAIL PROTECTED] WWW: http://www.backsource.org
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
