You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by James Strachan <ja...@gmail.com> on 2006/08/01 13:33:07 UTC
Re: Same class but not equal ==
If the types are not equal to what you expect then it must be a class
loader issue - do you have multiple instances of the class on the
classpath in different class loaders?
On 8/1/06, Nguyen Kien Trung <tr...@gmail.com> wrote:
>
> Hi,
>
> I've got a mysterious error...
>
> I'm using Lingo and ActiveMQ for remote method invocation.
>
> When receiving a RemoteInvocation object, Lingo uses reflection to invoke
> method on proxy object which has been created earlier. But the invocation
> throws NoSuchMethodException. I logged as much as I could and found out:
>
> 1) By introspecting the proxy object, it's confirmed that it contains the
> required method for invocation
> 2) The parameters retrieved from RemoteInvocation object (invocation) by
> getParameterTypes() and from the proxy object by introspection are similar
> in terms of class type
> 3) Interesting results
> log.debug("equal==? : " + (m.getParameterTypes()[0] ==
> invocation.getParameterTypes()[0])); // return false
> log.debug("equal? : " +
> (m.getParameterTypes()[0].equals(invocation.getParameterTypes()[0])));//
> return false
> log.debug("equal class loader ==? : " +
> (m.getParameterTypes()[0].getClassLoader() ==
> invocation.getParameterTypes()[0].getClassLoader())); // return false
>
> where:
> - m: of type java.lang.reflect.Method : method in the proxy object
> - invocation: of type
> org.springframework.remoting.support.RemoteInvocation :
> invocation object received from ActiveMQ
>
>
> So, the issue here is: "Same class but not equal"
> Is there anything in marshalling and demarshalling process of ActiveMQ that
> could lead to this problem?
>
> Appreciate for any advice
>
> Trung
>
--
James
-------
http://radio.weblogs.com/0112098/
Re: Same class but not equal ==
Posted by Nguyen Kien Trung <tr...@gmail.com>.
Thanks, James. I did try but unfortunately it didn't work out....
However, I solved the problem (happy :D)
As mentioned in the previous email, the root cause was, I think, due to
a Single JMS Session created by the manager as I configured:
<!-- Lingo listener -->
<bean id="managerServer"
class="org.logicblaze.lingo.jms.JmsServiceExporter">
<property name="serviceInterface"
value="org.trung.manager.IServiceManager" />
<property name="service" ref="service" />
<property name="connectionFactory" ref="jmsFactory" />
<property name="destination" ref="destinationQueue" />
<property name="metadataStrategy" ref="metadataStrategy" />
</bean>
so the managerServer maintains only single session for all concurrent
invocation from modules (another observation is to look at the thread ID
in the log file: [ActiveMQ Session Task] ).
Therefore, when the managerServer is trying to execute a method A with
parameter PA upon a request, another request arrived and passed its PA1
to the current invocation, therefore the error occurred, since the
method A couldn't match with parameter PA1.
What I did is to change the configuration as follows:
<!-- Lingo listener -->
<bean id="managerServerListener"
class="org.logicblaze.lingo.jms.JmsServiceExporterMessageListener">
<property name="serviceInterface"
value="org.trung.manager.IServiceManager" />
<property name="service" ref="service" />
<property name="connectionFactory" ref="jmsFactory" />
<property name="metadataStrategy" ref="metadataStrategy" />
</bean>
<!-- Container for asynchronous invocation -->
<bean id="managerServer"
class="org.springframework.jms.listener.DefaultMessageListenerContainer">
<property name="concurrentConsumers" value="20"/>
<property name="messageListener" ref="managerServerListener"/>
<property name="destination" ref="destinationQueue" />
<property name="connectionFactory" ref="jmsFactory"/>
</bean>
So the managerServer now can manage incoming requests by having
different sessions, there'll be no conficts in invoking remote method.
Note: The first configuration works fine with JBossMQ so I think
ActiveMQ somehow hasn't supported session management.
Those are my naive explaination, plz correct me if I'm wrong.
Regards,
Trung
James Strachan wrote:
> One option out of class-loader-and-serializer-hell is to use the
> XStreamMarshaller with Lingo
>
> On 8/3/06, Nguyen Kien Trung <tr...@gmail.com> wrote:
>> Hi Hiram,
>>
>> Thanks for the suggestion.
>> In fact, I'm using TCP to connect to ActiveMQ... but it seems not
>> working though.
>>
>> Btw, I've found a blog:
>> http://jroller.com/page/sjivan?entry=asynchronous_calls_and_callbacks_using
>>
>> Sanjiv (the blogger) explained about asynchornous invocation in which I
>> am thinking that could be a root cause.
>>
>> Since I have the [manager.war] and quite number of modules,
>> [module1.war], [module2.war], [module3.war] ....
>> As explained in the blog... I understood that with my current
>> configuration, by using JmsServiceExporter, the manger uses a single JMS
>> Session to handle concurrent messages that are sent by modules. Here we
>> go, the situation is getting worse here....
>>
>> I'm not an expert in JMS so I can't explain well in this. How do you all
>> think about it?
>>
>> Trung
>>
>>
>> Hiram Chirino wrote:
>> > JBoss has a long history of using funky non-standard classloaders. It
>> > has burned many folks in the past and since the classloaders are not
>> > standard classloaders, it hard to debug the issue at times. The
>> > easiest thing I can recommend is that you use TCP transport to connect
>> > to your brokers. Hopefully the serialization that this forces will
>> > fixe your classloading issues.
>> >
>> > On 8/1/06, Nguyen Kien Trung <tr...@gmail.com> wrote:
>> >> Thanks, James for the prompt reply.
>> >>
>> >> You're right about the classloader. In my third log.debug(), I
>> tried to
>> >> compare classloader of two classes (whose types look the same)
>> >> And it returns FALSE. It means, there's a difference in classloader.
>> >>
>> >> I'm not quite familiar with classloader stuff, so let's me explain my
>> >> package deployment so that you could help me to figure out.
>> >>
>> >> I deploy in JBoss 4.0.4.GA as war files, each war file contains
>> Core.jar
>> >> (which has all model classes - classes that i'm talking above
>> regarding
>> >> the error) and Lingo.jar
>> >> [FrontEnd.war]
>> >> ||
>> >> || ActiveMQ
>> >> ||
>> >> [Manager.war]
>> >> ||
>> >> || ActiveMQ
>> >> ||
>> >> [Module.war]
>> >>
>> >> There are 2 things which may be important to consider
>> >> 1) When i switch to JBossMQ, then things are going just fine.
>> >> 2) The error occurs randomly - not for particular method in the proxy
>> >> object
>> >> 3) When I try to debug - timing delay - then there's no error
>> >>
>> >> >> log.debug("equal class loader ==? : " +
>> >> >> (m.getParameterTypes()[0].getClassLoader() ==
>> >> >> invocation.getParameterTypes()[0].getClassLoader())); // return
>> false
>> >>
>> >
>> >
>>
>>
>
>
Re: Same class but not equal ==
Posted by James Strachan <ja...@gmail.com>.
One option out of class-loader-and-serializer-hell is to use the
XStreamMarshaller with Lingo
On 8/3/06, Nguyen Kien Trung <tr...@gmail.com> wrote:
> Hi Hiram,
>
> Thanks for the suggestion.
> In fact, I'm using TCP to connect to ActiveMQ... but it seems not
> working though.
>
> Btw, I've found a blog:
> http://jroller.com/page/sjivan?entry=asynchronous_calls_and_callbacks_using
> Sanjiv (the blogger) explained about asynchornous invocation in which I
> am thinking that could be a root cause.
>
> Since I have the [manager.war] and quite number of modules,
> [module1.war], [module2.war], [module3.war] ....
> As explained in the blog... I understood that with my current
> configuration, by using JmsServiceExporter, the manger uses a single JMS
> Session to handle concurrent messages that are sent by modules. Here we
> go, the situation is getting worse here....
>
> I'm not an expert in JMS so I can't explain well in this. How do you all
> think about it?
>
> Trung
>
>
> Hiram Chirino wrote:
> > JBoss has a long history of using funky non-standard classloaders. It
> > has burned many folks in the past and since the classloaders are not
> > standard classloaders, it hard to debug the issue at times. The
> > easiest thing I can recommend is that you use TCP transport to connect
> > to your brokers. Hopefully the serialization that this forces will
> > fixe your classloading issues.
> >
> > On 8/1/06, Nguyen Kien Trung <tr...@gmail.com> wrote:
> >> Thanks, James for the prompt reply.
> >>
> >> You're right about the classloader. In my third log.debug(), I tried to
> >> compare classloader of two classes (whose types look the same)
> >> And it returns FALSE. It means, there's a difference in classloader.
> >>
> >> I'm not quite familiar with classloader stuff, so let's me explain my
> >> package deployment so that you could help me to figure out.
> >>
> >> I deploy in JBoss 4.0.4.GA as war files, each war file contains Core.jar
> >> (which has all model classes - classes that i'm talking above regarding
> >> the error) and Lingo.jar
> >> [FrontEnd.war]
> >> ||
> >> || ActiveMQ
> >> ||
> >> [Manager.war]
> >> ||
> >> || ActiveMQ
> >> ||
> >> [Module.war]
> >>
> >> There are 2 things which may be important to consider
> >> 1) When i switch to JBossMQ, then things are going just fine.
> >> 2) The error occurs randomly - not for particular method in the proxy
> >> object
> >> 3) When I try to debug - timing delay - then there's no error
> >>
> >> >> log.debug("equal class loader ==? : " +
> >> >> (m.getParameterTypes()[0].getClassLoader() ==
> >> >> invocation.getParameterTypes()[0].getClassLoader())); // return false
> >>
> >
> >
>
>
--
James
-------
http://radio.weblogs.com/0112098/
Re: Same class but not equal ==
Posted by Nguyen Kien Trung <tr...@gmail.com>.
Hi Hiram,
Thanks for the suggestion.
In fact, I'm using TCP to connect to ActiveMQ... but it seems not
working though.
Btw, I've found a blog:
http://jroller.com/page/sjivan?entry=asynchronous_calls_and_callbacks_using
Sanjiv (the blogger) explained about asynchornous invocation in which I
am thinking that could be a root cause.
Since I have the [manager.war] and quite number of modules,
[module1.war], [module2.war], [module3.war] ....
As explained in the blog... I understood that with my current
configuration, by using JmsServiceExporter, the manger uses a single JMS
Session to handle concurrent messages that are sent by modules. Here we
go, the situation is getting worse here....
I'm not an expert in JMS so I can't explain well in this. How do you all
think about it?
Trung
Hiram Chirino wrote:
> JBoss has a long history of using funky non-standard classloaders. It
> has burned many folks in the past and since the classloaders are not
> standard classloaders, it hard to debug the issue at times. The
> easiest thing I can recommend is that you use TCP transport to connect
> to your brokers. Hopefully the serialization that this forces will
> fixe your classloading issues.
>
> On 8/1/06, Nguyen Kien Trung <tr...@gmail.com> wrote:
>> Thanks, James for the prompt reply.
>>
>> You're right about the classloader. In my third log.debug(), I tried to
>> compare classloader of two classes (whose types look the same)
>> And it returns FALSE. It means, there's a difference in classloader.
>>
>> I'm not quite familiar with classloader stuff, so let's me explain my
>> package deployment so that you could help me to figure out.
>>
>> I deploy in JBoss 4.0.4.GA as war files, each war file contains Core.jar
>> (which has all model classes - classes that i'm talking above regarding
>> the error) and Lingo.jar
>> [FrontEnd.war]
>> ||
>> || ActiveMQ
>> ||
>> [Manager.war]
>> ||
>> || ActiveMQ
>> ||
>> [Module.war]
>>
>> There are 2 things which may be important to consider
>> 1) When i switch to JBossMQ, then things are going just fine.
>> 2) The error occurs randomly - not for particular method in the proxy
>> object
>> 3) When I try to debug - timing delay - then there's no error
>>
>> >> log.debug("equal class loader ==? : " +
>> >> (m.getParameterTypes()[0].getClassLoader() ==
>> >> invocation.getParameterTypes()[0].getClassLoader())); // return false
>>
>
>
Re: Same class but not equal ==
Posted by Hiram Chirino <hi...@hiramchirino.com>.
JBoss has a long history of using funky non-standard classloaders. It
has burned many folks in the past and since the classloaders are not
standard classloaders, it hard to debug the issue at times. The
easiest thing I can recommend is that you use TCP transport to connect
to your brokers. Hopefully the serialization that this forces will
fixe your classloading issues.
On 8/1/06, Nguyen Kien Trung <tr...@gmail.com> wrote:
> Thanks, James for the prompt reply.
>
> You're right about the classloader. In my third log.debug(), I tried to
> compare classloader of two classes (whose types look the same)
> And it returns FALSE. It means, there's a difference in classloader.
>
> I'm not quite familiar with classloader stuff, so let's me explain my
> package deployment so that you could help me to figure out.
>
> I deploy in JBoss 4.0.4.GA as war files, each war file contains Core.jar
> (which has all model classes - classes that i'm talking above regarding
> the error) and Lingo.jar
> [FrontEnd.war]
> ||
> || ActiveMQ
> ||
> [Manager.war]
> ||
> || ActiveMQ
> ||
> [Module.war]
>
> There are 2 things which may be important to consider
> 1) When i switch to JBossMQ, then things are going just fine.
> 2) The error occurs randomly - not for particular method in the proxy object
> 3) When I try to debug - timing delay - then there's no error
>
> >> log.debug("equal class loader ==? : " +
> >> (m.getParameterTypes()[0].getClassLoader() ==
> >> invocation.getParameterTypes()[0].getClassLoader())); // return false
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Re: Same class but not equal ==
Posted by Nguyen Kien Trung <tr...@gmail.com>.
Thanks, James for the prompt reply.
You're right about the classloader. In my third log.debug(), I tried to
compare classloader of two classes (whose types look the same)
And it returns FALSE. It means, there's a difference in classloader.
I'm not quite familiar with classloader stuff, so let's me explain my
package deployment so that you could help me to figure out.
I deploy in JBoss 4.0.4.GA as war files, each war file contains Core.jar
(which has all model classes - classes that i'm talking above regarding
the error) and Lingo.jar
[FrontEnd.war]
||
|| ActiveMQ
||
[Manager.war]
||
|| ActiveMQ
||
[Module.war]
There are 2 things which may be important to consider
1) When i switch to JBossMQ, then things are going just fine.
2) The error occurs randomly - not for particular method in the proxy object
3) When I try to debug - timing delay - then there's no error
>> log.debug("equal class loader ==? : " +
>> (m.getParameterTypes()[0].getClassLoader() ==
>> invocation.getParameterTypes()[0].getClassLoader())); // return false