The 'DirectConsumer:Caught Exception delivering
messagecom.sun.messaging.jmq.io.Packet cannot be cast to
com.sun.messaging.jms.ra.DirectPacket' message is due to a bug in the
direct mode implementation which has subsequently been fixed in MQ 4.1
Patch 2. Try upgrading your MQ version to 4.1 P2 or later.
Thx,
Satish
Dobes Vandermeer wrote:
>
> glassfish-2 wrote:
>
>>> I thought I could use JMS for this but the JMS
>>> implementation with glassfish
>>> v2ur2 is too buggy and I can't upgrade to 2.1 due to
>>> some weird classpath
>>> issues in 2.1 I couldn't resolve.
>>>
>> What issues are you having with JMS? Seems to me that JMS with a
>> constrained MDB (i.e. container can not make more than, say, 5 instances)
>> would work well at letting you control resource uses. And this doesn't
>> sound like a particularly exotic use of JMS.
>>
>> So I'm curious what problems you're encountering with it.
>>
>>
>
> This is the sort of thing JMS would be perfect for, if it worked. I was
> getting a lot of errors in the logs - for each message delivered it would
> print an error every once in a while (maybe 30 seconds?) and as more
> messages were sent the volume of errors increased.
>
> Generally, it's just a flaky unfinished product at the stage I was using it,
> for example when I first set up the Queue I got this:
>
> MQJMSRA_MC2001: createConnection API used w/ username, password for
> Container Auth
>
> Apparently I had to delete the username and password properties from the
> queue in the admin panel. Just something that shows a lack of usability
> testing. Why not just treat an empty username/password the same as a null
> one?
>
> Anyway, the actual error I was getting is discussed in this thread, I
> believe (it's been a couple weeks so I've gotten foggy on the exact error
> text):
>
> http://forums.java.net/jive/thread.jspa?messageID=278700
>
> For me, the suggested workaround of changing the connection type to LOCAL
> did not solve the problem, things actually got worse, so I gave up on the
> JMS solution.
>
>
>
>