activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Mittler <nathan.mitt...@gmail.com>
Subject Re: session thread and onException
Date Sat, 05 Jan 2008 16:01:06 GMT
Hi,

>
> Hi,
> i'm using activemq in my c++ application. I have one connection and  
> one
> session for this connection. I see that the session  
> (SessionExecutor) starts
> a new thread. I set my class that starts the connection and the  
> session to
> be the exceptionListener. Does that mean that the onException will  
> be called
> from the session Thread?

Yes, the C++ client mirrors this concept of JMS - all the other  
clients (Java, .NET, etc.)  are the same in this regard.

> If so, then i get here a thread unsafe application.
> During a connect I update my members ( session, producer and  
> consumer for
> example), if an exception will occur, i will access my members from  
> two
> different threads. Am I correct?

Correct - standard multithreading stuff.

>
> what is the possible solution? can i disable session thread?

No, you can't disable the fact that onException is called in a  
different thread.  However, you can be guaranteed that all calls to  
onException from the same session will be executed in the same thread  
context.  i.e. session = 1 thread.

> Do i need to
> lock my members?

A safe answer to this question is yes.  Any time you try to access the  
same data from multiple threads, it's a critical section.  ActiveMQ- 
CPP provides some mechanisms that simplify this process.  The  
activemq::concurrent::Mutex class should do the trick.

>
> I saw some explanation about optimizedDispatch=true option that looked
> suitable for disabling session thread, but couldn't find a cms  
> support for
> this.

There is no support for this feature in ActiveMQ-CPP at this time.

>
> Any help will be appreciated.
>

One other thing you should be aware of is that there are two ways of  
receiving messages: asynchronous (onException) and synchronous  
(receive).   If you'd rather poll from your application thread for new  
messages, you can call one of the MessageConsumer's receive methods,  
which will optionally block until it gets a new message and return  
it.  No threading involved on the part of the application.

Regards,
Nate





Mime
View raw message