On 14 Aug, David Maplesden wrote:
> I have had a look at the MDB problem this morning and found a simple bug in
> my original code for SpyConnectionConsumer that would certainly have been
> causing problems. As the CVS update says the fix should hopefully fix the
> problem people were having with MDB but as we are not using MDB ourselves
> and are currently having a bit of trouble with the new build system I can't
> test the fix. So please feel free to test the new fix and let us know if it
> still ain't working.
>
> Cheers,
> david
>
> PS: As I am new to the list I should probably introduce myself. My name is
> David Maplesden and I work at Orion Systems in NZ with Paul Kendall. I am
> responsible for the majority of the recent major changes to jboss mq
> submitted by Paul. They were submitted by him cause I am (to date) too lazy
> to set up a CVS account and stuff. Anyone with any problems with the new
> code or questions etc feel free to send me an e-mail, if I'm not too busy at
> work I'll get back to you ASAP.
Hi, and welcome to the list. You have done some great things. And it's
good that the first part of the MDB problem is solved.
We are now back on square one: undeploying an MDB while it still has
messages waiting does not work (as described in
http://groups.yahoo.com/group/spyderMQ/message/1401 appended here for
clarity).
Here is some sample output from mdb test:
JMSContainerInvoker] Stopping JMSContainerInvoker for bean ExQueueBean
[JMSContainerInvoker] stop requested
[JMSContainerInvoker] unset exception listener
[Connection] Stoping connection, ClientID=ID4
[ClientConsumer:ID4] ClientConsumer:ID4->setEnabled(enabled=false)
[JMSContainerInvoker] connection stopped
Ok, so the invoker is stopped, and the connection says it is stopped
too.
[JMSContainerInvoker] Destroying JMSContainerInvoker for bean ExQueueBean
[StdServerSessionPool] Clearing 14 from ServerSessionPool
[StdServerSession] closed
[StdServerSession] closed
[StdServerSession] closed
[StdServerSession] closed
[StdServerSession] closed
[StdServerSession] closed
[StdServerSession] closed
[StdServerSession] closed
[StdServerSession] closed
[StdServerSession] closed
[StdServerSession] closed
[StdServerSession] closed
[StdServerSession] closed
[StdServerSession] closed
This is nice too, the invoker is destroying it self, and is emptying the
StdServerSessionPool (clear()).
But this is not nice:
[StdServerSession] running...
[TxCapsule] Reused instance for tx=XidImpl [FormatId=257, GlobalId=pra.annons.dn
.se//35, BranchQual=]
[TxManager] began tx: TransactionImpl:XidImpl [FormatId=257, GlobalId=pra.annons
.dn.se//35, BranchQual=]
[TxCapsule] enlistResource(): Entered, tx=XidImpl [FormatId=257, GlobalId=pra.an
nons.dn.se//35, BranchQual=] status=STATUS_ACTIVE
[TxCapsule] startResource(XidImpl [FormatId=257, GlobalId=pra.annons.dn.se//35,
BranchQual=1]) entered: org.jboss.mq.SpyXAResource@7f9053 flags=0
[TxCapsule] startResource(XidImpl [FormatId=257, GlobalId=pra.annons.dn.se//35,
BranchQual=1]) leaving: org.jboss.mq.SpyXAResource@7f9053 flags=0
[StdServerSession] XAResource 'org.jboss.mq.SpyXAResource@7f9053' enlisted.
[JMSContainerInvoker] processing message: TextMessage@Queue Message queue/ex nr
1
[TxManager] suspended tx: TransactionImpl:XidImpl [FormatId=257, GlobalId=pra.an
nons.dn.se//35, BranchQual=]
[TxManager] resumed tx: TransactionImpl:XidImpl [FormatId=257, GlobalId=pra.anno
ns.dn.se//35, BranchQual=]
Bla, bla. The server session pool is still being used, inspite of the
fact that the connection is stoped and the pool has been clear.
The call to clean for the first bean to undeploy never returns, it hangs
there for ever and it is not even possible to shut down JBoss any more,
but kill -9 is needed.
I know there might be some bad behvaviour in the pool while cleaning up (a
potential race), but it is not good that JBossMQ stries to send messages
when the connection is in stoped mode.
This has not been the case before.
//Peter
Earlier mail on undeploy hang on JBossMQ list:
--------------
OK,
I have to admit. Now I have also run into the "hanging in undeploy"
when running mdbtests.
The first and simple reason this seems to be happening is that
undeploy is run so fast so that the tests have not yet finbished,
which is a bad thing. I guess we will eventually have to write
something like the code for ra tests where we have a result queue
where the client may check if everythinh went ok or not.
But it is also a good thing because it shows we have a problem i
StdServerSessionPool: if a bean is deployed before all its messages
has been consumed (which we have top expect) the code will hang in
clear(). It will try to run:
executor.shutdownAfterProcessingCurrentlyQueuedTasks();
But it will never return from it.
To me it also seems as if this is timing specific, under certain
loads
for example (fewer bean and with debugging turned on) it works. So
it's perhaps some threading issue.
What I don't understand is why connection.stop() is not
acknowledget.
Connection stop is namely run before the clean up, and I thought
that
that would stop the JMS server from sending any new messages.
Here are some of my debug output:
[JMSContainerInvoker] connection stopped
[JMSContainerInvoker] Destroying JMSContainerInvoker for bean
ExQueueBean
[StdServerSessionPool] Clearing 12 from ServerSessionPool
[StdServerSession] closed
[StdServerSession] closed
[StdServerSession] closed
[StdServerSession] closed
[StdServerSession] closed
[StdServerSession] closed
[StdServerSession] closed
[StdServerSession] closed
[StdServerSession] closed
[StdServerSession] closed
[StdServerSession] closed
[StdServerSession] closed
[StdServerSessionPool] Shutting down excecutor
Up to here it is fine, but then the shutting down of the executor
seems to trigger something that gets stuck:
BasicQueue] Adding to task queue so that we can route messages
[QueuedTask] Task was not queued in the executor previously, adding
to
executor
[ExclusiveQueue] running
[StdServerSession] running...
[StdServerSession] XAResource '[EMAIL PROTECTED]'
enlisted.
[SpySession] SpySession: run()
[JMSContainerInvoker] processing message: [EMAIL PROTECTED] Message
queue/ex nr
2
[Default] DEBUG: ExQueueBean got message [EMAIL PROTECTED] Message
queue/ex nr 2
[StdServerSessionPool] getting a server session
[StdServerSession] running...
[StdServerSession] XAResource '[EMAIL PROTECTED]'
enlisted.
[SpySession] SpySession: run()
[JMSContainerInvoker] processing message: [EMAIL PROTECTED] Message
queue/ex nr
3
[Default] DEBUG: ExQueueBean throwing EJBException for
[EMAIL PROTECTED]
Message queue/ex nr 3
Bla bla exception, part of the test.
[StdServerSessionPool] recycled server session:
org.jboss.jms.asf.StdServerSessi
[EMAIL PROTECTED]
[ClientConsumer:ID1]
ClientConsumer:ID1->acknowledge(item=AcknowledgementRequest
:ACK,QUEUE.ex,ID9-1,txId=-9223372036854775278)
[StdServerSession] done
[ClientConsumer:ID1] Message Ack: -9223372036854775807
[StdServerSession] Rolling back JMS transaction
[ClientConsumer:ID1]
ClientConsumer:ID1->acknowledge(item=AcknowledgementRequest
:NACK,QUEUE.ex,ID9-2,txId=-9223372036854775277)
[ClientConsumer:ID1] Restoring message: ID9-2
[ex] JMSDestination:QUEUE.ex->restoreMessage([EMAIL PROTECTED]
Message queue
/ex nr 3)
[BasicQueue] Restored a message, queue size:1
[BasicQueue] Adding to task queue so that we can route messages
[QueuedTask] Task was not queued in the executor previously, adding
to
executor
[ExclusiveQueue] running
[ClientConsumer:ID1]
ClientConsumer:ID1->scanExclusiveQueue(queue=org.jbossmq.se
[EMAIL PROTECTED])
Well, basically we have a bug here somewhere. Any ideas Hiram?
----------------
--
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]
http://lists.sourceforge.net/lists/listinfo/jboss-development
