Bugs item #448456, was opened at 2001-08-06 09:38
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=448456group_id=22866
Category: JBossServer
Group: v2.5 Rabbit Hole (unstable)
Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Andreas Schaefer (schaefera)
Summary: MDB Persistence with ejb-ref
Initial Comment:
This happens in Jboss 2.4.x - 2.5
It appears that when a MDB needs to use another EJB
that isn't bound yet at deployment time, it does not
run it's messages from persistent storage properly.
The EJB that it uses is in the same jar, just get's
deployed after it.
From the log, I can see that the container processes
the messages before the deployer is done binding the
ejb-refs, that may be the problem.
Apparently, as soon as the container deploys the MDB,
it loads the persistent messages and attempts to run
them all. However, I have noticed that it wasn't
running for my MDB.
My MDB has debug statements in it, as you can see from
the following log, after session.run() there are no
debugs, also the message is never acknowledged.
I've added the * comments here to explain what I'm
seeing.
**STARTS THE ejb-ref
[StatelessSessionContainer] Begin java:comp/env for
EJB: Queue
***
Starts running the messages (does nothing)**
[StatelessSessionContainer] TCL:
java.net.URLClassLoader@7f6de1
[SpySession] SpySession: run()
[SpySession] Session: commit()
[StdServerSessionPool] recycled server session:
org.jboss.jms.asf.StdServerSession@71949b
[StdServerSession] done
[StdServerSession] running...
[SpySession] SpySession: run()
[SpySession] Session: commit()
[StdServerSessionPool] recycled server session:
org.jboss.jms.asf.StdServerSession@52eef4
[StdServerSession] done
[StdServerSession] running...
[SpySession] SpySession: run()
[SpySession] Session: commit()
[StdServerSessionPool] recycled server session:
org.jboss.jms.asf.StdServerSession@16de29
[StdServerSession] done
**
**Then continues with the ejb-ref
[StatelessSessionContainer] End java:comp/env for EJB:
Queue
[ContainerFactory] Mapped Container method remove
HASH -1842617161
[ContainerFactory] Mapped Container method getEJBHome
HASH -993218923
[ContainerFactory] Mapped Container method getHandle
HASH 1182305581
[ContainerFactory] Mapped Container method
getPrimaryKey HASH -131865408
[ContainerFactory] Mapped Container method isIdentical
HASH 285457048
[ContainerFactory] Mapped getQueueModel 149634609to
public net.automark.iengine.
queue.model.QueueModel
net.automark.iengine.queue.ejb.QueueEJB.getQueueModel
(int)
[ContainerFactory] Mapped loadQueue 86577524to public
int net.automark.iengine.queue.ejb.QueueEJB.loadQueue
(int,java.lang.String,int,java.lang.String)
[ContainerFactory] Mapped removeQueue -1164152750to
public void
net.automark.iengine.queue.ejb.QueueEJB.removeQueue
(int)
[ContainerFactory] Mapped setAttempts -1043613833to
public void
net.automark.iengine.queue.ejb.QueueEJB.setAttempts
(int,int)
[ContainerFactory] Mapped setProcessingFlag -
1794014050to public void
net.automark.iengine.queue.ejb.QueueEJB.setProcessingFl
ag(int,java.lang.String)
[ContainerFactory] Mapping remove
[ContainerFactory] Mapping remove
[ContainerFactory] Mapping getEJBMetaData
[ContainerFactory] Mapping getHomeHandle
[ContainerFactory] Mapping create
*
When I add the following code to StdServerSession that
makes sure the Entity that the MDB uses is bound, it
works fine.
// run the session
while (true){
InitialContext ctx = new InitialContext();
Object objref = null;
try{
objref = ctx.lookup
(net.automark.iengine.queue.ejb.Queue);
} catch (Exception e){
Thread.sleep(1);
log.debug(*Queue Not
bound yet.);
}
if (objref != null){
break;
}
}
session.run();
I don't know whether it is simply the waiting that
fixes it, or the fact that the Entity is definitely
bound before it runs, but this fixes it. I have to
leave this terrible hack in the jboss code for now,
until this behaves properly. Please feel free to
email if I have not explained this well enough.
[EMAIL PROTECTED]
--
Comment By: Andreas Schaefer (schaefera)
Date: 2001-11-10 17:14
Message:
Logged In: YES
user_id=70434
I understand that when you deploy a MDB and another EJB is
not bound to the JNDI server because the EJB is not
deployed yet then the ejb-ref in your MDB points to a not
bound EJB now.
But I don't see that this is a bug. The PersistentManager
cannot know what the MDB uses to perform a message
delivery. Even we assume that a delay of 20 seconds will
fix your problem it still can fail when you bind to another
EJB deployed in
