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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
>>
>
>
