On Jan 20, 2009, at 9:11 AM, Tyson Weihs wrote: > The expected type is an instance of one of our serializable classes.
Hmm. Is there any pattern when this happens? > Fixing that back in 3.1.8/9 would be greatly appreciated. Yep. I'll check. -- Scott > > > On Tue, Jan 20, 2009 at 11:01 AM, Scott Ferguson <[email protected]> > wrote: >> >> On Jan 18, 2009, at 1:07 PM, tweihs wrote: >> >>> >>> We finally upgraded to 3.1.8! ("Hallelujah, holy s**t, where's the >>> tylenol" - >>> Clark W. Griswald) >>> >>> The pain moving from 3.1.3, which we stuck ourselves on not knowing >>> it was a >>> dev release, was intense (changed just about every tag, new super >>> classes >>> for many of our objects, made the jump to configuring all our beans >>> via >>> IoC), but it seems to be paying off (better production performance, >>> easier >>> development using annotations, etc.). >>> >>> We're seeing the following exception in production now, though: >> >> I've filed this as a bug, although I think we've already fixed it (it >> might need to be fixed back in 3.1.x) >> >>> >>> >>> [21:00:07.701] {resin-21} >>> MessageConsumerImpl[FileQueue[executorQueue]]: >>> message listener '_ejb.defaultexecutor.executor__...@149dd5b' failed >>> for >>> message 'ObjectMessageImpl[ID:4U5naCkuy/cAEe3cHn/wAC]' with >>> exception >>> [21:00:07.701] {resin-21} java.lang.RuntimeException: >>> java.lang.NullPointerException >>> [21:00:07.701] {resin-21} java.lang.RuntimeException: >>> java.lang.NullPointerException >>> [21:00:07.701] {resin-21} at >>> com.caucho.jms.connection.JmsSession.commit(JmsSession.java:1018) >>> [21:00:07.701] {resin-21} at >>> com.caucho.transaction.TransactionImpl.commit(TransactionImpl.java: >>> 658) >>> [21:00:07.701] {resin-21} at >>> com >>> .caucho >>> .transaction >>> .TransactionManagerImpl.commit(TransactionManagerImpl.java:271) >>> [21:00:07.701] {resin-21} atmore >>> >>> We're using file queues for storage. We're also seeing class cast >>> exceptions occasionally when pulling the message objects out of the >>> queue, >>> where Message.getObject() is returning a java.lang.Long (and we've >>> checked >>> code to see that we're not injecting Longs). Any ideas? >> >> Do you know what the expected type is? It's conceivable that a Byte >> is getting converted to a Long. >> >> -- Scott >> >>> >>> >>> >>> -- >>> View this message in context: >>> http://www.nabble.com/JMS-Exceptions%2C-3.1.8-tp21532983p21532983.html >>> Sent from the Resin mailing list archive at Nabble.com. >>> >>> >>> >>> _______________________________________________ >>> resin-interest mailing list >>> [email protected] >>> http://maillist.caucho.com/mailman/listinfo/resin-interest >> >> >> >> _______________________________________________ >> resin-interest mailing list >> [email protected] >> http://maillist.caucho.com/mailman/listinfo/resin-interest >> > > > _______________________________________________ > resin-interest mailing list > [email protected] > http://maillist.caucho.com/mailman/listinfo/resin-interest _______________________________________________ resin-interest mailing list [email protected] http://maillist.caucho.com/mailman/listinfo/resin-interest
