activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nguyen Kien Trung <trung....@gmail.com>
Subject Re: Same class but not equal ==
Date Thu, 03 Aug 2006 09:05:45 GMT
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 <trung.n.k@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 <trung.n.k@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
>> >>
>> >
>> >
>>
>>
>
>


Mime
View raw message