HTTPD Server Post Requests work ........about half the time

[Andre Garzia]

Monte and Tom,

Yes, that is true. The client will wait for a while. It can still drop
though if for any reason the socket disconnects while waiting for an answer
(IIRC).

A good practice, is to cache and pre-process aggressively so that you need
to minimal work when the request actually arrives. If you know you will
need to do some database queries for each request and the data doesn't
change much often, such as:

"You are building a blog cms. Each post can have any number of comments.
Your user is interested in seeing a list of their recent posts and their
comments since his last visit. One normal way to do it, would be to use a
boolean field in each comment such as "seen" and flip it to true when shown
to the user. To assemble such page, you'd need to query for the posts and
then query for the comments, in a join operation which can be costly. Why
not pre-compute this when someone comment on an article. At that time, you
know the comment is "not seen yet" and you know which post it is related
to. You can add it to a special "inbox queue" so that when the user
arrives, this "inbox queue" requires no join or complex query minimizing
your I/O blocking"

That kind of stuff. Also, remember, the time after you answer the request
but before other request arrives (idle time) is perfect for maintenance
pre-computing.

On Mon, May 7, 2018 at 10:45 PM, Monte Goulding via use-livecode <
use-livecode at lists.runrev.com> wrote:

> Andre I think that should only be an issue if your number of requests *
> time per request > client timeout.
>
> Tom probably the best place to start is some logs of the requests and
> responses on both client and server.
>
> Cheers
>
> Monte
>
> > On 8 May 2018, at 11:28 am, Andre Garzia via use-livecode <
> use-livecode at lists.runrev.com> wrote:
> >
> > Remember that LC is using a single thread and that script execution is
> > blocking, so, if your server is busy doing work to respond to a request,
> > then it will probably not acknowledge an incoming request at the same
> time.
> > Or at least that was true for my RevHTTPd version...
> >
> > On Mon, May 7, 2018 at 12:13 PM, Tom Glod via use-livecode <
> > use-livecode at lists.runrev.com> wrote:
> >
> >> Hi folks, so spent the last 2 days working on getting my client to talk
> to
> >> a simple service I created taking advantage of the httpd library in v9.
> >>
> >> Everything works fine..... half the time. ....literally the request is
> >> identical each time but the result differs.
> >>
> >> the content type is set to text/plain..... so the (base64 encoded)
> content
> >> is in the "content" variable.
> >>
> >> but thats only true half the time.... the other time it comes in empty.
> >>
> >> I also checked my post request with an online "post request"
> >> mechanism...and 100 % of the requests come in correctly. so the problem
> >> must be on my httpd service end.
> >>
> >> Anyone have any clue what could be creating this inconsistency?
> >> _______________________________________________
> >> use-livecode mailing list
> >> use-livecode at lists.runrev.com
> >> Please visit this url to subscribe, unsubscribe and manage your
> >> subscription preferences:
> >> http://lists.runrev.com/mailman/listinfo/use-livecode
> >>
> >
> >
> >
> > --
> > http://www.andregarzia.com -- All We Do Is Code.
> > http://fon.nu -- minimalist url shortening service.
> > _______________________________________________
> > use-livecode mailing list
> > use-livecode at lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



-- 
http://www.andregarzia.com -- All We Do Is Code.
http://fon.nu -- minimalist url shortening service.