JBoss Messaging - classcast exception

[prabhun]

Hi,

We are migrating our project from Jboss MQ to Jboss Messaging.
The following scenario works fine in Jboss MQ however it does not work in Jboss Messaging:

Object A is a publisher, which publishes the messages to a JMStopic.
Object B is a subscriber to topic.
Object C is another subscriber to same topic.

All 3 are individual J2ee projects using isolated (individual) Class loaders.

A publishes the message, B and C reads the message.

· B reads the message successfully and works fine.
· When C reads the message the actual class is loaded from classloader of B instead of classloader of C (runtime,object class loader path shows the class is loaded from B). Hence class cast exception occurs.

Code in B
{
public void onMessage(Message message) {

// message object is loaded from classloader of B.No exception
}

}

Code in C
{
public void onMessage(Message message) {

// Message object is loaded from classloader of B, it was suppose to be loaded from classloder of C.Hence class cast exception occurs.
}

}

It looks like a Class Loader problem while using the Jboss Messaging.

Is it a bug or we need to do any additional configuration to fix this issue?
If any one has come across this classcast exception please let us know the fix for this.
Regards,
Prabhu

[ataylor]

which version of JBM are you using, there have been issues like this fixed in the past, for example https://jira.jboss.org/jira/browse/JBMESSAGING-924, but these have been fixed

[prabhun]

Hi,

Thanks for your reply.

I am using Jboss messaging 1.4.0.SP3

Regards,
Prabhu

[clebert.suconic]

There is also https://jira.jboss.org/jira/browse/JBMESSAGING-1277

which is probably the cause of your problem.

[prabhun]

Thanks Andy and Clebert ,

In our case
Object A is a publisher, which publishes the messages to a JMStopic. And Object B and C are the subscribers which use their own scoped class loaders.
If I use the same class loader for both B and C it works fine. It fails only when the class loaders are different.
As mentioned in the post forwarded by Clebert , we do use getObject call like below,

In the first subscriber,

javax.jms.ObjectMessage objectMessageA = (javax.jms.ObjectMessage)message;

Object aObject = objectMessageA.getObject();
ObjectA a = (ObjectA)aObject; -- (1)
It works fine.

In next subscriber

javax.jms.ObjectMessage objectMessageB = (javax.jms.ObjectMessage)message;

Object bObject = objectMessageB.getObject();
ObjectA b = (ObjectA)bObject; -- (2)
This fails if we have a different class loader for the second subsriber.

Is there any other way to use the getObject call to avoid this exception?

Regards,
Prabhu

[clebert.suconic]

This is exactly what I fixed on https://jira.jboss.org/jira/browse/JBMESSAGING-1277.

[clebert.suconic]

1277 also duplicates https://jira.jboss.org/jira/browse/JBMESSAGING-1386 which shows exactly the scenario you're having.

I had to change code to fix that behavior:

http://fisheye.jboss.org/viewrep/Messaging/branches/Branch_Stable/src/main/org/jboss/jms/message/JBossObjectMessage.java?r1=3285&r2=4630

http://fisheye.jboss.org/viewrep/Messaging/branches/Branch_Stable/src/main/org/jboss/jms/message/ObjectMessageProxy.java?r1=3273&r2=4630

[clebert.suconic]

We will soon release SP4.
Meanwhile you could download this TAG:

svn co http://anonsvn.jboss.org/repos/messaging/tags/JBossMessaging_1_4_0_SP3_CP04/ SP3-fix
cd SP3-fix
ant release-bundle

[prabhun]

Hi Clebert,

Thank you.

I will try this and let you know.

However, how soon SP4 will be released ?

Regards,
Prabhu

[timfox]

We're hoping to bring out a 1.4.1.GA release some time next week, which will contain all the latest bug fixes and changes.

[prabhun]

Thanks Tim,

We have one more problem.

As I have already said that we are moving from Jboss MQ to Jboss Messaging,

In Jboss MQ we have a X-doclet code to define the subscription id for each subscriber,
like below


*@jboss.subscriber
* client-id="rate.of.sale.ip"
* subscription-id="rate.of.sale.ip"


This will appear as below in the JMXConsole.

TOPIC.TestIPTopic.rate.of.sale.ip.-2147483648

We want to extract this information for every consumers and to display in an application status window.

In the above we can extract the subscription id 'rate.of.sale.ip' from the 'TOPIC.TestIPTopic.rate.of.sale.ip'

But for Jboss Messaging this subscription id does not seem to work.

It appears as below in the JMXConsole.

Subscription.8n-qklvw8mf-1-gwnsw8mf-4ko8nl-k3d8a4ko8nl-k3d8a

So we could not clearly separate out the different subscribers as the subscription id are dynamically generated.

Since this x-doclet code had no effect in the new Jboss Messaging what is the alternative way to set (to make static subscription id) the
subscription id for each subscribers ?

Regards,
Prabhu

[prabhun]

Hi,

This is further to my above post.

Our subscribers are all non-durable.

Jboss messaging implementation seems to ignore both the client-id and subscription-id for non durable subscriptions.

If we change the subscriptions to being durable, this then allows the subscription ID and client-id to be set.

It may be a simple matter to make the queues durable and be done with it, however the very fact that we are adding a new persistence element
to the queue/topic might mean that the performance is badly hit by this change.

Is there any alternative way of setting the subscription and client id for non-durable subscribers?

Regards,
Prabhu

[clebert.suconic]

might mean that the performance is badly hit by this change.

this is totally up to your requirements.

We won't persist anything on NonDurableSubscribers. It is like you sending NonPersistentMessages on those cases. So you should decide if you use Durable or not based on your requirements.

Is there any alternative way of setting the subscription and client id for non-durable subscribers?

We just use UUIDs on NonDurableSubscriptions. You're not required to set the clientID on NonDurableSubscription and you could have multiple subscriptions, so we must use an UUID.

If you like, You could ask a feature through JIRA to use the clientID as part of the ID on
nonDurableSubscribers. I know it would be a simple change... but I'm not sure if that would make sense or not for other customers.. so Tim Fox would evaluate the request.

That wouldn't make any difference on the execution of your topics though.

[timfox]

Client id and subscription name are used in JMS to define *durable subscriptions*, in JMS they have absolutely no meaning for non durable subscriptions.

In fact, there is no way using the JMS API to create a non durable subscription with a specific id so you couldn't be doing this on JBoss MQ either, unless it provides a special API, which I very much doubt. I suspect you're actually using durable subscriptions with JBoss MQ.

Please see JMS spec for more details or clarification on the semantics of client id and subscription name.

[prabhun]

Hi Tim,

In Jboss MQ we are using the null persistance mechanism and we are not using any durable subscriptions.

We could not find the null persistance related NullPersistenceManager-xmbean.xml file in our version which is jboss messaging 1.4.0 SP3.

Whether 'SP4 release' which you are planning to release now will have this null persistance NullPersistenceManager-xmbean.xml file ?

Also I want to know if we follow the same null persistance in Jboss messaging will it take care our issue?

And one more issue is we could not retrieve the message depth (unread messages) for the topics in Jboss messaging. That is eventhough the topics contains the messages to process it is always showing the count as zero. The same was working fine with Jboss MQ as well as for Queues in Jboss messaging. It fails for Jboss messaging topics only.

Regards,
Prabhu