Perfomrance issue with DVRs

[Yamaeda]

Could reentrancy be a factor? Might there be some VI that locks the others?

/Y

[Mark_Yedinak]

To answer several of the questions. In my test application there should only be two instances using this class. All timeouts have been removed with the exception of the method above. I put a large timeout but it was needed to keep the system from hanging. I have gone through the properties of the methods and they are marked as reentrant with preallocation. All of the methods are set to normal priority and run in the same thread as the caller. I have considered putting in some simple logging but have held off to see if I could find the issue first. Also, the cluster contaied in the queue is very basic and not large. It should only be 100 to 200 bytes in length. Certainly that wouldn't cause any delay if an extra copy was made.

[GregFreeman]

---

@Mark_Yedinak wrote:

To answer several of the questions. In my test application there should only be two instances using this class. All timeouts have been removed with the exception of the method above. I put a large timeout but it was needed to keep the system from hanging. I have gone through the properties of the methods and they are marked as reentrant with preallocation. All of the methods are set to normal priority and run in the same thread as the caller. I have considered putting in some simple logging but have held off to see if I could find the issue first. Also, the cluster contaied in the queue is very basic and not large. It should only be 100 to 200 bytes in length. Certainly that wouldn't cause any delay if an extra copy was made.

---

Can you reproduce in a small project that you could post?

[Mark_Yedinak]

---

@for(imstuck) wrote:

---

@Mark_Yedinak wrote:

To answer several of the questions. In my test application there should only be two instances using this class. All timeouts have been removed with the exception of the method above. I put a large timeout but it was needed to keep the system from hanging. I have gone through the properties of the methods and they are marked as reentrant with preallocation. All of the methods are set to normal priority and run in the same thread as the caller. I have considered putting in some simple logging but have held off to see if I could find the issue first. Also, the cluster contaied in the queue is very basic and not large. It should only be 100 to 200 bytes in length. Certainly that wouldn't cause any delay if an extra copy was made.

---

Can you reproduce in a small project that you could post?

---

This would be rather difficult. I wish I could post it but there are lots of classes involved and pulling all of that out would be a fairly big task.

[GregFreeman]

---

@Mark_Yedinak wrote:

This would be rather difficult. I wish I could post it but there are lots of classes involved and pulling all of that out would be a fairly big task.

---

I will take the manager approach to this one: How long have you been troubleshooting vs how long would it take to pull all the classes out ?

[tst]

---

@Mark_Yedinak wrote:

All timeouts have been removed with the exception of the method above. I put a large timeout but it was needed to keep the system from hanging.

---

Sounds like a bug - if the system hangs with an infinite timeout, it presumably means something is not releasing the lock. I would guess it was deadlock, but I have nothing to actually base that on.

Incidentally, if the system doesn't hang with the DVR, it would seem to suggest that something about the implementation is different as a SEQ with an infinite timeout should behave the same as a DVR. Again, if I had to guess (which I really don't like to do), I would guess this had to do with something being called inside the lock in one implementation and outside it in another (the scope of the code affected by the lock is clearer with the DVR because you have the structure. With a SEQ you might get race conditions where unrelated code is sometimes affected by the lock and sometimes not).

[Mark_Yedinak · Accepted solution]

Well, after a bit of instrumenting code I found the root of the issue. One, as noted was the short timeouts. I also changed some reentrancy to allow for more parallelization. It turned out that the delay was actually caused by a invalid route in the messaging system. This actually delayed the message servers which resulted in the UI update delays. I did switch this to DVRs and it is working fine now. It also works correctly with the SEQ. This still turned out to be a good exercise since I discovered the bug with invalid message routes and ended up fine tuning this to up the performance.