Hi Steinar, I've been playing with your setup, and noticed one design problem right away -- currently there is no throttling of the number of queries queued by owserver. The loop can wrap around while owserver is still busy with the prior set of requests.
I'm not sure of the best way to handle this. Some thoughts: 1. limit the total requests being processed at the same time, A by not accepting new sockets until there is space, or B. by returning an EBUSY error message. 2. try to merge requests. (Only works if the same request is pending -- not certain, and messy). 3. cancel older pending requests, either in progress, or ones waiting for the bus to be free. 4. limit uncached requests 5. limit slow requests -- e.g. temperature and humidity A no limit on in-memory data (like device name) B. no limit on cached data In terms of ease of implementation easiest to hardest 1,4,5,3,2 In terms of least surprise to users: 2,1,4,3,5. So I'd like #1. (or #5) How would this be handled in a typical use case, say 1 thread reading temperature in a tight loop and a second doing occational monitoring and control? The loop thread would accept the busy and move on, while the control would repeat on busy to get a reading. Still, I need thoughts and input on a design change like this. Paul Alfille On Mon, Jun 8, 2009 at 2:43 AM, Steinar Midtskogen<stei...@latinitas.org> wrote: >> The problem seems to be that owserver is relatively fine as long as >> the requests come in an orderly fashion, such as in this script: > ... > >> But if I change the script to requesting everything at the same time, >> like this: >> >> #!/bin/sh >> >> while true; do >> owget -s 3000 uncached/10.7F1914000800/temperature & >> owget -s 3000 20.E0C700000000/volt.ALL & >> owget -s 3000 uncached/1D.0A5201000000/counters.A & >> owget -s 3000 10.7F1914000800/temperature & >> owget -s 3000 26.22FB4F000000/temperature & >> owget -s 3000 26.22FB4F000000/VDD & >> sleep 5 >> done >> >> then owserver breaks within seconds, owget processes pile up because >> owserver doesn't respond for some files. Eventally owserver might crash. > > Anything I can do to debug this? It's easy to reproduce. Owserver > seems pretty fragile, i.e. it'll crash under some load. > ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers