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

Reply via email to