Unable to recover from queue full exception errors

165 views
Skip to first unread message

Murat Egrikavuk

unread,
Feb 6, 2012, 5:20:45 AM2/6/12
to sedo...@googlegroups.com

(This could be for the Niagara-Central forum but I am not 100% sure. I am initially posting here rather than the wider Niagara community, please redirect if necessary)

To test performance of multiple Sedona controllers in a niagara setting, we have setup the following:
- One PC, running 15 instances of Sedona device, on different ports
---- Each virtual sedona device running at 50 msec scan time
---- Each virtual sedona device has 20 components, with a slot that changes every cycle
- A jace6, running a station with the TXS1.1 sedonanet, subscribing to all 20 points of all 15 virtual sedona devices.

You open up 15 tabs in Workbench so all these points are subscribed and everything works as expected. Then you introduce a major load in the system by clicking the RefreshTabs menu. This causes a major instability in the system with a whole lot of "queue full exception" messages. Many of the points, seemingly randomly, go into fault status. Others seem normal, but stop updating. Some others do receive updates, but only occasionally. There seems to be no way out of this situation, other then restarting the station.

It seems either the Sedona side or the Niagara driver needs some sort of prevention mechanism to recover from this sort of instability. The load described above is not exceptional (15 devices with a total 300 evenly distributed subscribed points). The intervention (refreshTabs) can be called exceptional, but it is impossible to tell all conditions real-life installations will experience.

Craig

unread,
Feb 6, 2012, 6:42:00 AM2/6/12
to sedo...@googlegroups.com, murat.e...@ontrol.com.tr
Hi Murat-

This sounds more like an issue with the Niagara driver than with the Sedona device code.  I have reposted this to the SedonaFramework / General Niagara Central forum.  Thanks for describing your setup, it sounds like it should be possible to replicate this behavior.

-Craig
Reply all
Reply to author
Forward
0 new messages