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 <f...@caucho.com>  
> 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
>>> resin-interest@caucho.com
>>> http://maillist.caucho.com/mailman/listinfo/resin-interest
>>
>>
>>
>> _______________________________________________
>> resin-interest mailing list
>> resin-interest@caucho.com
>> http://maillist.caucho.com/mailman/listinfo/resin-interest
>>
>
>
> _______________________________________________
> resin-interest mailing list
> resin-interest@caucho.com
> http://maillist.caucho.com/mailman/listinfo/resin-interest



_______________________________________________
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Reply via email to