In the testing I did, Connection is really created in a new thread. Session part I am not sure. Do not know how to test it. OnMessage() always comes to same thread (different with connection thread). It is wired
Wednesday, 10 February 2010
Threads allocated in ActiveMQ and options
I found a very nice post about threads allocated in ActiveMQ consumer, broker and producer. http://fusesource.com/wiki/display/ProdInfo/Understanding+the+Threads+Allocated+in+ActiveMQ
Two wire protocol supported in ActiveMQ
Default wire protocol supported by ActiveMQ is Java OpenWire transport. OpenWire is used to marshal objects to byte arrays and back. http://activemq.apache.org/openwire.html
Another one is Stomp. The Stomp project is the Streaming Text Orientated Messaging Protocol site (or the Protocol Briefly Known as TTMP and Represented by the symbol :ttmp).
Stomp provides an interoperable wire format so that any of the available Stomp Clients can communicate with any Stomp Message Broker to provide easy and widespread messaging interop among languages, platforms and brokers.
I think wire protocol is the way ActiveMQ pack messages to byte arrays. OpenWire and Stomp are two different ways here. As ActiveMQ website says "OpenWire is designed for maximum performance and features; its the protocol used inside ActiveMQ. If you want a simpler protocol to work with to get started with a cross language client then tryStomp which is designed for ease-of-implementation so its easy to support many clients." So it is your choice.
Monday, 1 February 2010
Why UI application hangs and top possible reasons
These days I am investigating freezing UI application problem. It is very painful. No clues.
I tried reading logs of UI application, checking socket connection status, memory and CPU usage. But it does not help. Everything seems fine.
I tried to add logs when entering and leaving locks in UI application. It seems fine. Entering and leaving match.
I also tried Windows debugging tool and ANTS performance profiler. They are not really helpful since freezing does not happen all the time. And Windows debugging tool is kind of difficult to use. You need spend some time to learn how to use it. It is not straightforward telling you what is wrong with your codes.
The problem was finally solved 'by accident'. Somebody changed something and magically UI stopps hangging any more.
Take a look at change history, we found out hanging is caused by cross thread problem of UI application. UI thread creates a new UI object. The handler on the new UI object starts to doing something. The later change is to put these codes in a safe invoke scope. It looks like as followings.
UIObject b = new UIObject(); //For example a button
if ( b.InvokeRequired )
{
// fall into here if new thread is needed
}
else
{
//fall into here if no new thread is needed
}
So top issues I will focus on if unfortunately I have to investigate this problem again
1) CPU and memory usage. They are always the first suspect and easy to check.
2) Threads number of this application. Easy to check.
3) UI update should be covered in safe Invoke/BeginInvoke/EndInvoke scope. Just like the above example.
4) lock problems.
I tried reading logs of UI application, checking socket connection status, memory and CPU usage. But it does not help. Everything seems fine.
I tried to add logs when entering and leaving locks in UI application. It seems fine. Entering and leaving match.
I also tried Windows debugging tool and ANTS performance profiler. They are not really helpful since freezing does not happen all the time. And Windows debugging tool is kind of difficult to use. You need spend some time to learn how to use it. It is not straightforward telling you what is wrong with your codes.
The problem was finally solved 'by accident'. Somebody changed something and magically UI stopps hangging any more.
Take a look at change history, we found out hanging is caused by cross thread problem of UI application. UI thread creates a new UI object. The handler on the new UI object starts to doing something. The later change is to put these codes in a safe invoke scope. It looks like as followings.
UIObject b = new UIObject(); //For example a button
if ( b.InvokeRequired )
{
// fall into here if new thread is needed
}
else
{
//fall into here if no new thread is needed
}
So top issues I will focus on if unfortunately I have to investigate this problem again
1) CPU and memory usage. They are always the first suspect and easy to check.
2) Threads number of this application. Easy to check.
3) UI update should be covered in safe Invoke/BeginInvoke/EndInvoke scope. Just like the above example.
4) lock problems.
Subscribe to:
Posts (Atom)