On January 15, 2004 05:20 am, Adrian Brock wrote:
> On Thu, 2004-01-15 at 04:29, Neal Sanche wrote:
> > On January 14, 2004 07:29 pm, Adrian Brock wrote:
> > > On Wed, 2004-01-14 at 23:29, Neal Sanche wrote:
> > > > Hi All,
> > > >
> > > > I've recently been having problems with MDBs not receiving
> > > > messages after my .EAR is redeployed. About the only thing
> > > > that I'm doing differently, as far as I can tell, is to set
> > > > the JNDI name of the MDB within the jboss deployment
> > > > descriptors. Are there JBoss 3.2.2 problems with MDB
> > > > redeployment? I looked through the bug lists on sourceforge
> > > > but was unable to find a bug that was specifically tied to
> > > > redeployment. Most closely related was a closed bug about an
> > > > MDB losing messages after some hours of operation. In my case
> > > > a single redeployment will cease any messages to the MDB.
> > >
> > > There are none that I know about.
> > >
> > > If you think you have a problem with messaging, enable trace
> > > logging for org.jboss.mq
> > > Since you are using mdbs also enable trace for
> > > org.jboss.jms and org.jboss.ejb.plugins.jms
> > >
> > > There are stop and start delivery operations available in 3.2.2
> > > if you find the invoker on the jmx console - something like:
> > > jboss.j2ee:service=EJB,jndiName=whatever,plugin=invoker,binding
> > >=def ault This will let you isolate the startup of delivery
> > > versus the startup of the whole application for debugging
> > > purposes.
> > >
> > > If you can reproduce it with 3.2.4RC1 (from cvs or the nightly
> > > snapshot) I've added a lot more trace logging to the client
> > > side of jbossmq. This should make it easier to figure out what
> > > is going on.
> >
> > Okay, Adrian,
> >
> > I build a nice fresh JBoss 3.2.4RC1 server, out of CVS and
> > configured it so my application would run on it. And I was able
> > to get the same behaviour. But, what I originally thought was
> > message delivery stopping turns out not to be. It's something
> > very strange.
> >
> > Okay, I know JMS messages aren't supposed to contain real
> > references to objects, and probably not references to local CMP
> > Entities. But I wanted to try it, and see if it worked. So I put
> > a CMP Entity reference inside a Hashtable, and sent it as an
> > ObjectMessage. Yeah, I know I probably shouldn't do this, but it
> > works until the application is reloaded. Then an instanceof check
> > in my code fails.
> >
> > My message receiver looks something like this:
> >
> > public void onMessage(javax.jms.Message message) {
> > if (message instanceof ObjectMessage) {
> > Hashtable h = (Hashtable)((ObjectMessage)message).getObject();
> > if (h.get("entity") instanceof ExperimentLocal) {
> > System.err.println("Got one!");
> > }
> > }
> > }
> >
> > This will work when the application is newly loaded after the
> > JBoss container is started. But after a redeploy, I never 'Got
> > one!'. I know I'm getting bitten by some sort of Unified Class
> > Loader voodoo curse, so I'm just going to rewrite my code to pass
> > in the primary key of the Experiment, and look it up from inside
> > my CMR instead.
> >
> > I'm just curious to know why the 'instanceof' might be failing in
> > this case? The Entity is a valid one after all. Regardless of my
> > obvious fudging of the use of JMS messages. :)
>
> I don't think what you are doing can work in general.
> The object inside the message is serialized then deserialized later
> (a deep clone). I don't think it is guaranteed by the spec
> that a local interface will still work after it has been
> serialized. It will do in jboss if it is deserialized in the same
> VM.
>
> The instanceof is probably failing because you are not redeploying
> correctly? Your MDB is probably holding a reference to the old
> interface in the original classloader. Check the interface's
> classloaders of the object from the message and one your mdb is
> using.
It's a pretty odd one, Adrian. I did have a look at the classloaders
on the classes, but didn't notice anything really strange about them.
It's definitely a classloader versioning problem, though. It's really
the only thing it could be. I've since rewritten the code to pass
only the primary key of the object which is a nice serializable
Integer, and it's working fine cross deploys now. If I have time,
I'll write out the classloaders of everything just for kicks and see
where the mismatch is coming from. However, I'm pretty sure I wasn't
holding onto the class reference. Though maybe Java was doing it for
me? Or maybe the serialization during JMS message deployment of
dynamically generated proxy classes is where something odd is
happening?
It's not worth worrying about. Just though it'd help someone else
avoid trying to do this.
-Neal
-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
