-
1. Re: JBoss Messaging - classcast exception
ataylor Oct 6, 2008 10:36 AM (in response to prabhun)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
-
2. Re: JBoss Messaging - classcast exception
prabhun Oct 6, 2008 12:25 PM (in response to prabhun)Hi,
Thanks for your reply.
I am using Jboss messaging 1.4.0.SP3
Regards,
Prabhu -
3. Re: JBoss Messaging - classcast exception
clebert.suconic Oct 6, 2008 3:56 PM (in response to prabhun)There is also https://jira.jboss.org/jira/browse/JBMESSAGING-1277
which is probably the cause of your problem. -
4. Re: JBoss Messaging - classcast exception
prabhun Oct 8, 2008 12:07 PM (in response to 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 -
5. Re: JBoss Messaging - classcast exception
clebert.suconic Oct 8, 2008 1:50 PM (in response to prabhun)This is exactly what I fixed on https://jira.jboss.org/jira/browse/JBMESSAGING-1277.
-
6. Re: JBoss Messaging - classcast exception
clebert.suconic Oct 8, 2008 1:59 PM (in response to prabhun)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 -
7. Re: JBoss Messaging - classcast exception
clebert.suconic Oct 8, 2008 8:38 PM (in response to prabhun)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
-
8. Re: JBoss Messaging - classcast exception
prabhun Oct 9, 2008 7:54 AM (in response to prabhun)Hi Clebert,
Thank you.
I will try this and let you know.
However, how soon SP4 will be released ?
Regards,
Prabhu -
9. Re: JBoss Messaging - classcast exception
timfox Oct 9, 2008 8:01 AM (in response to prabhun)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.
-
10. Re: JBoss Messaging - classcast exception
prabhun Oct 13, 2008 10:57 AM (in response to 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 -
11. Re: JBoss Messaging - classcast exception
prabhun Oct 13, 2008 12:32 PM (in response to 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 -
12. Re: JBoss Messaging - classcast exception
clebert.suconic Oct 13, 2008 7:02 PM (in response to prabhun)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. -
13. Re: JBoss Messaging - classcast exception
timfox Oct 14, 2008 2:57 AM (in response to prabhun)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. -
14. Re: JBoss Messaging - classcast exception
prabhun Oct 20, 2008 6:32 AM (in response to 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