Listen() in ow_net_server.c handles #1 automatically, more or less... It's set to handle 10 requests today, and according to the man-pages you see this: "If a connection request arrives when the queue is full, the client may receive an error with an indication of ECONNREFUSED or, if the underlying protocol supports retransmission, the request may be ignored so that a later reattempt at connection succeeds."
This means that it's possible to add a semaphore before calling accept() to avoid too many concurrent requests. A semaphore with max-val 10 will allow 10 running requests + 10 requests in queue. All other connecting applications should only be prepared to handle ECONNREFUSED, and either retry or report an error. Might be a good idea to accept() the 21st request and send an ow-package saying EBUSY though, so make it more visible that owserver is listening, BUT it's too busy handling your request. We will then need to raise the listen() queue a bit too just to handle those error-responses. Doing anything else is probably un-safe, since it's could result into too growing number of requests waiting to be handled. It's impossible to know if a request will take 1ms or 3 seconds to handle, since the request might be forwarded to another remote-owserver and where it's waiting for a LOCK to be completed. This applies to both cached and uncached values. This means that #4 and #5 is not solving anything. #2 and #3 is just too complex and will be hard to implement I think. /Christian -----Original Message----- From: Paul Alfille [mailto:paul.alfi...@gmail.com] Sent: den 10 juni 2009 04:21 To: owfs-developers@lists.sourceforge.net Subject: Re: [Owfs-developers] Two owserver problems 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 ------------------------------------------------------------------------------ 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
